Referenced from the Incident Response Plan → Root account compromise. Treat AWS root compromise as a P0 incident — it is the highest-impact category Neuroscale faces because it confers full control over every customer-affecting system.
If you suspect root compromise: do not log in as root to “verify.” Use the steps below in order. Logging in may alert the attacker and burn your only out-of-band signal.
Indicators
Any one of the following triggers this playbook:
- Unexpected AWS billing alerts or service activations (e.g., a new region becomes active, large EC2 spin-up, GuardDuty findings against root identity).
- Failed-login alerts on the root email (Microsoft 365 sign-in alerts).
- An MFA reset or recovery email on the root account that nobody on the team initiated.
- IAM access-key leak with
root principal.
- A vendor or auditor reports finding the root credential externally (paste sites, public repos).
Roles
| Role | Action |
|---|
| Incident Manager | CTO or CISO — designates IR lead immediately. |
| AWS escalation | CTO contacts AWS Trust & Safety / TAM via the entitled support plan; reference Key Contacts. |
| Legal / breach assessment | General Counsel — determines breach-notification obligations under GDPR, state laws, customer DPAs. |
| Comms | CEO + CISO approve any external statement. |
Steps
1. Page the IR team
Email security@neuroscale.ai AND page on-call via Better Stack AND Slack #security-incidents. Do not discuss in any channel that depends on AWS-hosted infrastructure (e.g., a self-hosted chat). Use Slack and cell phones.
2. Open AWS support and Trust & Safety cases
The CTO or CISO calls AWS support (entitled tier) and opens a case as “Account compromise — root identity.” Provide the account ID and the timeline of indicators.
3. Lock the root credential — if and only if the root password and MFA device are still under Neuroscale’s exclusive control
- Sign in as root from a known-clean device (not the one suspected of compromise).
- Rotate the root password to a new credential generated in Dashlane and stored in the CISO’s vault.
- Replace the root MFA device with a fresh hardware token.
- Sign out and verify.
If the attacker has already changed the password or MFA, stop and proceed to step 4. AWS Trust & Safety leads recovery from this point.
4. Assume identity loss; revoke and rotate
- Disable all root access keys (
aws iam delete-access-key from a privileged IAM role; if no IAM role retains permissions, this is done by AWS support during recovery).
- Rotate all IAM user credentials and access keys, prioritized by privilege.
- Rotate KMS-managed customer master keys if there is any signal that the attacker accessed key material.
- Force re-authentication across SSO (AWS IAM Identity Center / Rippling) and revoke active sessions.
- Rotate any third-party tokens that grant AWS access (CI/CD secrets, deploy keys, GitHub OIDC trust relationships).
5. Contain blast radius
- Snapshot suspect resources before changes for forensic analysis.
- Detach IAM policies from suspect roles; do not delete the roles until forensic capture is done.
- Review CloudTrail (read-only role) for the time window from the earliest indicator forward — note resource creations, IAM changes, S3 access, KMS key usage.
- If customer data was accessed, preserve evidence and engage the General Counsel for breach assessment per Incident Response → External communications and breach reporting.
6. Restore service
Restore from known-good infrastructure-as-code in neuroscale/infrastructure (or equivalent). Stand up replacements for any resources of unverified integrity. Cut over only after the IR team confirms no residual attacker presence.
7. Customer communication
Per Customer Communications and Incident Response → Breach notification timing matrix. Do not communicate before Legal has assessed obligations. The shortest applicable contractual window governs.
8. Post-incident
- Forensic report — CISO + CTO co-author within 5 business days.
- RCA via the RCA intake within 10 business days.
- Update this playbook with lessons learned.
Preventive controls (already in place)
- Root account email is on a dedicated, MFA-protected mailbox owned by the CTO.
- Root credentials are stored in Dashlane (CISO + CTO only).
- Hardware MFA on root.
- No root access keys exist in normal operations.
- AWS Organizations Service Control Policies block root usage on member accounts.
- GuardDuty + CloudTrail alerts on root login and IAM changes.
Cross-references
Version history
| Version | Date | Description | Author | Approved by |
|---|
| 1.0 | May 8, 2026 | Initial version | Cameron Wolfe | Ishan Jadhwani |
