Vultr Root Account Compromise Playbook

​

Indicators

• Unexpected Vultr billing alerts or service activations (new region active, large compute or storage spin-up).
• Failed-login alerts on the Vultr account email (Microsoft 365 sign-in alerts) — the master-account email is on a dedicated, MFA-protected mailbox owned by the CTO.
• An MFA reset or password-recovery email on the Vultr master account that nobody on the team initiated.
• A leaked or pasted Vultr API key surfacing on paste sites, public repos, or vendor secret-scanners.
• A Vultr support ticket or unsolicited contact about activity neither the CTO nor the CISO authorized.
• Anomalous sign-in alerts from Vultr (unfamiliar IP, geo, or user-agent).

​

Roles

​

Steps

​

1. Page the IR team

​

2. Open Vultr support and abuse cases

​

3. Lock the master credential — if and only if the master password and MFA device are still under Neuroscale’s exclusive control

• Sign in as the master account from a known-clean device (not the one suspected of compromise).
• Rotate the master password to a new credential generated in Dashlane and stored in the CISO’s vault.
• Replace the master MFA device with a fresh hardware token.
• Revoke any active sessions in the Vultr customer portal session-management view.
• Sign out and verify.

​

4. Assume identity loss; revoke and rotate

• API keys — disable all Vultr API keys via the customer portal (or via a privileged API key held in a separate, uncompromised vault). If no clean API key exists, this is done by Vultr Support during recovery.
• Sub-accounts — review the Vultr sub-account list and revoke any unrecognized accounts; rotate credentials on every legitimate sub-account.
• Cross-cloud secrets — rotate every Vault auth credential used by Vultr-hosted workloads (Kubernetes service-account tokens for VKE-side Vault auth, AppRole secret_ids for Cloud-Compute-side Vault auth, and any bootstrap credentials provisioned through Vultr instance metadata / VKE secrets per Secrets Management → Cross-cloud bootstrap). Vultr master compromise potentially exposes those bootstrap credentials; treat them as compromised. Where a Vultr-hosted workload had a Vault token cached, revoke the token via Vault’s audit log review.
• Force re-authentication across SSO and revoke active sessions on services that authenticate Vultr-side users.
• Rotate any third-party tokens that grant Vultr access (CI/CD secrets, deploy keys, GitHub OIDC trust relationships pointing at Vultr).
• Application-layer keys — rotate or destroy the Vault Transit keys that wrapped any Vultr-resident Confidential data, if there is any signal that the attacker accessed wrapped ciphertext (cryptographic erase). Vault Transit is the application-layer envelope surface for both clouds; the keys live inside the Neuroscale-operated Vault cluster, so a Vault host compromise (escalated from the Vultr master compromise) is the realistic attack path here. Where AWS KMS CMKs were used for cloud-native at-rest encryption of any AWS-resident copies of the same data, also schedule those for destruction. Coordinate with the AWS Root Account Compromise Playbook where the same keys are referenced.
• Vault host integrity — because Vault runs on Vultr, the master compromise potentially touches the Vault cluster itself. Inspect Vault audit-device logs (forwarded to Better Stack and replicated to AWS S3 Object Lock — those copies are out-of-band and trustworthy), check for unauthorized policy changes, unsealing events, root-token issuance, or new auth-method registrations. If any tampering is suspected, revoke all Vault tokens, rotate all Vault encryption keys, and re-seal the cluster — restore from the most recent verified Vault snapshot. Where the Vultr-side recovery window is long, stand up an emergency Vault cluster on AWS Cloud Compute from the AWS S3 Object Lock snapshot (per the RTO / RPO Matrix) and cut workload auth over to it.

​

5. Contain blast radius

• Snapshot suspect Vultr resources before changes for forensic analysis (Cloud Compute snapshots, Bare Metal disk images, Block Storage snapshots, Object Storage object versions).
• Detach firewall rules from suspect resources; do not delete the resources until forensic capture is done.
• Review Vultr API audit logs, VKE control-plane logs, and Postgres audit logs from Vultr-hosted instances for the time window from the earliest indicator forward — note resource creations, key changes, object reads, and database connections.
• 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

​

7. Customer communication

​

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)

• Vultr master account email is on a dedicated, MFA-protected mailbox owned by the CTO.
• Master credentials are stored in Dashlane (CISO + CTO only).
• Hardware MFA on the Vultr master account.
• API keys for Vultr are scoped (no master-equivalent API key in routine operations); keys are rotated annually and on personnel change.
• Vultr sub-accounts are used for separation of duties wherever supported by the Vultr plan.
• Vultr Firewall + Vultr DDoS Protection are always-on at the Vultr edge.
• Cross-cloud DR — production workloads designed for cross-cloud failover can run from AWS during a Vultr-side recovery window.

​

Cross-references

• Incident Response Plan
• AWS Root Account Compromise Playbook
• Cryptography Policy
• Secrets Management
• Customer Communications
• RTO / RPO Matrix

​

Version history