Точка входа: есть доступ, нет опоры.

Иногда доступ во внутреннюю сеть — это не начало атаки, а тупик. Именно в такой ситуации я оказался в самом начале.

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

Кратко напомню отправную точку: в ходе тестирования внешней инфраструктуры заказчика нам удалось получить доступ во внутреннюю сеть через туннелирование. Чтобы не дублировать материал, отмечу лишь, что схема была реализована по подходу, описанному у моих друзей из компании «Deiteriy Lab» в статье - https://habr.com/ru/companies/deiteriylab/articles/920064/. Способ отличный и полностью рабочий, советую взять на вооружение. Для общего представления приведу схему подключения, которую мы использовали (так же взята из статьи).

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

На машине был установлен антивирус Kaspersky, но, к моему удивлению, его процессы без проблем завершались через диспетчера задач. После этого я решил проверить самый очевидный сценарий — быстро собрать учетные данные. На хост был загружен Mimikatz, сняты SAM и дамп LSASS. Однако результат оказался довольно скромным: хэш локального администратора и одна доменная учетная запись без каких-либо привилегий. Ситуацию дополнительно осложняло то, что сама машина не состояла в домене, а значит, как опорная точка для дальнейшего продвижения она подходила слабо.

Разведка: когда быстрый путь не сработал

Если не получилось «взломать сходу», значит придётся понять, как вообще устроена инфраструктура — и где в ней слабые места.

Когда «быстрый путь» не срабатывает, почти всегда приходится возвращаться к базе — разведке. В процессе исследования инфраструктуры стало понятно, что сеть разделена на два сегмента, каждый из которых обслуживает свой домен: Corp.local.ru и Sub.corplocal.ru. При этом между доменами не было настроено доверительных отношений, хотя по именам было очевидно, что один из них играет основную роль, а второй — скорее прикладную.

Имея учетную запись пользователя из основного домена, я начал аккуратно собирать картину сети. Чтобы не шуметь лишний раз, сначала через fping собрал список доступных хостов, а затем уже с помощью nmap и netexec прошёлся по ним более детально, формируя представление об операционных системах и сервисах. Отдельно я прогнал свой стандартный пайплайн для поиска веб-сервисов во внутренней сети — связку masscan, nmap и EyeWitness. Это довольно простой, но эффективный способ быстро понять, какие внутренние веб-интерфейсы вообще существуют и заслуживают внимания.

masscan -p 80,443,8080,8443,8000 -i eth0 | tee web_ports.txt
cat web_ports.txt | awk {'print $6'} | sort | uniq > web_hosts.txt
nmap -p 80,443,8080,8443,8000 -iL web_hosts.txt -oX nmap_scan_web.xml
eyewitness -x nmap_scan_web.xml -d eyew –web

Если коротко, то скрипт реализует типичный пайплайн первичного веб-ресёрча (recon) по сети:

• masscan — быстро сканирует сеть через интерфейс eth0 на наличие открытых веб-портов (80, 443, 8080, 8443, 8000) и сохраняет результат в web_ports.txt.

• Обработка результатов (awk + sort + uniq) — из вывода masscan извлекаются IP-адреса хостов с открытыми портами → формируется уникальный список web_hosts.txt.

• nmap — более детально сканирует найденные хосты по тем же портам, собирает сервисную информацию и сохраняет результат в XML (nmap_scan_web.xml).

• EyeWitness — по результатам nmap делает скриншоты веб-сервисов и собирает веб-артефакты в директорию eyew.

Параллельно, поскольку инфраструктура была преимущественно на базе Windows, я собрал данные для BloodHound, пользователей, группы, доступные SMB-шары и параметры парольной политики. И именно на этом этапе появился первый действительно интересный зацеп.

Первый зацеп: то, что не должно было попасться.

Чаще всего первая серьёзная уязвимость находится не в сложной технике, а в банальной операционной ошибке. Здесь всё оказалось именно так.

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

Внутри нашёлся каталог с резервными копиями конфигурации Zabbix-сервера.

Распаковав архив, я достал файл etc/shadow, содержащий хэши паролей пользователей системы.

Полученные хэши сразу были отправлены на брутфорс при помощи утилиты «JohnTheRipper». Каково было мое удивление, когда через пару минут я получил пароль от root. Ох уж это номинальное соблюдение парольных политик в организациях))).

Полученный пароль я сначала проверил по назначению — доступ по SSH к серверу с Zabbix оказался успешным. После этого, как это обычно бывает, возникло очевидное предположение: а вдруг пароль используется где-то ещё. Попытка password spraying по доменным учеткам результата не дала, зато при проверке локальных пользователей на разных машинах всё оказалось гораздо интереснее — удалось получить несколько локальных администраторов сразу в обоих доменах.

Закрепление в домене: доступ есть, развития нет.

Получить локального администратора — приятно. Понять, что это не даёт продвижения — уже менее приятно.

Дальше мы с коллегами разделили зоны ответственности, и я сосредоточился на домене Sub.corplocal.ru, где у меня уже был доступ к одному из серверов с правами локального администратора. Подключившись по RDP и отключив антивирус, я повторил попытку извлечения учетных данных через Mimikatz, но на этот раз снова без особого успеха: кроме уже известных сущностей и NTLM хэша машинной учетной записи ничего полезного получить не удалось.

Принудительная аутентификация и NTLM Relay

Когда прямые методы не работают, приходится заставлять систему «атаковать саму себя».

В этот момент я решил сменить подход и поискать уязвимости, связанные с принудительной аутентификацией и relay-атаками. Довольно быстро нашлась связка: машина, уязвимая к PetitPotam, и цель, на которую можно было зарелейтить аутентификацию. Дальше всё развивалось по классическому сценарию.  В одном терминале запустил Impacket-ntlmrelayx.

А в другом запустил эксплуатацию уязвимости PetitPotam скриптом, взятым отсюда (https://github.com/topotam/PetitPotam).

Атака сработала, и я получил доступ к системе через SMB-шелл. Выполнять команды на атакуемом хосте я не мог. Однако была возможность читать и записывать файлы. Но этого оказалось достаточно.

От записи файлов к выполнению кода

Иногда между «у меня есть доступ к файлам» и «у меня есть полный контроль» — всего один шаг. Важно его вовремя увидеть.

 В файловой системе я обнаружил каталог C:\inetpub\wwwroot — корень веб-сервера IIS. Это сразу открыло понятный вектор: загрузка ASPX-шелла. Для этой цели я использовал ASPX Shell от xl7dev («https://raw.githubusercontent.com/xl7dev/WebShell/master/Aspx/ASPX Shell.aspx»). После размещения web-shell’а я получил уже полноценное удалённое выполнение команд.

Эскалация привилегий: почти максимум — это ещё не максимум

Даже получив выполнение команд, ты всё ещё можешь быть далёк от цели. Вопрос только в том, какие привилегии у тебя уже есть.

С этого момента работа пошла заметно быстрее. Первым делом я проверил доступные привилегии и обнаружил SeImpersonatePrivilege — один из тех флагов, которые почти всегда означают потенциальную эскалацию до SYSTEM.

И снова антивирус нам не помеха. Попытки воспользоваться различными вариантами «Potato»-эксплойтов не дали результата, поэтому я пошёл более надёжным путём и загрузил Meterpreter (в составе Metasploit Framework). В результате установления обратного TCP-соединения был получен интерактивный шелл с привилегиями текущего пользователя.

Внутри сессии Meterpreter был выполнен модуль getsystem который использовал эту привилегию для создания токена NT AUTHORITY\SYSTEM и подмены контекста выполнения. В результате получен шелл с максимальными привилегиями. Операция завершилась успешно: шелл-сессия была эскалирована до максимального уровня привилегий в системе.

Критическая точка: домен начинает «сыпаться»

Есть момент, после которого инфраструктура перестаёт сопротивляться. Здесь он наступил именно на этом этапе.

Получив наивысшие права в системе, я снова запустил Mimikatz и тут удача мне улыбнулась. Из Процесса LSASS мне удалось извлечь NTLM хэш пароля администратора домена. Используя его, я смог выгрузить NTDS.DIT, то есть фактически получить базу всех NTLM-хэшей домена. На этом этапе домен Sub.corplocal.ru можно было считать полностью скомпрометированным.

Низко висящие фрукты: когда атака масштабируется сама

После этого я подключился к коллегам, которые в это время продолжали работу с основным доменом. Решение, которое я попробовал дальше, нельзя назвать изящным, но оно часто срабатывает. Я взял хэши из NTDS и прогнал их по списку пользователей второго домена в рамках password spraying.

Результат оказался неожиданно щедрым: сразу две учетные записи с правами администратора домена.

Дальше всё было уже делом техники — pass-the-hash и повторный дамп NTDS, но уже во втором домене.

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

Выводы: компрометация — это всегда цепочка, а не одна ошибка

Если посмотреть на весь кейс целиком, становится очевидно: ни один из этапов сам по себе не был чем-то уникальным или особенно сложным. Здесь не было zero-day уязвимостей или изощрённых техник, требующих глубокой кастомной разработки. Вся атака — это последовательное использование вполне известных подходов, которые сработали из-за сочетания организационных и технических недочётов.

Ключевая проблема — в накопительном эффекте. Каждая отдельная слабость выглядела не критичной:

• резервные копии с чувствительными данными оказались доступны из сети,

• пароль root был слабым и быстро подобрался,

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

• локальные администраторы имели избыточные права,

• в инфраструктуре оставались уязвимости уровня PetitPotam,

• присутствовали привилегии вроде SeImpersonatePrivilege, позволяющие эскалацию.

По отдельности это типичные «средние» проблемы. Но в связке они образовали непрерывную цепочку атаки — от одной скомпрометированной машины вне домена до полного контроля над двумя доменами.

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