Tapping the event stream: Confluent Cloud API key abuse

A streaming platform moves your events between systems as a live flow. A stolen Confluent Cloud API key lets an attacker join it and read everything published.

How the attack works

The key authenticates from a new host and lists topics and consumer groups. It then creates a new consumer group on a topic carrying customer events and begins reading the live stream, intercepting events including PII as they are published. To widen the tap, the attacker adds an ACL granting the key read access to additional topics. The attacker never breached a database, they subscribed to the data in motion. In ATT&CK terms this is T1552, Unsecured Credentials, with T1530, Data from Cloud Storage, and T1119, Automated Collection, as the consumer reads steadily from the topic.

Why it works

A stream is a standing firehose, and a reader on it sees everything until you cut the key. The API key had broad ACLs across topics and could self-grant more, so a data key could extend its own reach.

How to fix it

The non-obvious move is that you do not pause the producers, because that is a self-inflicted outage and the still-valid key resumes reading as soon as events flow again. Revoke and rotate the API key to drop the rogue consumer’s access, remove the rogue consumer group, and tighten the topic ACLs so the tap cannot be re-established. For the class fix, scope keys to least-privilege per-topic ACLs, separate key management from data access so a key cannot self-grant, and alert on new consumer groups and ACL changes. Scope what was read from the audit log plus consumer-group offsets and consumption metrics over the window.

Practice it

We built this as a GraphLattice Range scenario so teams can rehearse the rogue consumer, the revoke-and-tighten-ACLs containment, and the point that intercepted in-motion PII is exposed data.