THREAT-Recon-DistributedVulnScanBurst IBM QRadar · QRadar

Detect Distributed Vulnerability Scanning Burst Against Web Infrastructure in IBM QRadar

Adversaries and access brokers run automated vulnerability scanners against externally-facing web infrastructure to fingerprint exposed technology and locate exploitable misconfigurations before initial access. Two patterns dominate: a concentrated burst, where a single source IP fires a wide diversity of scanner-signature requests (config file probes, admin panel paths, framework actuator endpoints, path traversal, webshell probes) at a target within minutes; and a low-and-slow variant, where a small rotating pool of source IPs within the same /24 subnet or hosting-provider ASN spreads the same signature diversity across a much longer window to stay under per-IP rate-limit thresholds. Both patterns are typically observed in WAF, reverse-proxy, or perimeter firewall logs rather than endpoint telemetry, since the target is the externally-facing HTTP surface itself. Detection prioritises the diversity of distinct scanner-signature categories touched per source (or per rotating subnet) over raw request volume, since volume alone is indistinguishable from normal crawler/bot traffic while signature diversity is not.

MITRE ATT&CK

Tactic
Reconnaissance

QRadar Detection Query

IBM QRadar (QRadar)
sql 
SELECT
  DATEFORMAT(starttime, 'yyyy-MM-dd HH:mm:ss') AS EventTime,
  sourceip AS SourceIP,
  "URL" AS RequestPath,
  "User Agent" AS UserAgent,
  UNIQUECOUNT("URL") AS DistinctPaths,
  CASE
    WHEN "URL" ILIKE '%.env%' THEN '.env'
    WHEN "URL" ILIKE '%.git%' THEN '.git'
    WHEN "URL" ILIKE '%wp-login%' OR "URL" ILIKE '%wp-admin%' THEN 'wordpress_admin'
    WHEN "URL" ILIKE '%xmlrpc.php%' THEN 'xmlrpc'
    WHEN "URL" ILIKE '%actuator%' THEN 'spring_actuator'
    WHEN "URL" ILIKE '%phpmyadmin%' THEN 'phpmyadmin'
    WHEN "URL" ILIKE '%solr/admin%' THEN 'solr_admin'
    WHEN "URL" ILIKE '%manager/html%' THEN 'tomcat_manager'
    WHEN "URL" ILIKE '%../../%' THEN 'path_traversal'
    WHEN "URL" ILIKE '%shell.php%' OR "URL" ILIKE '%eval-stdin%' THEN 'webshell_probe'
    WHEN "User Agent" ILIKE '%sqlmap%' OR "User Agent" ILIKE '%Nikto%' OR "User Agent" ILIKE '%Nessus%' OR "User Agent" ILIKE '%Acunetix%' OR "User Agent" ILIKE '%masscan%' OR "User Agent" ILIKE '%zgrab%' OR "User Agent" ILIKE '%Nuclei%' OR "User Agent" ILIKE '%wpscan%' THEN 'scanner_useragent'
    ELSE 'other_scanner_signature'
  END AS MatchedSignature
FROM events
WHERE
  LOGSOURCETYPEID(logsourceid) IN (66, 4, 250)
  AND starttime > NOW() - 86400000
  AND (
    "URL" ILIKE '%.env%' OR "URL" ILIKE '%.git%' OR "URL" ILIKE '%wp-login%' OR "URL" ILIKE '%wp-admin%'
    OR "URL" ILIKE '%xmlrpc.php%' OR "URL" ILIKE '%actuator%' OR "URL" ILIKE '%phpmyadmin%'
    OR "URL" ILIKE '%solr/admin%' OR "URL" ILIKE '%manager/html%' OR "URL" ILIKE '%../../%'
    OR "URL" ILIKE '%shell.php%' OR "URL" ILIKE '%eval-stdin%'
    OR "User Agent" ILIKE '%sqlmap%' OR "User Agent" ILIKE '%Nikto%' OR "User Agent" ILIKE '%Nessus%'
    OR "User Agent" ILIKE '%Acunetix%' OR "User Agent" ILIKE '%masscan%' OR "User Agent" ILIKE '%zgrab%'
    OR "User Agent" ILIKE '%Nuclei%' OR "User Agent" ILIKE '%wpscan%'
  )
GROUP BY SourceIP
HAVING UNIQUECOUNT("URL") >= 8
ORDER BY DistinctPaths DESC
high severity medium confidence

AQL query for IBM QRadar aggregating scanner-signature path matches per source IP over a 24-hour window, flagging source IPs that touch >=8 distinct URL paths matching known scanner signatures.

Data Sources

IBM QRadar SIEMWAF/reverse-proxy log sources (DSMs for F5, Fortinet, Imperva)

Required Tables

events

False Positives & Tuning

  • Authorized internal or contracted vulnerability management scans (Qualys, Nessus, Tenable, Rapid7) running against production on an approved scanning schedule
  • Bug bounty researchers or penetration testers operating within an approved rules-of-engagement window
  • Uptime/synthetic monitoring services (Pingdom, UptimeRobot, StatusCake) or health-check bots hitting many paths from a small set of monitoring IPs
  • SEO crawlers, CDN health probes, or archival bots (Googlebot, Bingbot, Wayback Machine) traversing many URL paths that incidentally overlap scanner signature patterns
  • Load testing tools or CI/CD smoke tests hitting numerous endpoints rapidly from a shared build-agent IP address

