pass-ta-key is a proof-of-concept demonstrating that Chrome's synced Google Password Manager passkeys can be decrypted once the Security Domain Secret leaks from process memory, built for authorized research.
| Tool | 0rcruxe/pass-ta-key — PoC for the Pass-ta-key Golden Attack: extracting GPM's Security Domain Secret from Chrome memory and decrypting synced passkey private keys |
| Category | Credential research / memory forensics PoC (C extractor + Python parser) |
| Primary Use | Demonstrating an architectural weakness in how Google Password Manager protects synced WebAuthn passkeys, by locating the SDS in Chrome memory and decrypting ECDSA P-256 keys from local LevelDB data |
| Safe Use | Educational and research purposes only, on systems you own or have explicit written permission to examine — red-team labs, defensive research, and vendor hardening work |
| Telemetry Note | The extractor opens the Chrome process for memory scanning, watches TCP connections to the enclave endpoint (enclave.ua5v.com), and manipulates the passkey_enclave_state file — all observable via process-access auditing, EDR memory-read alerts, and file monitoring on the profile directory |
pass-ta-key is a research proof-of-concept from 0rcruxe that demonstrates what the author calls the Pass-ta-key Golden Attack: a chain that recovers the Security Domain Secret (SDS) protecting Google Password Manager (GPM) synced passkeys, then uses it to decrypt the ECDSA P-256 private keys stored locally by Chrome. The repo is deliberately split into two components — a Windows memory scanner written in C and a Python parser/decryptor — mirroring the two halves of the problem: a transient secret that only exists in memory during device onboarding, and a persistent encrypted blob that survives on disk in the profile's LevelDB store. The README is explicit that this is a PoC for an architectural flaw, and it claims all Chrome release channels (Stable, Beta, Dev, Canary) are affected because the weakness is structural rather than a version-specific bug.
The first component, sds_extractor.c, is a MinGW-compiled native binary that scans the live Chrome process for CBOR-encoded buffers belonging to the passkey enclave protocol. What the README's example output reveals is genuinely instructive: the SDS appears in memory adjacent to identifiable CBOR map keys such as keys/wrap and passkeys/assert, embedded in structures that also carry a literal security domain secret label. The scanner works in timed passes — the log shows roughly a hundred sweeps over eleven hundred memory regions over about ten seconds — and it keys on those pattern markers to bracket the 32-byte secret. That is a classic pattern-scanning approach, not an exploit of a memory-safety bug; the vulnerability is that the wrapping secret transits process memory in a recoverable form at all.
Timing matters here, and the README is candid about it. The SDS is captured during device onboarding to the enclave security domain, which means the operator must trigger a passkey authentication — login or registration — so that Chrome performs the registration handshake and the secret is momentarily resident. The extractor correlates this with network activity: it resolves the enclave endpoint (shown in the log as enclave.ua5v.com) and watches for new TCP connections to that address as a signal that the interesting handshake is underway, then starts scanning. It also deletes and watches for the recreation of the passkey_enclave_state file as a second synchronization cue. This dependency on a live onboarding event is a meaningful operational constraint, and it is also the most useful detection signal for defenders.
The second component, passkey_extractor.py, is the quieter but arguably more interesting half. It parses the LevelDB database under /Sync Data/LevelDB inside a Chrome profile, extracts the WebauthnCredentialSpecifics records — the protobuf-serialized per-credential entries GPM syncs — and then decrypts the private key blob using the previously captured SDS. The repo ships the schema as webauthn_credential_specifics.proto, precompiled into webauthn_credential_specifics_pb2.py, so no protoc toolchain is needed. Installation for this half is just dependencies: pip install -r requirements.txt.
The Python tool exposes two subcommands: extract, which walks a LevelDB directory (--leveldb-dir) and dumps blobs plus metadata to an output directory, and decrypt, which takes one of the encrypted blobs (enc_<id>.bin), a 64-hex-character --sds value, and writes out the recovered ECDSA P-256 private key. The clean separation between extraction and decryption is good research hygiene: it lets analysts inspect the on-disk artifacts independently of the memory-capture step, which is exactly how a defensive researcher would want to audit what GPM persists locally on a managed endpoint.
The name of the attack is a deliberate nod to Kerberos golden-ticket tradecraft, and the analogy is apt in one specific way: once the SDS is recovered, it functions as a durable master secret for the synced passkey corpus rather than a per-credential crack. Because GPM passkeys are synced across a Google account's devices, the decrypted ECDSA P-256 keys are the account-wide credential material, not a single-machine artifact. The author's accompanying technical writeup (linked from the README at hxxps://0rcruxe.github.io/posts/pass-ta-key-golden-attack-sds-extraction/) covers the full analysis and is the right primary reading for anyone evaluating severity.
For defenders, the detection surface is broader than it might first appear. The C extractor must open the Chrome process with memory-read access and enumerate over a thousand regions in a loop — behavior that endpoint detection platforms already flag as suspicious cross-process access. It initializes Winsock and resolves the enclave hostname, produces network telemetry even before any authentication happens, and it deletes a known state file (passkey_enclave_state) inside the profile directory, which is a high-fidelity file-audit trigger. On the persistence side, defenders should understand that LevelDB sync data containing encrypted passkey material leaves every synced Chrome profile as a loot target; inventorying and protecting /Sync Data/LevelDB is a reasonable hardening conversation regardless of this specific PoC.
The licensing and metadata round out the picture: the repo is MIT-licensed, written in C, tagged with topics like security-research, offensive-security, credential-extraction, and chrome, and carries an in-README warning that it is for educational and research purposes on systems you own or have explicit permission to examine. The build line for the extractor is a standard cross-compile with x86_64-w64-mingw32-gcc against ws2_32 and iphlpapi, statically linked — consistent with a self-contained research binary rather than a distributed toolchain.
Where this sits in an authorized workflow is narrow and well-defined: adversary-simulation teams demonstrating the impact of endpoint compromise on passwordless authentication, and product security researchers evaluating whether vendor sync designs keep wrapping secrets out of long-lived process memory. The architectural takeaway — that any secret material enough to decrypt synced credentials will eventually be a memory-scraping target — applies well beyond Chrome, and pass-ta-key is a compact, readable demonstration of that principle rather than a turnkey attack framework. Teams running phishing-resistant authentication should treat it as a prompt to ask their vendors where the equivalent domain secret lives and for how long.
0rcruxe/pass-ta-key.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.