Netwrix 1Secure oferece visibilidade unificada de dados e identidade - gratuito por 14 dias com acesso total.Inicie um teste gratuito

Centro de recursosBlog
Você Não Pode Reverter um Segredo que Já Foi Lido

Você Não Pode Reverter um Segredo que Já Foi Lido

Aug 20, 2026

A segurança do Active Directory passou uma década competindo em velocidade de recuperação. A pergunta que realmente decide o resultado é se a alteração maliciosa chega a ser confirmada.

Imagine um cofre de documentos com propriedade intelectual valiosa. Um espião contratado o abre, fotografa os documentos que estão dentro, fecha-o novamente e vai embora. Na manhã seguinte, o cofre está exatamente como estava na noite anterior: mesma porta, mesma combinação, nada fora do lugar. Não há nada para devolver, porque, nos termos que uma ferramenta de recuperação entende, nada foi levado. A perda já saiu do prédio como uma cópia.

Essa é a forma incômoda que uma grande classe de ataques ao Active Directory assume, e é por isso que a narrativa defensiva favorita do setor tem uma lacuna bem no meio dela.

Por uma década, o mercado de segurança do Active Directory competiu em um único eixo: a rapidez com que você consegue desfazer uma alteração maliciosa. Detectar a gravação maliciosa, gerar um alerta e depois reverter para um estado íntegro conhecido. O rastreamento de alterações à prova de adulteração e o rollback automatizado são toda a proposta. Como narrativa de recuperação, é uma boa narrativa, e a recuperação realmente importa. Mas ela concede o ponto que realmente conta. A alteração já aconteceu, e algumas alterações, uma vez ocorridas, não podem mais ser desfeitas.

Os ataques ao Active Directory que terminam antes que você consiga revertê-los

Considere como os ataques a AD mais rápidos realmente funcionam. Grupos de ransomware encadeiam falhas como o noPac, o par de falsificação de sAMAccountName por trás do CVE-2021-42278 e do CVE-2021-42287, para passar de uma conta comum ao controle total do domínio em minutos. Assim que o invasor alcança essa posição, as técnicas seguintes não são um vandalismo barulhento que pode ser limpo depois. São leituras e personificações que concluem seu trabalho antes que um rollback tenha algo para recuperar.

O DCSync é o exemplo mais claro e o paralelo direto com a história do cofre. Abusando do próprio protocolo de replicação do diretório, o invasor solicita a um controlador de domínio os hashes de senha das contas e os recebe como faria outro controlador. Nenhum objeto alterado permanece no diretório para que uma ferramenta de recuperação o note e o reverta. A alteração, tal como é, é uma cópia das suas credenciais que já se foi. Você pode redefinir todas as senhas depois, e deveria fazer isso, mas nesse ponto você está limpando a bagunça após um roubo, não impedindo-o.

O DCShadow atua na direção oposta. Ele registra um controlador de domínio fraudulento e ilegítimo e injeta no diretório alterações escolhidas pelo invasor por meio do canal de replicação, contornando o caminho de gravação normal que o seu monitoramento observa. Aqui, o controle eficaz recusa a replicação fraudulenta no instante em que ela é tentada, de modo que a alteração injetada nunca chega a entrar no diretório para ser revertida.

Agora considere uma edição maliciosa de um objeto de política de grupo (GPO), do tipo que distribui uma payload de ransomware para cada máquina que lê a política, ou uma adição discreta a um grupo privilegiado. Reverta o objeto e o estado do diretório é restaurado. No entanto, a política já foi distribuída e a payload que ela carregava já foi executada. Restaurar o objeto não faz nada quanto ao raio de impacto já criado.

É aqui que a narrativa de recuperação fica sem espaço. Para toda essa categoria, a detecção e o rollback chegam, por sua própria estrutura, tarde demais, e a prevenção não é uma versão mais rápida da mesma ideia: é uma disciplina diferente. A detecção confirma que algo perigoso já alcançou o diretório. A prevenção interrompe a operação antes que o diretório chegue a aceitá-la.

Detecção versus prevenção: um ataque de GPO, analisado das duas formas

Suponha que um invasor edite um GPO vinculado aos seus servidores para implantar uma payload na próxima atualização de política. Pense nisso primeiro segundo o modelo de recuperação. A configuração maliciosa é detectada e revertida, e o GPO volta ao seu estado anterior; no papel, o incidente está encerrado. Na prática, todas as máquinas que buscaram a política na janela entre a edição e a reversão já executaram a payload, e nenhuma quantidade de restauração do objeto desfaz essa execução.

Agora pense nisso da outra forma. A gravação nesse GPO é avaliada de forma inline e rejeitada antes que o Active Directory a confirme (commit). A política nunca muda, portanto nunca é distribuída, e não resta nenhuma execução de payload para investigar. Mesmo ataque, dois modelos de defesa, e apenas um deles não deixa nada para você limpar.

Por que a palavra certa é prevenção, não detecção rápida

Esse segundo resultado só está disponível para um controle que atue no próprio caminho de gravação. Esse é o mecanismo por trás do Netwrix Threat Manager: ele avalia as operações de forma inline (alterações em objetos críticos e GPOs, modificações em grupos privilegiados e solicitações de replicação) e as bloqueia na origem, antes que o diretório confirme a gravação. Ele também captura esses eventos em seu ponto de origem mesmo quando o registro nativo foi desativado ou apagado, de modo que um invasor não consiga cegar o controle apagando os registros antes. É isso que conquista a palavra prevenção, em vez de uma detecção rápida vestida com uma linguagem mais forte.

Nada disso significa que a prevenção substitua a detecção. Alguns ataques só podem ser identificados e respondidos depois do fato, e fingir o contrário não sobrevive à primeira pergunta direta que qualquer CISO competente fará. Prometer demais atrai a resposta que merece. A postura defensável é mais restrita e mais sólida do que um slogan: prevenção em primeiro lugar para as alterações que podem ser bloqueadas de forma determinística, detecção e resposta para tudo o mais.

Há uma visão de mundo consistente por trás disso. Insistir em bloquear uma alteração perigosa no momento em que ela é tentada é a contrapartida, do lado da resiliência, de insistir em saber quem tem acesso no momento em que o utiliza. Ambas insistem em agir no instante da ação, e não na limpeza que vem depois.

O que nos leva de volta ao cofre que parecia intocado. O rollback é uma promessa de que você pode desfazer o dano rapidamente. A prevenção é uma garantia de que não houve dano algum para desfazer. Para os ataques ao Active Directory que copiam um Secret, personificam um controlador ou detonam antes que você consiga revertê-los, apenas uma dessas duas é uma promessa que o mecanismo realmente pode cumprir, e ela é feita pelo controle que nunca deixou a alteração ser confirmada (commit).

Compartilhar em

Saiba Mais

Sobre o autor

Asset Not Found

Dirk Schrader

VP de Pesquisa de Segurança

Dirk Schrader é um Resident CISO (EMEA) e VP de Pesquisa de Segurança na Netwrix. Com 25 anos de experiência em segurança de TI e certificações como CISSP (ISC²) e CISM (ISACA), ele trabalha para promover a ciberresiliência como uma abordagem moderna para enfrentar ameaças cibernéticas. Dirk trabalhou em projetos de cibersegurança ao redor do mundo, começando em funções técnicas e de suporte no início de sua carreira e, em seguida, passando para posições de vendas, marketing e gestão de produtos em grandes corporações multinacionais e pequenas startups. Ele publicou numerosos artigos sobre a necessidade de abordar a gestão de mudanças e vulnerabilidades para alcançar a ciberresiliência.