Keyeroo

किसी coerced victim के NTLM authentication को LDAP पर relay करें और उस victim के रूप में एक ऑपरेशन चलाएँ, भले ही domain controller LDAP signing की मांग करता हो और पूरी तरह patched हो।

यदि कोई DC LDAP signing की मांग करता है, तो हम NTLM को LDAP पर relay नहीं कर सकते क्योंकि हम victim की session key नहीं जानते, जो bind के बाद हर LDAP संदेश के लिए signing key होती है। Switcheroo ने bind और ऑपरेशन को हमारी अपनी session key से signed एक ही buffer में रखकर इससे बचने का रास्ता निकाला था, लेकिन अक्टूबर 2026 के अपडेट ने उसे ठीक कर दिया। Keyeroo एक अलग रास्ता अपनाता है। जो session key हमारे पास नहीं है, उसे bypass करने के बजाय, हम Netlogon secure channel पर machine account credentials का उपयोग करके victim की असली session key प्राप्त करते हैं, फिर उसकी signing key derive करते हैं और ऑपरेशन को उसी तरह sign करते हैं जैसे victim करता।

पृष्ठभूमि

LDAP Switcheroo टूल और उसका writeup, Signed, Sealed, and Relayed, NTLM-style: Bypassing LDAP Signing Through Reauthentication, मूल LDAP signing bypass और उसके मूल कारण को कवर करते हैं। Keyeroo उस मामले के लिए follow-on है जिसे Switcheroo अक्टूबर 2026 patch के बाद अब नहीं संभालता।

यह कैसे काम करता है

विचार यह है कि DC से हमारे लिए उपयोगकर्ता की session key प्राप्त करवाई जाए।

1. जब victim SMB पर हमसे authenticate करता है, तो हम TargetInfo हटाकर एक CHALLENGE वापस भेजते हैं। NTLMv1-सक्षम victim NTLMv2 के बजाय NTLMv1-ESS (24-byte) AUTHENTICATE के साथ उत्तर देता है।
2. हम उस AUTHENTICATE को अपने नियंत्रण वाले machine account के माध्यम से, उसके Netlogon secure channel (NetrLogonSamLogonWithFlags) पर validate करते हैं। DC हमारे लिए इसे validate करता है और victim की base key लौटाता है। वहाँ से हम NTLMv1-ESS key-exchange key derive करते हैं और victim की exported session key decrypt करते हैं।
3. अब हमारे पास victim की session key है, और LDAP signing key उसी से derive होती है। हम victim का LDAP bind पूरा करते हैं, कनेक्शन को recovered session key से re-key करते हैं, और अपना ऑपरेशन (डिफ़ॉल्ट रूप से RBCD) victim की signing key से signed अपने अलग SASL record में भेजते हैं। हस्ताक्षर victim का है, इसलिए DC इसे signing आवश्यक होने पर भी स्वीकार करता है।

परिणाम coerced account के रूप में एक LDAP write है, चाहे वह RBCD हो, shadow credentials हो, या कोई भी attribute, बिना हमारे अपने किसी LDAP credential की आवश्यकता के। Keyeroo, Impacket के ntlmrelayx.py के चारों ओर एक wrapper है और इसे आपके लिए शुरू करता है।

पकड़ यह है कि यह केवल तभी काम करता है जब victim NTLMv1-ESS भेजता है, जिसका अर्थ है LmCompatibilityLevel 2 या उससे कम, या कोई पुराना stack। आधुनिक Windows डिफ़ॉल्ट रूप से NTLMv2 का उपयोग करता है, और Windows 11 और Server 2025 NTLMv1 को पूरी तरह हटा देते हैं, इसलिए यह एक legacy path है। जहाँ वह legacy अभी भी मौजूद है, वहाँ यह patched DC पर LDAP signing को पार कर जाता है।

आवश्यकताएँ

• एक attacker-नियंत्रित machine account जिसका password या NT hash आप जानते हैं, Netlogon secure channel (-oracle-machine) के लिए। डिफ़ॉल्ट MachineAccountQuota के अंतर्गत कोई भी domain उपयोगकर्ता एक बना सकता है।
• एक victim जो NTLMv1-ESS उत्सर्जित करता है — अर्थात् LmCompatibilityLevel <= 2 या कोई legacy source। डिफ़ॉल्ट रूप से आधुनिक Windows NTLMv2 उत्सर्जित करता है (और Windows 11 / Server 2025 NTLMv1 को पूरी तरह हटा देते हैं), इसलिए यह legacy-निर्भर path है।
• victim को SMB पर -listen-ip से authenticate करने के लिए coerced किया गया हो, और target object (जैसे उसका अपना RBCD attribute) लिखने के लिए authorized हो।

उपयोग

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

फिर दूसरे टर्मिनल से शिकार को -listen-ip की ओर मोड़ें।

• प्रारंभिक LDAP कनेक्शन अनाम होता है, जब तक आप लक्ष्य के आगे domain/user[:password]@ न लगाएँ (तब यह प्रमाणित होता है और read-back जाँच चलती है)।
• Oracle क्रेडेंशियल: -oracle-password <pw> या -oracle-hashes [LM]:NT।
• -oracle-dc-ip Netlogon सुरक्षित चैनल के लिए DC चुनता है (डिफ़ॉल्ट -dc-ip है)।
• पेलोड: -rbcd-sid <SID> (RBCD), -shadow-credentials (Key Credential), या -attribute के साथ -value/-value-hex।

Shadow Credentials (-shadow-credentials)

लक्ष्य के msDS-KeyCredentialLink में एक Key Credential जोड़ता है (LDAP add, इसलिए मौजूदा कुंजियाँ बनी रहती हैं) और एक PFX लिखता है जिसे आप 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

फिर लक्ष्य का NT हैश प्राप्त करें (इसके लिए forest PKINIT आवश्यक है, अर्थात् एक enterprise CA / KDC प्रमाणपत्र):

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

इस मोड के लिए विशिष्ट आवश्यकताएँ: पीड़ित को -modify-dn पर msDS-KeyCredentialLink लिखने के लिए अधिकृत होना चाहिए (self-write उन स्थितियों में काम करता है जहाँ पीड़ित अपनी ही ऑब्जेक्ट संपादित कर सकता है), और फ़ॉरेस्ट को PKINIT का समर्थन करना चाहिए। बाद में सफ़ाई करें, जैसे certipy-ad shadow clear -u <admin>@<domain> -account 'TARGET$'।

Switcheroo से संबंध

Switcheroo पीड़ित के Bind और ऑपरेशन को एक ही रिकॉर्ड में संयोजित करता है जिस पर हमलावर की सत्र कुंजी से हस्ताक्षर किए जाते हैं (अक्टूबर 2026 के LDAP पैच द्वारा निर्धारित)। इसके विपरीत, Keyeroo पीड़ित की सत्र कुंजी पुनर्प्राप्त करता है, इसलिए ऑपरेशन पीड़ित के रूप में एक सामान्य हस्ताक्षरित अनुरोध होता है — जो पैच किए गए, हस्ताक्षर-आवश्यक DC के विरुद्ध भी प्रभावी रहता है (बशर्ते पीड़ित NTLMv1-ESS-सक्षम हो)।