The Chrome Cookie Cipher Cracker: How C4 Blasted a Hole in Google’s Cookie Security

In 2024, Google launched AppBound Cookie Encryption—an ambitious attempt to thwart the rising tide of infostealer malware targeting Chrome cookies. By layering in SYSTEM-level encryption and adding strict path validation, it promised to finally shut the door on low-privileged malware exfiltrating session data. But like many innovations in cybersecurity, a clever adversary—or in this case, a clever researcher—found a way back in.

CyberArk Labs has just detonated what might be Chrome’s most sophisticated cookie defense yet. The weapon of choice? A novel attack dubbed C4, short for Chrome Cookie Cipher Cracker—and yes, it’s as explosive as the name suggests.

“It shows that when trying to use old features, especially security features, in a new way, one can often end up with unintended problems,” Novick notes in his technical disclosure.

The Death of Cookie Stealing, Briefly

To understand the significance of C4, it's worth revisiting what Google was trying to solve. Traditionally, Chrome stored encrypted cookies in a local SQLite database, with the decryption key protected by Windows’ Data Protection API (DPAPI). While this added some resistance to offline theft, infostealers simply exploited the fact that DPAPI decryption is possible for any process running in the same user context. In short, if the malware had the user’s rights, it had the user’s cookies.

Google’s answer was elegant but intricate. By wrapping the encryption key in both User-DPAPI and SYSTEM-DPAPI, and outsourcing decryption to a privileged elevation service, Chrome created a wall between low-privileged malware and decrypted cookie data. Further, it validated that only requests coming from Chrome itself (by checking the path of the binary) would succeed.

That last part—the path validation—would become C4’s entry point.

Hijacking Trust, One COM Object at a Time

C4 wasn’t built in a day. Novick and his team approached Chrome’s architecture like a lock-picking puzzle, probing for assumptions. The first attack vector? COM hijacking.

Chrome communicates with its SYSTEM-run decryption helper via Microsoft’s Component Object Model (COM), a legacy mechanism that’s seen more than its share of abuse. By modifying registry entries, attackers can redirect COM requests to their own binaries or even dummy endpoints.

In this case, Novick discovered that if Chrome can’t find the elevation service, it quietly falls back to its older, vulnerable encryption model. That means a well-placed registry tweak could convince Chrome to encrypt cookies in the old way again—leaving the door open for patient malware to collect them later.

But C4 wasn’t satisfied with a passive approach.

The Padding Oracle Payload

The real breakthrough came from turning the very thing that secured Chrome—DPAPI—into a vulnerability. DPAPI relies on AES encryption in CBC mode, a well-known standard with a problematic history. CBC is notoriously susceptible to padding oracle attacks—a class of side-channel exploit that reveals plaintext through subtle differences in error messages when decrypting manipulated ciphertext.

C4 leveraged this by feeding tampered encrypted cookie blobs into Chrome’s elevation service and watching how Windows’ Event Viewer responded. By analyzing whether the error was a padding failure or a signature mismatch, Novick had himself a live oracle—one that could, byte by byte, decrypt SYSTEM-level DPAPI data.

After hours of automated guessing and careful brute-forcing, C4 peeled off the SYSTEM encryption layer, then used standard user-level decryption to finish the job. What Chrome had designed to be readable only by a SYSTEM-trusted binary could now be cracked by a low-privileged user. Cookie theft was back on the table.

Not Just Cookies

The implications go far beyond session tokens. Any blob encrypted with SYSTEM-DPAPI—and there are plenty across Windows—could be targeted with a variation of the C4 attack.

In one particularly curious case, Novick’s team used C4 to extract an obscure XML token stored by the Windows Credential Manager. While the credentials appeared to be tied to the defunct passport.net domain, they served as proof of concept: Chrome isn’t the only program delegating encryption to SYSTEM-level DPAPI, and any similar setup could be just as vulnerable.

Industry Response: Slow But Aware

Google acknowledged the vulnerability in late 2024 and began working on a fix. As of late June 2025, a partial mitigation exists in Chrome—but it remains disabled by default. Microsoft, meanwhile, rejected the issue entirely, stating it didn’t meet the bar for a security fix due to “environmental constraints” and low exploitability in the wild.

That leaves a lingering question: If SYSTEM-DPAPI blobs can be cracked with enough time and log-watching, is CBC encryption still safe?

“Considering the issues that come with the encryption mode, perhaps it’s time to start considering CBC insecure and abandon it,” Novick concludes.

That sentiment echoes the broader industry trend. CBC has already been deprecated in TLS after attacks like POODLE and BEAST showed how vulnerable it could be in real-world applications. Now, C4 may be remembered as the next acronym that hastened CBC’s demise.

What’s Next?

The story of C4 is less about a single bug and more about systemic design debt. It’s a cautionary tale of what happens when modern security goals collide with legacy infrastructure—especially in a browser like Chrome that must straddle enterprise control and consumer convenience.

As for infostealers, many had shifted tactics long before C4—harvesting cookies directly from memory or abusing elevated privileges. But for malware authors and defenders alike, the existence of a low-privileged, SYSTEM-decrypting attack vector is a game-changer.

Security researchers will be watching closely to see how Google retools Chrome’s architecture in future releases. Meanwhile, for defenders, the message is clear: don’t assume encryption means immunity—especially when the locks are made of legacy code.