Leaked API Key Creates a Tenancy-Wide Policy at 09:12

Order matters because the policy is the exposure.

1. Delete the tmp-ops policy and the group. It grants tenancy-wide manage all-resources, which includes creating further users, keys and policies. Every minute it exists, the attacker can build persistence that survives any later cleanup. This is a single API call and should happen in the first two minutes.
2. Revoke credentials, not the identity. Delete the API signing key, then delete the Customer Secret Key, then delete any auth tokens. These are separate credential types - killing the API key does nothing to the S3-compatible key, which is likely the one in the public commit. Then reset the console password or deactivate interactive login.
3. Preserve evidence. Do not terminate instances or delete the user yet. If a compute instance is implicated, take a boot volume backup before anyone reboots it.
4. Keep the backup running. Create a replacement credential stored in Vault, or run the 02:00 backup manually under a monitored identity; do not restore the old key to unblock a job.

Why not delete the user first. Deletion is irreversible, it destroys an identity you still need to correlate against Audit, and it does not remove what the attacker already created - the policy, the group, or any new principal. Contain the grant, then the credentials, then the identity, once you know the shape of the intrusion.

Everything the attacker created outlives its creator. A policy does not disappear when the principal that wrote it is deleted; a tenancy-wide grant is a standing back door. Check, in this order:

• IAM policies at tenancy root and in every compartment, including ones created after Saturday. Compare against your IaC baseline rather than reading each one.
• Users and credentials in all four identity domains. A policy written in tenancy crosses domain boundaries, so an account parked in a non-default domain inherits it. Enumerating only the Default domain is the classic miss. Check for new users, new API keys, new Customer Secret Keys, OAuth confidential applications and any change to the identity provider or federation trust.
• Dynamic groups and tags. A tag-based rule such as tag.ci.role.value = 'runner' means any instance the attacker launches with that tag inherits rights with no user involved. Audit dynamic group creation and any instance launched in compartments covered by an existing permissive rule.
• Instance principals in practice: look for CreateInstance calls followed by unexpected Object Storage or Vault activity from those instances.
• Data-plane changes: buckets flipped to public, new pre-authenticated requests, Vault key access, exfiltration volume from Object Storage logs.

Also check the S3 compatibility endpoint specifically - the Customer Secret Key is a different control plane from the OCI API, and your SIEM query on OCI Audit calls will not show S3-style requests.

Remove the static credential. Run the nightly backup as a Function or a Compute instance principal in a dedicated compartment, with a policy narrow enough to be boring: Allow dynamic-group backup-writers to manage objects in compartment Fare-Backup where target.bucket.name = 'fare-archive', plus use secret-bundles for the destination credentials. There is then no fingerprint to commit to GitHub. If an S3-compatible endpoint is unavoidable, the Customer Secret Key must live in Vault and be fetched at runtime by the instance principal, never in a repo or a config file.

Detection.

• Events rule on IAM policy create/update/delete, user creation, API key creation and identity provider changes, routed to Notifications and to a Function that pages the SOC out of hours. The Saturday event already fired - the gap was that it was a notification, not an alarm with a runbook.
• Cloud Guard IAM detectors, and extend the reporting region coverage beyond the home region; a tenancy-wide policy is a global object but your visibility is not.
• A SIEM correlation rule that alerts on any policy created by a principal outside the IAM-Admins group, with a two-minute threshold.

Blast radius. Keep workload compartments unable to write IAM at all, so a compromised workload credential cannot escalate - the compromise here became serious only because the stolen identity could create policy.