ivancabrera02/hashsiphonवर्तमान उपयोगकर्ता के NetNTLMv2 हैश को HTTP प्रमाणीकरण प्रॉक्सी के माध्यम से निकालता है, सीधे SSPI कॉल से बचता है; v2 प्रक्रिया एट्रिब्यूशन को तोड़ने के लिए प्रमाणीकरण को BITS सेवा को सौंपता है।
HTTP-लेयर प्रमाणीकरण प्रॉक्सी के माध्यम से NTLM हैश निष्कर्षण, आक्रमणकारी प्रक्रिया से शून्य SSPI कॉल।
HashSiphon वर्तमान उपयोगकर्ता का NetNTLMv2 हैश निकालता है, सीधे SSPI API को कॉल करने के बजाय HTTP प्रमाणीकरण प्रवाह में हेरफेर करके। यह दो वेरिएंट प्रदान करता है: v1 उसी प्रक्रिया के भीतर .NET के HTTP स्टैक के माध्यम से NTLM प्रमाणीकरण को रूट करता है, और v2 प्रमाणीकरण को पूरी तरह से एक अलग PID में BITS सेवा (svchost.exe) को सौंपता है, जिससे प्रक्रिया-स्तरीय एट्रिब्यूशन पूरी तरह टूट जाता है।
प्रत्येक ज्ञात NTLM हैश स्व-निष्कर्षण उपकरण Internal Monologue, मैनुअल SSPI स्क्रिप्ट, और उनके व्युत्पन्न आक्रमणकारी की अपनी प्रक्रिया से AcquireCredentialsHandle → InitializeSecurityContext → AcceptSecurityContext को कॉल करते हैं। EDR इन SSPI फ़ंक्शन्स को हुक करते हैं और कॉल श्रृंखला को फ़्लैग करते हैं।
HashSiphon एक मौलिक रूप से भिन्न मार्ग अपनाता है:
| पहलू | Internal Monologue | HashSiphon v1 | HashSiphon v2 |
|---|---|---|---|
| आक्रमणकारी PID से SSPI कॉल | 4+ प्रत्यक्ष कॉल | 0 प्रत्यक्ष (WinHTTP आंतरिक रूप से कॉल करता है) | हमारे स्वामित्व वाली किसी भी प्रक्रिया में 0 |
| प्रमाणीकरण प्रक्रिया | आक्रमणकारी PID | आक्रमणकारी PID (HTTP स्टैक के माध्यम से) | svchost.exe (BITS सेवा) |
| सुरक्षा API आयात | SSPI DLL आयात आवश्यक | हमारे कोड में कोई नहीं | हमारे कोड में कोई नहीं |
| पहचान सतह | SSPI हुक, API कॉल पैटर्न | HTTP लूपबैक ट्रैफ़िक | BITS जॉब + लूपबैक ट्रैफ़िक |
| प्रक्रिया एट्रिब्यूशन | आक्रमणकारी PID | आक्रमणकारी PID | टूटा हुआ, पूरी तरह से भिन्न PID |
दोनों वेरिएंट एक ही मूल साझा करते हैं: 127.0.0.1 पर एक न्यूनतम TCP सर्वर जो NTLM चैलेंज-रिस्पॉन्स एक्सचेंज करने के लिए पर्याप्त HTTP बोलता है, एक नियंत्रित 8-बाइट चैलेंज के साथ ताकि कैप्चर किया गया हैश ऑफ़लाइन क्रैक करने योग्य हो।
HashSiphon.ps1)┌──────────────────────────┐
│ PowerShell (PID X) │
│ │
│ ┌────────────────────┐ │ ┌──────────────────────┐
│ │ TCP Server (C#) │◄─┼──────────┤ HttpWebRequest + │
│ │ Loopback :random │ │ HTTP │ DefaultCredentials │
│ │ │──┼──────────► │
│ │ 1. Send 401+NTLM │ │ NTLM │ WinHTTP auto-auths │
│ │ 2. Send Type 2 │ │ Type │ using current user's │
│ │ 3. Capture Type 3 │ │ 1/2/3 │ credentials │
│ │ 4. Extract hash │ │ │ │
│ └────────────────────┘ │ └──────────────────────┘
└──────────────────────────┘
Add-Type के माध्यम से एक C# TCP सर्वर संकलित करता है, 127.0.0.1:0 (OS-निर्धारित पोर्ट) पर बाइंड करता हैHttpWebRequest + CredentialCache.DefaultCredentials के साथ कनेक्ट करता हैWWW-Authenticate: NTLM के साथ HTTP 401 का जवाब देता हैट्रेड-ऑफ: WinHTTP आंतरिक रूप से उसी PID के भीतर SSPI को कॉल करता है, कोई प्रत्यक्ष आयात नहीं, लेकिन कॉल स्टैक अभी भी हम तक वापस ट्रेस होता है।
HashSiphonV2.ps1)┌─────────────────────┐ ┌───────────────────────────┐
│ PowerShell (PID X) │ │ svchost.exe (PID Y) │
│ │ │ BITS Service │
│ ┌───────────────┐ │ HTTP │ │
│ │ TCP Server │◄─┼─────────┤ BITS downloads from our │
│ │ (Background │ │ NTLM │ server, auto-authenticates│
│ │ Runspace) │──┼─────────► using job owner's creds │
│ └───────────────┘ │ Type │ │
│ │ 1/2/3 │ SSPI calls happen HERE, │
│ Start-BitsTransfer─┼────────►│ not in PID X │
│ (Trigger only) │ COM │ │
└─────────────────────┘ └───────────────────────────┘
│
└── Our process: TcpListener + Start-BitsTransfer
Zero SSPI. Zero security API imports.
Start-BitsTransfer http://127.0.0.1:<port>/hashsiphon.bin की ओर इशारा करते हुए एक डाउनलोड जॉब बनाता हैsvchost.exe, एक पूरी तरह से अलग PID) हमारे सर्वर से कनेक्ट करती हैHTTP 200 लौटाता है ताकि BITS ट्रांसफर को सफल मानेसफलता: हमारी प्रक्रिया कभी भी SSPI को कॉल नहीं करती, न सीधे, न WinHTTP के माध्यम से, बिल्कुल नहीं। संपूर्ण NTLM गणना svchost.exe में होती है। EDR SSPI हुक कॉल स्टैक को BITS सेवा प्रक्रिया में देखते हैं, हमारी में नहीं।
powershell -ExecutionPolicy Bypass -File HashSiphon.ps1
powershell -ExecutionPolicy Bypass -File HashSiphonV2.ps1
[*] Compiling HashSiphon v2 server...
[+] Server compiled
HashSiphon v2.0 - BITS Service Proxy Authentication
Auth by svchost.exe (BITS), not our process
[1] NTLM HTTP server ready on 127.0.0.1:52847
[2] Controlled challenge: 1122334455667788
[3] Triggering BITS transfer to our server...
[4] BITS transfer initiated
[+] User: ivan
[+] Domain: DESKTOP-ABCDEF
[+] NT response: 280 bytes (NTLMv2)
+----------------------------------------------------------+
| NetNTLMv2 HASH - Extracted via BITS service proxy! |
+----------------------------------------------------------+
| hashcat -m 5600 | john --format=netntlmv2 |
+----------------------------------------------------------+
ivan::DESKTOP-ABCDEF:1122334455667788:<NTProofStr>:<ClientBlob>
+----------------------------------------------------------+
| ATTRIBUTION ANALYSIS |
+----------------------------------------------------------+
| Our PID: 844 (PowerShell) |
| Auth by: BITS service (svchost.exe, PID 5500) |
| SSPI calls: Zero from PID 844 |
| Our APIs: TcpListener + Start-BitsTransfer only |
+----------------------------------------------------------+
यदि BITS विफल हो जाता है (सेवा अक्षम, मॉड्यूल अनुपलब्ध), तो v2 स्वचालित रूप से Invoke-WebRequest -UseDefaultCredentials के साथ एक चाइल्ड powershell.exe प्रक्रिया लॉन्च करने पर फ़ॉलबैक करता है। यह अभी भी PID पृथक्करण प्राप्त करता है, हालाँकि चाइल्ड प्रक्रिया BITS की तुलना में अधिक दृश्यमान है।