Overview

System Information Discovery (T1082) is a technique where adversaries enumerate detailed information about a target system — including OS version, patch level, architecture, hostname, and hardware configuration. Attackers use this intelligence to make informed decisions: whether to proceed with a full compromise, which exploits to deploy, how to tailor payloads to the environment, and how to avoid triggering version-specific defenses.

Because this technique appears in virtually every intrusion chain — from initial access through ransomware staging — every security team needs reliable detection coverage for it. Alone, a single systeminfo execution looks mundane; in context, it is often the clearest signal that an adversary has established a foothold and is actively preparing their next move.

Attacker Perspective

After gaining initial access, one of the first things an adversary does is take stock of where they’ve landed — and T1082 is their primary tool for doing exactly that.

• Windows reconnaissance bursts: Threat actors such as FIN7 and Lazarus Group run a rapid sequence of built-in commands — systeminfo, hostname, whoami, ver — within seconds of establishing a shell, often piping output to a staging file like systeminfo > C:\Users\Public\info.txt for later exfiltration.
• PowerShell environment fingerprinting: Attackers use Get-ComputerInfo, Get-WmiObject Win32_OperatingSystem, or [System.Environment]::OSVersion inside obfuscated PowerShell to gather OS build numbers and patch levels without spawning a visible cmd.exe process.
• Linux/macOS enumeration scripts: Post-exploitation frameworks like Metasploit and Cobalt Strike automatically run commands such as uname -a, cat /etc/os-release, sw_vers, and systemsetup -getcomputersleep as part of their built-in post-exploitation modules immediately after session establishment.
• ESXi and cloud API abuse: Ransomware operators targeting virtualization infrastructure (e.g., Royal, Black Basta) use esxcli system version get and esxcli system hostname get to confirm hypervisor details before deploying ESXi-specific encryptors; in cloud environments, attackers call AWS DescribeInstances or Azure VM metadata APIs after credential theft to enumerate targets at scale.

This technique is attractive precisely because it uses native OS utilities that are always present, rarely blocked, and generate noise that blends into legitimate administrative activity — making it a low-risk, high-value step for any adversary.

Detection Strategy

Required Telemetry

• Windows — Process Creation (Event ID 4688): Enable via Group Policy: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line logging in process creation events via GPO: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This generates Event ID 4688 with full command-line arguments.
• Windows — Sysmon (Event ID 1): Deploy Sysmon with a configuration that captures process creation, including CommandLine, ParentImage, ParentCommandLine, and User fields. Sysmon Event ID 1 is generally richer and more reliable than 4688 alone. Use a community config such as SwiftOnSecurity or Olaf Hartong’s modular config as a baseline.
• Windows — PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. This captures the full decoded content of every PowerShell script block, including obfuscated WMI queries and Get-ComputerInfo calls, in the Microsoft-Windows-PowerShell/Operational log.
• Windows — PowerShell Module Logging (Event ID 4103): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1 with ModuleNames = *. Captures individual pipeline execution and parameter values for all loaded modules.
• Linux — auditd rules: Add the following rules to /etc/audit/rules.d/discovery.rules to capture execution of enumeration binaries:
  -a always,exit -F arch=b64 -S execve -F path=/usr/bin/uname -k sysinfo_discovery,
  -a always,exit -F arch=b64 -S execve -F path=/usr/bin/hostnamectl -k sysinfo_discovery,
  -a always,exit -F arch=b64 -S open -F path=/etc/os-release -k sysinfo_discovery.
  Ship these logs to your SIEM via auditbeats, Filebeat (audit module), or rsyslog.
