StealC v2 Malware Enhances Stealth and Expands Data Theft Features

StealC is a widely used infostealer and malware downloader that first appeared in dark web marketplaces in early 2023. Its effectiveness and ease of deployment quickly made it popular on cybercrime forums, where access has been advertised for around $200 per month.

In March 2025, the developer released StealC version 2 (latest known version: v2.2.4), marking a major upgrade with a focus on stealth and versatility. This release introduced a streamlined JSON-based command-and-control protocol, expanded payload delivery options, and a redesigned web control panel with a built-in builder. Additional enhancements include multi-monitor screenshot capture, a unified file grabber supporting numerous applications, and server-side techniques to bypass certain credential protections. This makes StealC v2 significantly more covert and flexible than its predecessor.

In this blog, we offer a comprehensive analysis of StealC V2, detailing its development history, technical capabilities, MITRE ATT&CK mapping, known IOCs, and recommended defense strategies. By understanding how StealC V2 operates, defenders can better detect and mitigate its threats.

History, Origin, and Victimology of StealC InfoStealer Malware

Origins and Development

StealC was first observed in the wild around late 2022 and gained traction on dark web marketplaces by early 2023 [1]. It is written in C++ and is offered as Malware-as-a-Service (MaaS) by its developer. 

According to security researchers, the malware’s author (known by the handle “Plymouth” in underground forums) actively marketed StealC to cybercriminals, highlighting its broad stealing capabilities. Over 2023, StealC underwent continuous improvements and attracted a growing user base in the cybercriminal community. 

In early 2025, the developer announced the release of StealC v2 (sometimes stylized as stealc_v2), claiming a new codebase with enhanced features such as server-side decryption of stolen data and stronger encryption for network traffic. Interestingly, around the same time, the developer also attempted to sell a limited number of copies of the StealC v1 source code (five copies at $3000 each), perhaps to monetize the old version now that v2 was out. This suggests the author’s confidence in the new version and possibly an attempt to let others build on the older code while they focus on v2.

StealC Malware Sample Overview: File Metadata and Hashes

StealC is typically delivered as a Windows executable (PE32 or PE64 depending on version). The binary’s name can vary, as attackers often rename it to masquerade as benign software. 

In StealC v1 campaigns, filenames like StealC.exe or innocuous names were used, but StealC v2 binaries are built via an admin panel, meaning the file name and attributes can be customized per campaign. 

Figure 1. Admin panel of StealC infostealer malware

The packed StealC v2 samples observed are often protected with Themida packer and hover around a few hundred KB in size when unpacked. The malware does not carry any digital signature (it is unsigned) and relies on obfuscation for evasion rather than impersonating legitimate code signatures.

Victimology & Language Check for CIS Countries

StealC is sold as a commodity infostealer, meaning it is used by multiple independent threat actors across various campaigns. It does not target a specific industry or region per se – any Windows user can be a victim if they execute the malware. Common victims range from individual home users (whose personal passwords, cryptocurrency wallets, or gaming accounts might be stolen) to employees at organizations (where stolen browser and VPN credentials can facilitate further intrusions). 

In 2024, StealC was spread via malvertising and likely phishing emails or trojanized software downloads, indicating a broad targeting approach. However, there is a notable geographic origin clue: StealC contains checks to avoid infecting systems in certain regions. 

Specifically, StealC’s code includes a language check to exclude computers set to languages of the Commonwealth of Independent States (CIS). This is a common trait of malware developed by Russian or Eastern European actors, to avoid drawing law enforcement attention to local victims. 

This section likely retrieves the language ID or locale identifier (LCID) of the system using the function qword_7FF72B904E10().

Specifically, StealC’s code includes a language check to exclude computers set to languages of the Commonwealth of Independent States (CIS). This is a common trait of malware developed by Russian or Eastern European actors, to avoid drawing law enforcement attention to local victims. 

Because of this exclusion logic, infections caused by StealC are generally not observed within CIS countries, and are instead more commonly seen in regions such as North America, Western Europe, and parts of Asia.

In addition to the language check, StealC uses named event objects in Windows to prevent multiple instances of itself from running on the same system. The malware first enters a loop where it attempts to open a named event. If the event exists, indicating that another instance may already be active, it waits briefly before trying again. If no event is found, it proceeds to create one to mark its own presence. If the event creation fails, it terminates.

The behavior is reflected in the following code:

This approach is a standard technique for enforcing single-instance execution or coordinating between multiple malware components. It helps the malware avoid conflicts that could arise from simultaneous execution, and may also be used to signal that an infection has already occurred.

Technical Breakdown of StealC V2 InfoStealer Malware

This section dissects how StealC v2 executes on a victim machine, how it communicates with its command-and-control, and the functionality of its main components (grabber, screenshot, loader, etc.), including representative code snippets from real malware samples.

Initial Execution and Setup

When a StealC v2 binary is run on a victim’s Windows machine (whether the user was tricked into launching an EXE or it was launched by a dropper), it begins by performing several setup checks and initialization steps. Like its predecessor, StealC v2 is heavily obfuscated and packed to hinder analysis. Many samples are wrapped in the Themida commercial packer, meaning the malware first goes through an unpacking routine in memory. 

Additionally, nearly all strings in the malware are encrypted (obfuscated) using RC4 with a hardcoded key. 

Upon startup, StealC v2 will decrypt important strings (using that embedded RC4 key) needed for its operation, such as the C2 server URL and API function names. 

StealC v2 also reads an expiration date from its configuration; if the current system date is beyond this hardcoded date, the malware will terminate itself. This acts as a time-bomb to ensure outdated builds don’t run indefinitely (and possibly as a rudimentary countermeasure against sandbox analysis that occurs after the campaign window).

Environment Checks and Execution Control Done by StealC Version2 

StealC v2 includes a regional language check to avoid infecting systems in CIS countries. It inspects the system’s UI language and exits if it matches specific locale IDs associated with countries like Russia, Ukraine, or Kazakhstan. This geofencing is likely intended to reduce the risk of prosecution in the malware authors’ home region.

Earlier versions of StealC also included anti-VM and sandbox user checks. These were removed in v2, possibly to simplify the codebase or to rely on external packers and runtime evasion instead.

To prevent multiple instances from running, StealC v2 uses a Windows Event Object as a mutex. On launch, it repeatedly attempts to open a named event. If it exists, the malware waits for about four seconds before retrying. Once the event is confirmed absent, it creates the event to mark its presence. If creation fails, it exits.

This singleton approach helps avoid redundant activity, excessive resource use, and potential operational conflicts, prioritizing stealth and stability before contacting the command-and-control server.

Hardware ID Generation and Host Fingerprinting by StealC V2 InfoStealer 

Uniquely, StealC generates a hardware ID (HWID) for the machine using a multi-step hashing process based on the system’s volume serial number. 

Determine System Drive Letter: It gets the system's Windows directory (e.g., C:\Windows) using GetWindowsDirectoryA(), and extracts the drive letter(C) to target that volume.

Get Volume Serial Number: It calls GetVolumeInformationA() to retrieve the Volume Serial Number of that drive. This is a unique ID assigned when the drive is formatted, making it a stable fingerprint across reboots.

Apply Custom Hashing: It transforms the serial number using a series of math operations:

1. first_hash: Basic transformation of the serial using constants.
2. second_hash and third_hash: Further derivations using modified constants and additional math.
3. These values are designed to obfuscate the original serial and produce more entropy.

Generate a Byte Array: It mutates third_hash in a loop to fill an 8-byte array, which contributes to the uniqueness of the final ID.

Format the HWID: The hardware ID is assembled as a GUID-style string using a mix of the hashes and byte array: XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX

This HWID will be used to identify the bot in communications. StealC also carries a Build ID (sometimes called botnet ID) that is a string identifying the campaign or build (this ID is embedded in the binary by the builder panel).

