ESET takes part in Operation Endgame to disrupt Amadey and Stealc

A year ago, ESET Research was part of two major operations that disrupted some of the leading cybercriminal operations at the time, Lumma Stealer and Danabot. More recently, our researchers are once again collaborating with private partners and law enforcement, but this time taking aim at the Amadey botnet and Stealc infostealer, both provided via malware-as-a-service (MaaS) offerings. Operation Endgame – coordinated by Microsoft Digital Crimes Unit (DCU), BitSight, Lumen, Mitsui Bussan Secure Directions (MBSD), and other partners – targeted all known network infrastructure used by Amadey and Stealc affiliates in order to cripple their cybercriminal operations.

ESET contributed to this effort by providing technical analyses, statistical information, known command and control (C&C) servers, encryption keys, campaign and build identifiers, and other threat intelligence collected during our long-term tracking of both malware families.

Key points of this blogpost:

• ESET took part in the coordinated, global Operation Endgame to disrupt Amadey and Stealc.
• Operation Endgame impacted around 50 domains and nearly 200 active IP-based C&C servers associated with Amadey and Stealc.
• ESET provided technical analyses, statistical information, known C&C servers, encryption keys, campaign identifiers, and other insights.
• We provide an overview of the MaaS ecosystem at the affiliate level for both malware families.
• We describe how we clustered Amadey and Stealc activity.
• We summarize the technical properties most relevant to tracking and disruption, including C&C communications, embedded identifiers, and encryption keys.
• We detail overlaps between activities of Amadey and affiliates of Lumma Stealer.

Disruption contribution

ESET Research has been tracking both the Amadey botnet and Stealc infostealer for the past three years. For this disruption operation, we shared statistics covering Q4 2025 through H1 2026, along with technical indicators and configuration data extracted from processed malware samples.

Our automated systems have been dissecting Amadey and Stealc samples and identifying the fields most relevant for large-scale tracking. These include C&C servers, build identifiers, encryption keys, URL paths, campaign identifiers, and other embedded values used by the malware families during communication with attacker-controlled infrastructure.

A major focus of our work was finding reliable methods to handle the large volume of processed samples and to cluster them. This was particularly useful because both Amadey and Stealc are sold as services. As such, the malware samples are distributed and operated by affiliates, often running their own infrastructure, generating or requesting their own builds, and orchestrating their own campaigns. Identifying activity clusters in such ecosystems allows us to spot high-priority targets for disruptions like this one.

Sharing technical analyses, statistical information, and threat intelligence, such as C&C server lists, affiliate identifiers, and encryption keys, enables law enforcement agencies to identify, prioritize, and act against infrastructure with a high degree of confidence. IoCs also help distinguish between individual clusters, shared infrastructure, and high-impact botnets whose disruption is likely to have the greatest impact on the overall threat landscape. Ultimately, the disruption affected around 50 domains and nearly 200 active IPs used as C&C servers for either Amadey or Stealc.

Disrupted malware families

Amadey is a modular malware loader. Its main purpose is to distribute additional malware to compromised systems, although it also offers modules for data exfiltration and remote access.

Stealc, in contrast, is a typical infostealer as a service. It targets credentials, cookies, cryptocurrency wallets, browser extensions, and files whose names match affiliate-defined patterns.

Both malware families are sold as services and advertised on darknet forums. For visibility into darknet forums, we used Flare.io, a threat intelligence platform that monitors underground communities. In both ecosystems, affiliates receive a self-hosted administration panel that must be deployed on their own server infrastructure. This requires a certain level of technical skill from affiliates and also gives them direct control over victim data and payload distribution.

This model differs from other MaaS ecosystems. For example, Danabot affiliates can choose to rent C&C infrastructure as a service, while Lumma Stealer used an exfiltration network fully managed by its operators. In the case of Amadey and Stealc, affiliates are responsible for deploying and operating their own infrastructure, making disruption efforts more difficult, which is why the clustering approach was essential.

While distribution methods ultimately depend on each individual affiliate, ESET telemetry consistently showed that both malware families were delivered through a wide range of channels. The most common methods included fake software updates, cracked software installers, and third-party malware loaders.

Amadey used a pay-per-rebuild model. Affiliates purchased a license and then paid an additional fee each time they needed to generate a new build, for example when rotating to a new C&C server. In other words, Amadey operators did not provide affiliates with a builder tool; instead, samples were compiled on request for each affiliate.

Stealc took a more affiliate-friendly approach, offering unlimited build generation (Figure 1) as part of its subscription. This lowered the operational cost of rotating C&C infrastructure and made it easier for affiliates to generate new samples as needed.

Trying to avoid impersonation scams, operators of both services explicitly instructed prospective affiliates on darknet forums to contact them only through official channels. Amadey directed buyers to private messages on the darknet forum where it is advertised, while Stealc used private messages on darknet forums or Telegram.

Amadey

Amadey is a modular malware loader that has been advertised on darknet forums by account name InCrease since October 2018. Over time, it has become one of the more stable and actively maintained malware families, with ongoing support provided through darknet forum channels.

Our telemetry detection rate, shown in Figure 2, indicates that Amadey was observed globally with no specific regional focus, although the highest detection rates were observed in India, Turkey, Egypt, Mexico, and Spain.

The primary function of Amadey is to distribute additional malware to victims. Besides that, it offers three modules for further data exfiltration and access: clipboard monitoring, credential theft, and VNC-based remote access.

The service is priced at US$600, paid in Bitcoin, for a single license, with an additional US$50 charged per rebuild. This means affiliates incur a cost each time they generate a new build, such as when rotating to a fresh C&C server. This pricing has remained largely unchanged since the earliest advertised versions, suggesting a stable and established customer base.

Over the years we have observed ongoing version updates (Figure 3) and active development of Amadey. The most significant milestone in Amadey’s development came in August 2020 (v1.99.5), when the entire codebase was completely rewritten. The second major evolution arrived in the release of v5.03 in October 2024, which delivered a dense wave of new capabilities: hVNC with reverse connect, MSI silent installer support, RDP enabling, cmd.exe execution with SYSTEM privileges, and integrated support for encrypted payloads. Overall, the majority of the other, more minor updates served one implicit but constant purpose: evading AV detections as they appeared.

Technical overview

Each Amadey sample contains at least one hardcoded C&C server URL, with the configuration supporting up to three entries. Samples also embed an RC4 key used for encrypting communications with the C&C server.

Our analysis showed that the RC4 key extracted from each sample serves as a reliable cluster identifier, allowing us to cluster samples into individual botnets, which we discuss in more detail in the Clustering section.

A second hardcoded value, internally referred to as sd, is a random-looking six-character hexadecimal string matching the pattern [0-9a-f]{6}. It is transmitted during the initial C&C handshake and most likely identifies a specific build within an affiliate’s deployment. Although it is sometimes called a campaign ID or Amadey ID by researchers, Amadey’s pay-per-build business model suggests that it more accurately represents a build identifier.

Each sample also carries a version number. Our analysis focuses on version v5.x, which has been the dominant variant observed in ESET telemetry since the beginning of 2025.

This bot also checks the victim’s keyboard layout. If it matches a layout associated with a CIS country, all network communication is silently rejected. Threat actors operating from Eastern Europe commonly use this type of built-in safeguard to avoid affecting businesses and governmental entities in the region, reducing the risk of attention or prosecution by local authorities. In addition, these operators often follow such practices to avoid potential backlash from their peers for targeting “their own people” or for violating the rules of darknet forums where their services are advertised.

This section provides only a high-level overview of Amadey, as deep technical analysis has already been published in the Swisscom report.

C&C communications

Amadey communicates with its C&C server over HTTP using POST requests. At a high level, communication follows a three-stage lifecycle:

• Initial beacon – the bot sends a minimal st=s HTTP POST request to the C&C server. The server responds with a sleep interval, for example <c>10<d>, instructing the bot to wait 10 minutes between subsequent check-ins.
• Registration – the bot transmits RC4-encrypted system information encoded as a flat key-value string. This data includes the operating system version, username, PC name, installed antivirus product, administrative privileges, sd value, and other host information. Notably, the RC4 key itself is never transmitted over the network. Based on our telemetry, no server was observed serving tasks for more than one RC4 key at a time, suggesting that each sample must communicate with a C&C server that already knows and expects that exact RC4 key. The server responds with a task list.
• Tasking – tasks are delivered as structured command strings delimited by <c> and <d> tags with individual commands separated by # characters, as shown in Figure 4. Each task encodes a command type, such as downloading and executing an EXE, starting VNC, or running a stealer plugin. Tasks also include parameters such as a privilege escalation flag, target directory, and payload URL.

