Playbook: First 4 Hours of OneDrive or Drive Ransomware
When endpoint malware is encrypting a synced OneDrive or Google Drive folder: isolate the PC, stop the cloud copy from updating, then restore from version history or Recycle Bin to a side path.
- Unplug or pause sync before you restore — a live client will re-upload ciphertext.
- This is an identity and endpoint incident as well as a file incident.
- Version history and Recycle Bin can still win in the first hours; Takeout will not.
- Restore to a side path. Never restore onto the infected sync root.
When to use this playbook
Trigger: files gaining strange extensions, ransom notes, or a sync client pushing a wave of changes across OneDrive, SharePoint, or Google Drive. If files are merely missing with no encryption, start with mass delete and sync conflict first.
Severity and who owns it
P1. Split ownership immediately: identity (sessions, MFA, admin) and data (pause sync, versions, restore). Do not wait for a war-room name before unplugging the laptop.
Minutes 0–15: isolate
- Disconnect the suspect PC from the network (cable and Wi-Fi). Pausing the sync app is second best; unplug is first.
- Do not log that PC into other cloud accounts “to check.”
- From a clean browser (another machine), sign in as admin. Revoke the user’s sessions and app passwords. Reset the password.
- If a privileged account was on that PC, treat tenant admins as possibly stolen. Break-glass account only.
- Tell the company: do not open attachments from the victim; do not empty Recycle Bin or Drive Trash.
Minutes 15–60: stop the cloud bleed
- Confirm in the web UI whether ciphertext has already replaced live files.
- OneDrive/SharePoint: version history on a sample of files. Restore a version from before the encryption wave to a side library or local folder that is not synced.
- Google Drive: version list on binaries; Docs may still have earlier revisions.
- If the wave is still landing, remove the user’s Drive/OneDrive app access and unsync devices in the admin console.
- Do not restore into the original sync root while any infected endpoint is still linked.
Hours 1–4: restore a slice, then widen
- Pick one critical folder. Restore pre-encryption versions or Recycle Bin items to
restore-incident-YYYYMMDD. - Open real files (PDF, Office). If they open, you have a path. If they do not, stop and try an independent backup copy — not a bigger restore of garbage.
- Only then restore additional folders the same way.
- Rebuild the user’s PC from known-good media. Do not “clean” and reconnect the same disk to sync.
- Start a timeline for legal/insurer: first encrypted timestamp, accounts revoked, what was restored.
Day 2
Hunt forwarding rules, OAuth apps, and other devices. Re-enable sync for that user only after the new PC is clean and the cloud copies are verified. Run a small restore drill on a second workload so the rest of the tenant is not a surprise.
Background on why sync is the blast radius: ransomware and cloud accounts.
Do / don’t
| Do | Don’t |
|---|---|
| Unplug the endpoint | Keep sync running “so we can watch it” |
| Restore versions to a side path | Overwrite the live library from the infected PC |
| Revoke tokens | Start Takeout as the first restore tool |
| Sample-open files | Announce all-clear because the job bar finished |
What to tell the business
A PC is isolated. Do not pay, decrypt, or empty Trash. Do not reconnect OneDrive/Drive until IT says so. We are restoring from cloud versions or backups to a holding area, not from the infected laptop.
Exit criteria
No infected endpoint still syncing; sample restored files open; sessions revoked; a written timestamp of first encryption and first good restore. If versions and recycle are already gone, escalate to native recovery over.
Index of all runbooks: incident playbooks.
