Active Directory е туптящото сърце на идентичността в повечето предприятия и неговата единствена най-ценна тайна е хешът на паролата на всеки потребител, услуга и машинен акаунт.

DCSync атаката позволява на атакуващия да си тръгне с тези хешове, без изобщо да се вписва в домейнов контролер, да оставя инструмент на него или да чете NTDS.dit базата данни от диска. Вместо това атакуващият просто изисква от домейновия контролер да му предаде тайните, като използва същия репликационен протокол, който домейновите контролери използват за синхронизация помежду си.

Технически, DCSync се представя за домейнов контролер и изпраща заявка за репликация на директория чрез отдалечения протокол на Microsoft за услуги за репликация на директории (MS-DRSR).

Той се свързва с DRSUAPI RPC интерфейса и извиква IDL_DRSGetNCChanges, за да изиска атрибутите за идентификационни данни на един акаунт, на няколко или на всеки акаунт в домейна. Домейновият контролер, вярвайки, че разговаря с друг домейнов контролер, отговаря с NTLM хешове, Kerberos ключове и история на паролите.

За първи път превърнат в оръжие в Mimikatz от Бенджамин Делпи и Венсан Льо Ту, DCSync сега е стандартен ход в почти всеки сценарий на зловреден софтуер за откуп (ransomware) и на държавно спонсорирани атакуващи групи. MITRE ATT&CK го класифицира като T1003.006 (OS Credential Dumping: DCSync).

За по-широк поглед върху това къде се вписва тази атака в едно проникване, вижте Списъка с веригата за компрометиране при атака срещу Active Directory.

Защо DCSync е толкова безшумна и опасна

Повечето техники за кражба на идентификационни данни оставят шумни следи. Дъмпингът на LSASS генерира подозрителен достъп до процеси; кражбата на NTDS.dit от домейнов контролер обикновено означава създаване на Volume Shadow Copy, копиране на заключена база данни и вземане на системния регистър SYSTEM — като всички те пишат по диска и задействат аларми за защита на крайни устройства. DCSync избягва всеки един от тези признаци.

Тъй като заявката се движи по същия репликационен канал, който домейновите контролери легитимно използват, тя изглежда като рутинна синхронизация на директория за целевия домейнов контролер. Няма зловреден код, който да бъде поставен под карантина, няма копиране в сянка, което да се маркира, и няма предупреждение за достъп до файлове.

Атаката се изпълнява изцяло от работната станция на атакуващия, така че домейновият контролер никога не изпълнява код на атакуващия. Поради това откриването зависи почти изцяло от одита на услугите на директорията и мрежовата телеметрия, а не от традиционния антивирусен софтуер.

Въздействието е сериозно, тъй като DCSync предава хеша на krbtgt акаунта. С него атакуващият може да фалшифицира „Golden Tickets“ (Златни билети) – самоиздадени Kerberos билети, които предоставят достъп като всеки потребител, до всяка услуга, за толкова дълго време, колкото ключът krbtgt остане непроменен.

Това на практика представлява персистентно компрометиране на целия домейн от една единствена репликационна заявка. Същите хешове захранват странично движение от тип „Pass-the-Hash“ и офлайн разбиване на пароли. Резултатът е същият катастрофален изход като при кражба на NTDS.dit база данни, но е много по-тих.

Как работи DCSync под капака

DCSync операцията е кратък, добре дефиниран обмен. Разбирането на всяка стъпка показва на защитника точно къде се появяват откриваемите артефакти.

  • Стъпка 1 — RPC свързване: Атакуващият се свързва с DRSUAPI интерфейса (UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2) на целевия домейнов контролер.
  • Стъпка 2 — Заявка за репликация: Той извиква IDL_DRSGetNCChanges, искайки от домейновия контролер да репликира тайните атрибути на избран обект — обикновено krbtgt, администратор на домейн или всички акаунти наведнъж.
  • Стъпка 3 — Проверка на достъпа: Домейновият контролер проверява дали изпращачът притежава разширените права DS-Replication-Get-Changes(-All). Ако е така, заявката се третира като легитимна репликация.
  • Стъпка 4 — Връщане на тайните: Домейновият контролер връща NTLM хеша, AES/Kerberos ключовете, LM хеша (ако е наличен) и историята на паролите за заявените акаунти.

Правата за репликация, които я правят възможна

DCSync зависи от две разширени права в контекста за именуване на домейна. На атакуващия са му необходими както Get-Changes, така и Get-Changes-All: първото оторизира репликацията, а второто отключва поверителните атрибути (хешове на пароли) в нея.

По подразбиране тези права се притежават само от администратори на домейни (Domain Admins), корпоративни администратори (Enterprise Admins), администратори (Administrators) и домейнови контролери (Domain Controllers).

Проблемът е в неконтролираното предоставяне на права: пощенски конектори, Entra Connect / Azure AD Sync, софтуер за резервно копиране и наследени акаунти за миграция често получават тези права и след това биват забравени, превръщайки обикновен служебен акаунт в отправна точка за DCSync.

Неуправляваните ACL списъци като тези са сред най-често срещаните неправилни конфигурации в Active Directory, които водят до пълно компрометиране на домейна.

Какво е необходимо на атакуващия първоначално (Предпоставки)

DCSync не е техника за първоначален достъп – това е инструмент, към който атакуващият посяга, след като е придобил подходяща идентичност. Реалистичните пътища към акаунт с възможности за DCSync включват: съвместни техники, подробно разглеждани в киберсигурността, включително атаки с принудителна автентификация, MITM6 + NTLM препредаване (relay) и dMSA атака в Windows Server 2025.

Техники за DCSync атака, инструменти и команди

След като атакуващият контролира субект с права за репликация, изпълнението на DCSync е лесно. По-долу са изброени инструментите, които защитниците ще видят споменати в докладите за заплахи, заедно с примерни команди.

1. Разузнаване — откриване на това кой може да изпълнява DCSync
Преди...