typetechniqueconfidencemediumcreated2026-08-08updated2026-08-08credential-accessdefense-evasionbrowser-theftmitre-attckresearch-target

Chrome App-Bound Encryption Bypass

What It Does

Chrome 127+ introduced App-Bound Encryption (ABE) to protect the master encryption key stored in Local State. Unlike legacy DPAPI, ABE binds the key to the browser process identity via a service-specific secret. Malware that previously relied on CryptUnprotectData (which works for any process running as the same user) must now either:

  1. Inject into the browser process and call the browser's own decryption routines
  2. Use a Chrome extension with elevated privileges that can access the ABE key
  3. Extract the app_bound_encrypted_key field from Local State and decrypt it with the correct service identity

This technique page documents the third approach, observed in a standalone harvester DLL.

Detection / Fingerprint

Static indicators of ABE-aware malware:

  • String app_bound_encrypted_key or aster_app_bound_encrypted_key in the binary
  • Debug/log string NO_ABE:Browser uses legacy DPAPI encryption (App-Bound Encryption not enabled) — indicates graceful fallback
  • Debug prefix ASTER_KEY: or similar — developer/project marker for decrypted ABE material
  • BCryptOpenAlgorithmProvider + BCryptGenerateSymmetricKey + BCryptDecrypt imports (CNG AES)
  • CoInitializeEx + CoCreateInstance imports (COM interop for DPAPI fallback)
  • CryptStringToBinaryA import (Base64 decode of the ABE key field)

Implementation Patterns Observed

In sample 9d3d5ac0 (MSVC 14.50 x64 DLL):

  1. Reads Local State JSON from %LOCALAPPDATA%\Google\Chrome\User Data\
  2. Checks for app_bound_encrypted_key field
  3. If present: Base64-decode via CryptStringToBinaryA, then AES-decrypt via bcrypt.dll CNG APIs
  4. If absent or ABE fails: falls back to legacy DPAPI path (CryptUnprotectData via COM)
  5. Uses the recovered master key to decrypt os_crypt.encrypted_key and then browser SQLite databases

Reproduce on Your Own VMs

Not yet fully reproducible — the ABE service identity secret is not publicly documented. To replicate:

  1. Set up a Windows 11/Chrome 127+ VM
  2. Enable ABE in Chrome flags (chrome://flags/#app-bound-encryption)
  3. Save a password in Chrome to generate app_bound_encrypted_key
  4. Build a test tool that:
    • Reads Local State JSON
    • Extracts app_bound_encrypted_key
    • Attempts BCryptDecrypt with various AES modes (CBC, GCM, CCM)
    • Falls back to CryptUnprotectData if ABE fails
  5. Compare behavior against a known ABE-enabled profile

Research target: determine the exact AES mode, key derivation, and service identity binding used by Chrome's ABE implementation.

Defensive Countermeasures

  • Enable ABE in Chrome 127+ (default on for enterprise; consumer rollout ongoing)
  • Monitor for Local State reads by non-browser processes — high signal when combined with SQLite file access
  • Detect app_bound_encrypted_key string presence in non-browser binaries
  • Application Control (WDAC/AppLocker): block unsigned DLLs from loading in browser contexts

Pages Where Observed