• macOS — Endpoint Security Framework / Unified Log: Use an EDR agent (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) that hooks the Endpoint Security Framework. Alternatively, enable sudo log config --subsystem com.apple.security --mode level:debug and monitor for sw_vers, system_profiler, and systemsetup execution. OpenBSM audit rules targeting execve syscalls also work: configure /etc/security/audit_control with flags:ex,lo,aa.
• ESXi — Shell and esxcli logs: Enable ESXi Shell logging and ship /var/log/shell.log and /var/log/hostd.log to your SIEM via syslog. Configure syslog forwarding in ESXi: Host → Configure → System → Advanced Settings → Syslog.global.logHost. Look for esxcli system command executions in shell.log.
• Cloud (AWS/Azure/GCP) — API / Control Plane Logs: Enable AWS CloudTrail (all regions, include management events) and capture DescribeInstances, DescribeInstanceAttribute API calls. For Azure, enable Azure Activity Log and Microsoft Defender for Cloud; monitor Microsoft.Compute/virtualMachines/read operations. For GCP, enable Cloud Audit Logs (Admin Activity) and monitor compute.instances.list and compute.instances.get calls.
• EDR telemetry (any platform): If you have CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne deployed, their process telemetry is the highest-fidelity source and should be your primary detection layer. All of the above command patterns will appear in their process trees with full context.

Key Indicators

• Windows — suspicious execution of systeminfo: Log source: Sysmon Event ID 1 or Windows Event ID 4688. Field: Image ends with \systeminfo.exe. Flag when ParentImage is an unusual spawning process such as cmd.exe spawned by powershell.exe, wscript.exe, mshta.exe, regsvr32.exe, or any Office application (winword.exe, excel.exe). Also flag output redirection in CommandLine matching pattern systeminfo > or systeminfo /fo csv.
• Windows — rapid sequential discovery command execution: Log source: Sysmon Event ID 1 or 4688. Look for multiple discovery binaries executed within a short time window (e.g., 60–120 seconds) by the same User on the same Computer. Command patterns: hostname, whoami, net user, ipconfig /all, systeminfo, tasklist, ver. This “discovery burst” pattern is a strong behavioral indicator of post-exploitation activity.
• Windows — PowerShell WMI-based OS enumeration: Log source: PowerShell Event ID 4104 (Script Block Logging). Field: ScriptBlockText contains patterns such as Win32_OperatingSystem, Get-ComputerInfo, Get-WmiObject combined with OSVersion, CSName, or OSArchitecture. Also flag [System.Environment]::OSVersion and [System.Runtime.InteropServices.RuntimeInformation]::OSDescription.
• Linux — uname and os-release access from unexpected parents: Log source: auditd (syscall execve with key sysinfo_discovery). Field: exe equals /usr/bin/uname and ppid maps to a process that is not a known admin shell (e.g., parent is a web server process like apache2, nginx, php-fpm, or a container runtime). Also monitor open syscalls on /etc/os-release, /proc/version, /etc/issue, and /proc/cpuinfo from interactive shells spawned by non-admin users.
• macOS — system profiler and sw_vers abuse: Log source: EDR process telemetry or OpenBSM audit log. Field: process_name equals sw_vers or system_profiler with a parent process that is a browser, document viewer, or downloaded application. Flag systemsetup executions that occur outside of standard admin maintenance windows or from unusual parent processes.
• ESXi — esxcli system enumeration: Log source: ESXi /var/log/shell.log. Field: log line contains esxcli system hostname get, esxcli system version get, vim-cmd hostsvc/hostsummary, or esxcli hardware platform get. Flag any of these commands executed by an account that is not a known named admin, especially if the session was established outside of business hours or from an unusual source IP.
• Cloud — unexpected DescribeInstances / VM list API calls: Log source: AWS CloudTrail, Azure Activity Log. Field (AWS): eventName equals DescribeInstances or DescribeInstanceAttribute, and userIdentity.type is IAMUser or AssumedRole from an IP address not in your known admin CIDR ranges. Field (Azure): operationName equals Microsoft.Compute/virtualMachines/read from a callerIpAddress that is not a known management IP or automation account.

Detection Logic

