Stripe restricted key abuse: refund fraud plus a quiet PII scrape
A leaked Stripe restricted key with refund-write and customer-read issues fraudulent refunds and scrapes customer PII. You roll the key, cap refunds, and treat it as loss plus a data exposure.
A Stripe restricted key is a non-human principal that can move money and read customer data. When a key labeled restricted actually carries both refund-write and customer-read, and it leaks, there is no finance employee to lock and no approval step in the path.
How the attack works
The key is used from an IP and ASN not seen for the account, with a non-standard user agent. It issues a rapid series of refunds on recent charges, several routed to a payment method that differs from the original, then paginates the Customers and PaymentIntents APIs to read names, emails, billing addresses, and last-4 card data. Tens of refunds clear before alerting fires, and a customer PII export is reconstructed from the read pattern. In ATT&CK terms this is T1078, Valid Accounts, with T1657, Financial Theft, T1213, Data from Information Repositories, and T1552 for the leaked credential.
Why it works
Refund volume and API-issued refunds are normal operations. The fraud signal is refunds going to a destination that differs from the original payment method, paired with concurrent bulk customer reads. An over-broad restricted key combining refund-write and customer-read, stored in shared config, is the root cause.
How to fix it
Roll the restricted key, which revokes and regenerates it instantly, then apply temporary refund limits while you reconcile the fraudulent refunds for reversal. Suspending an employee or changing the account password does not invalidate a standalone key. Scope both the loss and the exact records read from Stripe Events and the API request logs filtered to the key. For the class, minimize each key’s permissions, separate read-only from refund-write, vault secrets, allowlist IPs on keys, and add refund-velocity and destination-anomaly alerts. Frame it as financial loss and a regulated-data exposure, with PCI-DSS in play.
Practice it
We built this as a GraphLattice Range scenario so responders can rehearse rolling the key, capping refunds, and scoping the dual financial and data impact.