T1592.001 Microsoft Sentinel · KQL

Detect Hardware in Microsoft Sentinel

Adversaries may gather information about the victim's host hardware that can be used during targeting. Hardware details may include types and versions of specific hosts, as well as the presence of additional defensive components such as smart card readers, biometric authentication hardware, TPM chips, and dedicated encryption co-processors. Adversaries gather this information via direct Active Scanning (ex: banner grabbing, SNMP enumeration), Phishing for Information, or by compromising third-party websites and deploying malicious JavaScript reconnaissance frameworks (such as ScanBox) that silently collect host hardware telemetry from visiting users. Hardware information may also be passively harvested from publicly accessible sources including job postings listing specific hardware requirements, LinkedIn profiles, assessment reports, equipment purchase invoices, and network topology diagrams. Collected hardware intelligence enables adversaries to tailor exploits for specific processor architectures, identify hardware vulnerabilities (e.g., Spectre/Meltdown variants), plan hardware supply chain attack opportunities (T1195.003), and understand the physical security posture of the target — including whether hardware-based authentication is in use.

MITRE ATT&CK

Tactic
Reconnaissance
Technique
T1592 Gather Victim Host Information
Sub-technique
T1592.001 Hardware
Canonical reference
https://attack.mitre.org/techniques/T1592/001/

KQL Detection Query

Microsoft Sentinel (KQL)
kusto
// T1592.001 — Gather Victim Host Information: Hardware
// Detects the minority of hardware reconnaissance activity visible within victim networks.
// PRIMARY LIMITATION: Most T1592.001 activity (Shodan scanning, OSINT, job postings, LinkedIn)
// occurs entirely outside the victim environment. This query targets the two detectable
// in-environment signals: ScanBox-style JavaScript fingerprinting exfiltration and
// SNMP/service enumeration attempts against managed hosts.
//
// Confidence is LOW due to fundamental external-nature of this PRE technique.

let ExcludedHostnames = dynamic([
    "microsoft.com", "office.com", "windows.com", "live.com", "microsoftonline.com",
    "google.com", "googleapis.com", "gstatic.com",
    "apple.com", "icloud.com",
    "mozilla.org", "firefox.com",
    "amazon.com", "amazonaws.com", "cloudfront.net",
    "akamai.net", "akamaized.net", "cloudflare.com",
    "fastly.net", "cdn77.com"
]);
// ScanBox and similar JavaScript reconnaissance framework URL patterns
let ScanBoxURLPatterns = dynamic([
    "/scanbox", "/fp.php", "/gate.php", "/collect.php", "/beacon.php",
    "/hwinfo", "/hardware", "/fingerprint", "/stat.php", "/track.php"
]);
// Hardware-identifying parameters exfiltrated by browser fingerprinting scripts
let HardwareFingerprintParams = dynamic([
    "hardwareConcurrency", "deviceMemory", "cpuClass",
    "hardwareinfo", "numCores", "screenDepth",
    "colorDepth", "pixelDepth", "touchPoints"
]);
// Branch 1: Proxy/Firewall (CommonSecurityLog) detecting ScanBox-style POST exfiltration
let Branch1 = CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceProduct has_any ("Proxy", "Web Gateway", "URL Filter", "Firewall", "WAF", "NGFW")
    or DeviceVendor has_any ("Palo Alto Networks", "Fortinet", "Zscaler", "iboss",
                              "Symantec", "McAfee", "Blue Coat", "Cisco", "F5", "Imperva")
| where RequestMethod =~ "POST"
| where BytesSent between (100 .. 50000)
| where RequestURL has_any (ScanBoxURLPatterns)
    or AdditionalExtensions has_any (HardwareFingerprintParams)
    or Message has_any (HardwareFingerprintParams)
| where not(DestinationHostName has_any (ExcludedHostnames))
| extend DetectionBranch = "ScanBox-POST"
| extend RiskIndicator = case(
    RequestURL has_any ("/scanbox", "/gate.php", "/fp.php"), "KnownScanBoxURL",
    AdditionalExtensions has_any ("hardwareConcurrency", "deviceMemory", "cpuClass"), "HardwareFingerprintParam",
    RequestURL has_any ("/collect.php", "/beacon.php") and BytesSent > 500, "FingerprintExfiltration",
    "SuspiciousFingerprintURL"
)
| project TimeGenerated, SourceUserName, SourceIP, DestinationHostName, DestinationPort,
          RequestURL, RequestMethod, BytesSent, BytesReceived,
          DeviceVendor, Activity, RiskIndicator, DetectionBranch;
// Branch 2: SNMP enumeration targeting hardware OIDs from external/unexpected sources
// SNMP OID 1.3.6.1.2.1.25.3.2 = hrDeviceType, OID 1.3.6.1.2.1.47 = ENTITY-MIB (hardware)
let Branch2 = CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort == 161 or DestinationPort == 162  // SNMP UDP ports
| where ipv4_is_private(SourceIP) == false  // Inbound from external
| extend DetectionBranch = "ExternalSNMPEnum"
| extend RiskIndicator = "ExternalSNMPHardwareEnum"
| project TimeGenerated, SourceUserName = "", SourceIP, 
          DestinationHostName, DestinationPort,
          RequestURL = "", RequestMethod = "SNMP", BytesSent, BytesReceived,
          DeviceVendor, Activity, RiskIndicator, DetectionBranch;
