Detecting Browser Credential Store Theft

Nearly every infostealer targets the browser password store. Chromium-based browsers keep saved logins in a SQLite file named Login Data and protect the values with a key held in Local State; Firefox uses logins.json and key4.db. The access pattern is narrow and consistent, so a process that is not a browser touching these files is one of the cleanest detections in the stealer set.

Signals at a Glance

Auditing Access to the Stores

Sysmon does not log file reads, so reads need either EDR file-access telemetry or a Windows System ACL (SACL) on the stores. A SACL on each profile’s Login Data and Local State generates Security event 4663 for every read. Enable the File System audit subcategory first, then set the audit rule:

# Enable object-access auditing for the file system (once, via GPO in production)
auditpol /set /subcategory:"File System" /success:enable

# Add a read audit rule to a Chromium credential store (repeat per profile and browser)
$p = "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Login Data"
$acl = Get-Acl $p
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
    "Everyone", "ReadData", "Success")
$acl.AddAuditRule($rule)
Set-Acl -Path $p -AclObject $acl
# tune/validate: test on a pilot group; browsers read these files at startup,
# so expect a high volume from the browser itself until you allowlist it.

Then alert on every reader that is not a browser or a known security agent:

// Microsoft Sentinel (KQL) - non-browser reads of browser credential stores
let Browsers = dynamic(["chrome.exe","msedge.exe","firefox.exe","brave.exe","opera.exe","vivaldi.exe"]);
SecurityEvent
| where EventID == 4663
| where ObjectName has_any ("\\Login Data", "\\Local State", "logins.json", "key4.db")
| where AccessMask in ("0x1", "0x120089")
| extend Proc = tolower(tostring(split(ProcessName, "\\")[-1]))
| where Proc !in (Browsers)
| summarize reads=count(), files=make_set(ObjectName, 10) by Computer, SubjectUserName, ProcessName, bin(TimeGenerated, 15m)
// tune/validate: allowlist your EDR, backup and profile-sync agents by full path

Hardening and Triage

• Alert on the temp copy as well as the read: Chromium holds a lock on Login Data while running, so stealers commonly copy it before opening it. A file named Login Data created outside the profile directory is a strong lead.
• Chrome 127 introduced app-bound encryption to make the stored key harder to lift from outside the browser. Reported bypasses push stealers toward injecting into the browser or driving it directly, so pair this detection with the injection and remote-debugging signals on the cookie-theft page.
• Set a browser policy that disables the built-in password manager (for example PasswordManagerEnabled in Chrome and Edge) and move users to a managed password manager or SSO. You cannot steal what is not stored.
• On a confirmed hit, treat every credential saved in that profile as exposed: rotate, revoke sessions and review sign-ins. Containing the host is not enough.