How T1652 device driver discovery shows up in your environment
A SOC lead who sees a process enumerating kernel drivers and modules should treat it as reconnaissance until the context shows otherwise. Device driver discovery sits under the Discovery tactic (TA0007) in MITRE ATT&CK, and it lets an adversary learn which security sensors, endpoint agents, virtualization components and hardware interfaces are present on a host. That knowledge helps an intruder decide what to avoid and which later steps are likely to work. This page maps the detection to ATT&CK Enterprise version 20.0. Recheck that mapping against the version you run, because ATT&CK releases can rename, deprecate or revoke techniques.
In intrusions, device driver discovery usually appears early, after initial access and before privilege changes or lateral movement, while the operator is still orienting on the host. The same information is also queried by legitimate work, including hardware inventory tools, driver update checks, backup and endpoint agent health checks, and help desk troubleshooting. Because of that overlap, a single event rarely proves intent. Detection depends on context: who launched the process, which parent process started it, what kind of asset it ran on, and whether the activity falls outside the normal pattern for that host group.
Before you write or tune rules, confirm what your sensors actually record. Process Creation and Command Execution telemetry show which tool ran and with which arguments on Linux, macOS and Windows, while File Access telemetry can show reads of driver and module locations if your agents collect it. Ask your endpoint and SIEM vendors, and your own platform team, which of these sources are enabled, how long they are retained, and whether they reach your stack at full fidelity. Record any gap as a known coverage limit, since a missing data source is exactly the blind spot an intruder depends on.
Which telemetry reveals device driver discovery on each platform
This table maps the data components most often referenced for Discovery techniques (Process Creation, Command Execution, File Access and OS API Execution) to Linux, macOS and Windows, with the signal to look for and an open-source collector. Read each row as a starting point for your own analytics, and confirm the detection strategy and analytic IDs for the ATT&CK version you target, because releases can change them.
| Data component | Linux | macOS | Windows |
|---|---|---|---|
| Process Creation (DC0032) | Execution of kernel module listing or loading utilities by an unexpected parent process, captured via auditd execve records. Collector: auditd forwarded to Wazuh. | Execution of kext or system extension inspection utilities from a non-administrative or unusual parent process. Collector: Wazuh or Velociraptor endpoint process artifacts. | Execution of driver enumeration utilities such as those querying installed device drivers or service-backed kernel drivers. Collector: Sysmon Event ID 1 forwarded through Wazuh or Security Onion. |
| Command Execution (DC0064) | Shell command lines that list loaded modules or device nodes, including unusual argument patterns from interactive or service accounts. Collector: auditd command logging and Wazuh log analysis. | Terminal or script command lines that query loaded kernel extensions or system extensions, especially from user sessions with no admin activity. Collector: Wazuh unified logging ingestion or Velociraptor artifact collection. | Command lines invoking driver query tooling or PowerShell cmdlets that enumerate devices and drivers, correlated with the parent process. Collector: Sysmon Event ID 1 and PowerShell script block logging via Wazuh. |
| File Access (DC0055) | Reads of kernel module metadata or device directories under /sys and /proc by processes that do not normally touch them. Collector: auditd file watch rules and Wazuh FIM. | Access to kernel extension bundle directories or system extension configuration by unexpected processes. Collector: Wazuh file integrity monitoring or Endpoint Security framework events through a supported agent. | Access to driver store or driver service registry paths by non-system processes. Collector: Sysmon file and registry events forwarded to Wazuh or Security Onion. |
| OS API Execution (DC0021) | Direct system calls or library calls that query device or module information, visible only where a kernel-level or eBPF collector is deployed. Collector: confirm eBPF tooling support in your distribution before relying on it. | API calls that enumerate IOKit device registry entries from unexpected binaries. Collector: confirm availability through your chosen endpoint agent, since visibility varies. | Calls to device enumeration APIs from processes outside expected management tools. Collector: Velociraptor artifacts or EDR telemetry where your environment includes it. |
| Confirm before rollout | Confirm the ATT&CK version, detection strategy ID and analytic IDs for T1652 in the enterprise-attack bundle you target. | Confirm which data components your collector can produce on each platform version before writing analytics against them. | Confirm log volume and retention needs for Sysmon and PowerShell logging with your security operations team before enabling them broadly. |
Detection ideas that catch T1652 without drowning the SOC in alerts
T1652 Device driver discovery is easy to over-alert on, because hardware inventory and endpoint management tools legitimately list drivers and modules all day. The cards below describe detection logic in words for Linux, macOS and Windows, then explain how to baseline, threshold and suppress known benign activity so that the remaining alerts are worth an analyst's time.
Unexpected driver enumeration by process
Start with the process, not the command. Alert when a process that has no business in hardware inventory lists drivers or kernel modules, for example a script interpreter, a web server worker, a document viewer or a user-launched utility. On Windows, this maps to Process Creation and Command Execution telemetry that names driver query tools. On Linux and macOS, watch for module listing utilities and reads of kernel module metadata launched from unusual parents. Record the parent process and the account, because the same binary can be benign under one and suspicious under the other. Tune by allowlisting specific parent and child pairs, not whole directories.
Bursts of enumeration from one host
A single driver listing is normal. Many listings in a short window from one host or one account is the pattern worth catching. Build a count of distinct enumeration events per host and per account over a fixed window, then alert when that count exceeds the baseline for the host's role. Pair the count with the number of distinct processes involved, since a burst from one trusted agent is different from a burst spread across several unrelated binaries. Start with conservative thresholds, review two to four weeks of alerts, then adjust per host group. Document each threshold so a reviewer can explain why an alert fired.
File reads under driver and module paths
Reads under driver or module directories, such as Windows driver store folders, Linux module trees and macOS extension locations, come from File Access telemetry when auditing is enabled. Confirm that the audit policy or file integrity rules cover these paths before writing logic against them, because silent gaps produce false confidence. Alert on reads by processes outside an approved set, and treat reads that are followed by process creation from the same parent as higher priority. Expect updates, scanners and backup tools to generate large volumes here, so suppress by signed publisher and known install path rather than by filename.
Baselining against inventory and management agents
Before alerting, document every legitimate tool that reads driver or module data: hardware inventory scanners, endpoint management agents, patch and asset management software, backup agents and vendor diagnostics. For each one, record its executable path, signing certificate, parent process and typical schedule. Use a two- to four-week observation window in a pilot group to capture real activity, then convert that record into an allowlist with an expiry date. Revisit the list after every agent upgrade, since a new version can change the child processes it launches. Ask the management vendor to confirm which driver queries its agent performs.
False positive sources to suppress
The most common noise comes from patch and asset management software, endpoint detection products themselves, driver update utilities and scheduled hardware audits. Each produces the same telemetry as an adversary, so suppression must be specific. Scope exclusions by signed publisher, install path and scheduled task identity, and never exclude an entire server group or admin account. Review suppressions monthly, because a suppression written for one tool version can hide a malicious binary that copies its path. Track the ratio of suppressed to escalated events as a tuning signal.
Validating the logic in a cyber range
Test each rule in a private cyber range using benign enumeration that mirrors the technique, run from representative processes on Linux, macOS and Windows test hosts. Check three outcomes: the event is collected, the rule fires at the intended threshold, and the allowlisted agents stay quiet. Record the results against the ATT&CK version you target, since mappings can change between releases. Keep the test harness under version control so that rule changes can be re-validated after each tuning cycle.
How to validate the T1652 detection in a lab before you trust it
This sequence turns the T1652 Device Driver Discovery detection into a tested control by emulating the behavior in a private cyber range, confirming the telemetry and alerts arrive intact, and measuring how well the rule performs. It produces a dated validation record that shows what was detected, how quickly, and where false positives come from.
Agree the emulation scope in writing
The detection owner, the SIEM administrator, the cyber range operator and the red team lead sign a short scope document before any activity starts. It names the target platforms (Linux, macOS and Windows), the test accounts, the time window, the ATT&CK version the detection maps to, and the stop conditions. It also states who can halt the exercise and how the lab is isolated from production networks. The step is complete when every signatory has confirmed the document and the range operator has verified the isolation.
Select representative hosts on each platform
Choose a small set of lab hosts that mirror production builds for each operating system in scope: a Linux server image, a macOS workstation image and a Windows endpoint image. Confirm that each host runs the same agent, logging policy and audit configuration as its production counterpart, because a test on a host with different telemetry proves little. Record the OS version, agent version and log sources for every host in the validation record. The step is complete when an inventory lists each host with its configuration and the SIEM confirms that each one is forwarding events.
Define the expected telemetry before testing
Write down, for each platform, which data components should produce evidence of the emulated behavior, such as Process Creation, Command Execution and File Access, and which fields the analyst expects to see, including the process name, parent process, user, host and command line where the platform records it. Set these expectations before the run so that results cannot be shaped after the fact. Agree which events count as a detection and which count as a miss. The step is complete when the expected-telemetry table is approved by the detection owner and stored with the rule.
Run the emulation and capture the raw events
The red team or range operator performs the agreed emulation steps on each host, described at the level of intent in your scope document and executed under the supervision of the range team. Capture the raw endpoint events on each host and note the exact start and end time of every action. Keep the raw logs even when no alert fires, because they show whether the telemetry existed at all. The step is complete when each host has a time-stamped log bundle linked to the scope document.
Confirm alerts reach the SIEM with correct fields
The SIEM analyst checks that each expected event arrived, was parsed, and matched the rule. For each match, confirm that the alert contains the fields defined in the expected-telemetry table, the correct host and user, and a timestamp that aligns with the emulation log. A detection that fires with missing or mis-parsed fields is a parsing defect, not a success. The step is complete when every expected event is either traced to an alert with correct fields or logged as a gap with a cause.
Measure detection rate, latency and false positives
Calculate the detection rate as the share of emulated actions that produced a correct alert, measure latency as the time between each action and its alert arrival, and count false positives by running the rule against a baseline period of normal administrative activity on the same hosts. Report the results per platform, because a rule can work well on Windows and poorly on macOS. Ask your SIEM and endpoint vendors to confirm how their ingestion pipeline affects latency before you present the figures as a benchmark. The step is complete when the metrics are written into the validation record with the method used to produce them.
Record the validation and set a re-test trigger
Write a validation record that includes the scope document, host inventory, expected-telemetry table, raw logs references, alert outcomes, metrics, known gaps and the approver's decision to accept, tune or reject the rule. Assign an owner for each gap. Set re-test triggers in the record: any change to the rule logic, the log source configuration or the agent version, and any update to the ATT&CK version the detection targets. Releases can rename, deprecate or revoke techniques, so check the ATT&CK updates page before each re-test. The step is complete when the record is filed and the re-test triggers are visible to the detection engineering queue.
Preventive controls that limit what discovery reveals
Preventive controls do not stop a user from listing devices or drivers, but they decide who can run those queries, whether the queries leave evidence, and how many unnecessary tools are available to run them. The three ATT&CK mitigations below work together: one makes activity visible, one limits who can perform it, and one removes the tools that make it easy.
Audit to keep detection evidence
Audit (M1047) is the mitigation that makes T1652 detectable at all. Device driver queries on Linux, macOS and Windows only show up in Process Creation and Command Execution telemetry if process auditing and command logging are turned on and forwarded to your SIEM. Check that process execution logging, the auditd or endpoint equivalent, and command-line capture are enabled on every platform in scope, and that the logs reach Wazuh or your chosen pipeline without gaps. A discovery rule cannot fire on events that were never recorded.
Restrict who can query hardware state
Operating System Configuration (M1028) covers the hardening settings that determine which accounts can inspect driver and hardware state. On Linux, that includes who can read kernel module listings, device nodes and sysfs paths. On Windows, it includes who can query installed drivers through standard tooling. Review these settings against your baseline and confirm that routine service accounts and ordinary users do not hold rights they never use. Narrowing access does not remove the technique from ATT&CK, but it reduces the population of accounts whose activity would be normal noise.
Remove unneeded tooling and features
Disable or Remove Feature or Program (M1042) reduces the number of utilities an intruder can use to enumerate drivers without writing new tools. Inventory the diagnostic packages, administrative utilities and scripting runtimes on production hosts, and remove those that no supported workflow requires. Where a utility must stay, record it as an expected tool so that any unexpected execution stands out in Command Execution telemetry. Confirm the inventory against the current ATT&CK version, because mappings to this mitigation are reviewed between releases.
Verify mappings against your ATT&CK version
Mitigation mappings are attached to techniques in the ATT&CK knowledge base, and they change as the framework is updated. Before you rely on this list in an audit or a control matrix, check the mapping for T1652 in the Enterprise version you target, and record that version in your documentation. The mitigation pages in the ATT&CK site and the STIX bundle for your version are the authoritative references. Ask your implementation partner to show the version pinned in your detection content.
What the SOC does when the T1652 alert fires
When a T1652 alert fires, the first decision is whether the device driver query came from a known, authorized source. Start by confirming the process, its parent, the user context and the host, then compare them against the approved inventory or management job calendar for that host. A driver listing run by a configuration management agent during a scheduled patch window is a very different event from an interactive shell on a database server that nobody is supposed to be touching. On Windows, the parent-child relationship and the account under which the command ran usually answer the question quickly. On Linux and macOS, check whether the activity coincides with a package update, a hardware change ticket or an approved support session. Record what you confirmed and what you could not confirm, because that record drives the next decision.
If the activity does not match an approved job, pivot to the host itself. Review recent logon sessions, including remote and privileged ones, and look for process activity in the surrounding window: discovery commands run alongside driver enumeration, unusual tools copied to the host, or new scheduled tasks. Also check whether the same user or parent process has triggered other T1652 alerts or related discovery alerts such as peripheral device discovery across the fleet. Escalate when the pattern spans several hosts, when the account is privileged or unfamiliar, or when the activity cannot be tied to any owner within your change window. The decision to isolate belongs to the incident lead and the endpoint owner, so agree in advance who can authorize it.
Containment should preserve evidence. Where the risk allows, prefer restricting network access or suspending the suspicious session over rebooting or reimaging, since memory and process state are lost on restart. Involve the platform or endpoint owner early, particularly when the host runs a managed workload, because a clean-looking termination can break a service or hide the trail. Document the case in a single record: the alert identifier, the ATT&CK version you mapped against, the telemetry reviewed, the owner you contacted, the disposition and the reason. Feed false positives back into your Sigma or Wazuh rule exclusions with a named approver, so the tuning is auditable and does not quietly widen the blind spot.
Rehearsing T1652 detection and response in a private cyber range
The Linux segment places a small set of hosts in an isolated range network, with a monitored workstation, a server profile and a log collector running Wazuh or a comparable agent. Telemetry should include process creation and command execution records from auditd or an equivalent agent, plus file access events on the directories where kernel module and device information is read. The facilitator plans injects as scripted, benign enumeration activity run by a range operator under an agreed runbook, so the team can judge detection quality without any real harm.
- Topology: Two or three Linux hosts, one log pipeline and one analyst workstation, all on a segregated range subnet with no route to production.
- Injects: Scripted enumeration of device driver information by a named operator at a planned time, followed by a second inject with a different tool to test coverage.
- Detection expectation: An alert appears within the window the team agreed in advance, and it shows the host, user, process lineage and time, so the analyst does not need to pivot to find basics.
- Response expectation: Triage notes record the alert, the affected host and the decision to contain or monitor, with timestamps.
- Lessons learned: Record which telemetry was missing, such as file access auditing not enabled on a path, and assign an owner to fix it.
Confirm with your platform team which audit rules and agent versions are in place in your own environment before the exercise.
The macOS segment reflects a fleet of managed endpoints, usually run by a device management or endpoint detection product your organization already owns. Telemetry depends heavily on what the endpoint agent collects, so the facilitator should confirm in advance which process, command and file events reach the log pipeline. Because macOS logging configuration varies by agent and by build, the range plan should treat coverage as something to measure, not assume.
- Topology: One or two managed macOS test endpoints enrolled in a range tenant, forwarding telemetry to the same SIEM used in production-like conditions.
- Injects: A scripted, benign discovery activity executed by an operator, paired with a control inject that performs a comparable action with an unrelated tool, so analysts can separate noise from signal.
- Detection expectation: A correlated alert that names the endpoint, the logged-in user and the process that performed the enumeration, delivered within the agreed window.
- Response expectation: The analyst documents whether the endpoint should be isolated through the management console, and records who approved that step.
- Lessons learned: Compare the event fields actually received with the fields the detection logic expects, and log any gaps for the platform owner.
Ask your endpoint vendor which macOS event types its agent exposes and whether they are available in your retention tier.
The Windows segment uses domain-joined test workstations and a member server, instrumented with Sysmon or an equivalent collector and forwarding to Wazuh, Security Onion or another SIEM your team already runs. Windows process creation, command execution and file access events are generally richer than on other platforms, which makes this segment a good place to test whether analysts can separate routine administrative activity from suspicious enumeration. The range should include a normal administrative baseline so false positives can be measured.
- Topology: Two or three Windows hosts in a range domain, one member server, and a collector configured with the audit and Sysmon policies your production estate uses.
- Injects: Benign driver enumeration run from a standard session, then the same activity from an elevated or service context, to check whether context changes the alert.
- Detection expectation: An alert within the agreed window that includes the host, account, parent process and command context, and that is tagged with the ATT&CK technique so the analyst can map it quickly.
- Response expectation: Triage notes state whether the activity matched the baseline, whether the account was verified with its owner, and what containment action was chosen.
- Lessons learned: Tune the rule for the baseline activity observed, record the change in version control and retest the same inject.
Review your Sysmon configuration with your Windows administrators before the exercise so that expected events are actually being generated.
Questions SOC leads and detection engineers ask about T1652
How do we separate legitimate hardware inventory tools from adversary device driver discovery?
Start by building an allowlist of the processes, service accounts and hosts that legitimately enumerate drivers, such as endpoint management agents, asset inventory scanners and vendor diagnostic tools. Then alert on enumeration that comes from outside that baseline, especially from interactive shells, unusual parent processes, or accounts that never run inventory jobs. Context matters more than the command itself: the same action at the same time from a known management server is routine, while the same action from a user workstation with no change ticket deserves review. Document each allowlist entry with an owner and a review date so exceptions do not become blind spots.
Which logs should we enable first for device driver discovery on Linux, macOS and Windows?
Prioritize the data components that ATT&CK detection strategies most often reference for Discovery techniques: Process Creation, Command Execution and File Access. On Linux and macOS, confirm that process auditing captures the execution of commands and that file access auditing covers the driver and kernel module paths your platform uses. On Windows, enable process creation auditing with command line capture and review what your endpoint agent already records. Verify each source by generating a known benign enumeration on a test host and confirming the event arrives in your SIEM with the fields your rules need. Exact event IDs and audit settings depend on OS version, so confirm them against vendor documentation for your environment.
How should we version detection mappings across ATT&CK releases?
Pin every detection to the ATT&CK version it targets, recorded in the rule metadata and in your coverage register. ATT&CK v18 replaced detections on technique pages with detection strategies and analytics, and later releases can rename, deprecate or revoke techniques, so a mapping that was correct in one version may need review in the next. Pull the relevant STIX bundle for each version from the attack-stix-data repository, diff the T1652 entries and related Discovery objects, and update your mappings in a tracked change. Keep older mappings in version control so audit evidence shows what was covered at a given date.
How can we test device driver discovery detections without disrupting production?
Run the tests in a private cyber range or an isolated staging segment that mirrors your production logging pipeline, not on live endpoints. Use a controlled, documented set of benign enumeration actions executed by a test account, with start and end times recorded so the SIEM alerts can be matched to the exercise. Confirm the range has no route to production systems, and get written approval from the owners of any system that will be touched. Schedule runs outside change freezes, and roll back any test artifacts afterward. The test plan should name what success looks like: the expected event, the expected alert and the expected triage notes.
How do we measure detection coverage for T1652 in a way auditors will accept?
Measure coverage as a documented chain: each ATT&CK technique and sub-technique in scope maps to a named detection, that detection lists its required data sources, and each data source is confirmed as collected on the relevant hosts. Then record the date of the last successful validation test and the result. Report gaps honestly, such as hosts missing audit policy or platforms where no rule exists yet. Coverage percentages are less useful than the evidence trail behind them, so keep the register, rule versions, test logs and alert records together. DeployOpen can help prepare this evidence for a compliance assessment, but independent auditors decide whether it meets their requirements.
What do we need to confirm about ATT&CK mitigations for device driver discovery?
Confirm which mitigations ATT&CK maps to Discovery techniques in the version you target, and check whether any of them apply to T1652 in your environment. The mitigations most often mapped to Discovery techniques in the current bundle include Audit, Operating System Configuration and User Account Management. Review each one against your platform: for example, whether audit policy is enforced by configuration management, and whether only approved administrators can load or change drivers. Record which mitigations you have implemented, which are partial, and which are not applicable, with the reason for each.
Can our own team run this detection program, or do we need outside help?
Many teams can run it internally if they already operate a SIEM, have endpoint telemetry, and staff a detection engineer who can maintain rules and tests. Outside help is more useful for the parts that are easy to underestimate: designing the cyber range, writing a validation plan, mapping coverage to ATT&CK versions and assembling audit-ready evidence. Ask any partner to confirm scope in writing, including which platforms, which log sources and which deliverables are covered. DeployOpen works on fixed-scope engagements and can also provide ongoing retainers for continuous testing and upgrades, but the right split depends on your team's skills and capacity.
How DeployOpen builds T1652 detections and range scenarios
DeployOpen starts every T1652 Device driver discovery engagement with a fixed scope agreed in writing before any work begins. In practice, the scope names the platforms in play (Linux, macOS and Windows endpoints are the common cases for this technique), the log sources that already reach your SIEM, the ATT&CK version the detections will target, and the deliverables, such as the detection rules, test records and runbook entries. Confirm early whether Process Creation and Command Execution events are collected on each platform, and whether File Access auditing is enabled on the paths where driver inventory data is commonly read. Those two answers decide how much of the work is tuning existing telemetry and how much is adding collection, which in turn shapes the schedule and the quote.
Detection engineering then proceeds in the open. DeployOpen maps the technique to the ATT&CK detection strategy and data components it references, writes candidate rules in an open format such as Sigma, and implements them in your existing open-source stack, for example Wazuh rules or Security Onion and Zeek-based analytics where network evidence is relevant. Each rule is tuned against baseline activity from your own hosts, because administrative tooling that enumerates drivers can look identical to this technique. The output is a tuned rule set with documented false-positive notes, not a promise of coverage. Ask for the rule-level change log and the ATT&CK version each rule targets.
Purple team exercises run in a private cyber range that mirrors your build images, so the team can execute agreed test scenarios and confirm that alerts fire, reach the right queue and carry enough context to triage. Results are handed over as documented evidence: scenario records, alert samples, gaps found, and the response steps your analysts should follow. DeployOpen prepares this evidence for your internal review and for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work. Support and continuous testing can be added as a retainer once the initial handover is accepted.
