Some companies see cybersecurity as a cost center. We see things a little different. LEARN MORE >
Experiencing a Breach?
BLOG
Eight Lessons from the Front Lines of Incident Response
JUMP TO: VISIBILITY | INVESTIGATION | CONTAINMENT | PRACTICE | CALL EARLY | TIME | HARDENING | IDENTITY | CONCLUSION
Key Takeaways
- Visibility is non-negotiable. If you can't see your own environment — cloud, Linux, virtualization hosts — attackers will find the dark corners before you do.
- Alerts require investigation. An EDR alert that gets waved off as "handled by antivirus" can become a ransomware attack six weeks later.
- Partial containment is no containment. Hesitating to isolate systems during an active incident can turn hours of downtime into weeks of recovery.
- Tabletop exercises aren't optional. The teams who respond best are the ones who've already practiced failing.
- Call your IR team early. Every day an attacker sits in your environment, forensic artifacts disappear and your options shrink.
- Identity is the new perimeter. Modern attackers don't break in — they log in. Protect admin accounts and monitor user behavior.
When I was asked to speak at the 2026 Central Ohio InfoSec Summit, the mission seemed simple.
"As an Incident Response expert, what's the one thing you wish your clients knew before they called you?"
It's a great question. Problem is, there's no easy answer — because there's never just one thing.
But after 25 years of doing this work, I've definitely observed some patterns.
So instead of one thing, I decided to share eight — inspired by two real incidents I worked recently.
- The first case started with a single click and ended in ransomware. A domain admin installed a bad link, the alerts got waved off, and a month and a half later the attacker came roaring back.
- The second case never touched an endpoint at all. Attackers walked straight into a Microsoft 365 environment using stolen identities, compromised dozens of accounts, and left us with a real mess.
Some details have been adjusted to protect the innocent, but these eight takeaways are real — and they should be useful for anyone managing cybersecurity risk, whether you attended the summit or not.
1. You Always Need More Visibility
In our first case, the attacker moved laterally, dropped backdoors that hid alongside legitimate programs, and disabled EDR as they went. On the systems where EDR was never installed, they operated freely — the client's Linux fleet was still waiting on a deployment "scheduled for later this year."
Then they jumped into the Azure control plane and executed commands directly through the cloud. The logging existed. Nobody was watching it. We spent days playing whack-a-mole because the client couldn't see across their own environment.
In the second case, the most important machine in the whole investigation — patient zero — was a personal device the organization had zero visibility into. That single blind spot meant we never established root cause.
Visibility determines so much about how an incident plays out. You can never have too much logging, and you should deploy EDR everywhere: virtualization hosts, cloud environments, and yes, your Linux fleet.
2. Investigation Is Not Optional
Incidents don't magically happen. Big problems often follow someone failing to raise the alarm on a smaller issue — and that's exactly what happened in our first case.
A domain admin searched for a common IT utility and clicked a malicious link. The EDR system caught part of the malware and threw an alert on day one. The team assumed it had been handled by "the antivirus" and moved on.
A month and a half later, that same malicious link served as the open door for a full-blown ransomware attack. The whole thing might have been avoided if someone had just shut the door.
3. Containment Counts
One of the first things the attacker did in our first case was disable EDR. The client had no fallback for the systems that were suddenly dark. We recommended cutting internet access to break the attacker's connection — but the client hesitated out of fear of an outage.
The math here is simple: a few hours of downtime vs. a few weeks of ransomware negotiation. Sure enough, while the client was deliberating, the attacker came back in the middle of the night and detonated ransomware across the virtual machines.
Partial containment is no containment. Be prepared to isolate users, networks and systems — and understand how much speed matters in this phase of response.
4. Practice Makes Perfect
To paraphrase a famous catchphrase: everybody has a plan until they get hacked in the middle of the night.
In both examples, neither client had planned for an incident at the scale they faced, and neither had talked through containment decisions with leadership beforehand. In the second case, there was no plan at all for how to analyze or contain an employee-owned device.
The teams who respond best are the ones who've been battle-tested before the real crisis happens. Tabletop exercises help ensure you know who leads, who does what, and what to do when your big plan falls apart.
5. Don't Wait to Call
Every day an attacker sits in your environment is a day they're expanding access, destroying evidence and shrinking your options.
When you bring in an IR provider too late, the most useful forensic artifacts are frequently already gone, and the best advice we could have given on day one no longer applies.
The sooner you call, the faster you get help. Waiting can also mean waiting for availability — especially if you're working without an IR retainer, which you should strongly consider.
6. Incident Response Takes Time
In our second example, hundreds of phishing emails went out from compromised accounts, and roughly 50 users were caught up in the attack. Every single one of those identities became its own investigation — logging into each account and reconstructing what the attacker did inside it.
These cases are heavily dependent on logs, and when you're working in Microsoft 365, you're on Microsoft's clock. You request logs and they could come back in 30 seconds — or two hours.
Setting up access beforehand and maintaining centralized, searchable logs helps ensure your IR team isn't starting from zero. But it's important to level-set: these investigations aren't quick.
7. Harden Your Systems
Attackers go where you aren't looking. A little-used device or appliance is just as good an entry point as a workstation — maybe better.
This is why you need to establish minimum security baselines for all of your systems. In our first case, the attacker thrived in the gaps: older Windows servers, Linux machines with no EDR, virtualization hosts nobody monitored.
When they finally deployed ransomware, they did it by encrypting the VMs at the ESXi disk level — underneath the hosts entirely, in a place no one was watching. That wasn't an accident.
8. Identity Is the New Perimeter
We often say attackers don't break in — they log in. Our second case is one of the clearest examples I've seen of this idea in practice.
Not a single endpoint was ever compromised. It was all identities. The attacker used a technique called device code phishing, which abuses a legitimate Microsoft authentication flow built for devices like smart TVs, printers and conference room systems. They generated a device code, sent it to a victim with a convincing pretext, and the victim entered it on the real Microsoft site — handing the attacker full access.
From there, they compromised around 50 accounts in roughly two hours. The victim did everything they were trained to do, and it didn't matter — because identity was the battlefield.
Protect your admin accounts. Review access regularly. Keep a close watch on user behavior and activity. Your identity plane is your perimeter now.
We're Here to Help
Our incident response team sees problems like these every day. We'd rather help you prepare today than meet you tomorrow in the middle of a crisis — but we're always ready for both.
If any of these eight lessons hit close to home, that's not a coincidence. It means there's work to do, and there's still time to do it before the next call comes in.
