Sality Botnet Disruption: How Defenders Turned a P2P Network Against Itself

A botnet can lose its operator while its victims still have an incident to resolve. That is the uncomfortable part of the Sality disruption: a successful infrastructure operation gives defenders an opportunity, but somebody still has to account for each compromised computer.

On 1 September 2026, the US Department of Justice announced an international operation against Sality, a malware operation it traces back to 2003. The action combined a peer-to-peer sinkhole operation with domain seizures in the United States and action against associated domains in Bulgaria, Hungary, and Romania. Europol and Eurojust supported the effort. DOJ announcement.

The interesting question is how defenders interrupt a network whose infected machines communicate directly with one another. The operational question is what evidence allows a security team to declare its own machines trustworthy again.

TL;DR

• The international operation targeted Sality’s communications and supporting infrastructure.
• A distributed network still has trust boundaries worth examining.
• Use the disruption as a trigger for endpoint investigation, with explicit evidence requirements for recovery.
• Separate historical malware behavior, current operation reporting, and conclusions about your own environment.

Why a file infector deserves attention in 2026

Microsoft’s historical Sality analysis describes infection of Windows executables, including .exe and .scr files, and propagation through removable media and network shares. It also documents security interference, such as stopping protective software and changing security settings. These are family-level observations from an entry updated in 2017, not a claim that every behavior occurred on every endpoint in the latest operation. Microsoft’s Win32/Sality description.

This changes the investigation. A suspicious executable may be a legitimate application that has been modified. Deleting one obviously malicious download is a poor stopping point when other programs might contain injected code.

Consider a hypothetical maintenance workstation with a shared folder of portable utilities. If an executable in that folder becomes infected, the investigation must account for both the workstation and the people who copied or ran that utility. Replacing the workstation while preserving the contaminated software collection could undermine the recovery.

That example is an investigation model, not a reported victim story. Its purpose is to make scope tangible: identify the files, users, shared locations, and removable media that connect the affected host to the rest of the organization.

Sality’s architecture was already the subject of a 2011 Symantec research paper. Its contemporary overview described a decentralized network used to distribute additional malware for activities including spam, proxying, and information theft. That historical analysis establishes that the design was understood long before this operation; it does not establish the present size or workload of the network. Symantec research overview.

For defenders, the age of a malware family is a poor prioritization shortcut. Exposure, execution, and the ability to restore trusted systems matter more than whether the name appeared in this week’s threat report.

How the network was disrupted

CrowdStrike dates the coordinated action to 31 August 2026. Its technical account describes peers accepted without cryptographic identity verification. Defenders manipulated peer lists, removed entries connecting bots to the criminal network, and inserted sinkholes. Publicly reachable super peers were targeted first; hosts behind NAT could be reached through their subsequent contact with sinkhole nodes. Payload-hosting URLs were also taken down. CrowdStrike’s operation analysis.

A sinkhole is infrastructure used to receive or redirect traffic that would otherwise support malicious activity. In an investigation, that traffic can help identify affected networks. Its value depends on what the team can observe and how those observations reach someone capable of repairing the host.

The DOJ says Shadowserver was working with internet service providers and computer security incident response teams to support infection identification, victim notification, and remediation. That notification chain is part of the response, not an administrative detail after the technical work. DOJ announcement.

Two different trust questions

CrowdStrike also describes RSA keys used to verify payload signatures. That protection coexisted with weak peer admission. Payload authenticity and trustworthy network membership were separate properties. Technical analysis and detection material.

The general security lesson is useful beyond malware. A system can verify the origin of a message while relying on an untrustworthy mechanism to locate the next participant. Signing a package does not automatically authenticate the directory, routing table, or discovery service that helps deliver it.

For an architecture review, ask three questions separately:

This is an analytical framework for reviewing distributed systems. It is not a claim that every P2P network shares Sality’s weaknesses. Decentralization describes where work happens; the protocol still determines whom participants trust.

What the announcement establishes—and what to measure locally

Treat the operation report as evidence of coordinated disruption. Treat endpoint recovery as a separate claim requiring local evidence.

CrowdStrike explicitly warns that installed malware remains active even though the disruption prevents delivery of new payloads. Its report also identifies EggJagger, a cryptocurrency-address clipboard replacer, as a major payload. CrowdStrike analysis.

For incident response, distinguish four milestones:

1. Infrastructure disruption: the adversary’s communications or delivery capacity is interrupted.
2. Host containment: the organization limits an affected machine’s ability to cause further harm.
3. Eradication: investigators address malicious software and contaminated files within the established scope.
4. Recovery: the organization restores service and verifies the required security controls.

These milestones need different owners and evidence. An external takedown cannot answer whether an administrator restored an infected utility from an old backup yesterday.

Be equally careful with botnet population figures. Public IP addresses, distinct endpoint identifiers, and observations collected over time measure different things. NAT can put several machines behind one address; address reassignment can give one machine several addresses. Without a measurement window and deduplication method, a large number tells an incomplete story. This article deliberately avoids presenting an IP total as a count of simultaneously infected computers.

Detection: turn an indicator into an investigation

CrowdStrike published 188.166.101[.]148 as a UDP lighthouse indicator and supplied memory-scanning YARA rules. Consult the dated source when using these indicators. Published detection guidance.

Record the destination’s role as defender-operated infrastructure. Labeling every relevant IP as an attacker-controlled server creates misleading incident timelines and can cause analysts to misinterpret later traffic.

The following is an illustrative Microsoft Defender XDR Advanced Hunting query. Its columns follow Microsoft’s documented DeviceNetworkEvents schema; the table requires Defender for Endpoint data. It has not been executed against a live tenant. Microsoft schema reference.

DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteIP == "188.166.101.148"
| where Protocol =~ "Udp"
| project Timestamp, DeviceId, DeviceName, ActionType,
          LocalIP, RemoteIP, RemotePort,
          InitiatingProcessFileName, InitiatingProcessFolderPath,
          InitiatingProcessCommandLine, InitiatingProcessSHA1
| order by Timestamp desc

The address is intentionally usable in the query and defanged in prose. Searching existing telemetry does not contact it. Adjust the time window to retained data, and inspect ActionType before describing an event as successful communication.

A match should lead to a host investigation, not merely a firewall ticket. Establish which device and process produced it, whether the activity belongs to an authorized research environment, and what evidence supports a production infection. Preserve the event timestamp and device identifier so that DHCP changes or renamed machines do not break the trail.

An empty result is narrower evidence: this query found no matching records in the searched dataset. It says nothing about unmonitored endpoints, expired logs, or telemetry gaps. Check sensor coverage before interpreting silence as fleet-wide absence.

For network-only observations, correlate the source address and timestamp with DHCP, VPN, and NAT records. An external notification naming a public address should become a device-level lead wherever possible. Otherwise, the team risks investigating whichever machine happens to hold the address now.

Recovery: define what “clean” means before closing the ticket

The following workflow is a recommended response approach, not a description of actions performed by the international operation.

1. Contain and preserve useful evidence

Use the organization’s endpoint isolation or network containment process. Preserve available process, connection, file, and security-alert evidence before rebuilding, where incident priorities permit. Avoid delaying containment solely to collect a perfect forensic image.

Document the earliest observed activity, the user’s access, and the shared locations the device could modify. Keep investigation copies separate from software that administrators might accidentally reuse.

2. Establish the file and exposure scope

Identify applications associated with detections, their installation sources, and any copies on shared storage or removable media. Review software repositories writable by ordinary users. A recovered workstation should not reconnect to a software collection that has never been assessed.

Microsoft notes that Sality can leave security settings altered even after cleaning. Verification therefore needs to include the security configuration as well as malware detections. Use current platform guidance when restoring controls; the historical family entry contains legacy Windows examples that should not be copied blindly into a modern environment. Microsoft family guidance.

3. Choose a recovery method you can defend

Where executable integrity cannot be established, prefer rebuilding from trusted installation media and reinstalling applications from verified sources. This is a risk-based recommendation, not a claim that every Sality detection makes repair impossible.

Treat restored executable content as a separate approval decision. A backup’s existence says nothing about whether it predates the compromise. Restore required business data through the organization’s scanning and recovery process, and validate the resulting system before returning it to normal access.

Review credentials and sessions used on the affected host according to the observed payloads, exposure window, and account privileges. Resetting a password from the same untrusted machine is a poor recovery step. Use a known-clean device and revoke relevant sessions where warranted.

4. Require evidence of restored protection

Agree on closure criteria before the pressure to return a machine to service arrives:

Choose a follow-up monitoring period based on the environment’s coverage and operating cycle. Include intermittent devices and restored applications in that decision. A machine that stays powered off throughout observation has not provided reassuring telemetry.

The practical value of the takedown

The Sality operation gives defenders a concrete reason to revisit systems that may have escaped routine attention. Start with asset coverage, search available telemetry, investigate credible matches, and make the recovery decision at the host and shared-storage level.

For teams designing distributed systems, the case raises a second question: which security property does each cryptographic check actually establish? A signature, an authenticated participant, and an available route solve different problems. Security reviews should test each boundary explicitly.

An incident closes when the organization can explain what was affected, what it restored, and what evidence supports that decision. A takedown announcement is a valuable starting point for that work.

Related Posts

• FBI Seizes NetNut: How a 2-Million-Device Proxy Botnet Hid Inside Smart TVs — another infrastructure operation involving compromised devices and criminal services.
• DFIR 2026: Memory Forensics, Windows Artifacts, and Incident Response — evidence collection and investigation techniques for the endpoint work that follows.

Sources

• Europol: Global public-private operation disrupts Sality botnet active for two decades — the originating Europol announcement.
• US Department of Justice: Sality Malware Disrupted in International Cyber Takedown, 1 September 2026 — international action and victim-notification coordination.
• CrowdStrike: Peer Pressure: Inside the Sality Botnet Disruption Operation, 1 September 2026 — participating researchers’ technical account and detection material.
• Microsoft Security Intelligence: Win32/Sality, updated 15 September 2017 — historical family behavior and remediation considerations.
• Symantec: Sality: Story of a Peer-to-Peer Viral Network, research overview posted 7 October 2011 — historical architectural context.
• Microsoft Learn: DeviceNetworkEvents — Advanced Hunting field definitions and data requirements.