Vectored Overloading PE Injection

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Oorsig van die tegniek

Vectored Overloading is a Windows PE injection primitive wat klassieke Module Overloading met Vectored Exception Handlers (VEHs) en hardware breakpoints saamvoeg. In plaas daarvan om LoadLibrary te patch of ’n eie loader te skryf, die aanvaller:

  1. Skep ’n SEC_IMAGE section wat deur ’n wettige DLL ondersteun word (bv. wmp.dll).
  2. Oorskryf die gemapte view met ’n volledig hergelokiseerde kwaadwillige PE, maar hou die section object wat na die onskadelike image op skyf wys.
  3. Registreer ’n VEH en programmeer debug registers sodat elke oproep na NtOpenSection, NtMapViewOfSection, en opsioneel NtClose ’n user-mode breakpoint veroorsaak.
  4. Roep LoadLibrary("amsi.dll") op (of enige ander onskadelike teiken). Wanneer die Windows loader daardie syscalls aanroep, slaag die VEH daarby in om die kernel-oorgang oor te slaan en die handles en basisadresse van die voorbereide kwaadwillige image terug te gee.

Omdat die loader steeds glo dit het die versoekte DLL gekarteer, sien tooling wat net na section backing files kyk wmp.dll, al bevat geheue nou die aanvaller se payload. Intussen word imports/TLS callbacks steeds deur die ware loader opgelos, wat die hoeveelheid pasgemaakte PE-parsing logika wat die aanvaller moet handhaaf beduidend verminder.

Fase 1 – Bou die vermomde section

  1. Create and map a section for the decoy DLL
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. Kopieer die kwaadwillige PE in daardie view section-vir-section, respekteer SizeOfRawData/VirtualSize en werk die protections daarna by (PAGE_EXECUTE_READ, PAGE_READWRITE, ens.).
  2. Pas relocations toe en los imports op presies soos ’n reflective loader sou doen. Omdat die view reeds as SEC_IMAGE gemap is, stem section alignments en guard pages ooreen met wat die Windows loader later verwag.
  3. Normaliseer die PE-header:
  • Indien die payload ’n EXE is, stel IMAGE_FILE_HEADER.Characteristics |= IMAGE_FILE_DLL en nul die entry point om te verhoed dat LdrpCallTlsInitializers in EXE-spesifieke stubs spring.
  • DLL payloads kan hul headers ongemoeid laat.

Op hierdie punt het die proses ’n RWX-vaardige view waarvan die backing object nog steeds wmp.dll is, maar die bytes in geheue is deur die aanvaller beheer.

Fase 2 – Kaap die loader met VEHs

  1. Registreer ’n VEH en aktieweer hardware breakpoints: programmeer Dr0 (of ’n ander debug register) met die adres van ntdll!NtOpenSection en stel DR7 sodat elke uitvoering STATUS_SINGLE_STEP veroorsaak. Herhaal later vir NtMapViewOfSection en opsioneel NtClose.
  2. Trigger DLL loading met LoadLibrary("amsi.dll"). LdrLoadDll sal uiteindelik NtOpenSection aanroep om die regte section handle te kry.
  3. VEH hook vir NtOpenSection:
  • Lokaliseer die stack-slot vir die [out] PHANDLE SectionHandle argument.
  • Skryf die vooraf geskepte DecoySection handle in daardie slot.
  • Advance RIP/EIP na die ret instruksie sodat die kernel nooit aangeroep word nie.
  • Heraktiveer die hardware breakpoint om volgende na NtMapViewOfSection te kyk.
  1. VEH hook vir NtMapViewOfSection:
  • Oorskryf die [out] PVOID *BaseAddress (en size/protection uitvoerparameters) met die adres van die reeds gemapte kwaadwillige view.
  • Slaan die syscall-lichaam oor soos tevore.
  1. (Opsioneel) VEH hook vir NtClose verifieer dat die fop section handle skoongemaak word, voorkom resource leaks en bied ’n finale sanity check.

Aangesien die syscalls nooit uitgevoer word nie, sien kernel callbacks (ETWti, minifilter, ens.) nie die verdagte NtOpenSection/NtMapViewOfSection gebeure nie, wat telemetry drasties verlaag. Vanuit die loader se oogpunt het alles geslaag en is amsi.dll in geheue, dus gaan dit voort met import/TLS-oplossing teenoor die aanvaller se bytes.

Fase 3 – Voer die payload uit

  • EXE payload: Die injector spring eenvoudig na die oorspronklike entry point sodra relocations gedoen is. Wanneer die loader dink dit sou DllMain oproep, voer die pasgemaakte kode in plaas daarvan die EXE-styl entry uit.
  • DLL payload / Node.js addon: Los die bedoelde export op en roep dit aan (Kidkadi gee ’n benoemde funksie aan JavaScript). Omdat die module reeds by LdrpModuleBaseAddressIndex geregistreer is, sien opvolg-lookup dit as die onskadelike DLL.

Wanneer dit met ’n Node.js native addon (.node lêer) gekombineer word, bly al die swaar Windows-internals werk buite die JavaScript-laag, wat die bedreigingsakteur help om dieselfde loader met baie verskillende obfuskeerde Node-wrappers te gebruik.

References

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks