Статья Как мы дважды проникли в домен, который считался неприступным

[stihl]

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

Pentest Award​

Этот текст занял третьей место на премии Для просмотра ссылки Войди или Зарегистрируйся в категории «Пробив инфры». Соревнование ежегодно проводит компания Awilix.
Дело было осенью 2022 года. Мы работали вдвоем с коллегой: он отвечал за веб‑уязвимости, а я за анализ инфраструктуры — сервисы, домен и прочее.


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

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

И действительно, проект оказался непростым, учетную запись в домене мне не предоставили. Я проверил возможность LLMNR poisoning и прочие вариации этой атаки, попробовал слушать трафик, сканировал на предмет наличия популярных уязвимостей (Bluekeep, EternalBlue и тому подобных), проверил анонимные файловые ресурсы, нашел и изучил принтеры и МФУ. Веб тоже не дал никаких надежд.

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

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

info​

Название домена целевой организации на всех скриншотах замазано, в текстовой части заменено test.local.

warning​

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

Ход атаки​

С заказчиком у нас был заключен договор сразу на два проекта, и весной 2023 года мы вернулись к нему снова, в ту же самую инфраструктуру, с той же самой точкой подключения, сервисов DameWare в сети уже не нашли. Заказчик с еще большей уверенностью стал заявлять, что в этот раз у нас точно ничего не получится, так как все замечания и единственный найденный нами баг они устранили. Даже спор снова предложил, а мы снова отказались. И снова пожалели об этом!

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

И тут на одном из веб‑ресурсов мне попалось опубликованное .NET-приложение.

Веб‑ресурс ppo-app


После нажатия кнопки Start на странице Для просмотра ссылки Войди или Зарегистрируйся происходит скачивание исполняемых файлов приложения во временную директорию на компьютере пользователя. Я подробно изучил скачанное приложение и выяснил, что оно подключается к базе данных Microsoft SQL, размещенной на хосте PPO-BD.test.local. Учетные данные для подключения к базе находятся в файле star.exe.config, который скачивается вместе с приложением.

Окно настроек подключения к базе данных


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

Параметры подключения к базе данных в star.exe.config


Для расшифровки пароля я декомпилировал приложение с помощью Для просмотра ссылки Войди или Зарегистрируйся. В динамической библиотеке Star.Wpf.Controls.dll нашлась функция EncryptionLogic, содержащая ключ шифрования и алгоритм расшифровки. В результате мне удалось получить пароль от учетной записи базы данных asabrys (это не доменная учетная запись). Затем с помощью Для просмотра ссылки Войди или Зарегистрируйся я подключился к базе данных.

У скомпрометированной учетки были права sysadmin в пределах MS SQL, чем я и воспользовался, чтобы включить оболочку xp_cmdshell, позволяющую исполнять команды операционной системы.

Оказалось, что сервер базы данных работает в контексте служебной учетной записи MSSQL$SQLEXPRESS, у которой есть привилегия SeImpersonatePrivilege, то есть можно выполнять команды в контексте любой учетной записи, в том числе системной.

Функция расшифровки пароля для подключения к базе данных (файл Star.Wpf.Controls.dll)


Чтобы загрузить необходимые инструменты на хост PPO-BD.test.local, я развернул FTP-сервер на рабочей станции, с которой проводил тестирование. Для эскалации привилегий до уровня SYSTEM я использовал инструмент Для просмотра ссылки Войди или Зарегистрируйся. С его помощью создал учетку локального администратора itadmin. Затем со своего компьютера подключился к хосту PPO-BD.test.local по протоколу RDP и с помощью обфусцированной сборки Для просмотра ссылки Войди или Зарегистрируйся создал дамп памяти системного процесса lsass.exe и извлек хранящиеся там учетные данные.

В дампе памяти нашелся NTLM-хеш пароля учетной записи компьютера test.local\PPO-BD$. Других актуальных доменных учеток на хосте PPO-BD.test.local не было.

Я использовал Для просмотра ссылки Войди или Зарегистрируйся, чтобы запросить TGT-билет Kerberos для учетной записи test.local\PPO-BD$, используя NTLM-хеш ее пароля. Это позволило получить доступ в домен test.local.

Привилегии и контекст учетной записи сервера базы данных на хосте PPO-BD

Выполнение техники Pass the Hash для учетной записи PPO-BD$


Используя учетную запись компьютера PPO-BD$, я собрал информацию о домене, включая данные о групповых политиках. При анализе скриптов, запускаемых этими политиками, удалось найти несколько файлов, в которых был прописан пароль для локальной учетной записи LocalAdmin.

Пароль для локальной учетной записи LocalAdmin в скрипте


Я подключился к серверу OMO-FSCHANGE.test.local от имени учетной записи LocalAdmin. Быстрый осмотр содержимого дисков не принес ничего полезного — ценных данных не нашлось, активных сессий администраторов тоже не было. Зато удалось сделать дамп хранилища локальных учетных записей (LSA).

Дамп LSA на хосте OMO-FSCHANGE.test.local


Извлеченные из LSA локальные учетные данные включали NTLM-хеш локальной учетки admin-omsk, которая состоит в группе локальных администраторов. После перебора хеша по словарю удалось восстановить пароль — 16010916.

С помощью локальной учетной записи admin-omsk я получил доступ к серверу OMO-TECH.test.local. На этом сервере нашел активную сессию учетной записи с таким же именем, но уже доменной — test.local\admin-omsk.

Сессии на сервере OMO-TECH


Хоть учетная запись test.local\admin-omsk и не входила в состав доменных административных групп, она оказалась владельцем учетных записей администраторов, отвечающих за регион «ОМСК».

Владелец учетной записи omo-adminvrs


Права локального администратора позволили извлечь TGT-билет Kerberos для test.local<wbr>admin-omsk из памяти системного процесса и выполнить атаку Pass the Ticket.

Результат атаки Pass the Ticket на учетку admin-omsk


Поскольку учетная запись test.local\admin-omsk была владельцем в том числе учетной записи test.local\omo-adminvrs, я добавил для нее привилегии GenericAll. Это открыло возможность провести атаку Shadow Credentials, при которой генерируется пара ключей и открытый ключ записывается в атрибут ms-DS-Key-Credential-Link. С помощью этой пары из открытого и закрытого ключей удалось запросить TGT-билет Kerberos и использовать его для аутентификации в домене.

Результат атаки Shadow Credentials на учетку omo-adminvrs


Я установил, что члены группы omo-admin-group, включая учетную запись test.local\omo-adminvrs, имеют права (ACL) на 4507 объектов в домене. Среди этих прав — GenericWrite на серверы SRVDIRECTUM-SQL и SRV-ND-PROD-WIN. В поисках вариантов компрометации домена и учетных записей с повышенными привилегиями я провел атаку Shadow Credentials на объект SRVDIRECTUM-SQL$ и получил возможность запросить для него билет TGT.

Атака Shadow Credentials на учетку SRVDIRECTUM-SQL$


Следующим шагом я извлек NTLM-хеш компьютерной учетной записи SRVDIRECTUM-SQL$ с помощью UnPAC the Hash.

Получение NTLM-хеша для учетной записи test.local\srvdirectum-sql$


Эта технология основана на использовании PKINIT, при котором клиент может запросить дополнительный тикет. В этом тикете KDC включает PAC_CREDENTIAL_INFO — специальную структуру, содержащую NTLM-ключи аутентифицирующего пользователя. Это дает клиенту возможность переключаться на NTLM-аутентификацию для служб, которые не поддерживают Kerberos.

Полученный NTLM-хеш использовался в технике Silver Ticket, которая позволяет генерировать сервисные билеты (TGS) Kerberos для любых доменных учетных записей. Эти билеты будут обладать всеми привилегиями на хосте, которыми обладал бы зашедший на хост пользователь. В результате мы сгенерировали сервисные билеты для доменного администратора test.local\d.syroezhkin, у которого есть права локального админа на хосте SRVDIRECTUM-SQL.

Билеты TGS на имя d.syroezhkin


С полученными правами удалось создать дамп процесса LSASS и извлечь из него пароли еще для некоторых доменных учеток.

Извлеченные из памяти процесса LSASS на хосте SRVDIRECTUM-SQL пароли


Таким же способом я получил доступ к хосту SRV-ND-PROD-WIN.

Права GenericWrite на объект SRV-ND-PROD-WIN$


В памяти процесса LSASS ничего интересного не нашлось. Поэтому мы собрали данные о локальных учетных записях из хранилища SAM. В результате получили хеш NTLM для локальной учетной записи Administrator и перебором по словарю извлекли пароль Pa******123.

NTLM-хеш для локального администратора на хосте SRV-ND-PROD-WIN


В результате атаки Pass the Hash я установил, что эта учетная запись с таким же паролем используется на следующих серверах:

• SRV-ND-PROD-ACCEPT.TEST.LOCAL;
• SRV-ND-PROD-AUT.TEST.LOCAL;
• SRV-ND-PROD-WIN-KODWEB.TEST.LOCAL;
• HV1-GORIZONT.TEST.LOCAL;
• SRV-WITNESS-EX.TEST.LOCAL.

Особый интерес представляет сервер SRV-WITNESS-EX. Он входит в группы Exchange Trusted Subsystem и Exchange Windows Permissions как сервер Exchange.

Членство в группах компьютерной учетной записи SRV-WITNESS-EX$


В свою очередь, Exchange Windows Permissions может добавлять членов в группу AD_Mgmt, которая имеет права GenericWrite на контроллеры домена.

Возможные векторы развития атаки после захвата учетной записи SRV-WITNESS-EX$


Для начала, используя права локального администратора, я извлек хеш NTLM-пароля компьютера из локального хранилища LSA на хосте SRV-WITNESS-EX. Полученный хеш NTLM я использовал в атаке Overpass the Hash для получения TGT-билета Kerberos. Это позволило внести изменения в состав доменной группы AD_Mgmt. При этом использовалась доменная учетная запись wa, скомпрометированная ранее на хосте SRVDIRECTUM-SQL.

Добавление учетной записи wa в группы AD_Mgmt


В качестве конечной цели я выбрал контроллер домена SRVDC01. Через атаку Shadow Credentials удалось сгенерировать пару ключей, с помощью которых я получил TGT-билет Kerberos для учетной записи контроллера домена. После этого провел атаку DCSync на учетную запись test.local\admin-voinov, что позволило извлечь хеш AES256 от ее пароля. Билет TGT также открыл доступ на сам контроллер домена.

Для просмотра ссылки Войди или Зарегистрируйся

Доступ на контроллер домена SRVDC01

Схема атаки
Для полноты картины я включу сюда из отчета рекомендации, которые дал заказчику на основе изменений, сделанных в его инфраструктуре. Вот что я менял:

1. На сервере PPO-BD.test.local создал локальную учетную запись администратора itadmin. Заказчику рекомендуется ее удалить.
2. Изменил значение атрибута msDS-KeyCredentialLink для объекта test.local\srvdirectum-sql$. Заказчику рекомендуется обнулить значение атрибута.
3. Изменил значение атрибута msDS-KeyCredentialLink для объекта test.local\srv-nd-prod-win$. Заказчику рекомендуется обнулить значение атрибута.
4. Изменил значение атрибута msDS-KeyCredentialLink у учетной записи test.local\omo-adminvrs. Заказчику рекомендуется обнулить значение атрибута.
5. Назначил права GenericAll учетной записи test.local\admin-omsk на test.local\omo-adminvrs. Заказчику рекомендуется отозвать их.

Рекомендации​

По итогам тестирования я дал заказчику следующие рекомендации:

• сменить пароль для скомпрометированной локальной учетной записи LocalAdmin на всех машинах;
• сменить пароль для скомпрометированной локальной учетной записи admin-omsk на всех машинах;
• удалить скрипты, содержащие пароли;
• вместо скриптов использовать технологию LAPS;
• отключить механизм wdigest, который позволяет хранить пароли в открытом виде;
• настроить антивирус на запрет дампа процесса LSASS;
• провести оценку прав для группы omo-admin-group в отношении других объектов домена на предмет их избыточности.

Выводы​

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

После получения доступа в домен мне удалось получить доступ к цепочке промежуточных серверов, что в итоге дало административный доступ к контроллеру домена. К компрометации домена привели несколько ключевых факторов: открытое хранение паролей в скриптах, использование слабых паролей для административных учетных записей и небезопасная настройка ACL, которая позволяла злоупотреблять избыточными правами объектов домена.

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