StealC You Later: Proofpoint and IBM X-Force Support Operation Endgame Disruptions

Key Findings: 

• Proofpoint and IBM X-Force supported a joint disruption as part of Operation Endgame, targeting the StealC ecosystem, a prominent information stealer. 
• The operation was coordinated by Europol, and impacted 66 domains and 296 servers associated with both Amadey and StealC. More than 25.6 million unique credentials stolen from over 385k compromised systems were seized. 
• A vulnerability in the StealC command and control panel discovered by researchers was used by law enforcement to support the operation. 
• Proofpoint and IBM X-Force threat researchers developed a StealC emulator to identify and track operations, infrastructure, and payloads. 
• In keeping with previous operations, a video was published on the Operation Endgame website. 

Overview  

StealC is a prominent malware-as-a-service in the growing ecosystem of information stealers. As identity continues to be a rich target for threat actors, the information stealer economy poses a significant and growing threat to organizations and private individuals alike. To combat this, private industry and global law enforcement partners collaborated to target and disrupt StealC and the supporting ecosystem. IBM X-Force and Proofpoint participated in this joint collective action. The disruption was carried out in June 2026 as part of Operation Endgame by law enforcement agencies and private partners. This joint blog post by X-Force and Proofpoint discusses details of the StealC malware and how collaborative action was taken against it.  

On 24 June 2026, law enforcement and private partners announced a disruption action against StealC. The action targeted 66 domains and 296 servers associated with both Amadey and StealC. Additionally, Microsoft’s Digital Crimes Unit filed a lawsuit against multiple alleged enablers involved in StealC and Amadey, and was able to take down infrastructure associated with the malware. Announcements included details on the coordinated disruption of SocGholish, too. 

The disruption and associated civil suit will impact the malware’s operations from both a tactical and reputational perspective. Based on efficacy of Operation Endgame’s previous efforts, this disruption will likely have a notable impact on StealC, including a disruption to services, malware delivery, reputational and financial damage, and loss of customers. 

What is StealC? 

StealC is a popular infostealer malware, which has been sold as a malware-as-a-service (MaaS) since January 2023. Clients of this service, also called affiliates, purchase a Linux-based installer for the command and control (C2) panel. Using this panel, affiliates can then build malware samples and distribute them to steal sensitive data from victims. The stolen data is processed and stored on the panel server, which affiliates can use to manage active infections, distribute secondary payloads, and update their configurations.  

In March 2025, the developers released StealC version 2 which featured several updates to its codebase. The latest StealC build is v2.22.0, released on 26 May 2026. Sensitive data targeted and exfiltrated by StealC includes: 

• Browser data: credentials, cookies, history, autofill data, tokens, credit cards, and browser extensions 
• Data from email/messenger software (Thunderbird, Outlook, Foxmail, Telegram, Discord, Tox, etc.) 
• Gaming software (Steam, Battle.Net, Uplay, etc.) 
• Credentials from other software including Azure, OpenVPN, ProtonVPN, FileZilla and WinSCP 
• Crypto wallets 

Apart from the default list searching for specific sensitive files to exfiltrate, affiliates can add custom rules as well.  

The stolen data may then be leveraged by the affiliates directly or sold on underground markets. Stolen credentials and identities have often been used to launch further attacks against organizations, resulting in significant damage.  

Tracking StealC and Extracting Configurations at Scale 

A large part of our research depended upon extracting configs from as many StealC samples as we could get our hands on. “Configs”, or configurations, are data structures stored in malware, usually in an encrypted or obfuscated state, and later decrypted and read by the malware. Configs can contain important settings the malware uses, such as C2 addresses, campaign and affiliate IDs, unique client/bot IDs, C2 communication encryption keys, and so on.  

Proofpoint and X-Force obtained StealC samples from internal data sources, as well as external data sources such as VirusTotal and sharing partners. Each StealC sample was fed into malware sandboxes and configuration extraction scripts were executed on the malware, allowing us to read, process, and store configs. A typical StealC config contains the following important data: 

We used these configurations to track StealC operations and affiliate groups, as well as to set up emulator infrastructure, which we’ll discuss later. Additionally, we used this intelligence to create detections and customer protections, including via Emerging Threats. 

Vulnerabilities in the C2 Panel 

In early 2026, while collaborating with law enforcement, we identified a vulnerability in the StealC C2 panels. An exploit was created, tested and later used in the disruptive and investigative actions by global law enforcement to search and seize StealC servers.  

The StealC backend is written in PHP and uses a randomized file path as its main endpoint, which is unique to every C2 server. As discussed previously, the full URL is hardcoded into every StealC sample as part of its configuration. The C2 communication uses RC4-encrypted HTTP POST requests containing JSON formatted data. C2 servers accept four different request types: 

1. “create”: The first beacon to register the bot, which returns an access token and configuration set up for the corresponding build ID. 
2. “upload_file”: A request exfiltrating data from the victim’s machine as a file. 
3. “loader”: A request to download a secondary payload, if configured. 
4. “done”: A final request to indicate that the exfiltration has completed. 

After a StealC client has registered and received an active token, this token is used during all communication to identify it. During the information gathering phase of the stealer, all data is exfiltrated as a Base64 string in the encrypted JSON object, together with a corresponding filename: 

{"access_token": "<access_token>", "data": "<base64-encoded data>", "filename": "<base6-encoded filename>", "type": "upload_file", "part_index": 0, "total_parts": 1} 

