THREAT-Recon-AutomatedVulnScannerSweep IBM QRadar · QRadar

Detect Automated Vulnerability Scanner Sweep Against External Attack Surface in IBM QRadar

Before exploitation, most intrusions begin with active scanning of the target's external attack surface using automated vulnerability scanning tools such as sqlmap, Nikto, Nuclei, Acunetix, Nessus, OpenVAS, or WPScan. Attackers run these tools against internet-facing web applications, APIs, and edge devices to fingerprint software versions, enumerate misconfigurations, and identify exploitable CVEs before committing to an intrusion attempt. This scanning is typically noisy at the HTTP layer: high-volume requests for known vulnerable paths (e.g. /.env, /.git/config, /wp-login.php, /actuator/health, /phpmyadmin), distinctive scanner user-agent strings, and rapid sequential probing of many distinct URIs from a single source in a short window. Nation-state actors such as Volt Typhoon and APT41 routinely scan edge devices and web infrastructure ahead of exploitation attempts, while eCrime groups like FIN7 and Scattered Spider use commodity scanning frameworks to identify soft targets at scale. Detecting the scanning phase gives defenders a window to harden or patch before the attacker moves to Initial Access.

MITRE ATT&CK

Tactic
Reconnaissance

QRadar Detection Query

IBM QRadar (QRadar)
sql 
SELECT
  DATEFORMAT(starttime, 'yyyy-MM-dd HH:mm') AS TimeWindow,
  sourceip AS SourceIP,
  destinationip AS DestinationIP,
  url AS RequestURL,
  LOGSOURCETYPENAME(devicetype) AS VendorType,
  COUNT(*) AS TotalRequests,
  COUNT(DISTINCT url) AS DistinctURIs
FROM events
WHERE
  LOGSOURCETYPENAME(devicetype) ILIKE ANY ('%F5%', '%Imperva%', '%FortiWeb%', '%Akamai%', '%Cloudflare%', '%NetScaler%')
  AND (
    LOWER(useragent) ILIKE ANY ('%sqlmap%', '%nikto%', '%nuclei%', '%acunetix%', '%nessus%', '%openvas%', '%wpscan%', '%dirbuster%', '%gobuster%')
    OR LOWER(url) ILIKE ANY ('%/.env%', '%/.git/config%', '%/wp-login.php%', '%/actuator/env%', '%/phpmyadmin%', '%/.aws/credentials%')
  )
  AND starttime >= NOW() - 86400000
GROUP BY
  DATEFORMAT(starttime, 'yyyy-MM-dd HH:mm'),
  sourceip,
  destinationip,
  url,
  LOGSOURCETYPENAME(devicetype)
ORDER BY TotalRequests DESC
medium severity medium confidence

Detects known vulnerability scanner user-agent strings or requests for well-known sensitive/vulnerable paths against WAF-protected web infrastructure (F5, Imperva, FortiWeb, Akamai, Cloudflare, NetScaler) within the last 24 hours.

Data Sources

F5 ASMImperva WAFFortiWebAkamai Kona Site DefenderCloudflare WAFCitrix NetScaler AppFirewall

Required Tables

events

False Positives & Tuning

  • Authorised internal or contracted vulnerability scanning not yet excluded via source IP allowlist
  • Synthetic monitoring services probing multiple endpoints for uptime checks
  • Security researchers or bug-bounty participants operating under an authorised program
  • Web crawlers indexing legitimately deprecated paths that happen to overlap sensitive-path patterns

Other platforms for THREAT-Recon-AutomatedVulnScannerSweep

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 1Vulnerability Scanner User-Agent Simulation via curl

    Expected signal: WAF/reverse-proxy logs record inbound requests with the scanner user-agent strings in the Message or http_user_agent field.

  2. Test 2Sensitive Path Probing Simulation

    Expected signal: WAF/reverse-proxy logs show requests to each sensitive path, mostly resulting in 404 responses.

  3. Test 3Behavioral URI Enumeration Simulation via ffuf-style Loop

    Expected signal: WAF/reverse-proxy logs record 40 distinct URIs requested from the test source IP within a single 5-minute window, nearly all returning 404.

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

Response Playbook

Triage

  1. Identify the source IP(s) generating the scan traffic. Check AbuseIPDB, Shodan, and VirusTotal for reputation — scanning frequently originates from VPS hosts, Tor exit nodes, or known scanning-as-a-service infrastructure (Shodan, Censys, GreyNoise crawlers).
  2. Determine whether the source IP matches an authorised vulnerability management scanner (internal AppSec team, contracted pentest firm, or vendor scanning service) already on the allowlist. If so, close as expected activity and add to the exclusion list if missing.
  3. Review which URIs and paths were probed — sensitive-path hits (/.env, /.git/config, /.aws/credentials) indicate the scanner is specifically hunting for exposed secrets or source code, a higher-priority signal than generic crawling.
  4. Check whether any of the probed paths returned a 200 OK or otherwise non-404 response, which would indicate the scanner found a genuinely exposed misconfiguration or vulnerable endpoint rather than just probing blind.
  5. Correlate the scanning window against subsequent traffic from the same source IP or ASN over the following days — scanning is frequently the reconnaissance phase preceding an exploitation attempt days or weeks later.

Containment

  1. If the source IP is confirmed malicious and unauthorised, block it at the WAF/CDN edge and add to the perimeter firewall deny list.
  2. If a probed sensitive path (e.g. /.env, /.git/config) returned a non-404 response, treat this as a confirmed exposure: remediate the misconfiguration immediately (remove the exposed file, restrict access, rotate any credentials that may have been exposed) and escalate as a potential compromise, not just reconnaissance.
  3. Enable or tune WAF rate-limiting and bot-management rules to throttle high-request-volume sources before they can complete a full enumeration sweep.
  4. Consider geo-blocking or ASN-blocking known scanning infrastructure ranges if the organisation has no legitimate business need for traffic from those sources.

Evidence Collection

  1. WAF/reverse-proxy access logs for the source IP across the full scan window: full URI list, response codes, user-agent strings, and timestamps
  2. Any subsequent authentication or application-layer events from the same source IP or ASN in the days following the scan
  3. Threat intelligence lookups and passive DNS history for the source IP
  4. Configuration and exposure audit of any sensitive path that returned a non-404 response during the scan

Escalation Criteria

  • !A probed sensitive path (e.g. /.env, /.git/config, /.aws/credentials, /phpmyadmin) returns a non-404/non-403 response — treat as a confirmed exposure requiring immediate remediation
  • !The scanning source IP is later observed attempting authentication or exploitation against the same target
  • !Scan volume or URI enumeration breadth is consistent with a known nation-state scanning campaign (e.g. mass internet-wide scanning for a newly disclosed CVE)
  • !Multiple internet-facing assets across the organisation are scanned by the same source IP within a short window, indicating targeted rather than opportunistic reconnaissance

Investigation Guide

Related Techniques

T1595 — Active Scanning (parent technique)T1595.001 — Active Scanning: Scanning IP BlocksT1590 — Gather Victim Network Information (often precedes targeted scanning)T1190 — Exploit Public-Facing Application (typical follow-on after successful scanning identifies a vulnerable endpoint)T1592 — Gather Victim Host Information

Forensic Artifacts

  • >WAF/reverse-proxy access logs: source IP, requested URI, HTTP method, response code, user-agent, timestamps
  • >CDN edge logs showing request geography and ASN for the scanning source
  • >Application server logs corroborating whether any probed path was actually reachable behind the WAF
  • >Threat intelligence enrichment records (AbuseIPDB, GreyNoise, Shodan) for the source IP at time of scan

Tuning Guidance

Thresholds should be tuned against your own baseline of legitimate scanning traffic — organisations that run frequent authorised vulnerability scans (weekly Nessus/Qualys runs, continuous DAST in CI/CD) should maintain a source-IP allowlist and exclude those ranges before enabling this rule broadly, otherwise the behavioral alert will fire constantly. The known-signature alert (Alert 1) is lower-noise and safe to run at high sensitivity since legitimate traffic rarely presents scanner user-agent strings. The behavioral alert (Alert 2) should have its distinct-URI and error-ratio thresholds raised for organisations with many single-page applications that legitimately generate high 404 rates from client-side routing, and lowered for small, stable web estates where any broad enumeration is anomalous.

Hunting Queries

Weekly hunt for any source IP that either enumerated 15+ distinct URIs against WAF-protected infrastructure in a single day or probed any known sensitive path — surfaces low-and-slow scanning that stays under the primary detection's 5-minute-window thresholds.

Hunting — KQL
kql 
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor has_any ("F5", "Imperva", "Fortinet", "Akamai", "Cloudflare", "Citrix")
| summarize
    DistinctURIs=dcount(RequestURL),
    TotalRequests=count(),
    SensitivePathHits=countif(RequestURL has_any ("/.env", "/.git/config", "/.aws/credentials", "/phpmyadmin"))
  by SourceIP, bin(TimeGenerated, 1d)
| where DistinctURIs >= 15 or SensitivePathHits >= 1
| sort by SensitivePathHits desc, DistinctURIs desc
Hunting — SPL
spl 
index=network sourcetype IN ("f5:asm","imperva:waf","fortinet:fortiweb","cloudflare:waf")
| bin _time span=1d
| stats dc(uri_path) AS DistinctURIs, count AS TotalRequests,
        count(eval(match(uri_path, "(?i)(\.env|\.git/config|\.aws/credentials|phpmyadmin)"))) AS SensitivePathHits
  BY src_ip, _time
| where DistinctURIs >= 15 OR SensitivePathHits >= 1
| sort - SensitivePathHits, - DistinctURIs

Atomic Red Team Tests

Test 1 Vulnerability Scanner User-Agent Simulation via curl
linux

Simulates requests bearing known vulnerability scanner user-agent strings against a test web endpoint, to validate that Alert 1's signature matching fires correctly.

Command

bash 
for ua in "sqlmap/1.7.2#stable" "Mozilla/5.0 (Nikto/2.5.0)" "Nuclei - Open-source project (github.com/projectdiscovery/nuclei)"; do curl -s -A "$ua" -o /dev/null -w '%{http_code}\n' https://<TEST_TARGET>/; sleep 1; done

Expected Telemetry

WAF/reverse-proxy logs record inbound requests with the scanner user-agent strings in the Message or http_user_agent field.

Expected Detection

Alert 1 fires on Message has_any match against known scanner tool signatures.

Test 2 Sensitive Path Probing Simulation
linux

Simulates a scanner probing common sensitive/vulnerable paths against a test endpoint to validate signature-based path matching.

Command

bash 
for path in "/.env" "/.git/config" "/wp-login.php" "/actuator/env" "/phpmyadmin" "/.aws/credentials"; do curl -s -o /dev/null -w "%{http_code} $path\n" https://<TEST_TARGET>$path; sleep 1; done

Expected Telemetry

WAF/reverse-proxy logs show requests to each sensitive path, mostly resulting in 404 responses.

Expected Detection

Alert 1 fires on RequestURL has_any match against the sensitive-path list.

Test 3 Behavioral URI Enumeration Simulation via ffuf-style Loop
linux

Simulates a custom scanner without a recognisable user-agent rapidly enumerating many distinct URIs against a single target, to validate that Alert 2's behavioral detection fires when the signature-based alert would miss unsigned tooling.

Command

bash 
python3 -c "
import requests, time
paths = [f'/test-path-{i}' for i in range(40)]
for p in paths:
    r = requests.get(f'https://<TEST_TARGET>{p}', verify=False)
    print(p, r.status_code)
    time.sleep(0.2)
"

Expected Telemetry

WAF/reverse-proxy logs record 40 distinct URIs requested from the test source IP within a single 5-minute window, nearly all returning 404.

Expected Detection

Alert 2 fires when DistinctURIs >= 25, TotalRequests >= 30, and NotFoundRatio >= 0.5 within the 5-minute bin.

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

T1595Active ScanningT1595.001Scanning IP BlocksT1590Gather Victim Network InformationT1190Exploit Public-Facing ApplicationT1592Gather Victim Host Information

Same Tactic: Reconnaissance

Popular Detections