Sality P2P Botnet Dismantled: Detection and Eradication Guide for Residual Infections

On August 31, 2026, the U.S. Department of Justice — working with authorities in Bulgaria, Hungary, and Romania, plus private partners CrowdStrike and the Shadowserver Foundation — executed a coordinated takedown of the Sality botnet, one of the longest-lived peer-to-peer compromised device networks in operation. Rather than seizing centralized infrastructure (Sality has none), law enforcement turned the botnet's own P2P protocol against itself, poisoning the peer mesh and cutting off the distribution of new malicious payloads to infected hosts.

This is a significant win — but it is not a cleanup. Takedowns decapitate command and control; they do not remove malware from infected endpoints. Every machine in your environment that was part of the Sality mesh is still infected. The file-infecting payload is still on disk, still attempting to beacon, and still capable of receiving follow-on instructions if any residual C2 infrastructure or successor operation reconstitutes. Defenders have a window right now — while the botnet is blind — to find and eradicate these infections before someone reassembles the pieces.

Why Sality Still Matters to Defenders

Sality is not a memory from a textbook. It is a resilient, actively maintained malware family that survived for over two decades precisely because of its architecture:

• No central C2 to seize. Sality uses a decentralized P2P overlay for command distribution. Infected nodes exchange payload URLs and updates directly with each other. That is why this operation required protocol-level poisoning rather than domain seizure or server takedown.
• File-infecting behavior. Unlike droppers or implants, Sality is a polymorphic file infector — it injects malicious code into legitimate executables. This has two consequences: infections spread laterally through shared executables and removable media, and infected machines cannot be safely "cleaned" by deleting a single malicious file — the malware lives inside otherwise-legitimate binaries.
• Defense impairment. Sality historically disables or interferes with antivirus and security services, meaning infected hosts often show fewer alerts, not more.
• Removable media propagation. Sality spreads via USB drives and network shares using autorun.inf and infected executables — a technique that still works in environments with legacy systems, manufacturing floors, and poorly controlled peripheral policies.

The takedown severs payload delivery, but the implant's local behaviors — file infection, service tampering, lateral propagation — continue on any host that remains compromised.

Technical Analysis: What an Infected Host Looks Like

Because no CVE is involved, detection here is purely behavioral. Based on Sality's documented tradecraft, an infected endpoint typically exhibits:

1. P2P mesh beaconing: High-volume UDP traffic to a large number of distinct external IP addresses on non-standard ports, with no associated DNS lookups (P2P peers are exchanged host-to-host, not resolved via DNS). This is your strongest network-side signal.
2. Executable modification: A running process opening and writing to large numbers of .exe files — the file-infection routine. Legitimate software almost never rewrites other executables outside of installers and updaters.
3. Security service tampering: Attempts to stop, disable, or delete antivirus/EDR services via service control manager, registry modification of service Start values, or process termination.
4. Removable media staging: Creation of autorun.inf files on removable or network-attached drives, often alongside an infected executable with a benign-looking name.
5. Persistence: Registry Run keys pointing to payloads in %TEMP%, %APPDATA%, or user profile paths.

Exploitation status: Not applicable — this is a malware family, not a vulnerability. The C2 layer is currently disrupted by law enforcement sinkholing, but residual infections remain active on-disk threats. Treat this as a confirmed-active compromise scenario for any host matching the indicators below.

Detection & Response

Sigma Rules

The following rules target the highest-fidelity, lowest-noise behaviors associated with Sality-class infections. The autorun staging and security-service tampering rules are reliable; the Run-key rule requires baseline tuning for your environment.

---
title: Autorun.inf Creation on Removable or Network Drives
id: 3f8c2a91-7d4e-4b6a-9f21-8c5e6d7a2b34
status: experimental
description: Detects creation of autorun.inf files, a propagation technique used by Sality and other file-infecting malware to spread via removable media and network shares.
references:
  - https://attack.mitre.org/techniques/T1091/
  - https://thehackernews.com/2026/09/authorities-turn-salitys-p2p-network.html
author: Security Arsenal
date: 2026/09/02
tags:
  - attack.lateral_movement
  - attack.t1091
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith: '\autorun.inf'
falsepositives:
  - Rare in modern environments; legitimate software distribution media creation tools
level: high
---
title: Security Service Disabled via Registry Modification
id: 9a4e1b72-2c6d-4f83-b5e4-7d9a3c1e5f08
status: experimental
description: Detects registry modifications that disable security product services by setting their Start value to disabled, consistent with Sality's defense-impairment behavior.
references:
  - https://attack.mitre.org/techniques/T1562/001/
  - https://thehackernews.com/2026/09/authorities-turn-salitys-p2p-network.html
author: Security Arsenal
date: 2026/09/02
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: registry_set
  product: windows
