Defender for Endpoint ASR Rules That Stop Ransomware Early | قواعد ASR في Defender for Endpoint اللي بتوقف الـ Ransomware قبل ما يبدأ
قواعد ASR في Defender for Endpoint اللي بتوقف الـ Ransomware قبل ما يبدأ
تجربة عملية مع Attack Surface Reduction rules، من التفعيل في Audit mode لحد الـ Enforcement، وإزاي تتابع النتيجة بـ KQL في Defender XDR.
المقدمة
حصلت معايا حادثة عند عميل، جهاز واحد فيه Excel macro مصاب حاول ينزل payload ويشغله عن طريق PowerShell، والقصة خلصت في ثواني لأن قاعدة ASR واحدة اسمها "Block all Office applications from creating child processes" كانت شغالة في Block mode. لو القاعدة دي متكانتش موجودة، كان الـ payload اتنفذ عادي وبدأ الانتشار الجانبي قبل ما أي حد يلاحظ حاجة. المشكلة إن كتير من الشركات بتدفع فلوس في Defender for Endpoint بس بتسيب الـ ASR rules في وضعها الافتراضي "Not configured"، يعني بيشتروا سيارة بأحدث نظام فرامل بس مش ضاغطين عليه. الـ ASR rules هي أرخص وأسرع طبقة حماية ممكن تقفلها النهارده، وبتوقف سلوكيات الـ Ransomware المعروفة قبل ما توصل لمرحلة الـ Encryption أصلا.
- Microsoft Defender for Endpoint Plan 1 على الأقل (الـ ASR rules متاحة من P1)
- أجهزة Windows 10/11 أو Windows Server مسجلة (Onboarded) على Defender for Endpoint
- Microsoft Defender Antivirus شغال بـ Real-time protection (مش شرط يكون Primary AV بس لازم يكون Active)
- صلاحيات Intune Administrator أو Security Administrator لنشر الـ Policies
- Access على Advanced Hunting في Defender XDR للمتابعة بـ KQL
ايه هي ASR rules أصلا وليه مهمة ضد الـ Ransomware
ASR rules هي مجموعة قواعد سلوكية جوه Defender for Endpoint بتقفل الطرق اللي الـ Malware عادة بتستخدمها عشان تنفذ نفسها، من غير ما تعتمد على Signature زي الـ Antivirus التقليدي. يعني بدل ما تستنى الملف يوصل ويتحلل، انت بتقفل السلوك نفسه: زي إن Word يفتح PowerShell، أو Script يشغل ملف Executable نازل من الإنترنت. أغلب هجمات الـ Ransomware بتمر بمرحلة "Initial access" عن طريق Phishing email فيه Office document، وبعدين مرحلة "Execution" عن طريق Macro أو Script، وده بالظبط اللي الـ ASR rules بتقطعه.
القواعد الأهم اللي لازم تفعلها ضد الـ Ransomware
مش كل الـ 16 قاعدة بنفس الأهمية. دي أهم القواعد اللي ليها علاقة مباشرة بسيناريوهات الـ Ransomware اللي شايفها في الميدان:
| القاعدة | GUID | بتقفل ايه |
|---|---|---|
| Block all Office applications from creating child processes | D4F940AB-401B-4EFC-AADC-AD5F3C50688A | Word/Excel يشغلوا cmd أو PowerShell |
| Block Office applications from injecting code into other processes | 75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84 | Process injection من الـ Macro |
| Block execution of potentially obfuscated scripts | 5BEB7EFE-FD9A-4556-801D-275E5FFC04CC | Scripts متشفرة أو Obfuscated بـ PowerShell/JS |
| Block JavaScript or VBScript from launching downloaded executable content | D3E037E1-3EB8-44C8-A917-57927947596D | Dropper stage بعد الـ Phishing |
| Use advanced protection against ransomware | C1DB55AB-C21A-4637-BB3F-A12568109D35 | Cloud-based check ضد Ransomware behaviors معروفة |
| Block credential stealing from lsass.exe | 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 | يمنع الانتشار الجانبي بعد الإصابة |
| Block process creations from PSExec and WMI commands | D1E49AAC-8F56-4280-B9BA-993A6D77406C | Lateral movement classic في ransomware campaigns |
التفعيل: من التجربة السريعة لحد الـ Production
1. تجربة سريعة بـ PowerShell على جهاز واحد
ده الشكل اللي بستخدمه عشان أختبر قاعدة معينة قبل ما أنشرها على نطاق واسع. الـ Action ممكن يكون Enabled (Block)، AuditMode، أو Disabled:
# تفعيل قاعدة في Audit mode الأول عشان تشوف تأثيرها من غير ما توقف حاجة فعلية
Add-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EFC-AADC-AD5F3C50688A `
-AttackSurfaceReductionRules_Actions AuditMode
# لما تتأكد إنها مش هتكسر حاجة، حولها لـ Block
Add-MpPreference -AttackSurfaceReductionRules_Ids D4F940AB-401B-4EFC-AADC-AD5F3C50688A `
-AttackSurfaceReductionRules_Actions Enabled
# عرض حالة كل الـ ASR rules على الجهاز
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
2. النشر الفعلي عن طريق Intune (Endpoint Security)
للـ Production، ماتعتمدش على PowerShell على كل جهاز، استخدم Intune Endpoint Security policy من نوع "Attack surface reduction rules". لو محتاج تعمل ده بـ Automation عن طريق Microsoft Graph:
POST https://graph.microsoft.com/beta/deviceManagement/intents
Content-Type: application/json
{
"displayName": "ASR Rules - Ransomware Protection",
"templateId": "e2c6c5e3-0000-0000-0000-000000000000",
"settingsDelta": [
{
"definitionId": "deviceConfiguration--windows10EndpointProtectionConfiguration_defenderAttackSurfaceReductionExcludedPaths",
"valueJson": "[]"
}
]
}
⚠️ الـ templateId بيختلف حسب الـ Tenant والـ Catalog version، الأسهل والأضمن إنك تعمل الـ Policy مرة من الـ Intune portal وبعدين تسحب نفس الـ JSON عن طريق GET وتستخدمه كـ Baseline للـ Automation بتاعتك.
3. المتابعة بـ KQL قبل وبعد الـ Enforcement
قبل ما تحول أي قاعدة من Audit لـ Block، شغل الاستعلام ده في Advanced Hunting عشان تشوف هل فيه Legitimate apps هتتأثر:
DeviceEvents | where Timestamp > ago(14d) | where ActionType startswith "Asr" | summarize Count = count() by ActionType, DeviceName, InitiatingProcessFileName | order by Count desc
وبعد التفعيل الفعلي في Block mode، الاستعلام ده بيوريك القواعد اللي فعلا وقفت هجمات:
DeviceEvents | where ActionType == "AsrRuleBlocked" | extend RuleId = tostring(AdditionalFields.RuleId) | summarize Blocks = count() by RuleId, DeviceName, bin(Timestamp, 1d) | order by Blocks desc
✅ لو شفت في اللوج إن قاعدة زي "Block Office applications from creating child processes" بتعمل Block على PowerShell طالع من Word في جهاز مستخدم عادي، ده مش False positive في الغالب، ده تحديدا السلوك اللي القاعدة اتعملت عشانه.
Audit mode ولا Block مباشرة؟
| الوضع | مناسب لـ | المخاطرة |
|---|---|---|
| Audit mode | بيئة جديدة، أول 2-4 أسابيع | مفيش حماية فعلية، بس بتجمع بيانات |
| Block mode | بعد التأكد من عدم وجود False positives | ممكن يوقف Legacy apps بتعتمد على macros |
| Warn mode | قواعد بتتفاعل معاها المستخدمين مباشرة | بيديله فرصة يـBypass لو محتاج فعلا |
مشاكل شائعة وحلولها
| المشكلة | الحل |
|---|---|
| قاعدة "Block Office apps from creating child processes" بتوقف Add-in شرعي بيستخدمه المحاسبين | ضيف الـ Process أو الـ Folder path في الـ Exclusions جوه نفس الـ Policy بدل ما تعطل القاعدة كلها |
| القاعدة شغالة Enabled بس مفيش أي Block ظاهر في Advanced Hunting | تأكد إن الجهاز فعلا Onboarded وإن Defender Antivirus هو الـ Active AV، لو فيه Third-party AV شغال كـ Primary، الـ ASR rules ممكن ماتشتغلش صح |
| الـ Policy متطبقة من Intune بس الحالة "Conflict" على الجهاز | فيه Policy تانية (GPO أو Configuration Profile قديم) بتحدد نفس القاعدة بقيمة مختلفة، لازم توحد المصدر |
| قاعدة "Use advanced protection against ransomware" مش بتظهر Blocks خالص | القاعدة دي بتعتمد على Cloud-delivered protection، تأكد إن الجهاز عنده Internet access للـ Microsoft cloud protection service |
نصائح الأمان 🔐
- ابدأ دايما بـ Audit mode لمدة أسبوعين على الأقل قبل أي Enforcement، خصوصا في بيئات فيها Legacy applications بتعتمد على macros.
- ماتفعلش كل الـ 16 قاعدة مرة واحدة، ركز على القواعد المرتبطة بالـ Ransomware الأول وبعدين وسع تدريجيا.
- ربط الـ ASR alerts بـ Automated investigation and response في Defender XDR بيقلل وقت الاستجابة بشكل كبير.
- استخدم Exclusions بحذر شديد، كل Exclusion هو ثقب محتمل، وثقه في الـ Documentation ليه اتضاف.
- راجع الـ ASR rules reports في Defender portal شهريا، مش مرة واحدة وخلاص، لأن السلوكيات بتتغير مع تحديثات الأنظمة والتطبيقات.
الخلاصة
الـ ASR rules مش ميزة إضافية، هي طبقة دفاع أساسية موجودة أصلا في الـ License اللي انت دافع فيه، والفرق بين تفعيلها وعدم تفعيلها ممكن يكون الفرق بين حادثة أمنية بسيطة اتوقفت في ثانية وبين انتشار Ransomware كامل في الشبكة. النقط الأساسية اللي لازم تاخدها معاك:
Comments
Post a Comment