Перейти к содержанию

Проникновение в Active Directory

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

OSINT и фишинг

Два популярных метода для получения начальных кредов в AD - OSINT и фишинг. Далее немного подробнее про OSINT.

OSINT

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

  • Пользователи задающие вопросы на Stack Overflow и подобных сервисах могут указать в вопросе различные конфидецниальные сведения

  • Разработчики использующие GitHub и подобные сервисы, могут также запушить логины/пароли которые зашиты в коде

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

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

NTLM аутентификация

NTLM и NetNTLM

New Technology LAN Manager (NTLM) - набор протоколов безопасности используемый для аутентификации пользователей в AD.

NTLM может быть использован для аутентификации путем использования механизма Вызов-ответ (Challenge-response-based scheme) под названием NetNTLM. Этот механизм часто используется сервисами в сети. Кроме того, такие сервисы могут иметь выход в Интернет: Почтовые сервисы использующие OWA (Outlook Web App) в качестве аутентификационного портала, RDP серверы, VPN интегрированные с AD, различные веб приложения.

NetNTLM, который также часто называют аутентификация NTLM, позволяет приложениям выполнять роль "человека-по-середине" между пользователем и AD.

Брутфорс логинов и password spraying

Рассмотрим ситуацию. Предположим, что с помощью OSINT нам удалось собрать множество аккаунтов пользователей. Кроме того, обнаружено доступное из Интернета веб приложение которое использует NTLM аутентификацию. Можно брутить каждый логин отдельно, однако, скорее всего учётка будет заблокирована в процессе. Можно использовать Password Spaying атаку, при которой для множества учёток будет использоватся один пароль. При такой атаке вероятность блокирования учётки уменьшается, но стоит иметь в виду, что Password Spaying также легко обнаруживается по возросшему количеству неудачных попыток входа большого количества пользователей.

Продолжим выдумывать ситуацию: в организации используется стандартный пароль для первого входа в систему. Пароль этот удалось получить с помощью OSINT. При таких исходных данных, проведение password spraying атаки не составит труда. Сделать это можно как с помощью hydra, так и с помощью самописных реализаций. Пример такой реализации можно найти тут.

LDAP

LDAP bind credentials

В LDAP v3 есть два варианта аутентификации - простой и SASL (Simple Authentication and Security Layer).

Простая аутентификация делится на следующие способы:

  • "Анонимная аутентификация", при которой клиенту предоставляется анонимный статус для LDAP.

  • "Аутентификация без аутентификации" - используется только для целей регистрации, не должна предоставлять доступ клиенту.

  • "Аутентификация по имени или паролю" - предоставляет доступ к серверу на основе предоставленных учетных данных.

При использовании SASL, сервер LDAP передает аутентификационную информацию какому-либо другому механизму аутентификации, как правило - Kerberos. Отправляются такие сообщения в формате LDAP.

Важно отметить, что по умолчанию LDAP передает все эти сообщения в plain text. Нужно добавлять шифрование TLS или подобное, чтобы сохранить передаваемые имена пользователей и пароли в безопасности.

LDAP Pass-back Attacks

Представим ситуацию, что злоумышленнику удалось подключить своё устройство в сеть. В сети нет 802.1x поэтому он без проблем зашел на вебморду сетевого принтера используя стандартный логин/пароль который ленивые админы забыли поменять. Сетевой принтер использует LDAP аутентификацию типа SASL (см. рисунок выше)

Попав на устройство, можно заменить адрес DC на адрес своего устройства. После чего запустить на нём nc -lvp 389 и ждать получения пакетов. Однако, если не поднять на устройстве LDAP сервер, принтер не сможет установить LDAP соединение, а следовательно необходимую информацию - аутентификационные данные принтера - получить не удастся.

В качестве поддельного LDAP сервера будем использовать OpenLDAP:

Установка OpenLDAP и открытие утилиты его конфигурирования
sudo apt-get update && sudo apt-get -y install slapd ldap-utils && sudo systemctl enable slapd

sudo dpkg-reconfigure -p low slapd

Далее:
# 1. Скипаем конфигурацию сервера
# 2. Записывается целевой домен и organization name
# 3. Записывается любой пароль Администратора
# 4. В качестве БД выбирается MDB
# 5. Отказываемся от удаления базы в случае очистки
# 6. Соглашаемся на перемещение файлов старой БД перед созданием новой

Далее, в качестве механизма аутентификации нужно оставить только PLAIN и LOGIN, для этого создаётся новый конфигурационный файл определяющий свойства безопасности SASL аутентификации LDAP:

olcSaslSecProps.ldif
dn: cn=config
replace: olcSaslSecProps
olcSaslSecProps: noanonymous,minssf=0,passcred

# noanonymous - запрещает подключатся анонимно
# minsf - определяет минимальный уровень безопасности. 0 = нет никакой безопасности.

Перечитываем новый конфиг и перезапускаем сервер:

sudo ldapmodify -Y EXTERNAL -H ldapi:// -f ./olcSaslSecProps.ldif && sudo service slapd restart

# Проверяем, что всё работает как нужно:
$ ldapsearch -H ldap:// -x -LLL -s base -b "" supportedSASLMechanisms

dn:
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

Готово! Для просмотра пакетов которые принтер отправляет фальшивому LDAP серверу осталось запустить сниффер, например tcpdump, и в перехваченных пакетах искать аутентификационные сведения:

sudo tcpdump -SX -i breachad tcp port 389

Ретрансляция аутентификации

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

Перехват NetNTLM сведений из LLMNR, NBT-NS, WAPD

В Windows сети проходит множество трафика содержащего в себе NetNTLM челленджи. Примером является трафик протоколов которые используются для локального определения имён без привлечения DNS: Link-Local Multicast Name Resolution - LLMR, NetBIOS Name Service - NBT-NS, Web Proxy Auto-Discovery - WPAD. Все они пытаются достучатся до соседей по широковещательному домену через бродкаст. Обычно, такие запросы отбрасываются, однако некоторое ПО, такое как Responder может перехватывать такие сообщения и отправлять в ответ модифицированные ответы, сообщающие о том, что он и есть тот сервис который нужен запрашивающему.

Следует помнить, что работает он очень шумно

Для запуска достаточно ввести sudo responder -I $if-name и ожидать перехваченных данных.

Далее, хэш отправляется в hascat или скармливается Джону.

Перехват challenge

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

  • Подписывание SMB должно быть или отключено или включено, но не задействовано.

  • Исследуемая учётная запись должна обладать соответствующими привилегиями на сервере. В идеале конечно перехватить учётку с админискими правами для дальнешего закрепления на узле.

Использование Microsoft Deployment Toolkit

В крупных организациях часто используются инструменты для автоматизации развертывания и конфигурирования образов ОС. Неверная конфигурация таких инструментов может привести к проникновению в AD.

MDT и SCCM

Одним из таких инструментов является MDT (Microsoft Deployment Toolkit) который в том числе содержит в себе централизованное хранилище образов различных версий ОС.

Обычно MDT интегрируется с SCCM (Microsoft System Configuration Manager) который используется для централизованного управляения обновлениями различного ПО. Суть их совместного использования заключается в создании преконфигурированных образов для дальнейшей их установке по сети. Останется только воткнуть кабель в новую машину и образ с нужным предустановленным ПО раскатается автоматически.

В качестве примера, рассмотрим способ проникновения в AD с помощью Preboot Execution Environment (PXE) Boot

PXE Boot

Образы PXE boot - те самые образы хранящиеся в MDT и устанавливающиеся по сети. В процессе обращения к DHCP, клиент получает не только IP адрес, но и информацию о MDT сервере, к которому обращается в дальнейшем, для получения нужного образа.

Исходя из изображения выше возможно:

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

  • Использовать password scraping атаку, для восстановления учётных сведений AD в процессе установки

Извлечение данных из PXE Boot образа

Получив сведения о MDT сервере (например из DHCP ответа) можно будет скачать с него имеющиеся файлы .bsd которые содержат информацию об образах для различных архитектур ОС, а также адрес и имя непоспредственно самого образа в формате .wmi . .bsd файлы должны располагатся в /Tmp/ сервера.

Работает MDT через TFTP который не поддерживает листинг файлов в директории.

Получив .bsd файл, распакуем его с помощью Powerpxe

##### Скачиваем образ с MDT сервера с помощью TFTP

C:\Users\dummy\Documents\Z> tftp -i <MDT-IP> GET "\Tmp\x64{35...34}.bcd" conf.bcd

##### Читаем, что там внутри образа

C:\Users\dummy\Documents\Z> powershell -executionpolicy bypass
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.   

PS C:\Users\dummy\Documents\Z> Import-Module .\PowerPXE.ps1
PS C:\Users\dummy\Documents\Z> $BCDFile = "conf.bcd"
PS C:\Users\dummy\Documents\Z> Get-WimFile -bcdFile $BCDFile
>> Parse the BCD file: conf.bcd
>>>> Identify wim file : <PXE Boot Image Location>
<PXE Boot Image Location>

##### Узнав имя wim файла загружаем его с сервера MDT-IP

PS C:\Users\dummy\Documents\Z> tftp -i <MDT-IP> GET "<PXE Boot Image Location>" pxeboot.wim

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

Для извлечения учётных данных из pxeboot.wim снова воспользуемся PowerPXE:

PS C:\Users\dummy\Documents\Z> Get-FindCredentials -WimFile pxeboot.wim
>> Open pxeboot.wim
>>>> Finding Bootstrap.ini
>>>> >>>> DeployRoot = \\DUMMYMDT\MTDBuildLab$
>>>> >>>> UserID = <account>
>>>> >>>> UserDomain = DUMMY
>>>> >>>> UserPassword = <password>

Конфигурационные файлы

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

Как со всем этим бороться?

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

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

  • Пересмотреть необходимость размещения сервисов использующих NTLM и LDAP непосредственно в Интернете. Гораздо безопаснее размещать их во внутренней сети, подключится к которой можно будет через VPN

  • Рассмотреть меры обеспечивающие защиту сети на канальном уровне: решения класса NAC, в частности использование 802.1x и т.п.

  • Использование SMB Singning для невозможности применения атак класса SMB relay

  • Следование принципу наименьших привилегий для уменьшения возможности использования скомпроментированных учёток.

  • Использование инструментов для перебора сведений об объектах AD (к примеру, тот же Sharphound) генерирует множество событий типа LogOn которые исходят из под той учётки под которой запущен инструмент. Отслеживание таких событий может способствовать раннему обнаружению попыток сканирования Administration

  • Можно использовать сигнатурный анализ, на предмет появления специфических бинарников на хостах (SharpHound, AD-RSAT)

  • Мониторить запуск cmd и powershell

Дополнительно можно почитать про "Принципы обеспечения информационной безопасности", в частности раздел про ISO/IEC 19249:2017