13.5 Basic Cloud Incident Reporting and Support Steps
Detect: Trust the Anomaly, Not Your Memory
Most personal cloud incidents surface as three signals: a sign-in alert for a device or city you do not recognize, mail or files you did not send or share, and a sudden spike of storage or version activity. Confirm fast and cheaply -- open the session map and audit feed from a known-clean device, and do not dismiss "maybe it was my phone." Log the UTC timestamps of the first and latest suspicious event; you will need that window for everything downstream, and provider log retention is short.
Contain: Lock the Account Before You Investigate
Containment order matters. Sign out everywhere, which revokes session and refresh-token grants at the identity provider; change the password, which invalidates remaining sessions server-side; revoke connected-app tokens; then rotate your second factor if the attacker could see it. Pause sync clients on machines you suspect are infected, otherwise a keyed-out device immediately re-authenticates and re-seeds the compromise. Check the one thing attackers change first: recovery email and phone. If your recovery contacts are wrong, you are racing whoever changed them -- tell the provider immediately.
Report Through Channels You Can Prove
Use the in-product security flow or verified support number, never a support link found in an email that arrived during the incident. State the facts in machine-checkable form: affected account, event window in UTC, which controls you already changed, and a request to preserve logs and enable lockdown on the mailbox while you recover. Ask for a case reference and enable every alert. If mail or files were exfiltrated, notify the people whose data was exposed -- their inboxes are now your second incident.
Recover: Restore, Then Hunt the Persistence
Use version history or snapshots to roll files back, but before declaring victory, look for persistence the attacker left behind: mail rules forwarding to a stranger, filters deleting your alert mail, new share links, re-added devices, and re-granted OAuth apps. Restore without hunting persistence just replays the incident a week later.
Architecture Diagram
Key Takeaways
- Confirm anomalies from a clean device and record a UTC event window before provider logs expire.
- Contain in order: sign out everywhere, change password, revoke app tokens, rotate second factors, pause suspect sync clients.
- Verify recovery email and phone first -- attackers change them to win the lockout race.
- Report only through in-product or independently verified support channels, and request log preservation plus a case ID.
- After restoring from snapshots, hunt persistence: forwarding rules, deleted alerts, new links, devices, and OAuth grants.