StealC you later: Proofpoint and IBM X-Force support Operation Endgame disruptions - IBM

Subscribe Security StealC you later: Proofpoint and IBM X-Force support Operation Endgame disruptions Discover how Proofpoint and IBM X-Force supported Operation Endgame to disrupt StealC malware, seizing over 25.6 million stolen credentials from compromised systems, showcasing effective cybercrime disruption through global collaboration. By Golo Mühr Published 24 June 2026 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. 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: Config Struct Member Description C2 server and URL A unique URL address used to connect to and communicate with the C2 panel BuildID A unique ID assigned to the malware. This ID is usually assigned to a certain number of samples and is frequently rotated. Config Encryption Key (RC4) An RC4 key used to encrypt/decrypt the comms key (see below) and other strings in the malware binary Communication Encryption Key An RC4 key used to encrypt/decrypt C2 communications 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: “create”: The first beacon to register the bot, which returns an access token and configuration set up for the corresponding build ID. “upload_file”: A request exfiltrating data from the victim’s machine as a file. “loader”: A request to download a secondary payload, if configured. “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 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 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. IBM X-Force exists to protect organizations, people, and societies from the advanced threats causing the greatest harm. Operations like Endgame demonstrate what becomes possible when world-class threat intelligence meets decisive law enforcement action. X-Force contributed directly to investigations into StealC and the ransomware operations it enables—bringing intelligence authorities needed to act decisively and at scale. This is not passive support. It is the deliberate application of global threat visibility toward outcomes that protect industries, institutions, and communities beyond any single client engagement. The threats causing the greatest harm do not stop at organizational boundaries. Neither does X-Force. Would your team catch the next zero-day in time? Join security leaders who rely on the Think Newsletter for curated news on AI, cybersecurity, data and automation. Learn fast from expert tutorials and explainers—delivered directly to your inbox twice weekly. See the IBM Privacy Statement. First name* Last name* Business email* * All fields required Your subscription will be delivered in English. You will find an unsubscribe link in every newsletter. Refer to our IBM Privacy Statement for more information. Subscribe Golo Mühr Malware Reverse Engineer IBM Report IBM X-Force Threat Intelligence Index 2026 Gain insights to prepare and respond to cyberattacks with greater speed and effectiveness with the IBM X-Force® Threat Intelligence Index. Read the report Resources Techsplainers podcast Cyberattacks explained Techsplainers by IBM breaks down the essentials of cyberattacks, from key concepts to real‑world use cases. Clear, quick episodes help you learn the fundamentals fast. Listen now On-demand webinars Guardium webinars Learn how to protect your data across its lifecycle from our webinars. Explore on-demand webinars Guide Cybersecurity in the era of generative AI Learn how today’s security landscape is changing and how to navigate the challenges and tap into the resilience of generative AI. Read the guide Explainer What is threat management? Threat management is a process of preventing cyberattacks, detecting threats and responding to security incidents. Read the article Incident response services Improve your organization’s incident response program, minimize the impact of a breach and experience rapid response to cybersecurity incidents. Explore incident response services Threat detection and response solutions Use IBM threat detection and response solutions to strengthen your security and accelerate threat detection. Explore threat detection solutions IBM QRadar SOAR Solutions Optimize decision-making processes, improve SOC efficiency and accelerate incident response with an intelligent automation and orchestration solution. Explore QRadar SOAR Take the next step Improve your organization’s incident response program, minimize the impact of a breach and experience rapid response to cybersecurity incidents. Explore incident response services Learn more about IBM X-Force Products Consulting services Industries Case studies Financing Research LinkedIn X Instagram YouTube Podcasts Business partners Documentation Events Newsletters Support TechXchange community Overview Careers Investor relations Leadership Newsroom Security, privacy and trust Contact IBM Privacy Terms of use Accessibility About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review yourcookie preferences options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement.  To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here. Accept all More options