typeanalysisfamilyuniqfileconfidencelowcreated2026-06-15updated2026-06-15malware-familypecompilermingwpackerobfuscationevasiondownloadergcleaner
SHA-256: e79a525e7677dfa422e529c390adb02c6250edb0e22f0666e3e7302ff27d8348

uniqfile: e79a525e — MinGW-w64 x86 .rdata payload with XOR-loop reflective loader and "FileSync Manager" masquerade

Executive Summary

PE32 x86 (~632 KB) compiled with MinGW-w64 GCC 10.3.0. Masquerades as "FileSync Manager" by "Orion Iucs Digital". The outer binary is a reflective loader: it copies ~610 KB of encrypted data from .rdata into a freshly allocated heap, decrypts it with a simple byte-wise XOR/ADD rolling-key loop, fixes up PE relocations, and transfers control. No malicious imports or strings are visible in the outer PE — all threat logic lives inside the encrypted blob. Static-only analysis (CAPE skipped, no Windows guest). Co-labeled dropped-by-gcleaner.

What It Is

  • SHA-256: e79a525e7677dfa422e529c390adb02c6250edb0e22f0666e3e7302ff27d8348^[triage.json]
  • File: PE32 executable (GUI) Intel 80386, 9 sections, stripped to external PDB^[file.txt]
  • Size: 632 320 bytes^[triage.json]
  • Compiler: MinGW-w64 GCC 10.3.0 (tdm64-1) — .rdata contains 37 instances of GCC: (GNU) 10.3.0 and GCC: (tdm64-1) 10.3.0^[strings.txt:1213]
  • Linker: 2.36 (Major=0x2, Minor=0x24)^^[pefile.txt:46]
  • Timestamp: Wed May 20 19:09:43 2026 UTC (TimeDateStamp 0x6A0E06F7)^[pefile.txt:34] — built 6 days before triage.
  • Signed: No authenticode or self-signed certificate^[pefile.txt:27]
  • Masquerade: Version-info claims CompanyName: Orion Iucs Digital, ProductName: FileSync Manager, OriginalFilename: WorkerLauncherMS.exe, InternalName: worker_launcher. The FileDescription field contains Chinese characters (鐢ㄦ埛宸ュ叿 v2.8) alongside a French Translation (0x040c 0x04b0) — a fractured locale fingerprint suggesting either a copied legitimate binary or deliberate misdirection.^[pefile.txt:342-351]^[exiftool.json:36-42]
  • Resources: .rsrc holds three PNG icons (16×16, 24×24, 32×32), an XML compatibility manifest (Vista through Windows 10), and an RT_STRING table containing:
    • Network communication module^[pefile.txt:539]
    • lr9jwe48REucDSWlx9yImn^[pefile.txt:537]
    • 3pnceWYJTFbrO6wVkeQyZU8BQfhWhD2cIoQ^[pefile.txt:538]
  • Imports: Minimal surface — KERNEL32.dll (12 imports: heap, critical-section, sleep, virtual-protect) and msvcrt.dll (25 imports: memory, string, I/O, CRT init).^[pefile.txt:364-422] No WinInet, WinHTTP, WS2_32, or socket APIs in the IAT.

How It Works

The binary follows a classic "encrypted payload in .rdata + reflective loader" pattern, wrapped in a MinGW CRT startup.

Entry and CRT initialization

entry0 (0x4014b0) is the MinGW PE entry point. After standard GetStartupInfoA, TLS callback dispatch, _initterm, and command-line parsing, it calls fcn.004026d0 with the image base as argument.^[r2:entry0]

Loader orchestrator: fcn.0040155b

