Chrome 148 App-Bound Encryption: How Cookie Theft Just Got Dramatically Harder

## The Architecture Change

Chrome 148 changed how it protects cookies, passwords, and authentication tokens. The shift is subtle but profound.

### Before Chrome 148

```mermaid
sequenceDiagram
    participant Malware
    participant DPAPI
    participant Chrome Storage
    Malware->>DPAPI: Request decryption (running as user)
    DPAPI->>Chrome Storage: Decrypt with user credential
    Chrome Storage-->>Malware: Return all cookies/passwords
```

### After Chrome 148

```mermaid
sequenceDiagram
    participant Malware
    participant Chrome Process
    participant App-Bound Key
    participant Chrome Storage
    Malware->>Chrome Process: Request decryption
    Chrome Process->>App-Bound Key: Verify process signature
    App-Bound Key-->>Malware: Denied (not Chrome.exe)
    Note over Malware,App-Bound Key: Must inject into Chrome process to bypass
```

## Attack Surface Comparison

| Before | After |
|--------|-------|
| DPAPI: any user process can decrypt | App-Bound: only Chrome.exe can decrypt |
| Infostealer: trivial extraction | Requires process injection |
| Zero-day not required | DLL hijacking or CDP needed |

## Bypass Techniques

Current infostealer adaptations:
1. **Process injection**: Inject code into Chrome.exe (requires elevated privileges)
2. **DLL hijacking**: Drop malicious DLL for Chrome to load (more detectable)
3. **CDP extraction**: Connect to Chrome debugging port (Chrome 148+ limits to localhost only)

## What's Next

Chrome v150+ targets hardware-backed key storage (TPM/Secure Enclave). At that point, process injection fails unless attacker controls the TPM. Credential protection is migrating from software to hardware, following the same arc as biometric authentication.

Chrome 148 App-Bound Encryption: How Cookie Theft Just Got Dramatically Harder

// COMMENTS

ON THIS PAGE