detection:
  selection_path:
    TargetObject|contains:\\CurrentControlSet\\Services\\
    TargetObject|endswith: '\\Start'
  selection_value:
    Details: 'DWORD (0x00000004)'
  filter_paths:
    TargetObject|contains:
      - 'Services\\TrustedInstaller'
      - 'Services\\wuauserv'
  condition: selection_path and selection_value and not filter_paths
falsepositives:
  - Administrators intentionally disabling services during troubleshooting
  - Software deployment tools reconfiguring services
level: high
---
title: Run Key Persistence Pointing to User-Writable Paths
id: 5d2c7f14-8a9b-4e35-a1c6-2f4b8d6e9a73
status: experimental
description: Detects persistence via registry Run keys where the payload resides in temp or user-profile directories, a common Sality persistence pattern.
references:
  - https://attack.mitre.org/techniques/T1547/001/
  - https://thehackernews.com/2026/09/authorities-turn-salitys-p2p-network.html
author: Security Arsenal
date: 2026/09/02
tags:
  - attack.persistence
  - attack.t1547.001
logsource:
  category: registry_set
  product: windows
detection:
  selection_key:
    TargetObject|contains:
      - '\\Software\\Microsoft\\Windows\\CurrentVersion\\Run'
  selection_path:
    Details|contains:
      - '%TEMP%'
      - '\\AppData\\Local\\Temp\\'
      - '\\Users\\Public\\'
      - '%APPDATA%'
  condition: selection_key and selection_path
falsepositives:
  - Legitimate user-installed applications that self-update from AppData
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts for the P2P mesh signature: a device initiating outbound connections to an abnormally large number of distinct external IPs over a short window, with no corresponding DNS activity — the hallmark of peer exchange rather than name-resolved traffic. Tune the threshold (100 distinct peers per hour) to your environment's baseline; P2P botnets generate an order of magnitude more peer diversity than any legitimate business application except sanctioned file-sharing (which itself should be policy-prohibited).

// Hunt for P2P botnet mesh behavior: high peer diversity, no DNS correlation
let lookback = 24h;
let window = 1h;
DeviceNetworkEvents
| where TimeGenerated > ago(lookback)
| where ActionType == "ConnectionSuccess"
| where RemoteIPType == "Public"
| where RemotePort !in (80, 443, 53, 25, 587, 993, 995)
| summarize DistinctPeers = dcount(RemoteIP), Peers = make_set(RemoteIP, 50),
            Ports = make_set(RemotePort, 20), InitiatingProc = make_set(InitiatingProcessFileName, 10)
    by DeviceName, bin(TimeGenerated, window)
| where DistinctPeers > 100
| project TimeGenerated, DeviceName, DistinctPeers, Ports, InitiatingProc, Peers
| sort by DistinctPeers desc
;
// Corollary: autorun.inf staging on any drive
DeviceFileEvents
| where TimeGenerated > ago(lookback)
| where FileName =~ "autorun.inf"
| project TimeGenerated, DeviceName, FolderPath, InitiatingProcessFileName, SHA256
| sort by TimeGenerated desc

Velociraptor VQL

Use this hunt to enumerate endpoints with abnormally high peer counts on non-standard UDP ports combined with autorun artifacts — the combination of network mesh behavior and removable-media staging is a high-confidence Sality indicator.

-- Hunt for processes with high peer diversity plus autorun.inf artifacts
SELECT Pid, Name, Path, Username,
       Lport, Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort, Status
FROM netstat()
WHERE Status =~ 'ESTABLISH|SYN|LISTEN'
  AND RemotePort NOT IN (80, 443, 53)
  AND NOT Raddr.IP =~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)'
GROUP BY Pid, Name, Raddr.IP, RemotePort
HAVING count(group_by=Pid) > 50

-- Separately: locate autorun.inf files across fixed and removable drives
LET autorun_hunt = SELECT FullPath, Size, Mtime
FROM glob(globs=['C:/**/autorun.inf', 'D:/autorun.inf', 'E:/autorun.inf', 'F:/autorun.inf'],
          accessor='ntfs')
SELECT * FROM autorun_hunt

Remediation & Verification Script

Run this on suspected endpoints (or deploy via your RMM/EDR for fleet-wide assessment) to verify hardening controls and surface indicators. It does not attempt malware removal — see the remediation section for why file-infector cleanup requires reimaging.

# Sality-class infection assessment and AutoRun hardening verification
# Run as Administrator. Review output before taking action.

$report = [ordered]@{}

# 1. Check AutoRun/AutoPlay hardening (NoDriveTypeAutoRun = 0xFF disables all)
$autorunKey = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer'
$noDriveType = (Get-ItemProperty -Path $autorunKey -Name 'NoDriveTypeAutoRun' -ErrorAction SilentlyContinue).NoDriveTypeAutoRun
$report['AutoRunDisabled'] = ($noDriveType -eq 255)

# 2. Enforce AutoRun disablement if not set
if (-not $report['AutoRunDisabled']) {
    New-Item -Path $autorunKey -Force | Out-Null
    Set-ItemProperty -Path $autorunKey -Name 'NoDriveTypeAutoRun' -Value 255 -Type DWord
    Set-ItemProperty -Path $autorunKey -Name 'NoAutorun' -Value 1 -Type DWord
    $report['AutoRunRemediated'] = $true
}

# 3. Scan for autorun.inf on all mounted volumes
$report['AutorunArtifacts'] = Get-PSDrive -PSProvider FileSystem | ForEach-Object {
    Get-ChildItem -Path "$($_.Root)autorun.inf" -Force -ErrorAction SilentlyContinue
} | Select-Object -ExpandProperty FullName

# 4. Identify security services set to Disabled (Start = 4) unexpectedly
$report['DisabledSecurityServices'] = Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Services' |
    Where-Object { (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue).Start -eq 4 } |
    Where-Object { $_.PSChildName -match 'WinDefend|Sense|MsMpSvc|SecurityHealth|EDR|CrowdStrike|CSFalcon|Sentinel' } |
    Select-Object -ExpandProperty PSChildName

# 5. Flag Run-key persistence in user-writable paths
$runKeys = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run',
           'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run'
$report['SuspiciousRunKeys'] = foreach ($key in $runKeys) {
    if (Test-Path $key) {
        (Get-ItemProperty $key).PSObject.Properties |
            Where-Object { $_.Value -match 'Temp|AppData|Users\\Public' } |
            Select-Object Name, Value
    }
}

# 6. Measure outbound peer diversity (P2P mesh indicator)
$peerCount = Get-NetUDPEndpoint -ErrorAction SilentlyContinue |
    Where-Object { $_.RemoteAddress -notmatch '^(0\.0\.0\.0|::|127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)' } |
    Select-Object -ExpandProperty RemoteAddress -Unique | Measure-Object | Select-Object -ExpandProperty Count
$report['DistinctUDPPeers'] = $peerCount
$report['P2PMeshSuspected'] = ($peerCount -gt 100)

$report.GetEnumerator() | Format-Table -AutoSize
if ($report['AutorunArtifacts'] -or $report['DisabledSecurityServices'] -or $report['P2PMeshSuspected']) {
    Write-Warning 'Indicators consistent with file-infector/botnet compromise. Isolate host and initiate IR — reimage required.'
}

Remediation & Eradication

There is no patch for this — eradicating a file infector is an operational discipline problem, not a vulnerability management one. Prioritize the following:

1. Reimage, don't clean. Sality embeds itself inside legitimate executables. Antivirus "cleanup" of file infectors routinely leaves corrupted binaries or residual code. Any confirmed-infected host gets isolated, imaged from known-good media, and has its credentials rotated. This is non-negotiable in your IR runbook for file-infecting malware.
2. Cut egress for P2P traffic. Enforce default-deny outbound at the perimeter. Alert on (and block) high-cardinality UDP destinations from endpoints. There is virtually no legitimate business reason for a workstation to maintain hundreds of concurrent external UDP peers.
3. Disable AutoRun/AutoPlay fleet-wide via GPO (NoDriveTypeAutoRun = 0xFF) and enforce USB device control policies. Sality's removable-media vector dies here.
4. Audit your network shares. Infected executables on writable network shares re-seed cleaned environments. Scan shares for modified executables and restrict write permissions.
5. Leverage the free intelligence this operation generated. The Shadowserver Foundation publishes free daily network remediation feeds — subscribe at shadowserver.org and cross-reference your netblocks against their botnet infection reports. If your IP space was talking to the Sality mesh, Shadowserver data will show it. CrowdStrike customers should pull the actor/family detections from this operation's intel reporting.
6. Verify EDR coverage and tamper protection. Sality disables security tooling. Any endpoint where your EDR service was disabled, stopped, or uninstalled without a corresponding change ticket is a suspect host until proven otherwise. Enable tamper protection and alert on security-service state changes.
7. Threat hunt retroactively. Run the KQL and VQL above across 90 days of telemetry, not just current state — identify hosts that exhibited mesh behavior before the August 31 sinkhole to build your remediation scope.

Key Takeaways

• The Sality takedown disrupted C2, not infections. Residual implants are live on infected endpoints and represent both a reconstitution risk and a standing lateral-movement capability.
• The highest-fidelity detections are behavioral: P2P peer diversity, autorun staging, security-service tampering, and Run-key persistence in user-writable paths.
• File infectors cannot be safely cleaned — reimage confirmed hosts, scan network shares, and rotate credentials.
• Sinkhole operations create a defender's window. Use it now: hunt, scope, and eradicate before any successor infrastructure comes online.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub