How T1012 query registry shows up in Windows discovery activity
For a SOC lead, the hard part of T1012 Query Registry is that registry queries are a normal part of Windows. Applications, installers, management agents and the operating system itself read the registry constantly, so the detection question is not whether a query happened but which queries, run by which process, in what sequence, look like an adversary taking inventory of the host. Under the Discovery tactic (TA0007), ATT&CK describes this as an adversary trying to figure out the environment. Querying the registry lets an adversary learn the system configuration, the software installed on the host, and the security settings that govern what it can do next, often without dropping any new tooling.
In intrusions, this activity usually appears early or between stages, after access is gained and before movement or collection starts. The useful signal is the pattern: a short burst of reads against keys that describe installed applications, network and domain settings, or security tooling, issued by a process that has no business reading them, often from an unexpected parent or user context. The registry is also a common target for changes made during later stages, so the same telemetry should be reviewed alongside Windows Registry Key Modification events rather than in isolation. Confirm which registry auditing your Windows estate actually produces, because object access auditing on keys is not enabled by default and must be set deliberately.
This page maps detections to MITRE ATT&CK Enterprise version 20.0. ATT&CK releases can rename, deprecate or revoke techniques, and v20.0 is the version the mapping below targets, so recheck the technique and its data component references against the current release before you rely on them in a rule set. Your first decision is which registry hives and key paths you treat as high value for your environment, and your first check is whether process creation and command execution telemetry from your Windows endpoints is complete enough to attribute each query to a process.
Which telemetry reveals registry discovery on Windows
This table maps each data component relevant to T1012 Query Registry on Windows to the signal it gives, the open-source collector that produces it, and its gaps. Read it as a set of layers: process and command evidence shows who asked, registry auditing shows what was touched, and file evidence is a secondary check on exported hives. The main takeaway is that query-only reads are the weakest signal, so confirm your registry auditing configuration before relying on any rule.
| Telemetry source | Signal for T1012 | Open-source collector | Gap to confirm |
|---|---|---|---|
| Process Creation (DC0032) | Registry query utilities or scripts starting from unusual parents or user contexts | Sysmon process creation events forwarded to Wazuh or Security Onion | Renamed binaries and in-memory activity may not appear as expected process names |
| Command Execution (DC0064) | Command lines that reference registry hives, run keys or query switches | PowerShell script block logging and command line capture in Sysmon | Command line capture and script block logging must be enabled explicitly on each endpoint |
| Windows Registry Key Modification | Writes or value changes that accompany discovery, such as tooling staging data in keys | Sysmon registry events and Windows object access auditing feeding Wazuh agents | Read-only queries generally do not produce modification events, so this layer rarely shows pure discovery |
| Registry read auditing (object access) | Reads of sensitive hive keys when auditing is configured on those keys | Windows Security event log forwarded by the Wazuh agent or Winlogbeat to Security Onion | Auditing is off by default for most keys and can flood logs if applied broadly; confirm scope per key |
| File Access (DC0055), secondary | Creation or copy of exported hive files such as SAM or SYSTEM outside expected paths | Sysmon file create events and Windows file auditing on designated folders | Only relevant if hive exports occur; it does not cover in-memory registry reads |
| Endpoint hunting snapshots | Point-in-time evidence of loaded hives, recent command history and suspicious tool artifacts | Velociraptor collections run on demand against Windows endpoints | Collections capture state, not the moment of the query, so they support rather than replace event telemetry |
Detection ideas for T1012 that a SOC can tune
T1012 Query Registry is hard to alert on in isolation because reading the registry is routine for Windows software. The four approaches below combine process, command and access telemetry so that a SOC can separate ordinary administration from queries that do not fit a host's baseline. Tune every threshold against your own endpoint data before enabling alerts.
Read bursts from a single process
Alert when one process or user account issues an unusually high number of registry read events within a short window on the same host. The logic counts Windows Registry Key Modification and Process Creation events per process over a sliding window and compares the count with that host's historical median. Start with a window and count threshold derived from two to four weeks of baseline data, and review the top talkers first. Expect false positives from software inventory agents, endpoint management tools and installers, which legitimately enumerate large key trees. Allow-list them by signed binary path and parent, not by name alone.
Security-relevant keys read by unusual processes
Flag processes that read keys associated with credentials, security settings, installed software or network configuration when those processes do not normally touch them. The logic joins Windows Registry Key Modification telemetry with a per-host list of expected readers for each sensitive key path. Build that list from a clean baseline and from the vendors your estate actually runs. Expect noise from backup agents, vulnerability scanners and compliance tooling, which read widely by design. Confirm each exception with the owning team before adding it to the allow list.
Registry queries from unusual parents
Alert when a registry query utility is launched by a parent process that does not normally start one, such as an office application, a browser, a document viewer or a remote service host. The logic uses Process Creation events and Command Execution telemetry to pair each query utility invocation with its parent and command line. Build the expected parent list from observed administrative workflows. Expect false positives from login scripts, logon automation and deployment tools that run queries from shells, so review those parents with the operations team first.
Queries from remote and scripted sessions
Correlate registry query activity with remote logon sessions and scripted execution contexts, and alert when queries arrive over a session that has no matching change ticket or management job. The logic links Logon Session Creation context and remote administration process trees to Command Execution events on the target host. Define which remote administration paths are sanctioned, such as your endpoint management platform, and treat all others as review items. Expect false positives from remote support sessions and configuration management runs, so record their schedules and service accounts in the detection baseline.
Validate thresholds in the cyber range
Replay benign administrative activity and simulated registry enumeration on a range host, then measure how often each rule fires. The purpose is to set thresholds from observed rates rather than from assumptions. Use a fixed test plan that covers inventory agents, installers and a scripted operator session, and record the alert count and triage time for each rule. Revisit the thresholds after every major endpoint agent update, because agent behavior changes between versions.
How to validate that T1012 detections fire
This sequence confirms, in a private cyber range, that registry query activity mapped to T1012 produces telemetry, reaches the collector and triggers the intended rule within a measured window. It ends with a recorded pass or fail decision that the detection owner can defend to auditors and the SOC.
Agree scope and ATT&CK version
The detection owner, the SOC lead and the range operator agree in writing which Windows host roles, user contexts and registry hives are in scope, and which ATT&CK version the detection mapping targets. Name the version explicitly, because releases can rename, deprecate or revoke techniques and the mapping must match the release the team is using. The step is complete when the scope note and version are signed off and stored with the test plan.
Select benign registry discovery actions
Choose a set of low-impact registry read actions that correspond to T1012 Query Registry, covering several hives and key paths that the organization considers high value. Keep every action read-only and reversible, and document the expected telemetry for each one, such as the process that performs the query and the command execution record it produces. The step closes when each action has a written expected-signal entry that the detection engineer can check against later.
Instrument the Windows test hosts
Confirm that the range hosts forward process creation, command execution and registry-related audit events to the collector, and that the audit policy and logging settings match the production baseline. Record the configuration state of each host, including agent version, audit settings and clock source, so that a missing event can later be traced to a configuration gap rather than to the rule. The step is done when a health check shows all hosts reporting and the configuration snapshot is archived.
Run the scripted actions and log timestamps
The range operator runs the selected actions in the agreed order, with a timestamp recorded for each action start and end in a separate run log. Keep the run log outside the monitored hosts where practical so that the evidence is not dependent on the telemetry under test. The step closes when the run log lists every action, its start time and whether the operator observed any error during execution.
Confirm events reach the collector
The detection engineer searches the collector for each expected event and compares what arrived with the expected-signal entries from the planning step. Check field completeness, such as the parent process, user and command line fields, and record the ingestion delay for each event type. The step is complete when every expected event is either present with its required fields or listed as a gap with a likely cause, such as a missing audit setting or a parsing error.
Measure time to alert and rule match
For each action, record the time from the logged action start to the alert in the SOC platform, the name and version of the rule that fired, and whether the alert contains the host and user context needed for triage. Where a Sigma rule is the source, note the rule identifier and the converted query version used in the platform. The step closes when a complete row exists for every action, including actions where no alert fired.
Record missed events and decide pass or fail
Document each missed event or non-firing rule with its root cause category, such as telemetry gap, rule logic, threshold or enrichment, and assign an owner and a retest date. Decide pass or fail against criteria agreed in the scope step, for example that every in-scope action produces the expected event and an alert from the intended rule. A fail is retested after the fix, and the step is complete when the signed result, evidence bundle and rule change log are filed with the detection record.
Baselining registry reads before turning on alerts
Do not turn on T1012 alerts until you know what normal registry query activity looks like on each host role. Registry reads are constant on Windows: installers, security agents, group policy processing, and user sessions all query the registry as part of routine work. Start by collecting Process Creation and Command Execution events, along with Windows Registry Key Modification telemetry where your logging supports it, for a period long enough to cover normal business cycles, including patch windows and month-end processing. Group the results by host role, since workstations, member servers and domain controllers produce very different process lineages. For each role, record which parent processes launch command interpreters or query tools, how often they do so, and which accounts they run under. Confirm with your Windows and endpoint teams which logging policies are actually enabled on each role before you treat the data as complete.
Suppression is where most T1012 programs lose their value. Known management tools, such as endpoint agents, inventory collectors, and configuration management runners, should be suppressed by a precise combination of parent image path, signing certificate, service account and host group, not by process name alone, because a name is easy to reuse. Keep the suppression rules in version control with an owner and a written reason for each entry. Review a sample of suppressed events every cycle to confirm the tools still behave as expected. Do not suppress at the level of a whole host group or a whole account, since that removes the technique from view on the hosts where an intruder is most likely to blend in. Ask your detection engineering team to show how each suppression is tested against the Sigma rules and Wazuh rules you deploy, and which ATT&CK version the mapping targets.
Treat the baseline as a living record. Schedule a review after each significant change to the software estate, such as operating system upgrades, new security agents, changes to group policy or the addition of a management platform, and at a fixed cadence otherwise. During each review, compare current registry query volume and lineage against the last approved baseline for each role, and retire suppressions for tools that no longer exist. Assign a named owner for the review and keep a dated record of what changed. When MITRE releases new ATT&CK versions, check whether the detection strategies or data components behind your T1012 rules have changed, since releases can rename or deprecate content. Rehearse the review in your cyber range by introducing a new management tool and confirming that the baseline update, suppression and alert behavior all behave as your runbook says.
Preventive controls that limit what registry discovery reveals
Registry queries from an intruder only reveal what the host and its accounts expose, so preventive controls shape the answer before any detection fires. The four mitigations below reduce what a query can learn, and they also decide how much of that activity leaves a usable record. Confirm each control's effect on your own Windows estate before relying on it.
Audit policy for registry access
The Audit mitigation (M1047) covers configuring what the operating system records, so registry activity becomes visible to your SIEM. For T1012 Query registry, the key decision is which hives and keys get object access auditing, since enabling it everywhere creates heavy log volume. Check that the chosen keys produce events in your collection pipeline, and that someone reviews the volume at least monthly. Confirm the effect on your own hosts, because audit settings are inherited through Group Policy and can be overridden locally.
Operating system configuration hardening
Operating System Configuration (M1028) covers hardening settings that limit what ordinary users and processes can read from the registry. Tightening permissions on sensitive keys and disabling unneeded information disclosure reduces the value of a query for an intruder who lacks elevated rights. Review key permissions on hosts in scope, and check that changes survive a baseline refresh. Confirm with your platform team which keys are safe to restrict without breaking line-of-business applications.
Account scoping and user management
User Account Management (M1018) restricts which accounts can run enumeration at all, and how quickly unused or over-privileged accounts are removed. Registry queries made under a standard user account expose far less than those made under a service or administrator account. Review group memberships that grant broad read access, and remove standing privileges that no longer have a business owner. Confirm with your identity team how service accounts are scoped, since these are often the account a discovery query runs under.
Removing unneeded features and programs
Disable or Remove Feature or Program (M1042) reduces the tools available on a host that can perform registry enumeration. Legacy utilities, unused scripting components and unnecessary management agents each give an intruder another way to query the registry, and each one also needs monitoring. Build an inventory of installed components per host role, then remove or disable what the role does not need. Confirm with each application owner which components are required before removal, and test changes in a non-production image first.
Triage steps when a T1012 alert fires
When a T1012 alert fires, the first task is to establish what actually ran and who ran it. Confirm the process image, its command line, the parent process, the user context and the host name from the Process Creation and Command Execution records. Then check the Windows Registry Key Modification events if the alert was raised on a write, because a query-only alert may have no registry change to show. Note whether the parent is an expected management agent, a logon shell or an interactive console session. A query issued by a script host or a remote shell spawned by an unfamiliar parent deserves faster escalation than the same query issued from a known administrative tool. Record the exact timestamp in UTC so the event can be lined up with other sources later.
Next, decide whether the activity was authorized. Compare the host, user and time window against the change calendar, the approved administrative tool list and any patch, inventory or configuration management job scheduled for that period. Ask the system owner or the identity team to confirm whether the account was expected to query the keys named in the alert. An alert on a build server during a known deployment window is a different case from the same query on a finance workstation with no related ticket. If authorization cannot be confirmed within the agreed response window, treat the activity as unexplained and move on to scoping rather than waiting for a reply.
Look for neighboring discovery activity on the same host and account over a short look-back window. T1012 is often one step among several reconnaissance actions, so search for related T1082, T1033 and T1057 signals alongside it. Set containment thresholds in advance: for example, isolating a host when the query is unexplained and accompanied by other discovery or credential-related alerts, and only monitoring when it is isolated, authorized and self-contained. Document each decision with the evidence used, the people consulted and the time of the decision. Preserve the raw event records, the alert payload and any collected host artifacts in a case folder with hashes, so the incident record can stand on its own during review. Confirm the retention period of each log source with your own platform owners before you rely on it.
Rehearsing T1012 detection and response in a private cyber range
The range should be an isolated network that mirrors the Windows endpoints the team operates in production, with logging configured the same way it is in production. Before any exercise, confirm that the endpoints forward the telemetry the detection depends on, including process creation, command execution and registry key modification events. The collector, such as Wazuh or Security Onion, should be the same version and ruleset the production monitoring uses, so the results carry over.
- Instrumented Windows endpoints: Confirm that process creation auditing and command line capture are enabled on each test host, and that registry auditing is set on the key paths the detection covers.
- Collector parity: Record the exact collector version and rule set under test, because detection content changes between releases.
- Network isolation: Keep the range segmented from corporate and internet networks, with egress blocked by default.
- Time synchronization: Sync all hosts and the collector to one time source so events can be correlated across the timeline.
- Baseline capture: Snapshot the hosts before the exercise so the team can reset between runs.
Ask the range provider and your own platform team to confirm which audit settings and retention periods are in force on each host before the exercise starts.
Injects are scripted discovery activities mapped to T1012 that a red team or exercise lead runs on the range hosts. The scenario should include benign, pre-agreed activity at varied times so the defenders cannot predict when it occurs, plus one unlabeled inject that the defenders are not told about. The exercise lead keeps a private log that records the time, host, account and action of every inject so results can be checked afterwards.
- Scheduled injects: Run several registry query activities across the exercise window at different times of day, each logged by the exercise lead.
- Varied actors: Use more than one user account, including a standard user and a privileged user, so the team tests user context in the alerts.
- One unlabeled inject: Include a single activity that defenders are not told about, to test whether the detection fires without prior knowledge.
- Inject record: Store the exercise lead's log separately from the defenders' materials until the debrief.
- Stop conditions: Define in writing how the exercise stops if it affects production systems or leaves the range.
Confirm the approved inject list, the exercise window and the stop conditions with the sponsor before the first run.
A good detection outcome means that the alert fires for the scheduled and unlabeled injects, names the correct host and user, and arrives inside the window the team agreed in advance. The exercise should measure the result against these criteria instead of judging whether anyone noticed. Each inject should be scored as detected, detected late, detected with wrong context or missed.
- Correct host and user: The alert must identify the affected endpoint and the account that ran the activity.
- Agreed time window: Define the maximum acceptable delay between the inject and the alert before the run starts.
- Coverage of both inject types: Score the scheduled injects and the unlabeled inject separately.
- Rule identification: Record which rule or analytic produced each alert, including its ATT&CK version.
- False positive check: Note any unrelated alerts raised during the same window.
Ask your collector team to confirm which rule version and ATT&CK mapping were active during the run, so the results can be traced back to the exact detection logic.
Detection only helps if the analysts act on it in a consistent way. A good response outcome means analysts follow the triage runbook for T1012 from alert to disposition and record every decision with a timestamp. The exercise should check whether the runbook is clear, whether the analysts know who to escalate to, and whether the records are complete enough for a later review.
- Runbook use: Confirm that analysts follow the documented triage steps in order, such as confirming the host, reviewing the account and checking related activity.
- Decision record: Require a timestamped note for each decision, including whether the activity was judged benign, suspicious or confirmed.
- Escalation path: Test that the alert reaches the on-call contact defined in the runbook.
- Containment choice: Record whether the analysts isolate the host or only monitor it, and why.
- Evidence preservation: Check that the relevant logs are retained before any cleanup on the range host.
Review the runbook with the incident response lead before the exercise so the team tests the document as written.
The debrief turns the exercise into changes. Compare the inject log with the alerts and the analyst records, then list each gap by category, such as missing telemetry, late alerts, wrong context, unclear runbook steps or noisy rules. Each gap should have an owner and a retest date, and every rule change should be tested again on the range before it reaches production.
- Gap register: Record each missed or late inject with its root cause, such as a missing audit setting or a rule that filters the event.
- Rule tuning: Adjust detection logic only where the evidence supports it, and record the change with the ATT&CK version it targets.
- False positive review: Identify alerts that were noisy and decide whether to narrow them or accept them with documented reasons.
- Runbook updates: Revise steps the analysts found unclear or missing.
- Retest: Rerun the same injects after changes to confirm the gap closed without new noise.
Ask the sponsor to confirm who signs off the findings and how the retest results will be kept for later review.
Questions detection engineers ask about T1012
Are registry reads logged by default on Windows?
No, not in a form most teams can use for detection without configuration. Windows does not record every registry query by default, so T1012 visibility depends on what you enable. Registry auditing is controlled through object access auditing on specific keys, and the volume it creates can be high, so scope it to keys that matter for your environment. Process Creation and Command Execution telemetry, usually from Sysmon or Windows Security event logging with command line capture enabled, shows the process that performed the query even when the individual read is not logged. Confirm your current audit policy and which keys are covered with your own administrators before you write any rule against it.
How do I separate T1012 from T1082 system information discovery?
Separate them by the process and the key path, not by the fact that the registry was read. T1012 covers adversaries querying the registry for configuration, software, or security settings, while T1082 covers gathering general system details such as OS version and hostname. Many built-in and vendor tools read the same keys for both purposes, so a single event rarely settles the question. Build the rule around the combination of a query tool or command, a sensitive key family, and an unusual parent process or user context. Record in your rule metadata which ATT&CK version and technique IDs it targets, so the two mappings stay distinct as the framework changes.
How do I handle noisy management tools that query the registry?
Start by inventorying the legitimate tools in your estate that read the registry, including endpoint agents, inventory scanners, patch tools, and backup software. Then allowlist them by a stable combination of signed binary path, parent process, and service account, not by process name alone, because names are easy to imitate. Review exclusions on a fixed schedule and treat any exclusion as a documented decision with an owner. Expect the first tuning cycle to take longer than the rule itself. Confirm with your platform team which management tools run on which hosts and at what intervals before you set thresholds.
How do I test detections against a specific ATT&CK version?
Pin the version in your detection repository and test against that version's content. ATT&CK publishes its content as STIX 2.1 bundles in the attack-stix-data repository, one per domain and version, so you can script a check that every rule's technique ID still exists and is not deprecated or revoked. Releases can rename or deprecate techniques, and the detection strategy and data component mappings have changed in recent versions, so record the version you targeted in each rule. Review the release notes for the version you upgrade to before you change mappings. Confirm the exact version your program targets with your governance owner.
Do I need Sysmon to detect T1012?
Sysmon is not strictly required, but you need equivalent process and command telemetry from somewhere. Without Process Creation with command line data, the detection has little to pivot on, and registry query activity is difficult to attribute to a specific process. Sysmon is a common free option from Microsoft, and it can produce registry events for selected keys, but it needs a configuration that you tune and maintain. Some endpoint platforms provide similar data natively. Confirm which telemetry your Windows estate already collects, at what volume, and whether your log pipeline forwards it to the platform you run.
How often should T1012 detections be re-validated?
Re-validate after every change that could alter the telemetry or the rule, and on a recurring schedule set by your risk owner. Triggers include a new ATT&CK version, an operating system or agent upgrade, a change to audit policy or Sysmon configuration, and a change to the management tools in your estate. A recurring cadence keeps the detection from silently breaking when logging stops arriving. Each run should record the test date, the ATT&CK version, the rule version, and the result. The right frequency depends on your change volume and regulatory expectations, so confirm it with your compliance lead and auditors.
Can our own team run T1012 detection and validation, or do we need outside help?
Your team can run it if it has Windows logging expertise, a SIEM or log platform it operates, and time to maintain rules. The work breaks into four parts: configuring telemetry, writing and tuning rules, building repeatable validation in a private cyber range, and documenting evidence. Outside help is often used for the cyber range build, for a scoped validation exercise, or for a retainer that re-tests after changes. DeployOpen implements and documents self-hosted open-source platforms inside a client's own environment and runs security testing and private cyber ranges, under fixed-scope written agreements. Cost depends on the number of hosts, the telemetry you already have, and how much tuning your estate needs, so ask for a quote against a written scope.
How DeployOpen builds T1012 detections and range exercises
DeployOpen approaches T1012 Query registry as a fixed-scope engagement inside the client's own environment, with detection logic built on Windows process and registry telemetry. Each step is agreed in writing, tested in a private cyber range, and documented so the client's own team can run and maintain it.
How we scope
- Confirm which Windows endpoint groups and admin workstations fall inside the written scope for T1012 Query registry.
- Inventory the telemetry already collected, such as process creation, command execution and registry key modification events.
- Agree the ATT&CK version the detection mapping targets, so later technique changes do not silently alter coverage.
- Record which Windows hosts are excluded and why, so the scope and any gaps are visible to auditors.
How we build
- Write detection logic in open-source formats such as Sigma rules, then translate it for the client's SIEM or Wazuh deployment.
- Map detections to the relevant ATT&CK detection strategies and data components, naming each data source used.
- Tune thresholds and allowlists against the client's normal administrative and software-management registry activity.
- Test each detection against controlled cyber range exercises that reproduce the technique's observable behavior in words and logs.
How we hand over
- Deliver written runbooks covering alert triage, escalation paths and evidence collection for T1012 detections.
- Provide validation records showing which exercises fired which rules, with timestamps and the telemetry relied on.
- Document known blind spots, such as hosts without registry auditing enabled, so the client can plan remediation.
- Train the client's analysts on the detection logic and the range exercise so they can repeat validation themselves.
How we support
- Ongoing support, rule updates and continuous testing are available as a retainer after the fixed-scope work closes.
- Review the T1012 mapping whenever MITRE ATT&CK publishes a new version that renames, deprecates or revokes related content.
- Re-run cyber range exercises after logging changes, endpoint agent upgrades or SIEM migrations that could affect telemetry.
- Confirm with the client's compliance lead which control evidence the T1012 work supports, and leave final assessment to the independent auditor.
