hippamsascom: 630202e6 — Stripped x64 sibling, standard IAT, no masquerade identity

Executive Summary

A stripped MSVC x64 PE with a real (albeit minimal) import table rather than the zero-IAT + PEB-walking pattern seen in prior hippamsascom siblings. No VS_VERSIONINFO masquerade, no Authenticode signature, zero exports, and a random filename (vjsyqtvw.exe). The .data section entropy is 3.83 — no encrypted payload — suggesting this variant executes its logic directly rather than decrypting a second-stage PE. Import profile (clipboard, GDI screenshot, COM/OLE, computer name, username) aligns with a stealer/dropper hybrid rather than a pure self-loader. Co-labeled remusstealer and sivaph-shop by OpenCTI.

What It Is

• File: vjsyqtvw.exe, 232 KB, PE32+ x64, Windows GUI subsystem ^[file.txt]
• Compiler: MSVC linker 14.0 (VS 2022), compiled Sat Apr 25 19:27:16 2026 UTC ^[exiftool.json:15], ^[rabin2-info.txt]
• Sections: 4 (.text .rdata .data .reloc), no resource directory, no security directory, no debug directory ^[pefile.txt:157+]
• Signing: None (signed: false in rabin2, no security directory) ^[rabin2-info.txt]
• IAT: Standard (34 imports across 6 DLLs), not zero-IAT ^[pefile.txt:208+], ^[rabin2-info.txt]
• Exports: 0, stripped ^[rabin2-info.txt]
• Version info: None — no CompanyName, ProductName, Description, or OriginalFilename strings ^[strings.txt], ^[exiftool.json]
• OpenCTI labels: hippamsas-com, remusstealer, sivaph-shop, sunwukong ^[triage.json:7-13]

How It Works

This sample diverges from the hippamsascom cluster's established pattern in three ways:

1. Standard IAT instead of zero-IAT: A normal import table is present with 34 imports. The set is small and targeted: clipboard access (OpenClipboard, GetClipboardData, CloseClipboard), desktop/GDI screenshot primitives (GetDC, BitBlt, CreateCompatibleBitmap, GetDIBits), COM/OLE automation (CoCreateInstance, CoInitializeSecurity, OLEAUT32 by ordinal), and system enumeration (GetComputerNameA, GetComputerNameExA, GetUserNameA). This is functionally a stealer toolkit. ^[pefile.txt:208+]

2. No encrypted payload in .data: Prior siblings store a custom-cipher-encrypted PE in .data (entropy ~7.97). Here .data entropy is 3.83 — initialized but not high-entropy — indicating the primary logic resides in .text and .data holds plaintext data structures, not a wrapped second stage. ^[terminal:entropy_command]

3. No masquerade identity: All prior siblings carry fabricated VS_VERSIONINFO claiming a fake company (Emard LLC, Olson Group, Hane Group, Littel LLC). This sample has none. The filename is pure noise (vjsyqtvw.exe), suggesting deployment via a different infection vector (not social-engineering installer). ^[strings.txt]

Decompiled Behavior

Entry point entry0 at 0x140001d90 follows the same anti-analysis template as siblings but with reduced obfuscation surface:

• Hash-based API resolution gate: fcn.14002d560(0x89516899) and fcn.14002d560(0xe6aaa317) resolve two function pointers stored in .data globals at 0x140038d40 and 0x140038d48. The resolver reads gs:[0x78f5e2c8] (TEB/PEB access) and branches on a computed hash match. ^[r2:entry0]

• Junk math loop: A 32-bit loop with multiplication/addition/XOR against hardcoded constants (0x71d3c96a, 0xe2c3695, 0x6cd44c9) spins before the real gate check. The loop body has no side effects — pure delay / anti-emulation. ^[r2:entry0 @ loc_0x140001dd0]

• Buffer XOR decryption: At loc_0x140001ec0, a 22-word buffer (on-stack) is iterated with XOR against 0x6331 * index + 0x6331. This decrypts a function pointer or string table used downstream. ^[r2:entry0 @ loc_0x140001ec0]

• Conditional chain: After decryption, entry0 calls a sequence of boolean-returning functions: fcn.14002ce40 → fcn.1400296d0 → fcn.1400280d0 → fcn.140004bc0 → fcn.1400064a0. If any returns false, the binary exits via ExitProcess(0) ^[r2:entry0 @ 0x140001f47]. This is the same sandbox-gate pattern observed in siblings.

• fcn.1400280d0 — Control-flow flattening: A massive flattened dispatcher with nested switch/jump tables (33 cases, 116 cases, 225 cases), VariantClear, SysReAllocString, VirtualProtect-like allocation primitives, and shell-execute-style branching. This is the core payload orchestrator. ^[r2:fcn.1400280d0]

C2 Infrastructure

No static C2 indicators observed. No hardcoded IPs, domains, URLs, mutex names, or named pipes in strings or imports. C2 likely runtime-resolved via the COM/OLE or clipboard channels, or delivered in a configuration block decrypted at runtime. ^[strings.txt], ^[rabin2-info.txt]

Interesting Tidbits

• This is the first hippamsascom sibling with legitimate imports rather than PEB-walking resolution. The authors either compiled a different branch or stripped the export-obfuscation layer. ^[pefile.txt:208+]
• The .data section is only 3.83 entropy — if there's a second stage, it's not stored here. ^[terminal:entropy_command]
• OLEAUT32 imports by ordinal (SysReAllocString, SysStringLen, VariantCopy, VariantClear) suggest VARIANT/BSTR manipulation — consistent with COM-based data exfil or configuration parsing. ^[pefile.txt:296+]
• CoInitializeSecurity import is unusual for malware and suggests the binary prepares for COM server impersonation or DCOM interaction. ^[pefile.txt:236]
• rabin2 marks stripped: false (signed: false, static: false), yet ExifTool reports a warning parsing the data dictionary — the PE structure is slightly non-standard, possibly modified post-link. ^[exiftool.json:27]

How To Mess With It (Homelab Replication)

See the hippamsascom entity page for the full build recipe of the encrypted-payload siblings. This stripped variant is not easily replicable as a "dropper" because it lacks the encrypted payload stage. To approximate its capa-like fingerprint:

• Create a MSVC x64 Release console app in VS 2022 (v143 toolset, /O2, /GS-, /guard:cf-).
• Import only: kernel32.dll (GetComputerNameA, GetComputerNameExA), user32.dll (OpenClipboard, GetClipboardData, GetDC, BitBlt), gdi32.dll (CreateCompatibleBitmap, GetDIBits), ole32.dll (CoInitialize, CoCreateInstance), oleaut32.dll (SysAllocString, VariantClear).
• Add a small XOR-loop string decoder and a for loop with junk arithmetic.
• Strip exports and resources. No version info.
• Verification: rabin2 -I should show imports: 30-40, exports: 0, signed: false.

Deployable Signatures

YARA rule

rule Hippamsascom_Stripped_Stealer_Variant
{
    meta:
        description = "Hippamsascom stripped x64 sibling: standard minimal IAT, no masquerade, clipboard+screenshot+COM imports"
        author = "PacketPursuit"
        hash = "630202e6856062a04b0eb9bd7c5100339d4d007f1a0d25519ae86a7edc4a3e6c"
        date = "2026-05-31"
    strings:
        $s1 = "ole32.dll" ascii wide
        $s2 = "ADVAPI32.dll" ascii wide
        $s3 = "OLEAUT32.dll" ascii wide
        $s4 = "GetClipboardData" ascii wide
        $s5 = "BitBlt" ascii wide
        $s6 = "CoInitializeSecurity" ascii wide
        $s7 = "GetComputerNameExA" ascii wide
        $s8 = "CreateCompatibleBitmap" ascii wide
    condition:
        uint16(0) == 0x5A4D
        and uint32(uint32(0x3C)) == 0x00004550
        and uint16(uint32(0x3C)+0x18) == 0x20B   // PE32+
        and uint16(uint32(0x3C)+0x44) == 0x2     // Windows GUI
        and uint32(uint32(0x3C)+0x84) == 0       // Export directory VA = 0
        and uint32(uint32(0x3C)+0x88) != 0       // Import directory exists
        and uint32(uint32(0x3C)+0x90) == 0       // Resource directory VA = 0
        and 5 of ($s*)
}

Behavioral hunt query (Sigma — lightweight)

title: Hippamsascom Stripped Variant Process Creation
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '.exe'
        CommandLine|re: '^[a-z]{8,12}\.exe$'   # Pure-noise filename
    condition: selection
    # Further enrich with: imports ole32+user32+gdi32+advapi32, no version-info

IOC list

Behavioral fingerprint statement

This x64 PE has a minimal but legitimate import table (34 entries across 6 DLLs) including clipboard harvesting, GDI screenshot primitives, COM initialization, and system enumeration APIs. It has zero exports, no resource directory, and no embedded version information. On launch it performs hash-based API resolution via PEB/TEB reads, executes junk-math anti-emulation loops, XOR-decrypts an on-stack buffer, and chains through a sequence of boolean-returning gates before reaching a heavily control-flow-flattened dispatcher (33/116/225-case jump tables) that orchestrates payload behavior. Absence of a high-entropy .data section indicates the primary logic executes in-place rather than decrypting a second-stage PE.

Detection Signatures

• YARA: PE_File_Generic (generic) ^[yara.txt]. No family-specific YARA hit at this time — rule above closes the gap.
• capa: Skipped (signatures not installed). ^[capa.txt]

References

• MalwareBazaar / OpenCTI: artifact fd7802c3-3ad7-4f6d-8aa0-bcaeb8c7dc2f, labels hippamsas-com, remusstealer, sivaph-shop, sunwukong ^[triage.json]
• hippamsascom — entity page with build pattern and prior siblings
• sunwukong — related build cluster
• peb-walking-api-resolution — technique page (observed in siblings, not directly in this stripped variant)

Provenance

Analysis derived from:

• file.txt, exiftool.json, pefile.txt, strings.txt, rabin2-info.txt, triage.json — triage-fast artifacts (file type, PE headers, strings)
• binwalk.txt — no embedded payloads
• radare2 decompilation — entry point entry0 (0x140001d90) and callees fcn.14002d560, fcn.14002dba0, fcn.1400280d0, fcn.140004bc0, fcn.1400064a0 (r2 version not recorded)
• .data entropy computed via Python shannon_entropy() on section bytes 0x32800–0x37600
• No CAPE dynamic analysis (guest unavailable)