Погружение в AD: разбираем продвинутые атаки на Microsoft Active Directory и способы их детекта

Изображение: Pexels

За последние четыре года ни один Black Hat или DEF CON не обошелся без докладов на тему атак на Microsoft Active Directory. Участники рассказывают о новых векторах и своих изобретениях, но не забывают и о советах, как можно их обнаружить и предотвратить. В этой статье мы рассмотрим популярные способы атак на AD и приведем рекомендации, которые помогут от них защититься.

Шесть атак на AD, которые нельзя не заметить

Многие производители программного обеспечения для мониторинга ИБ уже поддерживают в своих продуктах разнообразные техники атак злоумышленников. Рассмотрим некоторые из них.

Pass-the-Hash

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

Mimikatz

Для удобной эксплуатации Pass-the-Hash французский исследователь Бенжамен Делпи (Benjamin Delpy) в 2014 году разработал утилиту mimikatz. Она позволяет дампить из памяти clear-text-пароли и NTLM-хеши.

Brute Force

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

net user /domain

Откуда взять словарик имен пользователей для того, чтобы провести Brute Force? Любому члену домена доступно выполнение команды net user /domain, которая возвращает полный список имён пользователей из AD.

Kerberoasting

Если же домене в качестве протокола аутентификации используется Kerberos, то злоумышленник может прибегнуть к атаке Kerberoasting. Любой аутентифицированный в домене пользователь может запросить Kerberos-билет для доступа к сервису (Ticket Granting Service). TGS зашифрован хешем пароля учетной записи, от которой запущен целевой сервис. Злоумышленник, получив таким образом TGS, теперь может расшифровать его, подбирая пароль и не боясь блокировки, поскольку делает это на оффлайн. При успешном исходе, он получает пароль от ассоциированной с сервисом учетной записи, которая зачастую является привилегированной.

PsExec

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

Семь заклинаний атакующих для захвата Active Directory

Сейчас мы переходим к семи заклинаниям, благодаря которым атакующие могут получить полный контроль над Active Directory. Разделим их на четыре стадии:

1. Разведка.
2. Продвижение по AD.
3. Эксплуатация.
4. Захват домена.

На схеме можно увидеть все четыре, а также техники, которые на них при- меняются. Рассмотрим каждую детально.

Стадия 1. Разведка

Начнем со стадии разведки.

PowerView

Этот инструмент входит в популярный PowerShell-фреймворк для проведения тестирований на проникновение — PowerSploit. Также на него опирается инструмент BloodHound, строящий граф связей объектов внутри AD.

Графовое представление связей объектов Active Directory

Bloodhound сразу предоставляет такие возможности:

• найти аккаунты всех доменных администраторов;
• найти хосты, на которых залогинены доменные администраторы;
• построить кратчайший путь от хоста атакующего до хоста с сессией доменного админа.

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

PowerView отличает от встроенных утилит для получения данных об объектах AD (например, net.exe) то, что он работает по протоколу LDAP, а не SAMR. Для обнаружения данной активности подойдет событие 1644 с контроллера домена. Логирование данного события включается добавлением соответствующего значения в реестре:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostic\15 Field Engineering = 5

Включение логирования LDAP Event 1644

Событие 1644 с параметрами LDAP-запроса

Стоит обратить внимание на то, что таких событий может быть довольно много, и хорошей альтернативой детекту по событию является детект по трафику, поскольку LDAP – это clear-text протокол, соответственно, все запросы в трафике отлично видны.

LDAP SearchRequest (по клику картинка откроется в полном размере)

Еще одна важная особенность этого фреймворка — он написан на чистом PowerShell и не имеет зависимостей. И здесь для детектирования нам поможет появившаяся в PowerShell версии 5 возможность расширенного аудита. Событие 4104 показывает тело скрипта, в котором мы можем поискать характерные для PowerView названия функций.

SPN Scan

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

Обычно это решается сканированием портов утилитой nmap. Но теперь эту информацию можно получить и из AD – она там уже хранится. Посмотреть на результат выполнения такого запроса можно так: возвращаются так называемые SPN (Service Principal Names). SPN состоит из serviceclass, он уникален для каждого типа сервиса, затем идет hostname в форме FQDN и для некоторых сервисов – port.

Примеры spn. Полный список Service Principal Names

Для того, чтобы обнаруживать SPN Scan на помощь также приходит аудит событий LDAP.
Важно отметить, что SPN scan имеет явное преимущество перед сканом nmap: он менее шумный. При использовании nmap вам нужно подключаться к каждому узлу и отправлять пакеты на тот диапазон портов, который вы указали. А для получения списка SPN, нужно отправить всего один запрос.

Remote Sessions Enumeration

Важной задачей перед атакующим на этапе lateral movement становится определение, какой пользователь на какой машине залогинен. Либо у него уже есть учетные данные пользователя (хеш или Kerberos-тикет), и он ищет хосты, куда можно беспрепятственно залогиниться. Либо он в поисках хоста, где есть живая сессия доменного администратора.

Тогда срабатывает сценарий: охота –> компрометация любого хоста –> залив Mimikatz – > профит.

Для обнаружения данной техники можно использовать 2 события. 4624 – это успешный логон на удаленной системе с логон тайпом 3, а также события доступа к сетевой шаре IPC$, и нюанс – название пайпа – srvsvc. Почему пайп так называется, можно понять из трафика.

По клику картинку откроется в полном размере

В левой части в красных рамках обращения к SMB, затем обращения к пайпу – srvsvc. Вот этот пайп позволяет взаимодействовать по специальному протоколу Server Service Remote Protocol. Конечным хостам он позволяет получать от него различную административную информацию, в т.ч. среди запросов есть такой, который называется NetSessEnum. В результате этого запроса возвращается полный список залогиненных на удаленной системе пользователей с IP и именами пользователей.

В MaxPatrol SIEM мы сделали детект на основе связки этих двух событий с учётом srvsvc. И аналогичный детект по трафику в PT Network Attack Discovery.

Стадия 2. Продвижение по AD

Overpass-the-Hash

Реинкарнация Pass-the-Hash. Продолжая тему lateral movement. Что атакующий может сделать, если у него есть NTLM-хеш? Он может провести атаку Pass-the-Hash – но на нее уже есть детекты. Поэтому был найден новый вектор — атака Overpass-the-Hash.

Протокол Kerberos был разработан специально для того, чтобы пароли пользователей в том или ином виде не передавались по сети. Для этого на своей машине пользователь хешом своего пароля шифрует запрос на аутентификацию. В ответ Key Distribution Center (специальная служба, которая хостится на контроллере домена) выдает ему билет на получение других билетов. Так называемый Ticket-Granting Ticket (TGT). Теперь клиент считается аутентифицированным, и в течение 10 часов он может обращаться за билетами для доступа к другим сервисам. Соответственно, если атакующий сдампил хеш пользователя, который входит в доверенную группу интересующего его сервиса, например, ERP-системы или базы данных, атакующий может выпустить пропуск для себя и успешно авторизоваться на интересующем его сервисе.

Как детектить

Если атакующий использует PowerShell версию mimikatz для этой атаки, то здесь на помощь приходит логирование тела скрипта. Потому что «Invoke-Mimikatz» весьма характерная строчка.

Или же 4688 – событие запуска процесса с расширенным аудитом командной строки. Даже если бинарь будет переименован, то по командной строке мы обнаружим очень характерную для mimikatz команду.

По трафику Overpass-the-Hash можно детектить на основе аномалии, которая возникает в результате того, что Microsoft рекомендует для текущих доменов использовать для шифрования authentication request AES256. А mimikatz когда отправляет данные authentication request, он шифрует данные с помощью устаревшего ARCFOUR.

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

Golden Ticket

Что атакующий может сделать, если у него есть хеш пароля специальной учетной записи, которая называется krbtgt? Ранее мы рассматривали случай, когда пользователь мог быть непривилегированным. Сейчас мы рассматриваем пользователя, хешем пароля которого подписываются абсолютно все билеты на получение других билетов (TGT). Соответственно, злоумышленник больше не обращается к Key Distribution Center, он сам у себя генерирует этот билет, поскольку Golden Ticket, по сути, и есть TGT. Затем он уже может отправлять запросы на аутентификацию на любом сервисе внутри AD, причем на неограниченное время. В итоге он беспрепятственно обращается к этому ресурсу — Golden Ticket неспроста называется золотым.

Как детектить по событиям

Существует событие 4768, говорящее о том, что был выдан TGT, и событие 4769, говорящее о том, что был выдан сер- висный билет, который необходим для аутентификации на каком-то сервисе внутри AD.

Здесь мы можем играть на разнице: т.к. при атаке Golden Ticket не запрашивает TGT у контроллера домена (он генерирует его самостоятельно), а TGS ему запрашивать необходимо, то если мы обнаруживаем разницу в полученных TGT и TGS, то можем предположить, что происходит атака Golden Ticket.

