What T1120 peripheral device discovery tells an attacker and where it appears
T1120 Peripheral device discovery is the point where an adversary tries to learn what hardware is attached to a system, which is one of the ways they work out what they have landed on. MITRE defines the Discovery tactic (TA0007) as the adversary trying to figure out your environment, and peripheral enumeration is a small, quiet part of that effort. For a SOC lead, the event often looks routine: a process queries device lists on an endpoint that has no obvious reason to care about them, and the alert competes with ordinary administrative activity. This page treats the event as a signal worth triaging, not as background noise. All mappings in this section and the rest of the page target Enterprise ATT&CK version 20.0.
At a high level, knowing which peripherals are attached tells an attacker what kind of machine they are on and what it is used for. Attached storage can point to removable media that may be used to move data out of a network. Input devices and keyboards can indicate a workstation used by a person with privileged access, which changes the value of the host. Capture hardware such as cameras or microphones, or specialized equipment in clinical, industrial or lab settings, can indicate a target for collection. The same information also helps an operator decide whether an endpoint is a worthwhile pivot or simply a lab machine. In intrusions, this step usually comes after initial access and alongside other host and network discovery, so a peripheral query is most informative when it sits next to process, account or network enumeration on the same host.
Before tuning any rule, confirm with your endpoint and platform vendors which telemetry is available on each operating system in your estate, and which ATT&CK version your detection content names. Ask whether your tooling maps T1120 to a current detection strategy and analytic in the version you target, since releases can rename or revise techniques. Then decide who triages a peripheral enumeration alert, which hosts are expected to query devices (for example, help desk or imaging workstations), and what evidence is needed to close the alert. Those decisions shape the detection more than any single query pattern.
Which telemetry reveals peripheral device discovery and which open-source tool collects it
This table maps Process Creation (DC0032), File Access (DC0055) and Process Access (DC0035) to the signal each gives for T1120 on Linux, macOS and Windows, and names an open-source collector for each. Read each row as a starting point for coverage, then confirm in your own environment which events your agents actually record before relying on a rule.
| Telemetry source | Linux | macOS | Windows |
|---|---|---|---|
| Process Creation (DC0032) | Process starts of enumeration utilities that read device information, logged by auditd or the Wazuh agent. Coverage depends on audit rules being loaded. | Process starts captured through the Wazuh agent or Endpoint Security based logging, depending on the deployment. Confirm which events reach the manager. | Process starts logged by Sysmon-style logging forwarded through the Wazuh agent. Confirm the Sysmon configuration includes process creation with command lines. |
| File Access (DC0055) | Reads of device node or sysfs paths watched by auditd rules, collected through the Wazuh agent. Noisy on hosts with frequent hardware activity. | File reads of device-related paths observed through file integrity or audit-style monitoring, where the platform supports it. Confirm path coverage. | File access auditing on device-related registry or file locations, if object access auditing is enabled and forwarded. Often disabled by default, so confirm before relying on it. |
| Process Access (DC0035) | Limited native visibility. Relevant only where an EDR or a Velociraptor artifact inspects process memory or handles. Confirm vendor support. | Limited native visibility. Relevant only where a commercial or open-source agent exposes process interaction events. Confirm the collector. | Process access events from Sysmon-style logging, useful for spotting tools that open other processes while enumerating devices. Requires a tuned configuration to stay manageable. |
| Command Execution (DC0064), related source | Shell history and command logs collected by auditd or the Wazuh agent. Treat as a supporting source, not a standalone signal. | Unified logging or shell history collected by the Wazuh agent, where configured. Coverage varies by setup. | Command line capture from process creation events, collected through Sysmon-style logging. Supports triage of Process Creation hits. |
| Velociraptor collection | Hunts can query device listings and recent process activity on demand for validation and incident scoping. Confirm artifact availability for your version. | On-demand collection of device and process state for investigation. Confirm the artifacts shipped with your release. | On-demand collection of device enumeration output and process state for investigation. Confirm the artifacts shipped with your release. |
Detection ideas for T1120 and how to tune them
T1120 Peripheral device discovery is hard to separate from legitimate hardware management because the same system calls and device queries appear in printer, backup and inventory tooling. The cards below pair each detection idea with the telemetry that supports it, the thresholds to tune and the benign software that will fire first, so the rules are tuned in your environment rather than copied from a default.
Process lineage and parent-child logic
Start by mapping which parent processes normally launch device enumeration tools on each platform. Flag enumeration activity whose parent is a web service, a script interpreter, a document application or an unexpected user session, rather than an administrative shell or a known management agent. Use Process Creation (DC0032) telemetry on Linux, macOS and Windows, and keep a per-host allowlist of parent-child pairs observed during a baseline period. False positives come from hardware management suites, endpoint agents that probe USB devices and printer driver installers, so confirm each allowlist entry with the owning team before tuning.
Bursts of device-node reads
Peripheral enumeration on Linux often reads device nodes and sysfs entries in a short, dense sequence. Alert on a host where reads against hardware interfaces, such as device directories or USB and block device attributes, exceed a baseline rate within a short window, and where the reading process has no recent history of hardware access. Use File Access (DC0055) telemetry and tune the window and count per host class, since workstations with many USB peripherals will produce higher normal counts than servers. Expect backup agents, disk health monitors and print spoolers to generate bursts; record their signatures in the baseline.
Process access to hardware query handles
Some discovery activity opens handles to other processes or to device management services to read their hardware state. Correlate Process Access (DC0035) events where a non-management process requests read rights against drivers, print services or device management components, and where the same source process then performs no legitimate device action. Tune by requested access rights rather than by process name alone, because names are easy to change. Hardware vendor utilities, endpoint protection and monitoring agents commonly open these handles, so exclude them only by verified signer and path.
Time-window correlation with user context
Enumeration that follows an unusual logon, a remote session or a privilege change within a short window is more significant than the same activity during a scheduled maintenance period. Correlate Process Creation with Command Execution (DC0064) and session data, grouping events per user and per host over a window you set from your own incident history. Check whether the account belongs to an IT, helpdesk or facilities group before raising severity. Scheduled inventory scans, patch windows and new-device onboarding will create legitimate clusters, so pair each alert with the change calendar.
Baseline and false positive sources
Build the baseline before writing alerts. Inventory the printer and drive utilities, backup agents, hardware management suites and IT inventory tools that run on each host class, record when they run and which devices they touch, and store that as a tuning register. Review the register after each software change or driver update, since new versions often change the enumeration pattern. Ask each team to name its scheduled jobs so that expected activity can be suppressed with a documented reason rather than a broad exclusion.
How to validate that the T1120 detection fires
This sequence proves, in a private cyber range or lab, that the T1120 Peripheral device discovery detection produces the expected alert on each platform in scope. It also leaves a written record of what was seen, what was missed and which tuning decisions followed.
Agree the emulation plan with the change board
The detection owner, the SIEM administrator and the change board agree in writing which platforms, accounts and hosts will be used, what the benign emulation will do and when it will run. The plan names the ATT&CK version the detection targets, so the rule and the technique reference stay aligned. Each platform's rule is tied to the data components it depends on, and the work is done when the board signs off the plan and its rollback steps.
Define expected telemetry for each platform
Before anything runs, the team writes down which events should appear on Linux, macOS and Windows for a peripheral enumeration activity, drawing on the Process Creation, File Access and Process Access data components named in the ATT&CK technique. For each platform, the expected event sources, field names and the log path into the SIEM are recorded. The step is complete when every expected event has a named source, so a missing event later can be traced to a collection gap rather than guessed at.
Run an approved benign emulation
A tester who is authorized under the plan runs a benign, pre-approved emulation in the range that reproduces the observable behavior of peripheral enumeration on each in-scope host. The run is limited to the agreed accounts and hosts, is timed and logged by the operator, and stops if production-like traffic appears. The step closes when the operator's activity log matches the plan, so the team knows exactly which actions the detection should have caught.
Confirm the alert reaches the SIEM
The SIEM administrator checks that the raw events arrived, were parsed into the expected fields and matched the detection logic, then confirms the alert was created and routed to the correct queue. Each platform is checked separately, because an agent or parser failure can affect one operating system and not others. The step is complete when each expected event has a traced path from host to alert, or a documented reason it does not.
Record detection gaps and tuning decisions
The team compares expected telemetry with what was observed and records every gap, false positive and timing issue in a single validation record tied to the rule version and ATT&CK version. Each tuning change is proposed, reviewed and approved through the change process before it is applied, with the reason stated. The step closes when the record shows the outcome for each platform, the open gaps and the owner and date for each follow-up.
Retest after tuning and retain the evidence
After approved tuning, the benign emulation is repeated on the same hosts under the same plan, so the before and after results can be compared directly. The evidence package holds the plan, the expected telemetry, the operator log, the SIEM query results and the change records, and it is stored where the compliance and audit teams can retrieve it. The step is done when the retest shows the expected alerts or a documented, accepted residual gap.
Preventive controls that reduce peripheral discovery value
Peripheral device discovery only pays off for an adversary when the device inventory is visible, unlogged or unrestricted. The four ATT&CK mitigations below act on those three conditions: what is installed, what the operating system exposes, what gets recorded, and who can query it. Confirm the mapping of each mitigation to T1120 against the ATT&CK version your detection content targets, because mappings can change between releases.
Remove unneeded device features
Mitigation M1042, Disable or Remove Feature or Program, reduces the number of peripheral interfaces and driver stacks a host exposes. Start with inventory: list which USB, Bluetooth, camera, audio and removable storage functions are needed for each host role, then disable or uninstall the rest through configuration management. Fewer enabled features means fewer device enumeration results for an adversary to collect and fewer baseline events to tune around. Ask the vendor or your platform team to confirm which features can be disabled per operating system version.
Harden operating system configuration
Mitigation M1028, Operating System Configuration, covers the settings that decide whether device listings can be read by unprivileged accounts and whether removable device classes are permitted at all. Define a hardened baseline for workstations and servers, set restrictions on device installation and removable media, and enforce it with your configuration management tooling. Record the baseline version so drift can be measured. Confirm the exact settings that apply to each platform with its vendor documentation, since the mechanisms differ across Linux, macOS and Windows.
Audit device and privilege use
Mitigation M1047, Audit, ensures that device enumeration commands and device-related file access are recorded rather than invisible. Enable process execution auditing and file access auditing on the paths that expose device state, such as device directories and kernel interfaces on Linux, the device and driver registry hives and setup logs on Windows, and the corresponding system logs on macOS. Forward these events to your SIEM, such as Wazuh, and confirm that collection survives a host reboot. Auditing without retention and review gives you the event but not the detection.
Restrict who can enumerate devices
Mitigation M1018, User Account Management, limits which accounts can run device-inspection tools and read device state. Review standard user rights on endpoints, remove local administrator rights from users who do not need them, and separate service accounts from interactive accounts. When an account that normally never inspects hardware starts doing so, the mismatch becomes a clear signal in Process Creation telemetry. Ask your identity team to confirm which accounts currently hold elevated rights on your endpoint fleet before tuning alerts.
Triage steps when a peripheral discovery alert fires
The first decision on a T1120 Peripheral device discovery alert is whether the activity is expected. Confirm the process name, the full command lineage, the user context and the host that raised the alert from Process Creation telemetry, and note whether the process ran interactively or from a scheduled job. Then check the host against your approved asset inventory and change calendar. Asset management tooling, endorsed maintenance scripts from endpoint or device management platforms, and vendor diagnostic utilities often enumerate devices legitimately, so a match to a named service account, a ticketed maintenance window or a known management server closes many alerts quickly. Record the result in the ticket before moving on, because an unexplained match is the point where triage changes direction.
If the activity does not match an approved job, widen the view to the same host and the same user over a defined window. Discovery rarely appears alone, so look for neighboring signals such as T1082 System information discovery or T1057 Process discovery, which are covered on their own pages, and for unusual File Access against device or driver-related paths on Linux and macOS, or unexpected Process Access on Windows. Also check whether the user or session had recent authentication anomalies. Confirm what your telemetry actually covers on the host, since gaps in collection are a common reason correlation comes up empty. Decide on containment based on the user's role, the sensitivity of the host and whether the sequence looks like inventory or reconnaissance. Options include isolating the endpoint through your EDR platform, disabling the session, or restricting the account, with each action approved by the on-call incident owner.
Preserve evidence before you change the host. Capture the relevant process, logs and file state the way your incident response procedure requires, and record hashes and timestamps so the chain of custody holds if the case is escalated. Escalate to the incident response lead when the activity is unexplained, when it overlaps with other discovery or credential signals, or when it touches a regulated system, and notify the asset owner so they can confirm what should and should not be connected. After closure, feed the outcome back into the approved inventory list and the detection tuning, and confirm with your security operations team which retention period applies to these logs under your own policy.
How to rehearse T1120 detection in a private cyber range
The range should mirror the endpoint mix your organization actually runs, with Linux, macOS and Windows hosts enrolled in the same open-source SIEM and collector stack used in production. Each platform produces different telemetry for peripheral device discovery, so the range must collect process creation, file access and process access events from every operating system you intend to cover. Keep the range isolated, label every host with its role and owner, and record the configuration baseline so results can be compared between runs.
- Endpoint coverage: Include a representative workstation, server and developer or engineering build for each operating system, since their logging policies often differ.
- Collector configuration: Confirm which audit and event sources are enabled on each host and document any gaps before the exercise starts.
- Clock and time sync: Verify that all hosts and the SIEM share a synchronized time source so event sequences can be reconstructed.
- Data retention: Set the range retention period to match the production policy so analysts see realistic volumes of data.
- Rule version pinning: Record the exact detection rule set and the ATT&CK version it targets before each run.
Before the first run, ask your implementation partner to confirm which collector features are available on each platform in your environment.
Injects are the scripted activities the range team triggers to test the detection. Three categories give the most useful signal: benign discovery activity that reflects expected administration, noisy administrative activity that resembles discovery but comes from known tooling, and a hidden variant that tries to blend into normal operations. Each inject should have a written expected outcome so the range team can judge whether the detection fired, stayed quiet or fired for the wrong reason. The range team runs the scripts, and analysts are not told which category is in play.
- Benign discovery: Scripted hardware inventory by IT support staff, which should be documented and checked for false positives.
- Noisy administration: Routine device management by known administrative accounts, testing whether the rules separate expected tooling from unexpected use.
- Hidden variant: An activity pattern designed to be less obvious, such as spreading enumeration across time or accounts, to test coverage gaps.
- Expected outcomes: A written result for every inject, covering alert, no alert or alert with an incorrect severity.
- Blind execution: Analysts receive the alert queue without knowing the inject schedule, which keeps the exercise close to a real investigation.
Ask the range provider to confirm in writing which scripts they will run and who approves each inject.
A rehearsal is only useful if it produces a clear measure of detection and response quality. Judge each run on whether the alert arrived in time for the analyst to act, whether the analyst notes explain the reasoning, and whether the team documented any tuning changes with their justification. Compare alert timing against the expected event sequence rather than against an assumed target, and record where delays come from, such as collector lag, rule scheduling or triage queues. Tuning should follow evidence from the run and should be reviewed so that a fix for one noisy inject does not blind the rule to the hidden variant.
- Alert timing: Measure the gap between the triggering event and the alert in the SIEM, and separately the time to analyst acknowledgement.
- Analyst notes: Require each analyst to record the hypothesis, the evidence checked and the decision taken.
- Documented tuning: Every change to a rule should name the inject that prompted it, the expected effect and the rollback plan.
- Regression checks: Rerun the benign and hidden injects after tuning to confirm that the change did not create new gaps.
- Debrief record: Keep a written summary that maps results to the ATT&CK technique and the rule version under test.
Check that your SIEM and response procedures can export these records, since auditors and your own review board will ask for them.
Questions SOC leads and detection engineers ask about T1120
How do I separate legitimate inventory tools from adversary peripheral device discovery?
Start by building an allowlist of the processes, service accounts and hosts that legitimately enumerate devices, such as endpoint management agents, asset inventory scripts and help desk tooling. Then alert on device enumeration from processes outside that baseline, or from user sessions that do not match the host's normal role. Process Creation telemetry gives you the parent-child context needed to make that call. Review the allowlist with the team that owns each inventory tool, because it changes whenever those tools are updated or replaced. Treat any allowlist exception as something that needs a named owner and an expiry date.
Which telemetry is most reliable for T1120 on Linux, macOS and Windows?
Reliability depends on what each host records by default, so verify it rather than assume it. On Windows, Process Creation logging with command line capture is usually the first source to enable, and it pairs well with OS API Execution where your EDR exposes it. On Linux, process execution auditing and File Access rules on device nodes and sysfs paths are the usual sources, while macOS needs its own unified logging and endpoint security configuration checked on your fleet. Confirm each source with your EDR or audit vendor before writing the rule, and document any gap as a known limitation.
How should I version the detection rule against ATT&CK 20.0?
Record the ATT&CK version in the rule metadata, for example the version it was mapped to, so that anyone reading the rule knows which technique definition it targets. ATT&CK releases can rename, deprecate or revoke techniques, and the detection strategy and data component references can change with them. Check the MITRE ATT&CK updates pages against your mapping each time a new version is released, and keep the mapping in version control next to the rule. When you move to a newer version, diff the Enterprise STIX bundle for T1120 and its data components before you change the rule logic.
How often should we rerun validation for the T1120 detection?
Rerun validation after every change that could affect the telemetry path, including EDR agent upgrades, audit policy changes, SIEM parser updates and rule edits, and also on a fixed schedule set by your risk owner. The schedule is a governance decision, so agree it in writing with the SOC lead and record each run with its date, the rule version and the result. Your cyber range can host these reruns without touching production. Ask any managed provider to state the test cadence and the evidence it returns in the written scope.
What should we do about sub-technique or platform gaps for T1120?
Map each platform you run to the data sources you actually collect, then list the gaps explicitly. A gap is acceptable when it is documented, has a compensating control such as a host-based alert or a manual hunt query, and has an owner who reviews it on a schedule. Do not present partial coverage as full coverage in audit or board reporting. Where ATT&CK does not define a sub-technique for your platform, record that as a scope decision instead of a missing detection.
Can our own team run the T1120 detection and validation, or do we need outside help?
Many teams can run the detection themselves if they already operate a SIEM and an EDR, have someone who can write and test rules, and have a cyber range or lab to test against. Outside help is most useful for the initial mapping, the range setup, or an independent check of your results. DeployOpen supports self-hosted open-source platforms in your own infrastructure and can plan, implement and document this work under a fixed written scope, but the decision should follow your own skills review. Ask any provider which parts of the work you would own after handover.
What evidence should we keep to show the T1120 detection works?
Keep the rule source, its ATT&CK version mapping, the telemetry sources it depends on, the validation test record with date and result, and the alert and response records from any real or exercise detections. Also keep the list of known gaps and the owner who accepted each one. Store this in a location your audit team can reach, and confirm with your assessor which format they expect, since requirements differ by framework and by organization.
Official sources for T1120 and ATT&CK detection mapping
Start with the MITRE ATT&CK tactic page for Discovery (TA0007) before writing any T1120 Peripheral device discovery rule. The tactic page frames Discovery as the adversary trying to figure out your environment, which is the question your detection has to answer for peripheral enumeration: what devices, drivers and attached hardware can a process or user see on the host, and which of those queries are normal for that role. Read the technique page alongside it to confirm the platforms in scope for T1120 (Linux, macOS and Windows) and the data components it references, then map each one to telemetry you actually collect, such as Process Creation, File Access and Process Access.
Next, read the ATT&CK updates page and the release notes for the version you target. Detection engineers need this because ATT&CK v18 replaced the detections in technique pages with detection strategies and analytics, updated data components and deprecated some data sources. Recent releases also rename, deprecate or revoke techniques. Record the ATT&CK version in every rule's metadata, and confirm with your team whether the release notes you rely on still describe T1120 and its data components unchanged before you ship a mapping.
For machine-readable mapping, use the enterprise-attack 20.0 STIX bundle in the attack-stix-data repository. It is the source to query when you need the exact data component and mitigation relationships for T1120, which is more reliable than copying labels from a web page. Parse the bundle with a script that pins the version, export the T1120 relationships into your detection catalog, and review the diff each time MITRE publishes a new release, so that your Sigma rules and Wazuh or Security Onion content stay traceable to the ATT&CK version they were written against.
How DeployOpen builds T1120 detections, purple team exercises and range scenarios
DeployOpen approaches T1120 Peripheral device discovery as a fixed-scope engagement inside the client's own environment. The work covers detection content for Linux, macOS and Windows, validation in a private cyber range, and documented handover to the client's security operations team.
How we scope
- Agree in writing which operating systems, endpoint telemetry sources and SIEM or Wazuh pipelines are in scope for T1120.
- Record which ATT&CK version the detection mapping targets, so later technique changes can be tracked against it.
- Confirm which peripheral device classes and logging configurations matter in the client's estate before any build work starts.
How we build
- Write detection logic in plain words for Process Creation, File Access and Process Access telemetry, then translate it into open-source rule formats.
- Tune rules against the client's normal peripheral and device management activity to reduce noise from legitimate administration.
- Document each rule's data sources, known blind spots and the logging settings it depends on on each platform.
How we hand over
- Deliver a validation report listing which range scenarios fired each detection, which did not, and why.
- Provide runbooks that tell analysts how to triage a T1120 alert, what evidence to collect and when to escalate.
- Walk the client's analysts through the detections and range results in a handover session, then leave the content under their control.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Retainer work can re-test T1120 detections after logging changes, platform upgrades or new ATT&CK releases.
- Ask the client to confirm retention periods and telemetry coverage for each platform before the retainer scope is agreed.
