T1592

Gather Victim Host Information

Reconnaissance Last updated:

This detection identifies adversary attempts to enumerate victim host information during pre-compromise reconnaissance. Because T1592 is a PRE-ATT&CK technique occurring outside the victim network, direct detection is impossible — this rule targets second-order indicators visible from the defender side: automated scanning tools and fingerprinting bots making requests to internet-facing web servers, User-Agent rotation patterns consistent with OS/browser profiling, and rapid enumeration of host-revealing paths such as /robots.txt, /.env, /phpinfo.php, and similar disclosure endpoints. The primary data source is web server access logs (IIS W3C or common log format), which record client IP, User-Agent, and requested paths — the exact data an adversary harvests to profile target host configurations before launching phishing, supply chain, or watering hole operations.

What is T1592 Gather Victim Host Information?

Gather Victim Host Information (T1592) maps to the Reconnaissance tactic — the adversary is trying to gather information they can use to plan future operations in MITRE ATT&CK.

This page provides production-ready detection logic for Gather Victim Host Information, covering the data sources and telemetry it touches: Microsoft Sentinel - IIS Logs (W3CIISLog). The queries below are rated medium severity at low confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Reconnaissance
Technique
T1592 Gather Victim Host Information
Canonical reference
https://attack.mitre.org/techniques/T1592/
Microsoft Sentinel / Defender
kusto 
let ScannerUserAgents = dynamic([
    "masscan", "nmap", "zgrab", "nikto", "sqlmap", "nuclei",
    "dirbuster", "gobuster", "wfuzz", "ffuf", "whatweb",
    "python-requests", "go-http-client", "libwww-perl",
    "shodan", "censys", "binaryedge", "wget/", "lwp-trivial",
    "apachebench", "java/", "ruby"
]);
let FingerPrintPaths = dynamic([
    "/robots.txt", "/.git/", "/.env", "/.env.local", "/.env.production",
    "/phpinfo.php", "/server-status", "/server-info",
    "/crossdomain.xml", "/clientaccesspolicy.xml", "/sitemap.xml",
    "/wp-admin", "/wp-login.php", "/xmlrpc.php",
    "/.well-known/security.txt", "/CHANGELOG.txt", "/readme.html",
    "/web.config", "/WEB-INF/web.xml"
]);
W3CIISLog
| where TimeGenerated > ago(1h)
| where csUserAgent has_any (ScannerUserAgents)
    or csUriStem has_any (FingerPrintPaths)
| extend
    ClientIP       = cIP,
    UserAgent      = csUserAgent,
    RequestPath    = csUriStem,
    ResponseStatus = scStatus,
    ResponseBytes  = scBytes
| summarize
    RequestCount       = count(),
    UniqueUserAgents   = dcount(csUserAgent),
    UniquePaths        = dcount(csUriStem),
    HTTP200Count       = countif(scStatus == 200),
    HTTP404Count       = countif(scStatus == 404),
    FirstRequest       = min(TimeGenerated),
    LastRequest        = max(TimeGenerated),
    SampledUserAgents  = make_set(csUserAgent, 10),
    SampledPaths       = make_set(csUriStem, 15)
    by ClientIP, bin(TimeGenerated, 1h)
| extend
    DurationMinutes = datetime_diff('minute', LastRequest, FirstRequest),
    ReconScore = toint(0)
        + case(RequestCount > 100, 3, RequestCount > 30, 2, RequestCount > 5, 1, 0)
        + case(UniqueUserAgents > 5, 2, UniqueUserAgents > 2, 1, 0)
        + case(UniquePaths > 20, 2, UniquePaths > 8, 1, 0)
        + case(HTTP404Count > 20, 1, 0)
| where ReconScore >= 2
| project
    TimeGenerated, ClientIP, RequestCount, UniqueUserAgents, UniquePaths,
    HTTP200Count, HTTP404Count, DurationMinutes, ReconScore,
    SampledUserAgents, SampledPaths, FirstRequest, LastRequest
| sort by ReconScore desc, RequestCount desc

