T1555.004: Windows Credential Manager
Adversaries may acquire credentials from the Windows Credential Manager. The Credential Manager stores credentials for signing into websites, applications, and/or devices that request authentication through NTLM or Kerberos in Credential Lockers (previously known as Windows Vaults).[1][2]
The Windows Credential Manager separates website credentials from application or network credentials in two lockers. As part of Credentials from Web Browsers, Internet Explorer and Microsoft Edge website credentials are managed by the Credential Manager and are stored in the Web Credentials locker. Application and network credentials are stored in the Windows Credentials locker.
Credential Lockers store credentials in encrypted `.vcrd` files, located under `%Systemdrive%\Users\\[Username]\AppData\Local\Microsoft\\[Vault/Credentials]\`. The encryption key can be found in a file named Policy.vpol, typically located in the same folder as the credentials.[3][4]
Adversaries may list credentials managed by the Windows Credential Manager through several mechanisms. vaultcmd.exe is a native Windows executable that can be used to enumerate credentials stored in the Credential Locker through a command-line interface. Adversaries may also gather credentials by directly reading files located inside of the Credential Lockers. Windows APIs, such as CredEnumerateA, may also be absued to list credentials managed by the Credential Manager.[5][6]
Adversaries may also obtain credentials from credential backups. Credential backups and restorations may be performed by running rundll32.exe keymgr.dll KRShowKeyMgr then selecting the “Back up...” button on the “Stored User Names and Passwords” GUI.
Password recovery tools may also obtain plain text passwords from the Credential Manager.[4]
Analyst context for executives and security teams
Windows Credential Manager matters because it can hold reusable website, application, and network credentials on Windows endpoints. If an intruder or post-exploitation tool can enumerate or read those stored credentials, a single compromised workstation may become a source of additional access rather than an isolated incident.
Executive priority
Treat this as a credential-access risk tied to Windows endpoint resilience and incident scoping. Leaders should ask whether stored Windows credentials are necessary for business workflows, whether endpoint monitoring can show suspicious access to Credential Manager data, and whether incident response playbooks include reviewing exposed saved credentials when a Windows host is compromised. The relationship to multiple ATT&CK software entries, including Mimikatz, LaZagne, PowerSploit, and other Windows malware/tools, makes this a practical control-validation item rather than a theoretical concern.
Technical view
This is a Windows sub-technique under Credentials from Password Stores. Defensive validation should focus on attempts to enumerate Credential Manager using native tooling such as vaultcmd.exe, use of rundll32.exe with keymgr.dll KRShowKeyMgr for credential backup workflows, suspicious access to Credential Locker paths under user AppData, and programmatic enumeration through Windows Credential APIs such as CredEnumerateA. Because MITRE provides no official detection text for this object, teams should use the related detection strategy DET0134 as a starting point and test coverage against both native utilities and known credential-recovery tooling named in relationships.
Likely telemetry
- Windows process creation and command-line telemetry for vaultcmd.exe and rundll32.exe keymgr.dll KRShowKeyMgr
- File access telemetry for Credential Locker locations under %Systemdrive%\Users\[Username]\AppData\Local\Microsoft\[Vault/Credentials]\, including .vcrd files and Policy.vpol
- Endpoint detection telemetry showing credential-recovery or post-exploitation tools such as Mimikatz, LaZagne, PowerSploit, or SILENTTRINITY when present
- API-level or behavioral telemetry, where available, for calls that enumerate stored credentials such as CredEnumerateA
- User and host context showing whether credential access occurred from an expected administrative, user, or unusual process context
Detection direction
- Validate that DET0134-style logic covers both native Windows mechanisms and direct file access to Credential Locker storage, not only known tool names.
- Tune process detections around vaultcmd.exe and rundll32.exe carefully because some administrative or user-initiated credential management activity may be legitimate.
- Look for unusual parent-child process relationships, rare execution by user context, or credential access occurring shortly after other suspicious activity on the same Windows endpoint.
- Do not rely solely on malware signatures; the ATT&CK description explicitly includes native executables, Windows APIs, direct file reads, credential backups, and password recovery tools.
- Confirm collection depth: if command-line logging, file access telemetry, or endpoint behavioral data is absent, coverage for this technique may be materially limited.
Mitigation priorities
- Reduce exposure by disabling or removing unnecessary features, software, or workflows that store or recover credentials where business requirements allow, consistent with mitigation M1042.
- Review whether users and administrators need saved website, application, or network credentials on Windows endpoints, especially on high-value systems.
- Harden endpoint monitoring and response procedures so suspected access to Credential Manager triggers credential exposure assessment and follow-on containment decisions.
- Include saved-credential review in incident response scoping for compromised Windows hosts, since credentials obtained from local stores may enable later access.
- Use policy and user guidance to limit unnecessary credential saving, then validate with endpoint evidence rather than assuming the behavior is controlled.
Analyst notes and limits
ATT&CK links this technique to several groups, a campaign, and multiple software families/tools, but those relationships should be used for detection engineering context and threat-informed testing rather than as proof of current activity in any specific environment. The most useful local question is whether Windows endpoints both store sensitive credentials and produce enough telemetry to prove or disprove suspicious access.
The official ATT&CK object does not provide detection guidance, and the supplied mitigation relationship is broad. This take is therefore limited to behaviors described in the official technique text and supplied relationships. Local policy, endpoint configuration, logging depth, and legitimate credential-management workflows are required to determine priority and detection quality.
Windows Credential Manager
Adversaries may acquire credentials from the Windows Credential Manager. The Credential Manager stores credentials for signing into websites, applications, and/or devices that request authentication through NTLM or Kerberos in Credential Lockers (previously known as Windows Vaults).[1][2]
The Windows Credential Manager separates website credentials from application or network credentials in two lockers. As part of Credentials from Web Browsers, Internet Explorer and Microsoft Edge website credentials are managed by the Credential Manager and are stored in the Web Credentials locker. Application and network credentials are stored in the Windows Credentials locker.
Credential Lockers store credentials in encrypted `.vcrd` files, located under `%Systemdrive%\Users\\[Username]\AppData\Local\Microsoft\\[Vault/Credentials]\`. The encryption key can be found in a file named Policy.vpol, typically located in the same folder as the credentials.[3][4]
Adversaries may list credentials managed by the Windows Credential Manager through several mechanisms. vaultcmd.exe is a native Windows executable that can be used to enumerate credentials stored in the Credential Locker through a command-line interface. Adversaries may also gather credentials by directly reading files located inside of the Credential Lockers. Windows APIs, such as CredEnumerateA, may also be absued to list credentials managed by the Credential Manager.[5][6]
Adversaries may also obtain credentials from credential backups. Credential backups and restorations may be performed by running rundll32.exe keymgr.dll KRShowKeyMgr then selecting the “Back up...” button on the “Stored User Names and Passwords” GUI.
Password recovery tools may also obtain plain text passwords from the Credential Manager.[4]
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.
Related techniques
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 | T1555 | Credentials from Password Stores | This object subtechnique of Credentials from Password Stores. |
Groups, software, and campaigns
G0049: OilRig
OilRig is a suspected Iranian threat group that has targeted Middle Eastern and international victims since at least 2014. The group has targeted a variety of sectors, including financial, government, energy, chemical, and telecommunications. It appears the group carries out supply chain attacks, leveraging the trust relationship between organizations to attack their primary targets. The group works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.[1][2][3][4][5][6][7]
G0038: Stealth Falcon
Stealth Falcon is a threat group that has conducted targeted spyware attacks against Emirati journalists, activists, and dissidents since at least 2012. Circumstantial evidence suggests there could be a link between this group and the United Arab Emirates (UAE) government, but that has not been confirmed. [1]
G0010: Turla
Turla is a cyber espionage threat group that has been attributed to Russia's Federal Security Service (FSB). They have compromised victims in over 50 countries since at least 2004, spanning a range of industries including government, embassies, military, education, research and pharmaceutical companies. Turla is known for conducting watering hole and spearphishing campaigns, and leveraging in-house tools and malware, such as Uroburos.[1][2][3][4][5]
G0102: Wizard Spider
Wizard Spider is a Russia-based financially motivated threat group originally known for the creation and deployment of TrickBot since at least 2016. Wizard Spider possesses a diverse arsenal of tools and has conducted ransomware campaigns against a variety of organizations, ranging from major corporations to hospitals.[1][2][3]
S0476: Valak
S0349: LaZagne
S0681: Lizar
S0240: ROKRAT
S0629: RainyDay
S0692: SILENTTRINITY
SILENTTRINITY is an open source remote administration and post-exploitation framework primarily written in Python that includes stagers written in Powershell, C, and Boo. SILENTTRINITY was used in a 2019 campaign against Croatian government agencies by unidentified cyber actors.[1][2]
S0002: Mimikatz
S0526: KGH_SPY
S0194: PowerSploit
PowerSploit is an open source, offensive security framework comprised of PowerShell modules and scripts that perform a wide range of tasks related to penetration testing such as code execution, persistence, bypassing anti-virus, recon, and exfiltration. [1] [2] [3]
C0044: Juicy Mix
All related ATT&CK context
Mitigation direction
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.1 | Current bundle | fa7df04c437d… |
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]
Microsoft Credential Manager store
Microsoft. (2016, August 31). Cached and Stored Credentials Technical Overview. Retrieved November 24, 2020.
Open source URL -
[2]
Microsoft Credential Locker
Microsoft. (2013, October 23). Credential Locker Overview. Retrieved November 24, 2020.
Open source URL -
[3]
passcape Windows Vault
Passcape. (n.d.). Windows Password Recovery - Vault Explorer and Decoder. Retrieved November 24, 2020.
Open source URL -
[4]
Malwarebytes The Windows Vault
Arntz, P. (2016, March 30). The Windows Vault . Retrieved November 23, 2020.
Open source URL -
[5]
Microsoft CredEnumerate
Microsoft. (2018, December 5). CredEnumarateA function (wincred.h). Retrieved November 24, 2020.
Open source URL -
[6]
Delpy Mimikatz Crendential Manager
Delpy, B. (2017, December 12). howto ~ credential manager saved credentials. Retrieved November 23, 2020.
Open source URL -
[7]
mitre-attack T1555.004Open 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.