Other platforms for THREAT-Recon-DistributedVulnScanBurst

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

  1. Test 1Scanner Signature Path Sweep (Concentrated Burst)

    Expected signal: WAF/reverse-proxy logs show >=10 distinct scanner-signature paths requested within seconds from the tester's single source IP, User-Agent 'AtomicTest-VulnScan/1.0'.

  2. Test 2Known Scanner Tool User-Agent Sweep

    Expected signal: WAF logs show dozens of distinct paths (config, admin, CGI, backup file probes) and User-Agent containing 'Nikto' from the tester's source IP within minutes.

  3. Test 3Low-and-Slow Subnet-Rotated Scan Simulation

    Expected signal: WAF logs show 4 distinct source IPs within 198.51.100.0/24, each issuing 2 scanner-signature requests spread across several hours, collectively covering >=8 distinct signature categories.

Last updated: 2026-07-20 Research depth: deep
References (5)

Response Playbook

Triage

  1. Confirm whether the source IP(s)/subnet correspond to a known, authorized scanner (internal vulnerability-management platform, contracted pentest firm, bug bounty program) by checking IP allowlists and scanning calendars before treating this as hostile.
  2. Review the specific signature categories matched (config-file probes, admin-panel paths, framework actuator endpoints, path traversal, webshell probes) to assess whether the actor is doing broad fingerprinting or targeting a vulnerability class relevant to your actual stack.
  3. Check WAF/reverse-proxy response codes for the matched requests: a 200 or 500 response on a scanner-signature path indicates the probed resource may genuinely exist and warrants an immediate deep-dive, versus uniform 403/404 broad blind probing.
  4. For the low-and-slow variant, pivot on the /24 subnet or ASN of the rotating source IPs to determine whether they belong to a cloud-hosting provider commonly used for scanning infrastructure, or to a residential/proxy range indicating botnet-driven scanning.
  5. Cross-reference the scanned paths against your actual technology stack (CMS, frameworks, app servers in use) — probes for irrelevant technology (e.g. WordPress paths against a pure API service) indicate blind broad-spectrum internet scanning rather than targeted recon of your environment specifically.

Containment

  1. Rate-limit or block the offending source IP(s) / subnet at the WAF/CDN edge (Cloudflare, Azure Front Door, F5) once authorization has been ruled out.
  2. If low-and-slow subnet rotation is confirmed against a hosting-provider ASN, apply an ASN-level or geo-based rate limit rather than single-IP blocks, since the actor will continue rotating source addresses within the range.
  3. Immediately lock down or remove any endpoint confirmed to exist via a 200/500 response on a sensitive config/debug/admin/webshell-probe path — the recon itself already revealed the exposure.
  4. Notify the vulnerability-management or pentest-coordination owner to confirm or rule out an authorized scanning window before escalating further.

Evidence Collection

  1. Full WAF/reverse-proxy access logs for the source IP(s)/subnet spanning the detection window, including request path, query string, headers, User-Agent, and response code/size for every request.
  2. Whois/ASN lookup and threat-intelligence enrichment (GreyNoise, AbuseIPDB, Shodan) on the source IP(s) to classify known-scanner infrastructure versus a likely-compromised host.
  3. A chronological timeline of distinct signature categories observed, to reconstruct the scanner's fingerprinting sequence and identify what technology it believes it found.
  4. Any downstream alerts (WAF blocks, IDS/IPS hits, application error logs) correlated to the same source IP/subnet and time window.

Escalation Criteria

  • !Any scanner-signature request returns HTTP 200 or 500 against a config/debug/admin/webshell-probe path, indicating the probed resource may actually exist.
  • !The same source IP or subnet pivots from broad vulnerability scanning to authentication attempts (login POST requests) or exploitation payloads (SQLi/RCE strings) within the same session, indicating recon has transitioned to active exploitation.
  • !Distinct-signature count exceeds 20 in a single burst window, or the low-and-slow pattern persists across multiple consecutive 24-hour windows, indicating a dedicated persistent actor rather than opportunistic internet-wide noise.
  • !The scanning activity is not attributable to any authorized internal or contracted scanning program after checking allowlists and calendars.

Investigation Guide

Related Techniques

T1595.001 — Active Scanning: Scanning IP BlocksT1590 — Gather Victim Network InformationT1592 — Gather Victim Host InformationT1190 — Exploit Public-Facing Application (likely next stage)T1189 — Drive-by Compromise (alternate follow-on)

Forensic Artifacts

  • >WAF/reverse-proxy access logs: request path, query string, headers, User-Agent, and response code/size per request
  • >CDN edge logs (Cloudflare, Azure Front Door, Akamai) distinguishing edge cache-hit from origin-forwarded requests from the scanning source
  • >Threat-intel enrichment records (GreyNoise, Shodan, AbuseIPDB) classifying the source IP/ASN at the time of the scan
  • >Downstream IDS/IPS or application error logs correlated to the same source and time window

Tuning Guidance

Maintain an allowlist of known-authorized vulnerability scanner and monitoring IP ranges (internal Qualys/Nessus/Tenable appliances, contracted pentest firm ranges, uptime-monitoring services) and exclude them at the top of both queries — legitimate scheduled scans will otherwise trip both ConcentratedBurst and LowAndSlowSubnetRotation on every scan cycle. Tune the DistinctSignatures/DistinctPaths thresholds (currently 6/10 for the burst, 8 signatures across 3-25 distinct source IPs for low-and-slow) upward for high-traffic public sites with heavy legitimate crawler/bot diversity, and downward for low-traffic internal-facing apps where any signature diversity is anomalous. Prioritise alerts where a scanner-signature request returned 200/500 over uniform 403/404, since those indicate the probed resource genuinely exists.

Hunting Queries

Once a source IP is confirmed malicious, pivot across the full environment (all sites/tenants behind the WAF) over the prior 7 days to identify every other host it touched — distributed scanners frequently probe multiple properties from the same infrastructure before or after the detected burst.

Hunting — KQL
kql 
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP == "REPLACE_WITH_CONFIRMED_SCANNER_IP"
| summarize RequestCount = count(), DistinctTargets = dcount(DestinationHostName), Targets = make_set(DestinationHostName), Paths = make_set(RequestURL) by SourceIP, bin(TimeGenerated, 1h)
| sort by TimeGenerated asc
Hunting — SPL
spl 
index=waf OR index=firewall src_ip="REPLACE_WITH_CONFIRMED_SCANNER_IP" earliest=-7d
| stats count AS RequestCount, dc(dest_host) AS DistinctTargets, values(dest_host) AS Targets, values(uri_path) AS Paths BY src_ip, span=1h
| sort _time

Atomic Red Team Tests

Test 1 Scanner Signature Path Sweep (Concentrated Burst)
linux

Rapidly requests a set of known vulnerability-scanner-signature paths (config files, admin panels, framework actuator endpoints, CGI probes) against a target from a single source IP within seconds, simulating the ConcentratedBurst detection pattern.

Command

bash 
for p in /.env /.git/config /wp-login.php /xmlrpc.php /actuator/env /phpmyadmin/ /solr/admin/ /manager/html /cgi-bin/test.cgi /server-status; do curl -s -o /dev/null -A "AtomicTest-VulnScan/1.0" "https://TARGET_HOST$p"; done

Cleanup

bash 
unset p

Expected Telemetry

WAF/reverse-proxy logs show >=10 distinct scanner-signature paths requested within seconds from the tester's single source IP, User-Agent 'AtomicTest-VulnScan/1.0'.

Expected Detection

Fires ConcentratedBurst with DistinctSignatures >= 6, DistinctPaths >= 10, RiskScore >= 78.

Test 2 Known Scanner Tool User-Agent Sweep
linux

Runs Nikto against the target, generating a wide diversity of scanner-signature path probes and a fingerprinted scanner User-Agent string in a single short-lived session.

Command

bash 
nikto -h https://TARGET_HOST -o /tmp/nikto_out.txt -Tuning 123456789

Cleanup

bash 
rm -f /tmp/nikto_out.txt

Expected Telemetry

WAF logs show dozens of distinct paths (config, admin, CGI, backup file probes) and User-Agent containing 'Nikto' from the tester's source IP within minutes.

Expected Detection

Fires ConcentratedBurst with DistinctSignatures well above the 6-category threshold; RiskScore >= 88 given high signature diversity.

Test 3 Low-and-Slow Subnet-Rotated Scan Simulation
linux

Simulates distributed low-and-slow scanning by issuing scanner-signature requests from multiple source addresses within the same /24 test range (e.g. via a local proxy/interface pool), spreading the same signature diversity across several hours to stay under a per-IP burst threshold.

Command

bash 
for ip in 198.51.100.10 198.51.100.11 198.51.100.12 198.51.100.13; do curl -s -o /dev/null --interface $ip -A "AtomicTest-VulnScan/1.0" "https://TARGET_HOST/.env"; curl -s -o /dev/null --interface $ip -A "AtomicTest-VulnScan/1.0" "https://TARGET_HOST/actuator/env"; sleep 3600; done

Cleanup

bash 
unset ip

Expected Telemetry

WAF logs show 4 distinct source IPs within 198.51.100.0/24, each issuing 2 scanner-signature requests spread across several hours, collectively covering >=8 distinct signature categories.

Expected Detection

Fires LowAndSlowSubnetRotation once the 24h window accumulates DistinctSourceIPs between 3-25 and DistinctSignatures >= 8; RiskScore >= 72.

Related Detections

Tactic Hub

TA0043Reconnaissance

Detection Variants (2)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Parent Technique

T1595.002Vulnerability Scanning

Related Techniques

T1595.001Scanning IP BlocksT1590Gather Victim Network InformationT1592Gather Victim Host InformationT1190Exploit Public-Facing ApplicationT1189Drive-by Compromise

Same Tactic: Reconnaissance

Popular Detections