T1082 System Information Discovery: Detecting Host and Cloud Fingerprinting Early

Almost every intrusion asks the host what it is before doing anything expensive, and that fingerprinting step is one of the few moments where an attacker on a server, a hypervisor or a cloud instance behaves differently from the workload it has taken over. MITRE ATT&CK T1082 System Information Discovery covers collecting the operating system, version, patch level, architecture and hardware details of a system, on Windows, Linux, macOS, ESXi, network devices and IaaS instances. ATT&CK v20 records hundreds of procedure examples, from espionage groups to ransomware families, and maps no preventive mitigation to it, because the information is available to any process by design. This guide explains how the technique shows up, which telemetry from the ATT&CK v20 detection strategy actually catches it, how to cut the noise, and how to limit what cloud instance metadata gives away. It is written for detection engineers, SOC analysts and cloud platform teams and contains no attack procedures.

Key takeaways

• The command is not the signal. Administrators, agents and installers query system information all day; the signal is who asks, from which parent process, and what follows within minutes.
• Look for bursts. ATT&CK v20 detection strategy DET0525 tunes on a time window and user context: several discovery commands from one session in a short period, especially by a service account, is the pattern worth alerting on.
• Malware fingerprints silently. Many implants read version and hardware data through APIs and send it to their command and control server, so process command lines alone miss part of the technique; EDR API telemetry and network context fill the gap.
• Cloud adds a second surface. Instance metadata services answer anyone on the instance without credentials, and control plane calls such as DescribeInstances reveal the same facts at fleet scale.
• Hypervisors and network devices count. ESXi esxcli queries and network device show version commands are recorded procedure examples and need their own log collection.

What the technique covers

ATT&CK v20 describes T1082 as an adversary trying "to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture", and using it to decide whether to fully infect the target and which actions to take next. It sits in the Discovery tactic (TA0007) and has no sub-techniques. ATT&CK separates it from neighbouring IDs: drive and volume discovery is T1680 Local Storage Discovery, locale and keyboard layout checks are T1614 System Location Discovery, clock and time zone queries are T1124 System Time Discovery, and installed security tools are T1518.001 Security Software Discovery. In practice they run together in the same first minutes.

The broader tactic is covered in the Discovery and Reconnaissance Techniques Guide; this page goes deeper on T1082 only.

How adversaries use it: real cases

The procedure examples below come from the ATT&CK v20 data and the sources it cites. They show three distinct uses: deciding which payload to run, registering the victim with command and control, and choosing targets on infrastructure that defenders rarely monitor.

• Payload selection (Scattered Spider): ATT&CK records the group executing scripts to identify the underlying operating system so it uses the correct installation package, citing Google Cloud research on defending vSphere from UNC3944. See the Scattered Spider Threat Actor Profile.
• Ransomware preparation (Medusa, Storm-0501): CISA advisory AA25-071A, cited by ATT&CK, records Medusa actors running systeminfo through cmd.exe. ATT&CK records Storm-0501 using systeminfo plus open source tools such as OSQuery and ossec-win32 to query endpoints, citing Microsoft's 2024 report on hybrid cloud ransomware. See the Medusa Ransomware Threat Actor Profile.
• Victim registration (BlackByte): in the Microsoft "five-day job" case study, a backdoor DLL collected the installed antivirus products, device name and IP address and sent them to its server, before the operators moved on to network scanning, Active Directory reconnaissance and credential theft; the whole chain took under five days. See the BlackByte Ransomware Profile Guide.
• Network infrastructure (Salt Typhoon): ATT&CK records the group discovering system information through the CLI on network devices, citing CISA advisory AA25-239A. See the Salt Typhoon Threat Actor Profile.
• Unique victim identifiers: ATT&CK records BlackCat collecting the computer name and UUID, and BlackByte ransomware gathering system information to build a victim identifier. Identifiers derived from hardware make every implant check-in distinguishable to the operator.

Fingerprinting also feeds evasion: malware that checks hardware and system values to spot a sandbox is mapped separately to T1497.001 System Checks, but the underlying queries look the same to a defender.

What to detect and where

ATT&CK v20 detection strategy DET0525 "System Discovery via Native and Remote Utilities" defines one analytic per platform. The log sources below are the ones it names; the detection ideas are NHI Mgmt Group recommendations built on them.

Cutting the noise

1. Baseline the legitimate askers: software inventory agents, EDR and vulnerability scanners, configuration management (Ansible facts, SCCM or Intune inventory), monitoring agents and installers. Record them by host group, account, parent process and signer.
2. Score sequences: one hostname is meaningless. System information plus user, network configuration, process and security software discovery from one session within a few minutes is a recognisable first-hands-on-keyboard pattern.
3. Weight by context: raise severity when the process runs as a service account, under a web server or database parent, on a domain controller or hypervisor, or shortly after a new remote access tool appears.
4. Watch the follow-on: fingerprinting followed by tool transfer (T1105), a new service, or architecture-specific payload execution within the same session should escalate automatically.
5. Cover API-only collection: implants that read version data through APIs never spawn systeminfo. EDR telemetry for unsigned processes reading many system properties and then beaconing out is the complement to command line rules.

Cloud instance metadata

Instance metadata services expose system facts to every process on an instance without authentication. On Azure, Microsoft documents that the compute endpoint returns fields such as osType, vmSize, subscriptionId, resourceGroupName and osProfile.computerName, that requests need the Metadata: true header and are rejected if they carry X-Forwarded-For, and that IMDS is unauthenticated and reachable by every process on the VM, so local firewall rules are the way to restrict it. On AWS, the service listens on 169.254.169.254 (and fd00:ec2::254 on Nitro instances in IPv6 subnets). The same endpoint that answers system questions also issues role credentials, which is why metadata hardening matters well beyond T1082: the Capital One breach turned a request forgery flaw into theft of a firewall role's credentials through the metadata endpoint. Credential theft from metadata is a separate technique, T1552.005 Cloud Instance Metadata API.

AWS also rejects token PUT requests that carry X-Forwarded-For, which blunts many request forgery paths through proxies. For the full comparison across providers see the Cloud Instance Metadata Services Compared Guide and the EC2 Instance Metadata Service Hardening Guide. For control plane enumeration across a whole account, see the T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide.

Mitigations and hardening

ATT&CK v20 maps no mitigations to T1082: the operating system has to tell programs what it is. The practical controls below are NHI Mgmt Group recommendations that reduce who can ask, from where, and how much a single compromised identity reveals.

Choosing where to start

A small organisation gets most of the value from three things: require IMDSv2 everywhere, enable process command line logging, and keep one SIEM rule for discovery bursts from service accounts and server parent processes. A large organisation adds per-platform analytics from DET0525, baselines for inventory and configuration tools, CloudTrail rules scoped by role, and purple team tests that measure time to detect the first discovery burst on servers, hypervisors and network devices.

Where identity fits

System information discovery is often the first thing done with a non-human identity after compromise. A web application's service account, a CI runner, a monitoring agent or an instance role is used to ask where it is running, because the attacker arrived through it and does not yet know the environment. Record which non-human identities are expected to run inventory queries or call Describe APIs, alert on any other one that does, and treat discovery by a workload identity as a cue to rotate its credentials before investigating further. See the Service Account Security Guide.

How to test your coverage

1. Pick a safe emulation: in a lab or approved pilot host, run the native system information utilities for each platform from an unusual parent (a script host, a web server worker, a service account session), using an authorised framework such as Atomic Red Team tests mapped to T1082.
2. Confirm telemetry: check that 4688 or Sysmon 1, PowerShell 4104 and auditd execve records arrive with command line, parent and user.
3. Confirm the analytic: verify the burst rule fires on the sequence and does not fire on your inventory agent's normal run.
4. Test cloud paths: from a test instance, confirm IMDSv1 calls are rejected and appear in MetadataNoTokenRejected, and that DescribeInstances from a workload role raises an alert.
5. Test infrastructure: confirm ESXi shell commands and network device show commands from a non-jump address reach the SIEM.
6. Roll back: remove any test exclusions and record the result against the technique in your coverage map.

Metrics

• Telemetry coverage: share of servers, workstations, hypervisors and network devices sending the DET0525 log sources.
• IMDSv2 enforcement: percentage of instances with HttpTokens set to required, and instances with non-zero MetadataNoToken.
• Precision: share of discovery alerts closed as known tooling; a falling rate shows baselines are working.
• Time to detect: in exercises, minutes from the first discovery burst to an analyst seeing it.
• Workload role exposure: number of workload roles holding broad Describe permissions they never use.

Framework mapping

Practitioner checklist

• Enable process creation logging with command line on Windows, PowerShell script block logging, and auditd execve on Linux servers.
• Build a baseline of inventory, configuration and security tools that legitimately query system information.
• Alert on discovery bursts from service accounts, web and database parents, domain controllers and hypervisors.
• Require IMDSv2 on every EC2 instance after checking MetadataNoToken, and alert on MetadataNoTokenRejected.
• Restrict Azure and other metadata endpoints to the processes that need them with local firewall rules.
• Remove unused Describe permissions from workload roles and alert on fleet enumeration by them.
• Keep ESXi SSH disabled by default and forward hypervisor and network device command logs.
• Test the analytics against T1082 emulation each quarter and record the result in your ATT&CK coverage map.

Standards and references

• MITRE ATT&CK: System Information Discovery (T1082)
• MITRE ATT&CK: Discovery (TA0007)
• AWS: Use the Instance Metadata Service to access instance metadata
• AWS: Modify instance metadata options for existing instances
• AWS: CloudWatch metrics for EC2 instances (MetadataNoToken)
• Microsoft Learn: Azure Instance Metadata Service
• Microsoft Security: The five-day job, a BlackByte ransomware intrusion case study
• MITRE D3FEND: Process Spawn Analysis

Related NHI Mgmt Group resources: Discovery and Reconnaissance Techniques Guide · T1580 and T1619 Cloud Infrastructure and Storage Discovery Guide · T1087 and T1069 Account and Permission Group Discovery Defensive Guide · EDR Guide