Key takeaways:
Encryption is the last step of the intrusion. Mandiant's M-Trends 2026 puts the global median dwell time at 14 days, so hour zero for you is usually week two for them.
Assume the data left before the files are locked. CISA's Akira advisory records cases where exfiltration was complete two hours after the attacker got in.
Restore something from a backup before anyone gives the board a recovery time. Ransomware crews now hunt backup infrastructure on purpose.
Most first-day failures are decision failures. The technical steps are written down somewhere. The authority to take them usually is not.
The first report rarely comes from a detection rule. It comes from a shift supervisor who can't open the production schedule, or from a finance clerk who found a text file on the shared drive with payment instructions in it.
By the time that call reaches you, the part of the attack you can still influence has already started. What follows is the shape of a first day, hour by hour, as I have watched it run in ransomware engagements across food production, business services and retail. The hour markers are approximate. The order is not.
Hour 0: The clock started long before you noticed
The most useful thing to establish in the first ten minutes is when this began, and the answer is almost never today.
Mandiant's M-Trends 2026, published in March 2026 and built on over 500,000 hours of frontline investigations, reports global median dwell time rose to 14 days from 11.
A second finding in that report changes how you scope the day. In 2022, the median gap between an initial access event and the hand-off to a second threat group was more than eight hours. By 2025 it had collapsed to 22 seconds.
The practical consequence: the crew encrypting your files is often not the crew that broke in. You are reconstructing two sets of activity with different tooling and different goals, and the quiet one came first.
Hours 0 to 1: Confirm it before you say the word
Saying "ransomware" out loud starts a chain of calls you can't unmake, so the first hour buys certainty. Check whether the ransom note sits on more than one host, whether a file extension changed across a share or only on one workstation, and whether your endpoint detection and response (EDR) shows mass file modification by a single process.
A failed backup job and a broken sync client both look like this from a help desk ticket, and calling it wrong costs you credibility you'll need later.
Getting it wrong in the other direction costs more. In one engagement UnderDefense's responders were called into, the ransomware had already reached 22 hypervisors by the time anyone picked up the phone. The signal had arrived as a handful of unremarkable alerts spread across a week.
So scope by blast radius: one endpoint, a file share, a domain controller, the virtualization layer. Each step up that list closes off decisions in the next section.
Hours one to two: Containment choices you can't take back
Hour one decides most of the rest. Every containment action buys something and destroys something, and the trade is rarely written anywhere your night-shift engineer can find at 03:00.
Action | What it stops | What it costs you | Choose it when |
|---|---|---|---|
Network-isolate the host from the EDR console | Lateral movement and command-and-control from that host | Your own remote access, unless you hold an allowlist open | The host still runs an agent you control |
Pull the cable | The same, on a host with no agent | Remote access, with no allowlist option | There's no agent and someone can reach it physically |
Power the host off | Encryption still running on that disk | Memory, which often holds the injected process, the operator's tooling and sometimes key material | Files are actively encrypting and you have no other way to stop it |
Disable VPN and external remote access | Re-entry through the route they most likely used | Remote staff and every third party who supports your systems | Early, unless a documented dependency stops you |
Disable the compromised accounts and reset krbtgt twice | Reuse of stolen tickets and credentials | A wave of authentication failures you then have to triage | Credential theft is confirmed and you can schedule both resets |
Shut down the hypervisor cluster | Encryption spreading across every guest at once | Every system on it, including the healthy ones | The management plane itself is confirmed compromised |
The VPN row is the one I would act on first. CISA's Akira advisory, updated in November 2025 with the FBI, Europol's EC3 and partners in France, Germany and the Netherlands, lists a VPN service without multi-factor authentication configured as a primary access vector. If yours is in that state, closing it is both containment and root cause.
Speed here is worth more than elegance. In a Swiss retail engagement that opened with a wave of more than 3,000 unrelated emails, the intrusion was contained in 43 minutes and stopped before ransomware deployed at all.
Hours two to four: The data left before the files locked
Treat exfiltration as confirmed until you can prove otherwise, because the timeline gives you no reason to assume anything else. The same CISA advisory records that in some incidents Akira operators exfiltrated data in just over two hours from initial access, and puts claimed proceeds at approximately $244.17 million as of late September 2025.
The tooling is ordinary, which is why it survives a casual log review. The advisory names FileZilla and WinRAR for staging, WinSCP and RClone for transfer, Mega for cloud storage and Ngrok for tunneling, nearly all of it software your admins have a legitimate reason to run.
Hunt on volume and destination. Malware signatures will not find this. A single host pushing tens of gigabytes to a consumer cloud endpoint over a weekend is the shape you're hunting.
This is also the hour your legal counsel joins the call, because what left the building determines who has to be told and by when.
Hours three to six: Open a backup before you promise a recovery time
The worst moment of the first day is usually the one where somebody restores a test file and it doesn't come back.
M-Trends 2026 describes this as a deliberate shift toward recovery denial. Its authors observed operators, including groups using REDBIKE and AGENDA, "actively targeted backup infrastructure, identity services, and virtualization management planes," and record attackers deleting backup objects straight out of cloud storage. CISA's advisory documents the simpler version of the same idea: volume shadow copies removed with a short PowerShell command.
Before anyone quotes a recovery time to an executive, walk this and write down what you find:
Restore one real file from the most recent backup and open it.
Check whether the backup server authenticates against the same domain you are about to rebuild.
Confirm in the console that immutability or object lock is switched on today.
Find the last date a full restore was actually tested end to end.
Identify who holds credentials for the backup console that are not domain accounts.
Every answer here is either a recovery hour you can promise or one you can't. The most expensive sentence on day one is "we have backups," said by someone who has not restored one.
Hours four to eight: The hard problems stop being technical
By now the technical picture is stable enough to act on, and the day turns into decisions no engineer has the authority to make.
Somebody has to approve taking a production line offline, and decide whether the plant runs on paper for a shift. Your insurer's notification window, your regulator's reporting clock and your largest customer's breach clause all begin on different events and run at different speeds, and none of them pauses while you investigate.
The ransom question arrives earlier than most plans expect and lands on whoever is in the room. Whether you engage at all, who may communicate, and who signs off are three separate answers, and an incident is a poor place to discover you hold none of them.
This is where I have seen most first days go wrong. The runbook describes isolation and forensics in detail, and it names nobody. Write the names in before you need them, with a deputy for each, because the person you listed will eventually be on a plane.
Hours 8 to 16: You can't rebuild until you know how they got in
Rebuilding on top of an unanswered root cause buys you a second incident.
Identity is where this investigation lives. CISA's advisory documents Akira operators dumping credentials with Mimikatz and LaZagne, pulling them from LSASS memory, and running Kerberoasting against service accounts. Any of those means the credentials you're about to reset were readable long before the encryption started.
UnderDefense's account of a Colorado engagement describes moving from detecting Cobalt Strike to removing it from 11 critical servers in under 24 hours, which is achievable only when the entry point and the credential scope get answered while containment is still running.
Work through the questions that gate a rebuild:
Which account was used first, and was it a person or a service?
Was multi-factor authentication absent, bypassed, or satisfied by a stolen session token?
Which systems did that account touch in the 30 days before the encryption event?
Do your domain controllers still hold the logs covering that window, or have they rolled?
Which service accounts have passwords that predate the intrusion and can't be rotated without an outage?
The last question usually adds a day. Nobody documents the batch job from 2019 that breaks when its password changes, and everybody finds it at 02:00 on day two.
Hours 16 to 24: staged recovery, and what "back online" means
Recovery runs in an order, and identity comes first. A clean domain controller in an isolated segment is what everything else authenticates against, so restoring the ERP before the directory is trustworthy just moves the problem forward a few hours.
Rebuild into a clean environment and restore data into it. Restoring a compromised system in place preserves whatever persistence was installed alongside the ransomware, which is the access broker's whole purpose.
Hours | What you're doing | What they've usually already done | The decision on the table |
|---|---|---|---|
0 to 1 | Confirming it's ransomware and scoping the blast radius | Held access for roughly two weeks | Do we declare an incident? |
1 to 2 | Isolating hosts, closing remote access | Finished encrypting whatever they intended to | What do we take offline, and who approves it? |
2 to 4 | Hunting outbound volume and destinations | Exfiltrated data, often within hours of entry | Who gets notified, and when does the clock start? |
4 to 8 | Briefing legal, insurance and the executive team | Set a payment deadline in the note | Do we engage with them at all? |
8 to 16 | Answering root cause and credential scope | Left persistence behind for a return visit | Can we rebuild yet, or are we still guessing? |
16 to 24 | Standing up clean identity, restoring in priority order | Waiting to see whether you rebuild onto their foothold | What does the business actually need first? |
Nothing on that table is finished at hour 24. What ends is the phase where every decision is still reversible.
What separates the teams that get through day one
The organizations that come out of a first day intact rarely move faster in the moment. They arrive with fewer open questions.
Their backup restore was tested this quarter, so the recovery time they give the board is a measurement. Their ransom-decision authority is named in a document somebody has read. Their responders cover the hours when these calls actually land, which means Friday evening and the first morning of a public holiday.
The poultry producer mentioned earlier ended its incident with zero ransom paid, according to UnderDefense's write-up of the engagement, and followed it by replacing more than 900 noisy detection rules with over 100 written against its own environment. That second half is the part I would copy.
Pick one of these and do it this week:
Restore a file from your newest backup and time it.
Write three names and three deputies into the decision section of your IR plan.
Check whether every remote access path into your estate enforces multi-factor authentication today.
Run the tabletop on a Friday at 17:00, with the people who'd really be on that call, and see which assumptions survive contact.
Frequently asked questions
Should you power off a machine that is actively encrypting files?
Only when you have no faster way to stop it. Powering off destroys memory, which frequently holds the injected process, the operator's tooling and occasionally key material that a responder could have recovered. Network isolation from an EDR console stops the spread while preserving all of it. Pull the cable if there's no agent on the host and you can reach it in person.
How do you tell whether data was stolen as well as encrypted?
Look for outbound volume and destination before you look for malware. The transfer tools named in CISA's November 2025 Akira advisory (RClone, WinSCP, FileZilla, Mega, Ngrok) are legitimate software someone in your estate has a reason to run, so your signal is a host pushing unusual volume to an unusual endpoint at an unusual hour. Absence of proof is not proof of absence, and your legal counsel will treat it that way.
When should you bring in an external incident response team?
Before you need one. A retainer signed during an incident costs you hours of procurement and contract review, and those are the hours where containment decisions are still cheap. If you have no retainer and an incident is live, call as soon as you confirm it is ransomware. Waiting until your own team runs out of options spends the hours that matter most.
Does paying the ransom shorten the first 24 hours?
No. Decryption tooling supplied by an attacker is typically slow and incomplete, and it does nothing about the persistence, the stolen credentials or the exfiltrated data. Payment is a separate commercial and legal decision with sanctions exposure attached, and it should be made by named people against a policy written in advance.
What is the single most useful thing to prepare before an incident?
A tested restore. Everything in the first 24 hours bends around whether your recovery time is a measurement or a hope, and a backup that nobody has restored from is the latter. Second place goes to writing names into the decision points of your incident response plan, because an unassigned decision is the most reliable way to lose four hours.
Nazar Tymoshyk founded UnderDefense in 2017 and leads it as CEO. The company runs security operations, incident response and offensive testing for customers across the US and Europe.
