The kit

Most of the stealers I get handed are a main that does seven crimes in a row and a README that lies about half of them. Veneficus Mini is the other shape: a Windows x64 agent split into modules that actually know their jobs, with a host profile, concealment, a driver pool, harvest, persistence, a loopback relay, and a control plane sitting in separate files instead of one paste. The boundaries between those jobs are real.

The public tree is slightly broken on purpose. I am going to talk about the design.

Intended flow

1. Stager. Quiet the script engine, GET the image from the Worker, write a throwaway-named PE under the user temp directory, and start it hidden.
2. Score. Debugger, hypervisor, hardware, idle, timing, outbound. High means wipe and exit (self_destruct.rs). Medium means quiet mode and a host card only. Low means full operation.
3. Conceal. Syscall path. Stack-cover helper. Kernel hide. In-process script-scan and telemetry patches.
4. Driver pool. Try signed-but-vulnerable kernel images as a process-kill helper. This needs admin.
5. Harvest. Host card, browser logins, OS secret-store dump, clipboard swap.
6. Hold. WMI pulse, on-logon task, machine Run key. Loopback relay. Blank view listener. Control poll with jitter.

The dropper does not harvest, scoring happens before concealment, and concealment happens before the driver pool. The control loop is the thing that never returns, which is the type system's way of saying this process is supposed to live until someone burns it. Details live in the host decides.

The crate

Public Cargo.toml is a real manifest this time, aimed at a Rust crate named veneficus_mini 3.0, edition 2021, cross-compiled from Linux with MinGW-w64 to x86_64-pc-windows-gnu. The PE will be large, because it pulls Windows bindings, an async runtime (Tokio), an HTTPS client on a non-OpenSSL TLS stack (rustls), JSON, authenticated encryption, and an embedded SQLite reader for browser stores. Other current Rust stealers look like this on disk, and Veneficus is built to sit in that company.

Compile-time switches:

• default = byovd + dkom
• drop both for a thinner image: --no-default-features

Release intent: strip symbols, LTO, abort on panic, size-oriented optimization. Debug logging is compiled out of release. Each build bakes a random UUID-shaped string as IMPLANT_UUID (build.rs). That id is the implant's name toward the worker, and it is also the seed for the channel key: SHA-256 of the identity string, which means possession of the PE is possession of the key. See the wire.

Build inputs, under the names the tree uses: an obfuscated relay URL, a directory of signed-but-vulnerable .sys files, optional helper tools, a SOCKS-like bind, and a hidden-view port. drivers/ and tools/ ship empty. That is not an accident.

Orchestrator

The entry point is the orchestrator and nothing else. It decides whether theft, concealment, and the listeners run, in what order, and on which threads.

score the host
  HIGH  -> wipe and exit
  MED   -> quiet mode
  else  -> full

if not quiet:
  bring up concealment
  if byovd: kill endpoint-security PIDs via the pool

spawn work
  full: harvest, persist, loopback relay, hidden view, clipboard swap
  quiet: host card only

spin the control loop forever

Quiet mode is a product decision. A lot of kits just exit when they smell a lab; Veneficus can shrink instead, skipping concealment, the driver pool, persistence, the relay, the view, the clipper, and the secret-store dump, then sending a fingerprint and keeping the poll alive. That is how you keep a foothold on a host you do not trust yet. The CPUID hypervisor-present bit also fires on Hyper-V corporate endpoints. Details in phase 2.

Module map

The colours are in the diagram. The .rs files are the detail. I am going to talk about the design.

Source: main.rs. Next: the host decides. Before any of the theft, the host gets a vote.