Each task has its own processing logic, ranging from simple download-and-execute commands to more complex execution of hVNC or proxy components. The inner workings have been documented in previous technical reporting.

Clustering

When tracking MaaS malware, a key challenge is finding a reliable way to group samples belonging to the same threat actor. Understanding the business model and the distribution of network infrastructure is thus essential for successful disruption, because it allows defenders and law enforcement to identify the critical points where action will have the greatest impact. In this section, we explain our methodology.

Amadey samples contain three key hardcoded configuration values:

• C&C URLs,
• RC4 keys used for C&C communications, and
• the sd value transmitted during the initial C&C handshake.

Over the course of our tracking, we noticed that Amadey C&C URLs follow a consistent pattern:

http(s)?://<C&C>/<random_path>/index.php

Further, the same <random_path> URL part was used with different C&C servers (see Figure 5). As this value appears to be a random string, seeing it tied to multiple C&C servers over time seemed like a strong indicator that the C&C servers are operated as part of the same cluster. Therefore, we further decomposed the C&C URL into these two parts: the IP address or domain and the URL <random_path>.

Using values from the samples’ configuration, combined with our understanding of their purpose, we leveraged graph modeling to gain insights into the structure of the Amadey ecosystem. On first glance at Figure 6, we clearly see that, indeed, there is no shared infrastructure, but rather several smaller sub-botnets with one clearly dominating. We dive deeper into that largest cluster in the next section.

To conclude, the main takeaways are:

1. We identified a total of 53 unique clusters inside the Amadey ecosystem.
2. Each sd value is tied to exactly one RC4 key.
3. RC4 keys are likely a useful affiliate identifier, as rebuilds preserve the key while changing the sd value.
4. The C&C URL <random_path> part is occasionally reused when rotating C&C servers, serving as reliable evidence of such C&C servers belonging to the same cluster.

The largest Amadey botnet cluster

One cluster stands out as the largest, and it contributed nearly 34% of all processed Amadey samples. This cluster was also the only one active throughout the entire analyzed time period, as represented in our timeline in Figure 7.

The largest botnet also dominated in the average number of payloads distributed to victims per execution. Based on our clustering methodology, Amadey samples belonging to the largest botnet delivered, on average, around 14 payloads to every victim simultaneously (Figure 8).

The range and diversity of distributed malware families was broad, from infostealers and RATs to malware packed with complex code protectors. Figure 9 provides an insight into the payloads we detected being delivered throughout the tracking period.

Furthermore, ESET researchers were able to obtain evidence that many times, multiple Lumma Stealer samples were delivered to a single victim, each attributed to a different affiliate (see our previous Lumma Stealer research). This results in multiple Lumma Stealer affiliates ending up with the same stolen data. This observation leads us to conclude that the threat actors controlling this largest cluster likely ran their own pay-per-install (PPI) model, further monetizing their bots.

Stealc

In contrast to Amadey, Stealc is a typical representative of an infostealer. It targets a broad range of data sources, including credentials stored by web browsers, email clients, FTP clients, gaming platforms, cryptocurrency wallet files, and browser extensions.

Stealc was introduced on a darknet forum in February 2023, and we started tracking it shortly thereafter. Our telemetry detection rate, shown in Figure 10, indicates that Stealc was distributed globally with no specific regional focus. The highest detection rates were observed in the United States, Poland, and Italy.

Stealc is advertised by a threat actor using the moniker plymouth. The operators had been actively maintaining Stealc; each time a new version was released, they disclosed release notes in a darknet forum post. There have been 37 such releases in the past three years. Stealc is sold as a monthly subscription, with pricing that has evolved only slightly:

• US$300 per month
• US$700 for three months
• US$1,000 for six months

In March 2025, Stealc received a major architectural update with version 2, introducing significant changes to the network protocol and configuration structure and – since then – this version has dominated in our telemetry. By June 2026, it had reached version 2.22.1, as shown in Figure 11.

Besides its main targets, Stealc includes a configurable file grabber that allows affiliates to specify custom patterns defining files to exfiltrate from compromised machines. Its C&C communications and embedded strings are protected by RC4 encryption with per-build keys.

Stealc does not rely on a single, standardized distribution method – each affiliate is responsible for its own delivery mechanisms. However, similar to Amadey, our telemetry indicates that certain vectors consistently stand out – particularly trojanized software installers and established malware loaders (like Amadey).

Technical overview

A detailed technical analysis of Stealc v2 has already been published by Lumma-Labs. In this section, we focus on the properties usable for clustering.

Current versions of Stealc embed two distinct RC4 keys per sample:

• one to decrypt obfuscated strings at runtime, and
• a second one to encrypt C&C network communications.

In addition to the two RC4 keys, we have been extracting the build identifier from Stealc samples. This value represents an individual Stealc campaign, and unlike other strings it is not protected in the binary. The value is important because it is transmitted as part of the C&C handshake (see Figure 12).

The C&C server address and URL path used for communications are both stored among the RC4-encrypted strings and have been extracted as part of our automated configuration unpacking pipeline.

C&C communications

Stealc communicates with its C&C server over HTTP using RC4-encrypted JSON objects. The initial request sent to the C&C contains three values:

• a build identifier (build),
• a fingerprint of the compromised machine (hwid), and
• the request type (this initial request is of the type create).

The machine fingerprint is derived from the system’s volume serial number and formatted as a UUIDv4 string. An example JSON object for this initial request is shown in Figure 12.

The C&C server responds with a complex JSON object that defines what features Stealc should perform. Alongside that, the response contains a randomly generated access_token value that acts as a session key and needs to be used in all subsequent requests, otherwise they are refused by the server. Besides the complex definitions of targets, the JSON object also defines whether to take a screenshot, self-destruct when finished, or download and execute an additional payload afterwards. An example of response JSON object is shown in Figure 13.

Each server response also contains a randomly generated key-value pair at the very beginning – neither hexadecimal string is ever reused in subsequent C&C communications. According to Zscaler research, this prevents static detection signatures on RC4-encrypted traffic, even when the same encryption key is used repeatedly. In Figure 13 the randomly generated nonce is "bf66e52": "03030ac3e9a8cebf".

After the initial registration, Stealc uses three additional operation types with self-explanatory names to perform its functionality:

• upload_file – exfiltrate collected data,
• loader – fetch and execute a follow-on payload, and
• done – signal completion.

Clustering

As mentioned, unlike Lumma Stealer’s, Stealc operators offer their affiliates no shared infrastructure. Similar to our clustering approach for Amadey, we applied graph modeling to values extracted from Stealc configurations, combined with our understanding of their purpose, to better comprehend the structure of the Stealc ecosystem. We ended up with a graph showing that Stealc is indeed fractured into many small clusters (see Figure 14). Each cluster is centered around a small number of C&C servers (often just one) and typically tied to only a few build IDs or C&C URL paths. Disrupting such infrastructure is therefore a challenging task due to the lack of a weak point. Overall, we identified a total of 73 distinct clusters (see Figure 14) operating Stealc since March 2025.

Conclusion

For global disruption operations such as Operation Endgame against Amadey and Stealc, long-term automated tracking of malware is necessary. This blogpost presents information collected in that manner but also provides details on the specific MaaS business model behind each family and how that translates into often fragmented network infrastructure, documents their key static identifiers and C&C communication protocols, and outlines how ESET researchers helped to identify critical points for the disruption. Our threat intelligence on both Amadey and Stealc, combined with data shared by our partners, provided a strong foundation for both the disruption operation and law enforcement efforts.

Operation Endgame aimed to seize or render inoperative all known Amadey and Stealc C&C servers, directly disrupting the infrastructure relied upon by both MaaS offerings’ affiliates. ESET will continue to monitor both families and track any attempts to rebuild operational infrastructure following this disruption.

IoCs

A comprehensive list of indicators of compromise (IoCs) and samples can be found in our GitHub repository.

Files

Network

MITRE ATT&CK techniques

This table was built using version 19 of the MITRE ATT&CK framework.