Sunday, January 18, 2026

New C4 Hack Shatters Chrome’s AppBound Cookie Encryption

Google’s AppBound Cookie Encryption was meant to shut the door on low-privilege infostealers.

Instead, security researchers have demonstrated a “C4: Chrome Cookie Cipher Cracker” technique that cracks the new protection in hours, not days, and even opens a path to decrypt any SYSTEM-protected DPAPI blob on Windows.

The legacy Chrome model stored encrypted cookies in an SQLite “Cookies” file and safeguarded the decryption key in Local State, itself wrapped by the Windows Data Protection API (DPAPI).

Old cookie protection flow.
Old cookie protection flow

Because both items were encrypted in the same user context, any malware running with that user’s privileges could freely decrypt cookies.

AppBound Encryption changed three things:

  1. Double-wrapping with SYSTEM-DPAPI. Chrome now encrypts the cookie key under the user’s DPAPI and then again under SYSTEM, blocking standard user processes from decrypting it directly.
  2. Elevation service COM server. A SYSTEM service performs all decryption on Chrome’s behalf.
  3. Executable-path validation. The service returns the key only if the requestor’s binary path matches the original Chrome path.

Together, these layers forced attackers to choose between elevating privileges or scraping plaintext cookies from Chrome’s memory.

COM Hijack to Padding-Oracle

Malicious code can register a fake server or simply redirect Chrome to a non-existent DLL; Chrome then falls back to the legacy, easily decrypted method.

The drawback: it only captures cookies generated after the hijack.

The breakthrough came with a deeper look at DPAPI’s use of AES-CBC. Because CBC decrypts each 16-byte block and XORs it with the previous ciphertext, an attacker can tweak bytes in a chosen block and control bits of the next plaintext block—a classic bit-flipping attack.

Bit-flipping attack.
Bit-flipping attack

DPAPI also employs PKCS7 padding. Crucially, Windows logs distinguish between padding errors (“unknown”) and MAC failures (“MAC check failed”).

This discrepancy forms a padding oracle that reveals whether a guessed byte produced valid padding.

By iteratively modifying ciphertext, querying the elevation service, and checking the resulting event log, the team brute-forced each byte of the SYSTEM-encrypted blob.

Once the outer layer was stripped, the remaining user-encrypted blob could be decrypted with a regular CryptUnprotectData call.

Chrome adds one proprietary “post-processing” step—an extra XOR with a hard-coded key—but that, too, was reversed.

Even with modest hardware, the full attack runs in roughly 16 hours. Skipping predictable sections and refining timing measurements could shorten that window further, researchers say.

Beyond Cookies

Researchers first noted that the elevation service is an ordinary COM server, making it susceptible to COM hijacking.

Because the elevation service happily tries to decrypt any DPAPI blob supplied by a low-privileged caller, C4 is not limited to cookies.

The team was able to target Windows Credential Manager entries created by SYSTEM processes, including credentials silently stored by Task Scheduler jobs.

Although abusing Task Scheduler itself would require patient, reboot-per-guess brute-forcing and is therefore impractical, the finding highlights a wider class of vulnerable workflows: any feature that writes SYSTEM-protected secrets yet exposes a user-triggerable decryption path.

Google and Microsoft were notified under responsible-disclosure policies. While Google can revise Chrome’s elevation service, the episode underscores a broader lesson:

 Windows Credential Manager.
 Windows Credential Manager

AES-CBC with predictable error channels remains fertile ground for padding-oracle attacks, and bolting new trust models onto legacy crypto is fraught with side effects.

For defenders, the immediate mitigations are standard: monitor for suspicious COM registration changes, restrict write access to HKCU/HKCR, and audit event logs for repeated DPAPI padding errors.

Longer term, vendors may need to follow TLS’s lead and retire CBC-based schemes in favor of authenticated encryption modes that eliminate padding oracles altogether.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.

Ethan Brooks
Ethan Brooks
Ethan Brooks is a Senior cybersecurity journalist passionate about threat intelligence and data privacy. His work highlights cyber attacks, hacking, security culture, and cybercrime with The Cyber News.

Recent News

Recent News