The First 24 Hours: What Happens When Ransomware Lands

What it is

A structured hour-by-hour runbook for the first 24 hours of a ransomware incident, written by UnderDefense CEO Nazar Tymoshyk, with specific decision points, diagnostic checks, and a staged recovery order the summary doesn't capture.

How it works

The page breaks the first day into distinct windows, each with a governing question and a specific action, not just a topic:

• Hours 0-1 (confirm): distinguish real ransomware from a failed backup job or broken sync client by checking whether the ransom note is on more than one host, whether the file extension change is cross-share or single-workstation, and whether EDR shows mass file modification by a single process.
• Hours 1-2 (contain): act on the VPN-without-MFA vector first, since closing it is simultaneously containment and root-cause remediation.
• Hours 2-4 (exfiltration): hunt by volume and destination, not signature — a single host pushing tens of GB to a consumer cloud endpoint over a weekend is the pattern, since the tools involved (FileZilla, WinSCP, RClone, Mega, Ngrok) are legitimate software admins already run.
• Hours 3-6 (backups): before quoting a recovery time, restore one real file and open it, verify the backup server doesn't authenticate against the domain being rebuilt, confirm immutability/object lock is active, find the last tested full restore, and identify non-domain credentials for the backup console.
• Hours 8-16 (root cause): identity investigation gates the rebuild — determine which account was used first (person vs. service), whether MFA was absent/bypassed/token-stolen, what that account touched in the prior 30 days, whether DC logs still cover that window, and which service-account passwords predate the intrusion and can't rotate without an outage.
• Hours 16-24 (recovery): rebuild identity first into a clean, isolated domain controller before restoring anything else, since restoring a compromised system in place preserves the attacker's persistence mechanism.

Preconditions / Affected

Applies to any organization with VPN remote access lacking MFA (named as a primary access vector in CISA's Akira advisory), shared backup infrastructure authenticating against the production domain, and no pre-named incident decision authority.

What to do

Three concrete actions the author recommends doing this week, not during an incident:

• Restore a file from the newest backup and time it.
• Write three named people and three deputies into the IR plan's decision section (covering who approves ransom engagement, communication, and sign-off — stated as three separate roles).
• Verify every remote access path enforces MFA today.

Also: run a tabletop exercise on a Friday at 17:00 with the actual people who'd be on that call.

Caveats

The hour markers are explicitly approximate and the order is not fixed — the author frames this as the shape of engagements he's observed in food production, business services, and retail, not a universal timeline.