fcn.0040155b (0x40155b) performs four stages:

  1. Timing gate — calls clock(), then Sleep(0x3e8) (1 second), then clock() again. If the elapsed delta is ≤ 0x6b3 (1715 ms), it aborts.^[r2:fcn.0040155b] This is a crude anti-emulation / anti-sandbox check: emulators that fast-forward Sleep will fail the timing test.
  2. Stack probe — calls fcn.004025b0, a stack-probing helper that touches pages in 0x1000-byte decrements to ensure the large local buffer (0x95008 bytes) is committed.^[r2:fcn.004025b0]
  3. Payload staging — copies 0x95008 bytes (610,568 bytes, essentially the full .rdata section) from 0x404000 into a stack buffer, then creates a private heap (HeapCreate) of 0x10000000 bytes, allocates from it (HeapAlloc), copies the payload there, and zeroes the allocation with memset.^[r2:fcn.0040155b]
  4. Decryption & execution — calls fcn.00401520 with five arguments pushed on the stack. The parameters recovered from the decompilation are a buffer pointer, length 0x94fc0, initial key 0x3e, delta 3, and a reset threshold of 8.^[r2:fcn.0040155b] After decryption returns, the code performs an indirect call into the decrypted payload.

Decryption loop: fcn.00401520

fcn.00401520 (0x401520) is a compact byte-wise transform:

for (i = 0; i < len; i++) {
    buf[i] ^= key;
    key += delta;
    if (key >= limit) key = delta;
}

^[r2:fcn.00401520]

Because the decompilation stack-frame mapping may be slightly off, the exact live values of key, delta, and limit should be confirmed by breaking at 0x401520 in a debugger and reading the live stack. For static reproduction, the simplest approach is to dump the .rdata section and brute-force the three small constants against known plaintext heuristics (e.g., MZ header, PE\0\0, or English string frequency).

Runtime fixups: fcn.00401ae0

fcn.00401ae0 (0x401ae0) is called during startup and handles MinGW pseudo-relocations. It walks a relocation table at 0x49945c, resolves fixups against the image base (0x400000), and applies VirtualProtect to mark sections executable.^[r2:fcn.00401ae0] In this sample the same machinery is reused to fix up the decrypted payload before execution.

Decompiled Behavior

Address Role Observation
0x4014b0 entry0 MinGW CRT startup; dispatches TLS callbacks; calls fcn.004026d0 after init.^[r2:entry0]
0x4026d0 fcn.004026d0 Loader wrapper; passes image base to fcn.0040155b.^[r2:fcn.004026d0]
0x40155b fcn.0040155b Timing gate → stack probe → .rdata memcpy → heap alloc → decrypt → execute.^[r2:fcn.0040155b]
0x401520 fcn.00401520 Byte-wise XOR with rolling key; key increments by delta and resets on threshold.^[r2:fcn.00401520]
0x401ae0 fcn.00401ae0 Pseudo-relocation engine + VirtualProtect fixups for the decrypted payload.^[r2:fcn.00401ae0]
0x401f60 fcn.00401f60 Critical-section guarded callback iterator; standard MinGW atexit / onexit handler.^[r2:fcn.00401f60]
0x402200 fcn.00402200 PE section lookup helper (walks section table by VirtualAddress).^[r2:fcn.00402200]

C2 Infrastructure

None recoverable statically. The IAT contains only KERNEL32.dll and msvcrt.dll. No hardcoded URLs, IPs, domains, or socket APIs are present in the outer PE. The RT_STRING resource contains "Network communication module" and two long alphanumeric strings (lr9jwe48REucDSWlx9yImn, 3pnceWYJTFbrO6wVkeQyZU8BQfhWhD2cIoQ) that may be seed values, API keys, or C2 identifiers for the inner payload, but they are not directly usable as network IOCs without decryption.

C2 is either:

  • Runtime-resolved (DGA, config downloaded, or hardcoded inside the encrypted payload), or
  • Delivered as a second stage after the primary payload executes.

Interesting Tidbits

  • Fresh build, short fuse: Compiled 2026-05-20 19:09 UTC, triaged 2026-05-26 04:57 UTC — a six-day turnaround suggests rapid deployment or A/B testing.^[pefile.txt:34]^[triage.json]
  • Fractured locale: Version info claims LangID: 040c04b0 (French + Unicode), but FileDescription is Chinese (鐢ㄦ埛宸ュ叿). This is not a coherent locale stack; it is either a copy-paste from a legitimate Chinese utility or deliberate noise.^[pefile.txt:340]^[exiftool.json:37]
  • Binwalk false positive: Binwalk reports mcrypt 2.5 encrypted data, algorithm: "nitializeCriticalSection" at offset 0x975F7. This is a magic-match false positive — the string "InitializeCriticalSection" (a KERNEL32 import) overlaps with binwalk's mcrypt signature.^[binwalk.txt]
  • No anti-debug beyond timing: No IsDebuggerPresent, CheckRemoteDebuggerPresent, CPUID hypervisor checks, or process blacklisting in the outer binary. The only evasion is the Sleep + clock() gate.^[r2:fcn.0040155b]
  • TLS callbacks present but benign: The TLS directory lists two callbacks (entry1 at 0x4017e0, entry2 at 0x401790). Their disassembly shows standard MinGW TLS initialization, not anti-debug logic.^[pefile.txt:641-648]

How To Mess With It (Homelab Replication)

Toolchain

  • MinGW-w64 GCC 10.3.0 (tdm64-1) or any recent MinGW-w64 release
  • Target: i686-w64-mingw32 (PE32), -mwindows for GUI subsystem
  • Flags: -O2 -s (strip), -Wl,--strip-all

Replicating the loader skeleton

The outer binary is essentially a custom PE loader. To reproduce the capa-like fingerprint:

  1. Embed a second PE or shellcode as a const unsigned char payload[] in .rdata.
  2. Write a loader that:
    • Calls clock(); Sleep(1000); clock(); and aborts if delta < 1700 ms.
    • memcpy the payload from .rdata to a HeapAlloc'd buffer.
    • Applies a rolling-XOR decryption loop.
    • Walks the payload's relocation table and calls VirtualProtect on each section.
    • Jumps to the payload entry point.
  3. Compile with MinGW, strip symbols, and add a VS_VERSIONINFO resource with fake vendor strings.

Verification

  • Run strings -n 8 on the reproducer and confirm it shows only CRT strings and the fake version info — no payload strings.
  • Dump the .rdata section and confirm the embedded payload is opaque (high entropy).

What you'll learn

This demonstrates how a minimal IAT + encrypted .rdata payload defeats static string extraction and import-based detection. The threat logic is entirely in the inner payload; the outer binary is just a delivery envelope.

Deployable Signatures

YARA rule

rule Uniqfile_Mingw_Rdata_Reflective_Loader {
    meta:
        description = "MinGW-w64 PE32 with encrypted .rdata reflective loader and Orion Iucs Digital masquerade"
        author = "triage-agent"
        date = "2026-06-15"
        sha256 = "e79a525e7677dfa422e529c390adb02c6250edb0e22f0666e3e7302ff27d8348"
    strings:
        $gcc1 = "GCC: (GNU) 10.3.0" ascii
        $gcc2 = "GCC: (tdm64-1) 10.3.0" ascii
        $mingw_err1 = "Mingw-w64 runtime failure:" ascii
        $mingw_err2 = "Unknown pseudo relocation protocol version %d." ascii
        $company = "Orion Iucs Digital" wide
        $product = "FileSync Manager" wide
        $origfile = "WorkerLauncherMS.exe" wide
        $internal = "worker_launcher" wide
        $netmod = "Network communication module" wide
    condition:
        uint16(0) == 0x5A4D and
        uint32(uint32(0x3C)) == 0x00004550 and
        pe.number_of_sections == 9 and
        pe.imports("KERNEL32.dll", "HeapCreate") and
        pe.imports("KERNEL32.dll", "VirtualProtect") and
        pe.imports("msvcrt.dll", "memcpy") and
        pe.imports("msvcrt.dll", "clock") and
        filesize > 600KB and filesize < 700KB and
        2 of ($gcc*) and
        2 of ($mingw_err*) and
        2 of ($company, $product, $origfile, $internal) and
        $netmod
}

