Извлечение учетных данных из реестра Windows: анализ новой техники
Недавно в сети появился инструмент, который позволяет извлекать учетные данные из реестра Windows без взаимодействия с файловой системой — непосредственно из памяти. Детектировать такие атаки средствами штатного аудита очень непросто. В статье сравниваем механизм работы новой утилиты со старыми средствами, рассказываем о способе обнаружения ее активности и разных подходах к защите.
Утилита go-secdump позволяет удаленно извлекать NT-хеши из куста реестра SAM (security account manager) и секреты LSA (local security authority) непосредственно из памяти и без какого-либо удаленного агента. Она имеет заметные отличия от предыдущих аналогов с точки зрения своего поведения, что влияет на возможность обнаружения активности данной утилиты. Один из пользователей комьюнити создал Pull Request на добавление функциональности инструмента для скрипта secretsdump.py из Impacket, что сильно скажется на частоте его использования злоумышленниками в «дикой природе», если он в итоге будет принят.
Предыдущие способы получения NT-хешей паролей локальных пользователей тоже так или иначе основывались на чтении из базы данных SAM. Поскольку получить доступ к файлу SAM в файловой системе работающей ОС невозможно, большинство способов реализованы на чтении ключей SAM, SYSTEM и SECURITY из ветки реестра HKLM.
Злоумышленники могут получать NT-хеши двумя способами: локально и удаленно. Локальное извлечение хешей может осуществляться с помощью встроенной утилиты reg.exe:
reg save HKLM\sam sam_file
reg save HKLM\system system_file
reg save HKLM\security security_file
Далее, используя скрипт secretsdump.py из пакета Impacket, командой secretsdump.py -sam sam_file -system system_file -security security_file LOCAL извлекают:
- NT-хеши паролей локальных пользователей;
- LSA-секреты;
- кеш паролей доменных пользователей в формате DCC-хешей.
Удаленное извлечение чаще осуществляется такими утилитами, как CrackMapExec, NetExec и secretsdump.py. Данные утилиты также используют описанные выше ветки реестра.
Детектирование локального извлечения данных обычно строится на событии создания процесса (Event ID 4688) — запуске reg.exe с передачей параметров, содержащих строки system/sam/security.
Обнаружение удаленного извлечения хешей осуществляется с использованием следующих событий:
- Аутентификация — событие безопасности с кодом 4624 с типом входа 3 (рис. 1).
Рис. 1. Скриншот события безопасности с кодом 4624
- Вызов удаленного реестра — событие безопасности «Объект общей сетевой папки был проверен на предмет возможности предоставления клиенту желаемого доступа» с кодом 5145 с Relative Target Name —
winreg(рис. 2). Для регистрации данного события необходимо дополнительно настроить аудит, что не всегда используется из-за генерации большого количества событий.
Рис. 2. Скриншот события безопасности с кодом 5145
- Запрос дескриптора объекта — событие безопасности с кодом 4656 (рис. 3). Для регистрации данного события необходимо настроить политику аудита Object Access — Registry и SACL для веток реестра
HKLM\SAMиHKLM\SYSTEM\CurrentControlSet\Control\Lsa.
Рис. 3. Скриншот события безопасности с кодом 4656
- Сохранение содержимого ключей в каталоге Windows с произвольным именем и чтение данного файла через сетевую шару
$ADMIN. Событие безопасности «Объект общей сетевой папки был проверен на предмет возможности предоставления клиенту желаемого доступа» с кодом 5145 (рис. 4).
Рис. 4. Скриншот события безопасности с кодом 5145
Описанные выше способы работают с файловой системой для временного хранения и получения содержимого выгруженных ключей реестра. Инструмент go-secdump использует привилегии WriteDACL для временного доступа к кустам реестра и выгрузки их содержимого без применения временных файлов. Событие 5145 с чтением и удалением TMP-файла зарегистрировано не будет.
Логирование события 4656 нужно настраивать отдельно, но объекты, для которых надо настраивать такой аудит, часто используются компонентами ОС. Поток подобных событий будет высок даже с одного хоста, а если говорить про инфраструктуру в тысячу или десятки тысяч конечных точек, то количество данных событий может влиять на время доступности полезных для форензики событий.
Для мониторинга действий атакующих по изменению веток реестра ACL (access control list) мы используем BI.ZONE EDR, который позволяет генерировать события при изменении/добавлении/удалении объектов ACE (access control entries) для интересующих нас веток реестра, в данном случае — SAM/SECURITY.
Настройка аудита добавления ACE в ACL — ветки реестра SAM позволяет обнаружить атаку c использованием утилиты go-secdump, при которой генерируется только одно событие. Как выглядит алерт при срабатывании правила корреляции как раз на основе данного события, показано на рис. 5.
Рис. 5. Обнаружение атаки с применением go-secdump на основе одного события
Настроив логирование сохранения содержимого ветки реестра SAM, мы имеем возможность обнаружить использование других инструментов, действующих похожим образом, также на основе единичного события.
Злоумышленники продолжают совершенствовать методы атак и создают новые инструменты для незаметного проникновения в инфраструктуру и слива данных. Для защиты от подобных угроз важно осуществлять непрерывный мониторинг конечных точек и уметь быстро нейтрализовывать их. Одним из таких решений является BI.ZONE EDR, помогающий обнаруживать сложные угрозы и проводить активное реагирование для того, чтобы не допустить развития атаки.