HTB Monteverde: повышение привилегий через Azure AD Connect и пароль MSOL-аккаунта

Monteverde на HackTheBox — одна из тех машин, где путь до Domain Admin идёт не через переполнение буфера или дырку в ядре, а через штатный компонент Microsoft. Azure AD Connect — инструмент синхронизации локального Active Directory с облачным Azure AD — хранит пароль привилегированного сервисного аккаунта в локальной SQL-базе. Этот пароль расшифровывается одним PowerShell-скриптом. В реальных аудитах Windows-инфраструктур та же конфигурация регулярно всплывает в проектах с гибридной идентификацией, и каждый раз это прямой маршрут до полной компрометации домена. Разберём всю цепочку по шагам: от анонимного RPC-подключения до извлечения пароля Domain Admin.

Место в цепочке атаки: от разведки до Domain Admin

Прежде чем открывать терминал, стоит увидеть маршрут целиком. MITRE ATT&CK — открытая база тактик и техник атак, где каждой технике присвоен уникальный T-код (например, T1087 — Account Discovery). Думайте о ней как о «каталоге приёмов», которыми пользуются атакующие. На языке ATT&CK цепочка Monteverde выглядит так:

1. Discovery — перечисление пользователей AD через анонимный RPC-запрос (T1087.002 — Domain Account).
2. Initial Access — найденная валидная пара используется для входа через доменную учётную запись (T1078.002 — Domain Accounts).
3. Credential Access — открытый пароль пользователя mhope в XML-файле на SMB-шаре (T1552.001 — Credentials In Files).
4. Privilege Escalation — извлечение пароля администратора из базы данных службы Azure AD Connect (T1556.007 — Hybrid Identity).

Каждый шаг опирается на результат предыдущего. Если password spray не сработает — возвращаемся к разведке и ищем другой вектор. На реальном пентесте именно такая методология определяет эффективность: не перебор всех техник подряд, а осмысленное продвижение по цепочке.

Контекст: внутренний пентест Active Directory, grey box — мы знаем, что цель — Windows-домен, но учётных данных на старте нет. В реальном проекте начальная позиция — VPN-доступ в корпоративную сеть или подключённый к розетке ноутбук.

Разведка: сканирование портов и перечисление пользователей AD

Требования к окружению: Kali Linux (или любой дистрибутив с nmap, rpcclient, smbclient), сетевой доступ к целевому IP 10.10.10.172, минимум 2 ГБ RAM. На HTB нужен активный VPN через OpenVPN.

Сканирование портов

Первый шаг в любом пентесте Active Directory — узнать, какие сервисы доступны. Запускаем nmap -p- --min-rate 10000 10.10.10.172 для быстрого обнаружения всех открытых TCP-портов, затем nmap -p 53,88,135,139,389,445,5985,9389 -sC -sV 10.10.10.172 для детального анализа.

Ожидаемый результат: 19 открытых портов. На что смотреть:

• 53/tcp (DNS) + 88/tcp (Kerberos) + 389/tcp (LDAP) — классическая триада контроллера домена. DC (Domain Controller) — сервер, который управляет учётными записями и политиками Active Directory. Видите эту тройку — перед вами DC.
• 445/tcp (SMB) — файловые шары. Именно здесь позже найдётся пароль в конфигурационном файле.
• 5985/tcp (WinRM) — Windows Remote Management, удалённое управление через PowerShell. Если найдём учётные данные пользователя из группы Remote Management Users — получим шелл.

Nmap также покажет домен MEGABANK.LOCAL и имя хоста MONTEVERDE. Контроллер домена, вся AD-инфраструктура на одном сервере.

Перечисление пользователей через RPC

Зачем: нам нужен список учётных записей домена для последующего подбора паролей. На многих DC анонимное подключение к RPC (Remote Procedure Call — протокол, позволяющий удалённо вызывать функции на сервере) разрешено по умолчанию. Это T1087.002 — Domain Account Discovery по MITRE ATT&CK. Подключаемся rpcclient -U "" -N 10.10.10.172 (пустой логин, без пароля) и выполняем querydispinfo.

Получаем 10 учётных записей. Три из них интересны:

Описание аккаунта AAD_987d7f2f57d2 содержит фразу «Synchronization Service» — прямое указание на установленный Azure AD Connect. Запишите эту деталь: она понадобится для повышения привилегий.

Тот же результат можно получить через ldapsearch -x -H ldap://10.10.10.172 -b "dc=megabank,dc=local" или enum4linux -a 10.10.10.172. Все три инструмента эксплуатируют одну мисконфигурацию — разрешённые анонимные запросы (A05:2021 — Security Misconfiguration по классификации OWASP).

Подбор пароля: HTB Monteverde writeup и password spray

У нас есть список пользователей, но нет паролей. Прежде чем искать сложные уязвимости, проверяем простое: не использует ли кто-то имя учётной записи в качестве пароля. Создаём файл users.txt с именами всех обнаруженных пользователей и запускаем CrackMapExec (CME) — инструмент автоматизации проверки учётных данных в Windows-сетях. (Проект официально не поддерживается с 2023 года, актуальный форк — NetExec/nxc с аналогичным синтаксисом.)

crackmapexec smb 10.10.10.172 -u users.txt -p users.txt --continue-on-success

CME перебирает каждую пару «логин:пароль» из двух файлов. Флаг --continue-on-success заставляет не останавливаться после первого попадания.

Среди десятков строк STATUS_LOGON_FAILURE одна покажет успех: SABatchJobs:SABatchJobs. Сервисный аккаунт, чей пароль совпадает с именем. На реальных пентестах это встречается чаще, чем хотелось бы — особенно у batch-аккаунтов, созданных «временно» и забытых.

Когда password spray НЕ работает: если в домене включена политика блокировки аккаунтов (Account Lockout Threshold). На Monteverde порог — None (видно из вывода enum4linux). В реальной среде с порогом 3–5 попыток нужно ограничивать скорость и количество попыток на аккаунт, иначе залочите половину домена и получите звонок от SOC.

Пароль в конфигурационном файле: SMB и azure.xml

С учётными данными SABatchJobs:SABatchJobs перечисляем SMB-шары командой smbclient -L //10.10.10.172 -U SABatchJobs. Появляются шары, скрытые от анонимного доступа: users$ и azure_uploads.

Подключаемся к users$ и находим единственный файл — mhope/azure.xml. Скачиваем и видим:

<Objs Version="1.1.0.1">
  <Obj RefId="0">
    <Props>
      <DT N="StartDate">2020-01-03T05:35:00</DT>
      <DT N="EndDate">2054-01-03T05:35:00</DT>
      <G N="KeyId">00000000-0000-0000-0000-000000000000</G>
      <S N="Password">4n0therD4y@n0th3r$</S>
    </Props>
  </Obj>
</Objs>

Пароль открытым текстом: 4n0therD4y@n0th3r$. Это T1552.001 (Credentials In Files) — учётные данные, сохранённые в конфигурационных файлах. В реальных инфраструктурах аналогичные находки — скрипты развёртывания, конфиги CI/CD, бэкапы групповых политик. Я на одном проекте нашёл пароль от SA в .ps1-скрипте, который лежал в SYSVOL и был доступен любому доменному пользователю.

Проверяем: crackmapexec winrm 10.10.10.172 -u mhope -p '4n0therD4y@n0th3r$'. Ответ — Pwn3d!. Подключаемся через evil-winrm -i 10.10.10.172 -u mhope -p '4n0therD4y@n0th3r$' и получаем PowerShell-шелл. Флаг user.txt лежит в C:\Users\mhope\Desktop.

Повышение привилегий: эксплуатация Azure AD Connect и MSOL-аккаунта

Теперь главная часть разбора машины HackTheBox Monteverde — подъём до Domain Admin. Здесь нет стандартного эксплойта под бинарник. Работает архитектурная особенность Azure AD Connect.

Архитектура Azure AD Connect и уязвимость MSOL

Azure AD Connect (сейчас Microsoft Entra Connect) синхронизирует учётные записи между локальным AD и облачным Azure AD. Если упрощённо: чтобы пользователь мог логиниться одним паролем и в корпоративный ноутбук, и в Office 365, кто-то должен синхронизировать эти два каталога. Этот «кто-то» — Azure AD Connect.

При установке создаётся сервисный аккаунт MSOL (на Monteverde — AAD_987d7f2f57d2). Он получает права Replicating Directory Changes — фактически может выполнить DCSync (T1003.006), то есть извлечь хеши паролей всех пользователей домена. Представьте сотрудника, у которого есть мастер-ключ от всех шкафчиков в офисе.

Пароль MSOL-аккаунта хранится в зашифрованном виде в локальной базе данных SQL (ADSync). Ключ шифрования — на той же машине. Сейф и ключ от него — в одной комнате.

Предусловия (работает если): — На машине установлен Azure AD Connect (проверяем: Get-Service ADSync или наличие C:\Program Files\Microsoft Azure AD Sync). — Текущий пользователь — член группы Azure Admins или ADSyncAdmins (проверяем: net user mhope /domain). — База ADSync доступна через локальный SQL Server (MSSQL на порту 1433 или LocalDB).

Не работает если: — Azure AD Connect не установлен. — Пользователь не входит в группу с доступом к базе ADSync. — Организация мигрировала на Azure AD Cloud Sync (другая архитектура хранения, пароль не лежит локально). — Microsoft Defender for Identity мониторит обращения к ADSync и генерирует алерт при нестандартных SQL-запросах.

Извлечение пароля из ADSyncConfig

Для расшифровки используется PowerShell-скрипт, основанный на исследовании Adam Chester (xpnsec.com). Скрипт подключается к базе ADSync, извлекает зашифрованные данные и расшифровывает их штатными DLL Azure AD Sync. Ключевой фрагмент (адаптирован под MSSQL-подключение Monteverde):

$client = New-Object System.Data.SqlClient.SqlConnection
$client.ConnectionString = "Server=MONTEVERDE;Database=ADSync;Trusted_Connection=true"
$client.Open()
$cmd = $client.CreateCommand()
$cmd.CommandText = "SELECT keyset_id, instance_id, entropy FROM mms_server_configuration"
$reader = $cmd.ExecuteReader()
$reader.Read()
$key_id = $reader.GetInt32(0)
$instance_id = $reader.GetGuid(1)
$entropy = $reader.GetGuid(2)

Полный скрипт дополнительно запрашивает зашифрованные данные из таблицы mms_management_agent, загружает DLL из каталога Azure AD Sync (например, Microsoft.DirectoryServices.MetadirectoryServicesEx.dll) и расшифровывает данные через DPAPI. Приведённый фрагмент — упрощённая иллюстрация, а не рабочий PoC; полный скрипт см. в оригинальном исследовании Adam Chester (xpnsec.com). На выходе — открытый пароль.

Ожидаемый результат: скрипт выводит administrator и пароль d0m@in4dminyeah!. Финальный шаг — evil-winrm -i 10.10.10.172 -u administrator -p 'd0m@in4dminyeah!'. Полный контроль над доменом MEGABANK.LOCAL. Флаг root.txt — в C:\Users\Administrator\Desktop.

Сравнение подходов к эксплуатации Azure AD Sync

В разных writeup используются разные инструменты. Выбор зависит от того, что доступно на месте:

Детектируемость по вендорам: Windows Defender на Monteverde не блокирует PowerShell-скрипт. Microsoft Defender for Identity генерирует алерт «Suspicious usage of Azure AD Connect credentials». CrowdStrike Falcon фиксирует аномальные PowerShell-команды с обращением к SQL, но реакция зависит от настроенных политик. SentinelOne в режиме Detect может пропустить, в Protect — заблокирует загрузку DLL из нестандартного контекста. Elastic 8.x+ с включённым ETW-TI зафиксирует обращение к ADSync как аномалию PowerShell-процесса. Конкретное поведение зависит от версии и конфигурации каждого продукта.

Минилаб для отработки атаки на Azure AD Connect

Требования к окружению: гипервизор VirtualBox или VMware, минимум 8 ГБ RAM на хосте (рекомендуется 16 ГБ), доступ к интернету для загрузки Azure AD Connect.

• VM 1: Kali Linux (2 ГБ RAM).
• VM 2: Windows Server 2016/2019 с ролью AD DS, настроенный домен (4 ГБ RAM). Azure AD Connect установлен (бесплатная загрузка, потребуется trial-тенант Azure для мастера настройки).

Шаги:

1. Настройте DC с доменом LAB.LOCAL — после этого появится служба AD DS.
2. Установите Azure AD Connect и завершите мастер — в домене появится аккаунт MSOL_* и база ADSync.
3. Создайте тестового пользователя и добавьте его в группу ADSyncAdmins.
4. Выполните PowerShell-скрипт от имени этого пользователя — увидите расшифрованный пароль.
5. Проверьте Event Log (Security и Application): какие события генерирует SQL-запрос к ADSync? Это основа для написания SIEM-правила.

Машина Monteverde на HackTheBox доступна как retired (нужна VIP-подписка) и позволяет пройти всю цепочку без настройки собственного окружения. Если формула «теория на бумаге понятна, но до конца ощущается только когда прогоняешь руками» — про вас, готовый стенд ждёт на HackerLab.pro. Это CTF-платформа экосистемы Codeby с 12 категориями (web, crypto, forensics и другие), нужна регистрация — после неё доступны задачи всех уровней.

Как обнаружить и предотвратить атаку на Azure AD Connect

Для blue team и администраторов — чеклист конкретных действий:

1. Не устанавливайте Azure AD Connect на контроллер домена. Microsoft рекомендует выделенный сервер. На DC аккаунт MSOL и так имеет полный доступ к базе AD — зачем давать ему ещё и локальный SQL под боком?
2. Ограничьте членство в группах ADSyncAdmins и Azure Admins. Только выделенные сервисные аккаунты, никаких пользовательских учёток. Ревизия — ежеквартально.
3. Включите аудит SQL-запросов к базе ADSync. Мониторьте SELECT-запросы к таблицам mms_management_agent и mms_server_configuration. Любой запрос не от процесса синхронизации — тревога.
4. Мониторьте DCSync от MSOL-аккаунта. Если аккаунт AAD_* или MSOL_* выполняет репликацию (событие 4662 с GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes) и 1131f6ae-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All)) вне штатного расписания — инцидент.
5. Закройте анонимные RPC/LDAP-запросы. Параметр RestrictAnonymous = 2 в групповых политиках блокирует первый шаг всей цепочки.
6. Рассмотрите миграцию на Azure AD Cloud Sync (Microsoft Entra Cloud Sync) — другая архитектура, учётные данные не хранятся локально в SQL.

Большинство организаций узнают об этом векторе только после пентеста. Azure AD Connect устанавливается один раз, настраивается за 20 минут и забывается на годы. За это время сервисный аккаунт MSOL накапливает права, достаточные для полной компрометации домена, а его пароль лежит в базе, доступной любому члену группы ADSyncAdmins.

Самое неудобное в гибридной идентификации (Hybrid Identity, T1556.007): локальный AD проверен десятилетиями, облачный Azure AD — тоже, но точка стыковки между ними становится самым слабым звеном. Пароль Domain Admin расшифровывается скриптом из открытого блога 2018 года, и никакой патч эту архитектуру не исправит — только перенос коннектора на изолированный сервер и жёсткий контроль доступа к нему.

Если в вашей инфраструктуре есть Azure AD Connect, проверьте три вещи прямо сейчас: на каком сервере он стоит, кто входит в ADSyncAdmins, и генерирует ли ваш SIEM хоть один алерт при SQL-запросе к базе ADSync. Если хочется выстроить эту логику аудита от нуля — на IB Basics в Codeby Academy разбирают как раз такие сценарии, от первых задач до рабочих навыков в blue team и offensive.