Welcome back, aspiring cyberwarriors.

Imagine the following scene. Evening. You are casually scrolling through eBay. Among the usual clutter of obsolete electronics and forgotten hardware, something unusual appears. It’s heavy industrial modules, clearly not meant for hobbyists. On the circuit boards you recognize familiar names: Siemens. AREVA. The listing description is brief, technical, and written by someone who knows what they are selling. The price, however, is unexpectedly low.

What you are looking at are components of the Teleperm XS system. This is a digital control platform used in nuclear power plants. Right now, this class of equipment is part of the safety backbone of reactors operating around the world. One independent security researcher, Rubén Santamarta, noticed the same thing and decided to investigate. His work over two decades has covered everything from satellite communications to industrial control systems, and this discovery raised a question: what happens if someone gains access to the digital “brain” of a nuclear reactor? From that question emerged a modeled scenario sometimes referred to as “Cyber Three Mile Island,” which is a theoretical chain of events that, under ideal attacker conditions, leads to reactor core damage in under an hour.

We will walk through that scenario to help you understand these systems.

Giant Containers

To understand how a nuclear reactor could be attacked digitally, we first need to understand how it operates physically. There is no need to dive into advanced nuclear physics. A few core concepts and some practical analogies will take us far enough.

Three Loops

At its heart, a pressurized water reactor (PWR) is an extremely sophisticated and very expensive boiler. In simplified form, it consists of three interconnected loops.

The first loop is the reactor itself. Inside a thick steel vessel sit fuel assemblies made of uranium dioxide pellets. This is where nuclear fission occurs, releasing enormous amounts of heat. Water circulates through this core, heating up to around 330°C. To prevent boiling, it is kept under immense pressure (about 155 atmospheres). This water becomes radioactive and never leaves the sealed primary circuit.

The second loop exists to convert that heat into useful work. The hot water from the primary loop passes through a steam generator, a massive heat exchanger. Without mixing, it transfers heat to a separate body of water, turning it into steam. This steam is not radioactive. It flows to turbines, spins them, drives generators, and produces electricity.

Finally, the third loop handles cooling. After passing through the turbines, the steam must be condensed back into water. This is done using water drawn from rivers, lakes, or the sea, often via cooling towers. This loop never comes into contact with radioactive materials.

With this structure in mind, we can now discuss what separates a reactor from a nuclear bomb. It’s control.

Reactivity

If a car accelerates when you press the gas pedal, a reactor accelerates when more neutrons are available. This is expressed through the multiplication factor, k. When k is greater than 1, power increases. When it is less than 1, the reaction slows. When k equals exactly 1, the reactor is stable, producing constant power.

Most neutrons from fission are released instantly, far too fast for any mechanical or digital system to respond. Fortunately, about 0.7% are delayed, appearing seconds or minutes later. That tiny fraction makes controlled nuclear power possible.

There is also a built-in safety mechanism rooted in physics itself. It’s called the Doppler effect. As fuel heats up, uranium-238 absorbs more neutrons, naturally slowing the reaction. This cannot be disabled by software or configuration. It is the reactor’s ultimate brake, supported by multiple engineered systems layered on top.

Nuclear Reactor Protection

Reactor safety follows a defense-in-depth philosophy, much like a medieval fortress. The fuel pellet itself retains many fission products. Fuel rod cladding adds another barrier. The reactor vessel is the next wall, followed by the reinforced concrete containment structure, often over a meter thick and designed to withstand extreme impacts. Finally, there are active safety systems and trained operators. The design prevents a single failure from leading to a catastrophe. For a disaster to occur, multiple independent layers must fail in sequence.

From a cybersecurity perspective, attention naturally turns to safety systems and operator interfaces. Sensors feed data into controllers, controllers apply voting logic, and actuators carry out physical actions. When parameters drift out of range, the system shuts the reactor down and initiates cooling. Human operators then follow procedures to stabilize the plant. It is an architecture designed to fail safely. That is precisely why understanding its digital foundations matters.

Teleperm XS: Anatomy of The Nuclear “Brains”

The Teleperm XS (TXS) platform, developed by Framatome, is a modular digital safety system used in many reactors worldwide. Its architecture is divided into functional units. Acquisition and Processing Units (APUs) collect sensor data, like temperature, pressure, neutron flux. Actuation Logic Units (ALUs) receive this data from multiple channels and decide when to trigger actions such as inserting control rods or starting emergency pumps.

The Monitoring and Service Interface (MSI) bridges two worlds. On one side is the isolated safety network using Profibus. On the other is a conventional local area network used by engineers.

The Service Unit (SU) is a standard computer running SUSE Linux. It is used for diagnostics, configuration, testing, and firmware updates. Critically, it is the only system allowed to communicate bidirectionally with the safety network through the MSI. TXS uses custom processors like the SVE2 and communication modules such as the SCP3, but it also relies on commercial components, such as Hirschmann switches, single-board computers, and standard Ethernet.

