Author: Andrew Mikhaliuk, CEO CoreWin
Greetings to anyone working in cybersecurity, or IT in general, who eventually run into the same question: how do systems recover after something goes wrong?
In a perfect world, ping would never spike, CPU and memory utilization would never cross 80%, and data would never be at risk.
Unfortunately, production environments do not live in that world.
Sooner or later, every IT professional has to deal with recovery after an outage, failure, or security incident. Good architecture, careful administration, and solid planning can reduce the likelihood and impact of those events, but they cannot eliminate them completely.
Things break. Systems get compromised. And recovery becomes part of the job.
The more interesting question is what recovery actually means after a cyber incident.
What does NIST say about recovery?
First, some fundamentals.
According to NIST SP 800-61 Rev. 2, incident response can be divided into four major stages:
- Preparation
- Detection and analysis
- Containment, eradication, and recovery
- Post-incident activity
This article focuses on the final part of stage three: recovery.
For simplicity, assume that the threat has already been detected, contained, and supposedly removed.
That word, supposedly, is where things get interesting.
NIST is foundational material for incident response, and every one of these stages could easily justify an article of its own. Anyone unfamiliar with the framework should spend some time with it, whether through the full publication, a shorter overview, or even a podcast or video breakdown.
For the sake of keeping this article shorter than a small book, cyber incidents can also be simplified into two broad categories.
The first includes large-scale, often automated attacks involving malware. The second includes targeted campaigns carried out by threat groups with a specific objective.
It is an imperfect simplification, but it helps explain an important shift in attacker behavior over the past few years.
What has changed?
- Eradication and recovery can no longer be treated as the same thing. Removing malware from every affected system does not automatically mean that the environment is secure again.
- Different threat actors optimize their operations for different outcomes. Some, particularly ransomware operators, prioritize speed and maximum impact. Others, including some state-sponsored groups, focus on remaining inside an environment quietly for as long as possible, sometimes described as “extreme persistence.”
- Access itself has become an asset. Specialized groups may focus entirely on gaining access to an organization and then selling that access to another criminal group. For them, establishing the initial foothold can be the end goal rather than the beginning of the attack.
- Attacker persistence is increasingly found outside the places security teams traditionally monitor most closely. It may exist in VPN infrastructure, firewalls, DevOps pipelines, compromised cloud tokens, or other credentials. Focusing only on traditional endpoints is no longer enough.
More examples of current attacker behavior and persistence techniques can be found in M-Trends 2026.
Why removing the threat does not mean the incident is over
A typical incident starts when something is detected. A SIEM raises an alert, a SOC registers an incident, and a ticket suddenly appears with an alarming red status and an unpleasantly high priority. Emails start flying toward the CISO and the team responsible for the affected system. Then comes the familiar sequence: denial, anger, bargaining, and eventually the actual technical work.
At some point, the immediate cause of the incident is removed. And this is where the problem begins.
Operationally, teams often start thinking about the incident through the event that triggered detection. It might be unauthorized access from an unknown source, a compromised production system, or an unauthorized transfer of sensitive data. But the first visible signal is not necessarily the beginning of the attack.
It may represent lateral movement, an attempt to determine whether a particular file is valuable, or the creation of another backdoor. It may simply be the moment when an attacker who has already been inside the environment for days or weeks finally does something noisy enough to trigger detection.
Meanwhile, the original foothold may exist somewhere nobody initially thought to look: a forgotten network appliance, a printer, or, in the worst possible combination of convenience and bad security decisions, a coffee machine with Wi-Fi.
The point is not that detection and prevention are unimportant. Quite the opposite. The more visibility and defensive controls an organization has, the better.
That may include:
- EDR/XDR, such as Cynet
- DLP, such as Netwrix Endpoint Protector
- IAM and identity management
- Active Directory auditing
- network vulnerability scanning, such as OPENVAS (Enterprise)
- antivirus
- firewalls
- VPN infrastructure
- SIEM
- SOC capabilities
All of these controls matter.
But the next question is what happens after they start producing evidence.
From isolated incidents to the full attack story
This is where the problem starts to resemble something the business world faced around a decade ago: Big Data. Yes, that Big Data. The term that once appeared in almost every presentation, article, and conference agenda in roughly the same way AI does today.
For finance, sales, and logistics teams, the problem was not simply that data existed. There was too much of it, it came from too many sources, and it was stored in different formats and systems. At the same time, the window for making decisions became much shorter.
The response was not a single tool, but an entire layer of technologies designed to bring scattered information together. Data virtualization and data lakes helped aggregate information, while business intelligence and data analysis made those combined datasets usable for decision-making.
Cybersecurity is starting to face a very similar problem. SIEM platforms and SOC teams are good at detecting and responding to events in real time, but there is another analytical layer that deserves more attention: collecting important security events over time, correlating them, and looking for relationships that are invisible when each alert is investigated in isolation.
Think of it this way. Responding to a single alert is like sending a patrol car to a crime scene. That is necessary. But if five similar crimes happen across the city, somebody also needs to collect the evidence from all five scenes, compare it, identify patterns, and ask whether they are connected. That is no longer patrol work. That is an investigation.
Cybersecurity needs more of that investigative mindset. Instead of asking only, “What happened on this system?”, teams should also be asking what happened before and after it, which identities, hosts, applications, network devices, and cloud resources were involved, and whether seemingly unrelated alerts could actually describe different stages of the same operation.
This kind of approach may also help expose attackers who are simply waiting inside the environment. After gaining quiet access, an attacker often needs time to understand the infrastructure. During that phase, mistakes happen: a reconnaissance command here, an unusual authentication attempt there, a strange request to an internal service, or a low-priority alert that looks harmless on its own.
Individually, those events may not look dramatic. Together, they may tell a very different story.
Recovery must include proving that the environment is safe
Eventually, every incident reaches the practical question: can the affected service be restored?
But restoring availability is only one part of recovery.
An incident should not be considered closed simply because the service is running again. It should be considered closed when the response team can reasonably explain how the attacker got in, how far they went, what persistence or access mechanisms they may have created, why those mechanisms no longer work, and what telemetry supports those conclusions.
The harder part is restoring confidence: confidence that the attacker is no longer present, that no secondary access path remains, and that credentials, tokens, automation systems, cloud resources, or network infrastructure have not been left compromised.
Ideally, that confidence should come from evidence rather than hope.
How to achieve this consistently is still an open question. Organizations with mature incident-response teams can build retrospective analysis directly into their process. If there is no dedicated team, someone still needs to own the task.
And that leaves a broader question for the CISO: how can an organization move beyond reacting to individual alerts and start reconstructing the full sequence of an attack? How can seemingly unrelated security events be correlated, mapped, and used to identify what an attacker may still control inside the environment?
Because getting the service back online is not enough.
At some point, somebody still has to find the bastard hiding in the environment and kick them out. 😊
