AN0694: Analytic 0694
Defenders observe command-line executions or API-based registry reads targeting sensitive paths like HKLM or HKCU with keyword filters such as 'password', 'cred', or 'logon'. Typically performed by Reg.exe, PowerShell, custom binaries, or offensive tools such as Cobalt Strike. Correlation with process ancestry and command-line arguments indicates suspicious credential discovery activity.
Analyst context for executives and security teams
This analytic matters because it focuses on a common Windows credential-discovery pattern: processes reading sensitive Registry locations while searching for terms such as password, cred, or logon. For leaders, the decision value is whether the organization can see and investigate early credential-access behavior before it turns into broader identity compromise, lateral movement, or incident escalation.
Executive priority
Prioritize this as an identity and incident-readiness validation item for Windows environments. Executives and security leaders should ask whether SOC teams collect process command lines, process ancestry, and Registry-read evidence with enough fidelity to distinguish legitimate administration from suspicious credential discovery. The business value is not just alerting on a tool name; it is proving that the organization can recognize attempts to locate credential material in the Windows Registry and respond before compromised credentials affect resilience, audit posture, or recovery decisions.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into Windows command-line executions and API-based Registry reads targeting sensitive hives such as HKLM and HKCU, especially when combined with keyword filters like password, cred, or logon. The ATT&CK description identifies Reg.exe, PowerShell, custom binaries, and offensive tooling such as Cobalt Strike as possible execution sources, so detection should not depend on a single binary name. Correlate Registry access patterns with process ancestry, command-line arguments, user context, host role, and nearby authentication or privilege activity. Because no official detection logic or relationships were supplied, local baselining is required to separate administrative scripts, troubleshooting, inventory, and security tooling from suspicious discovery behavior.
Likely telemetry
- Windows process creation events with full command-line arguments
- Parent-child process ancestry for command shells, PowerShell, Reg.exe, and uncommon binaries
- Registry read/query telemetry for HKLM and HKCU paths
- PowerShell execution telemetry where available
- Endpoint detection and response process and Registry activity records
Detection direction
- Validate that Registry reads and command-line Registry queries are logged with enough detail to capture target hive/path and search terms.
- Look for combinations of sensitive Registry locations, credential-related keywords, and suspicious or unusual process ancestry rather than relying only on tool names.
- Tune against known administrative, troubleshooting, compliance, software inventory, and security-scanning activity that may legitimately query Registry values.
- Include custom binaries and script-driven activity in logic, since the object notes that activity may occur through Reg.exe, PowerShell, custom binaries, or offensive tools.
- Use host role and user context to prioritize alerts, especially where non-administrative users, unusual parent processes, or unexpected endpoints perform credential-related Registry searches.
Mitigation priorities
- Ensure endpoint logging and EDR coverage on Windows systems captures process command lines, ancestry, and Registry read/query activity.
- Restrict unnecessary access to sensitive Registry areas through least privilege and standard Windows hardening practices.
- Review and govern administrative scripts that search Registry content so they are identifiable, approved, and suppressible in detection logic.
- Harden PowerShell and command-line administration practices with appropriate logging, constrained administrative access, and change control.
- Prepare IR playbooks for suspected credential discovery, including scoping affected hosts, reviewing account activity, and determining whether credential rotation or containment is needed.
Analyst notes and limits
This object is a detection analytic for Windows in the enterprise ATT&CK domain. It provides a behavioral description but no official detection pseudocode, no tactics, and no relationship context. The strongest use is as a coverage validation prompt: confirm whether existing managed detection, endpoint monitoring, and IR processes can observe and triage credential-related Registry discovery behavior.
The supplied ATT&CK fields do not include active exploitation evidence, adversary attribution, impact claims, specific Registry paths beyond HKLM/HKCU examples, or a complete detection rule. Conclusions about risk, prevalence, and alert fidelity require local telemetry, asset context, and baseline administrative behavior.
Analytic 0694
Defenders observe command-line executions or API-based registry reads targeting sensitive paths like HKLM or HKCU with keyword filters such as 'password', 'cred', or 'logon'. Typically performed by Reg.exe, PowerShell, custom binaries, or offensive tools such as Cobalt Strike. Correlation with process ancestry and command-line arguments indicates suspicious credential discovery activity.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 6436de3069a2… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0694Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.