This hybrid design improves maintainability and longevity, but it also expands the potential attack surface. Widely used components are well documented, available, and easier to study outside a plant environment.

Hunting For Holes

Any attacker would be happy to compromise the Service Unit, since it provides access to the APU and ALU controllers, which directly control the physical processes in the reactor. However, on the way to this goal, you still have to overcome several barriers.

Problem 1: Empty hardware

Ruben unpacked the SVE2 and SCP3 modules, connected the programmer, and got ready to dump the firmware for reverse engineering, but a surprise was waiting for him. Unfortunately (or fortunately for the rest of the world), the devices’ memory was completely empty.

After studying the documentation, it became clear that the software is loaded into the controllers at the factory immediately before acceptance testing. The modules from eBay were apparently surplus stock and had never been programmed.

It turned out that TXS uses a simple CRC32 checksum to verify the integrity and authenticity of firmware. The problem is that CRC32 is NOT a cryptographic protection mechanism. It is merely a way to detect accidental data errors, similar to a parity check. An attacker can take a standard firmware image, inject malicious code into it, and then adjust a few bytes in the file so that the CRC32 value remains unchanged. The system will accept such firmware as authentic.

It reveals an architectural vulnerability embedded in the very design of the system. To understand it, we need to talk about the most painful issue in any security system: trust.

Problem 2: MAC address-based protection

The MSI is configured to accept commands only from a single MAC address. It’s the address of the legitimate SU. Any other computer on the same network is simply ignored. However, for an experienced hacker, spoofing (MAC address impersonation) poses no real difficulty. Such a barrier will stop only the laziest and least competent. For a serious hacking group, it is not even a speed bump, it is merely road markings on the asphalt. But there is one more obstacle called a physical key.

Problem 3: A key that is not really a key

U.S. regulatory guidance rightly insists that switching safety systems into programming mode requires physical action. A real key, a real human and a real interruption. An engineer must approach the equipment cabinet, insert a physical key, and turn it. That turn must physically break the electrical circuit, creating an air gap between the ALU and the rest of the world. Turning the key in a Teleperm XS cabinet does not directly change the system’s operating mode. It only sets a single bit (a logical one) on the discrete input board. In the system logic, this bit is called “permissive.” It signals to the processor: “Attention, the Service Unit is about to communicate with you, and it can be trusted.”

The actual command to change the mode (switching to “Test” or “Diagnostics”) arrives later over the network, from that same SU. The ALU/APU processor logic performs a simple check: “A mode-change command has arrived. Check the permissive bit. Is it set? Okay, execute.”

As a result, if malware has already been implanted in the ALU or APU, it can completely ignore this bit check. For it, the signal from the key does not exist. And if the malware resides on the SU, it only needs to wait until an engineer turns the key for routine work (such as sensor calibration) and use that moment to do its dirty work.

The lock becomes a trigger.

Summary

Part 1 establishes the foundation by explaining how nuclear power plants operate, how safety is enforced through layered engineering and physical principles, and also how digital control systems support these protections. By looking at reactor control logic, trust assumptions in safety architectures, and the realities of legacy industrial design, it becomes clear that cybersecurity risk comes not from a single vulnerability, but from the interaction of multiple small decisions over time. These elements on their own do not cause failure, but they shape an environment in which trust can be misused.

In Part 2, we shift our focus from structure to behavior. We will actively model a realistic cyber-physical attack and simulate how it unfolds in practice, tracing the entire sequence from an initial digital compromise.

Welcome back, aspiring digital forensic investigators.

The malware ecosystem is vast and constantly evolving. New samples appear every day, shared across underground forums and malware repositories. Some of these threats are short-lived, while others leave a lasting mark on history. Today, we are going to analyze one of those historically significant threats called BlackEnergy (for more on Blackenergy3 and it’s use to black out Ukraine, see the excellent article here by OTW). BlackEnergy is a malware family that gained global attention after being linked to large-scale cyber operations, most notably attacks against critical infrastructure. While it began as a relatively simple tool, it evolved into a sophisticated platform used in highly targeted campaigns. In this article, we will examine a memory dump from an infected Windows 7 system and use Volatility 3 to understand how BlackEnergy behaves in memory and how we can identify it during a forensic investigation.

Understanding BlackEnergy

BlackEnergy first appeared in the mid-2000s as a relatively basic DDoS bot. Early versions were used mainly to flood websites and disrupt online services. Over time, however, the malware evolved significantly. Later variants transformed BlackEnergy into a modular implant capable of espionage, sabotage, and long-term persistence. By the time it was linked to attacks against Ukrainian energy companies, BlackEnergy was an operational platform. It supported plugins for credential theft, system reconnaissance, file exfiltration, and lateral movement. One of its most destructive uses was as a delivery mechanism for KillDisk, a wiper component designed to overwrite critical system structures, erase logs, and make machines unusable. These capabilities strongly suggest the involvement of a well-resourced and organized threat actor, commonly associated in public reporting with the group known as Voodoo Bear.

Starting the Analysis

Our investigation begins with a raw memory capture from an infected Windows 7 machine. Memory analysis is especially valuable in cases like this because advanced malware often hides itself on disk but leaves traces while running.

Profile Information

Before diving into artifacts, it is always a good idea to understand the environment we are working with. The windows.info plugin gives us essential information such as the operating system version, architecture, kernel details, and system time. This context helps ensure that later findings make sense and that we interpret timestamps correctly.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.info

Process Listing

One of the first steps in memory analysis is reviewing the list of processes that were running when the memory was captured. This gives us a snapshot of system activity at that moment.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.pslist

During this step, two processes immediately stand out: rootkit.exe and DumpIt.exe. DumpIt is commonly used to acquire memory, so its presence is expected. The appearance of rootkit.exe, however, is an indicator of malicious activity and deserves closer inspection.

To gain more context, we can look at which processes had already exited and which were still running. Processes that have ended will show an exit time, while active ones usually display “N/A.”

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.pslist | grep -avi n/a

Among the terminated processes, we see rootkit.exe, cmd.exe, and others. This alone does not prove anything, but it makes us wonder how these processes were launched.

By correlating their process IDs, we can reconstruct the execution chain.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.pslist | grep -iE “1484|1960|276|964”

Although the output may look messy at first, it tells a clear story. explorer.exe launched several child processes, including cmd.exe, rootkit.exe, DumpIt.exe, and notepad.exe. This means the malicious activity was initiated through a user session, not a background service or boot-level process. Attackers often hide behind legitimate parent processes to blend in with normal system behavior, but in this case, the activity still leaves a clear forensic trail.

Code Injection Analysis

A common technique used by advanced malware is process injection. Instead of running entirely on its own, malware injects malicious code into legitimate processes to evade detection. DLL injection is especially popular because it allows attackers to run code inside trusted system binaries.

To look for signs of injection, we use the malfind plugin.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.malware.malfind

Several processes are flagged, but svchost.exe immediately draws attention due to the presence of an MZ header. The MZ signature normally appears at the beginning of Windows executable files. Finding it inside the memory of a running service process strongly suggests injected executable code.

To investigate further, we dump the suspicious memory region.

vol -f WINDOWS-ROOTKIT.raw windows.malware.malfind --dump --pid 880

VirusTotal and Malware Identification

After calculating the hash of the dumped payload, we can check it against VirusTotal. The results say the injected code belongs to BlackEnergy.

This confirms that the malware was running inside svchost.exe as an implant. Historically, BlackEnergy was used to maintain access, collect information, and deliver destructive payloads such as KillDisk. During the Ukrainian power grid attacks, this approach allowed attackers to disrupt operations while actively complicating forensic investigations.

MITRE ATT&CK classifications help further explain how BlackEnergy operated. The malware used obfuscation to hide its true functionality, masquerading to appear as legitimate software, system binary proxy execution to abuse trusted Windows components, and sandbox evasion to avoid automated analysis. It also performed registry queries and system discovery to understand the environment before sending data back to its command-and-control servers over HTTP, a technique that remains common even today.

Strings Analysis and Persistence

Running strings on the memory image shows additional clues.

bash$ > strings WINDOWS-ROOTKIT.raw

One particularly important finding is a reference to a .sys driver file, indicating that the malware persisted as a kernel driver. Driver-based persistence is more advanced than simple registry keys or scheduled tasks. It allows malware to load early during system startup and operate with high privileges, making detection and removal significantly harder.

Loaded DLL Analysis

To understand how the malware hides itself, we examine loaded modules using ldrmodules.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.ldrmodules --pid 880

The DLL msxml3r.dll does not appear as loaded, initialized, or mapped in memory according to the module lists. When all these indicators are false, it often means the malware is deliberately hiding the module from standard enumeration methods. This is a classic rootkit technique designed to evade detection.

DumpIt.exe Investigation

Finally, we examine DumpIt.exe. Dumping the process and checking its hash reveals that it is, in fact, a trojan.

bash$ > vol -f WINDOWS-ROOTKIT.raw windows.dump --pid 276

Its behavior shows a wide range of capabilities, including file manipulation, registry modification, privilege changes, service-based persistence, driver interaction, and embedded payload execution. In short, this malware component acted as a support tool, enabling persistence, system control, and interaction with low-level components.

Timeline Reconstruction

