54e64e: de601a8a — MSVC 14.44 reflective loader, Google Drive staging, custom Base85 decoder

Executive Summary

MSVC C++ x64 reflective loader (10.5 KB) with minimal IAT, runtime API resolution via GetModuleHandleW/GetProcAddress, HTTPS payload fetch from Google Drive (drive.usercontent.google.com), custom printable-ASCII decoder, and process-creation APIs with extended attributes. Tenth confirmed build morph under the 54e64e umbrella. Static-only (CAPE skipped — no Windows guest).

What It Is

• File: PE32+ x64 GUI, 10,752 bytes, MSVC 14.44 (VS 2022 17.x), build timestamp 2026-03-31 15:39:36 UTC ^[file.txt] ^[pefile.txt:38] ^[exiftool.json:15-18]
• Sections: 5 standard sections (.text, .rdata, .data, .pdata, .rsrc), no packing, no entropy anomalies ^[pefile.txt:79-179] ^[binwalk.txt]
• Signing: Unsigned ^[rabin2-info.txt:27]
• IAT: Minimal — 6 KERNEL32 imports only (GetModuleHandleW, GetProcAddress, LoadLibraryW, VirtualAlloc, VirtualFree, ExitProcess) ^[pefile.txt:242-247]
• Rich header: Linker1400, Cvtres1400, Utc1900_C, Masm1400 — consistent with VS 2022 v143 toolset ^[rabin2-info.txt:Product lines]
• Debug: IMAGE_DEBUG_TYPE_POGO at 0x3490, matching compile timestamp; binary is not stripped ^[pefile.txt:291-302]

How It Works

Entry point (entry0 @ 0x1400011e8) delegates to fcn.1400010b4, which drives the full infection chain:

1. Runtime API resolution (fcn.1400011fc): Loads kernel32.dll, winhttp.dll, shell32.dll, ole32.dll by name and resolves ~30 API pointers into writable .data slots (0x140004020–0x140004120) using direct GetModuleHandleW → GetProcAddress. Not PEB-walking. ^[r2:fcn.1400011fc]
2. HTTPS payload fetch (fcn.140001544): WinHttpOpen → WinHttpConnect → WinHttpOpenRequest → WinHttpSendRequest → WinHttpReceiveResponse → WinHttpReadData. Primary C2 is Google Drive; fallback IP used on failure. ^[r2:fcn.140001544] ^[strings.txt:15-16]
3. Memory staging (fcn.140001914): VirtualAlloc(0, 0x18000, MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE) followed by expansion to 0x235000 (~2.3 MB). Reads HTTP payload into the first buffer, decodes it, then copies to the larger staging region. ^[r2:fcn.140001914]
4. Custom decoder (section..text @ 0x140001000): Processes downloaded printable-ASCII data through range checks (0x20–0x7E), building a 16-bit word array. Special-case mappings observed: 'J' → 0x30, 'K' → 0x2e. Structurally resembles a Base85 (Z85) 5-to-4 byte decoder. ^[r2:section..text]
5. Optimized memory ops (fcn.140001b00, fcn.140001ec0): memset and memcpy implementations use AVX2 (vmovdqu, vmovntdq, vzeroupper) with switch-case size dispatch (1–32 bytes, plus 256-byte blocks). Unusual optimization for a 10 KB malware stub. ^[r2:fcn.140001b00] ^[r2:fcn.140001ec0]
6. Process creation surface: Resolved APIs include CreateProcessW, InitializeProcThreadAttributeList, UpdateProcThreadAttribute, DeleteProcThreadAttributeList, CreatePipe, PeekNamedPipe, ReadFile, WriteFile. The exact call site is not visible statically (indirect dispatch through resolved pointers), but the API set strongly suggests process creation with extended attributes and IPC pipe redirection. ^[strings.txt:17-24]

Decompiled Behavior

Entry (entry0 @ 0x1400011e8): Calls fcn.1400010b4 then ExitProcess(0). ^[r2:entry0]

Main orchestrator (fcn.1400010b4 @ 0x1400010b4): Zeroes a local buffer via fcn.140001b00, calls the API resolver, then calls the HTTP downloader (fcn.140001544) with the Google Drive URL and port 443. If the download succeeds, passes the buffer to fcn.14000171c (fallback downloader) with size 0x50. Finally calls a processing routine. ^[r2:fcn.1400010b4]

API resolver (fcn.1400011fc @ 0x1400011fc): Sequential DLL loading and GetProcAddress resolution. WinHTTP surface (11 APIs), Shell32 (SHGetFolderPathW), OLE32 (CoInitialize, CoCreateInstance). All pointers stored in .data globals. ^[r2:fcn.1400011fc]

HTTP downloader (fcn.140001544 @ 0x140001544): Full WinHTTP request lifecycle. Uses flag 0x3300 in WinHttpAddRequestHeaders. Sets WINHTTP_OPTION_SECURITY_FLAGS via WinHttpSetOption. Reads response into caller-allocated buffer. ^[r2:fcn.140001544]

Memory allocator / payload reader (fcn.140001914 @ 0x140001914): Two-stage VirtualAlloc. Reads data through WinHttpReadData into the first buffer, decodes via the custom decoder, then copies to the second staging buffer using the AVX2 memcpy. Frees the first buffer. ^[r2:fcn.140001914]

Custom decoder (section..text @ 0x140001000): Byte-by-byte character classification. Distinguishes printable-space characters, applies offset/subtraction masks, and writes 16-bit words to an output array. The mapping is not a standard Base64 or Z85 alphabet — it is a custom character-to-value table. ^[r2:section..text]

AVX2 memset (fcn.140001b00 @ 0x140001b00): Replicates a fill byte across r11 = 0x0101010101010101 * byte, then dispatches via nested switch-cases for sizes 1–15, 16–31, 32–255, and 256+. Uses vmovdqu for aligned stores and vmovntdq + sfence for large non-temporal stores. ^[r2:fcn.140001b00]

AVX2 memcpy (fcn.140001ec0 @ 0x140001ec0): Similar switch-case dispatch with rep movsb fallback for small copies, AVX2 vmovdqu for medium, and vmovntdq for large non-temporal copies. ^[r2:fcn.140001ec0]

C2 Infrastructure

No hardcoded User-Agent, no mutex names, no named pipes, no registry keys observed statically.

Interesting Tidbits

• Google Drive as C2 staging: Hardcoded Google Drive file ID (1YBVIDkZgygNfUU2rbJXXCYdrzay5rMdY) suggests the attacker uploaded a payload to a personal Drive account and shared it publicly. This is a cheap, high-availability staging layer that blends with benign HTTPS traffic and is difficult to block at the perimeter without breaking legitimate Google services. ^[strings.txt:15-16]
• Fallback direct IP: If Google Drive fails, the binary falls back to a bare IPv4 (158.94.209.95) with a simple query-string path. This two-tier staging (legitimate cloud + direct IP) is resilient against single-point takedown. ^[strings.txt:15-16]
• AVX2 in a 10 KB stub: Both memset and memcpy use AVX2 YMM registers with vzeroupper discipline and non-temporal stores for large blocks. This indicates the builder was compiled with /arch:AVX2 or equivalent, and the CRT intrinsics were not stripped out. Unusual for crimeware. ^[r2:fcn.140001b00] ^[r2:fcn.140001ec0]
• No version info, no icon, no .rsrc beyond manifest: The .rsrc section contains only a single RT_MANIFEST with asInvoker execution level. No VS_VERSIONINFO, no icon group, no masquerade — the binary relies entirely on its small size and Google Drive domain for evasion. ^[pefile.txt:251-288]
• POGO debug directory: The binary carries a IMAGE_DEBUG_TYPE_POGO entry (Profile Guided Optimization), confirming a Release build with PGO enabled — consistent with the aggressive inlining and AVX2 codegen observed. ^[pefile.txt:291-302]
• ProcThreadAttributeList without static call site: InitializeProcThreadAttributeList, UpdateProcThreadAttribute, and DeleteProcThreadAttributeList are resolved and stored in function-pointer slots, but the decompiler cannot trace their call site due to indirect dispatch. Their presence alongside CreateProcessW + CreatePipe strongly implies process creation with extended attributes (e.g., mitigation policies, parent PID spoofing, or block-DLL injection) and IPC redirection. ^[strings.txt:17-24]
• GOOS=windows, GOARCH=amd64? No — pure MSVC: Despite the 54e64e umbrella containing multiple Go morphs, this sample is unambiguously MSVC C++ (Utc1900_C in Rich header, lang: c from rabin2, standard PE32+ CRT sections). ^[rabin2-info.txt:17] ^[rabin2-info.txt:Product lines]

How To Mess With It (Homelab Replication)

Toolchain: Visual Studio 2022 (v143, 14.40+), x64 Release, /O2 or /Ox, /arch:AVX2 (inferred from YMM codegen).

Reproduction sketch:

1. Write a minimal Win32 PE in C++ that links only kernel32.lib.
2. At runtime, call LoadLibraryW(L"winhttp.dll") and GetProcAddress for the full WinHTTP surface.
3. Open an HTTPS request to drive.usercontent.google.com (or any HTTPS host).
4. Download a payload, decode it with a custom 5-to-4 printable-ASCII decoder.
5. Allocate RWX memory with VirtualAlloc, copy the decoded payload.
6. Resolve CreateProcessW, InitializeProcThreadAttributeList, UpdateProcThreadAttribute.
7. Create a STARTUPINFOEX structure, initialize the attribute list, set desired attributes (e.g., PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY), and call CreateProcessW.

Verification: Run capa <reproducer.exe> — should hit T1105 Ingress Tool Transfer and T1055 Process Injection if you implement process hollowing or extended-attribute process creation.

Deployable Signatures

YARA

rule PE54e64e_ReflectiveLoader_GDrive {
    meta:
        description = "54e64e MSVC reflective loader with Google Drive staging"
        author = "PacketPursuit"
        date = "2026-08-15"
        sha256 = "de601a8a3d45d818f6bd867f5bba33d576bc1d9d983511b66f2b22447dd5d8e4"
    strings:
        $gdrive = "drive.usercontent.google.com" ascii wide
        $dl_path = "/download?id=" ascii wide
        $winhttp1 = "WinHttpOpen" ascii
        $winhttp2 = "WinHttpConnect" ascii
        $winhttp3 = "WinHttpSendRequest" ascii
        $createproc = "CreateProcessW" ascii
        $init_attr = "InitializeProcThreadAttributeList" ascii
        $update_attr = "UpdateProcThreadAttribute" ascii
        $kernel32 = "GetModuleHandleW" ascii
        $fallback_ip = "158.94.209.95" ascii
    condition:
        uint16(0) == 0x5A4D and
        filesize < 20KB and
        $gdrive and $dl_path and
        2 of ($winhttp*) and
        $createproc and $init_attr and $update_attr and
        $kernel32
}

Sigma

title: 54e64e Reflective Loader Process Creation
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\de601a8a.exe'
    selection_network:
        CommandLine|contains:
            - 'drive.usercontent.google.com'
            - '158.94.209.95'
    condition: selection_parent or selection_network
falsepositives:
    - None expected for the IP indicator; Google Drive URL may appear in benign software updaters
level: high

IOC List

Behavioral Fingerprint

This binary launches with a 6-import IAT consisting solely of KERNEL32 functions. Within seconds it loads winhttp.dll, shell32.dll, and ole32.dll by name, resolving approximately 30 API pointers into global data slots via GetProcAddress. It immediately opens an HTTPS connection to drive.usercontent.google.com on port 443, downloads a payload using WinHttpSendRequest/WinHttpReadData, and allocates two sequential RWX memory regions (0x18000 bytes then 0x235000 bytes). The downloaded data is decoded via a custom printable-ASCII character-set routine before being copied into the larger staging buffer with AVX2-optimized memcpy. Resolved but not statically called APIs include CreateProcessW, InitializeProcThreadAttributeList, UpdateProcThreadAttribute, CreatePipe, PeekNamedPipe, ReadFile, and WriteFile — indicating the final stage is likely process creation with extended attributes and pipe-based IPC.

Detection Signatures

References

• 54e64e — Cluster entity page
• google-drive-payload-staging — Cross-family technique (not yet written)
• proc-thread-attribute-process-creation — Procedure page (not yet written)
• peb-walking-api-resolution — Related but different API resolution technique (this sample uses GetModuleHandleW/GetProcAddress, not PEB walking)
• MalwareBazaar / OpenCTI artifact 5f904781-7558-4450-9524-917c8df339e0

Provenance

• file.txt — file(1) v5.44
• pefile.txt — pefile 2023.2.7
• strings.txt — GNU strings
• rabin2-info.txt — radare2 5.9.8
• exiftool.json — ExifTool 12.76
• binwalk.txt — binwalk v2.3.4
• dynamic-analysis.md — CAPE status (skipped, no Windows guest)
• Radare2 analysis + decompilation (r2ghidra-dec) via MCP, level 3, 120 s timeout