DET0412: Detect Access or Search for Unsecured Credentials Across Platforms
DET0412 is a detection strategy for finding activity associated with access to or searching for unsecured credentials. Its practical value is that exposed...
Analyst context for executives and security teams
DET0412 is a detection strategy for finding activity associated with access to or searching for unsecured credentials. Its practical value is that exposed secrets are often a pivot point from an initial compromise into broader identity, cloud, SaaS, IaaS, Linux, or Windows access. For leaders, this is less about one alert and more about proving the organization can see when attackers look for misplaced passwords, keys, registry-stored credentials, shell history, or similar artifacts tied to ATT&CK technique T1552.
Executive priority
Prioritize this as an identity and incident-readiness control area. If unsecured credentials exist and access to them is not visible, an intrusion can become harder to contain because responders may not know which accounts, keys, or environments require rotation. Executives should ask whether teams can identify where sensitive credentials are stored, whether access to those locations is logged, and whether incident response playbooks include credential revocation and validation across Windows, Linux, SaaS, and IaaS where applicable to the related technique.
Technical view
The supplied detection strategy has no official detection text or platform list, but it detects T1552: Unsecured Credentials, which is associated with credential access across Windows, SaaS, IaaS, and Linux. SOC and detection teams should validate coverage around access to known credential storage locations and artifacts referenced by the related technique, such as plaintext files, shell history, registry credential locations, private keys, and application or operating-system repositories. Detection should be tested against legitimate administrative activity to reduce noise while preserving visibility into unusual access, search, or collection patterns.
Likely telemetry
- Endpoint file access and process execution logs showing reads, searches, or collection of credential-like files or artifacts
- Windows registry access telemetry for credential-related locations where applicable
- Shell history and command-line telemetry on Linux or other managed hosts where collected
- Cloud and SaaS audit logs showing access to secrets, keys, configuration stores, or credential-bearing objects where applicable
- Identity logs for subsequent authentication using accounts or keys that may have been exposed
Detection direction
- Map local data sources to T1552-relevant credential locations rather than assuming DET0412 provides platform-specific coverage; the object itself does not specify platforms or detection logic.
- Tune for context: administrators, backup tools, deployment systems, and security scanners may legitimately read credential-bearing files or repositories.
- Look for combinations of search behavior, unusual process lineage, access by unexpected users, access outside normal maintenance windows, or activity followed by new authentication from related identities.
- Validate whether cloud and SaaS audit logs capture access to secrets or credential-bearing configuration objects, since the related technique includes SaaS and IaaS platforms.
- Use incident-response feedback to identify missed credential locations discovered during investigations and add them to monitoring scope.
Mitigation priorities
- Inventory where credentials, private keys, shell history artifacts, application secrets, and configuration files may reside across the environments in scope.
- Reduce exposure by removing plaintext or misplaced credentials and moving secrets into managed, access-controlled repositories where feasible.
- Restrict and monitor access to credential-bearing files, registries, repositories, and cloud/SaaS secret locations.
- Ensure rapid credential rotation and revocation procedures are part of incident response for suspected T1552 activity.
- Use detection validation and compliance evidence reviews to confirm logs are retained and searchable for credential access investigations.
Analyst notes and limits
This take is relationship-driven because the detection strategy record itself provides no official description, no official detection guidance, no tactics, and no platforms. The strongest supported context is that DET0412 detects T1552, Unsecured Credentials, a credential-access technique associated with Windows, SaaS, IaaS, and Linux. Defensive decisions should therefore be grounded in the organization’s actual credential storage patterns and available telemetry.
The official object is sparse: no detection text, no platform field, and no tactics are specified on DET0412 itself. Recommendations are conservative and derived from the supplied relationship to T1552 and its description. Local validation is required before asserting coverage, risk exposure, or detection effectiveness.
Detect Access or Search for Unsecured Credentials Across Platforms
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1552 | Unsecured Credentials | This object detects Unsecured Credentials. |
All related ATT&CK context
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 | 418570e10a15… |
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 DET0412Open 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.