Detects automated host fingerprinting and reconnaissance against internet-facing IIS web servers by correlating known scanner User-Agent strings, enumeration of host-disclosure paths (phpinfo, .env, server-status), high request volumes, and User-Agent diversity — scored into a composite ReconScore to prioritise high-confidence hits.

medium severity low confidence

Data Sources

Microsoft Sentinel - IIS Logs (W3CIISLog)

Required Tables

W3CIISLog

False Positives

  • Legitimate SEO crawlers such as Googlebot, Bingbot, or commercial crawlers (Screaming Frog, Ahrefs, Semrush) may trigger on path enumeration rules — allowlist known crawler IP ranges and User-Agent prefixes
  • Internal vulnerability scanners (Nessus, Qualys, Rapid7) run by the security team against web assets will generate identical patterns — exclude known scanner IP ranges via watchlist
  • Developer tooling such as curl, wget, or Python requests used legitimately by CI/CD pipelines or deployment scripts may match scanner User-Agent patterns — baseline known build server IPs

Sigma rule & cross-platform mapping

The detection logic for Gather Victim Host Information (T1592) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1592 Sigma rules on detection.fyi

Platform-specific guides for T1592

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-03-19 Research depth: deep
References (4)

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 1Web Server Fingerprinting via Automated Scanner User-Agent

    Expected signal: Web server access log entries (IIS W3C or Apache combined format) showing requests from the test host IP with User-Agents matching masscan, python-requests, Go-http-client, and curl patterns against multiple disclosure paths. ReconScore should trigger at >= 2 given multiple fingerprinting paths and multiple scanner User-Agents.

  2. Test 2OS-Targeted User-Agent Rotation for Victim Profiling

    Expected signal: Access log entries from test IP showing 5 distinct User-Agents representing Windows, Linux, macOS, Android, and iOS across the same path set within a short window. The User-Agent rotation hunting query should fire with UniqueOSHints = 5.

  3. Test 3Nmap Service and OS Version Detection Scan

    Expected signal: Network flow records showing TCP SYN packets to multiple ports from test host. Web server access logs showing nmap User-Agent requests (if HTTP ports scanned). IDS/IPS logs showing port scan detection. Network baseline anomaly for rapid sequential port connections.

Response Playbook

Triage

  1. 1. Identify the source IP from the alert and check its geolocation, ASN, and reputation via threat intelligence (VirusTotal, Shodan, AbuseIPDB). Note whether the ASN is a hosting provider, VPN service, Tor exit node, or residential ISP.
  2. 2. Review the full list of requested paths (SampledPaths in alert). Determine whether the enumeration targeted generic web discovery paths (robots.txt, sitemap.xml) vs. more targeted paths indicating knowledge of the specific stack (wp-login.php, /phpmyadmin, WEB-INF/).
  3. 3. Check the HTTP response codes in the session. A high 200-success rate against fingerprint paths (e.g., /phpinfo.php returned 200) indicates actual information disclosure — this significantly increases severity and urgency.
  4. 4. Look up the source IP in your WAF or firewall logs over the past 30 days. Determine whether this is a first-seen IP or part of a recurring pattern. Check whether the same IP has appeared against other assets in your network.
  5. 5. Correlate with DNS logs to determine whether the source IP queried your hostnames before making web requests — this may indicate targeted reconnaissance rather than opportunistic scanning.
  6. 6. Review the User-Agent strings. Generic scanner agents (masscan, nmap, nuclei) suggest automated tooling. Carefully crafted User-Agents mimicking browsers paired with fingerprinting paths suggest a more sophisticated operator performing manual profiling.
  7. 7. Cross-reference the source IP with any recent phishing campaigns, credential stuffing attempts, or brute-force activity across your environment to assess whether this is part of a broader pre-compromise operation.

Containment

  1. If the source IP is confirmed malicious and actively scanning: implement a block rule in your WAF, firewall, or CDN (Cloudflare, Akamai) for the specific IP and/or its /24 subnet. Set the block to expire after 30 days to avoid permanent stale rules.
  2. If sensitive host information was successfully served (e.g., /phpinfo.php returned 200, /.env returned configuration data): immediately remove or restrict access to those disclosure endpoints. Rotate any credentials or API keys that may have been exposed.
  3. Enable enhanced logging for the source IP across all perimeter systems (WAF, load balancer, API gateway) to capture any follow-on activity if the actor pivots to different infrastructure.
  4. If the recon pattern is part of a wider campaign (multiple IPs, coordinated targeting): escalate to CISO and consider activating defensive deception assets (honeypots or fake configuration files that trigger alerts when accessed).

Evidence Collection

  1. Export full W3C IIS or Apache access logs for the source IP for the past 72 hours: `Get-EventLog` or pull from SIEM. Preserve original log files with hash verification before any log rotation occurs.
  2. Capture a full packet capture (PCAP) of traffic from the source IP if real-time monitoring is available (network TAP, Azure Network Watcher, or VPC Flow Logs). Focus on HTTP/S request headers — these capture the exact User-Agent and additional fingerprinting headers (Accept-Language, Accept-Encoding) the adversary is collecting.
  3. Document the exact paths that returned HTTP 200 responses — these reveal what host information was successfully exfiltrated (server version headers, technology stack, configuration details). Pull the actual HTTP response bodies for those requests from your access log or cache.
  4. Collect WAF rule match logs for the same timeframe to determine whether any injection or exploitation attempts followed the reconnaissance session.
  5. Query your CDN or reverse proxy for the source IP to identify whether the actor requested assets from multiple virtual hosts or subdomains, suggesting broad infrastructure enumeration.

Escalation Criteria

  • ! Escalate immediately if host-disclosing paths (phpinfo.php, .env, web.config, server-status) returned HTTP 200 responses — actual information was served to the adversary and your attack surface is now partially mapped.
  • ! Escalate if the same source IP or campaign indicators appear across multiple internet-facing assets (multiple servers, multiple subdomains, API endpoints) within a 24-hour window, indicating targeted reconnaissance of your organization rather than opportunistic scanning.
  • ! Escalate if reconnaissance activity is followed within 48 hours by authentication attempts, exploitation attempts, or phishing emails referencing specific host configurations discovered during the scan — this establishes a kill chain and requires incident response activation.
  • ! Escalate if threat intelligence identifies the source IP as belonging to a known APT group infrastructure or if the IP appears in sector-specific threat feeds (e.g., CISA advisories for critical infrastructure, government attribution reports).

Investigation Guide

Forensic Artifacts

  • > Web server access logs (IIS W3C logs: %SystemDrive%\inetpub\logs\LogFiles\, Apache: /var/log/apache2/access.log, Nginx: /var/log/nginx/access.log) — primary evidence source for fingerprinting sessions
  • > WAF and reverse proxy logs showing blocked vs. allowed request patterns, full HTTP request headers including User-Agent, X-Forwarded-For, and custom fingerprinting headers
  • > Network flow records (NetFlow/IPFIX, AWS VPC Flow Logs, Azure NSG Flow Logs) showing connection volumes and duration from source IP to web server ports (80, 443, 8080, 8443)
  • > DNS query logs showing whether the source IP performed reverse DNS lookups or queried your organization's DNS zones prior to web scanning
  • > HTTP response headers cached in CDN or load balancer — these reveal what server version strings, technology banners, and X-Powered-By headers were served to the adversary

Tuning Guidance

This detection has inherent high false-positive rates because legitimate crawlers, monitoring services, and security scanners use the same paths and User-Agents. Effective tuning requires three steps: (1) Build an IP allowlist for known-good scanners — fetch ASN ranges for Google, Bing, Ahrefs, Screaming Frog, your own vulnerability scanners, and CDN health-check probes, then exclude these from the main detection while retaining them in hunting queries. (2) Increase the ReconScore threshold to 3 or 4 in high-traffic environments where bot traffic is common — reduce sensitivity during known marketing crawl campaigns. (3) Prioritize alerts where HTTP200Count is non-zero for fingerprinting paths — a scanner that receives error responses gathered nothing useful, while one that got 200 responses is a genuine intelligence leak. For the low-and-slow hunting query, exclude IP ranges belonging to cloud WAF providers (Cloudflare: 103.21.244.0/22, 103.22.200.0/22) that make regular health probes. Review the detection monthly and cull User-Agent terms that generate >80% false positives in your environment.

Hunting Queries

Hunts for single source IPs rotating through multiple OS-representative User-Agent strings within a 30-minute window — a pattern consistent with an adversary testing which OS-targeted payloads to serve victims, rather than normal browser diversity.

Hunting — KQL
kql 
// Hunt for User-Agent rotation indicating systematic OS/browser fingerprinting
// Different pattern: focuses on SINGLE IPs rotating through OS-representative User-Agents
W3CIISLog
| where TimeGenerated > ago(7d)
| where isnotempty(csUserAgent)
| extend OSHint = case(
    csUserAgent has "Windows NT 10", "Win10",
    csUserAgent has "Windows NT 6.3", "Win8.1",
    csUserAgent has "Windows NT 6.1", "Win7",
    csUserAgent has "X11; Linux", "Linux",
    csUserAgent has "Macintosh; Intel Mac", "macOS",
    csUserAgent has "Android", "Android",
    csUserAgent has "iPhone", "iOS",
    csUserAgent has "curl", "CLI-curl",
    csUserAgent has "python", "CLI-python",
    csUserAgent has "Go-http", "CLI-Go",
    "Other"
)
| summarize
    UniqueOSHints      = dcount(OSHint),
    UniqueUserAgents   = dcount(csUserAgent),
    RequestCount       = count(),
    OSProfiles         = make_set(OSHint, 15),
    SampledUAs         = make_set(csUserAgent, 10)
    by cIP, bin(TimeGenerated, 30m)
| where UniqueOSHints >= 3 and UniqueUserAgents >= 3 and RequestCount >= 5
| project TimeGenerated, SourceIP = cIP, UniqueOSHints, UniqueUserAgents, RequestCount, OSProfiles, SampledUAs
| sort by UniqueOSHints desc
Hunting — SPL
spl 
index=web (sourcetype="access_combined" OR sourcetype="iis") earliest=-7d
| eval os_hint=case(
    match(useragent, "Windows NT 10"), "Win10",
    match(useragent, "Windows NT 6\.3"), "Win8.1",
    match(useragent, "Windows NT 6\.1"), "Win7",
    match(useragent, "X11; Linux"), "Linux",
    match(useragent, "Macintosh; Intel Mac"), "macOS",
    match(useragent, "Android"), "Android",
    match(useragent, "iPhone"), "iOS",
    match(useragent, "curl"), "CLI-curl",
    match(useragent, "python"), "CLI-python",
    true(), "Other"
)
| bucket span=30m _time
| stats dc(os_hint) AS unique_os, dc(useragent) AS unique_ua, count AS req_count, values(os_hint) AS os_profiles by src_ip, _time
| where unique_os >= 3 AND unique_ua >= 3 AND req_count >= 5
| sort -unique_os

Hunts for low-and-slow persistent reconnaissance over 3+ days — a pattern consistent with APT groups (including Volt Typhoon) that spread automated fingerprinting across time to evade rate-based detections. Focuses on paths that disclose application stack details.

Hunting — KQL
kql 
// Hunt for low-and-slow persistent host enumeration over multiple days (APT pattern)
// Different pattern: long-duration, low-volume recon spanning 3+ days from same IP
let DisclosurePaths = dynamic([
    "/robots.txt", "/.git/HEAD", "/.env", "/phpinfo.php", "/server-status",
    "/web.config", "/WEB-INF/web.xml", "/.well-known/security.txt",
    "/CHANGELOG.txt", "/composer.json", "/package.json", "/Gemfile"
]);
W3CIISLog
| where TimeGenerated > ago(30d)
| where csUriStem has_any (DisclosurePaths)
| summarize
    ActiveDays   = dcount(bin(TimeGenerated, 1d)),
    TotalReqs    = count(),
    FirstSeen    = min(TimeGenerated),
    LastSeen     = max(TimeGenerated),
    SuccessHits  = countif(scStatus == 200),
    DisclosurePaths = make_set(csUriStem, 20)
    by cIP
| where ActiveDays >= 3 and TotalReqs >= 5
| extend
    DaySpan      = datetime_diff('day', LastSeen, FirstSeen),
    AvgReqPerDay = round(todouble(TotalReqs) / todouble(ActiveDays), 1)
| where DaySpan >= 3
| project FirstSeen, LastSeen, SourceIP = cIP, ActiveDays, DaySpan, TotalReqs, AvgReqPerDay, SuccessHits, DisclosurePaths
| sort by SuccessHits desc, ActiveDays desc
Hunting — SPL
spl 
index=web (sourcetype="access_combined" OR sourcetype="iis") earliest=-30d
| where match(uri_path, "robots\.txt|\.git\/HEAD|\.env|phpinfo\.php|server-status|web\.config|WEB-INF|security\.txt|CHANGELOG|composer\.json|package\.json|Gemfile")
| eval day=strftime(_time, "%Y-%m-%d")
| stats dc(day) AS active_days, count AS total_reqs, min(_time) AS first_seen, max(_time) AS last_seen, count(eval(status=="200")) AS success_hits, values(uri_path) AS paths by src_ip
| where active_days >= 3 AND total_reqs >= 5
| eval day_span=round((last_seen - first_seen) / 86400, 0)
| where day_span >= 3
| eval avg_req_per_day=round(total_reqs / active_days, 1)
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| table src_ip, active_days, day_span, total_reqs, avg_req_per_day, success_hits, paths, first_seen, last_seen
| sort -success_hits, -active_days

Hunts for actively exploitable information disclosure endpoints returning HTTP 200 to external requestors. Identifies paths like phpinfo.php, Spring Actuator /env, and /server-status that expose exact technology stack versions — the information adversaries need to select targeted exploits.

Hunting — KQL
kql 
// Hunt for server version disclosure in HTTP response headers served to external IPs
// Detects when our servers are actively leaking technology stack details to requestors
// Uses W3CIISLog sc-win32-status and additional header fields if available
W3CIISLog
| where TimeGenerated > ago(24h)
| where scStatus == 200
| where csUriStem in ("/phpinfo.php", "/server-status", "/server-info", "/_status", "/status", "/health", "/info", "/debug", "/actuator/env", "/actuator/info", "/actuator/health", "/api/version", "/version.txt", "/buildinfo")
| summarize
    UniqueIPs       = dcount(cIP),
    TotalHits       = count(),
    ExternalIPs     = make_set(cIP, 20),
    AvgResponseSize = avg(scBytes)
    by csUriStem
| where TotalHits > 0
| extend RiskLevel = case(
    csUriStem in ("/phpinfo.php", "/server-status", "/actuator/env"), "CRITICAL",
    csUriStem in ("/server-info", "/debug", "/actuator/info"), "HIGH",
    "MEDIUM"
)
| project csUriStem, RiskLevel, TotalHits, UniqueIPs, AvgResponseSize, ExternalIPs
| sort by RiskLevel asc, TotalHits desc
Hunting — SPL
spl 
index=web (sourcetype="access_combined" OR sourcetype="iis") earliest=-24h status=200
| where match(uri_path, "phpinfo\.php|server-status|server-info|_status|\/status|\/info|\/debug|actuator\/env|actuator\/info|actuator\/health|api\/version|version\.txt|buildinfo")
| stats count AS total_hits, dc(src_ip) AS unique_ips, avg(bytes) AS avg_response_size, values(src_ip) AS source_ips by uri_path
| eval risk_level=case(
    match(uri_path, "phpinfo\.php|server-status|actuator\/env"), "CRITICAL",
    match(uri_path, "server-info|debug|actuator\/info"), "HIGH",
    true(), "MEDIUM"
)
| table uri_path, risk_level, total_hits, unique_ips, avg_response_size, source_ips
| sort risk_level, -total_hits

Atomic Red Team Tests

Test 1 Web Server Fingerprinting via Automated Scanner User-Agent
linux

Simulates an adversary using curl with scanner-style User-Agents to enumerate host-disclosure paths on a web server. Generates the exact log patterns this detection targets.

Command

bash 
TARGET_HOST="http://localhost:80"
for UA in "masscan/1.0" "python-requests/2.28.0" "Go-http-client/1.1" "curl/7.68.0 (linux)"; do
  for PATH in "/robots.txt" "/phpinfo.php" "/.env" "/server-status" "/sitemap.xml" "/web.config" "/CHANGELOG.txt"; do
    curl -s -o /dev/null -w "%{http_code} ${PATH} [${UA}]\n" \
      -A "${UA}" \
      --connect-timeout 3 \
      "${TARGET_HOST}${PATH}"
  done
done

Cleanup

bash 
# No cleanup needed — no persistent changes made
echo 'Atomic test complete. Review web server access logs for scanner User-Agent entries.'

Expected Telemetry

Web server access log entries (IIS W3C or Apache combined format) showing requests from the test host IP with User-Agents matching masscan, python-requests, Go-http-client, and curl patterns against multiple disclosure paths. ReconScore should trigger at >= 2 given multiple fingerprinting paths and multiple scanner User-Agents.

Expected Detection

KQL/SPL detection alert for source IP with ReconScore >= 2, UniqueUserAgents = 4, UniquePaths = 7, with SampledPaths containing /.env, /phpinfo.php, and /server-status

Test 2 OS-Targeted User-Agent Rotation for Victim Profiling
linux

Simulates an adversary rotating through OS-representative User-Agent strings to test which operating system is present on the target — a technique used to serve OS-specific malware to watering hole victims.

Command

bash 
TARGET_HOST="http://localhost:80"
# Rotate through User-Agents representing different OS profiles
PATH_LIST=("/" "/login" "/download" "/update")
UA_LIST=(
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
  "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"
  "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_0) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15"
  "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.43"
  "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15"
)
for UA in "${UA_LIST[@]}"; do
  for P in "${PATH_LIST[@]}"; do
    curl -s -o /dev/null -A "${UA}" --connect-timeout 3 "${TARGET_HOST}${P}"
    sleep 0.5
  done
done

Cleanup

bash 
echo 'UA rotation test complete. Review web logs for OS fingerprinting pattern.'

Expected Telemetry

Access log entries from test IP showing 5 distinct User-Agents representing Windows, Linux, macOS, Android, and iOS across the same path set within a short window. The User-Agent rotation hunting query should fire with UniqueOSHints = 5.

Expected Detection

Hunting query 1 (User-Agent rotation) alert for source IP with UniqueOSHints >= 3 and UniqueUserAgents >= 3 within the 30-minute window

Test 3 Nmap Service and OS Version Detection Scan
linux

Simulates an adversary running Nmap service version detection (-sV) and OS fingerprinting (-O) against a target host to enumerate exposed services, software versions, and operating system details. This is the most common active technique for T1592 host information gathering.

Command

bash 
TARGET_IP="127.0.0.1"  # Replace with authorized target IP
# Service version detection + OS fingerprinting (requires root for OS detection)
sudo nmap -sV -O --version-intensity 5 \
  -p 22,80,443,445,3389,8080,8443 \
  --open \
  -oN /tmp/nmap_host_info_test.txt \
  ${TARGET_IP}
cat /tmp/nmap_host_info_test.txt

Cleanup

bash 
rm -f /tmp/nmap_host_info_test.txt
echo 'Nmap scan complete. Check web server logs and network flow records for scan traffic.'

Expected Telemetry

Network flow records showing TCP SYN packets to multiple ports from test host. Web server access logs showing nmap User-Agent requests (if HTTP ports scanned). IDS/IPS logs showing port scan detection. Network baseline anomaly for rapid sequential port connections.

Expected Detection

IDS alert for port scan activity; web server detection may fire if nmap probes port 80/443 with its default User-Agent (Mozilla/5.0 (compatible; Nmap Scripting Engine)) hitting fingerprinting paths during service detection phase

Related Detections

Tactic Hub

TA0043Reconnaissance

Sub-techniques (4)

Related Techniques

T1595Active ScanningT1598Phishing for InformationT1592.001HardwareT1592.002SoftwareT1592.003FirmwareT1592.004Client ConfigurationsT1190Exploit Public-Facing ApplicationT1133External Remote ServicesT1596Search Open Technical Databases

Same Tactic: Reconnaissance

Popular Detections