JSON-based Command and Control (C2) Protocol of StealC V2

TL:DR;

StealC v2 communicates with its command-and-control (C2) server over HTTP, using Base64-encoded JSON messages. Although the malware’s developer claimed support for RC4 encryption in later builds, analysis of version 2 samples shows that RC4 is typically disabled, leaving communication in unencrypted Base64 format.

The communication begins with the malware registering the infected host. It sends a POST request to the C2 URL with a Base64-encoded JSON object. After decoding, the payload includes fields such as build (the malware variant), hwid (a hardware ID generated from the system’s volume serial number), and type, which is set to "create" to indicate new registration.

The server responds with a configuration JSON that includes an access_token, used for all subsequent communications, along with instructions that determine the malware’s behavior. These may define what types of data to collect (such as browser credentials, plugin data, or files), whether to activate the loader module, and additional random fields to obfuscate response patterns. 

• If the server responds with "opcode": "blocked", the malware exits. 
• If the response contains "opcode": "success", the configuration is accepted and stored.

After receiving its configuration, StealC begins collecting and exfiltrating data. 

Each stolen file or data item is sent in a separate POST request using a consistent format. The request includes the previously received token, the Base64-encoded data, and an encoded or hashed filename. The "type" is always set to "upload_file".

To support larger files, StealC can divide them into 512 KB chunks and send them as multipart uploads. Each chunk includes metadata that specifies its position and total number of parts, allowing the server to reassemble the full file after transfer.

Once all configured data has been sent, the malware notifies the server by sending a final message with "type": "done", indicating the completion of the exfiltration phase.

After that, StealC checks for further instructions by sending a "loader" request. The C2 may respond with an empty list if no follow-up actions are required, or it may provide a list of payload URLs and execution instructions. This stage is typically executed at the end, but if the loader flag in the original configuration was set to true, the loader request may be sent earlier in the process.

If the configuration includes a self-deletion directive, StealC cleans up its presence by removing its executable from disk. It does this by running the following command via ShellExecuteEx:

This is executed using ShellExecuteEx and ensures the binary is removed after execution.

Loader Module of StealC V2

StealC v2 includes a native loader capability that allows it to act not only as an infostealer but also as a malware delivery tool. This functionality enables the deployment of additional payloads on an infected system, extending its utility beyond credential theft. Operators configure the loader through the builder interface in the control panel during the creation of the malware.

Executable Payloads (Type 0)

For .exe payloads, StealC downloads the binary from a URL specified by the C2 server and attempts to execute it using the ShellExecuteEx Windows API function. If the initial execution fails, the malware includes a retry mechanism and will attempt to run the payload up to ten times. If the builder configuration includes a "RunAs" flag, StealC attempts to launch the executable with elevated privileges by invoking the runas verb, enabling execution with administrator rights if permissions allow.

PowerShell Scripts (Type 1)

For PowerShell-based payloads, StealC constructs and executes a command that fetches and runs a remote PowerShell script directly in memory. It explicitly uses the 32-bit PowerShell binary to ensure compatibility with 64-bit Windows systems:

The -nop parameter disables loading user profiles, and -c allows the inline command. iex is shorthand for Invoke-Expression, which causes the downloaded script to execute directly in memory. The URL is controlled by the attacker and may point to anything from reconnaissance scripts to full malware frameworks.

MSI Installers (Type 2)

When using MSI packages, StealC downloads a .msi file from the provided URL and installs it using the Windows Installer utility. It runs the installer silently with one of the following parameters:

or

The /passive option minimizes the interface, while /qn suppresses it entirely. As with executable payloads, the malware attempts the installation up to ten times if initial attempts fail. This mechanism allows attackers to install additional tools or software that may appear legitimate but contain embedded malware.

Loader Timing and Execution Flow

The execution of the loader is controlled by a flag in the initial configuration received from the C2 server. If the loader flag is set to 1, the loader phase begins immediately, before data theft occurs. This may be used to install a persistent backdoor or drop other payloads early in the infection chain. If the flag is set to 0, the loader runs only after the data exfiltration phase is complete.