Branch1
| union Branch2
| sort by TimeGenerated desc
medium severity low confidence

Detects hardware reconnaissance via two branches. Branch 1 uses proxy/firewall telemetry (CommonSecurityLog) to identify ScanBox-style JavaScript fingerprint data being POST-exfiltrated to external infrastructure from managed endpoints — matching on known ScanBox URL patterns (/fp.php, /gate.php, /scanbox) and hardware-identifying parameters (hardwareConcurrency, deviceMemory, cpuClass). Branch 2 detects external SNMP enumeration targeting internal hosts on UDP port 161, which can expose hardware inventory via the HOST-RESOURCES-MIB and ENTITY-MIB OID trees. Excludes major CDN and legitimate vendor domains to reduce false positives. Confidence is set to LOW because the vast majority of T1592.001 activity (Shodan, OSINT, LinkedIn, external scanning) occurs entirely outside the victim environment and leaves no observable internal telemetry.

Data Sources

Network Traffic: Network Traffic ContentNetwork Traffic: Network Traffic FlowApplication Log: Application Log Content

Required Tables

CommonSecurityLog

False Positives & Tuning

  • Analytics and telemetry platforms (Mixpanel, Amplitude, Heap, FullStory) that legitimately collect browser device metrics including screen resolution, hardware concurrency, and device memory for UX analytics
  • Authorized vulnerability management tools (Qualys, Rapid7 InsightVM, Tenable Nessus, Qualys VMDR) performing scheduled asset inventory scans including SNMP hardware enumeration from known scanner IPs
  • Web application performance monitoring frameworks (Modernizr, feature-detective.js) that detect browser hardware capabilities for progressive enhancement and responsive design decisions
  • Internal IT asset management systems performing SNMP polling for hardware inventory, network management, or capacity planning — typically from known NMS IP ranges
  • Content delivery networks and web performance tools (New Relic Browser, Datadog RUM, Dynatrace) that collect device/hardware metrics as part of real user monitoring
Download portable Sigma rule (.yml)

Other platforms for T1592.001


Testing Methodology

Validate this detection against 5 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 1Hardware Fingerprint Collection and Simulated Exfiltration via PowerShell

    Expected signal: Sysmon Event ID 1: Process Create for powershell.exe with CommandLine containing 'Invoke-WebRequest', 'collect.php', 'hardwareConcurrency', 'deviceMemory'. Sysmon Event ID 3: Network Connection to 127.0.0.1:8888 from powershell.exe. Proxy logs (if present): POST to /collect.php with ?hwid= parameter and JSON body containing hardware parameter names. PowerShell ScriptBlock Log Event ID 4104 with full script content.

  2. Test 2SNMP Hardware Enumeration via snmpwalk (Linux)

    Expected signal: Linux auditd EXECVE record for snmpwalk with arguments including community string and hardware OIDs. Syslog entries from snmpd if configured to log queries. Network capture (if enabled): UDP packets to port 161 with SNMP GET-NEXT PDUs targeting OID 1.3.6.1.2.1.25.3.2 (hrDeviceType). Firewall/flow logs: UDP/161 connection from initiating host to target.

  3. Test 3JavaScript Hardware Fingerprint Collection via Browser DevTools Console

    Expected signal: Sysmon Event ID 1: Process Create for msedge.exe or chrome.exe with headless flag. Sysmon Event ID 3: Network Connection attempt from browser process to 127.0.0.1:9999. Sysmon Event ID 11: File Create for df00tech-scanbox-sim.js in TEMP directory. Proxy logs (if present): GET/POST to /fp.php with ?fid= parameter from browser User-Agent.

  4. Test 4Active Hardware Banner Grabbing via Nmap Service Scripts

    Expected signal: Linux auditd EXECVE record for nmap with service detection and NSE script flags. Syslog: connection attempts to ports 22, 80, 443, 161, 8080 originating from localhost. Network flow logs: multiple short-duration TCP SYN connections from initiating host to target. Any IDS/IPS (Suricata, Snort) will generate alerts for Nmap SYN scan signature (ET SCAN Nmap). File creation: /tmp/df00tech-hw-scan.txt with scan results.

  5. Test 5Hardware Enumeration via WMI Query Simulation (Windows Endpoint)

    Expected signal: Sysmon Event ID 1: Process Create for powershell.exe with WMI query commands (Get-WmiObject). Sysmon Event ID 11: File Create for df00tech-hwinventory.json in TEMP. Windows Security Event ID 4688 (if command line auditing enabled). PowerShell ScriptBlock Log Event ID 4104 with full WMI query content. WMI activity log: Microsoft-Windows-WMI-Activity/Operational with WMI queries for Win32_Processor, Win32_BIOS, Win32_BaseBoard.

Unlock Pro Content

Get the full detection package for T1592.001 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections