Defender for Identity: Detecting Lateral Movement and Kerberoasting in Hybrid AD | Defender for Identity وصيد Kerberoasting والحركة الجانبية في شبكتك الهجينة

Defender for Identity وصيد Kerberoasting والحركة الجانبية في شبكتك الهجينة

إزاي تمسك attacker بيتحرك من مكينة لمكينة في Active Directory قبل ما يوصل لـ Domain Admin.

---

المقدمة

لو عندك بيئة hybrid فيها on-prem AD متوصل بـ Entra ID، فاكر إن الحماية بتاعة الـ cloud كفاية؟ للأسف لا. أغلب الـ incidents الكبيرة اللي شوفتها في بيئات العملاء بتبدأ من مكينة عادية جوه الشبكة، الـ attacker بياخد foothold صغير، وبعدين يبدأ يعمل lateral movement بهدوء لغاية ما يوصل لـ Domain Controller. في الوقت ده، Conditional Access و MFA على الـ cloud ملهم مفعول لأن الهجوم كله شغال على الـ on-prem identity.

هنا بالضبط بييجي دور Defender for Identity (كان اسمه Azure ATP قبل كده). هو الـ sensor اللي شغال على الـ Domain Controllers نفسها، وبيراقب الـ traffic والـ authentication requests علشان يمسك حاجات مثل Kerberoasting و Pass-the-Hash و DCSync قبل ما توصل لـ Defender XDR كـ incident كامل. المقال ده هيمشيك خطوة خطوة إزاي تفهم الـ detections بتاعته، وإزاي تكتب KQL queries تساعدك تصيد نفس السلوكيات بنفسك.

💡 المتطلبات:
- Microsoft Defender for Identity license (جزء من Microsoft 365 E5 أو standalone add-on).
- Domain Controllers فيها Defender for Identity sensor متنصب عليها (أو Directory Service Account محدد لو استخدمت الطريقة القديمة sensorless).
- صلاحية Security Administrator أو Security Operator في Microsoft Defender XDR portal.
- Access لـ Advanced Hunting جوه Defender XDR علشان تشغل KQL queries.
- فهم أساسي لـ Kerberos authentication flow (TGT, TGS, SPN).

1. إزاي Kerberoasting بيحصل وإزاي Defender for Identity بيمسكه

Kerberoasting هو attack بسيط في المبدأ: أي authenticated user (حتى لو صلاحياته منخفضة) يقدر يطلب Kerberos service ticket (TGS) لأي service account عنده SPN مسجل. المشكلة إن الـ ticket ده بيكون مشفّر بـ hash بتاع الـ password الخاص بالـ service account، فالـ attacker يقدر ياخد التذكرة ويحاول يفك التشفير offline بدون ما يلمس الشبكة تاني.

الخطوة الأولى: الفرق بين الطلب الطبيعي والمشبوه

Defender for Identity بيبني profile سلوكي (behavioral baseline) لكل user وكل مكينة. لو حصل فجأة request لعدد كبير من TGS tickets لـ service accounts مختلفة في فترة قصيرة، أو الـ encryption type اللي مطلوب كان RC4 بدل AES (وده indicator كلاسيكي لأن الأدوات القديمة زي Rubeus بتفضل تطلب RC4 لأنه أسهل في الـ cracking)، الـ alert بيتفعل تلقائي باسم "Suspected Kerberoasting attack".

الخطوة الثانية: تأكيد الـ alert من Defender XDR

لما يوصلك الـ alert، افتح incident في Defender XDR portal وشوف الـ timeline. هتلاقي فيه اسم الـ user، المكينة اللي طلع منها الـ request، والـ service accounts المستهدفة. ده بيوفر عليك وقت كبير مقارنة بمراجعة Security Event logs يدويًا.

// KQL query على Advanced Hunting لصيد Kerberoasting patterns
IdentityLogonEvents
| where ActionType == "TGS Requested"
| where Protocol == "Kerberos"
| summarize TicketCount = count(), Accounts = make_set(TargetAccountDisplayName)
    by AccountName, DeviceName, bin(Timestamp, 10m)
| where TicketCount > 15
| order by TicketCount desc

الـ query ده بيدلك على أي حساب طلب أكتر من 15 service ticket في نافذة 10 دقايق، وده pattern غير طبيعي في أغلب البيئات العادية.

2. صيد Lateral Movement: Pass-the-Hash وPass-the-Ticket

بعد ما الـ attacker يفك الـ hash أو يحصل على credentials، الخطوة التالية طبيعيًا هي الـ lateral movement: يحاول يستخدم نفس الـ credentials أو الـ hash على مكينات تانية جوه الشبكة بدل ما يعرف الـ plaintext password.

1. Pass-the-Hash Detection

Defender for Identity بيلاحظ لو حصل NTLM authentication من مكينة معينة باستخدام hash مش متطابق مع الـ logon session pattern الطبيعي للـ user ده. الـ alert بيظهر باسم "Suspected identity theft (pass-the-hash)".

2. Pass-the-Ticket Detection

هنا الفرق إن الـ attacker بينقل Kerberos ticket كامل (بدل الـ hash) من مكينة لمكينة تانية. Defender for Identity بيقارن IP address وMachine identity المرتبطة بالـ ticket الأصلي مقابل المكينة اللي استخدمته، ولو فيه mismatch جغرافي أو زمني (يعني الـ ticket استخدم من مكينتين في وقت متقارب جدًا مش منطقي)، بيتفعل الـ alert.