In both cases, after StealC attempts to execute the loader instructions, it sends a final loader request to the C2 with the results of those actions. Once this step is completed, the malware exits. If configured to do so, it may also delete itself from disk using a self-deletion routine.

Data Stealing Capabilities (Grabber Modules) of StealC V2 Malware

StealC v2 is designed to collect a wide range of sensitive data from infected systems. Its core functionality revolves around a unified grabber module that is dynamically configured through the server’s response. This configuration determines what categories of data the malware will target on the victim’s machine.

Configuration-Based Targeting

Rather than hard-coding each data source, StealC v2 uses configuration flags sent from the C2 server to control which modules are activated. Depending on the configuration, the malware can extract credentials and session data from web browsers, cryptocurrency wallet extensions, email and VPN clients, instant messengers, gaming applications, and user files stored in common directories.

Browser Data Collection

The browser data module allows StealC to target specific browsers such as Chrome, Firefox, Edge, Opera, and others. The configuration can specify what type of browser data to extract, including passwords, cookies, and autofill data. 

For Chromium-based browsers like Chrome and Edge, StealC v2 does not attempt to decrypt passwords or cookies on the victim’s machine. Instead, it gathers the encrypted files and sends them to the C2 server for decryption. This approach reduces the malware’s footprint and avoids detection mechanisms that monitor decrypted credentials in memory.

In contrast, Firefox uses a different encryption system based on the NSS (Network Security Services) library. StealC v2 is capable of decrypting Firefox credentials and cookies locally. To do this, it modifies the system’s PATH environment variable to include the Firefox installation directory (such as C:\Program Files\Mozilla Firefox) and loads the nss3.dll library into memory using the LoadLibraryA function. Once loaded, it uses NSS functions to decrypt saved data directly within the malware process. 

This dual strategy, local decryption for Firefox and server-side decryption for Chrome, enables StealC to cover both major browser families.

Cryptocurrency Wallet Extensions

The plugin section of the configuration is used to target cryptocurrency wallets stored as browser extensions. These extensions store wallet data in various forms, such as local storage, IndexedDB, or file-based databases. The configuration can specify each wallet extension’s unique identifier and indicate whether data should be extracted from local storage, sync storage, or IndexedDB. This enables StealC to collect private keys, recovery phrases, and wallet credentials from multiple wallet types without hardcoding specific targets.

Email and VPN Clients

StealC can also extract stored credentials and configuration files from email and VPN clients. 

For example, it may target Microsoft Outlook data stored in PST or OST files, or VPN configuration files that contain authentication details. These paths are likely defined in the configuration panel and do not require code changes in the malware binary, making it easy to add new targets.

File Grabber and Folder Targeting

The file grabber module enables StealC to collect arbitrary files from the system. The configuration can instruct the malware to search specific user directories using CSIDL (Common Special Item ID List) codes. These numeric codes map to known folder paths:

Based on these values, StealC can recursively scan folders such as Desktop and Documents for files of interest. Typically, it looks for files with extensions such as .txt, .pwd, .wallet, or .doc, though the panel may allow broader collection rules. When a file is found, StealC reads its contents and uploads it using the same mechanism as other data. Large files are divided into 512KB chunks to reduce the risk of detection during transfer.

How Does Picus Help Defend Against the StealC V2 Stealer Attacks?

StealC V2 uses techniques like browser credential theft, encrypted C2 traffic, PowerShell-based payloads, and stealthy HTTP exfiltration. To stay protected, it’s vital to validate whether your controls can detect and block these behaviors.

Picus Security Validation Platform helps by safely simulating StealC V2’s techniques, such as password and cookie theft, wallet data access, and script execution, using its up-to-date Threat Library. These tests help you uncover blind spots across EDRs, NGFWs, and SIEMs before attackers do.

The Picus Threat Library includes the StealC V2 Stealer threat, replicating real-world TTPs for continuous security control validation.