Putting all the pieces together, we can reconstruct the likely sequence of events. A user session initiated explorer.exe, which then launched command-line activity. Rootkit.exe was executed, injecting BlackEnergy into svchost.exe. The malware established persistence through a driver, hid its components using rootkit techniques, and maintained control over the system. DumpIt.exe, masquerading as a legitimate tool, further supported these activities.

Summary

In this investigation, we used Volatility to analyze a memory dump from a Windows 7 system infected with BlackEnergy. By examining running processes, code injection artifacts, loaded modules, strings, and malware behavior, we found a sophisticated implant designed for stealth and persistence. The whole case is a reminder that advanced malware often lives in memory, hides inside trusted processes, and actively works against forensic analysis.

Welcome back, aspiring SCADA hackers!

Today we introduce some of the most popular SCADA / ICS protocols that you will encounter during forensic investigations, incident response and penetration tests. Mastering SCADA forensics is an important career step for anyone focused on industrial cybersecurity. Understanding protocol behavior, engineering workflows, and device artifacts is a skill that employers in utilities, manufacturing, oil & gas, and building automation actively seek. Skilled SCADA forensic analysts can extract evidence with protocol fluency to perform analysis and translate findings into recommendations.

In our coming course in November on SCADA Forensics we will be using realistic ICS network topologies and simulated attacks on devices like PLCs and RTUs. You will reconstruct attack chains, identify indicators of compromise (IOCs) and analyze artifacts across field devices, engineering workstations, and HMI systems. All of that will make your profile unique.

Let’s learn about some popular protocols in SCADA environments.

Modbus

Modbus was developed in 1979 by Modicon as a simple master/slave protocol for programmable logic controllers (PLCs). It became an open standard because it was simple, publicly documented and royalty-free. Now it exists in two main flavors such as serial (Modbus RTU) and Modbus TCP. You’ll find it everywhere in legacy industrial equipment, like PLC I/O, sensors, RTUs and in small-to-medium industrial installations where simplicity and interoperability matter. Because it’s simple and widespread, Modbus is a frequent target for security research and forensic analysis.

DNP3

DNP3 (Distributed Network Protocol) originated in the early 1990s and was developed to meet the tougher telemetry needs of electric utilities. It was later standardized by IEEE. Today DNP3 is strong in electric, water and other utility SCADA systems. It supports features for telemetry, like timestamped events, buffered event reporting and was designed for unreliable or noisy links, which makes it ideal for remote substations and field RTUs. Modern deployments often run DNP3 over IP and may use the secure encrypted variants.

IEC 60870 (especially IEC 60870-5-104)

IEC 60870 is a family of telecontrol standards created for electric power system control and teleprotection. The 60870-5-104 profile (commonly called IEC 104) maps those telecontrol services onto TCP/IP. It is widely used in Europe and regions following IEC standards, so expect it in European grids and many vendor products that target telecom-grade reliability.

Malware can “speak” SCADA/ICS protocols too. For instance, Industroyer (also known as CrashOverride) that was used in the second major cyberattack on Ukraine’s power grid on December 17, 2016, by the Russian-linked Sandworm group had built-in support for multiple industrial control protocols like IEC 61850, IEC 104, OLE for Process Control Data Access (OPC DA), and DNP3. Essentially it used protocol languages to directly manipulate substations, circuit breakers, and other grid hardware without needing deeper system access.

EtherNet/IP (EIP / ETHERNET_IP)

EtherNet/IP adapts the Common Industrial Protocol (CIP) to standard Ethernet. Developed in the 1990s and standardized through ODVA, it brought CIP services to TCP/UDP over Ethernet. Now it’s widespread in manufacturing and process automation, especially in North America. It supports configuration and file transfers over TCP and I/O, cyclic data over UDP, using standard ports (TCP 44818). You’ll see it on plant-floor Ethernet networks connecting PLCs, I/O modules, HMIs and drives. 

S7 (Siemens S7 / S7comm)

S7comm (Step 7 communications) is Siemens’ proprietary protocol family used for the SIMATIC S7 PLC series since the 1990s. It is tightly associated with Siemens PLCs and the Step7 / TIA engineering ecosystem. Today it is extremely common where Siemens PLCs are deployed. Mainly in manufacturing, process control and utilities. S7 traffic often includes programs for device diagnostics, so that makes it high-value for both legitimate engineering and hackers. S7-based communications can run over Industrial Ethernet or other fieldbuses.

BACnet

BACnet (Building Automation and Control Network) was developed through ASHRAE and became ANSI/ASHRAE Standard 135 in the 1990s. It’s the open standard for building automation. Now BACnet is used in building management systems, such as HVAC, lighting, access control, fire systems and other building services. You’ll see BACnet on wired (BACnet/IP and BACnet MSTP) and wireless links inside commercial buildings, and it’s a key protocol to know when investigating building-level automation incidents.

HART-IP

HART started as a hybrid analog/digital field instrument protocol (HART) and later evolved to include HART-IP for TCP/IP-based access to HART device data. The FieldComm Group maintains HART standards. The protocol brings process instrumentation like valves, flow meters, transmitters onto IP networks so instrument diagnostics and configuration can be accessed from enterprise or control networks. It’s common in process industries, like oil & gas, chemical and petrochemical.

EtherCAT

EtherCAT (Ethernet for Control Automation Technology) is a real-time Ethernet protocol standardized under IEC 61158 and maintained by the EtherCAT Technology Group. It introduced “processing on the fly” for very low latency. It is frequent in motion control, robotics, and high-speed automation where deterministic, very low-latency communication is required. You’ll find it in machine tools, robotics cells and applications that require precise synchronization.

POWERLINK (Ethernet POWERLINK / EPL)

Ethernet POWERLINK emerged in the early 2000s as an open real-time Ethernet profile for deterministic communication. It’s managed historically by the EPSG and adopted by several vendors. POWERLINK provides deterministic cycles and tight synchronization for motion and automation tasks. Can be used in robotics, drives, and motion-critical machine control. It’s one of the real-time Ethernet families alongside EtherCAT, PROFINET-IRT and others.

Summary

We hope you found this introduction both clear and practical. SCADA protocols are the backbone of industrial operations and each one carries the fingerprints of how control systems communicate, fail, and recover. Understanding these protocols is important to carry out investigations. Interpreting Modbus commands, DNP3 events, or S7 traffic can help you retrace the steps of an attacker or engineer precisely.

In the upcoming SCADA Forensics course, you’ll build on this foundation and analyze artifacts across field devices, engineering workstations, and HMI systems. These skills are applicable in defensive operations, threat hunting, industrial digital forensics and industrial incident response. You will know how to explain what happened and how to prevent it. In a field where reliability and safety are everything, that kind of expertise can generate a lot of income.

See you there!

Learn more: https://hackersarise.thinkific.com/courses/scada-forensics

The post SCADA (ICS) Hacking and Security: SCADA Protocols and Their Purpose first appeared on Hackers Arise.

Welcome back, my aspiring SCADA/ICS cyberwarriors!

SCADA (Supervisory Control and Data Acquisition) systems and the wider class of industrial control systems (ICS) run many parts of modern life, such as electricity, water, transport, factories. These systems were originally built to work in closed environments and not to be exposed to the public Internet. Over the last decade they have been connected more and more to corporate networks and remote services to improve efficiency and monitoring. That change has also made them reachable by the same attackers who target regular IT systems. When a SCADA system is hit by malware, sabotage, or human error, operators must restore service fast. At the same time investigators need trustworthy evidence to find out what happened and to support legal, regulatory, or insurance processes.

Forensics techniques from traditional IT are helpful, but they usually do not fit SCADA devices directly. Many field controllers run custom or minimal operating systems, lack detailed logs, and expose few of the standard interfaces that desktop forensics relies on. To address that gap, we are starting a focused, practical 3-day course on SCADA forensics. The course is designed to equip you with hands-on skills for collecting, preserving and analysing evidence from PLCs, RTUs, HMIs and engineering workstations.

Today we will explain how SCADA systems are built, what makes forensics in that space hard, and which practical approaches and tools investigators can use nowadays.

Background and SCADA Architecture

A SCADA environment usually has three main parts: the control center, the network that connects things, and the field devices.

The control center contains servers that run the supervisory applications, databases or historians that store measurement data, and operator screens (human-machine interfaces). These hosts look more like regular IT systems and are usually the easiest place to start a forensic investigation.

The network between control center and field devices is varied. It can include Ethernet, serial links, cellular radios, or specialized industrial buses. Protocols range from simple serial messages to industrial Ethernet and protocol stacks that are unique to vendors. That variety makes it harder to collect and interpret network traffic consistently.

Field devices sit at the edge. They include PLCs (programmable logic controllers), RTUs (remote terminal units), and other embedded controllers that handle sensors and actuators. Many of these devices run stripped-down or proprietary firmware, hold little storage, and are designed to operate continuously.

Understanding these layers helps set realistic expectations for what evidence is available and how to collect it without stopping critical operations.

Challenges in SCADA Forensics

SCADA forensics has specific challenges that change how an investigation is done.

First, some field devices are not built for forensics. They often lack detailed logs, have limited storage, and run proprietary software. That makes it hard to find recorded events or to run standard acquisition tools on the device.

Second, availability matters. Many SCADA devices must stay online to keep a plant, substation, or waterworks operating. Investigators cannot simply shut everything down to image drives. This requirement forces use of live-acquisition techniques that gather volatile data while systems keep running.

Third, timing and synchronization are difficult. Distributed devices often have different clocks and can drift. That makes correlating events across a wide system challenging unless timestamps are synchronized or corrected during analysis.

Finally, organizational and legal issues interfere. Companies often reluctant to share device details, firmware, or incident records because of safety, reputation, or legal concerns. That slows development of general-purpose tools and slows learning from real incidents.

All these challenges only increase the value of SCADA forensics specialists. Salary varies by location, experience, and roles, but can range from approximately $65,000 to over $120,000 per year.

Real-world attack chain

To understand why SCADA forensics matters, it helps to look at how real incidents unfold. The following examples show how a single compromise inside the corporate network can quickly spread into the operational side of a company. In both cases, the attack starts with the compromise of an HR employee’s workstation, which is a common low-privilege entry point. From there, the attacker begins basic domain reconnaissance, such as mapping users, groups, servers, and RDP access paths. 

Case 1

In the first path, the attacker discovers that the compromised account has the right to replicate directory data, similar to a DCSync privilege. That allows the extraction of domain administrator credentials. Once the attacker holds domain admin rights, they use Group Policy to push a task or service that creates a persistent connection to their command-and-control server. From that moment, they can access nearly every machine in the domain without resistance. With such reach, pivoting into the SCADA or engineering network becomes a matter of time. In one real scenario, this setup lasted only weeks before attackers gained full control and eventually destroyed the domain.

Case 2

The second path shows a different but equally dangerous route. After gathering domain information, the attacker finds that the HR account has RDP access to a BACKUP server, which stores local administrator hashes. They use these hashes to move laterally, discovering that most domain users also have RDP access through an RDG gateway that connects to multiple workstations. From there, they hop across endpoints, including those used by engineers. Once inside engineering workstations, the attacker maps out routes to the industrial control network and starts interacting with devices by changing configurations, altering setpoints, or pushing malicious logic into PLCs.

Both cases end with full access to SCADA and industrial equipment. The common causes are poor segmentation between IT and OT, excessive privileges, and weak monitoring.

Frameworks and Methodologies

A practical framework for SCADA forensics has to preserve evidence and keep the process safe. The basic idea is to capture the most fragile, meaningful data first and leave more invasive actions for later or for offline testing.

Start with clear roles and priorities. You need to know who can order device changes, who will gather evidence, and who is responsible for restoring service. Communication between operations and security must be planned ahead of incidents.

As previously said, capture volatile and remote evidence first, then persistent local data. This includes memory contents, current register values, and anything stored only in RAM. Remote evidence includes network traffic, historian streams, and operator session logs. Persistent local data includes configuration files, firmware images, and file system contents. Capturing network traffic and historian data early preserves context without touching the device.

A common operational pattern is to use lightweight preservation agents or passive sensors that record traffic and key events in real time. These components should avoid any action that changes device behavior. Heavy analysis and pattern matching happen later on copies of captured data in a safe environment.

When device interaction is required, prefer read-only APIs, documented diagnostic ports, or vendor-supported tools. If hardware-level extraction is necessary, use controlled methods (for example JTAG reads, serial console captures, or bus sniffers) with clear test plans and safety checks. Keep detailed logs of every command and action taken during live acquisition so the evidence chain is traceable.

Automation helps, but only if it is conservative. Two-stage approaches are useful, where stage one performs simple, safe preservation and stage two runs deeper analyses offline. Any automated agent must be tested to ensure it never interferes with real-time control logic.

SCADA Network Forensics

Network captures are often the richest, least disruptive source of evidence. Packet captures and flow data show commands sent to controllers, operator actions, and any external systems that are connected to the control network.

Start by placing passive capture points in places that see control traffic without being in the critical data path, such as network mirrors or dedicated taps. Capture both raw packets and derived session logs as well as timestamps with a reliable time source.

Protocol awareness is essential. We will cover some of them in the next article. A lot more will be covered during the course. Industrial protocols like Modbus, DNP3, and vendor-specific protocols carry operational commands. Parsing these messages into readable audit records makes it much easier to spot abnormal commands, unauthorized writes to registers, or suspicious sequence patterns. Deterministic models, for example, state machines that describe allowed sequences of messages, help identify anomalies. But expect normal operations to be noisy and variable. Any model must be trained or tuned to the site’s own behavior to reduce false positives.

Network forensics also supports containment. If an anomaly is detected in real time, defenders can ramp up capture fidelity in critical segments and preserve extra context for later analysis. Because many incidents move from corporate IT into OT networks, collecting correlated data from both domains gives a bigger picture of the attacker’s path

Endpoint and Device Forensics

Field devices are the hardest but the most important forensic targets. The path to useful evidence often follows a tiered strategy, where you use non-invasive sources first, then proceed to live acquisition, and finally to hardware-level extraction only when necessary.

Non-invasive collection means pulling data from historians, backups, documented export functions, and vendor tools that allow read-only access. These sources often include configuration snapshots, logged process values, and operator commands.

Live acquisition captures runtime state without stopping the device. Where possible, use the device’s read-only interfaces or diagnostic links to get memory snapshots, register values, and program state. If a device provides a console or API that returns internal variables, collect those values along with timestamps and any available context.

If read-only or diagnostic interfaces are not available or do not contain the needed data, hardware extraction methods come next. This includes connecting to serial consoles, listening on fieldbuses, using JTAG or SWD to read memory, or intercepting firmware during upload processes. These operations require specialized hardware and procedures. It must be planned carefully to avoid accidental writes, timing interruptions, or safety hazards.

Interpreting raw dumps is often the bottleneck. Memory and storage can contain mixed content, such as configuration data, program code, encrypted blobs, and timestamps. But there are techniques that can help, including differential analysis (comparing multiple dumps from similar devices), data carving for detectable structures, and machine-assisted methods that separate low-entropy (likely structured) regions from high-entropy (likely encrypted) ones. Comparing captured firmware to a known baseline is a reliable way to detect tampering.

Where possible, create an offline test environment that emulates the device and process so investigators can replay traffic, exercise suspected malicious inputs, and validate hypotheses without touching production hardware.

SCADA Forensics Tooling

Right now the toolset is mixed. Investigators use standard forensic suites for control-center hosts, packet-capture and IDS tools extended with industrial protocol parsers for networks, and bespoke hardware tools or vendor utilities for field devices. Many useful tools exist, but most are specific to a vendor, a protocol, or a device family.

A practical roadmap for better tooling includes three points. First, create and adopt standardized formats for logging control-protocol events and for preserving packet captures with synchronized timestamps. Second, build non-disruptive acquisition primitives that work across device classes, ways to read key memory regions, configuration, and program images without stopping operation. Third, develop shared anonymized incident datasets that let researchers validate tools against realistic behaviors and edge cases.

In the meantime, it’s important to combine several approaches, such as maintaining high-quality network capture, work with vendors to understand diagnostic interfaces, prepare hardware tools and safe extraction procedures, while documenting everything. Establish and test standard operating procedures in advance so that when an incident happens the team acts quickly and consistently.

Conclusion

Attacks on critical infrastructure are rising, and SCADA forensics still trails IT forensics because field devices are often proprietary, have limited logging, and cannot be taken offline. We showed those gaps and gave practical actions. You will need to preserve network and historian data early, prefer read-only device collection, enforce strict IT/OT segmentation, reduce privileges, and rehearse incident response to protect those systems. In the next article, we will look at different protocols to give you a better idea of how everything works.

To support hands-on learning, our 3-day SCADA Forensics course starts in November that uses realistic ICS network topologies, breach simulations, and labs to teach how to reconstruct attack chains, identify IOCs, and analyze artifacts on PLCs, RTUs, engineering workstations and HMIs. 

During the course you will use common forensic tools to complete exercises and focus on safe, non-disruptive procedures you can apply in production environments. 

Learn more: https://hackersarise.thinkific.com/courses/scada-forensics

The post SCADA (ICS) Hacking and Security: An Introduction to SCADA Forensics first appeared on Hackers Arise.

Welcome back, cyberwarriors.

This is the final part in our series on SCADA hacking. We continue diving into operations conducted by the Cyber Cossacks, a unit formed by OTW at the request of the Ukrainian government. These missions were carried out together with various Ukrainian hacker groups across the country. In unity we are strong!

Water Utility – Voronezh, Russia

Voronezh Water Utility is a major regional provider serving more than 1,050,000 residents in the city and nearby areas. The utility sources raw water from the Voronezh River and treats it at two large plants equipped with sand filtration, UV disinfection, and chemical dosing units. The final product is distributed through a network of over 1,200 kilometers of pipes. A separate system handles wastewater collection and purification using a mix of mechanical and biological treatment stages. Federal guidelines set strict standards, and the utility operates under regulatory oversight from Rosprirodnadzor and Rospotrebnadzor.

The utility’s infrastructure includes multiple SCADA workstations, PLC units at pump stations, telemetry relays at water towers, and a central monitoring hall. Around 300 employees manage operations, including remote inspections and data logging.

In late 2024, one of their employees clicked on a malicious email disguised as an equipment upgrade notice. This gave us access to the corporate network. From there, we moved laterally, bypassing internal firewalls and accessing the SCADA servers. For several weeks, the purification process had been deliberately altered during the night, with the aim of contaminating the water supply with chemicals. It took them weeks to notice the suspicious system’s behavior on several machines. When the engineers logged in to investigate, they found control applications locked and SCADA databases wiped clean.

Recovery required specialist teams from Moscow. They came to rebuild the infrastructure.

Ice Arena – St. Petersburg, Russia

The Ice Arena Sports Complex in St. Petersburg is a major hub for ice sports and public recreation. The building is often used for regional tournaments, youth training camps, and figure-skating events. The rinks are kept operational by an industrial-grade refrigeration system controlled by a SCADA platform that adjusts compressors, chillers, and air handlers.

In 2024, we launched a targeted spear-phishing campaign against front-desk staff, posing as event organizers. One employee took the bait, allowing us to infiltrate the internal network. From there, we accessed the SCADA subnet. At night we remotely shut down the compressors and chilled-water pumps. Within hours, ice temperatures rose, creating soft patches and melting zones.

We also managed to manipulate air circulation systems, flooding locker rooms with freezing air and locking operators out of the control systems. The attack happened just before a regional competition, throwing event schedules into chaos. Finally, technicians decided to isolate the SCADA servers physically. But we had already embedded a scheduled wiper, programmed to delete everything a few days later.

For deeper compromise, you can implant a hidden service that runs silently with SYSTEM privileges. Over time, this infects off-site backups, ensuring every recovery attempt carries the malware forward.

Business Center – Moscow, Russia

Located on Vasilisy Kozhinoy Street in western Moscow, this big business center houses tech startups, consulting firms, and shared office tenants. The building has a digital elevator system, climate controls, RFID access gates, and a surveillance network. The control systems are maintained remotely by a contracted service provider.

Once in, we accessed the SCADA controls for the elevator system. All the elevators were halted using an emergency-stop command. Simultaneously, we revoked credentials for the operator consoles.

It must be tough to get stuck between floors. The team had no access to real-time diagnostics, leading to delays and significant disruptions across the building.

Water Utility – Petrozavodsk, Russia

Petrozavodsk, the capital of the Republic of Karelia, depends on its central water utility to draw and process water from Lake Onega. The system covers thousands of households, several public institutions, and light industrial sites.

During our operation, we gained access through an insecure VPN channel used by contractors for remote troubleshooting. Then closed several critical vault valves and increased pressure across specific districts, overwhelming older pipes to cause bursts and leaks throughout the city.

With no access to real-time telemetry, emergency services had to rely on manual inspections. Water distribution was unstable for days, especially in industrial zones.

Boiler House – Pervouralsk, Russia

In the industrial town of Pervouralsk, one gas-fired boiler house supports a nearby residential complex. The system includes four small-capacity boilers, each with its own control loop managed via SCADA terminals. Operators can toggle between automatic and manual modes, monitor temperatures, and adjust draft fan speeds.

After breaching the control room through remote desktop access we forced all systems into emergency shutdown. Then, by simulating erratic ignition cycles, we forced feed-water temperatures to exceed safe thresholds. The system’s draft fans failed, and district supply temperatures dropped sharply.

Residents could notice no heating within hours. With the SCADA terminals unresponsive and all settings scrambled, technicians could not reboot the system properly. A full reset required factory assistance and downtime of several days.

Water Utility – Samara, Russia

Samara is a key city along the Volga River, home to over a million residents and a wide industrial base. The city’s water utility handles sourcing, purification, and distribution across residential, commercial, and public service zones. A large SCADA system tracks flow rates, water levels, and chlorine dosing at treatment sites.

Within hours, we deployed ransomware that encrypted all control software, telemetry dashboards, and server logs. Operators had no access to chemical dosing data or pump controls.

The utility switched to manual modes, which involved teams physically inspecting and operating equipment. While crews were working on reactivation, residents had water quality issues. Backup systems proved inadequate, as ransomware had infected shared network storage.

Gas Stations – Russia

In August 2024, we launched one of our most effective SCADA attacks against fuel distribution systems across Russia. A separate article covers the campaign in full, but here we’ll revisit the SCADA environment itself. The compromised SCADA software was developed by a regional contractor and deployed in dozens of fueling stations. One remote management port (TCP 50000) was left exposed. It used basic authentication and featured a command-line interface for basic status control via commands like ps. The interface had a hidden command injection feature that poorly sanitized input.

We used this to run commands and establish reverse shells.  Having cracked the passwords, we found out that the default credentials are used across many stations. Ultimately, we compromised over 60 fueling stations, including some in annexed Crimea.

Some gas stations were completely bricked. Others remain under our control, proxying traffic for intelligence and routing during the ongoing cyberwarfare. Their infrastructure now works against them.

Conclusion

It’s been a wild ride, from freezing homes in St. Petersburg and cutting off water in small villages to shutting down elevators in Moscow and tampering with oil and gas controls. We hope you liked this series. If SCADA hacking is your thing, go check out OTW’s SCADA hacking course. Keep sharpening your skills, stay curious about how systems really work, and be safe out there. Until the next operation!