54e64e: 6e0ef3af — MSVC x64 XMM-loader with 2.8 MB encrypted .data payload

Executive Summary

A 2.8 MB PE32+ x64 GUI binary compiled with MSVC 14.0 (May 2026) that carries its real payload inside a 2.8 MB .data section. At runtime it decrypts wide-char strings and executable content using SSE2 word-wise arithmetic (paddw / pand) before jumping through an indirect thunk. No hardcoded C2, no resources, no signing, and a minimal CRT import table. This is a fourth distinct build morph under the 54e64e OpenCTI umbrella, unrelated to the previously documented null-padded dropper, UPX-packed sibling, or Go infostealer cluster.

What It Is

The binary is not packed in the conventional sense (no UPX, Themida, or custom packer magic), but the .data section is effectively an encrypted payload container. ^[binwalk.txt:1]

Build / RE

Toolchain & Layout

• Compiler: MSVC C++ x64, linker version 14.0. The exception directory uses standard AMD64 unwind info with __C_specific_handler. ^[pefile.txt:268]
• Runtime: MinGW-w64 CRT strings present ("Mingw-w64 runtime failure:", pseudo-relocation error strings), but the PE structure, linker version, and unwind data are MSVC-native. This is consistent with a MSVC-compiled binary statically linking a MinGW-w64 compatibility layer, or a MSVC object file linked with a mixed CRT. ^[strings.txt:64] ^[pefile.txt:268]
• Subsystem: Windows GUI (0x2), base address 0x140000000. ^[pefile.txt:65] ^[pefile.txt:52]
• ASLR/NX: Enabled (DYNAMIC_BASE, HIGH_ENTROPY_VA, NX_COMPAT). ^[pefile.txt:73]

Section Balance (Key Indicator)

^[pefile.txt:76]

The .data section dominates the binary. Its entropy (6.49) is below true-random (~7.8) but well above structured data, consistent with encrypted or strongly encoded content.

Import Table (Minimal CRT)

Only two DLLs are imported:

• msvcrt.dll — 31 functions covering memory, string, I/O, and exception handling.
• KERNEL32.dll — 11 functions: DeleteCriticalSection, EnterCriticalSection, GetLastError, InitializeCriticalSection, LeaveCriticalSection, SetUnhandledExceptionFilter, Sleep, TlsGetValue, VirtualProtect, VirtualQuery. ^[pefile.txt:268]

Notably absent: LoadLibraryA, GetProcAddress, CreateProcess, WinExec, URLDownloadToFile, InternetOpen, RegSetValue, or any networking APIs. Either the payload is fully self-contained after decryption, or it resolves APIs dynamically via VirtualProtect + shellcode injection.

Anti-Analysis

• No debug checks or VM-detection strings observed statically.
• No junk code or control-flow flattening in the decompiled stub.
• The primary anti-static measure is the absence of plaintext strings and APIs — everything lives in the encrypted .data blob.

Decompiled Behavior

Entry point (entry0 @ 0x140001140) Sets a global flag and calls fcn.140001160, the C-runtime initialiser. ^[r2:entry0]

fcn.140001160 Standard MSVC startup sequence: __initterm for C initialisers, __initterm for C++ constructors, _setusermatherr, _set_app_type, then jumps to the user main() equivalent at fcn.140003c20. ^[r2:fcn.140001160]

fcn.140003c20 — the payload loader This is the core behavior function. In pseudo-C:

1. Calls fcn.1400016c0 (TLS callback setup).
2. Enters a gated decryption loop controlled by byte flags at 0x1402bc521, 0x1402bc522, 0x1402bc523, 0x1402bc524.
3. Each loop body loads 128-bit chunks from .data into xmm0, performs paddw (packed word addition) with a hardcoded constant, then pand (bitwise AND) with a mask, writing the result back. ^[r2:fcn.140003c20]
4. The loop constants include word-wise addition of 0xcd (205) and 0xbf (191), masked with 0x00ff patterns. ^[r2:fcn.140003c20]
5. After decryption, it calls fcn.14000153f, which writes two 32-bit constants to .data (0x3b4ea807, 0xbc2f8b84) and invokes an indirect call through fcn.140001394. ^[r2:fcn.14000153f]
6. fcn.140001394 pops the return address, reads a key from .data, calls fcn.140009cf0 (trivial key generator: return arg1 - 0x173ceb4f), then calls fcn.140009fa0 (a hash/lookup routine with hardcoded constants 0x1756515c, 0x53abdeae), and finally jumps to the resolved address. ^[r2:fcn.140001394] ^[r2:fcn.140009ce0] ^[r2:fcn.140009fa0]
7. Later in fcn.140003c20, wide-char path construction appears: memset + wcscat + wcscpy operations on stack buffers, suggesting the decrypted payload contains Unicode file paths or registry keys. ^[r2:fcn.140003c20]

fcn.140001880 — PE pseudo-relocation handler Implements the MinGW-w64 pseudo-relocation protocol. Iterates over a relocation table in .data, uses VirtualProtect to make pages writable, applies 8/16/32/64-bit fixups, and restores page permissions. This is the mechanism that patches the decrypted payload in memory before execution. ^[r2:fcn.140001880]

How It Works (Narrative)

