The Cosmos DB key that walks straight past Entra RBAC

A Cosmos DB account key is not just a password. It is a data-plane master credential, and a leaked one reads your data while leaving the identity layer none the wiser.

How the attack works

An AccountEndpoint and AccountKey connection string gets committed to a shared config repo. That key grants full NoSQL read and write directly against the account and bypasses Entra ID RBAC, conditional access, and the control-plane audit story completely. The attacker uses it from an unexpected network, and Entra sign-in logs show nothing because key auth never touches Entra. The activity appears only in the Cosmos DB DataPlaneRequests diagnostic log: master-key requests from an IP outside the app subnet, then ReadFeed and Query operations enumerating a customer-profile container end to end, then enumeration of the other databases and containers in the account. This maps to T1552, Unsecured Credentials, and T1530, Data from Cloud Storage.

Why it works

The key is a static master credential that authenticates straight to the data plane. There is no user session to disable and no conditional access in the path, so a single leaked string is full access from anywhere.

How to fix it

An IP allowlist does not invalidate a stolen key, and disabling the subscription owner does nothing to a data-plane credential. The key is the identity, so you must rotate it, and you rotate both the primary and the secondary, because the secondary grants identical access and an attacker who saw one config may hold both. The durable fix is to move the application to Entra token authentication with Cosmos DB data-plane RBAC and then disable key-based auth on the account entirely, so a future leaked key is simply rejected.

Practice it

We built this as a GraphLattice Range scenario so responders learn why you rotate both keys and then disable key auth for good.