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

Tip

Soek jy Windows 11 LFH heap shaping en VMware Workstation PVSCSI (vmware-vmx) escape techniques?

{{#ref}} vmware-workstation-pvscsi-lfh-escape.md {{#endref}}

Oorsig van die tegniek

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

  1. Skep ’n SEC_IMAGE section wat gesteun word deur ’n egte DLL (bv. wmp.dll).
  2. Oorskryf die gemapte view met ’n volledig gerelokeerde kwaadwillige PE, maar laat die section object steeds na die benigne 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") (of enige ander benigne teiken). Wanneer die Windows loader daardie syscalls aanroep, sla die VEH die kernoorgang oor en keer die handvatsels en basisadresse van die voorbereide kwaadwillige image terug.

Omdat die loader steeds dink dit het die versoekte DLL gemap, sien gereedskap 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 werklike loader opgelos, wat die hoeveelheid pasgemaakte PE-parsing logika wat die aanvaller moet bestuur aansienlik 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 na daardie view section vir section, hou rekening met SizeOfRawData/VirtualSize en werk beskermings daarna op (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 oor met wat die Windows loader later verwag.
  3. Normaliseer die PE-header:
  • As die payload ’n EXE is, stel IMAGE_FILE_HEADER.Characteristics |= IMAGE_FILE_DLL en nul die entry point om te voorkom dat LdrpCallTlsInitializers in EXE-spesifieke stubs spring.
  • DLL payloads kan hul headers ongemoeid laat.

Op hierdie stadium het die proses ’n RWX-geskikte view wat se backing object steeds wmp.dll is, maar die bytes in geheue is onder die aanvaller se beheer.

Fase 2 – Kaap die loader met VEHs

  1. Registreer ’n VEH en aktiveer 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 verkry.
  3. VEH hook vir NtOpenSection:
  • Lokalisereer die stack slot vir die [out] PHANDLE SectionHandle argument.
  • Skryf die vooraf geskepte DecoySection handle in daardie slot.
  • Beweeg RIP/EIP na die ret instruksie sodat die kernel nooit aangeroep word nie.
  • Her-aktiveer die hardware breakpoint om na NtMapViewOfSection te kyk volgende.
  1. VEH hook vir NtMapViewOfSection:
  • Oorskryf die [out] PVOID *BaseAddress (en grootte/beskerming outputs) met die adres van die reeds gemapte kwaadwillige view.
  • Sla die syscall-lichaam oor net soos voorheen.
  1. (Opsioneel) VEH hook vir NtClose verifieer dat die vals section handle skoongemaak word, wat resource leaks voorkom en ’n finale sanity check bied.

Omdat die syscalls nooit uitgevoer word nie, sien kern callbacks (ETWti, minifilter, ens.) nie die verdagte NtOpenSection/NtMapViewOfSection gebeure nie, wat telemetry drasties verlaag. Vanuit die loader se perspektief het alles geslaag en amsi.dll is in geheue, so dit gaan voort met import/TLS resolusie teen die aanvaller se bytes.

Fase 3 – Voer die payload uit

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

Wanneer dit saam met ’n Node.js native addon (.node file) gebruik word, bly al die Windows-internals swaar werk buite die JavaScript-laag, wat die dreigenaakter toelaat om dieselfde loader met baie verskillende obfusceerde 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