Chrome App-Bound Encryption Bypass

Technique for decrypting Chrome's App-Bound Encryption (ABE) credential database, introduced in Chrome 114 to harden Login Data against DPAPI-only decryption. Malware bypasses ABE by retrieving the app-bound key from the Chrome Local State or via COM elevation.

Detection / Fingerprint

• Go function names: main.GetAppBoundKey, main.StartAPPB, main.decryptAPPB
• File access: %LOCALAPPDATA%\Google\Chrome\User Data\Local State
• Registry access: SOFTWARE\Microsoft\Windows\CurrentVersion\Run (persistence for elevated key retrieval)
• COM interaction: CoCreateInstance, CoInitializeEx for Chrome Elevator COM interface

Implementation Patterns

The AFK Stealer sibling bd6dead7 includes a dedicated ABE bypass module:

• main.GetAppBoundKey — retrieves the app-bound key blob
• main.StartAPPB — initializes the ABE decryption context
• main.decryptAPPB — decrypts credentials using the app-bound key
• main.decryptDataEdge, main.decryptDataBrave — browser-specific variants

This suggests the malware can handle both the legacy DPAPI path and the newer ABE path for Chromium-based browsers.

Defensive Detection

• EDR: non-Chrome process reading Local State with intent to parse JSON and extract app_bound_encrypted_key
• EDR: process invoking Chrome's IElevator COM interface without being Chrome itself
• File integrity: monitor for unauthorized access to Login Data and Local State files

Cross-References

• Observed in: afk-stealer bd6dead7f5a0ec51
• Related: browser-credential-harvesting — cross-family technique page
• Related: chrome-app-bound-encryption-bypass — if a dedicated page exists for this concept