Current State
The Malpedia entry for win.idat_loader is currently an empty stub:
- No description
- No references
- No YARA rules
- No sample hashes
Meanwhile, Malpedia already lists "IDAT Loader" as a known alias of win.hijackloader.
Proposal
Two options, requesting maintainer guidance on preferred approach:
Option A: Formal Redirect/Merge into win.hijackloader
If the Malpedia maintainers consider IDAT Loader and HijackLoader to be the same family (as the current alias mapping implies), then win.idat_loader should be formally redirected to win.hijackloader to avoid confusion. The "IDAT Loader" alias is already listed under HijackLoader, so having a separate empty entry creates ambiguity for researchers querying the database.
Option B: Populate with IDAT-Specific Technical Details
If the families are considered distinct (some vendors do differentiate them), the win.idat_loader entry should be populated with IDAT-chunk-specific technical details that distinguish it from HijackLoader proper.
Key distinguishing characteristics from our analysis:
-
IDAT chunk payload storage — The loader specifically abuses PNG IDAT chunk structures to store XOR-encrypted payloads. The IDAT chunks contain encrypted data rather than valid zlib-compressed image data, but the PNG container passes superficial validation.
-
Modular PE architecture — The decrypted payload contains multiple concatenated PE files (observed: 8 PEs in a single blob), each serving a specific role:
tinystub — Minimal stub loadersLauncherLdr64 — Reflective PE loader / shellcode launchertinyutilitymodule — Anti-forensics module (exports _tiny_erase_)- Final payload (Stealc, Amadey, etc.)
-
DWORD XOR + LZNT1 — Decryption uses a DWORD XOR key from the payload header, followed by LZNT1 decompression via RtlDecompressBuffer.
-
Delivery via DLL sideloading — Typically arrives through trojanized MSI installers or DLL sideloading chains using legitimate signed binaries.
Supporting Analysis
Recommendation
Given that multiple vendor names exist for overlapping concepts (Rugmi, Penguish, IDAT Loader, HijackLoader), clarifying the taxonomy in Malpedia would benefit the community. At minimum, the empty stub should either be populated or formally merged to avoid dead entries in the database.
Current State
The Malpedia entry for
win.idat_loaderis currently an empty stub:Meanwhile, Malpedia already lists "IDAT Loader" as a known alias of
win.hijackloader.Proposal
Two options, requesting maintainer guidance on preferred approach:
Option A: Formal Redirect/Merge into win.hijackloader
If the Malpedia maintainers consider IDAT Loader and HijackLoader to be the same family (as the current alias mapping implies), then
win.idat_loadershould be formally redirected towin.hijackloaderto avoid confusion. The "IDAT Loader" alias is already listed under HijackLoader, so having a separate empty entry creates ambiguity for researchers querying the database.Option B: Populate with IDAT-Specific Technical Details
If the families are considered distinct (some vendors do differentiate them), the
win.idat_loaderentry should be populated with IDAT-chunk-specific technical details that distinguish it from HijackLoader proper.Key distinguishing characteristics from our analysis:
IDAT chunk payload storage — The loader specifically abuses PNG IDAT chunk structures to store XOR-encrypted payloads. The IDAT chunks contain encrypted data rather than valid zlib-compressed image data, but the PNG container passes superficial validation.
Modular PE architecture — The decrypted payload contains multiple concatenated PE files (observed: 8 PEs in a single blob), each serving a specific role:
tinystub— Minimal stub loadersLauncherLdr64— Reflective PE loader / shellcode launchertinyutilitymodule— Anti-forensics module (exports_tiny_erase_)DWORD XOR + LZNT1 — Decryption uses a DWORD XOR key from the payload header, followed by LZNT1 decompression via
RtlDecompressBuffer.Delivery via DLL sideloading — Typically arrives through trojanized MSI installers or DLL sideloading chains using legitimate signed binaries.
Supporting Analysis
win.rugmisubmissionRecommendation
Given that multiple vendor names exist for overlapping concepts (Rugmi, Penguish, IDAT Loader, HijackLoader), clarifying the taxonomy in Malpedia would benefit the community. At minimum, the empty stub should either be populated or formally merged to avoid dead entries in the database.