O que é um ataque DCSync: detecção e prevenção

DCSync é um ataque que permite a um adversário simular o comportamento de um controlador de domínio (DC) e recuperar dados de senha por meio da replicação de domínio. O uso clássico para DCSync é como precursor de um ataque de Golden Ticket , pois pode ser usado para recuperar o hash KRBTGT.

Especificamente, DCSync é um comando na ferramenta de código aberto Mimikatz. Ele utiliza comandos no Directory Replication Service Remote Protocol (MS-DRSR) para simular o comportamento de um controlador de domínio e solicitar a outros controladores de domínio que repliquem informações — aproveitando funções válidas e necessárias do Active Directory que não podem ser desativadas ou desabilitadas.

O Processo de Ataque

O ataque DCSYNC funciona da seguinte forma:

1. O atacante descobre um controlador de domínio para solicitar replicação.
2. O atacante solicita a replicação do usuário usando o GetNCChanges
3. O DC retorna os dados de replicação ao solicitante, incluindo os hashes de senha.

Direitos Necessários

Alguns direitos muito privilegiados são necessários para executar um ataque DCSync. Como normalmente leva algum tempo para um atacante obter essas permissões, esse ataque é classificado como um ataque de cadeia de eliminação em estágio avançado.

Geralmente, Administradores, Domain Admins e Enterprise Admins possuem os direitos necessários para executar um ataque DCSync. Especificamente, os seguintes direitos são necessários:

• Replicando Alterações de Directory
• Replicando alterações em todo o Directory

Replicando alterações no diretório em conjunto filtrado

Como as soluções Netwrix podem ajudá-lo a detectar e impedir ataques DCSync

Detecção

Netwrix Threat Manager monitora todo o tráfego de replicação de domínio em busca de sinais de DCSync. Não depende de logs de eventos ou captura de pacotes de rede. Seu principal método de detecção é encontrar padrões de comportamento que correspondam ao DCSync, incluindo atividade de replicação entre um controlador de domínio e uma máquina que não é um controlador de domínio.

A solução fornece um resumo claro da atividade suspeita, bem como uma visualização ilustrando qual usuário perpetrou o ataque, o domínio e o usuário alvo, e evidências de suporte do ataque. Se o mesmo usuário executar múltiplos ataques DCSync, essa informação crítica também será incluída.

Resposta

Para executar o DCSync, um atacante precisa de privilégios elevados, então a chave para impedir um ataque é bloquear imediatamente a escalada de privilégios. A resposta padrão do playbook de desativar a conta do usuário pode não ser suficiente, já que quando você percebe o ataque em andamento, o atacante provavelmente tem uma série de outros recursos e opções disponíveis.

Netwrix Threat Prevention fornece políticas de bloqueio que podem impedir uma conta ou estação de trabalho de executar replicação adicional, o que pode desacelerar um ataque e dar mais tempo aos respondentes para eliminar completamente a ameaça.

Netwrix Threat Manager suporta essas etapas de resposta fornecendo detalhes sobre o perpetrador do ataque DCSync, fontes, alvos e objetos consultados.

O que é um ataque DCSync?

Os atacantes chegam lá com mais frequência por esse tipo de delegação residual do que por uma conta de administrador comprometida, pois os direitos de replicação são concedidos a contas de serviço durante migrações e integrações e depois nunca são revogados.

No entanto, o próprio DCSync não tem patch, pois usa a mesma interface de replicação que os controladores de domínio usam para se manter sincronizados, e bloqueá-lo quebraria o Active Directory. O tráfego resultante parece idêntico à replicação comum para quem analisa os logs rapidamente.

Como funciona um ataque DCSync

Apenas 26% das organizações estão totalmente confiantes de que seu Active Directory está livre de configurações incorretas que permitem escalonamento de privilégios, de acordo com o Netwrix 2026 Data and Identity Security Report. Essa incerteza é justificada, pois o DCSync precisa de apenas uma permissão delegada em uma conta de serviço esquecida para entregar todos os hashes de senha do domínio.

A sequência é concluída em segundos e não requer execução de código no controlador de domínio.

1. O atacante mira em qualquer domain controller no domínio

Um ataque DCSync é uma técnica de intrusão em que um adversário simula um controlador de domínio (DC) e recupera dados de senha por meio da replicação de domínio. Geralmente precede um ataque Golden Ticket.

3. O controlador de domínio alvo retorna hashes de senha

Não é necessário nenhum acesso prévio a essa máquina específica, pois a solicitação viaja pela rede como qualquer outro tráfego de replicação. Qualquer controlador de domínio irá respondê-la.

2. O invasor se faz passar por um controlador de domínio para solicitar a replicação

DCSync também é o nome de um comando na ferramenta open-source Mimikatz. O comando usa o Directory Replication Service Remote Protocol (MS-DRSR) para se passar por um controlador de domínio e pedir aos controladores reais que repliquem informações do diretório, abusando da replicação AD que funciona exatamente como projetado. MITRE o rastreia como T1003.006 sob OS Credential Dumping, e não há vulnerabilidade subjacente para corrigir.

O atacante chama IDL_DRSGetNCChanges na interface de replicação MS-DRSR, também conhecida como DRSUAPI, e solicita dados de replicação de usuários enquanto se faz passar por um controlador de domínio. A chamada é um uso legítimo da API de replicação, não uma solicitação malformada ou incomum, portanto não aciona defesas em nível de protocolo.

O controlador de domínio responde com dados de replicação, incluindo hashes de senha, porque a interface não consegue distinguir um controlador de domínio legítimo de uma conta com as permissões corretas.

4. Ferramentas existentes executam a solicitação

Quais direitos um ataque DCSync requer

Administrators, Domain Admins e Enterprise Admins possuem os direitos necessários por padrão. Como esses privilégios levam tempo para serem obtidos, o DCSync tende a aparecer tardiamente na cadeia de ataque. As permissões específicas são:

• Replicando alterações do Directory (DS-Replication-Get-ChangesExpand)

O módulo PowerShell DSInternals o expõe através de Get-ADReplAccountExpand. Extrair dados de senha de usuário com Mimikatz DCSync cobre toda a sequência de comandos.

O módulo lsadump::dcsync do Mimikatz continua sendo a implementação mais conhecida, e outras ferramentas realizam a mesma solicitação de replicação. O secretsdump.py do Impacket executa-o pela rede, e o módulo DSInternals PowerShell o expõe através de Get-ADReplAccountExpand.

• Replicando Directory Changes All (DS-Replication-Get-Changes-AllExpand)
• Replicação de alterações de Directory em conjunto filtrado (requerido apenas em alguns ambientes)

Mais duas permissões abrem a mesma porta e raramente aparecem em uma revisão da associação a grupos privilegiados. Uma conta com GenericAll (controle total) ou AllExtendedRights no nível de domínio pode executar DCSync sem pertencer a nenhum grupo privilegiado.

O que os atacantes fazem com os hashes

Qualquer conta com esses direitos delegados no contexto de nomenclatura de domínio pode replicar. Contas de serviço Entra Connect, normalmente nomeadas com o prefixo MSOL_, possuem legitimamente esses direitos, assim como contas que os herdaram de uma migração ou integração esquecida há muito tempo.

Os direitos de replicação que tornam o DCSync possível são permissões; os hashes que ele retorna não são. Um hash é material de credencial, a representação criptográfica de uma senha, e possuir um permite que um invasor se faça passar por quem ele pertence sem nunca conhecer a senha real dessa pessoa. O que um invasor faz a seguir depende de qual conta ele obteve o hash.

Hash KRBTGT: Forjar tickets para qualquer conta no domínio

Enumerar quem detém os direitos hoje é a verificação de exposição mais barata disponível, pois a delegação está nas listas de controle de acesso (ACLs) que uma ferramenta de avaliação de diretório lê diretamente, e análise do caminho de ataque mostra como esses direitos se encadeiam.

Os atacantes obtêm esses direitos por meio de privilege escalation, então qualquer conta que os possua precisa da mesma privileged account management disciplina que um Domain Admin, não um acesso permanente que ninguém revisita.

Hashes de contas regulares: Movimente-se lateralmente sem decifrar nada

Uma execução de DCSync que alcança a conta KRBTGT transforma o roubo de credenciais em comprometimento do domínio. O hash KRBTGT assina todos os tickets Kerberos no domínio. Um invasor que o possua pode forjar Ticket Granting Tickets (TGTs) para qualquer conta sem tocar nas credenciais dessa conta, e esse acesso forjado sobrevive a uma redefinição normal de senha na conta personificada. Apenas uma redefinição de KRBTGT invalida os tickets forjados.

Material de credenciais mais fraco: quebrar offline uma senha em texto simples

Como detectar um ataque DCSync

Hashes NT LAN Manager (NTLM) para contas regulares e privilegiadas alimentam Pass-the-Hash diretamente. Um invasor se autentica como essa conta reproduzindo o hash em si, então nada precisa ser quebrado antes que a credencial possa ser usada em outro lugar no domínio.

Três locais podem detectar uma solicitação DCSync, e cada um detecta algo diferente: o log de eventos do controlador de domínio, a própria rede e o comportamento da identidade que faz a solicitação.

Chaves Kerberos e histórico de senhas armazenadas recuperados na mesma resposta de replicação são quebrados offline quando o tipo de hash é fraco o suficiente para tornar isso prático. Senhas em texto simples aparecem diretamente apenas para contas configuradas com criptografia reversível, uma configuração que vale a pena auditar exatamente por esse motivo.

Ative a auditoria do Directory Service e alertas sobre os GUIDs de replicação

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 para DS-Replication-Get-ChangesExpand
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 para DS-Replication-Get-Changes-AllExpand

Observe o tráfego para replicação de um host que não seja DC

Comportamento básico de identidade para capturar o que um único evento não consegue

Ative primeiro a Advanced Audit Policy para Directory Service Access, pois o Windows a desativa por padrão e o Evento ID 4662 não será acionado sem ela. Uma vez ativada, observe especificamente esses GUIDs de propriedades de replicação, identificados por identificador global único (GUID) em vez de nome amigável:

Alerta quando esses GUIDs aparecerem em uma conta que não seja um domain controller ou uma conta de serviço de replicação conhecida, e filtre antes de alertar, pois um volume 4662 não filtrado em um domain controller ocupado gera ruído que ninguém lê. Trate este sinal como um respaldo em vez do controle principal, pois um invasor que alcança um domain controller também pode limpar ou atrasar os logs dos quais uma estratégia somente 4662 depende.

Como prevenir ataques DCSync

Controle novos direitos de replicação no provisionamento, não apenas na próxima revisão

Não existem controles a nível de protocolo que bloqueiem o DCSync, portanto a prevenção depende de controlar quem pode invocar a replicação e encurtar os caminhos que levam a esses direitos.

Monitore uma ligação DRSUAPI que carrega IDL_DRSGetNCChanges de qualquer host que não seja um controlador de domínio, pois a replicação legítima ocorre apenas entre controladores de domínio e não existe uma versão benigna desse tráfego para filtrar. Priorize este sinal em relação à detecção em logs de eventos, pois o monitoramento de rede captura a solicitação independentemente de o controlador de domínio tê-la registrado, mantendo o sinal disponível mesmo após um invasor manipular o registro do endpoint.

Alimente eventos de replicação em uma plataforma de Identity Threat Detection que constrói uma linha de base para o comportamento normal de cada conta, pois um evento 4662 ou uma vinculação DRSUAPI podem parecer legítimos isoladamente, mas anormais em relação ao histórico específico daquela conta. Esta camada existe para detectar o padrão de uma conta que nunca fez uma solicitação de replicação antes de fazê-lo uma vez, algo que uma lista de permissões estática ou uma regra pontual podem perder completamente.

Os direitos concedidos durante uma migração ou integração tendem a permanecer muito depois do fim do projeto, pois remover acessos que ninguém lembra de ter concedido é mais difícil do que concedê-los inicialmente.

Revise e remova direitos de replicação que ninguém pode justificar

Restringir a RPC de replicação a endereços conhecidos de controladores de domínio

Revise todas as contas que possuem as três permissões de replicação mais GenericAll e AllExtendedRights no contexto de nomenclatura do domínio e remova o que ninguém pode justificar. Repita a revisão periodicamente, pois novas integrações reintroduzem os direitos.

Feche os caminhos que os atacantes usam para alcançar direitos de replicação

Quando a topologia permitir, permita a replicação de chamadas de procedimento remoto (RPC) apenas entre endereços conhecidos de controladores de domínio. Isso não impedirá um invasor que já tenha direitos válidos de replicação, mas bloqueia solicitações de qualquer host sem motivo legítimo.

Como responder a um ataque DCSync suspeito

Delimite o que o invasor realmente consultou

Enterprise Key Admins é o exemplo recorrente, pois o adprep /domainprep no Windows Server 2016 concedeu a esse grupo controle total sobre o Domain Naming Context e seus objetos filhos. A Microsoft chamou isso de bug em vez de vulnerabilidade e corrigiu para novas preparações de domínio a partir da atualização 1709, mas domínios preparados antes dessa correção precisam de um script de remediação separado; atualizações de esquema em todo o domínio sozinhas não resolverão isso.

Suponha que os hashes já tenham desaparecido, porque os dados saíram do domínio antes do alerta ser acionado. O que você fizer a seguir decide por quanto tempo esse acesso continuará a beneficiar o invasor.

Exigir uma justificativa documentada e um responsável nomeado antes que qualquer nova integração ou migração receba DS-Replication-Get-ChangesExpand, DS-Replication-Get-Changes-AllExpand, GenericAllExpand, ou AllExtendedRightsExpand, em vez de conceder o direito primeiro e revisá-lo no próximo ciclo de auditoria.

Revise o ID do Evento 4662, Directory Service e os logs do Sysmon para estabelecer quais objetos o invasor consultou antes de decidir até onde a contenção e a remediação precisam chegar. O que for encontrado aqui determina se a resposta para em uma conta ou se estende a uma redefinição de credenciais em todo o domínio.

Verifique se Zerologon (CVE-2020-1472) foi corrigido, pois vulnerabilidades que concedem privilégios de domínio encurtam diretamente toda a cadeia de ataque. Considere rotas de coleta de credenciais como Kerberoasting como a forma pela qual os atacantes obtêm direitos de replicação desde o início, não como um problema separado para resolver depois. Ambas as correções fazem parte das melhores práticas de segurança de Active Directory que mantêm sob controle os outros caminhos privilegiados do domínio.

Redefina o KRBTGT duas vezes se ele estiver entre os hashes

Contenha a fonte, não apenas a conta implicada

Desativar a conta implicada é o reflexo, mas por si só realiza pouco, pois o invasor agora possui credenciais que funcionam independentemente dessa conta. Revogue os direitos de replicação e as associações a grupos privilegiados e isole o host de origem.

Como a Netwrix ajuda você a detectar e bloquear ataques DCSync

Encontre todas as contas com direitos de replicação

Avaliação, detecção e prevenção são feitas por diferentes produtos aqui, que trabalham juntos.

Se KRBTGT estava entre eles, redefina a senha do KRBTGT duas vezes, deixando um intervalo entre as duas redefinições maior que o tempo máximo de vida do ticket (10 horas por padrão) e um ciclo completo de replicação. Uma única redefinição deixa a chave anterior válida, então os tickets falsificados continuam funcionando. Quando os logs não conseguem estabelecer o escopo, opte por uma redefinição de credenciais em todo o domínio em vez de adivinhar.

Detectar uma solicitação de replicação de um host que não seja DC

Bloqueie a solicitação de replicação antes que ela seja concluída

Netwrix PingCastle avalia o Active Directory com base em suas verificações mapeadas pelo MITRE ATT&CK, incluindo contas com direitos de replicação fora dos grupos padrão, transformando a revisão de delegação acima em uma verificação repetível.

Seus alertas mostram a conta por trás da solicitação, o domínio e a conta alvo, e os objetos consultados, que são os detalhes que um analista precisa para delimitar a execução, em vez de apenas confirmar que ela ocorreu.

A detecção de DCSync vem de uma política de Netwrix Threat Prevention AD Replication Monitoring, portanto, os dois produtos funcionam em conjunto.

Netwrix Threat Manager detecta técnicas de roubo de credenciais contra Active Directory, incluindo uma solicitação de replicação emitida por uma máquina que não é um controlador de domínio, e alerta sobre isso.

Netwrix Threat Prevention aplica políticas de bloqueio que impedem que uma conta ou estação de trabalho específica execute replicações adicionais. Ambos se enquadram em identity threat detection and response, com Threat Manager estendendo a detecção para Entra ID e Threat Prevention aplicando no nível do Active Directory local.

Por onde começar com a exposição DCSync

[MARCADOR DE IMAGEM: Produto, solicitação ao PMM. Precisa de uma captura de tela do produto Netwrix Threat Manager (qualquer visualização atual mostrando um evento DCSync detectado com host de origem, conta alvo e objetos consultados)]

Os direitos de replicação carregam a maior parte da defesa aqui, e uma lista de delegação que ninguém revisou desde a última migração é o caminho de ataque realista. Enumerá-la custa uma tarde.

Solicite uma demonstração para ver como Netwrix encontra direitos de replicação, detecta uma tentativa ativa de DCSync e bloqueia a próxima no seu próprio ambiente Active Directory.

O alerta sobre replicação de hosts que não são controladores de domínio detecta a tentativa em si, e esse sinal permanece válido independentemente de a auditoria do Directory Service ter sido ativada ou não. Um procedimento documentado de redefinição do KRBTGT decide então por quanto tempo uma execução bem-sucedida continua beneficiando o invasor.