Ataque DCShadow: Controlador de Domínio Fraudulento

O ataque DCShadow controlador de domínio fraudulento — uma técnica de registro de controlador de domínio fraudulento divulgada publicamente por Benjamin Delpy e Vincent Le Toux (criadores do Mimikatz) na BlueHat IL em janeiro de 2018 — permite que um atacante com privilégios suficientes registre temporariamente uma máquina comprometida como controlador de domínio e envie alterações de objetos do Active Directory para o resto do domínio através do protocolo de replicação normal, em vez de uma API de escrita padrão. O MITRE ATT&CK cataloga isso como T1207 — Rogue Domain Controller.

Este artigo cobre o mecanismo, o motivo pelo qual ele escapa do log que normalmente captura alterações privilegiadas no AD, e passos concretos de detecção e remediação. Para a técnica de abuso de replicação mais comum — ler segredos em vez de escrever alterações — veja Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin e Monitoramento de Seguranca AD: Os Eventos que Importam para a linha de base mais ampla de auditoria de replicação que esta técnica foi projetada para driblar.

O Ataque DCShadow Controlador de Domínio Fraudulento Explicado

Todo controlador de domínio no Active Directory é representado no próprio diretório: um objeto de servidor e um objeto nTDSDSA filho, no contexto de nomenclatura de Configuração (CN=Sites) — a mesma classe de objetos criada sempre que um DC real é promovido. O DCShadow abusa do fato de que qualquer principal com os direitos de replicação corretos pode criar esse mesmo par de objetos em uma máquina que não é, de fato, um controlador de domínio — e então usar o protocolo RPC legítimo do Directory Replication Service (DRS) para fazer o resto do domínio "puxar" alterações dela, como se fosse um par confiável.

⚠️

⚠️ Aviso: como a alteração chega via replicação, e não por meio de escritas LDAP ou do log local de Segurança de um DC, o DCShadow não gera os eventos que as equipes de segurança normalmente usam para detectar adulteração privilegiada do AD — nenhum 4738 (conta de usuário alterada), nenhum 5136 (objeto do serviço de diretório modificado) vinculado à própria alteração.

O DCShadow é diferente do DCSync. O DCSync (DS-Replication-Get-Changes) abusa de direitos de replicação para ler segredos — mais comumente para extrair hashes de senha do ponto de vista de um DC legítimo. O DCShadow abusa de um conjunto diferente, mas adjacente, de direitos de replicação para escrever — ele fabrica uma fonte de replicação fraudulenta e injeta alterações no diretório. Os dois são frequentemente confundidos porque compartilham a mesma família de protocolo subjacente (MS-DRSR) e a mesma classe de pergunta de auditoria "quem tem direitos adjacentes ao DCSync", mas são primitivas de ataque separadas, com superfícies de detecção separadas.

Como Funciona

Passo 1 — Obter os Direitos

Segundo pesquisa independente sobre privilégios mínimos publicada pelo Lab of a Penetration Tester em abril de 2018, o DCShadow não exige estritamente associação a Domain Admins ou Enterprise Admins — esse é o caminho comum, mas a técnica também funciona com um conjunto mais restrito de concessões diretamente no objeto de domínio: os direitos estendidos DS-Install-Replica ({9923a32a-3607-11d2-b9be-0000f87a36b2}, conforme a referência ADSchema da Microsoft), DS-Replication-Manage-Topology e DS-Replication-Synchronize ({1131f6ab-9c07-11d1-f79f-00c04fc2dcd2}, conforme a referência ADSchema da Microsoft) — além de WriteProperty suficiente no próprio objeto de computador da máquina atacante (veja Superfície de Ataque de Objetos de Computador Active Directory: O Risco de Identidade de Máquina que Ninguém Audita sobre essa classe de risco mais ampla) para definir seus Service Principal Names. É por isso que o catálogo da EtcSec rastreia quem possui direitos de Server Trust Account como um achado distinto e crítico: essa é a pré-condição que torna possível registrar um DC fraudulento, independentemente de essa conta também ser Domain Admin.

Passo 2 — Registrar o DC Fraudulento

Usando o módulo lsadump::dcshadow, o Mimikatz (executando com privilégios SYSTEM na máquina atacante) define dois Service Principal Names na conta de computador comprometida e, em seguida, cria os objetos de servidor e nTDSDSA na partição de Configuração. Segundo a estratégia de detecção DET0276 do MITRE, os SPNs usados são o SPN de Global Catalog (GC/<hostname>/<domain>) e o SPN de interface do Directory Replication Service (E3514235-4B06-11D1-AB04-00C04FC2DCD2/<guid>/<domain>) — as mesmas classes de SPN que um DC legítimo possui, o que é exatamente o que permite à máquina se passar por um para fins de replicação.

Passo 3 — Enviar a Alteração

Com o DC fraudulento registrado e os SPNs em vigor, um segundo comando lsadump::dcshadow /push dispara um evento de replicação de saída: a alteração fabricada de objeto ou atributo (uma reescrita de ACL, uma associação de grupo, um msDS-KeyCredentialLink, um atributo de schema — o DCShadow pode ter como alvo essencialmente qualquer dado gravável do AD) é replicada da máquina do atacante para um DC real via IDL_DRSReplicaAdd/GetNCChanges, exatamente como se tivesse vindo de um DC par.

Passo 4 — Desregistrar e Desaparecer

O atacante remove o objeto de servidor e nTDSDSA fraudulento, restaura os SPNs originais, e a máquina volta a parecer um computador comum ingressado no domínio. A alteração maliciosa, porém, já foi replicada para todos os DCs reais do domínio e persiste no diretório.

Detecção

Os passos de registro e desregistro são a janela detectável — a própria alteração enviada, uma vez replicada, se parece com qualquer outro atributo de diretório.

Indicador	ID do Evento	Origem	Descrição
Contexto de nomenclatura de origem de réplica estabelecido	4928	DC — subcategoria "Auditar Replicação Detalhada do Serviço de Diretório"	Segundo a referência de eventos da Microsoft, disparado quando um DC começa a tratar uma origem como parceiro de replicação. Em um DC legítimo, isso se correlaciona com promoções conhecidas; um Source DRA inesperado é o sinal.
Contexto de nomenclatura de origem de réplica removido	4929	DC — mesma subcategoria	Segundo a referência de eventos da Microsoft, disparado no desregistro — a etapa de limpeza do DCShadow. Um par 4928/4929 próximo no tempo, vindo de um host que não é um DC conhecido, é um sinal forte.
Conta de computador modificada	4742	DC — "Auditar Gerenciamento de Contas de Computador"	Segundo a referência de eventos da Microsoft, disparado quando os SPNs da máquina atacante são definidos. Correlacione o Subject (a conta que realiza a alteração) com sua lista de detentores conhecidos de Domain Admin / Server Trust Account.
Criação de objeto nTDSDSA / servidor no NC de Configuração	—	Directory Service Changes (5137), requer uma SACL em `CN=Sites,CN=Configuration`	O Active Directory não audita a partição de Configuração por padrão. É necessária uma SACL no container Sites para que esse sinal exista — isso corresponde diretamente a correlacionar "objetos nTDSDSA/servidor inesperados" conforme a orientação DET0276 do MITRE.
Uso inesperado de SPN de DRS	—	Autenticação Kerberos / correlação de SIEM	Segundo o MITRE DET0276, autenticação Kerberos usando as classes de SPN `GC/` ou `E3514235-4B06-11D1-AB04-00C04FC2DCD2` a partir de um host fora da lista conhecida de DCs.

💡

💡 Dica: nenhum dos sinais da partição de Configuração acima é capturado por padrão. Se a única visibilidade que você tem sobre replicação for a política de auditoria padrão do NC de domínio, você não verá um registro de controlador de domínio fraudulento via DCShadow. Essa é exatamente a lacuna que a técnica foi projetada para explorar — ferramentas especializadas (análise da SentinelOne) recomendam tratar o par 4928/4929 e as SACLs do NC de Configuração como linha de base, não como um extra opcional.

Remediation

1. Audite Quem Possui Direitos de Server Trust Account e de Escrita de Replicação

A pré-condição para um ataque DCShadow é um principal com DS-Install-Replica, DS-Replication-Manage-Topology e DS-Replication-Synchronize no objeto de domínio — ou direitos mais amplos para definir os SPNs de uma conta de computador. Faça esse levantamento da mesma forma que auditaria contas capazes de DCSync, mas para os direitos estendidos do lado de escrita:

# Listar principals não padrão com direitos estendidos de replicação no objeto de domínio
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access |
  Where-Object { $_.ActiveDirectoryRights -match "ExtendedRight" } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Cruze cada resultado com sua associação esperada de Domain Admin / Enterprise Admin — qualquer outra coisa é uma concessão não documentada que vale a pena investigar.

2. Habilite a Auditoria da Partição de Configuração

Alterações no NC de Configuração não são auditadas por padrão. Aplique uma SACL em CN=Sites,CN=Configuration,DC=<domain> (e, idealmente, na raiz do NC de Configuração) para que a criação/exclusão de objetos nTDSDSA e de servidor gere eventos de Directory Service Changes (5136/5137), e habilite a subcategoria "Auditar Replicação Detalhada do Serviço de Diretório" em todo o domínio para que 4928/4929 sejam capturados.

3. Minimize e Segmente o Acesso Privilegiado

💡

💡 Vitória Rápida: trate "quem pode se registrar como DC" como uma questão de Tier 0, não apenas "quem é Domain Admin".

Siga um modelo de administração em camadas — veja Endurecimento Active Directory: o que bloquear primeiro e como validar — para que as contas capazes de possuir direitos de escrita de replicação sejam o mesmo conjunto pequeno e monitorado que você já trata como Tier 0, sem associação permanente além do que é ativamente necessário. Essa é a mesma disciplina que evita o desvio de acesso privilegiado de forma mais ampla.

4. Alerte para o Par 4928/4929 Correlacionado com DCs Conhecidos

Crie uma regra de detecção que sinalize qualquer 4928 (e seu 4929 correspondente) cujo Source DRA não corresponda ao seu inventário mantido de controladores de domínio legítimos. Como a janela de registro do DCShadow costuma ser breve, o encaminhamento de logs quase em tempo real importa mais aqui do que na maioria das detecções de AD — uma revisão em lote diária geralmente ocorre depois que o DC fraudulento já se desregistrou.

Como a EtcSec Detecta Isso

O catálogo de vulnerabilidades de AD da EtcSec sinaliza essa exposição por meio de duas verificações: DCSHADOW_EVIDENCE, que procura evidências diretas de que um registro de controlador de domínio fraudulento via DCShadow ocorreu, e SERVER_TRUST_ACCOUNT_RIGHT, que sinaliza contas e grupos que possuem os direitos para definir uma conta de server trust — a pré-condição que torna a técnica viável independentemente de essa conta também ser Domain Admin. Ambientes que já revisaram suas contas capazes de DCSync devem tratar isso como a auditoria complementar: os direitos de replicação dos caminhos de leitura e escrita geralmente vêm dos mesmos erros de delegação, mas raramente são revisados juntos.

ℹ️

ℹ️ Nota: a EtcSec verifica automaticamente evidências de DCShadow e direitos de Server Trust Account em cada auditoria de AD. Execute uma auditoria gratuita para verificar se seu ambiente apresenta essa exposição.

Ataque DCShadow Controlador de Domínio Fraudulento: Registro que Contorna a Auditoria do AD