Operational technology asset owners should realise the benefits of red teaming, write Daniel Kapellmann Zafra – Threat Analysis Manager, Mandiant Threat Intelligence, pictured; Ken Proska – Threat Analyst, Mandiant Threat Intelligence; and Mark Heekin – Senior Consultant, at the cyber firm Mandiant.
Red teaming is an essential part of maintaining an effective cybersecurity posture by lifting the lid on systems and processes for security teams to have a better view of the weaknesses and vulnerabilities which threaten their organisation. However, operational technology (OT) asset owners have historically considered red teaming of OT and industrial control system (ICS) networks to be too risky due to the potential for disruptions or adverse impact to production systems. While this mindset has remained largely unchanged for years, Mandiant’s experience in the field suggests that these perspectives are beginning to change.
This increasing willingness to red team OT is likely driven by a couple of factors, including the growing number and visibility of threats to OT systems, the increasing adoption of IT hardware and software into OT networks, and OT security teams becoming more sophisticated. In this article, we will discuss our approach to red teaming using a case study of “Big Steam Works” (the name of the company has been redacted but the techniques applied remain the same). It will highlight how we create realistic threat scenarios which defenders of the organisation can use as a training exercise to have visibility of their OT environment to better mitigate the impact of attacks and safeguard their assets.
Method
Mandiant’s approach to red teaming OT production systems consists of two phases: active testing on IT and/or OT intermediary systems, and custom attack modelling to develop one or more realistic attack scenarios. Our approach is designed to mirror the OT-targeted attack lifecycle—with active testing during the initial stages (initial compromise, establish foothold, escalate privileges, and internal reconnaissance), and a combination of active/passive data collection and custom threat modelling to design feasible paths an attacker would follow to complete the mission.
OT red teaming can be scoped in different ways depending on the target environment, the organisation’s goals, and the asset owner’s cyber security program maturity. For example, some may test the full network architecture, while others prefer to sample only an attack on a single system or process. This type of sampling is useful for organisations that own a large number of processes and are unlikely to test them one by one, but instead, they can learn from a single-use case that reflects target-specific weaknesses and vulnerabilities.
Case study: “Big Steam Works”
To illustrate this method in practice, Mandiant was tasked with gaining access to critical control systems and designing a destructive attack in an environment where industrial steaming boilers are operated with a Distributed Control System (DCS). In this description, the customer information has been redacted—including the name, which we refer to as “Big Steam Works”—and sensitive details have been altered. However, the overall attack techniques remain unchanged. The main objective of Big Steam Works is to deliver steam to a nearby chemical production company.
For the scope of this red team, the customer wanted to focus entirely on its OT production network. We did not perform any tests in IT networks and instead began the engagement with initial access granted in the form of a static IP address in Big Steam Work’s OT network. The goal of the engagement was to deliver consequence-driven analysis exploring a scenario that could cause a significant physical impact on both safety and operations. Following our red teaming approach, the engagement was divided into two phases: active testing across IT and/or OT intermediary systems, and custom attack modelling to predict paths attackers may follow to complete their mission.
During the active testing phase, we leveraged publicly accessible offensive security tools (including Wireshark, Responder, Hashcat, and CrackMapExec) to collect information, escalate privileges, and move across the OT network. In close to six hours, we achieved administrative control on several Big Steam Works’ OLE for Process Control (OPC) servers and clients in their DCS environment.
The second phase of Custom Attack Modelling was performed for roughly a week, where Mandiant gathered additional information from client documentation and research on industrial steaming boilers. We then mirrored the process an attacker would follow to design a destructive attack on the target process given the results achieved during phase one. At this point of the intrusion, the attacker would have already obtained complete control over Big Steam Works’ OPC clients and servers, gaining visibility and access to the DCS environment. It’s worth saying that before defining the path to follow, the attacker would likely have to perform further reconnaissance (eg. compromising additional systems, data, and credentials within the Big Steam Works DCS environment).
Our next step was to develop the custom scenario. For this example, we were tasked with modelling a case where the attacker was attempting to create a condition that had a high likelihood of causing physical damage and disruption of operations. In this scenario, the attacker attempted to achieve this by lowering the water level in a boiler drum below the safe threshold while not tripping the burner management system or other safety mechanisms. If successful, this would result in rapid and extreme overheating in the boiler. Opening the feedwater valve under such conditions could result in a catastrophic explosion.
The model presented one feasible combination of actions that an attacker could perform to access devices governing the boiler drum and modify the water level while remaining undetected. With the level of access obtained from phase one, the attacker would likely be able to compromise engineering workstations (EWS) for the boiler drum’s controller using similar tools. This would likely enable the actor to perform actions such as changing the drum level setpoints, modifying the flow of steam scaling, or modifying water flow scaling. While the model does not reflect all additional safety and security measures that may be present deeper in the process, it does account for the attacker’s need to modify alarms and control sensor outputs to remain undetected.
By connecting the outcomes produced in the test to the potential physical impacts and motivations involved in a real attack, this model provided Big Steam Works with a realistic overview of cyber security threats to a specific physical process. Further collaboration with the customer enabled us to validate the findings and support the organisation to mitigate the risks reflected in the model.
This approach presents realistic scenarios based upon technical evidence of intrusion activity on OT intermediary systems in the tested network. In this way, it is tailored to support consequence-driven analysis of threats to specific critical systems and processes. This enables organisations to identify attack scenarios involving digital assets and determine safeguards that can best help to protect the process and ensure the safety of their facilities. By conducting these scenarios regularly, many OT asset owners will find themselves with a considerably improved security posture.