Rule 1 (Broad — High Sensitivity): Discovery Binary Execution from Unusual Parent
IF process_name IN ["systeminfo.exe", "hostname.exe", "ver.exe", "uname", "sw_vers", "system_profiler"]
AND parent_process_name IN ["powershell.exe", "cmd.exe", "wscript.exe", "mshta.exe", "regsvr32.exe", "winword.exe", "excel.exe", "bash", "sh", "python", "python3", "ruby", "perl", "php"]
AND NOT (user IN [known_admin_accounts] AND source_ip IN [admin_jump_hosts])
THEN alert(severity=medium)

This catches any execution of common discovery utilities spawned by scripting interpreters or Office applications — covering both Windows and Linux post-exploitation patterns. Expect moderate alert volume; requires tuning based on your environment’s admin tooling and scripting practices.

Rule 2 (Behavioral — High Value): Discovery Command Burst (Multiple Tools, Short Window)
IF COUNT(DISTINCT process_name) >= 4
WHERE process_name IN ["systeminfo.exe", "hostname.exe", "whoami.exe", "ipconfig.exe", "net.exe", "tasklist.exe", "ver.exe", "uname", "id", "ifconfig", "cat /etc/os-release"]
AND same user AND same host
WITHIN 120 seconds
AND NOT parent_process_name IN [known_automation_tools]
THEN alert(severity=high)

This behavioral rule specifically targets the “rapid-fire enumeration” pattern common to post-exploitation frameworks (Cobalt Strike, Metasploit, Sliver) that run a suite of discovery commands immediately after session establishment. Low false positive rate in non-SOC environments; will fire on legitimate pentest activity.

Rule 3 (PowerShell — Medium Precision): WMI OS Enumeration in Script Block
IF event_id = 4104
AND script_block_text MATCHES (regex: "Win32_OperatingSystem|Get-ComputerInfo|OSVersion|OSArchitecture|CSDVersion")
AND script_block_text MATCHES (regex: "Get-WmiObject|Get-CimInstance|\[wmi\]|Invoke-WmiMethod")
AND NOT (script_block_path STARTS WITH "C:\Program Files\" OR script_block_path STARTS WITH "C:\Windows\")
THEN alert(severity=medium)

Catches PowerShell-based OS enumeration that avoids spawning child processes. The exclusion on signed script paths reduces noise from legitimate management tooling. Still expect false positives from legitimate monitoring agents; tune by adding known script hashes or signing certificate thumbprints to an exclusion list.

Rule 4 (High Precision — Low Noise): systeminfo Output Redirected to Disk
IF process_name = "systeminfo.exe"
AND command_line MATCHES (regex: ">|/fo csv|/fo list|>> ")
AND file_path_written MATCHES (regex: "C:\\Users\\Public|C:\\Temp|C:\\Windows\\Temp|/tmp/|/dev/shm/")
AND NOT user IN [known_admin_service_accounts]
THEN alert(severity=high)

This precision rule catches a very specific attacker behavior: capturing systeminfo output to a staging directory for later exfiltration. Very low false positive rate in most environments. Any hit here should be treated as a confirmed suspicious event and escalated immediately.

Tuning Guidance

• IT management platforms (SCCM, Ansible, Puppet, Chef, Tanium): These tools routinely execute systeminfo, WMI queries, and uname as part of inventory collection. Exclude by adding parent_process_name IN ["ccmexec.exe", "python.exe" WHERE command_line CONTAINS "ansible", "puppet", "chef-client"] or by user account (user IN [sccm_service_account, ansible_svc]). Baseline the exact command-line strings these tools use and add them as explicit exclusions.
• Vulnerability scanners (Tenable Nessus, Qualys, Rapid7 InsightVM): Authenticated scans will generate high volumes of WMI and SSH-based OS enumeration. Exclude by source_ip IN [scanner_ips] or by the service account used for authenticated scanning. Create a suppression window tied to your scheduled scan windows.
• Security and monitoring agents (CrowdStrike, SentinelOne, Elastic Agent, Splunk UF, Datadog): Some agents call WMI or read /etc/os-release at startup and on schedule. Identify the specific process names and parent process names these agents use and add targeted exclusions rather than broad account-level suppression.
• Developer workstations and CI/CD pipelines: Developers frequently run PowerShell scripts locally or in build pipelines that include WMI calls for environment detection. Scope exclusions to known developer machine OUs (via computer_ou CONTAINS "Developer Workstations") or by CI/CD service account names, and limit the exclusion to Rule 3 (the PowerShell WMI rule) only — do not suppress the behavioral burst rule for these hosts.
• Administrative jump servers and bastion hosts: Sysadmins legitimately run systeminfo and uname -a from jump hosts during troubleshooting. Exclude by source_host IN [known_bastion_hosts] and user IN [named_admin_accounts] — but enforce MFA and session recording on those hosts so the exclusion is justified and auditable.
• Cloud automation and IaC (Terraform, Boto3 scripts, Azure SDKs): Infrastructure automation routinely calls DescribeInstances and VM read APIs. Exclude by userIdentity.arn CONTAINS "terraform-role" OR "automation-account" in CloudTrail rules, and ensure these service principals have tightly scoped IAM policies to validate the exclusion is safe.

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event: Pull the original log entry directly from your SIEM using the event ID, timestamp, and hostname from the alert — confirm the CommandLine, User, ParentImage, and Computer fields are populated and match what the rule triggered on. Do not rely solely on the alert summary; raw event validation rules out parser errors or rule logic bugs.
2. Identify the affected host and user, and check for privilege: Query your directory service (Active Directory, LDAP, or cloud IAM) to determine the account type — flag immediately if the executing account is a service account, domain admin, or cloud privileged role. Cross-reference the hostname against your asset inventory to determine its classification (workstation, server, domain controller, cloud instance, ESXi host) since higher-value assets elevate priority.
3. Pull the full process execution chain and parent tree: In your EDR console (CrowdStrike Process Tree, MDE Device Timeline, SentinelOne Storyline) or via Sysmon Event IDs 1 and 5, trace the full ancestry of the discovery process — from the suspicious binary back through its parent, grandparent, and any injected or hollowed processes. Look for unusual chains such as winword.exe → cmd.exe → systeminfo.exe or nginx → bash → uname, which indicate initial access via document macro or web shell respectively.
4. Check for files written to disk and network connections: Search for file creation events (Sysmon Event ID 11) within a ±5 minute window of the alert on the same host, specifically in staging directories (C:\Users\Public, C:\Temp, /tmp, /dev/shm). Simultaneously pull network connection events (Sysmon Event ID 3, or EDR network telemetry) to identify any outbound connections to external IPs or domains that occurred within the same time window — a connection shortly after discovery commands is a strong indicator of C2 check-in with enumerated data.
5. Search for lateral movement originating from this host: Query your SIEM for authentication events (Windows Event IDs 4624, 4648, 4768, 4769) where the source IP matches the affected host, looking for logon type 3 (network) or type 10 (remote interactive) to other internal systems in the 30–60 minutes following the discovery activity. Also check for SMB lateral movement indicators (Event ID 5145 — network share access) and any new remote service creation (Event ID 7045) on peer systems.
6. Search for persistence mechanisms added on this host: Query for Sysmon Event ID 13 (Registry value set) targeting common persistence keys: HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Also check for new scheduled task creation (Windows Event ID 4698, Sysmon Event ID 1 with schtasks.exe /create), new services (Event ID 7045), and new user account creation (Event ID 4720). On Linux, check crontab -l history and /etc/cron* modifications via auditd file watch events.
7. Make the escalation decision based on context: Treat the event as a confirmed incident requiring full IR response if any of the following are true: the parent process is a known initial access vector (Office app, browser, web server, phishing lure); the account is privileged or a service account; there are correlated network connections to external IPs; lateral movement or persistence artifacts are present; or the host is a high-value asset (DC, ESXi host, secrets manager). Treat as likely benign if the executing user is a named admin running from a known jump host with a documented change ticket, the command-line exactly matches a known management tool pattern, and there are no correlated suspicious events — document your conclusion and close with a tuning note.

Response Playbook

Containment

• Isolate the affected host from the network immediately, but leave it powered on: Use your EDR’s network containment feature (CrowdStrike “Contain Host,” MDE “Isolate Device,” SentinelOne “Network Quarantine”) to cut off network access while preserving live memory, running processes, and volatile artifacts for forensics. Do not power off or reboot the system — doing so destroys in-memory artifacts like injected shellcode, credential material, and active C2 connections.
• Disable the affected user account without resetting the password yet: Disable (not delete) the account in Active Directory or your cloud IAM (set userAccountControl to disabled in AD, or set the Azure AD account to blocked sign-in) to prevent further authentication. Hold off on password reset until forensics are complete, as the original credentials may be needed to trace adversary session activity in authentication logs.
• Block identified C2 IPs and domains at the perimeter and internal DNS: If network connections were identified in Step 4 of investigation, immediately create firewall deny rules for those destination IPs and add them to your DNS sinkhole or RPZ (Response Policy Zone). Submit the IPs and domains to your threat intelligence platform for enrichment and propagate to EDR block lists.
• Kill the malicious process and any child processes: If the host cannot be isolated immediately (e.g., critical production system), use EDR remote response to terminate the suspicious process tree by PID. Document the PID, process name, and command-line before killing so this context is not lost. On Linux, use kill -9 <PID> via EDR remote shell or SSH from a trusted admin host.
• Revoke active cloud sessions and API tokens if cloud assets are involved: If the alert involves cloud API calls, immediately revoke the active session tokens for the affected IAM user or role (AWS: aws iam delete-access-key and attach a deny-all policy; Azure: revoke refresh tokens via Revoke-AzureADUserAllRefreshToken; GCP: disable the service account key). Do not delete the access key record — preserve it for forensics and logging correlation.

Eradication

• Remove all identified persistence mechanisms: Based on findings from investigation Step 6, delete malicious scheduled tasks (schtasks /delete /tn "<task_name>" /f), remove registry run keys, disable and delete malicious services (sc stop <service> then sc delete <service>), and remove any added cron jobs on Linux/macOS. Document every artifact removed with its full path, registry key, or task definition for the incident record.
• Search for and delete dropped payloads and staging files: Check all staging directories identified during investigation (C:\Users\Public, C:\Temp, C:\Windows\Temp, /tmp, /dev/shm, %APPDATA%) for dropped executables, scripts, or output files. Hash any found files before deletion, submit hashes to VirusTotal, and retain copies in a password-protected evidence archive for your IR record.
• Reset credentials for all accounts that touched the malicious activity: After forensic imaging is complete, force password resets for the affected user account, any service accounts that ran the malicious process, and any accounts whose credentials may have been accessed or dumped during the session (check for LSASS access events: Sysmon Event ID 10, target lsass.exe). Enforce MFA enrollment as part of account re-enablement.
• Inspect all hosts the adversary reached via lateral movement: For every host identified in investigation Step 5 as a lateral movement target, run the same persistence and payload sweep. Treat each as a potentially compromised host requiring its own containment decision — do not assume the attacker only achieved read access.
• Rotate any secrets, API keys, or certificates potentially exposed: If the compromised host had access to secrets (AWS credential files, .ssh private keys, service account tokens, application config files with embedded credentials, Kubernetes service account tokens), rotate all of them immediately regardless of whether direct access was confirmed. Assume any secret accessible to the compromised account is burned.

Recovery

• Verify the host is clean before reconnecting to the network: Run a full EDR scan and, if available, a memory forensics scan (Volatility, Magnet AXIOM) against a forensic image before lifting network isolation. If confidence in cleanliness is less than high — especially for servers, domain controllers, or ESXi hosts — re-image from a known-good baseline rather than attempting manual remediation. The cost of re-imaging is always