Neste Artigo
No universo da segurança corporativa, poucas combinações são tão perigosas quanto a junção de MITM6 (ataque Man-in-the-Middle via IPv6) com NTLM Relay.
Essa técnica mostra como simples padrões deixados ativos no Windows e Active Directory (AD) podem ser explorados para levar ao comprometimento completo de um domínio.
A seguir, vamos entender em profundidade o ataque, como ele acontece passo a passo e por que seu impacto é tão devastador.
1. Por que o IPv6 ainda é um problema para redes corporativas?
Muitos administradores acreditam que, ao não configurar o IPv6, automaticamente estão protegidos. O que acontece na prática é o contrário:
Máquinas Windows enviam requisições DHCPv6 automaticamente, mesmo em redes puramente IPv4.
Isso significa que, se não houver um servidor DHCPv6 legítimo, o primeiro servidor DHCPv6 que responder será considerado válido pelo Windows.
Esse comportamento cria a brecha perfeita para um servidor DHCPv6 malicioso injetar configurações falsas (exemplo: DNS controlado pelo atacante).
Ou seja: mesmo quem nunca ativou IPv6 na rede pode estar exposto sem perceber.
2. O papel do NTLM no ataque
O NTLM Authentication continua sendo usado em ambientes corporativos por razões de compatibilidade.
Apesar de antigo, ele tem uma fraqueza séria: é suscetível a relay attacks.
O atacante não precisa quebrar a senha.
Ele apenas captura a autenticação e a reaproveita em outro serviço (como LDAP ou SMB).
Ferramentas como
ntlmrelayx.py(do framework Impacket) automatizam esse processo.
Resultado: um simples pedido de autenticação pode ser transformado em acesso privilegiado.
3. WPAD – o elo esquecido da cadeia
O WPAD (Web Proxy Auto-Discovery Protocol) é outra configuração padrão do Windows. Ele foi projetado para facilitar a descoberta de proxies, mas:
A máquina cliente pergunta automaticamente pelo servidor WPAD.
Se o atacante responde antes, a máquina acredita e envia credenciais NTLM para esse servidor falso.
Isso cria a ponte perfeita entre o MITM6 e o NTLM Relay:
O atacante força o cliente a usar DNS malicioso.
O DNS resolve WPAD para o servidor do atacante.
O atacante captura credenciais.
4. Abuso do Active Directory: como se chega ao domínio inteiro
A genialidade (ou tragédia) desse ataque está no abuso de três configurações padrão do Active Directory:
MachineAccountQuota
Por padrão, qualquer usuário autenticado pode criar até 10 contas de máquina no AD.
Isso significa que um atacante com credenciais mínimas consegue inserir novos computadores no domínio.
RBCD (Resource-Based Constrained Delegation)
A conta de máquina criada pode modificar seu próprio atributo
msDS-AllowedToActOnBehalfOfOtherIdentity.Isso permite impersonar contas privilegiadas (inclusive administradores).
Execução remota
Uma vez que o atacante pode se passar por administrador, ele utiliza ferramentas como WMIExec ou PsExec para executar comandos nos servidores do domínio.
A consequência é inevitável: controle total da infraestrutura.
Simulando o ataque em NetCatTest.com
Imagine o cenário de uma empresa fictícia com domínio netcattest.com. Esse domínio roda em um controlador de domínio chamado DC1.netcattest.com, que gerencia toda a autenticação e políticas de rede. Os administradores acreditam estar protegidos porque utilizam apenas IPv4 na infraestrutura, ignorando completamente o IPv6. É justamente aí que o atacante encontra a brecha. O primeiro passo é simples: o atacante conecta seu equipamento à mesma rede em que as estações Windows estão. Automaticamente, as máquinas da empresa enviam solicitações DHCPv6 ao iniciar a conexão. Mesmo que ninguém ali tenha configurado servidores IPv6 legítimos, o Windows, por padrão, continua perguntando. Esse detalhe é o suficiente. O atacante roda a ferramenta mitm6 especificando o domínio da empresa:
| python3 mitm6.py -d netcattest.com |
A partir desse momento, todas as requisições DHCPv6 passam a receber resposta do servidor falso do atacante, que injeta um DNS malicioso controlado por ele. Agora, quando qualquer máquina do domínio precisar resolver nomes, quem responde é o atacante, não o servidor legítimo.
É nesse ponto que entra o WPAD. As máquinas Windows, tentando descobrir automaticamente a configuração de proxy da rede, fazem requisições para wpad.netcattest.com. Como o DNS já está envenenado, essa resolução aponta diretamente para o IP do servidor do atacante. O resultado: as estações começam a enviar credenciais NTLM achando que estão se autenticando em um serviço de rede confiável. Essas credenciais, porém, não ficam paradas. O atacante utiliza o ntlmrelayx, do framework Impacket, para capturar e imediatamente reaproveitar as autenticações contra o LDAP do controlador de domínio. O comando usado é semelhante a:
| ntlmrelayx.py -6 -t ldap://DC1.netcattest.com -wh WPAD --delegate-access |
Com isso, cada autenticação interceptada vira uma tentativa legítima de comunicação com o AD. E aqui entra a primeira “falha padrão” do Active Directory: qualquer usuário autenticado pode criar até dez contas de máquina no domínio sem precisar de permissão especial, graças ao atributo ms-DS-MachineAccountQuota. Assim, o atacante consegue cadastrar um computador falso, por exemplo WIN-HACKER$, dentro de netcattest.com.
O novo computador agora existe oficialmente dentro do domínio e pode interagir com ele. Mas não para por aí. A segunda falha padrão é ainda mais perigosa: máquinas têm a capacidade de modificar o atributo msDS-AllowedToActOnBehalfOfOtherIdentity. Com essa configuração alterada, o atacante faz com que WIN-HACKER$ tenha permissão para agir em nome de outros usuários inclusive administradores de domínio. Essa técnica é conhecida como Resource-Based Constrained Delegation (RBCD) e é uma verdadeira porta dos fundos para a escalada de privilégios. Depois que a delegação maliciosa está configurada, basta ao atacante escolher qual conta privilegiada deseja imitar. Um dos alvos mais comuns é a conta de administração de banco de dados ou mesmo a de Domain Admin. Nesse momento, ele já pode executar comandos remotos em sistemas críticos. Utilizando o módulo wmiexec.py, a execução ocorre de forma direta:
| wmiexec.py netcattest.com/[email protected] -hashes <hashes> |
A tela de resultado não deixa dúvidas. O prompt exibido já não é mais o da máquina atacante, mas sim o de um servidor dentro da rede corporativa. Ao rodar whoami, o retorno é claro:
| netcattest\sqladmin |
O atacante agora não é mais um usuário externo tentando acesso, mas sim um administrador legítimo dentro do domínio netcattest.com. A partir daqui, as possibilidades são praticamente ilimitadas: extração de hashes com secretsdump.py, movimentação lateral com PsExec, exfiltração de dados sigilosos ou até a implantação de ransomware em larga escala.
O mais alarmante é que, em nenhum momento, foi necessário quebrar senhas ou explorar vulnerabilidades complexas de software. Todo o ataque se apoiou em comportamentos padrão do Windows e do Active Directory.
Esse cenário evidencia como a combinação de MITM6 e NTLM Relay cria uma cadeia de ataque silenciosa, quase imperceptível, que transforma uma simples presença na rede em controle total da infraestrutura. O domínio netcattest.com, que parecia protegido, acaba sendo completamente comprometido apenas por confiar em padrões inseguros deixados habilitados por conveniência.
