Sality Botnet Takedown Ends 23-Year Command Network

Sality botnet infrastructure has been disrupted after more than two decades of operation, cutting its peer-to-peer command channel off from more than 15,000 currently infected endpoints. The coordinated action did not automatically clean those computers, but it stopped the operator from using Sality’s known super-peer network to push new malicious files and download instructions.

Sality botnet disruption: the verified facts

CrowdStrike’s Counter Adversary Operations team said it worked with the US Department of Justice, FBI, Defense Criminal Investigative Service, Shadowserver Foundation, Europol and Eurojust, as well as authorities in Bulgaria, Hungary and Romania. Europol separately confirmed the international operation and said the United States led the 31 August action.

The figures describe different slices of the same system. CrowdStrike counted more than 15,000 infected machines receiving malicious payloads before the disruption. Europol said up to one million machines were available to the operator at Sality’s peak and that more than 11 million unique IP addresses had been associated with its infrastructure over time. Those totals are not interchangeable: an IP-history count can include changing addresses and machines seen at different moments.

Sality operation facts and their limits

Measure	Verified figure	What it means
Operation date	31 August 2026	Coordinated disruption date
Current payload recipients	15,000+ endpoints	Machines still connected before sinkholing
Peak access	Up to 1 million machines	Historical maximum cited by Europol
Lifetime footprint	11 million+ unique IPs	Addresses linked over more than two decades
EggJagger theft	At least ₽12.1 million	About $150,000 estimated by CrowdStrike

How the Sality botnet survived for two decades

Sality began as file-infecting malware in the early 2000s and later adopted a peer-to-peer design. A conventional botnet can become fragile when all infected machines depend on a small group of command servers. Sality instead let infected peers exchange lists of other peers and pass instructions through the network, making the system harder to disable at a single point.

The operator used specially positioned “super peers” as a communication backbone. These nodes helped circulate two kinds of instructions: file packs that transferred malware directly and URL packs that told an infected machine where to download a payload. That distinction matters because the Sality botnet was not merely a collection of infected PCs; it was a reusable delivery service that could change what those PCs ran.

BleepingComputer, TechRadar and Decrypt independently described the same mechanism after reviewing the coordinated announcements. Their accounts agree that the disruption focused on the command layer rather than remotely removing Sality from every device.

What the sinkholing operation actually changed

A sinkhole is infrastructure controlled by defenders that receives traffic intended for malicious systems. CrowdStrike said the operation replaced Sality’s known super-peer list with defender-controlled destinations, prevented file and URL packs from spreading, and purged infected machines’ existing peer lists. In effect, the investigators used the botnet’s own update process to isolate connected machines from the operator.

This is a disruption, not the same thing as a universal uninstall. A machine with the Sality infection can remain compromised even when it can no longer receive the operator’s current commands. If defenders lose control of the sinkhole or an unlisted route survives, the residual infection may still matter. Organisations therefore need endpoint-level investigation instead of treating the international announcement as an all-clear.

The distinction mirrors a broader lesson in our coverage of the AI cyberattack speed gap: stopping infrastructure can reduce immediate harm, but recovery still depends on knowing which assets were touched and how trust will be restored.

EggJagger shows why payload delivery mattered

CrowdStrike tied Sality to a clipboard-hijacking payload called EggJagger. Cryptocurrency users often copy a long wallet address before sending funds. EggJagger watched the clipboard and substituted an address controlled by the attacker, redirecting a payment if the user failed to notice the change.

The security company estimated that this technique stole at least 12.1 million Russian rubles, roughly $150,000, across Bitcoin, Ether and other cryptocurrency networks. The amount is a lower-bound estimate based on observable transactions, not a complete accounting of everything Sality enabled. The botnet could also distribute other code, proxy traffic or change its payload mix.

What security teams should do after the Sality botnet takedown

First, identify Windows systems that have exchanged traffic with known Sality infrastructure or exhibit file-infector behaviour. Network telemetry can reveal sinkhole connections, while endpoint tools can identify altered executables, persistence and secondary payloads. Shadowserver notifications can help network owners locate exposed addresses, but address ownership still has to be mapped to real assets.

Second, isolate suspected machines before attempting recovery. Because Sality infects executable files, deleting one obvious sample may leave modified programs behind. Reimaging from a trusted source can be safer than trying to clean a deeply affected host, especially where integrity matters.

Third, reset credentials and inspect downstream access. A long-lived infection may have delivered tools unrelated to the final command channel. Teams should examine identity logs, privileged accounts, remote-access software, cryptocurrency operations and any system that exchanged files with the affected endpoint.

Finally, treat the operation as intelligence about resilience. The AI agent security problem looks technologically different, but the control principle is similar: prevent one compromised component from becoming a durable distribution layer across the organisation.

Why disruption required public and private partners

The Sality botnet crossed national borders by design. An infected computer could sit in one country, exchange peer information with a second and download a payload hosted in a third. No single company or police agency could compel every network owner to act at the same moment.

CrowdStrike brought current knowledge of the malware protocol and the nodes that mattered. Shadowserver contributed internet-scale visibility and a channel for notifying network operators. National investigators and prosecutors supplied legal authority, while Europol and Eurojust supported coordination across jurisdictions. The value of the partnership was synchronisation: a partial or early intervention could have warned the operator and encouraged a move to fresh infrastructure.

The agencies have not publicly claimed that an arrest ended the case, and the published accounts focus on infrastructure disruption. That wording should be preserved. Taking control of communication routes can protect victims immediately even when attribution, charging decisions or extradition take longer.

Why the network can still teach defenders something

Sality’s age is not evidence that its code was unbeatable. It is evidence that decentralisation, replaceable hosts and neglected endpoints can keep a criminal service useful. Modern security programmes often prioritise the newest exploit, yet an old infection can remain profitable if it still delivers payloads or steals payments reliably.

The operation also shows why inventory data must connect network addresses to devices and owners. A sinkhole may reveal an address that is contacting known malicious infrastructure, but responders still need to identify the laptop, virtual machine or customer connection behind that address. Without that mapping, high-quality threat intelligence can stop at the edge of the organisation.

Organisations should also avoid treating a quiet endpoint as a healthy endpoint. Once the command path is cut, malicious traffic may fall sharply even though modified files, stolen credentials or scheduled persistence remain. Historical endpoint logs, software hashes and authentication records can reveal activity that a present-time network scan misses.

For smaller businesses without a dedicated incident-response team, the practical order is containment, preservation and expert review. Disconnect the suspected system, preserve relevant logs, record the time and symptoms, and avoid reconnecting it merely because antivirus reports one deleted file. Recovery should start from trusted installation media and known-good backups, followed by credential rotation from a separate clean device.

Why the Sality botnet story matters

The Sality botnet disruption matters because it neutralised a peer-to-peer delivery channel that had survived since 2003, while also showing that infrastructure takedowns do not clean infected endpoints automatically. The public-private operation reduced the operator’s reach, but asset owners retain the final responsibility for containment and recovery.

The most useful source material is CrowdStrike’s technical account of the Sality operation and Europol’s international disruption notice. Both support the mechanics and scale reported here; independent accounts from BleepingComputer, TechRadar and Decrypt corroborate the central event.

Frequently asked questions

Was the Sality botnet completely removed?

No. The known command-and-payload channel was disrupted, but infected endpoints may still contain Sality or other malware and require local remediation.

How did defenders stop a peer-to-peer botnet?

They sinkholed the known super peers, blocked file and URL pack propagation, and used the network’s update mechanism to purge peer lists.

Why do the 15,000 and 11 million figures differ?

More than 15,000 refers to endpoints receiving payloads around the operation. More than 11 million is a historical count of unique IP addresses linked over the botnet’s lifetime.

What should an affected organisation do?

It should isolate suspected hosts, validate file integrity, reimage when necessary, reset exposed credentials and investigate secondary payloads or lateral movement.