T1012 Query Registry: Detecting Registry Reads for Stored Credentials and Security Settings

The Windows Registry tells an intruder which remote access tools a user has configured, which servers they connect to, whether an autologon password is sitting in plain text and which security products are installed, and reading it takes no special privilege for most of those answers. MITRE ATT&CK tracks this as T1012 Query Registry, a Discovery technique on Windows. Registry reads happen millions of times a day on every host, so the technique cannot be blocked and is hard to see without the right telemetry. This guide is for detection engineers, SOC analysts and Windows administrators. It focuses on the registry locations attackers read for credentials and connection history (PuTTY, WinSCP, VNC, RDP client history and Winlogon autologon) and for security configuration, explains why common Sysmon configurations miss registry reads, and sets out how to detect and reduce the exposure.

Key takeaways

• Most telemetry records writes, not reads. Sysmon registry events cover key creation, deletion, value set and rename; seeing a read needs a SACL with Audit Registry (event 4663), EDR registry telemetry, or the command line of the tool doing the reading.
• A few keys carry most of the risk. Winlogon autologon values, saved session keys for SSH, SFTP and VNC clients, RDP client server history and security product keys are where targeted reads concentrate.
• Autologon is a plain text password. Microsoft states the Winlogon DefaultPassword is stored in plain text and that the key can be read remotely by Authenticated Users.
• Real groups do this. Volt Typhoon enumerated stored PuTTY sessions, Operation Wocao queried PuTTY session keys, and Chimera read RDP client server history from remote hosts.
• Cleaning the registry beats watching it. Removing stored passwords and connection secrets, then auditing the few keys that must remain, is cheaper than broad registry auditing.

What T1012 covers in ATT&CK v20

ATT&CK v20 (technique version 1.3) describes Query Registry as interacting with the Windows Registry to gather information about the system, configuration and installed software, often with the Reg utility (S0075) though other means exist, and using the result during automated discovery to shape follow-on behaviour. The platform is Windows only. There are no sub-techniques and no listed mitigations.

Two neighbouring techniques have their own pages and should not be confused with it: Credentials in Registry (T1552.002), where the goal is extracting a stored secret, and Modify Registry (T1112), where values are changed. T1012 is the read and discovery step that usually comes first. Security Software Discovery (T1518.001) also names reg query as a common method. For credential extraction depth see the MITRE ATT&CK T1552 Unsecured Credentials Guide; for registry changes see MITRE ATT&CK T1112 Modify Registry.

High-value registry locations attackers read

The table lists locations that appear in ATT&CK procedure examples or vendor documentation, what they reveal and the owner of the fix. It is a monitoring and clean-up list, not an exhaustive one.

Related but distinct: reading HKLM\SECURITY\Policy\Secrets needs SYSTEM and is LSA Secrets (T1003.004), and saving the SAM, SYSTEM and SECURITY hives, as ATT&CK records for Daggerfly, is Security Account Manager dumping (T1003.002). Both are credential access, not discovery, and should alert on sight. See the T1003 OS Credential Dumping guide.

How adversaries use registry queries

• Finding the next hop: CISA's Volt Typhoon advisory (AA24-038A) lists reg query among the group's living off the land tools and records enumeration of stored PuTTY sessions; ATT&CK v20 records Volt Typhoon querying installed software including PuTTY. During Operation Wocao the actors queried the per-user PuTTY Sessions key to find recent SSH sessions.
• Remote harvesting across hosts: Chimera queried the Terminal Server Client Servers key on remote hosts under each user's SID, building a map of RDP targets without running code on each machine.
• Environment checks before payload: TEARDROP checked a registry key existed before decoding its payload, and BlackByte read language settings; these checks decide whether the malware proceeds.
• Software inventory for targeting: APT38 ran Node.js malware that queried the registry for installed software, and Dtrack collected RegisteredOwner, RegisteredOrganization and InstallDate values.
• Offline hive access: Fox Kitten accessed the ntuser.dat and UserClass.dat hives (per CISA AA20-259A), which avoids live registry APIs entirely.

What to detect and where

ATT&CK v20 detection strategy DET0209, "Detection of Registry Query for Environmental Discovery", has one Windows analytic (AN0589): registry read access by suspicious or non-interactive processes querying system configuration, installed software or security settings. It names Process Creation (Sysmon event 1), Windows Registry Key Modification (Sysmon events 13 and 14) and Command Execution (PowerShell events 4103 to 4106).

The read visibility gap

Microsoft's Sysmon documentation defines its registry events as key and value create and delete (12), value set (13) and rename (14). None records a read, so a typical Sysmon deployment sees reg.exe query through its command line but not an implant calling the registry API directly. To see reads you need one of:

Detection logic that holds up

• Targeted key reads by unusual processes: put read SACLs on the small set of keys in the table above (Winlogon, PuTTY Sessions, WinSCP sessions, VNC keys, Terminal Server Client) on pilot hosts, and alert on event 4663 where the process is not the owning application, Explorer, backup or management agents.
• reg.exe from odd parents: reg.exe query spawned by web servers, database servers, Office applications, script hosts or remote shells, especially with search switches for strings such as "password".
• Remote registry fan-out: one workstation opening the winreg pipe on many hosts, or the Remote Registry service starting on hosts where it is normally stopped.
• Read then use: a read of PuTTY, WinSCP or RDP history keys followed within the hour by new SSH, SFTP or RDP connections from that host to hosts it has not contacted before.
• Hive saves: reg save of SAM, SYSTEM or SECURITY, or copying ntuser.dat, outside backup tooling. High fidelity, escalate as credential access.

