DCSync часто называют одной из самых неприятных техник в атаках на Active Directory. Она не требует сброса дампов памяти на контроллере домена и не выглядит как классическое «вытащили пароли из LSASS». Вместо этого злоумышленник делает вид, что он тоже контроллер домена, и «просит» у настоящего контроллера отдать данные репликации. В результате можно получить NTLM-хэши, Kerberos-ключи и другие секреты, которые открывают путь к компрометации всего домена.
Коварство DCSync в том, что это злоупотребление легитимным механизмом. Репликация в Active Directory жизненно необходима, иначе несколько контроллеров домена не смогли бы синхронизировать учётные записи, группы и политики. Техника DCSync просто использует тот же протокол, что применяют контроллеры между собой, и при наличии нужных прав запрашивает «репликацию секретов» с удалённой машины.
В MITRE ATT&CK DCSync описан как субтехника OS Credential Dumping и имеет идентификатор T1003.006. Это полезная отправная точка, чтобы понимать место DCSync в цепочках атак и типовые сценарии использования. Удобно держать под рукой карточку техники на сайте MITRE ATT&CK.
Ниже разбирается, для чего злоумышленникам нужен DCSync, как он работает на уровне прав и протоколов, а также что именно стоит делать для защиты и обнаружения.
Зачем вообще существует DCSync и почему он так опасен
Active Directory обычно развёрнут не на одном сервере. В домене часто несколько контроллеров домена, и все изменения должны быстро разъезжаться по инфраструктуре. Для этого существует репликация через Directory Replication Service Remote Protocol, он же MS-DRSR или DRSUAPI. Про механизм и упоминание MS-DRSR в контексте DCSync пишут многие вендоры и исследователи, например NCC Group.
Опасность начинается там, где репликация включает не только «обычные» атрибуты, но и чувствительные данные. В AD есть секреты, которые нельзя раздавать кому попало, но контроллерам домена они нужны. Поэтому права на репликацию строго ограничены, и по умолчанию их имеют только привилегированные субъекты домена.
DCSync превращает эти права в универсальный «пылесос» для учётных данных домена. Получив хэши и ключи, атакующий может перейти к pass-the-hash, golden ticket или тихому закреплению через замену паролей и создание «вечных» бэкдоров в AD. Особенно неприятна кража учётки krbtgt, поскольку она лежит в основе Kerberos-доверия домена.
Отдельная боль в том, что DCSync нередко применяется уже после того, как злоумышленник получил не самую очевидную, но достаточную делегацию прав. Не всегда это «Domain Admin». Иногда это сервисная учётка, которой когда-то «временно» выдали права для синхронизации, миграции или интеграции, а временно оказалось навсегда.
Как работает атака DCSync на уровне протокола и прав
В техническом смысле DCSync имитирует поведение контроллера домена и инициирует запросы репликации к настоящему DC. На практике часто упоминают вызовы семейства GetNCChanges, поскольку именно через них можно запросить данные нужных разделов каталога. Удобное популярное объяснение того, что DCSync «притворяется DC и запрашивает репликацию», есть, например, у ADSecurity.
Чтобы запрос на репликацию был успешным, у субъекта должны быть соответствующие расширенные права в домене. Ключевые права обычно перечисляют так: Replicating Directory Changes и Replicating Directory Changes All. В схемных названиях AD это DS-Replication-Get-Changes и DS-Replication-Get-Changes-All. Описание прав можно посмотреть в документации Microsoft по объектам схемы, например для DS-Replication-Get-Changes и DS-Replication-Get-Changes-All.
Если говорить проще, то это «пропуск» на чтение репликационных изменений. Для извлечения именно секретов и хэш-материала обычно требуется набор прав более высокого уровня, поэтому в реальных расследованиях важно проверять делегирование не только в группах админов, но и на уровне ACL домена.
Инструментально DCSync чаще всего ассоциируют с Mimikatz, командой lsadump::dcsync. Она отправляет запросы репликации и получает данные без необходимости выполнять код на самом контроллере домена. Практическое описание того, как это выглядит с точки зрения злоумышленника, есть у разных источников, например у The Hacker Recipes и в разборе у Netwrix.
Главный вывод здесь простой: DCSync это не «магия», а проверка прав плюс легитимный протокол. Поэтому защита должна начинаться не с «запретить протокол», а с контроля того, кому вообще позволено реплицировать чувствительные данные.
Как DCSync используют в атаках, где он появляется в цепочке и какие есть признаки
DCSync редко бывает самым первым шагом. Обычно до него злоумышленник уже получил доступ к доменной учётной записи и продвинулся по привилегиям. Дальше DCSync становится способом резко ускорить атаку. Вместо того чтобы долго охотиться за паролями, можно одним движением получить хэши ключевых учёток и переключиться на более надёжные техники аутентификации по хэшам или Kerberos-тикетам.
Типовой сценарий выглядит так: сначала компрометируется рабочая станция или сервер. Затем атакующий вытаскивает учётные данные, двигается латерально и находит учётку, у которой есть права репликации. Иногда такие права у сервисов синхронизации или у «технических» групп, созданных для миграций. После этого выполняется DCSync к одному из DC и запрашиваются секреты нужных пользователей. Частая цель — это krbtgt, Administrator и привилегированные сервисные учётки.
По логам это может выглядеть как необычные запросы репликации от узла, который не является контроллером домена. Это важная мысль для детекта: репликация в AD нормальна, но нормальна она между DC. Когда «реплицировать» внезапно начинает обычный сервер, это повод насторожиться. Платформы класса Microsoft Defender for Identity умеют подсвечивать такие истории. У Microsoft есть обучающие материалы, где прямо демонстрируется сценарий подозрения на DCSync и расследование. Пример такого лабораторного упражнения доступен здесь Microsoft Defender for Identity lab.
Ещё один момент, который часто упускают: DCSync может выполняться точечно. Атакующему не обязательно «качать весь домен». Можно запросить только нужный объект или несколько объектов, чтобы уменьшить шум и вероятность обнаружения. Поэтому детект, который срабатывает лишь на массовые выгрузки, может пропустить аккуратную атаку.
Наконец, DCSync удобно использовать для закрепления. Получив нужные ключи, злоумышленник может построить устойчивый доступ, который переживёт смену пароля у обычных пользователей. Поэтому реагирование на DCSync всегда должно рассматриваться как инцидент уровня домена, а не как «ещё одна странная активность».
Как защититься от DCSync и как его обнаруживать
Самая эффективная защита — это минимизация прав репликации. Нужно знать, кто в домене имеет Replicating Directory Changes и Replicating Directory Changes All, и почему. Дальше следует жёсткая логика: если права не нужны, их убирают. Если нужны, их изолируют и контролируют. Microsoft отдельно описывает, как выдавать права Replicating Directory Changes для конкретных сценариев, и это полезно как ориентир, какие настройки вообще затрагиваются. Пример статьи Microsoft есть здесь Microsoft Learn.
Практический чеклист по защите обычно включает несколько слоёв. Первый слой — это аудит ACL на уровне домена и контейнеров конфигурации. Нужна регулярная проверка делегированных прав, включая вложенные группы, потому что «непрямая» выдача прав встречается чаще, чем хотелось бы. Полезно также ограничивать, какие сервисные учётки вообще могут логиниться интерактивно и с каких хостов.
Второй слой — это архитектура привилегий. Разделение админских учёток, принцип наименьших привилегий, отдельные админ-станции, запрет на использование привилегированных учёток в повседневных задачах. Да, это звучит скучно. Зато это ровно то, что уменьшает шанс, что права репликации окажутся у атакующего «по пути».
Третий слой — это детект и реагирование. Нужны правила мониторинга на аномальную репликацию, особенно от не-DC хостов, а также корреляция событий с сетевой активностью к контроллерам домена по RPC. Важно иметь готовый план реагирования. Если подозрение на DCSync подтверждается, обычно приходится рассматривать сброс секретов домена, включая смену пароля krbtgt по процедуре, пересмотр всех привилегий и проверку компрометации контроллеров домена.
Четвёртый слой — это устойчивость к «наследию». В реальных доменах живут старые сервисы, коннекторы, синхронизации, и у каждого есть своя легенда о том, почему ему «очень надо» реплицировать. Хорошая практика — это инвентаризация таких зависимостей и постепенная замена их на более безопасные подходы. А ещё полезно периодически задавать неудобный вопрос: что сломается, если прямо сейчас отобрать эти права.
Заключение
DCSync пугает не экзотикой, а простотой. При наличии нужных прав злоумышленник может вытащить из Active Directory самый ценный материал, не трогая контроллер домена руками в привычном смысле. Поэтому защита от DCSync начинается с дисциплины привилегий и прозрачности прав репликации, а продолжается качественным мониторингом репликационных аномалий и готовым планом реагирования.
Если домен давно живёт своей жизнью, самый полезный первый шаг — это ревизия того, у кого есть DS-Replication-Get-Changes и DS-Replication-Get-Changes-All, и зачем. Второй шаг — это выстраивание «чистого пути» для администрирования и сервисных задач, чтобы привилегии не расползались по инфраструктуре. И третий шаг — это детект, который умеет замечать репликацию там, где её быть не должно. В случае DCSync лучше один раз перебдеть, чем потом объяснять, почему внезапно «в домене всё стало не совсем вашим».
