You reset a compromised cloud admin, yet privileged API calls continue — what do you hunt in control-plane audit?

## Why the reset did not work Containment on a compromised administrator usually means: reset the password, revoke active sessions, re-enrol the second factor. That closes the interactive path. It does not close anything the intruder created *with* that account while they held it — and control-plane persistence is exactly that: an identity or credential added through the API that lives entirely independently of the human account it was created from. It is worth being precise about what a reset does and does not reach in general. Resetting a password does not by itself invalidate an already-issued refresh token, a Kerberos ticket, or an OAuth consent grant to an application, and it certainly does not invalidate a separately created key or certificate. Each of those is a distinct revocation action. ## The event families to hunt Bound the search to the window from **first confirmed compromise to the reset** — not from the alert, which is usually later — and search the control-plane audit records for creation and credential events performed by the compromised identity, or by anything it created: | Family | What it looks like | | --- | --- | | Long-lived key issued | an access key created for a user or a key generated for a service account | | Credential added to an existing app | a client secret or certificate added to an application or service principal that already existed and is already trusted | | New workload identity | a service account, managed identity or application registration created | | Trust widened | a role's trust policy edited to allow an external account or federated principal to assume it | | Privilege attached | a policy, app role or directory role granted to any of the above | | Consent granted | an application granted broad delegated or application permissions across the tenant | The second row is the nasty one. Creating a new application is conspicuous. Adding one more certificate to an application that fifty services already depend on is a single small update event in a stream of legitimate configuration churn, and after it, the intruder authenticates as an application the organisation itself trusts. ## Why the follow-on activity is invisible to human-focused hunting Once the credential is in use, every audit entry names the workload identity. There is no anomalous person, no impossible geography to reason about, no interactive login to challenge. Non-interactive workload sign-ins are commonly a separate log category from user sign-ins, and the policy controls that gate humans — conditional access, step-up MFA, device compliance — frequently do not apply to them at all. A hunt framed as "what did the compromised user do after the reset" returns nothing, and the SOC concludes containment worked. The pivot that works is to stop hunting the person and hunt the **credential's birth certificate**: enumerate the credentials attached to every privileged workload identity, read their creation timestamps, and treat any credential created inside the compromise window as attacker-controlled until an owner proves otherwise. Most estates have never done this enumeration once, and the exercise finds forgotten legitimate keys as well. ## Ephemerality raises the stakes The host or pipeline the intruder worked from may be long gone. If the credential creation happened from a build agent that was destroyed, or a session inside a container that has restarted, the control-plane record of the create event is the only surviving account of it. That is also the reason the control-plane trail deserves longer retention than most other sources: this class of persistence is routinely discovered weeks after the create event, and a thirty-day window will simply not contain it. ## Eradication, not just containment Removing these is a different action from the reset: - Delete the credential itself — the key, the secret, the certificate — rather than disabling the identity that created it. - Roll back the widened trust relationship and revoke the consent grant. - Revoke outstanding tokens issued to those identities, since deleting a credential does not always expire tokens already minted from it. - Then **watch for re-entry**: build a detection on credential-addition events against privileged workload identities and on first-seen source addresses for those identities, and keep it running past the incident. The eradication claim is only defensible once a period has passed with that watch in place and silent. ## The interview point The strong answer separates the two phases explicitly: the reset was **containment** of one authentication path, and eradication means finding every identity and credential created during attacker control. The weak answer treats the reset as the end of the incident and then explains the continuing activity as a false positive, because the actor now looks like an ordinary application doing ordinary things.