IT Pros All articles
Security & Operations

Dispatches from the 2 AM Breach: Seven Incident Response Mistakes That Turned a Bad Night Into a Lost Week

IT Pros
Dispatches from the 2 AM Breach: Seven Incident Response Mistakes That Turned a Bad Night Into a Lost Week

The alert came in at 1:47 AM on a Tuesday. By 3 AM, we knew it was ransomware. By Friday, half the company still could not work. What follows is not a theoretical framework — it is a post-mortem of everything our team got wrong, offered in the hope that your 2 AM goes better than ours did.

Mistake One: Backups That Had Never Been Restored

We had backups. We had backups of backups. What we did not have was a single documented, successful restoration test. When the moment came, we discovered corrupted incrementals, an outdated catalog, and a restore process that existed only in the head of a sysadmin who had left the company eight months earlier.

Restoration testing is not optional. Schedule quarterly restore drills against production-like infrastructure. If your backup strategy has never been rehearsed end to end, you do not have a backup strategy — you have a hope.

Mistake Two: No Air Gap, No Escape

Our backups lived on a file server with domain credentials cached. The ransomware, running with a compromised admin account, encrypted them right alongside the production shares. Segmentation and immutable or offline copies are the difference between paying a criminal and restoring from last night. Modern object storage with immutability locks is inexpensive insurance.

Mistake Three: The Ad Hoc War Room

Our initial response happened over a chaotic group text, two conference bridges, and a shared spreadsheet someone spun up at 3:30 AM. Decisions got made twice. Critical context got lost. By morning, nobody could say with certainty who had authorized taking the domain offline.

Every organization needs a documented communication protocol: a primary bridge, a backup channel independent of corporate systems (because your attacker may be watching your email), and a clear chain of authority for shutdown decisions.

Mistake Four: Alert Fatigue Had Numbs the Early Signals

In the post-incident review, we found the attackers had been in the environment for eleven days. Lateral movement alerts had fired — and been triaged as routine. Tune your detections, but more importantly, treat credential-based lateral movement as an emergency, not a ticket.

Mistake Five: Documentation Written by Nobody, Read by Less

Our network diagrams were two years stale. Our asset inventory lived in someone's head. We spent nearly a full day simply determining what systems existed and which ones mattered. A living, tested asset inventory — even a spreadsheet — is the unglamorous foundation of fast incident response.

Mistake Six: Forgetting the Humans

IT leadership focused so intensely on technical recovery that employee communication fell to whoever thought of it first. Rumors spread faster than facts. HR and communications need a seat in your incident plan, with pre-drafted holding statements ready.

Mistake Seven: No Legal or Insurance Contact List

Ransomware events in the United States carry regulatory and legal obligations that vary by industry and state. Knowing your cyber insurance carrier's breach hotline, your legal counsel's after-hours number, and any notification requirements in advance turns hours of scrambling into a single phone call.

The Uncomfortable Truth

Every mistake we made was a known best practice that felt unnecessary right up until it was not. Incident response is not a document in a shared drive; it is muscle memory built through testing. Run the tabletop exercise. Restore the backup. Update the diagram. Your future self, staring at an encryption notice at 2 AM, will be grateful.

All Articles

Related Articles

Follow the Money: Mapping 2025's IT Certifications to Real American Paychecks

Follow the Money: Mapping 2025's IT Certifications to Real American Paychecks