This article is also available in Japanese: Japanese version.

Background

Amadey is a bot-type malware targeting Windows that has been observed since around October 2018. It is responsible for collecting information from infected machines, conducting C2 communications, and retrieving and executing additional payloads, and it is known to be abused as an initial-access foundation for information-stealing malware and ransomware. Its primary infection vectors have been reported to include phishing emails, bundling with pirated software, and distribution via exploits.

In June 2026, Our Cyber Intelligence Group (CIG) took part in the Microsoft-announced project to take down the Amadey / StealC infrastructure. As a result, the activity of both malware families is expected to be substantially curtailed. The press release for this project is available here.

About the Cyber Intelligence Group (CIG) CIG is a specialized team within Mitsui Bussan Secure Directions (MBSD) responsible for malware analysis, investigating the real-world activities of ransomware groups, and the collection and analysis of threat intelligence. In addition to publishing information based on its own original research, the team is also engaged in explaining threat trends through the media.

At this juncture, which we believe marks a turning point for Amadey's activity, this blog post shares with our readers the insights gained from roughly six and a half years of observing Amadey's C2 servers by the CIG team. Drawing on findings from this long-term data analysis, and using observational data spanning from Amadey's earliest appearance through to the intervention by law enforcement, we examine how a single malware family expanded its influence and seeded malware through its infrastructure. Furthermore, we look to understand the broader ecosystem that emerges from these long-term C2 server observations.

How Amadey Works

Many articles already exist that provide detailed analyses of Amadey, so rather than covering those details, this blog post explains how Amadey's C2 communication works.

As of 2026, the Amadey C2 communication that we have been able to confirm operates by encrypting binary data with an RC4 key, converting it into a hexadecimal string, and exchanging it in that form.

Figure 1 shows an excerpt of an Amadey C2 server address along with the check-in request and response data. Amadey prepares data containing its version information (5.77 in Figure 1) and information about the infected machine as parameters for the initial check-in request directed at the C2 server address, and encrypts it using the RC4 key embedded in the binary. The encrypted binary data is converted into a hexadecimal string and concatenated to "r=", and this becomes the initial check-in data that the Amadey C2 server receives. The C2 server converts the hexadecimal string data back into binary data and decrypts it using the RC4 key, thereby obtaining the initial check-in data. After that, depending on the C2 server's configuration, it sends data such as additional payloads to the infected machine. This data, too, is RC4-encrypted and then converted into a hexadecimal string. After the infected machine receives the response data, it converts the hexadecimal string data into binary and performs RC4 decryption, allowing it to obtain information such as the additional payload.

Figure 1. Amadey - C2 server address, check-in request, and check-in response

Data Collection

From October 24, 2019 to June 3, 2026, we sent check-in requests to Amadey's C2 servers twice a day and collected the responses. The total number of C2 servers examined during this period was 741, and of these, the number of C2 servers from which we were able to receive the expected response from an Amadey C2 server at least once was 493. The C2 server addresses targeted in this investigation were collected from open sources (OSINT).

Using an emulator that implemented the functionality described in the previous section on how C2 communication works, we sent initial check-in requests that could be correctly decrypted on the Amadey C2 server side, and accumulated the response data obtained from the Amadey C2 servers. The data used in the following sections is the result of analyzing this accumulated data.

Trends in the Number of Active C2 Servers

Figure 2 is a graph that tabulates, on a daily basis, the number of C2 servers from which the expected response could be obtained after sending a check-in request. After trending steadily upward until around February 2022, it gradually shifted to a downward trend. We can see that it took Amadey several years to establish a significant presence.

Figure 2. Daily trend in the number of active C2 servers

Once we began tracking, the daily number of active C2 servers ranged roughly between 2 and 18 until around September 2022. From January 2023 to early December 2023, however, this figure rose to between 5 and 30, suggesting that Amadey had come into widespread use. In 2024, after a brief dormant period, the daily count gradually declined from a peak of 17 and has continued to fall to the present day.

C2 Server Activity Duration

Figure 3 shows the distribution of Amadey's C2 servers classified by their number of active days into predefined periods. While the majority of C2 servers ceased activity in under 60 days, some C2 servers remained active for over a year.

Figure 3. Distribution of active days across Amadey's C2 servers

C2 servers that were active for 1 to 7 days accounted for 20.69% of the total, and adding those active for 8 to 30 days brings this to 57.00%, showing that roughly half ceased activity within 30 days. Extending the range to include those active within 60 days brings the figure to 79.51%, and including those within 90 days brings it to 89.05% — meaning that in Amadey's case, approximately 90% of the C2 servers ceased activity within 90 days. On the other hand, about 10% of the C2 servers continued operating for longer than 90 days: 2 servers were active for one year or more but less than two years, and 2 servers continued operating for two years or more.

These findings suggest that defenders should keep in mind that even if they are infected with malware whose first appearance dates back a year, they may still end up connecting to a C2 server that has been active over a long period.

Trends in Malware Distributed via Amadey

Figure 4 shows the number of malware samples distributed via Amadey, where the number of unique additional payloads obtained daily is summed up by year.

Figure 4. Daily unique additional payload counts summed by year

We found that the count basically trended upward from the start of observation through 2025. While there were 66 in 2019 and 260 in 2020, the figure reached 1,231 for the year in 2021 and 3,500 in 2022, from which we can infer that Amadey had come to be recognized as an infrastructure for distributing malware. In 2023, the annual total reached 8,360. This year coincided with the period in which the number of daily active C2 servers increased sharply, and we can see that the total number of malware samples distributed surged. In 2024, the figure decreased slightly to 7,619, but Amadey was still distributing a large amount of malware throughout the year. In 2025, the total reached 11,635, surpassing 2023. Given that the number of daily active C2 servers was on a downward trend, we can see that each individual C2 server was distributing a large amount of malware. For 2026, although the figure is not an annual total, it currently stands at 1,837.

One contributing factor to the smaller volume of malware distribution in 2026 was that, even when we accessed the additional payload URLs received from a certain C2 server, no PE executable was present. From this, we can infer that the attacker using that C2 server may not be performing regular maintenance.

Hosting Locations of Malware Distributed via Amadey

Figure 5 is a graph that analyzes the URLs of malware distributed from Amadey's C2 servers and displays the top 20 by the number of URLs associated with each domain or IP address.

Figure 5. Top 20 IP addresses and domains by additional payload URL count

While the majority are IP addresses, malware is also being distributed from widely known services such as cdn[.]discordapp[.]com, bitbucket[.]org, and github[.]com. Because such legitimate, widely used services are often allowed through corporate firewalls, preventing malware intrusion requires checks not only at the network level but also at the endpoint level.

Conclusion

This blog presents an excerpt of the insights gained from approximately six and a half years of observational data on Amadey's C2 servers.

Observing the changes in the number of daily active C2 servers and the trends in malware distribution via Amadey, it became clear that, although there was no notable activity for the first several years after Amadey's appearance, it expanded rapidly from around the four-to-five-year mark. This suggests that even malware which attracts no attention at the time of its emergence may, after a dormant period, abruptly establish a significant presence. It is therefore advisable to build a defensive posture with the awareness that even an obscure malware family at its initial appearance may, several years later, come to wreak havoc.

The graph of C2 server activity periods shows that approximately 57% of C2 servers ceased activity within 30 days. While this aligns with the conventional wisdom that C2 servers are, in many cases, short-lived, some C2 servers continued operating for over a year. This means that even if the malware behind an infection did not first appear within the past few months, there remains a possibility of connecting to a C2 server that has been active over a long period. It bears repeating that, regardless of whether the malware is new or old, an infection results in data being leaked to the C2 server.

Examining the domains and IP addresses of the URLs hosting malware distributed via Amadey reveals that malware is in some cases downloaded from widely known services that are used on a daily basis. For this reason, it is necessary to verify whether a retrieved file is malware not only at the network level but also at the endpoint.

Acknowledgments

This operation brought together Microsoft alongside law enforcement agencies including Europol's European Cybercrime Centre (EC3), Germany's Federal Criminal Police Office, the Danish Police, and the Dutch Police, as well as private-sector security companies such as ESET, BitSight, Lumen, IBM, and Proofpoint. MBSD extends its gratitude to everyone involved for their dedication and collaboration on this effort.

Figure 6. Splash page

The insights gained from the CIG team's observation of Amadey's C2 servers over approximately six and a half years enabled us to make a meaningful contribution to the Microsoft-led takedown of Amadey and StealC.

MBSD remains committed to advancing a secure digital society—not only within Japan but through global public-private collaboration.