Detect Distributed Low-and-Slow Port/Service Scanning Sweep in Splunk
Adversaries increasingly avoid classic single-source port scan detection (which alerts on one IP hitting many ports/hosts in a short window) by distributing the sweep across a large pool of source IPs — botnet nodes, residential proxies, or rented scanning infrastructure — with each individual source only touching a handful of destination hosts or ports. No single source ever crosses a per-IP threshold, but the aggregate campaign methodically walks the organization's entire public IP block (T1595.001 — Active Scanning: Scanning IP Blocks) looking for exposed services ahead of exploitation. This is a persistent detection gap because most SIEM scan-detection rules key off a single source IP's touch count within a window; a coordinated low-and-slow sweep spread across dozens or hundreds of source IPs, each staying under that threshold, sails through undetected. Reliable detection requires aggregating perimeter firewall deny/reset telemetry at the destination CIDR level across ALL source IPs in a rolling window, then flagging when a large number of distinct low-touch sources collectively achieve high coverage of the organization's address space — the fingerprint of a coordinated sweep rather than background internet noise.
MITRE ATT&CK
- Tactic
- Reconnaissance
SPL Detection Query
index=firewall (action="deny" OR action="drop" OR action="reset" OR action="blocked")
| where cidrmatch("203.0.113.0/24", dest_ip) OR cidrmatch("198.51.100.0/23", dest_ip)
| bin _time span=24h
| stats dc(dest_ip) as DistinctDestIPs, dc(dest_port) as DistinctDestPorts by src_ip, _time
| where DistinctDestIPs <= 3
| rename src_ip as LowTouchSource
| join type=inner LowTouchSource
[ search index=firewall (action="deny" OR action="drop" OR action="reset" OR action="blocked")
| where cidrmatch("203.0.113.0/24", dest_ip) OR cidrmatch("198.51.100.0/23", dest_ip)
| bin _time span=24h
| rename src_ip as LowTouchSource ]
| stats
dc(LowTouchSource) as UniqueSources,
dc(dest_ip) as UniqueDestIPsSwept,
dc(dest_port) as UniqueDestPorts,
earliest(_time) as FirstSeen,
latest(_time) as LastSeen
by _time
| where UniqueSources >= 25 AND UniqueDestIPsSwept >= 50
| eval Signal="DistributedLowAndSlowScanSweep"
| sort - UniqueDestIPsSweptSplunk detection over perimeter firewall deny/drop/reset events using cidrmatch() (NOT string equality) against the org's registered public CIDR blocks. Stage 1 finds source IPs that individually touch 3 or fewer distinct destination hosts within a 24h window ('low-touch'); the subsearch join aggregates across all such low-touch sources to flag when 25+ distinct sources collectively sweep 50+ distinct destination hosts, the pattern of a coordinated distributed reconnaissance campaign spread across many source IPs to evade per-source thresholds.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Known internet research scanners (Shodan, Censys, Shadowserver, GreyNoise) — maintain an allowlist of their published scanning IP ranges
- Third-party attack-surface-management or vulnerability-scanning vendors performing authorized recurring external scans from cloud scanner pools
- Distributed synthetic-monitoring services probing multiple public IPs from many geographically dispersed nodes
Other platforms for THREAT-Recon-DistributedPortScanSweep
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulated Low-Touch Multi-Source Port Probe (Single Host, Multiple Ports)
Expected signal: Perimeter firewall deny/reset log entries for the connection attempts to closed/filtered ports on the lab target, recorded with the source IP and each probed destination port.
- Test 2Simulated Coordinated Sweep (Multiple Scripted Sources, Sequential IP Block Walk)
Expected signal: Firewall deny/reset log entries showing the same source IP touching multiple sequential destination IPs in the lab CIDR block, each with a small number of probed ports.
- Test 3Masscan High-Speed IP Block Sweep (Single Source, Lab Range)
Expected signal: Firewall/NetFlow records showing SYN-only or single-packet connection attempts across every host in the lab /28 range from one source IP.
Response Playbook
Triage
- Confirm the aggregation pattern first: pull the list of distinct low-touch source IPs contributing to the flagged CIDR block and verify they are genuinely distinct entities (not NAT'd behind a single upstream gateway, which would understate the true source count).
- Cross-reference the source IP set against known-benign internet scanner ranges (Shodan, Censys, Shadowserver, GreyNoise) and any contracted attack-surface-management vendor's published scanning ranges — legitimate research/vendor scans are the most common false positive for this pattern.
- Check whether the swept destination IPs/ports correlate with recently disclosed CVEs or newly exposed services — a distributed sweep immediately preceding or following a high-profile vulnerability disclosure is a strong signal of targeted pre-exploitation recon rather than generic internet background noise.
- Determine geographic and ASN diversity of the source IP set: a sweep from a tightly clustered ASN/geography suggests a single actor's rented infrastructure; a sweep from globally dispersed residential/proxy IPs suggests a botnet-for-hire recon service.
- Check for a temporal pattern — does the per-source touch rate stay just under common detection thresholds (e.g., consistently 2-3 hosts per source), suggesting the adversary deliberately tuned the sweep to evade known scan-detection rules?
Containment
- Add the confirmed malicious low-touch source IP set to the perimeter firewall/WAF blocklist as a batch, rather than one-off IP blocks, since new sources in the same campaign will keep rotating in.
- If the source IPs cluster in a small number of ASNs/subnets and show no legitimate use, consider a temporary geo/ASN-level block at the perimeter for the duration of the campaign.
- Prioritize patching or restricting external exposure of any service/port that was specifically and repeatedly targeted across the swept hosts, since that is the likely next-stage exploitation target.
- Notify the vulnerability management team to fast-track scanning and remediation of any internet-facing assets identified as being probed, ahead of a possible follow-on exploitation attempt.
Evidence Collection
- CommonSecurityLog / firewall deny-drop-reset records: full list of source IPs, destination IPs/ports, and timestamps contributing to the flagged sweep
- WHOIS/ASN enrichment for the contributing source IPs to establish infrastructure ownership and geographic distribution
- Any successful (non-denied) connections from the same source IP set in the surrounding time window, which would indicate the sweep found and exploited an open service
- Threat intelligence platform lookups (GreyNoise, Shodan, AbuseIPDB) for the contributing source IPs to classify them as known-scanner, known-malicious, or unclassified
Escalation Criteria
- !Any source IP from the sweep is subsequently observed making a successful (allowed) connection to a swept host, indicating the recon phase transitioned into access
- !The swept destination ports/services map to a recently disclosed critical CVE affecting software known to be deployed on the organization's perimeter
- !The source IP set overlaps with IOCs from an active threat intelligence campaign or a known botnet/scanning-as-a-service infrastructure tracked by the organization's TI feeds
- !Repeated distributed sweeps of the same IP block recur over multiple days, suggesting sustained, deliberate reconnaissance rather than a one-off internet-wide scan pass
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Perimeter firewall deny/drop/reset logs: the primary evidence source, containing source IP, destination IP/port, and timestamp for every probed connection - >
NetFlow/IPFIX flow records showing short-lived, single-packet or SYN-only flows consistent with port scanning rather than legitimate application traffic - >
IDS/IPS alerts for scan-signature detections (e.g., Suricata's stream/scan rules) that may have fired on individual sources without triggering aggregate correlation - >
DNS PTR/reverse-lookup history for contributing source IPs, useful for distinguishing known research scanners from unattributed infrastructure - >
WAF/reverse-proxy access logs if any swept host sits behind a web-facing proxy, which may show HTTP-layer probing (path/method enumeration) alongside the network-layer scan
Tuning Guidance
Build and continuously maintain an allowlist of known-benign internet research scanners (Shodan, Censys, Shadowserver, GreyNoise RIOT list) and any contracted attack-surface-management vendor's published scanning ranges — exclude these at the source-IP or ASN level before the low-touch aggregation stage, since they are the dominant false-positive source for this pattern. The PerSourceTouchCeiling (default 3) and MinDistinctSources/MinSweptHosts (default 25/50) thresholds should be baselined against 2-4 weeks of the organization's own perimeter traffic before enabling alerting, since background internet scan noise volume varies significantly by IP block size and industry. Consider lowering MinDistinctSources for smaller organizations with a narrow public IP footprint, where a coordinated sweep would involve proportionally fewer sources to achieve high coverage.
Hunting Queries
Seven-day hunt isolating every low-touch source IP against the org's perimeter block, independent of the 24h/threshold gates in the primary detection, for manual ASN/geo/TI enrichment and campaign clustering analysis (e.g., identifying whether sources rotate through the same /24 upstream range over successive days).
// Hunt: rank contributing source IPs by ASN/geography for the flagged block to distinguish
// coordinated hostile infrastructure from a legitimate distributed scanner service
let PerimeterBlocks = dynamic(["203.0.113.0/24", "198.51.100.0/23"]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceAction in~ ("deny", "drop", "reset")
| mv-expand Block = PerimeterBlocks to typeof(string)
| where ipv4_is_in_range(DestinationIP, Block)
| summarize DistinctDestIPs = dcount(DestinationIP), TouchTimes = make_list(TimeGenerated) by SourceIP
| where DistinctDestIPs between (1 .. 3)
| sort by DistinctDestIPs descindex=firewall (action="deny" OR action="drop" OR action="reset")
| where cidrmatch("203.0.113.0/24", dest_ip) OR cidrmatch("198.51.100.0/23", dest_ip)
| stats dc(dest_ip) as DistinctDestIPs, values(_time) as TouchTimes by src_ip
| where DistinctDestIPs <= 3
| sort - DistinctDestIPsAtomic Red Team Tests
Uses nmap to probe a small, non-default set of ports on a single target, simulating one 'low-touch' source's contribution to a distributed sweep (stays under any single-source scan threshold). Run against a lab target only.
Command
nmap -Pn -p 22,80,443,3389,8080 --max-retries 1 --scan-delay 2s <lab_target_ip>Expected Telemetry
Perimeter firewall deny/reset log entries for the connection attempts to closed/filtered ports on the lab target, recorded with the source IP and each probed destination port.
Expected Detection
Individually below the low-touch source's DistinctDestIPs<=3 ceiling; contributes one entry to the LowTouchSources set in the KQL/SPL detection when correlated against other simulated sources.
Loops nmap across a small consecutive range of lab-owned IPs from a single test host to emulate the destination-coverage pattern of a distributed sweep walking an IP block, without exceeding a per-source connection ceiling per target.
Command
for ip in 10.10.10.1 10.10.10.2 10.10.10.3; do nmap -Pn -p 22,443 --max-retries 1 $ip; doneExpected Telemetry
Firewall deny/reset log entries showing the same source IP touching multiple sequential destination IPs in the lab CIDR block, each with a small number of probed ports.
Expected Detection
Simulates the aggregate 'UniqueDestIPsSwept' growth the detection watches for when correlated with other simulated low-touch sources in a lab CommonSecurityLog dataset.
Uses masscan to rapidly sweep a lab-owned CIDR range on a common port, simulating the raw internet-wide scanning behavior (e.g., Shodan/Censys-style or botnet worker) that feeds the low-touch source pool when spread across many source IPs.
Command
masscan -p80,443 10.10.10.0/28 --rate 100Expected Telemetry
Firewall/NetFlow records showing SYN-only or single-packet connection attempts across every host in the lab /28 range from one source IP.
Expected Detection
In production this single-source behavior would be caught by classic single-IP scan-threshold rules; used here to validate that the perimeter log pipeline captures the raw scan telemetry the distributed-sweep detection depends on.