Разбираем атаки на Microsoft Active Directory. Техники проникновения и детекта. Ч.2. Заключительная.
Шалом, бегущие в тенях! Привет, случайный подписчик. За последние четыре года ни один Black Hat или DEF CON не обошелся без докладов на тему атак на Microsoft Active Directory. Участники рассказывают о новых векторах и своих изобретениях, но не забывают и о советах, как можно их обнаружить и предотвратить. В этой статье мы продолжаем рассматривать популярные практические способы атак на AD и приводим рекомендации, которые помогут от них защититься. Потихоньку вливаемся, господа.
Поехали:
Стадия 2. Продвижение по AD
Overpass-the-Hash
Реинкарнация Pass-the-Hash. Что атакующий может сделать, если у него есть NTLM-хеш? Он может провести атаку Pass-the-Hash — но на нее уже есть детекты. Поэтому был найден новый вектор — атака Overpass-the-Hash.
Протокол Kerberos был разработан специально для того, чтобы пароли пользователей в том или ином виде не передавались по сети. Для этого на своей машине пользователь хешем своего пароля шифрует запрос на аутентификацию. В ответ Key Distribution Center (специальная служба, которая хостится на контроллере домена) выдает ему билет на получение других билетов — так называемый Ticket-Granting Ticket (TGT). Теперь клиент считается аутентифицированным, и в течение десяти часов он может обращаться за билетами для доступа к другим сервисам. Соответственно, если атакующий сдампил хеш пользователя, который входит в доверенную группу интересующего его сервиса, например ERP-системы или базы данных, атакующий может выпустить пропуск для себя и успешно авторизоваться на этом сервисе.
Как детектить. Если атакующий использует PowerShell-версию mimikatz для этой атаки, то здесь на помощь приходит логирование тела скрипта, потому что «Invoke-Mimikatz» — весьма примечательная строчка.
Или же 4688 — событие запуска процесса с расширенным аудитом командной строки. Даже если бинарь будет переименован, то по командной строке мы обнаружим очень характерную для mimikatz команду.
По трафику Overpass-the-Hash можно детектить на основе аномалии, которая возникает в результате того, что Microsoft рекомендует для текущих доменов использовать для шифрования authentication request AES-256. А mimikatz, когда отправляет данные authentication request, шифрует их с помощью устаревшего RC4.
В трафике наблюдается еще одно отличие из-за особенностей 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.
INFO
В MaxPatrol SIEM с использованием табличных списков, в которых мы логируем все выданные TGT и TGS, нам удалось реализовать такой детект.
Стадия 3. Эксплуатация
После того как задача аутентификации и авторизации на желаемых хостах решена, атакующий может приступить к выполнению задач удаленно.
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
- Сложные и длинные (>25 символов) пароли для сервисных учетных записей. Это не оставит злоумышленнику шанса провести атаку Kerberoasting, так как брутить придется очень долго.
- Логирование PowerShell. Поможет обнаружить использование многих современных инструментов для атак на AD.
- Переезд на Windows 10, Windows Server 2016. Microsoft создала Credential Guard: больше не удастся сдампить из памяти NTLM-хеши и билеты Kerberos.
- Строгое разграничение ролей. Опасно сочетать в одной роли администратора AD, DC, всех серверов и рабочих машин.
- Двойная смена пароля krbtgt (это та самая учетная запись, которой подписываются TGT-билеты). Каждый год. И после ухода администратора AD:
- менять нужно дважды, так как хранится текущий и предыдущий пароль;
- менять каждый год, а также после ухода доменного администратора. Даже если сеть уже скомпрометирована и злоумышленники выпустили Golden Ticket, изменение пароля делает этот Ticket бесполезным. И им снова нужно начинать все сначала.
- Средства защиты с непрерывно обновляющейся экспертной базой знаний. Необходимо для обнаружения реальных актуальных атак.
Стадия 4. Захват домена
DCShadow
24 января 2018 года на конференции Microsoft BlueHat в Израиле Бенджамен Делпи и Венсан ле Ту (Vincent Le Toux) представили новый модуль mimikatz, который реализует атаку DCShadow. Суть атаки в том, что создается поддельный контроллер домена, чтобы изменять и создавать новые объекты в AD через репликацию. Исследователям удалось выделить минимальный набор Kerberos SPN, необходимых для прохождения процесса репликации, — их требуется всего лишь два. Кроме того, они представили специальную функцию, которой можно запускать репликацию контроллеров принудительно. Авторы атаки позиционируют ее как атаку, которая сделает твой SIEM слепым. Так как поддельный контроллер домена не отправляет события в SIEM, это значит, что злоумышленники могут творить темные дела с AD и SIEM об этом не узнает.
Схема атаки: на той системе, с которой производится атака, необходимо добавить два SPN, которые нужны, чтобы другие домен-контроллеры могли аутентифицироваться по Kerberos для репликации. Поскольку согласно спецификации контроллер домена представлен в базе AD объектом класса nTDSDSA, необходимо такой объект создать. И в завершение вызвать репликацию с помощью функции DRSReplicaAdd.
Как детектить. Каким образом DCShadow выглядит в трафике. По трафику мы отчетливо видим добавление нового объекта в схему конфигурации типа домен-контроллер, а затем принудительный запуск репликации.
Хотя авторы атаки и говорят, что SIEM обнаружить ее не поможет, мы нашли способ, как можно дать понять службе ИБ, что в сети подозрительная активность.
Благодаря тому что наша корреляция знает список легитимных домен-контроллеров, она будет срабатывать, когда произойдет репликация с домен-контроллера, не входящего в этот белый список. Соответственно, подразделение ИБ может провести расследование и уже понять, это легитимный домен-контроллер, который добавила ИТ-служба, или атака DCShadow.
Заключение
Пример DCShadow показывает, что появляются новые векторы атак на предприятия. В этом океане ИБ-событий очень важно оставаться на гребне волны: смотреть дальше и двигаться быстро. Так что, киберсталкеры, кто-то из вас нам ныл в боте, мол: "Практики не хватает. Хотим исчо" и прочую лабуду. Хотели - ебашьте. Нам не жалко.