Vectored Overloading PE Injection

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

तकनीक का अवलोकन

Vectored Overloading एक Windows PE injection primitive है जो क्लासिक Module Overloading को Vectored Exception Handlers (VEHs) और hardware breakpoints के साथ जोड़ता है। LoadLibrary को patch करने या अपना loader लिखने की बजाय, विरोधी:

  1. Creates a SEC_IMAGE section backed by a legitimate DLL (e.g., wmp.dll).
  2. Overwrites the mapped view with a fully relocated malicious PE but keeps the section object pointing to the benign image on disk.
  3. Registers a VEH and programs debug registers so every call to NtOpenSection, NtMapViewOfSection, and optionally NtClose raises a user-mode breakpoint.
  4. Calls LoadLibrary("amsi.dll") (or any other benign target). When the Windows loader invokes those syscalls, the VEH skips the kernel transition and returns the handles and base addresses of the prepared malicious image.

क्योंकि loader अभी भी मानता है कि उसने अनुरोधित DLL को map किया है, ऐसे टूल्स जो केवल section backing files देखते हैं उन्हें wmp.dll दिखाई देता है जबकि memory में अब attacker का payload मौजूद है। इसी बीच, imports/TLS callbacks असली loader द्वारा अभी भी resolve होते हैं, जिससे विरोधी को बनाए रखने के लिए custom PE-parsing logic की मात्रा काफी कम हो जाती है।

चरण 1 – छद्म सेक्शन बनाना

  1. Decoy DLL के लिए एक section बनाना और map करना
NtCreateSection(&DecoySection, SECTION_ALL_ACCESS, NULL,
0, PAGE_READWRITE, SEC_IMAGE, L"\??\C:\\Windows\\System32\\wmp.dll");
NtMapViewOfSection(DecoySection, GetCurrentProcess(), &DecoyView, 0, 0,
NULL, &DecoySize, ViewShare, 0, PAGE_READWRITE);
  1. उस view में malicious PE को section-दर-section कॉपी करें, SizeOfRawData/VirtualSize का सम्मान करते हुए और बाद में protections अपडेट करें (PAGE_EXECUTE_READ, PAGE_READWRITE, आदि)।
  2. Relocations लागू करें और imports resolve करें ठीक वैसा ही जैसे एक reflective loader करेगा। क्योंकि view पहले से SEC_IMAGE के रूप में map है, section alignments और guard pages Windows loader की अपेक्षाओं से मेल खाते हैं।
  3. PE header को सामान्य करें:
  • यदि payload एक EXE है, तो IMAGE_FILE_HEADER.Characteristics |= IMAGE_FILE_DLL सेट करें और entry point को zero करें ताकि LdrpCallTlsInitializers EXE-विशिष्ट stubs में jump न करे।
  • DLL payloads अपने headers अपरिवर्तित रख सकते हैं।

इस बिंदु पर process के पास एक RWX-capable view होता है जिसका backing object अभी भी wmp.dll है, पर memory के bytes attacker-controlled होते हैं।

चरण 2 – VEHs के साथ loader को हाईजैक करना

  1. VEH रजिस्टर करें और hardware breakpoints सेट करें: ntdll!NtOpenSection के address के साथ Dr0 (या किसी अन्य debug register) प्रोग्राम करें और DR7 सेट करें ताकि प्रत्येक execution STATUS_SINGLE_STEP उठाए। बाद में वही प्रक्रिया NtMapViewOfSection और ऑप्शनल रूप से NtClose के लिए दोहराएं।
  2. DLL लोडिंग ट्रिगर करें LoadLibrary("amsi.dll") के साथ। LdrLoadDll अंततः NtOpenSection कॉल करेगा ताकि वास्तविक section handle प्राप्त किया जा सके।
  3. NtOpenSection के लिए VEH hook:
  • [out] PHANDLE SectionHandle argument के लिए stack slot का पता लगाएँ।
  • उस slot में पहले बनाए गए DecoySection handle को लिखें।
  • RIP/EIP को ret instruction पर आगे बढ़ाएँ ताकि kernel कभी कॉल न हो।
  • अगले चरण के लिए hardware breakpoint को NtMapViewOfSection देखने के लिए पुनः-संचालित करें।
  1. NtMapViewOfSection के लिए VEH hook:
  • [out] PVOID *BaseAddress (और size/protection आउटपुट) को पहले से mapped malicious view के address से overwrite करें।
  • syscall body को पहले की तरह skip करें।
  1. (वैकल्पिक) NtClose के लिए VEH hook यह सत्यापित करता है कि fake section handle cleanup हो गया है, resource leaks को रोकता है और एक अंतिम sanity check प्रदान करता है।

क्योंकि syscalls कभी execute नहीं होते, kernel callbacks (ETWti, minifilter, आदि) संदिग्ध NtOpenSection/NtMapViewOfSection events को observe नहीं करते, जिससे telemetry में भारी कमी आती है। loader के दृष्टिकोण से सब कुछ सफल रहा और amsi.dll memory में है, इसलिए यह attacker के bytes के खिलाफ import/TLS resolution के साथ आगे बढ़ता है।

चरण 3 – Payload चलाना

  • EXE payload: Injector relocations के पूरा होने के बाद मूल entry point पर कूदता है। जब loader सोचता है कि वह DllMain कॉल करेगा, तो custom code इसके बजाय EXE-style entry execute करता है।
  • DLL payload / Node.js addon: इच्छित export को resolve और call करें (Kidkadi JavaScript को एक named function एक्सपोज़ करता है)। क्योंकि module पहले से LdrpModuleBaseAddressIndex में register है, बाद की lookups इसे benign DLL के रूप में देखती हैं।

जब इसे एक Node.js native addon (.node file) के साथ जोड़ा जाता है, तो Windows-internals का सारा भारी काम JavaScript लेयर के बाहर रह जाता है, जिससे threat actor कई अलग-अलग obfuscated Node wrappers के साथ वही loader भेज सकता है।

References

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें