AWS root account compromise: what does it reveal about IAM controls?

TL;DR: A former maintainer retained unrotated shared AWS root credentials in Ruby Central’s vault, then used them for an unauthorized login that briefly seized full administrative control and disrupted services, according to Unosecur. The incident shows how offboarding failures and shared privileged access can turn one stale credential into environment-wide risk.

NHIMG editorial — based on content published by Unosecur: AWS Root Account Compromise: Insider Misuse Exposes Credential Hygiene Gaps

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

Questions worth separating out

Q: What breaks when a former employee still has access to shared cloud root credentials?

A: Offboarding no longer removes authority, so a departed operator can re-enter production through a credential the organisation still trusts.

Q: Why do shared privileged credentials increase cloud breach impact?

A: Shared privileged credentials collapse multiple responsibilities into one secret, so compromise affects administration, detection, and automation at the same time.

Q: What do security teams get wrong about root account protection?

A: They often treat root protection as a password problem when it is really a governance problem.

Practitioner guidance

• Revoke and replace shared root credentials immediately Replace every shared AWS root secret with a fresh credential pair, verify vault entries, and confirm that no downstream system still references the old value.
• Restrict root use to documented break-glass events Remove routine operational dependence on the root account, require explicit approval for use, and maintain a separate path for emergency administration.
• Tie offboarding to privileged secret invalidation Make leaver processing trigger revocation of vault-held secrets, cloud console access, and any linked SaaS or CI/CD integrations before the exit record closes.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step account of the AWS root login sequence and the observed IP geographies.
• The specific remediation checklist for root account hardening, including MFA and IAM review actions.
• The incident timeline showing how production services and integrations were affected.
• The article's own guidance on monitoring signals such as password resets, policy changes, and unusual logins.

👉 Read Unosecur's analysis of the AWS root account compromise and offboarding failure →

AWS root account compromise: what does it reveal about IAM controls?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →