Silence. That’s the first thing that strikes after a ransomware attack on a production environment. Silence where just a moment ago there was a rhythmic hustle and bustle of machines. On the screens of SCADA systems, instead of graphs and indicators, there is a lockout and a ransom demand. Production is at a standstill. Every minute represents thousands of zlotys of loss. The natural reaction is to panic and want to get everything back to normal as soon as possible - restarting systems, restoring from backups, doing anything to get the machines going.
This is the worst thing you can do at the moment. Every reboot, every ill-considered action is an irrevocable obliteration of the digital footprints left behind by the attacker. It’s like letting a cleanup crew into a crime scene before the forensic technicians arrive. Without these traces, you’ll never answer the key questions: How did they get in? What exactly did they do? Are they still on our network? Are our backups infected, too?
Once the attack is over, the work for digital investigators begins. The process of post-hack analysis, or computer forensics, in an OT environment is extremely difficult and nothing like an investigation in the IT world. It’s a race against time in the midst of systems that don’t like to leave traces behind.
Shortcuts
- Why is the OT network’s digital “crime scene” obliterating faster than fingerprints in the rain?
- How is detective work in a factory different from that in an office?
Why is the OT network’s digital “crime scene” obliterating faster than fingerprints in the rain?
When an office incident occurs, analysts have a wealth of evidence at their disposal. Hard drives of servers and laptops, detailed system logs, RAM dumps - all of this allows for precise reconstruction of the intruder’s actions. The crime scene in IT is permanent. In OT, it is quite different.
The digital crime scene in a factory is extremely ephemeral. Most key devices, such as PLCs and remote I/O modules, are simple embedded systems. They do not have hard drives, and their ability to store logs is minimal or nil. The most valuable evidence - information about recent connections, running processes, snippets of malicious code - resides only in their operating memory (RAM). All it takes is one reboot or power outage, and all these traces disappear irretrievably.
This is why panic reboots of machines after an attack are so disastrous in their consequences. Every time a controller is turned off and on, potential evidence is irretrievably destroyed. Attackers are well aware of this and often design their attacks to force a reboot on the victim to cover their tracks.
📚 Read the complete guide: SOC: Security Operations Center - what it is, how it works, how to choose
How is detective work in a factory different from that in an office?
Computer forensics in IT is like detective work in a modern laboratory. He has advanced disk analysis tools at his disposal, can recover deleted files and examine the slightest changes in the system registry. His work focuses on analyzing persistent storage media.
Computer forensics in OT is more like an archaeologist’s work on a delicate excavation site. Evidence is fragile and scarce. They cannot simply be taken to the lab. Shutting down the system to make a binary copy is often impossible because it would mean weeks of downtime. The OT detective must work on a “living organism,” collecting evidence in a way that will not disrupt an already volatile situation.
Moreover, tools from the IT world are often useless in OT. Traditional forensic analysis software does not “understand” industry protocols or the specific file systems used in embedded devices. An OT detective must use a unique set of tools and techniques, and above all, must have a deep knowledge not only of cyber security, but also of automation and industrial processes.
Where to look for evidence when hard drives are silent - the power of network traffic analysis?
Since the terminal devices themselves leave so few traces, where to look for evidence? The answer is: in the network. In modern OT post-breach analysis, the most important source of evidence is not hard drives, but records of network traffic (known as PCAP - packet capture). This is the digital equivalent of surveillance camera footage that recorded everything that happened on the “streets” of our factory.
If an organization has a system for passive OT network monitoring, it has a real goldmine at the time of an incident. By analyzing the recorded network packets, the investigator can reconstruct the entire history of the attack step by step. He can see from which IP address the first malicious command came, what vulnerabilities were exploited, between which machines the attacker moved and what data he tried to steal.
Network traffic analysis can answer questions that a PLC analysis alone could never answer. It’s the only way to see the full picture, not just the latest scene of the drama. That’s why implementing continuous network monitoring is not only a detection tool, but also a key element of preparation for future forensic analysis.
What is ephemeral data and why is securing it a critical first step?
Volatile data is any information that exists only in the operating memory (RAM) of a computer or device and which disappears irretrievably when it is turned off. In the context of post-hack analysis, this is often the most valuable evidence, as it contains information about currently running processes, active network connections and pieces of malicious code that have not yet been written to disk.
Therefore, absolutely the first step of the response team, even before attempting to isolate or remove the threat, should be, if possible, to secure the ephemeral data. In the case of systems running on Windows (e.g., SCADA servers, HMI stations), this involves performing a so-called RAM dump (memory dump) using specialized tools.
For simpler devices, such as PLCs, taking a memory dump is often impossible. In such a situation, securing ephemeral data may involve taking detailed photographic documentation - photographing the status of LEDs on the device, messages on the operator panel or configuration parameters. All this to capture a “snapshot” of the state of the system at the time of the attack, before it is irretrievably lost.
How can SCADA and HMI systems become the “black box” of an entire incident?
While PLCs are digital mute, master systems such as SCADA servers, HMI panels or historical databases (historians) are much more “talkative.” Since they most often run on standard operating systems such as Windows or Linux, they become an invaluable source of evidence - a digital “black box” that recorded the course of a disaster.
A classic forensic analysis can and should be performed on these systems. Analysis of system and application logs can reveal unauthorized login attempts, running suspicious programs or configuration changes. Hard drive analysis can find files left behind by the attacker, such as scripts or hacking tools.
Most importantly, these systems often log communications with lower-level devices. SCADA system logs can include a precise record of what commands and at what time were sent to individual PLCs. By correlating this information with network monitoring data and anomalies in the physical process, an extremely detailed and reliable picture of the entire incident can be created.
What traces could the attacker have left on the controllers themselves and in the control cabinets?
Although PLCs do not store much data, there are some traces that an experienced analyst will look for. One of the most important is to see if the control logic (the program uploaded to the controller) has been modified. Many attacks on OTs (such as the famous attack on the Ukrainian power grid) involve precisely uploading a malicious program into the controller to perform physical sabotage.
The analyst must rip the current logic from the controller and compare it to the latest trusted version stored in the repository (if one exists). Any undocumented change is a wake-up call. Another important trace is to check the operating mode of the controller. Many PLCs have a physical mode switch (e.g., RUN/PROG/STOP). If a controller that should be in RUN mode has been switched to program mode (PROG), this is a strong indication that someone has tried to make unauthorized changes to it.
Also, don’t forget about physical analysis. An experienced team will check the logs from the access control system of the control cabinets to see if anyone unauthorized has had physical access to them. It will also check to see if any unknown devices have been plugged into the controllers’ service ports.
What is the reconstruction of the attack chain (kill chain) in an industrial environment?
The goal of post-breach analysis is not to collect a random list of evidence, but to organize it and assemble it into a coherent story. This process is called reconstruction of the attack chain (kill chain). It involves reconstructing, step by step, all the stages of the attacker’s activities, from the initial infection vector to the realization of the final goal.
In an industrial environment, the attack chain often begins in the IT network. The analyst must first determine how the attacker got into the corporate network (e.g., through phishing). Then, he or she must trace its lateral movements - how it moved from system to system, escalated privileges and eventually found a bridge leading to the OT network.
The next step is to analyze activities in the OT network itself. What systems did he map? What vulnerabilities did he exploit to take control of the engineering station? What commands did he send to the PLCs? What was his ultimate goal - theft, data encryption or sabotage? Creating such a complete timeline is crucial to fully understand the incident.
The digital investigator’s toolkit on the OT network
Main source of evidenceWhat can be gleaned from it?Key to…**Network traffic records (PCAP)**Full reconstruction of communications, identification of malicious commands.Understand “how” the attack was carried out at the network level.Logs from SCADA/HMI systemsHistory of logins, running applications, configuration changes.Identify which system was compromised first.Disk and RAM imagesFinding malware files, analyzing running processes.In-depth analysis of compromised Windows/Linux systems.PLC logic and statusDetection of unauthorized changes to the control program.Confirm whether physical sabotage was attempted.Logs from network devicesCall information, alerts from IDS/IPS systems.Track lateral movement and identify the source of the attack.
Is the goal just to find the culprit, or to guarantee that the system is truly clean?
Many companies, after a superficial analysis, are tempted to end things quickly. “We found the infected computer, removed the virus, restore the data from a copy and get back to work.” This is a huge mistake. The goal of post-hack analysis is not to find and remove a single, obvious trace of a threat. Its real purpose is to gain reasonable assurance that the entire environment has been fully cleaned and that the attacker has not left any hidden backdoors (backdoors) in it.
Experienced attackers rarely rely on a single point of entry. Once they gain access, they try to place multiple persistence mechanisms on the network - hidden user accounts, scheduled tasks or modified system services. These mechanisms allow them to re-enter the network even after the original malware has been removed.
This is why a full reconstruction of the attack chain is so important. Only by understanding every step the attacker has taken can we identify all the changes he has made and be sure they have been undone. Resuming production too quickly without a thorough cleanup of systems is a straight path to a repeat attack, often even more severe, in a few weeks.
Why do you need a unique “digital archaeologist” for post-breach analysis in OT?
As you can see, post-breach analysis in OT is a unique field, requiring an extremely rare combination of skills. The ideal analyst must be part experienced computer forensics expert in traditional systems, part proficient network analyst, and part automation engineer who understands the logic of industrial processes.
He must be able to use both RAM analysis tools and industrial protocol analyzers. He must understand how the Windows register works and how ladder logic works in a PLC. He must think like a hacker, but at the same time understand the priorities of a maintenance engineer.
Finding such “digital archaeologists” who can reconstruct the entire history of an ancient disaster from a few fleeting fragments is extremely difficult. This is why most organizations, even the largest ones, in the event of a major incident in the OT network, opt for the support of external, specialized incident response teams.
How do you prepare your environment for future forensic analysis?
While it is impossible to fully prepare for the chaos of an attack, a number of measures can be taken that will dramatically simplify and speed up the work of analysts in the future. The most important of these is to implement continuous monitoring and recording of network traffic in critical segments of the OT network. Having historical PCAP records is absolutely invaluable.
The second key action is to implement a central system for collecting and archiving logs from all devices that can generate them - SCADA servers, HMIs, firewalls, network switches and even Windows systems. Ensuring that the logs are securely stored and protected from modification is key.
Finally, maintain an up-to-date repository of trusted versions of software and control logic for all key devices. Having a “golden image” allows you to quickly compare and identify any unauthorized changes made by an attacker. These three measures - network monitoring, log centralization and code repository - are the foundation that turns an impossible analysis mission into a difficult but doable task.
How does documented post-breach analysis affect NIS2 reporting obligations?
The NIS2 directive requires not only the reporting of the incident itself, but also the provision of detailed information about the incident. In the final report, submitted within a month of the incident, the organization must include, among other things, a detailed description of the incident, its probable cause and the countermeasures applied.
Conducting a professional, documented post-hack analysis is the only way to gather the reliable information necessary for such a report. The results of the analysis - the reconstructed attack chain, the identified infection vector, the list of compromised systems - form the substantive core of the report for the regulator.
Moreover, providing evidence of an in-depth analysis proves the organization’s maturity and professionalism. It shows regulators that the company has not only “put out the fire,” but has also made an effort to understand its causes and learn lessons for the future. This is an important factor that can influence the evaluation of the company’s actions and possible regulatory consequences.
How does nFlo’s incident response team approach post-breach analysis at your plant?
At nFlo, we understand that in a moment of crisis, you need not only tools, but above all, experienced experts who can act calmly and methodically under tremendous pressure. Our incident response team (CSIRT) combines unique expertise in IT systems forensics and in-depth knowledge of specific industrial environments.
Our approach is based on a proven, multi-step methodology. Immediately after notification, we help secure evidence, placing special emphasis on ephemeral data. Then, using advanced OT-safe tools, we begin the process of collecting data from multiple sources - from network traffic records to logs from SCADA systems. Our analysts, working hand-in-hand with your engineers, correlate this data to reconstruct a complete picture of the attack.
Our goal is not just to provide you with a report with a list of findings. We actively support you in the process of eliminating the threat and safely restoring operations. Finally, we provide detailed recommendations to help you strengthen your defenses and prevent similar incidents in the future. We act as your trusted partner and guide during the most difficult times.
What is the most important lesson you must learn from every incident, even the smallest one?
Every security incident, regardless of its scale, is an extremely valuable, though often painful, lesson. It is a free penetration test, conducted by a real, motivated adversary. Ignoring this lesson and “sweeping the problem under the rug” as quickly as possible is the biggest mistake one can make.
The most important lesson to be learned from any incident is humility and an understanding that your defenses are never perfect. Every attack exposes real, not theoretical, weaknesses in your architecture, procedures or employee awareness. An in-depth post-intrusion analysis allows you to accurately identify these weaknesses.
This is why the analysis process should not end with the creation of a report. It must initiate a cycle of improvement. If the attacker entered through unsecured remote access, we need to implement MFA. If he moved freely on a flat network, we need to implement segmentation. Treating every incident as a learning opportunity and fundamentally strengthening one’s defenses is what separates mature and resilient organizations from those that perpetually remain victims.
Restarting production destroys the evidence
The first hours contain a conflict nobody wants to arbitrate under pressure: production wants the line back, and the investigation needs the systems untouched. In an OT environment that conflict is sharper than in IT, because engineering workstations and controllers keep little history — rebooting one frequently erases the only record of how the attacker reached it. Deciding afterwards who arbitrates costs both the evidence and the time.
Agreeing that in advance, with a team that already knows the environment, is what OT incident support covers.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- OSINT — OSINT, or Open Source Intelligence, is the process of collecting, analyzing,…
- Security Operations Center (SOC) — Security Operations Center (SOC) is a central location where a team of security…
- SOC as a Service — SOC as a Service (Security Operations Center as a Service), also known as…
- Backup — Backup, also known as a backup copy or safety copy, is the process of creating…
- Network Security — Network security is a set of practices, technologies, and strategies aimed at…
Learn More
Explore related articles in our knowledge base:
- New trends in ransomware attacks in 2025: how to defend a company against the evolving threat?
- Defense in Depth - how to build multilayer protection against cyberattacks
- FortiEDR: Real-Time Endpoint Protection
- How Does IBM Security QRadar EDR Work? Analysis
- NIS2 directive in practice: What does a manufacturing plant manager need to know about the new obligations?
Explore Our Services
Need cybersecurity support? Check out:
- Incident Response - rapid response to security incidents
- SOC as a Service - 24/7 security monitoring
- Backup & Disaster Recovery - data protection and business continuity
Explore Our Products
Solutions mentioned in this article that can help protect your organization:
- IBM Security QRadar EDR — IBM
- IBM Security QRadar — IBM
- FortiEDR — Fortinet
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
