How T1082 system information discovery reveals an intruder's first map of your hosts
When a host or workload starts behaving oddly, the first question for the SOC lead is whether an adversary is orienting itself on the system. T1082 System information discovery is the technique where an intruder collects details about the operating system, its version, architecture, patch level, hostname and configuration. Those details tell an attacker which tools will run, which vulnerabilities may apply and what to do next. In MITRE ATT&CK, the Discovery tactic (TA0007) is defined as the adversary trying to figure out your environment, and T1082 is one of the most common ways that goal is pursued on a single machine. This mapping targets Enterprise ATT&CK 20.0, so detection content should be checked against that version and against any later release that renames or deprecates the technique.
T1082 usually appears after initial access and before lateral movement or privilege escalation. An intruder who has a foothold on a Linux server, a macOS workstation, an ESXi host or a cloud instance tends to run a handful of short, read-only queries first. The volume is low, the commands are common in administrative work and the output is small, so a single event rarely looks alarming on its own. What makes it visible is sequence and context: the same account querying system details on many hosts in a short window, queries from a service account that normally never runs interactive commands, or host information gathered immediately after an unfamiliar login. Your first decision is therefore which hosts and accounts you consider unusual enough to baseline, and which process creation and command execution records you can actually see on them.
Before writing detection logic, confirm three things in your own environment: which platforms in your estate produce process creation and command execution telemetry, whether your agents capture that telemetry on ESXi, IaaS and other non-Windows hosts, and how long those records are retained. Ask your managed service or platform team to show you a sample of those events from a test host, not just the vendor's documentation. Gaps found at this stage are cheaper to close than gaps found during an incident, and they determine which parts of the detection in the rest of this page will work for you.
Which telemetry reveals T1082 and which open-source collector provides it
This table maps the data components ATT&CK most often references for Discovery techniques to the platforms named for T1082, with the signal to look for and an open-source collector that can gather it. Read each row as a starting point, then confirm per-platform coverage in your own environment before relying on it for alerting.
| Data component | Signal to look for (T1082) | Open-source collector | Platform notes |
|---|---|---|---|
| Process Creation (DC0032) | Execution of built-in system information utilities on Linux and macOS hosts, especially from unexpected parent processes or interactive shells on servers that normally run only services | Auditd-based collection on Linux, Wazuh agent process monitoring | Linux and macOS coverage depends on audit rules and agent configuration. Confirm that macOS endpoints forward process events to your SIEM. |
| Command Execution (DC0064) | Command lines that query OS version, kernel, hardware or hostname in short bursts from a single account or session | Wazuh command monitoring, Velociraptor artifacts for command history, Auditd command records | Shell history is not a reliable source on its own. Confirm whether command arguments are captured on each platform. |
| File Access (DC0055) | Reads of OS release files, kernel version files or hardware inventory paths by processes that do not normally touch them | Auditd file watch rules, Wazuh file integrity monitoring, Velociraptor file collection | Watch rule scope drives noise and cost. Test rules on each platform before widening them. |
| OS API Execution (DC0021) | Calls to system information interfaces from unexpected binaries, visible mainly where native instrumentation is available | Velociraptor endpoint queries, Wazuh system inventory, vendor-native instrumentation where present | Coverage varies widely across Linux, macOS and ESXi. Confirm with each platform owner which API calls are observable. |
| Windows Registry Key Modification | Reads or writes to registry keys that expose OS version, product name or hardware details from non-standard processes | Wazuh Windows registry monitoring, Velociraptor registry artifacts | Relevant only where Windows hosts are in scope for T1082. Linux, macOS and ESXi have no equivalent registry telemetry. |
| ESXi and IaaS management logs | Calls to hypervisor or cloud control plane APIs that return host or instance details from accounts not used for operations | Wazuh log collection from syslog and API audit sources, Zeek for management network traffic | Native audit logs must be enabled and forwarded. Confirm retention and which control plane events your provider exposes. |
| Network Traffic Content (DC0085) | Management protocol sessions that carry host information requests from unexpected sources | Zeek protocol logs, Suricata rules for management traffic | Visibility depends on sensor placement. Encrypted sessions limit content inspection, so confirm what metadata is retained. |
| Central validation and baselining | Expected administrative inventory activity compared with observed activity over time, so deviations stand out | Wazuh rule tuning, Security Onion dashboards, Sigma rules converted to your SIEM format | Baselines need owner sign-off per platform. Confirm the ATT&CK version your detection mappings target before publishing rules. |
Detection logic for T1082 that SOC teams can tune
These cards describe detection logic for T1082 System information discovery as it appears on Linux and macOS hosts, ESXi and IaaS management planes, and Windows registry activity. Each one names a signal, the thresholds to tune and the benign tooling that will trigger it, so analysts can separate routine inventory from reconnaissance. The detection logic targets MITRE ATT&CK Enterprise version 20.0, so mappings should be rechecked when the framework changes.
Process context on Linux and macOS
Alert on system information queries run from unexpected parent processes, such as a web server worker, a database service or a user shell spawned by a script that has no business inspecting hardware or kernel details. Build a baseline of which parents legitimately run these queries on each host group. Tune by host role, not globally. Expect false positives from inventory agents, configuration management runs, monitoring checks and patch tooling, so allowlist them by signed binary path and parent, and review the allowlist on each change window. Track the parent process, not just the queried command, because that is where the anomaly usually appears.
ESXi and IaaS management-plane signals
Correlate host and hypervisor queries with management-plane activity such as API calls from identities that do not normally read host configuration. On ESXi, review shell access and host-level queries outside approved maintenance windows. In IaaS consoles, flag metadata or instance-description reads from service accounts that have no inventory role. Set thresholds per identity, for example a count of distinct hosts queried within a short window. Expect false positives from CMDB synchronization, backup agents, cloud posture scanners and vulnerability management, so document each service identity and its expected query pattern before tuning.
Registry-related signals on Windows
Where T1082 overlaps with Windows, watch for bulk reads of system identity and build keys followed by queries from a process that is not an installed management or inventory component. Registry read telemetry is noisy, so focus on the executing process and its signature rather than on individual key names. Tune by excluding known endpoint management and software deployment agents. Expect false positives from software inventory scans, endpoint detection products and support tooling, and confirm each one against the vendor's documented behavior in your environment before adding an exclusion.
Correlating low-value discovery events
Individually, a single system information query is rarely suspicious. Correlate several low-value discovery events, such as T1082 queries combined with process listing, account listing or network configuration reads, from one source within a defined time window. Choose the window and the minimum event count from your own baseline, and start conservatively to limit noise. Expect false positives from administrators running health checks and from scheduled scripts that gather many facts at once, so suppress known automation by host and schedule. Score the correlated alert higher when the source host also shows a new parent or an unusual logon.
Validating thresholds before production
Before enabling any rule, replay it against a period of known administrative and automation activity to measure how many alerts it would have raised. Adjust thresholds until the alert volume is one your analysts can review, and record the allowlist decisions with their owners. Confirm that each Sigma or Wazuh rule names the ATT&CK version it targets, and recheck mappings when a new version is released. Rehearse the same rules in a private cyber range with scripted benign inventory tasks, so the team learns where legitimate activity falls before a real incident tests the logic.
How to validate that the T1082 detection fires
This sequence turns a T1082 System Information Discovery detection from a rule on paper into evidence that it fires, with known telemetry, expected fields and a recorded time to alert. It runs in a private cyber range under an approved test plan, and it ends with a detection record tied to the ATT&CK version under test.
Agree scope and rules of engagement
The security lead, the platform owner and the range operator agree in writing which hosts, platforms and accounts are in scope, which behaviors are allowed, who can stop the exercise, and how the range is isolated from production. Confirm the platforms in scope, such as ESXi, IaaS, Linux and macOS, and whether any cloud or identity logs are included. The step is done when all parties sign the test plan and the stop conditions are written down.
Map planned behavior to the technique
The detection engineer lists each planned behavior as a discrete item and maps it to T1082 System Information Discovery, and to any sub-technique the current ATT&CK version lists. Record the ATT&CK version number, the detection strategy and analytic IDs, and the data components each analytic expects, such as Process Creation (DC0032) and Command Execution (DC0064). The output is a traceability table that another engineer can read without asking questions.
Confirm telemetry reaches the platform
Before any behavior runs, the platform engineer checks that the log sources named in the traceability table are arriving in Wazuh, Security Onion or the chosen SIEM. Check agent status, time synchronization, parser health and event volume on the test hosts. The step is complete when a benign marker event from each source is visible in search with the expected fields populated, and the gaps are logged before the exercise starts.
Run the approved behavior in the range
The red team or range operator executes only the behaviors in the approved plan, in the agreed window, with an observer recording start and end times. The observer records the host, account and platform for each action so the activity can be matched later. The step ends when every planned item is marked as run, skipped or stopped, with no unplanned activity left unexplained.
Check the alert fires with expected fields
The detection engineer searches for alerts generated by the exercise window and compares each one with the expected rule name, ATT&CK technique tag, host, user and process fields. Confirm that the alert contains the fields the responder needs to triage it, and note any field that is empty or wrong. The output is a pass or fail per analytic, with screenshots or saved queries stored with the test record.
Measure time to alert and false positives
Calculate the elapsed time between the observer's recorded action and the first matching alert, and review all other alerts raised during the window to classify them as expected, benign or unexplained. Time to alert is only meaningful when the clocks are synchronized, so record the time source used. The step is complete when the time figures and the false positive review are attached to the test record.
Record gaps in a detection record
Write a detection record that names the ATT&CK version, the technique and sub-techniques tested, the data components, the rule version, the range configuration, the results per analytic, time to alert, false positives and every gap, with an owner and a next review date for each gap. Store the record in version control so later ATT&CK releases can be compared against it. The record is the output of the sequence and the input for the next tuning cycle.
Preventive controls that reduce what T1082 reveals
System information discovery succeeds when an intruder can read host details freely and nothing records the reads. The mitigations below narrow what a foothold can learn and make the remaining reads visible, so each one supports the detections on this page. Confirm how each applies to your platforms with the owners of those systems before you rely on it.
Operating system configuration
ATT&CK mitigation M1028 covers hardening settings that limit what local users and services can read about the host, such as restricting access to system files, kernel and hardware details, and verbose status interfaces. Less exposed host detail means fewer commands return useful answers, so the technique produces fewer successful results. Check which hosts keep default, permissive settings for reading version, hardware and boot information, and confirm the baseline with the team that owns each image. Hardening changes can break monitoring agents, so test them in staging first.
Audit logging coverage
ATT&CK mitigation M1047 is about making sure the platform records the activity that discovery generates. Audit coverage is the control that turns a quiet reconnaissance step into evidence. Check that process execution, command history and privileged API calls are logged on Linux, macOS, ESXi and cloud control planes, and that logs leave the host for central analysis. Verify retention and clock synchronization, because gaps in either weaken every later investigation.
Network segmentation
ATT&CK mitigation M1030 limits what a compromised host can see on the network. Discovery of hosts, services and VM inventories depends on reachability, so restricting management networks, hypervisor interfaces and cloud metadata paths reduces the answers an intruder gets. Review which workload zones can reach ESXi management, cloud instance metadata endpoints and administrative consoles. Confirm each rule with the network owner, since some monitoring and backup flows depend on the same paths.
Disable or remove unneeded features
ATT&CK mitigation M1042 reduces the number of utilities and services an intruder can query. Removing unused packages, debugging tools and legacy management interfaces shrinks the set of commands that return host, hypervisor or software details. Inventory installed tools on production images and compare them with the approved baseline. Confirm removals with application owners, because some diagnostic utilities are needed during incidents and may need to move to controlled admin jump hosts.
User account management
ATT&CK mitigation M1018 controls which accounts can run system-level queries in the first place. Limiting privileged accounts, separating admin roles and removing shared or dormant accounts means a low-privilege foothold reads far less. Review who holds sudo, root, vSphere administrator and cloud read roles, and check whether service accounts have broader access than their job needs. Confirm role changes with identity owners before enforcing them across environments.
What the SOC does in the first hour after a T1082 alert
The first decision in a T1082 System Information Discovery alert is whether the activity is authorized. System information queries are routine for inventory, patching, configuration management and asset tagging, so the analyst should first check the change calendar, the configuration management system and the owning team's job schedule for a matching task. Next, identify the account and parent process that ran the command, the host role (for example, a hypervisor, a build server, a database host or a developer workstation), and the exact time window. A query run by a known management agent from a documented service account on a server in its expected role is a very different event from an interactive shell on a host that should never be administered by hand. Record these fields in the case before doing anything else, because they decide whether the alert closes as benign or moves to escalation.
If the activity cannot be explained, look at what happened around it. T1082 is usually one step in a longer sequence, so search the same host and account for adjacent discovery activity (such as account, network, process or software queries), new logons, file transfers, service or scheduled task changes, and privilege changes over the preceding hours. Pivot to the detection source you already run, such as Wazuh alerts, Security Onion or Zeek records, and Velociraptor or EDR telemetry, and confirm the data is complete for that window. Escalate to incident response when the account or host is unknown, when adjacent activity points to access beyond the host's normal role, or when the same pattern appears on several hosts. Notify the asset owner at the same time for any host that carries production or regulated data, since they hold the context the SOC lacks.
Containment should slow the activity without destroying evidence. Prefer narrow actions such as restricting the account's access, blocking a single source address at the network boundary, or isolating the host from the network through an approved control, and avoid rebooting or reimaging before volatile data is captured. Preserve logs for the host, the account and the network segment in their original form, export or snapshot them under a documented chain of custody, and collect volatile data (running processes, network connections and logged-on sessions) before any change to the system. Confirm with the incident response lead and the asset owner which containment steps are approved for that host class, and record the time and reason for each step. Your runbook should state these approvals in advance so the first hour is spent on evidence, not on negotiation.
Rehearsing T1082 detection and response in a private cyber range
This track runs on a small set of isolated Linux and macOS hosts instrumented with the same agents and log pipelines used in production, such as Wazuh agents or Velociraptor clients forwarding process creation and command execution records to a central analytics platform. The facilitator schedules approved emulation steps that ask a standard user account to gather operating system and kernel identity information, the way a curious or compromised user might during early discovery. Analysts are not told which step is running.
- Approved injects: Schedule a set of host identity queries at staggered times, described in the exercise plan as plain-language objectives, so analysts can practice correlating a burst of benign-looking reads with the account and parent process that produced them.
- Good detection: Alerts fire from process creation records that show the originating user, parent process and working directory, and analysts can tie them to the same session within the agreed review window.
- Good response: The on-call analyst opens a case, confirms whether the account is expected to run inventory tasks, and notifies the host owner through the documented channel before containment is considered.
- Handoffs: Record the time from first alert to analyst acknowledgment and from acknowledgment to owner notification, then compare those times against the targets the client has set.
After the session, check whether macOS unified logging and Linux audit records were actually forwarded, because gaps in those sources are a common reason a rehearsal looks clean on paper but fails in practice.
This track uses a private virtualization cluster with an ESXi host, a management plane and a sandboxed cloud account or IaaS tenant. The goal is to test whether host identity and platform version queries made through management interfaces, automation tooling or administrative sessions are visible to the monitoring stack and attributable to a named identity. Access to the lab is limited to the exercise team, and every emulation step is logged with its start and stop time so detections can be matched afterward.
- Approved injects: Schedule platform identity reads from a service account and from a human administrator account, so analysts can compare patterns for automation against interactive use.
- Good detection: Management plane audit records, cloud control plane activity logs and host command records are correlated to the same identity, with an expected baseline for the service account.
- Good response: Analysts check whether the activity matches a scheduled change or a known automation job, then escalate to the platform owner with the session identifier and the affected management endpoint.
- Handoffs: Agree in advance who may suspend a service account in the lab and who must approve the action in production, and rehearse that approval path explicitly.
- Coverage check: Confirm with the cloud provider and virtualization vendor which audit events are emitted for each action, since event availability varies by product and configuration.
Before running this track, confirm which audit logging is enabled on the management plane and what retention period applies, because the exercise can only test what is recorded.
This track is for the team that writes and tunes rules. Rather than running the emulation steps to see whether alerts fire, the engineers replay recorded telemetry from the other two tracks against candidate Sigma rules and detection logic, then measure how often each rule fires on the captured benign activity. The exercise is organized around the ATT&CK version the team has pinned, so every rule and mapping names the version it targets, and the team records any detection strategy or data component changes that affect the rule.
- Replay sets: Keep labeled datasets of host, virtualization and cloud activity, with the operator role and intent recorded for each event, so tuning decisions can be traced.
- Rule quality: Test each rule for precision against routine inventory, patching and monitoring tasks, and record the false positive sources that need allowlisting with an owner and a review date.
- Coverage mapping: Map each rule to the data components it relies on, such as Process Creation and Command Execution, and identify where a missing source would silently disable the rule.
- Validation: Confirm that a rule change does not break alert routing in the SIEM or in the case management workflow before it reaches production.
- Response feedback: Share the outcomes with the analysts who ran the first two tracks, so response playbooks are updated with the same evidence used to tune detections.
For each rule, confirm the version of ATT&CK it targets and the date it was last reviewed, because mappings can change between releases.
Questions SOC leads and detection engineers ask about T1082
How do I separate T1082 activity from legitimate inventory agents?
Separate them by parent process, service account, schedule and destination, not by the command alone. Inventory agents run from known paths, under known service identities, on predictable intervals, and they report to a fixed management endpoint. Attacker-driven discovery usually arrives through an interactive or unexpected parent, from a user or service account that does not normally touch hosts, and in short bursts across many hosts. Build an allowlist from your own agent inventory and confirm each agent's process lineage in your environment before you suppress anything. Review suppressions regularly, because agents change during patching and upgrades.
Do I need Windows registry telemetry to detect T1082?
Registry telemetry is useful for some Windows variants of this technique, but it is not the core signal for most of the platforms this page covers. Process Creation and Command Execution telemetry carry most of the detection value on Linux, macOS, ESXi and IaaS hosts. On Windows, confirm in your own environment whether you collect Windows Registry Key Modification events, what the volume costs in storage, and whether the events you need are logged at all. Check the current data component and detection strategy entries in the ATT&CK STIX bundle for the version you target before you decide what to enable.
How should we handle ESXi coverage gaps for this technique?
Start by listing which ESXi hosts forward logs, which log sources reach your SIEM, and whether shell or command activity on the hypervisor is recorded at all. Many hypervisor deployments do not forward shell history by default, so treat that as a gap until you verify it. Where coverage is missing, document the gap as a risk, restrict and audit administrative access to the management plane, and forward the logs that do exist. Confirm the logging options available for your ESXi version with your vendor, since configuration keys and log destinations differ by release.
How do I version detections against ATT&CK releases?
Record the ATT&CK version each detection targets, for example v18, v19 or v20, in the rule metadata. ATT&CK releases can rename, deprecate or revoke techniques and change data components, so a rule written for one version can drift from the current mapping. Pin your detection mapping to a STIX bundle version, review it when MITRE publishes a new release, and keep a changelog of mapping updates. Confirm the release you use against the ATT&CK updates page before each review cycle, and test that rules still fire after any mapping change.
How do I tune thresholds for discovery bursts without missing activity?
Tune thresholds against a baseline built from your own hosts, not against a published number. Measure how many distinct discovery commands a given account or host runs within a time window during normal administration, then set alerts above that baseline and tier them by asset criticality. Use grouping by source account and parent process so a burst from one session produces one case. Run each threshold against replayed telemetry from your cyber range before production, and record the false positive and false negative results so the tuning decision can be reviewed later.
What evidence might auditors ask for about T1082 detection?
Auditors usually ask to see that the detection exists, that it is tested, and that alerts lead to a documented response. Prepare the rule definitions with their ATT&CK version, the log sources they depend on, evidence of log collection from representative hosts, records of test runs in your cyber range, and sample alert tickets showing triage and closure. Also keep the change history for suppressions and thresholds. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors decide whether the controls meet the applicable framework, so confirm the specific evidence set with your assessor.
Can our own team run this detection without outside help?
Yes, many SOC teams can implement and maintain this detection in-house if they already run a SIEM, have endpoint log collection and have staff who can write and test rules. The work includes mapping telemetry to rules, building allowlists, testing in a lab, and keeping mappings current with each ATT&CK release. Outside help is most useful for the parts your team has not done before, such as building a private cyber range, validating coverage across ESXi or IaaS, or documenting controls for an assessment. Confirm your internal skills and staffing against the written scope before deciding.
How a T1082 detection moves from rule to tuned production alert
A T1082 System information discovery detection should start as a portable rule, not as a query tied to one SIEM. Write the logic in a format such as *Sigma*, so the same rule can be converted for Wazuh, Security Onion or another backend your team runs. Keep the rule focused on the process creation and command execution events that reveal host enumeration on the platforms in scope, such as ESXi, IaaS instances, Linux and macOS hosts. Record the rule's data source requirements explicitly, including which command execution fields and process lineage attributes it depends on, so that a collector change on one platform does not silently blind the rule. Each rule should also carry its ATT&CK mapping with the version it targets, for example the Enterprise ATT&CK 20.0 release, since the mapping is only meaningful against a named version.
Before production, replay recorded or synthetic telemetry from your cyber range through the rule and measure what fires. Replay should include benign administrative activity that legitimately collects system details, such as patching tools, configuration management agents and monitoring probes, because those are the sources of the false positives you will tune against. Deploy the rule through a versioned change record that names the rule version, the author, the test evidence, the expected alert volume and the owner who will review it. Once live, review false positives on a fixed schedule, adding allow-list conditions only for named, verified processes and parent chains rather than broad exclusions. Finally, when a new ATT&CK release renames, deprecates or revokes content, check the T1082 mapping and detection strategy against the MITRE ATT&CK updates page and update the rule's version field. Confirm the current ATT&CK version and mapping status with your own content owner before each review cycle.
How DeployOpen builds T1082 detections, purple team exercises and range scenarios
DeployOpen works on T1082 System information discovery as a fixed-scope engagement inside your own infrastructure, covering the telemetry, detection logic and range exercises your team will run. Each step is agreed in writing before work starts, so you know which platforms, data sources and deliverables are included.
How we scope
- Confirm which platforms are in scope for T1082, such as ESXi, IaaS, Linux and macOS hosts, and which are excluded.
- Inventory the Process Creation, Command Execution and Windows Registry Key Modification telemetry your sensors already collect.
- Record the ATT&CK version the detections will target, and agree how mappings are updated when MITRE revises the technique.
How we build
- Write detection logic for T1082 in words and rule formats such as Sigma, then translate it into your SIEM, such as Wazuh.
- Map collection gaps for Process Creation and Command Execution data on each platform and document the fixes needed in the agreed scope.
- Set up dashboards and alert routing in open-source tooling so analysts can review System information discovery activity.
How we hand over
- Deliver a written detection record for T1082 covering data sources, logic, known false positives and tuning notes.
- Provide a range scenario runbook so your team can rehearse detection and response in a private cyber range.
- Run a knowledge transfer session with your analysts and document the validation results for your compliance evidence file.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Review detection mappings when a new ATT&CK release renames, deprecates or revokes techniques that T1082 depends on.
- Confirm with your team which changes to platforms, logging or cloud accounts trigger a retest of the T1082 detections.
