I am currently looking at an attack path inside a mining OT environment, and the more I follow the activity, the more interesting it gets. I can’t disclose the name, so I will refer to it simply as a mining OT environment throughout this investigation. I started with a fairly simple question: how does an attacker move from an external access point into the actual industrial control environment?
I am using MITRE ATT&CK for ICS to map what I am finding, but I am not looking at the techniques as isolated entries in a framework. I am following the activity as an attack would actually unfold.
The environment I am investigating has the usual layers you would expect in a mining operation. There is the corporate IT network, an industrial DMZ, remote access infrastructure, SCADA servers, engineering workstations, HMIs, historians, PLCs, network infrastructure and field devices. Down at the process level, there are conveyors, crushers, pumps and a grinding circuit involving a SAG mill.
The first thing that caught my attention was remote access. There is a VPN gateway providing access to the environment for engineers and third-party vendors. That by itself is completely normal. A mining operation has equipment distributed across a large area and remote maintenance is operationally necessary.
What was not normal was one of the successful VPN authentications. The account belonged to an engineering user. The credentials were valid. The authentication succeeded. There was no failed-login sequence suggesting password guessing, and there was no obvious malware involved at this stage.
The problem was what happened immediately afterwards.The account authenticated through the remote-access infrastructure and established a session with an engineering workstation that it had not accessed in its recent baseline.
That was my first real indicator. So, I started looking at the workstation's network activity. Within a short period after the VPN authentication, the engineering workstation began communicating with several OT assets. Some of those connections were completely normal. The workstation regularly communicated with the SCADA infrastructure.
But then I found something different. The workstation started communicating with a PLC in another process segment. That PLC was not part of the workstation's normal communication pattern. I checked the historical traffic. The relationship was not there.
The engineering workstation had a well-established communication pattern with several controllers, but this particular PLC was not one of them. At this point, I started treating the VPN authentication and the new PLC communication as related events rather than two separate alerts.
The initial access activity maps to External Remote Services, T0822. MITRE describes the technique around using external remote services to gain access to systems within an industrial environment. But the interesting part of the investigation was not the VPN login.
It was what happened after the login. I followed the session into the engineering workstation. The workstation was legitimate. The user account was legitimate. The installed engineering software was legitimate. The PLC was legitimate. The communication protocol was legitimate. There was no obvious malicious binary sitting on the machine.
If I had looked at the individual components independently, I could easily have dismissed the activity. The sequence was different. A valid engineering account authenticated remotely.The account accessed an engineering workstation.
The workstation began communicating with an unexpected controller. The controller started receiving traffic from a source that was outside its normal communication relationship. That was enough for me to start digging deeper. I then looked at the industrial protocol traffic.
And my investigation changed. At the IP layer, I had a workstation communicating with a PLC. At the OT layer, I could see what the communication was actually doing. The workstation was not simply polling the PLC for status information.
There were write operations. That immediately changed the priority of the investigation. A read operation from an engineering workstation is expected in many environments. A write operation is different. I started comparing the activity with the historical baseline for that controller.
The PLC normally received commands from a defined set of systems. The new source was not part of that normal pattern. I then started looking at the timing. The activity was not occurring during the maintenance window associated with that equipment. There was no corresponding scheduled engineering activity. There was no change request explaining the configuration activity. There was no maintenance ticket that matched the event.
The account was valid. The workstation was valid. The PLC was valid. But the activity was not normal. This I belive is extremely important in OT. The attacker does not necessarily have to break the protocol.They can use the protocol correctly.They can send a perfectly valid command.The PLC can process that command exactly as designed.
The security problem is that the person or system issuing the command is not supposed to be doing it. I then moved from the network data to the engineering workstation.The workstation had recently accessed several systems inside the OT segment.
The sequence showed discovery activity followed by communication with control assets. That gave me another piece of the attack chain.The attacker was not simply connecting to a known PLC and immediately changing something.They were learning the environment first.
They were identifying systems.They were identifying communication relationships.They were finding which systems could reach which controllers.This is exactly the sort of activity I would expect before someone starts manipulating a physical process.
I then started looking at the PLC itself.The controller was associated with a section of the mining process connected to the material handling system.The important thing here was not simply that a PLC had been accessed.I wanted to know what the PLC controlled.
That took me down another layer.The PLC was involved in the control of equipment associated with the conveyor system.Now the network event had physical context. This was no longer: Engineering workstation → PLC. It was:Engineering workstation → PLC → conveyor control process.
That completely changes how I look at the event.I then started examining the parameter changes.One of the values being written to the controller was outside the workstation's normal engineering activity baseline.The value itself was syntactically valid.
The PLC accepted it. There was no protocol error. There was no malformed packet. There was no obvious exploitation of the PLC.The controller simply received a legitimate command and executed it.
And I found that the modify Parameter technique is particularly relevant here. The attacker is not necessarily exploiting the controller. They are modifying an operational value through the control system. I then went one step further. I checked the process telemetry. The parameter change appeared in the OT network data first. A short time later, I could see a corresponding change in the process behaviour. That correlation was important.
The cyber event and the physical process event were now connected. I was no longer investigating an anomalous PLC write. I was investigating a PLC write that had an observable effect on the physical process.
Now again I went back to the SCADA environment.The operator's HMI was still showing the process as operational.The process telemetry available to the operator did not immediately reflect the significance of the change I had identified in the underlying control activity.
I started checking the alarm configuration and reporting path. I found activity involving the reporting mechanism associated with the affected process.
Now I had another question. Was the attacker only changing the process, or were they also trying to reduce the operator's ability to see what was happening?
If I can change a process and the operator immediately sees an alarm, the defender has an opportunity to respond. If I can change the process and interfere with the visibility of that change, the response window becomes much smaller.
MITRE's ICS matrix includes techniques associated with unauthorized reporting and alarm suppression, as well as the broader Impair Process Control and Inhibit Response Function tactics.
At this stage, I started building the attack timeline. The first event was the external authentication. Then came the remote session. Then access to the engineering workstation. Then discovery of OT assets. Then communication with an unexpected PLC. Then industrial protocol write activity. Then a parameter modification. Then a corresponding change in process telemetry. Then activity affecting operator visibility.
Each event on its own was explainable. Together, they were not. This is why I think OT detection cannot depend entirely on individual alerts. A VPN login is not necessarily malicious. An engineering workstation communicating with a PLC is not necessarily malicious. A PLC write operation is not necessarily malicious. A parameter change is not necessarily malicious. An alarm configuration change is not necessarily malicious.
But put those events into one timeline and the picture changes completely. The attacker is moving through the environment. They are using legitimate credentials. They are using legitimate systems. They are using legitimate industrial protocols. They are interacting with legitimate control infrastructure. And they are eventually affecting the physical process.
I then checked whether the engineering workstation was behaving as an authorized control master. It was not part of the normal control relationship for the affected PLC.
That immediately made me look at MITRE's Rogue Master technique, T0848. The important concept here is not that the attacker has created some obviously malicious communication channel. The attacker is attempting to communicate with an industrial controller using the mechanisms normally used by legitimate control systems.
From the PLC's perspective, the command can still be valid. From the network's perspective, the traffic can still look legitimate. From the attacker's perspective, that is exactly what they want.
The controller does not understand intent. It understands commands.That is one of the fundamental differences between enterprise IT and industrial control systems. The PLC is doing exactly what it has been programmed to do. The security problem exists somewhere above that layer.
I then started looking at whether the attacker had accessed other controllers. There were additional connections from the same engineering workstation.Some were read operations. Others showed different communication patterns.
This was the point where the activity started looking like lateral movement inside the OT environment rather than a single isolated action. The attacker was not only interested in one PLC. They were mapping the control environment.
That is where the asset relationships became extremely valuable. Once I understood which PLC controlled which part of the mining process, the network activity started making much more sense. A controller associated with material handling was one thing. A controller associated with a critical grinding process was another. A controller connected to protection or safety-related functions would be even more significant.
This is why I keep saying that an OT asset inventory without process context is incomplete.
I need more than:
10.10.20.15 = PLC
I need:
10.10.20.15 = PLC Process = Material handling Controlled equipment = Conveyor section SCADA source = SCADA-02 Engineering source = ENG-04 Protocol = Industrial control protocol Normal masters = SCADA-02, ENG-04 Unexpected source = ENG-07 Observed activity = Write operation Process impact = Parameter deviation
That is the information that turns network telemetry into an investigation. Now, I started correlating the OT network data with identity, endpoint and process telemetry. The VPN authentication gave me the identity. The endpoint telemetry gave me the workstation. The network telemetry gave me the movement. The industrial protocol telemetry gave me the control action. The SCADA data gave me the process context. The historian gave me the operational timeline. None of these data sources alone gave me the complete picture. Together, they did.
And this is probably the most important thing I have found while investigating this environment. The attacker does not have to look like an attacker. The attacker can look like an engineer. The workstation can look normal. The credentials can be valid. The protocol can be legitimate. The PLC can behave exactly as designed. The HMI can continue operating. The individual events can all look ordinary. The attack becomes visible only when I connect them.
That is why I am mapping this investigation against MITRE ATT&CK for ICS rather than simply creating a list of vulnerabilities. The framework gives me a way to describe the progression. External Remote Services for the initial access. Valid Accounts for credential abuse. Discovery activity for understanding the environment. Lateral movement through trusted OT relationships. Engineering workstation access. Industrial protocol communication.
Rogue Master behaviour. Unauthorized Command Messages.Modify Parameter. Impair Process Control. And eventually the possibility of Loss of Control or Loss of View at the impact stage. What started as a suspicious VPN authentication has now turned into an OT attack investigation.
If I had looked only at the VPN, I would have seen a successful login. If I had looked only at the endpoint, I would have seen an engineer's workstation. If I had looked only at the network, I would have seen normal industrial protocol traffic. If I had looked only at the PLC, I would have seen valid commands.
If I had looked only at the HMI, the process would initially have appeared normal. It is the correlation between all of them that exposes the attack. The attack path I am seeing is therefore not simply external access to a PLC. It is identity compromise, remote access, OT discovery, engineering workstation access, control-system communication, unauthorized control activity and process manipulation.
And that is exactly why I think OT security needs to be investigated differently. In this environment, I am not asking only whether the attacker has compromised a device. I am asking what the attacker is doing with the device. I am asking whether an engineering workstation is communicating with the right PLC. Whether the right user is making the change. Whether the right master is issuing the command. Whether the command is normal for that process. Whether the parameter is within the expected operating range. Whether the operator can still see what is happening.
And most importantly, whether a seemingly legitimate cyber action is starting to change the physical process. Because once I can see that last relationship, the investigation changes completely. I am no longer looking at an IT compromise that happens to touch OT. I am looking at a cyber attack that has reached the physical process.