В MaxPatrol SIEM с использованием табличных списков, в который мы логируем все выданные TGT и TGS, нам удалось реализовать такой детект.

WMI Remote Execution

После того, как задача аутентификации и авторизации на желаемым хостах решена, атакующий может приступить к выполнению задач удаленно. WMI как встроенный и предназначенный для этого механизм подходит отлично. Последние несколько лет “living off the land” (пер. жить с земли) означает пользоваться встроенными в Windows механизмами в тренде. В первую очередь потому, что позволяет маскироваться под легитимную активность.

На скриншоте использование встроенной утилиты wmic. Ей указывается адрес хоста, к которому нужно подключиться, учетные данные, оператор process call create и команда, которую необходимо выполнить на удаленном хосте.

Как детектить

По связке событий удаленного логона 4624 (обрати вни-
мание на Logon ID) и событию 4688, говорящему о запуске процесса с command line. 4688 — можно увидеть, что родитель запускаемого процесса — WmiPrvSE.exe, специальный сервисный процесс WMI, который используется для удаленного администрирования. Видна команда, которую мы отправляли net user /add, и Logon ID совпадает с событием 4624. Соответственно, мы можем совершенно точно сказать, с какого хоста запущена данная команда.

Детект по трафику

Здесь мы явно видим характерные слова Win32 process create, а также command line, которая отправляется на запуск. На скриншоте недавно встреченная нами малварь, которая распространялась в виртуальных сетях по принципу, схожему с WannaCry, только вместо шифрования она устанавливала майнер. Малварь несла с собой mimikatz и EthernalBlue, она дампила учетки, с их помощью логинилась на все те хосты, до которых могла дотянуться по сети. С помощью WMI она запускала на них PowerShell, скачивала PowerShell payload, который опять же содержал в себе mimikatz, EthernalBlue и майнер. Таким образом получалась цепная реакция.

Рекомендации к стадиям 1-3

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

2. Логирование PowerShell. Поможет обнаружить использование многих современных инструментов для атак на AD

3. Переезд на Windows 10, Windows Server 2016. Microsoft создал Credential Guard: больше не удастся сдампить из памяти NTLM-хеши и билеты Kerberos

4. Строгое разграничение ролей. Опасно сочетать в одной роли администратора AD, DC, всех серверов и рабочих машин

5. Двойная смена пароля krbtgt (эта та самая учетная запись, которой подписываются TGT билеты). Каждый год. И после ухода AD администратора AD:

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

6. Средства защиты с непрерывно обновляющейся экспертной базой знаний. Необходимо для обнаружения реальных актуальных атак.

Стадия 4. Захват домена

DCShadow

24 января 2018 года на конференции Microsoft BlueHat в Израиле Benjamin Delpy и Vincent Le Toux представили новый модуль mimikatz, которая реализует атаку DCShadow. Суть атаки в том, что создается поддельный контроллер домена, чтобы изменять и создавать новые объекты в AD через репликацию. Исследователям удалось выделить минимальный набор SPN Kerberos, необходимых для прохождения процесса репликации, — их требуется всего лишь 2. Кроме того, они представили специальную функцию, которую можно запускать репликацию контроллеров принудительно. Авторы атаки позиционируют ее как атаку, которая сделает ваш SIEM слепым. Т.к. поддельный контроллер домена не отправляет события в SIEM, а это значит, что злоумышленники могут делать различные темные дела с AD и SIEM об этом не узнает.

Схема атаки

На той системе, с которой производится атака, необходимо добавить 2 SPN, которые нужны, чтобы другие домен-контроллеры могли аутентифицироваться по kerberos для репликации. Т.к. согласно спецификации контроллер домена представлен в базе AD объектом класса nTDSDSA, необходимо такой объект создать. И в завершении вызвать репликацию с помощью функции DRSReplicaAdd.

Как детектить

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

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

Заключение

Пример DCShadow показывает, что появляются новые векторы атак на enterprise. В этом океане ИБ событий очень важно оставаться на гребне волны: смотреть дальше и двигаться быстро. Каждый день мы в PT Expert Security Center исследуем новые угрозы и разрабатываем для них способы и инструменты обнаружения. И готовы делиться этой информацией и дальше.

Автор: Антон Тюрин, руководитель Attack Detection Team, Positive Technologies

Автор: ptsecurity

Источник