The first four hours of an incident
In most incidents, the avoidable damage was not caused by the attacker but by the improvised reaction of the first few hours. Five mistakes we see repeatedly, and what to do instead.
When we get activated for an incident, our first question is almost never about the attacker. It is this: what did you do in the last few hours?
The answer determines how much of the case can still be reconstructed. In most incidents we handle, the damage that turned out to be unrecoverable was not the adversary’s work — it followed from well-intentioned decisions made in the first four hours, before anyone with forensic experience joined the conversation.
These are the five mistakes we see most often.
1. Powering off the compromised server
It is the natural reflex: something bad is running, so cut the power. The problem is that RAM holds the best available evidence — running processes, active connections, encryption keys, injected code that never touched disk — and it vanishes completely on shutdown.
A great deal of modern malware operates entirely in memory for exactly this reason. Powering off does not remove it if it has persistence; it only destroys the one copy of the evidence that explained it.
Instead: isolate the system from the network but keep it running. Pull the network cable, move the port to an isolated VLAN, or block it at the firewall. The adversary loses control; you keep the evidence.
2. Rotating every credential immediately
Rotating credentials is correct. Rotating them before you know the scope is counterproductive.
If the adversary holds three persistence mechanisms and you rotate the passwords covering two of them, you have accomplished exactly two things: you told them they were detected, and you did not remove them. An attacker who knows they have been spotted stops being stealthy — they move faster, destroy evidence, and increasingly, trigger encryption before losing access.
Instead: establish scope first, then rotate everything at once, in a coordinated push. If exposure is severe enough to demand rotation now, do it completely — service accounts, API tokens, SSH keys, and deployment pipeline credentials included.
3. Letting the antivirus “clean” it and moving on
The console shows the threat quarantined, the green check appears, and it feels like a closed case. But the detection tells you what the tool found — not how it got in, how long it had been there, or what else it did in the meantime.
The malware that gets detected is usually the disposable part of the operation. The service account created three weeks earlier, the scheduled task that runs every Sunday, and the forwarding rule in the CFO’s mailbox are all still exactly where they were.
Instead: preserve the sample before deleting anything, and treat the detection as the start of the investigation rather than its conclusion.
4. Communicating over compromised channels
If the adversary has access to your environment, it is reasonable to assume they read corporate email and internal chat. We have seen operations where the attacker followed the response in real time from the same Teams thread being used to coordinate it — and adjusted their behavior accordingly.
Instead: move coordination to an out-of-band channel from minute one. A group on personal phones, an email account on another domain, a phone call. Agree on which one before you need it; improvising during the crisis costs hours you do not have.
5. Restoring the backup onto the same vulnerability
Restoring is urgent and understandable. But if the backup is restored onto the same unpatched version of the same exposed service, reinfection arrives within days. We have watched it happen twice in the same case.
There is also this: if the backup was taken after initial access, the backup contains the persistence too.
Instead: identify the entry vector and the date of first access before restoring. Restore into a hardened environment, with the vector closed and heightened monitoring on the affected systems.
What is worth doing in the first hour
- Isolate without powering off the affected systems.
- Preserve logs now — many rotate within days and are unrecoverable afterward.
- Write down the timeline of what your team has already done. Every response action leaves artifacts an analyst can mistake for attacker activity.
- Open an out-of-band channel.
- Call whoever is going to respond. A twenty-minute call before touching anything is usually worth more than the next eight hours of work.
The underlying pattern
None of these mistakes come from negligence. They come from the fact that incident response is counterintuitive under pressure: the right instincts for a normal operational problem — restore the service, clean the infection, change the passwords — are almost all wrong when there is an active adversary.
That is why the plan gets written beforehand, and why it gets tested in a tabletop exercise. Not to have the document, but so the hard decisions are already made when the clock is running.