Multi-payload dropper analysis: process-injection stealer bundled with dork-generator tool

Conclusion

Scope and Coverage

Examined artifacts

• Root upload: /workspace/2b52858a79dbb765572d7c497f0fcf2540ba68b80866ab3c08b29032385b92e3.bin

• Derived carved children from embedded PE headers under /workspace/analysis_carved/:
• carved_00298e20_014c.bin — SHA256 2106190991efc4291f4211dd54ddb7444e7bf51503842a1380a4a1d902d888b6
• carved_00300c20_8664.bin — SHA256 fbcbe26a6c1a6fc8b451d3aec8a91384a15124c8ca9931363bdd9ed174631b11
• carved_00be9550_8664.bin — SHA256 631491fd39ec560d77b9c0bf55c1fb8c144e2b7effd25fe52342ed99c052d4ee
• additional carved PEs at offsets 0x2d680, 0x601420, 0xba5950, and 0xf9f150

• Emulator outputs:
• root run: emulator_report_2b52858a_706a1c90/report.json
• child run: emulator_report_21061909_0e28a0b5/report.json

Coverage notes

• Root bintools coverage was incomplete: 99% of code bytes disassembled, 17 unattributed regions, 49 unresolved indirect branches.

• carved_00298e20_014c.bin coverage was also incomplete: 94% of code bytes disassembled.

• These gaps limit absence-based claims. I do not treat missing xrefs, missing imports-with-callers, or missing plaintext config strings as proof that behavior is absent.

• A Rust-specific unpack attempt on the root failed because auto-unpack required a key; this is a coverage limit, not evidence of safety.

Artifact Relationships and Behavioral Sequence

Root sample behavior

• FileAccess(Create) and FileAccess(Write) for:
• C:\Users\Michael\AppData\Roaming\bvcbghgf.exe
• C:\Users\Michael\AppData\Roaming\cxvezrfde.exe
• C:\Users\Michael\AppData\Roaming\wxcvxverd.exe
• C:\Users\Michael\AppData\Roaming\cvcxxxx.exe
• C:\Users\Michael\AppData\Roaming\dfssdfxx.exe

• ShellExec events for those same paths with verb open

• FileAccess(Create) plus ShellExec for Launcher.exe

• Exit: ExitProcess(0) This establishes a clear parent-child relationship: the uploaded root binary acts as a dropper/launcher for multiple embedded executables.

Child correlation

• Runtime dfssdfxx.exe → SHA256 2106190991ef... = /workspace/analysis_carved/carved_00298e20_014c.bin

• Runtime cvcxxxx.exe → SHA256 fbcbe26a6c1a... = /workspace/analysis_carved/carved_00300c20_8664.bin

• Runtime wxcvxverd.exe → SHA256 631491fd39ec... = /workspace/analysis_carved/carved_00be9550_8664.bin Two other runtime-dropped executables were only partially retained by the emulator:

• bvcbghgf.exe — pe_like=True, original size 2,537,365, retained 1,048,576, truncated

• cxvezrfde.exe — pe_like=True, original size 5,915,939, retained 1,048,576, truncated So the root definitely stages at least five PE payloads, and likely more functionality than the retained dynamic artifacts alone expose.

Key Findings

1. The root file is a multi-payload Windows dropper

• High-entropy root .data section: size 16,340,480 bytes, entropy about 7.80.

• Raw byte scan found multiple valid embedded MZ/PE images at offsets including 0x2d680, 0x298e20, 0x300c20, 0x601420, 0xba5950, 0xbe9550, and 0xf9f150.

• Emulation confirmed it writes several .exe files to Roaming AppData and launches them. Why it matters: This is direct staged-execution behavior, not a benign single-binary application model.

2. One dropped child has process-injection capability

• OpenProcess

• VirtualAllocEx

• WriteProcessMemory

• ReadProcessMemory

• GetThreadContext

• SetThreadContext

• ResumeThread

• CreateToolhelp32Snapshot

• Process32FirstW / Process32NextWWhy it matters: This import cluster is characteristic of remote-process manipulation/injection workflows. I am reporting this as capability evidence from the child payload, not as a fully observed executed injection path.

3. The same child has screenshot and collection capability

• GetDC, CreateCompatibleDC, CreateCompatibleBitmap, BitBlt

• GdipCreateBitmapFromHBITMAP, GdipSaveImageToFile, GdiplusStartupWhy it matters: This supports desktop/screen capture functionality.

4. The same child has network/C2 or exfiltration capability

• WinINet: InternetOpenA, InternetConnectA, HttpOpenRequestA, HttpSendRequestA, InternetReadFile, InternetWriteFile

• Winsock: socket, connect, send, recv, getaddrinfo, inet_ptonWhy it matters: The payload can communicate over HTTP and raw sockets. I did not recover specific endpoints, so this is capability evidence rather than a confirmed live C2 address.

5. The child also includes token and registry manipulation capability

• OpenProcessToken, DuplicateTokenEx, ImpersonateLoggedOnUser

• RegOpenKeyExA, RegGetValueA, RegSetValueExA, RegEnumValueAWhy it matters: These APIs support user-context manipulation and Windows configuration access.

6. The bundle contains offensive or abusive tooling beyond a single payload

• .NET analysis identifies assembly name Lazy Mans Dork Gen v0.2 and module Lazy Mans Dork Gen v0.2.exe.

• Strings include Dork.gen.resources, dorklist.txt, Your dorks will be saved in dorks.txt at this directory., GENERATE!, and search-term lists including login-related tokens. Why it matters: Even if this component is not itself malware, it is an offensive/abusive utility, which contradicts any benign-software packaging explanation for the set.

7. Additional dropped Rust payloads were present and launched

• /workspace/analysis_carved/carved_00300c20_8664.bin

• /workspace/analysis_carved/carved_00be9550_8664.binEvidence:

• Both are x64 PEs with Rust metadata (rustc/129f3b...\lib) and high-entropy .rdata regions.

• Their hashes matched runtime-dropped executables cvcxxxx.exe and wxcvxverd.exe.

• They import process enumeration APIs (CreateToolhelp32Snapshot, Process32FirstW, Process32NextW) and broad filesystem/environment primitives. Why it matters: The dropper launches multiple secondary components, not just one. I did not prove their full roles, but they are active child payloads in the execution chain.

Alternative Explanations and Contrary Evidence

Alternative considered: legitimate multi-component installer

• Strings indicate Inno Setup (This installation was built with Inno Setup.)

• The root imports many file/console/runtime APIs consistent with packaging logic.

Why that alternative does not adequately explain the observed behavior

• writes executables directly into Roaming AppData rather than an obvious application install path,

• uses randomized nonsense names for those executables,

• immediately launches each dropped executable, and

• includes at least one child with process injection, screenshot, and network capability. Those facts are materially inconsistent with a straightforward benign installer explanation.

Unknowns

• The exact family or operator intent of the whole bundle remains unresolved.

• Two runtime-dropped PE files (bvcbghgf.exe, cxvezrfde.exe) were only partially retained by the emulator; their full behavior is not fully characterized.

• Launcher.exe was created and executed, but I did not recover its full on-disk image from this run.

• No specific C2 endpoints, URLs, or exfiltration targets were recovered from plaintext strings. This is not a confident negative finding because some child payloads were truncated or opaque, and Rust string recovery on the root produced no validated decryption output.

Verdict Rationale

1. executed behavior from the root sample, and

2. code-backed capabilities from an executed child payload. Coverage gaps limit some absence-based statements, but they do not materially weaken the positive evidence supporting a malicious classification.