GhostLocker: AppLocker-आधारित EDR निष्क्रियकरण

परिचय

Fairy-Law पर मेरे लेख के बाद, जिसमें मैंने Endpoint Detection & Response (EDR) समाधानों को अक्षम करने के लिए कर्नेल मिटिगेशन का उपयोग किया था, diversenok ने बताया कि IFEO अपवाद (Image File Execution Options) तृतीय-पक्ष अनुप्रयोगों के लिए बहुत आक्रामक थे। इससे एक बेहतर दृष्टिकोण सामने आया: AppLocker के माध्यम से प्रशासकों के पास पहले से मौजूद वैध शक्ति का लाभ उठाना।

यह अवधारणा diversenok से प्रेरित थी, जिन्होंने बताया कि प्रशासक अपने सिस्टम पर किसी भी सॉफ़्टवेयर को वैध रूप से नियंत्रित कर सकते हैं। उस अंतर्दृष्टि से, मैंने AppLocker को एक देशी Windows नियंत्रण तंत्र के रूप में उपयोग करने वाली तकनीक विकसित की। यह शोध EDR नियंत्रण के लिए AppLocker के तकनीकी कार्यान्वयन की पड़ताल करता है, इसकी तुलना WDAC से करता है, और एक व्यावहारिक proof-of-concept टूल प्रस्तुत करता है।

---

AppLocker: अनुप्रयोग व्हाइटलिस्टिंग आर्किटेक्चर

AppLocker को Windows 7 के साथ पेश किया गया था और बाद में Windows 8.1, 10 (Enterprise) और Windows Server 2012/R2/2016+ में संवर्धित किया गया। यह एक एप्लिकेशन व्हाइटलिस्टिंग फ्रेमवर्क है जो प्रशासकों को सटीक रूप से परिभाषित करने की अनुमति देता है कि कौन से निष्पादन योग्य, स्क्रिप्ट या इंस्टॉलर विशिष्ट उपयोगकर्ताओं या समूहों के लिए निष्पादित हो सकते हैं।

आंतरिक आर्किटेक्चर (Windows Internals परिप्रेक्ष्य)

User-Mode और Kernel घटक:

AppIDSvc (Application Identity Service)

• LocalService खाते के अंतर्गत चलता है
• AppLocker पॉलिसी पथों में रजिस्ट्री परिवर्तनों की निगरानी करता है
• XML-आधारित नियम परिभाषाओं को बाइनरी SDDL (Security Descriptor Definition Language) में अनुवादित करता है
• DeviceIoControl के माध्यम से कर्नेल ड्राइवर को पॉलिसी अपडेट संचारित करता है

AppID.sys (Kernel Driver)

• कॉलबैक तंत्रों के माध्यम से प्रक्रिया निर्माण घटनाओं को इंटरसेप्ट करता है
• SeSrpAccessCheck का उपयोग करके नियम मूल्यांकन करता है
• वैकल्पिक रूप से DLL लोड की निगरानी करता है (प्रदर्शन कारणों से डिफ़ॉल्ट रूप से अक्षम)

स्पष्टीकरण:
जबकि AppID.sys कर्नेल मोड में नियम मूल्यांकन करता है, DLL प्रवर्तन स्वायत्त नहीं है।
कर्नेल ड्राइवर स्वयं DLL लोड की सक्रिय रूप से निगरानी नहीं करता है। इसके बजाय, user-mode घटकों को यह निर्धारित करने के लिए IOCTL के माध्यम से ड्राइवर से स्पष्ट रूप से पूछताछ करनी होती है कि DLL लोड की अनुमति है या नहीं।
परिणामस्वरूप, AppLocker DLL नियम प्रभावी रूप से एक क्लाइंट-साइड सुरक्षा तंत्र के रूप में कार्य करते हैं।

नियम प्रकार और प्रवर्तन

AppLocker दो प्राथमिक नियम श्रेणियों का समर्थन करता है:

Allow Rules: परिभाषित अनुप्रयोगों को निष्पादित करने की स्पष्ट अनुमति दें

Deny Rules: परिभाषित अनुप्रयोगों को निष्पादित करने से स्पष्ट रूप से रोकें

• Deny नियम हमेशा allow नियमों पर पूर्वता लेते हैं
• विशिष्ट शर्तों के लिए अपवाद शामिल कर सकते हैं
• उपयोगकर्ता और समूह-स्तरीय लक्ष्यीकरण का समर्थन करते हैं

नियम मानदंड (AppID विशेषताएँ):

• पथ-आधारित नियम: C:\Program Files\Security\*.exe
• हैश-आधारित नियम: SHA256 Authenticode हैश सत्यापन
• प्रकाशक नियम: डिजिटल हस्ताक्षर, संस्करण, उत्पाद नाम सत्यापन
• फ़ाइल विशेषता नियम: कंपनी का नाम, उत्पाद संस्करण, आदि

रजिस्ट्री भंडारण स्थान:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (XML पॉलिसी संग्रहण, स्थायी)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (SDDL बाइनरी प्रारूप, सक्रिय प्रवर्तन)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (प्रमाणपत्र कैश)

सेवा और 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 प्रक्रियाएँ सिस्टम रीबूट होने तक निष्पादित होती रहती हैं। यह एक मौलिक आर्किटेक्चरल बाधा है।

Kernel Driver टेलीमेट्री चेतावनी:

EDR यूज़रलैंड निष्पादन योग्य को ब्लॉक करने के बाद भी, कर्नेल ड्राइवर (*.sys) सक्रिय और कार्यशील रहते हैं। ये ड्राइवर निम्न कार्य जारी रखते हैं:

• कर्नेल कॉलबैक पंजीकृत करना (प्रक्रिया, थ्रेड, इमेज लोड, रजिस्ट्री)
• टेलीमेट्री डेटा एकत्र करना
• सिस्टम इवेंट की निगरानी करना

हालाँकि, व्यापक परीक्षण से पता चलता है कि यह टेलीमेट्री कार्यात्मक रूप से अप्रभावी हो जाती है। यूज़रलैंड विश्लेषण इंजन, सहसंबंध प्रणालियों और रिपोर्टिंग तंत्रों के बिना, कच्चे टेलीमेट्री डेटा को कार्रवाई योग्य डिटेक्शन में संसाधित नहीं किया जा सकता है। EDR समाधान निम्न के लिए यूज़रलैंड घटकों पर अत्यधिक निर्भर करते हैं:

• इवेंट सहसंबंध और व्यवहारिक विश्लेषण
• मशीन लर्निंग अनुमान
• अलर्ट निर्माण और प्रतिक्रिया ऑर्केस्ट्रेशन
• प्रबंधन कंसोल के साथ संचार

---

GhostLocker: Proof-of-Concept कार्यान्वयन

टूल अवलोकन

GhostLocker एक C++ कार्यान्वयन है जो EDR निष्पादन योग्य को ब्लॉक करने के लिए AppLocker पॉलिसी परिनियोजन को स्वचालित करता है।

तकनीकी कार्यान्वयन विश्लेषण

कार्यान्वयन प्रकार

GhostLocker दो कार्यान्वयन प्रकार प्रदान करता है:

main.cpp – डायनामिक एन्यूमरेशन संस्करण

यह संस्करण चल रही प्रक्रियाओं की गणना करता है और देशी APIs (NtQuerySystemInformation) का उपयोग करके उनके पूर्ण इमेज पथों को हल करता है।
फिर सटीक AppLocker deny नियम उत्पन्न करने के लिए हल किए गए निरपेक्ष पथों का उपयोग किया जाता है।

टूल सभी चल रही प्रक्रियाओं की गणना करने के लिए TH32CS_SNAPPROCESS के साथ CreateToolhelp32Snapshot का उपयोग करता है। यह केस-असंवेदनशील मिलान (_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\...
• AppLocker संगतता के लिए Win32 पथ प्रारूप में रूपांतरण की आवश्यकता होती है

पथ रूपांतरण तर्क:

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