Комментарии 7
chainsaw - там уже есть соответствующее правило.
Chainsaw является действительно великолепным инструментом, позволяя найти нужную информацию в одном месте, что несомненно является полезным с точки зрения быстрой реализации соответствующих правил в системах. К сожалению только наличие готового правила зачастую не формирует понимания у команды Blue Team: как происходит атака, каким образом формируются события, в каком количестве и какие способы обхода возможны. Именно это мы попытались донести в своих статьях по DCSync
Ни один зрелый нарушитель не будет проводить DCSync от имени пользовательской учетки, поэтому отбрасывать машинные УЗ – такое себе. Детектирование на основе фильтрации трафика / мониторинга IP-адреса источника DRSGetNCChanges – это да, норм тема.
А разве детект по IP не обходится? Например в случаях read only DC находящегося в другой сети ну или если правило поставили на подсетку из за DHCP. В первой части описано что не обязательно мониторить вызов DRSGetNCChanges по IP, проще и надёжнее смотреть на сам факт вызова DRSReplicaSync и DRSGetNCChanges.
У коллег в статье про RPC и способы его мониторинга рассмотрен RPC-Firewall.
Также добавлю, что данный инструмент позволяет блокировать RPC запросы с конкретными UUID (мы можем указать соответствующие MS-DRSR), но нужна сегментация сети, чтобы не блокировать репликацию между DC. И подмечу, что при блокировке атаки RPC-firewall событий 4662 не будет.
DCSync: особенности выполнения атаки и возможные варианты детектирования, Часть 2