Baselining

Inventory, patch, backup and EDR agents read the registry constantly. Allow list by signer and install path, scope SACLs narrowly so the volume stays low, and review the allow list when agents change. CISA's Volt Typhoon guidance to baseline installed tools and account behaviour applies directly: a remote shell running reg.exe on a domain controller should never look normal. See the Windows Event Log Guide and Windows Event Forwarding Guide for collection.

Reducing what the registry gives away

ATT&CK v20 maps no mitigation to T1012. The steps below are NHI Mgmt Group recommendations, ordered by value.

1. Find and remove plain text autologon passwords. Query the Winlogon DefaultPassword value across the estate with your management tool (read only), then remove it or move devices to a dedicated, non-privileged kiosk account. Microsoft recommends autologon only where the computer is physically secured and untrusted users cannot remotely access the registry.
2. Stop client tools saving passwords. Set WinSCP to require a master password or disable password saving by policy, and move SSH users to key-based or certificate-based authentication with keys protected by a passphrase or hardware token. The PuTTY FAQ recommends public key authentication rather than remembered passwords.
3. Remove unmanaged remote access software. VNC and similar tools installed outside IT control both store configuration in the registry and provide an access path.
4. Restrict remote registry access. Keep the Remote Registry service disabled where it is not needed and limit who can connect to the winreg pipe, which also limits the remote read Microsoft warns about for the Winlogon key.
5. Protect local admin and service credentials. Use Windows LAPS for local administrator passwords and gMSAs for services instead of storing service passwords anywhere readable.
6. Audit the keys that must remain. Add read SACLs to the short list of sensitive keys rather than auditing the whole registry.

Where identity fits

Many secrets found in the registry are non-human or shared credentials: kiosk and autologon accounts, SFTP accounts used for file transfers to partners, and VNC passwords shared by a support team. They rarely have owners or rotation schedules, which is why they survive in the registry for years. Treat each one found as an identity to inventory, own and replace with a managed alternative. See the Service Account Security Guide.

How to test your coverage

1. Telemetry check: confirm command line logging, PowerShell 4104 and, on a pilot ring, Audit Registry events for SACL-protected keys reach the SIEM.
2. Emulate in an authorised test: read the test values in each sensitive key three ways: reg.exe, PowerShell and a compiled test program calling the registry API. Record which produce an alert.
3. Emulate remote reads from a test workstation against two servers and confirm the fan-out rule.
4. Measure volume for two weeks in alert-only mode, then tune by signer and path.
5. Rollback: SACLs can be removed by the same Group Policy that set them; keep them in a dedicated GPO.

Metrics

• Autologon exposure: number of hosts with a Winlogon DefaultPassword value (target zero outside approved kiosks).
• Stored client passwords: number of hosts with WinSCP saved passwords without a master password, trending to zero.
• Read coverage: of the three read routes in testing, how many raise an alert for each sensitive key.
• SACL coverage: percentage of tier 0 and tier 1 servers with read SACLs on the sensitive key list.
• Noise: T1012 alerts per 1,000 hosts per week after tuning and the share closed as benign.

Common failure patterns

• Relying on Sysmon for reads. Teams map T1012 as covered because Sysmon registry events are on, but those events record changes, not reads.
• Auditing the whole registry. Broad SACLs flood the Security log, which Microsoft warns against, and the auditing is switched off.
• Leaving autologon on servers. Build and lab servers keep a domain account in the Winlogon key long after setup, readable remotely by Authenticated Users.
• Searching only for "password". Rules match string searches but miss targeted reads of known keys such as PuTTY Sessions or Terminal Server Client, which is what Volt Typhoon, Operation Wocao and Chimera did.
• No follow-through after detection. A confirmed read of saved session keys is closed without checking for new connections to the listed hosts or rotating the credentials found there.

Framework mapping

Practitioner checklist

• Scan the estate read-only for Winlogon DefaultPassword values and remove them.
• Enforce WinSCP master password or disable password saving; move SSH to keys or certificates.
• Remove unmanaged VNC and remote access tools.
• Disable Remote Registry where not required and monitor winreg pipe access.
• Enable Audit Registry and add read SACLs only to the sensitive key list, starting with tier 0 and tier 1 servers.
• Alert on reg.exe from unusual parents and on hive saves outside backup tools.
• Correlate reads of session history keys with new outbound SSH, SFTP or RDP connections.
• Record ATT&CK coverage for T1012 as partial unless read telemetry exists.
• Rotate any credential found in the registry and assign it an owner.

Standards and references

• MITRE ATT&CK: T1012 Query Registry
• MITRE ATT&CK: T1552.002 Credentials in Registry
• CISA: AA24-038A PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure
• Microsoft Learn: Configure Windows to automate logon
• Microsoft Learn: Audit Registry
• Microsoft Learn: Sysmon
• PuTTY: Frequently Asked Questions
• WinSCP: Securing credentials

Related NHI Mgmt Group resources: Living off the Land Guide · Sysmon Guide · ATT&CK Credential Access Tactic Guide · ATT&CK Detection Strategies and Analytics Guide