Saving a password in the browser is easy for users and attractive to attackers. The browser keeps the data on disk, and the same machine that can use it can usually be asked for it. MITRE ATT&CK technique T1555.003, Credentials from Web Browsers, covers acquiring those credentials. The tactic is credential access, and the platforms are Linux, macOS and Windows.
How attackers use it
MITRE explains that adversaries read files specific to the target browser. Browsers typically keep credentials in an encrypted format inside a credential store, but methods exist to extract plaintext from them.
On Windows, MITRE gives Google Chrome as an example. Encrypted credentials sit in a database file named Login Data under the user's AppData\Local\Google\Chrome\User Data\Default folder. Reading that database and passing the encrypted values to the Windows API function CryptUnprotectData returns plaintext, because the function uses the victim's cached logon credentials as the key. The decryption works because it runs as the user.
MITRE adds that similar procedures exist for other common browsers, including Firefox, Safari and Edge. Windows stores Internet Explorer and Edge credentials in Credential Lockers managed by Windows Credential Manager, a separate technique covered at T1555.004. Adversaries may also search browser process memory for patterns that commonly match credentials.
The follow-on risk is reuse. Once credentials are collected, attackers may try them on other systems and accounts. That is most damaging where browser saved credentials overlap with privileged accounts such as a domain administrator.
How to detect it
MITRE lists no data sources on this page, so detection comes from behavior around these files.
- Unexpected file reads. A process that is not the browser opening the browser's credential database. File access auditing and endpoint telemetry both capture this, and a baseline of which processes legitimately open these files makes the signal clear.
- Copies of credential files. The
Login Datafile copied to another path or to a staging folder. - Credential API use. Processes calling the decryption API on data that did not originate in their own profile.
- Memory access. One process reading the memory of a browser process.
- Reuse and spread. The same account suddenly signing in to many systems, or a browser saved account used from a new device. Review sign-in logs for accounts that are known to be stored in browsers.
How to reduce the risk
MITRE lists five mitigations.
- Update software. Keep browsers, password managers and related software current so known vulnerabilities cannot be used to extract credentials or session cookies.
- User account management. Apply strict policies so unnecessary accounts cannot reach sensitive systems, and audit regularly to disable inactive accounts that attackers could target.
- User training. Teach secure credential practices: avoid storing sensitive passwords in browsers, use password managers properly, and recognize phishing that could steal session cookies or credentials.
- Restrict web based content. Restrict or block web content that could be used to extract session cookies or stored credentials. Use browser settings such as disabling third-party cookies and restricting extensions to cut the attack surface.
- Password policies. Weigh the risk of storing credentials in web browsers at all. If disclosure is a significant concern, use technical controls, policy and training to prevent browser storage.
The strongest single change is policy: on managed devices, decide whether browser password saving is allowed, and for privileged accounts the answer should be no. Pair it with multi-factor authentication so a recovered password alone does not open the door.
Check your own environment
Work through this checklist on a sample of managed machines.
- Is the browser password saving setting controlled by policy, or left to each user?
- Do any administrator or service accounts have saved passwords in browsers?
- Are browsers and extensions installed only from an approved list?
- Do your endpoint tools alert when a non-browser process opens browser credential databases?
- Are privileged accounts protected by MFA and kept separate from everyday accounts?
A read-only way to see how many profiles exist on a Windows machine, without opening any credential files:
# List Chrome profile folders for the current user (names only)
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data" -Directory | Select-Object Name
Do not open or copy the credential database itself during an audit. Use your endpoint tooling to count saved logins, or ask the browser's own management policy report.
Quick check
Why can a malicious program decrypt browser passwords without knowing the user's password?
On Windows, CryptUnprotectData uses the victim's cached logon credentials as the decryption key. A program running as that user can call it, so the encryption does not stop a local attacker running in the user's context.
Why is this technique especially risky for administrators?
Collected credentials may be recycled across systems and accounts. If a browser held a privileged account such as a domain administrator login, the attacker gains far more access than the original compromise gave.
