How Sality Was Disrupted

No single point of failure — but one trust flaw.

A network with no single point of failure can still fail at something much simpler: trust.

Sality is a textbook example.

Most botnets give security analysts an obvious target: a command-and-control (C2) server that can be taken down, blocked, or sinkholed. Sality avoided that trap for more than twenty years.

First seen in 2003, Sality later evolved into a peer-to-peer (P2P) network. Infected computers spoke directly with one another, shared updates, and passed commands without relying on a master server.

Take individual machines offline and the rest of the network can keep talking.

That resilience helped Sality remain active for more than two decades. But underneath it was a basic flaw: the network was decentralized, yet it had no peer authentication.

Sality was built to survive when nodes were lost. It was never built to check who was actually knocking on its door.

Defenders did not need to chase a hidden command server. They only had to learn how to appear as another peer.

Resilient Doesn't Mean Trusted

According to CrowdStrike, a publicly reachable machine that completed Sality's P2P handshake correctly could be treated as a peer. There was no peer authentication, no cryptographic identity, and no allowlist controlling who could join.

But there is an important distinction here.

Sality did verify signed payloads using embedded public keys. The malware would not simply accept an update because another machine sent it.

Network membership was different.

If a machine spoke Sality's protocol correctly, the botnet could accept it as a peer and use the information it provided for routing and peer discovery.

For years, that open-door policy helped keep the botnet self-healing and difficult to shut down.

In the end, defenders turned the same feature against it.

The Routing Table as an Attack Surface

Every Sality bot kept a finite list of "super peers" — publicly reachable infected machines that formed the backbone of the P2P network.

CrowdStrike's operation did not try to break Sality from the outside. Defenders followed Sality's own rules.

They created sinkhole nodes that behaved like legitimate Sality peers. With no peer authentication, the botnet had no reliable way to distinguish those machines from genuine participants.

The peer-discovery mechanism then became the attack surface.

Defenders manipulated peer lists so infected machines lost legitimate peers and picked up defender-controlled sinkholes instead. As those lists changed, more bots became isolated from the operator's network.

Once isolated, those machines could no longer receive new URL packs or file packs through the normal Sality P2P network.

At the same time, law enforcement seized Sality-linked domains in the United States and Europe. Shadowserver worked with network operators and incident-response teams to identify infections and help notify victims.

This was not the classic botnet takedown where investigators find one central server and pull the plug.

There was no single server to seize.

Instead, Sality's own network design was turned against its operator.

The Authority Problem in Distributed Systems

Decentralization solved one problem for Sality: it removed the central server as a single point of failure.

But it left another question largely unanswered:

Who is actually allowed to participate in the network?

How do you know whether a peer is really part of your system?

What happens when an outside machine can speak your protocol just as well as a legitimate node?

Those questions go far beyond malware research.

P2P storage systems, Web3 protocols, and other distributed networks can all become highly resilient while still getting the membership boundary wrong. Removing the center does not automatically solve the authority problem.

If a system carefully checks signatures on messages but leaves peer admission wide open, an attacker may not need to break the cryptography at all.

They may just need to join the network.

That is the part of Sality I find most interesting. The botnet could verify what it was being told, but it was much worse at verifying who it was talking to.

One boundary matters here: disrupting Sality's command channel did not remove the malware already installed on infected machines. CrowdStrike says those systems still require remediation.

Sality survived for more than twenty years partly because there was no central server that defenders could simply destroy.

Its disruption came from a different direction: defenders found a way to become part of the network itself.

Decentralization made Sality difficult to shut down. Weak peer authentication gave defenders a way in.

Further Reading

CrowdStrike: Peer Pressure: Inside the Sality Botnet Disruption Operation

U.S. Department of Justice: Sality Malware Disrupted in International Cyber Takedown