Sality, the P2P botnet used to steal cryptocurrency, disrupted after 23 years

International operation isolates the criminal network

An international operation has disrupted the infrastructure of Sality, a peer-to-peer botnet first observed in 2003 that remained active for 23 years. Over time, the network distributed information stealers, proxy services, DDoS tools, and other malicious components.

The campaign involved CrowdStrike, law enforcement agencies from the United States, Bulgaria, Hungary, and Romania, and the Shadowserver Foundation. Shadowserver is working with Internet providers and CSIRTs to identify systems that remain compromised and coordinate remediation efforts.

The intervention combined two actions. CrowdStrike manipulated the P2P protocol to separate bots from nodes controlled by the operator, while law enforcement agencies removed or disabled the URLs hosting payloads distributed by the network.

According to CrowdStrike, the Sality operator is no longer able to communicate with infected machines. Systems that remain compromised are now sending their periodic traffic to sinkholes controlled by the company.

The botnet has therefore been neutralized operationally, but it has not been automatically removed from endpoints. The malware may still be present on affected devices.

Why Sality survived for so long

Sality’s longevity was largely due to its distributed architecture. Rather than relying on a single command-and-control server, the botnet used a P2P network through which nodes received updates, instructions, and new code.

The absence of a central infrastructure made a conventional takedown more difficult. Disabling a single server would not have been enough: infected devices could have continued communicating through other peers.

The backbone of the network consisted of compromised machines acting as super peers. Each bot maintained a list of these nodes and periodically checked whether they were reachable.

The protocol used an operational reputation system. A super peer that continued responding gained reliability, while an unreachable node progressively lost reputation until it was removed from the list. This allowed Sality to update its topology autonomously and preserve functioning communication paths.

Propagation also contributed to the botnet’s persistence. Sality operated as a file infector, inserting its code into executables stored on disks and removable media. A modified file transferred to another computer could therefore spread the infection beyond the original system.

This feature also complicates remediation. Stopping the malicious process or deleting a single file is not enough: organizations must identify modified executables and inspect media that may have carried the malware.

The weakness hidden in the P2P protocol

The same architecture that protected Sality for more than two decades contained a structural weakness. The protocol trusted peers without enforcing authentication or reliable checks of their identities.

CrowdStrike exploited this trust to intervene directly in the lists used by the bots. The operation gradually removed references to super peers belonging to the criminal infrastructure and replaced them with nodes dedicated to sinkholing.

A sinkhole is a system controlled by defenders that receives traffic previously directed to malicious infrastructure. It does not disinfect the computer, but it prevents or limits contact with the operator and enables defenders to observe residual communications.

In Sality’s case, manipulating the lists gradually isolated compromised machines. As the bots updated their view of the network, defender-controlled nodes replaced the super peers used by the operator.

The action against the URLs completed the intervention. By removing the resources from which Sality downloaded payloads, authorities prevented already infected devices from receiving new components through those channels.

This was not a publicly classified software vulnerability. No CVE identifier was provided, and no specific products or versions requiring a patch were reported as affected. The weakness exploited for the disruption involved the trust model of the botnet’s P2P protocol.

EggJagger and clipboard-based theft

Over the past eight years, Sality was reportedly used primarily to distribute EggJagger, a clipjacking tool associated with cryptocurrency theft.

This technique targets content copied to the operating system’s clipboard. During a transaction, a user may copy the recipient’s wallet address and paste it into the application or website used to make the transfer.

The malware intercepts that value and replaces it with an address controlled by the attacker. If the victim does not carefully compare the pasted string with the original, the transaction is authorized to the wrong wallet.

Once the transfer has been confirmed on the blockchain, recovering the funds can be extremely difficult. EggJagger reportedly stole at least $150,000 in Bitcoin and Ethereum. This is a minimum estimate and may not reflect all proceeds obtained through the campaign.

Sality’s impact, however, was not limited to cryptocurrency theft. The botnet supported information-stealing operations, abusive proxy distribution, and DDoS attacks, providing its operator with a platform adaptable to different criminal purposes.

Disruption does not mean malware removal

Isolating the network reduces the operator’s ability to issue commands and distribute new payloads. It does not remove Sality from computers that are already compromised, nor does it restore executables modified by the file infector.

Organizations should therefore inspect potentially exposed endpoints, paying particular attention to older systems, executable files transferred between devices, and removable media used across multiple machines. These media may retain infected copies and reintroduce the malware after incomplete remediation.

Organizations should also check for anomalies in cryptocurrency applications. Wallet addresses must be verified before authorizing every transaction, especially when they have been entered using copy and paste.

No file names, hashes, domains, IP addresses, or other strings that could be used directly as indicators of compromise have been published. There are also no known operational signatures or universal procedures for removing the infection.

Once sinkhole data becomes available to defenders, traffic directed to those systems may help identify endpoints that remain active. Communication with a sinkhole is a possible sign of residual infection, not proof that the machine has already been cleaned.

Remediation depends on ISPs, CSIRTs, and security providers

The Shadowserver Foundation is working with ISPs and CSIRTs to associate observed connections with victim systems and notify users and organizations. Anyone who receives an alert should treat it as a concrete indication of compromise and begin an endpoint investigation.

In the absence of publicly released removal tools and signatures, remediation should be coordinated with the organization’s provider, the relevant CSIRT, or a security vendor. The investigation should cover executables, removable media, and other devices that exchanged files with the infected machine.

It may be necessary to replace altered files with known-good copies or completely rebuild the system. The appropriate approach depends on the extent of the infection, which a file infector can make difficult to determine with certainty.

The operation stripped Sality’s author of control over the network and blocked the known channels used to distribute payloads. The next phase is less visible but critical: finding the machines that remain infected and removing the code that has continued operating after 23 years of propagation.