At launch, the stub runs standard MSVC C++ initialisation. It then enters a multi-pass decryption routine that transforms the 2.8 MB .data blob in-place using SSE2 word-wise arithmetic. Each pass is gated by a boolean flag in .bss, suggesting the decryption may be spread across multiple function calls or timer callbacks. After decryption, a pseudo-relocation pass fixes up RVAs inside the now-plaintext payload, VirtualProtect is used to remap permissions, and control transfers through an indirect thunk (fcn.140001394) that resolves the final entry point via a small internal hash table. The presence of wcscpy/wcscat on decrypted buffers implies the payload carries its own Unicode strings — filenames, registry keys, or URLs — that are only visible at runtime.

C2 Infrastructure

None observable statically. No hardcoded IP addresses, domains, URLs, mutex names, or named pipes appear in the import table or ASCII/Unicode string dumps. ^[strings.txt:1-53795]

The decrypted payload may contain C2 configuration, but the outer loader is agnostic. Until CAPE detonation is available (requires a Windows guest), C2 attribution is impossible.

Interesting Tidbits

• Recent compilation: Timestamp is 2026-05-22, making this one of the freshest samples in the corpus. ^[pefile.txt:34]
• Zero resource footprint: No icons, no manifests, no version info. Masquerade potential is low unless delivered as a document or archive. ^[pefile.txt:225]
• SSE2 as decryption primitive: The use of paddw/pand in a loop is unusual for commodity malware; it suggests the author is comfortable with SIMD intrinsics or compiler vectorisation. ^[r2:fcn.140003c20]
• Mixed CRT heritage: MSVC PE structure with MinGW-w64 error strings and pseudo-relocations. This can happen when a MSVC object is linked against a MinGW-w64 static CRT, or when the author intentionally transplanted MinGW relocation code into an MSVC build for portability. ^[strings.txt:64] ^[r2:fcn.140001880]
• fcn.140009ce0 is a nop-thunk: return arg1 - 0x173ceb4f. It is called repeatedly with different immediate arguments to generate what appear to be per-function decryption keys. This is a lightweight string/API encryption helper. ^[r2:fcn.140009ce0]

How To Mess With It (Homelab Replication)

Goal: Reproduce the SSE2 word-wise decryption loop in a minimal MSVC x64 console project.

1. Toolchain: Visual Studio 2022 (v143) or VS 2019 (v142), x64 Release.
2. Source skeleton:

#include <immintrin.h>
#include <cstdint>

void decrypt_payload(uint16_t* data, size_t len, __m128i addend, __m128i mask) {
    for (size_t i = 0; i < len / 8; i++) {
        __m128i chunk = _mm_loadu_si128((__m128i*)&data[i * 8]);
        chunk = _mm_add_epi16(chunk, addend);
        chunk = _mm_and_si128(chunk, mask);
        _mm_storeu_si128((__m128i*)&data[i * 8], chunk);
    }
}

3. Verify: Compile with /arch:AVX or /arch:SSE2, disassemble with dumpbin /disasm, and confirm paddw + pand opcodes appear. The capa fingerprint should hit "uses SIMD instructions" and "encrypts data" if signatures are installed.
4. Payload staging: Encrypt a small PE or shellcode with the same SSE2 loop, embed it in .data, and jump to it after relocation. Compare the resulting binary's section layout to this sample.

Deployable Signatures

YARA Rule

rule XMM_Data_Loader_54e64e_Morph4
{
    meta:
        description = "MSVC x64 loader with large encrypted .data and SSE2 decryption"
        author = "pp-hermes"
        date = "2026-06-13"
        sha256 = "6e0ef3af90cd3e4a8d48b6e5fee62e5d88f69d007135314f9014e63cfb179e93"
        family = "54e64e"
    strings:
        $mingw_fail = "Mingw-w64 runtime failure:" ascii
        $pseudo_reloc = "Unknown pseudo relocation protocol version %d." ascii
        $matherr = "_matherr(): %s in %s(%g, %g)  (retval=%g)" ascii
        $paddw_pand = { 66 0f fd ?? ?? ?? ?? ?? 66 0f db ?? ?? ?? ?? ?? }
    condition:
        uint16(0) == 0x5A4D and
        uint32(uint32(0x3C)) == 0x00004550 and
        pe.machine == pe.MACHINE_AMD64 and
        pe.sections[2].name == ".data" and
        pe.sections[2].raw_data_size > 0x200000 and
        pe.number_of_imports <= 2 and
        3 of ($*) and
        pe.imports("KERNEL32.dll", "VirtualProtect")
}

Behavioral Fingerprint

This binary is a PE32+ x64 GUI executable with a minimal import table (msvcrt + KERNEL32 only). Its .data section exceeds 2 MB and has entropy between 6.0 and 6.8. On launch, the small .text stub (≈37 KB) executes SSE2 word-wise loops (paddw/pand) against .data buffers before jumping through an indirect thunk. No hardcoded network indicators, resources, or version info are present. The binary links MinGW-w64 pseudo-relocation code into an MSVC PE.

IOC List

Detection Signatures

References

• 54e64e — Entity page for the OpenCTI family umbrella.
• xmm-wordwise-payload-decryption — Technique page for the SSE2 decryption pattern.
• MalwareBazaar entry: 6e0ef3af90cd3e4a8d48b6e5fee62e5d88f69d007135314f9014e63cfb179e93
• OpenCTI labels: 54e64e, dropped-by-amadey, exe

Provenance

Analysis derived from:

• file.txt, pefile.txt, exiftool.json, rabin2-info.txt — static metadata
• strings.txt — full ASCII/Unicode string dump (53,795 lines)
• binwalk.txt — embedded artefact scan
• radare2 analysis (aa level 3) — function list, decompilation, disassembly
• pyghidra import attempted; analysis incomplete at time of writing
• dynamic-analysis.md — CAPE skipped (no Windows guest available)