For larger files, the data can be split into multiple parts.  

When the data is parsed and processed on the StealC backend, the contents of the “filename” field are passed through a string sanitization function: 

Figure 1: Snippet of C2 panel code. 

However, this implementation does not remove forward-slashes from the filename. All files collected from the victim are stored on the server within a ZIP file, with their original filenames, before being processed. For filenames matching a specific pattern, the MetaMask plugin will attempt to decrypt seed phrases of MetaMask crypto wallets stored in browser data. During the decryption process, the file data received from the infected machine is first extracted from the ZIP file into a new temporary directory under /var/www/temp, while maintaining its original filename. The function extracting the files does not verify whether the original filename is a path and will happily write the file’s data to any relative path it can access from its directory. This directory traversal bug opens up a convenient way to upload a web shell to the StealC C2 server.  

The vulnerability was patched in February by the developers of StealC. It has not been the only security bug in the StealC server’s codebase. There have been multiple other vulnerabilities as well, which have caused concern from affiliates on underground forums. Evidence uncovered during the investigation also suggests that the same vulnerability may have also been exploited by an affiliate to steal data from other affiliates.  

The StealC panel’s codebase, and the security improvements, appear to be iteratively stitched together and contain a lot of redundant logic. It appears to have been coded on top of older codebases of other infostealers and indicates a much less skilled developer in comparison to other malware. 

Emulating Clients and Collecting Payloads 

As mentioned, StealC functions primarily as an information stealer, but has an optional loader functionality. The C2 operator can specify loader URLs in the C2 panel. If the operator adds loader URLs, the StealC clients (bots) that connect to the C2 server will be delivered one or more of these loader URLs. At this point, the StealC malware client will attempt to download and execute one of the payloads from the URLs provided by the server. This gives StealC operators the ability to load whatever payloads they wish, including other infostealers, remote access trojans, or even ransomware. 

Emulating StealC Clients 

To track the operations, infrastructure, and payloads of the StealC operators, we built StealC bot emulation capabilities. Bot emulation, in our case, involved emulating C2 communications in order to “convince” the C2 server to divulge payload URLs.  To emulate this communication, we designed several tools that emulate the network activity that occurs in a normal StealC infection. This involves a C2 check-in followed by capturing the subsequent responses from the C2 and then sending a special request to the C2. The C2 would then potentially respond with one or more payload URLs.  

Upon receiving these payload URLs, we downloaded the payloads from the payload staging servers and executed them in a controlled sandbox environment. This allowed us not only to understand the payloads that were being delivered by the StealC operators, but also to better track actor clusters and affiliate groups. If more than one C2 panel is serving payloads from the same IP, for example, we can make the assumptions that there may be some link between these C2 servers and the operators. Below is a screenshot of the emulator code running, as well as a “loader” response received from the C2 server: 

Figure 2: StealC emulator code in action. 

Figure 3: C2 server response (in JSON format) containing payload URL’s. 

Observing and Tracking Payloads 

During the timeframe of our emulation operations, we observed many malware families (payloads) being delivered to systems infected with StealC. In some cases, the StealC client was delivered only one payload, such as another stealer or a remote access trojan (RAT). In many cases, however, the StealC client received another loader malware, which subsequently downloaded the final payload. One notable example is a StealC client downloading XTinyLoader, which, in turn, downloaded a LockBit Black ransomware payload. A ransomware payload was an edge case in our research, but these complex malware delivery chains were common.  

Here is a non-exhaustive list of the malware families we observed being delivered as payloads. Note that some of these malware families were delivered by other second stage loaders following an initial StealC infection (such as the example we mentioned above) and not directly by StealC: 

• Amadey 
• AsyncRAT 
• HijackLoader (aka. DOILoader, IDAT Loader) 
• LockBit Black 
• MaskGramStealer 
• RedLine Stealer 
• SDBbot 
• SectopRAT (ArechClient) 
• SmokeLoader 
• StealC (curiously, a second StealC sometimes appeared in a StealC infection) 
• SVCStealer 
• TinyNuke 
• Vidar 
• XMRig 
• XTinyLoader 
• zgRAT 
• Other python-based stealers and clippers 

We also observed overlap with the payloads StealC servers were delivering in relation to other malware families. For example, we witnessed certain sets of the exact same payload (with the same file hash) being delivered by other stealers/loaders like Amadey. This suggests that some StealC affiliates may be using other stealers and loaders as part of their operations as well.  

Conclusion 

The latest disruption effort marks another step in the broader series of Operation Endgame initiatives targeting the cybercrime ecosystem and the services that sustain it. By gathering intelligence and monitoring malicious infrastructure, X‑Force and Proofpoint provided key support to law enforcement, the Microsoft Digital Crimes Unit, and other private‑sector partners. These strong collaborations demonstrate how unified action can meaningfully weaken cybercriminal operations. 

Proofpoint’s mission is to provide the best human-centric protection for our customers against advanced threats. Whenever it is possible and appropriate to do so, and as is the case with Operation Endgame, Proofpoint uses its team’s knowledge and skills to help protect a wider audience against widespread malware threats. Proofpoint was proud to assist in the law enforcement investigations into StealC activity.  

Through its unique vantage point, Proofpoint is able to identify the largest and most consequential malware distribution campaigns, providing the authorities with much-needed insight into the biggest threats to society, affecting the greatest number of people around the world.