Behavioral hunt query (KQL-style)

ProcessCreationEvent
| where FileName =~ "WorkerLauncherMS.exe" or InternalName =~ "worker_launcher"
| where ImageSize between (600KB .. 700KB)
| where CommandLine == "" or isnull(CommandLine)
| where ParentProcessName in~ ("gcleaner.exe", "GCleaner.exe", "setup.exe", "installer.exe")
| summarize count() by ComputerName, SHA256, FileName

IOC list

Type Value Notes
SHA-256 e79a525e7677dfa422e529c390adb02c6250edb0e22f0666e3e7302ff27d8348 Outer loader
OriginalFilename WorkerLauncherMS.exe Version-info masquerade
InternalName worker_launcher
CompanyName Orion Iucs Digital Fake vendor
ProductName FileSync Manager Fake product
FileDescription 鐢ㄦ埛宸ュ叿 v2.8 Chinese text
PE Timestamp 2026-05-20 19:09:43 UTC Fresh build
.rdata size ~0x95000 bytes (~610 KB) Encrypted payload
Resource strings lr9jwe48REucDSWlx9yImn, 3pnceWYJTFbrO6wVkeQyZU8BQfhWhD2cIoQ Possible inner-payload seeds

Behavioral fingerprint statement

This binary is a MinGW-w64 compiled PE32 GUI executable with a minimal IAT (KERNEL32 + msvcrt only). On launch it performs a 1-second Sleep timing gate, then allocates a large private heap, copies its own .rdata section into it, decrypts the buffer with a byte-wise rolling-XOR loop, applies PE relocations via VirtualProtect, and jumps to the decrypted code. No network APIs are imported by the outer binary; all C2 behavior is deferred to the inner payload. The binary carries fabricated version info claiming "Orion Iucs Digital / FileSync Manager" and embeds three PNG icon resources plus an RT_STRING table containing "Network communication module".

Detection Signatures

capa: Not available — capa signatures were missing at analysis time (Using default signature path, but it doesn't exist).^[capa.txt] No static capability mapping was produced. If re-run with a current capa rule set, expected hits would include:

  • allocate memory (HeapCreate/HeapAlloc)
  • delay execution (Sleep)
  • check time (clock)
  • decrypt data (rolling XOR loop)
  • load PE (reflective execution of decrypted .rdata)

References

  • uniqfile — umbrella entity page (heterogeneous build morphs under OpenCTI label uniq.file)
  • gcleaner — distribution infrastructure that drops this sample
  • version-info-masquerade — technique page for fake vendor identity in PE resources
  • OpenCTI labels: uniq.file, dropped-by-gcleaner, exe, malware-bazaar, u
  • MalwareBazaar tag: u (shorthand for uniq.file in this corpus)

Provenance

  • Static inputs: file.txt, strings.txt, floss.txt (floss invocation failed — wrong CLI args), capa.txt (capa failed — missing signatures), binwalk.txt, rabin2-info.txt, pefile.txt, exiftool.json, metadata.json, triage.json, ssdeep.txt, tlsh.txt, yara.txt
  • Dynamic: dynamic-analysis.md — CAPE skipped, no Windows guest available.
  • radare2 (level-2 analysis): entry0, fcn.0040155b, fcn.00401520, fcn.00401ae0, fcn.004026d0, fcn.00401f60, fcn.00402200 decompiled via pdc.
  • pyghidra: binary imported (e79a525e...bin-46cdb3) but auto-analysis was still queued at report time; metadata confirmed MinGW-w64 compiler ID.