// KQL query لتتبع نفس الـ ticket استخدم من أكتر من مكينة
IdentityLogonEvents
| where Protocol == "Kerberos"
| summarize Devices = make_set(DeviceName), IPs = make_set(IPAddress)
    by AccountName, bin(Timestamp, 5m)
| where array_length(Devices) > 1
| project Timestamp, AccountName, Devices, IPs

⚠️ تنويه: الـ query ده ممكن يرجع false positives لو عندك environments فيها jump servers أو RDS farms مشتركة، فلازم تعمل tuning حسب الـ baseline بتاع كل شبكة.

3. الفرق بين الـ Sensor وSensorless Mode

لسه فيه محتوى قديم على الإنترنت بيتكلم عن Defender for Identity standalone sensor اللي كان يتنصب على مكينة منفصلة ويعمل port mirroring. الطريقة دي deprecated دلوقتي والمايكروسوفت بتوصي بالـ sensor اللي بيتنصب مباشرة على الـ Domain Controller نفسه.

النوع	مكانه	حالته دلوقتي
Sensor on DC	مباشرة على Domain Controller	الطريقة الموصى بها حاليًا
Standalone Sensor	مكينة منفصلة مع port mirroring	Legacy، مش بتتغطي فيها كل الـ traffic الداخلي
Sensor on AD FS	سيرفرات AD FS	مطلوب لو عندك federation flow

✅ لو شغال بالـ sensor المباشر على الـ DC، هتلاقي coverage أعلى للـ authentication traffic لأنه شايف كل الـ requests من غير الاعتماد على port mirroring اللي ممكن يفوّت packets.

4. ربط الـ Alerts بـ Incidents في Defender XDR

الميزة الحقيقية إن Defender for Identity ملقيش لوحده، لكنه بيتربط تلقائيًا مع Defender for Endpoint وDefender for Office 365 جوه incident واحد في Defender XDR. يعني لو attacker بدأ بـ phishing email، بعدين عمل Kerberoasting، هتلاقي كل ده في timeline واحدة بدل ما تجمعه من consoles متفرقة.

// KQL query لربط الـ Kerberoasting alert بأي endpoint activity مرتبط
AlertInfo
| where Title has "Kerberoasting" or Title has "identity theft"
| join kind=inner (
    AlertEvidence
    | where EntityType == "Machine"
) on AlertId
| project AlertId, Title, DeviceName, Timestamp

مشاكل شائعة وحلولها

المشكلة	الحل
Alerts كتير false positive لـ Kerberoasting	راجع الـ baseline بتاع accounts زي service accounts اللي بيعملوا batch jobs، وأضفهم كـ exceptions في الـ configuration
الـ sensor مش شايف كل الـ DCs	اتأكد إن الـ sensor متنصب على كل DC في الـ forest، مش بس الـ primary واحد
Alert بيتأخر يظهر في Defender XDR	شيك على health status بتاع الـ sensor من Defender for Identity settings، ممكن يكون فيه connectivity issue للـ cloud service
Advanced Hunting مش بيرجع نتايج للـ Identity tables	تأكد إن الـ license بتاعك بتشمل Defender for Identity فعليًا، مش كل E5 licenses بتفعّله تلقائي

نصائح الأمان 🔐

• شغّل rotation دوري لـ passwords بتاعة service accounts اللي عندها SPN، ده بيقلل قيمة الـ hash المستخرج من Kerberoasting حتى لو حصل.
• استخدم gMSA (Group Managed Service Accounts) لأي service جديد، لأن الـ password فيها بيتغير تلقائي وده بيصعّب الـ offline cracking.
• راجع Lateral Movement Paths جوه Defender for Identity portal بشكل دوري، ده feature بيوريك أضعف نقطة بين مكينة عادية وDomain Admin.
• لا تعتمد على الـ detection وحده، اربطه بـ PIM على Entra ID علشان أي privileged access يبقى time-bound ومش دائم.
• اعمل tabletop exercise سنوي تحاكي فيه Kerberoasting scenario علشان تتأكد إن الـ SOC عندك فاهم يقرأ الـ alert صح.

الخلاصة

Defender for Identity مش أداة تحطها وتنساها، هي بتحتاج tuning مستمر وفهم للـ baseline بتاع بيئتك، لكنها من أقوى الطرق اللي تقدر تمسك بيها attacker وهو لسه في مرحلة الاستطلاع والحركة الجانبية قبل ما يوصل لـ Domain Admin أو يعمل DCSync.

أهم نقاط تفتكرها:

1. Kerberoasting بيتصيد من خلال patterns غير طبيعية في طلبات TGS، خصوصًا لو كانت RC4.
2. Lateral movement (Pass-the-Hash وPass-the-Ticket) بيحتاج ربط بين الـ device وIP وSession pattern.
3. استخدم الـ sensor المباشر على الـ DC مش الـ standalone القديم.
4. الـ KQL queries في Advanced Hunting بتوفر عليك وقت كبير في التحقيق مقارنة بمراجعة logs يدويًا.

إنت جربت Kerberoasting detection في بيئتك؟ شاركنا تجربتك أو أي false positive غريب واجهته في التعليقات.