How to Defend Against StealC v2

Given StealC v2’s capabilities and tactics, organizations should employ a multi-layered defense to prevent infection, detect any breaches that do occur, and respond swiftly to minimize damage. 

Below are recommended strategies for prevention, detection, and response against StealC v2 (and infostealers in general):

Prevention

Preventing StealC from ever executing is the most effective defense. Since StealC relies on users (or user-run programs) to launch it, prevention focuses on hardening endpoints and educating users:

User Awareness and Training

Emphasize cyber hygiene to all users. They should be wary of unexpected email attachments, especially compressed files or executables, and avoid downloading software from sketchy websites or pirate links. Many StealC infections originate from users running cracked software or fake installers. Training users to recognize phishing attempts and malicious download prompts (including malvertising e.g., fake “Download” buttons on websites) can stop the initial execution. Encourage users to only install software from trusted sources (official app stores or vendor sites).

Web and Email Filtering

Deploy strong email security filters to catch phishing emails carrying StealC loaders or links. Block or quarantine emails with .exe, .scr, or unusual attachments unless absolutely necessary. Implement DNS and URL filtering to block access to known malicious domains/IPs and categories like piracy sites or newly seen domains. 

Since StealC was distributed via malvertising, using ad-blocking and DNS filtering on endpoints can reduce the chance of users visiting the malicious ad sites. Consider browser extensions or security tools that warn users about potentially malicious downloads.

Endpoint Protection (Anti-malware/EDR)

Ensure endpoints are protected by modern Antivirus or EDR solutions that have behavioral detection. 

Signature-based AV should be kept updated with the latest StealC indicators (many vendors detect StealC variants as e.g. PWS.Stealc). More importantly, enable features that detect suspicious behavior: e.g., flag any process (other than a browser or updater) that tries to access browser credential stores or loads browser DLLs like nss3.dll unexpectedly. 

EDRs can also block known malicious patterns like execution of PowerShell with web download commands. Configure these tools to ideally prevent execution of known malicious patterns (some EDRs can break the kill-chain by blocking the action and isolating the host).

Application Control & Hardening

Implement allow-listing for applications using tools like Microsoft AppLocker or Windows Defender Application Control. Only allow approved programs to run, especially in sensitive environments. Deny execution from common malware directories: for instance, users typically do not need to run programs from %AppData%\Local\Temp or from the Downloads folder. Blocking executables in these locations can stop many commodity malware (including StealC) from running at all, even if a user inadvertently downloads them. Similarly, enforce the principle of least privilege: users should not have admin rights if not needed, to prevent malware from easily elevating.

Credential Hygiene

Since StealC’s main goal is to steal credentials, reducing what’s available to steal is a defensive measure. Encourage or enforce the use of password managers that don’t store passwords in the browser, or at least require a master password. Discourage storing corporate credentials in plain text files on disk. 

For highly sensitive accounts, avoid allowing persistent cookies (require re-login, so stolen cookies are less useful). 

Also implement multi-factor authentication (MFA) on important accounts; while StealC can steal session tokens, MFA can limit attackers from directly using just usernames/passwords. Educating users not to save passwords in browsers (especially important admin or privileged passwords) can reduce the impact if an infostealer runs.

Up-to-date Software and Patches

Ensure browsers and OS are up to date. While StealC doesn’t exploit a vulnerability to run, keeping software updated helps overall security. Also, for any security tools or browser security features (like Chrome’s Enhanced Safe Browsing, or an enterprise browser policy limiting the ability to run unknown code like disabling unnecessary PowerShell if possible) can help. If an organization uses application sandboxing (virtual desktops for clicking unknown links, etc.), funneling user downloads through those can contain potential malware.

Detection

Despite preventive measures, it’s crucial to have detection controls to catch StealC if it slips through. StealC v2 is stealthier than some stealers, but it still has detectable behaviors:

Behavior Monitoring & Anomaly Detection

Configure your EDR or monitoring solution to alert on unusual process behavior. For example, flag any process (especially an unknown one in user space) that:

• Accesses files in browser data directories (e.g., reading Login Data, Web Data, Cookies files in Chrome’s folder). Legitimate software rarely needs to read those aside from the browser itself.
• Reads or copies files in %AppData%\Telegram Desktop\ or %AppData%\Discord\ (if neither Telegram nor Discord program is running, no process should touch these).
• Loads browser DLLs like nss3.dll (outside of the context of Firefox). For instance, a process named update.exe loading nss3.dll is suspicious.
• Spawns child processes such as cmd.exe or powershell.exe without a good reason. Particularly, an alert for processes launching powershell.exe -nop -c ...DownloadString should be high-severity, as that’s a common malware pattern. Also, monitor for msiexec.exe being launched by non-installer programs. StealC’s multi-step, multi-process chain gives several opportunities for detection: the initial process doing file access, the invocation of PowerShell, and the cmd self-delete.

Network Monitoring and Alerts

Implement network-based detection rules for StealC’s C2 traffic. Since StealC communicates via HTTP, a proxy or IDS can catch certain signs:

• Look for HTTP POST requests to raw IP addresses or to domains with long random paths. If your organization typically doesn’t communicate with IPs in certain ranges (like those used by bulletproof hosts), an IDS could flag any direct IP communication.
• Use threat intelligence feeds to block or alert on known StealC C2 indicators (like the IPs 45.93.20[.]28, 88.214.48[.]93, or others reported). Even if these specific ones change, the format of /<random>.php in an HTTP POST from a client application is suspicious.
• If possible, do protocol decoding: base64-encoded JSON blobs with fields like "type":"create" or "type":"upload_file" in outbound traffic (especially soon after an unknown EXE ran) are a giveaway. For encrypted traffic, this is harder, but one could detect the presence of a repeating HTTP POST of ~700KB chunks which is not normal for typical user behavior.
• Monitor egress for abnormal volume of data from a client soon after execution of a new program. Infostealers often cause a spike of outbound traffic (they quickly send a lot of data, albeit chunked). If a user’s machine suddenly posts tens of megabytes of data to an IP in a short span, that’s an anomaly worth investigating.

Threat Hunting with YARA and Memory Analysis

Develop YARA rules to scan for StealC in memory or in files. For example, even though strings are encrypted, the RC4 key or certain function strings might be consistent per version. 

Threat hunters could search for signs like the PowerShell command text in memory (if StealC constructs it dynamically, it might appear in memory). Additionally, scanning for the use of ShellExecuteEx with timeout and del in the command-line could catch the self-delete sequence in memory or command-line logs. EDRs that record command line arguments can trigger on the literal /c timeout /t 5 & del /f /q pattern as well, which is not common in normal operations.

Artifacts on Disk

While StealC tries not to leave traces, sometimes things can be left behind if something fails. After an incident, look for leftover temp files: Did StealC perhaps dump a temp copy of a screenshot or a zip file it failed to delete? Check the typical temp directories for any archive or weirdly named files around the time of suspicious activity. Also, any unknown binaries found on the system should be hashed and compared against malware databases.

User or System Indicators

Although StealC is stealthy, users might notice indirect effects. For instance, if an endpoint’s browser or application slows down or crashes (less likely with StealC v2 since it doesn’t forcibly kill processes), that could hint that something accessed those files. If the organization uses Google Workspace, seeing login alerts from new locations for that user could mean their cookie was used elsewhere (if StealC stole it). Setting up alerts for abnormal account access can tip you off that a user’s machine may have been compromised by an infostealer.

By layering these detection methods, an organization improves the odds of spotting StealC either at the point of execution or during its data exfiltration phase.

References

[1] A. Ekwall, “‘Over 330 Million Credentials Compromised by Infostealers,’” Bullet Ant Consulting, Feb. 21, 2025. Available: https://bulletantconsulting.com/blogs/news/over-330-million-credentials-compromised-by-infostealers. [Accessed: May 23, 2025]