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>'
}