A leaked SAS key has no user to disable: tapping Event Hub streams

There is no failed logon to chase, because the attacker never signed in as anyone. They are holding a bearer secret, and whoever holds it is the principal.

How the attack works

A shared access signature (SAS) key with the Listen claim for an Event Hub or Service Bus topic leaks from a config file. The attacker authenticates with the key, registers a new consumer group or subscription, and silently reads the live event stream. Because it is a separate consumer group, legitimate processing is unaffected and nothing looks broken. The diagnostic logs attribute the reads to the SAS policy name from a host outside the known consumer set, and the messages may carry tokens, PII, or transaction data that gets shipped out. In ATT&CK terms this is T1552, Unsecured Credentials, paired with T1530, Data from Cloud Storage.

Why it works

A SAS key is a long-lived shared secret that ends up in config files and is passed around widely. There is no user account behind it, so a SOC oriented around failed sign-ins sees nothing, and the read looks like just another legitimate consumer.

How to fix it

You cannot disable a key like a user, so you invalidate it. Regenerate the shared access policy key, which voids every copy including the leaked one at once, then remove the rogue consumer group. There is no user account to disable, and deleting the namespace breaks all legitimate consumers. For the root cause, move consumers to per-identity Entra authorization with RBAC so reads tie to revocable identities, eliminate long-lived shared keys where you can, and store any remainder in Key Vault with short rotation. Remember rotation stops the tap but does not undo what already leaked: treat any intercepted tokens as compromised and revoke them.

Practice it

We built this as a GraphLattice Range scenario so responders can rehearse rotating a leaked SAS key and scoping the interception when the principal is a key, not a person.