Привет, Хабр! В предыдущей статье мы разобрали основы и механизмы работы атаки DCSync, а также рассмотрели несколько наиболее популярных утилит для ее реализации: mimikatz, secretsdump, DSInternals и существующие между ними отличия. В результате мы обнаружили, что у всех утилит прослеживается один и тот же принцип проведения атаки и присутствует одинаковый фактор для ее выявления – DRSReplicaSync.

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

Анализ событий RPC

Ранее, при разборе кодовой базы утилит мы увидели, что при репликации данных используются вызовы RPC функций. Вызов RPC функций можно отследить с помощью технологии Event Tracing for Windows (ETW) и её провайдера Microsoft-Windows-RPC.
RPC функции однозначно идентифицируются по номеру интерфейса, его UUID, и номеру операции - opnum / procmon. При этом номер интерфейса распознает группу связанных удаленных функций. Функциям DRSUAPI соответствует идентификатор UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2.

Как видно из полученных логов (рисунок 22), на первом этапе происходит подключение клиента по порту 135 к протоколу удаленного вызова процедур (RPC) Microsoft Endpoint Mapper (EPM), которому соответствует UUID e1af8308-5d1f-11c9-91a4-08002b14a0fa.
EPM – это служба, сопоставляющая требуемому приложению динамический порт RPC.

Служба EPM возвращает клиенту номер динамического RPC порта, в нашем случае 49666, так как на нем работает DRSUAPI. После чего происходит подключение к нему и следующим этапом идет вызов RPC функций DRSUAPI . Ниже на рисунках 23 и 24 показаны примеры этих событий, отражающих вызов RPC функций.

Остальные логи выглядят идентично, только меняется ProcNum / OpNum в зависимости от вызываемой функции (метода), а общий порядок совпадает с представленным в трафике для каждой конкретной утилиты. В качестве примера представлен трафик mimikatz, под спойлером, из первой части статьи.

Трафик при DCSync

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

Возможно данные проблемы можно решить с помощью событий из журнала Windows Security, поэтому предлагаю перейти к его анализу и посмотреть, какие логи можно получить при проведении атаки.

Анализ Windows Security

Для всех рассмотренных нами утилит на стороне контроллера домена формируются идентичные события в журналах Windows. Так, например, на контроллере домена фиксируется событие 4662. Оно формируется, когда над объектом была выполнена какая-либо операция.

В событии 4662 нас интересуют такие поля, как Subject Account Name (SubjectUserName), AccessMask и Properties. В легитимном случае Subject Account Name должно содержать имя учетной записи контроллера домена или NT AUTHORITY/SYSTEM. Ниже приведен пример 4662 при легитимной репликации между контроллерами домена. Стоит отметить, что формирования данного события необходимо дополнительно настраивать SACL для группы Domain Controllers, об этом будет сказано далее.

AccessMask должна принимать 0x100 (Control Access): данное значение отражает, когда субъекту (пользователю, учетной записи) разрешается выполнение операции (репликации) над объектом (domainDNS). Операция репликации контролируется расширенным правом доступа, которое идентифицируется с помощью GUID. Их GUID были представлены в разделе "Права доступа для выполнения репликации".

Как мы видим поле Properties состоит из двух частей:

• Маска доступа (%7688 - Control Access);

• Тип доступа в GUID формате, связанный с репликацией, и класс объекта AD, представленный в виде GUID {19195a5b-6da0-11d0-afd3-00c04fd930c9}.

Отличным признаком между тремя событиями ниже является поле Properties, которое разные GUID'ы, отражающие соответствующие права доступа.

Если субъект не обладает требуемыми расширенными правами, то при попытке проведения атаки событие 4662 не регистрируется в журнале событий Windows Security.

SACL для формирования события 4662

Событие 4662 формируется после вызова функции DsGetNCChanges из-за выставленного SACL. Посмотреть и выставить SACL можно в оснастке там же, где и предоставляются права доступа. Также дополнительно нужно перейти на вкладку Advanced. На рисунке 30 представлен SACL по умолчанию.

Дополнительно для получения информации об источнике атаки можно использовать событие 4624 (An account was successfully logged on) или 5156 (The Windows Filtering Platform has permitted a connection).

Примеры событий 4624 и 5156

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

Разобравшись в механизмах проведения атаки, а также собрав информацию по работе утилит, перейдем к самому главному – к подготовке возможного детекта.

Детектирование атаки

Далее мы рассмотрим два варианта детектирования: на основе трафика и на основании событий Windows.

Детектирование на основе трафика

Конечно же атаку DCSync легче задетектировать, если мониторить сетевой трафик и вызов RPC функций. Для детекта нам нужно фиксировать информацию о наличии сразу двух функций DRSReplicaSync и DRSGetNCChanges. Если процедура репликации начинается с функции DRSReplicaSync, то данная ситуация с большей долей вероятности будет выглядеть как легитимная, в противном случае вызова функции DRSGetNCChanges без DRSReplicaSync будет говорить о проведении атаки.

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

Обнаружение атаки DCSync на сетевом уровне путем идентификации трафика DCE/RPC, включающий вызовы интерфейса RPC DRSUAPI, осуществляется обычно с помощью IDS/IPS решений. Данный способ является наиболее простым для детектирования этого типа атак.

Детект на основе Security журнала Windows

Как уже было сказано, для возможного варианта детекта можно использовать событие 4662. Ниже мы видим разработанное псевдо-правило:

(
	EventCode=4662 &&
	Access_Mask=0x100 &&
	Account_Name!="*$" &&
	Object_Type="%{19195a5b-6da0-11d0-afd3-00c04fd930c9}" &&
	(
		# Replicating Directory Changes
		Properties="*{1131f6aa-9c07–11d1-f79f-00c04fc2dcd2}*" ||
		# Replicating Directory Changes All
		Properties="*{1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}*" ||
		# Replicating Directory Changes In Filtered Set (Optional)
		Properties="*{89e95b76-444d-4c62-991a-0facbeda640c}*" ||
	) 
)

В данном правиле предлагается отслеживать события 4662, у которых AccessMask равна 0x100 (Control Access) в комбинации с расширенными правами доступа на проведение репликации: Replicating Directory Changes, Replicating Directory Changes All и Replicating Directory Changes In Filtered Set. Для снижения ложно-положительных сработок при включенном SACL для учетных записей устройств, рекомендуется отбрасывать события, где в качестве субъекта используется учетная запись компьютера, то есть оканчивающаяся на знак $.

Для получения дополнительной информации по атаке можно использовать события 4624 (An account was successfully logged on) или 5156 (The Windows Filtering Platform has permitted a connection). На мой взгляд, удобнее использовать 4624, так как можно провести корреляцию по полю Logon ID с событием 4662.

Не обошлось и без ложки дегтя: cобытий 4662 может быть очень много, поскольку они генерируется при любых попытках доступа к объектам, для которых был настроен SACL. Дополнительно под данное событие попадают обращения к пространству имен WMI и MicrosoftVolumeEncryption (BitLocker). Многие процессы скрыто используют WMI. Поэтому их аудит по умолчанию отключен со стороны Microsoft.

У данного варианта детектирования DCSync на основе Security журнала, безусловно, есть свои минусы:

• детектирование постфактум;

• большое количество событий на КД, что создает сложности в хранении и обработке логов.

Заключение

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

Надеюсь данная статья оказалась для вас полезной! Если у вас появились вопросы, пишите в комментариях!

Автор: Кожушок Диана (@wildresearcher), аналитик-исследователь киберугроз в компании R-Vision