Executive Summary
US agencies (CISA, NSA, FBI) and Department of Energy issued a new Cybersecurity Advisory (CSA) warning on 13.04.2022 in regards to increased threats to industrial control systems (ICS) / SCADA devices. Advanced persistent threat (APT) actors have developed custom malwares that are able to scan for, compromise and control affected devices after successful initial access to the operational technology (OT) network. The tools were designed specifically for:
- Schneider Electric PLCs
- OMRON Sysmac NEX PLCs
- Open Platform Communications Unified Architecture (OPC UA) servers
Moreover, actors are capable of compromising Windows-based workstations, both in IT and OT environments, which use ASRock motherboards by exploiting their vulnerable driver. Such compromises can lead to privilege escalations and lateral movement within an OT environment and eventually cause disruption to critical devices and functions.
A lot of new malwares has started to emerge targeting the mentioned PLCs and SCADA devices.
Chernovite’s emerging PIPEDREAM malware
One specific malware was detected by Dragos that targets the same ICS / SCADA devices – it is named Pipedream. According to Dragos, Pipedream has been developed by the Chenorvite Activity Group. Pipedream should be considered as ICS Attack Framework, which can impact a wide variety of PLCs and industrial software, including specific Omron, Schneider Electric PLCs and OPC UA servers. The interesting part is though that the Pipedream was detected prior real-life deployment.
“This is a rare case of analyzing malicious capabilities before employment against victim infrastructure giving defenders a unique opportunity to prepare in advance,” Dragos said in their whitepaper.
However, Chernovite can manipulate the speed and torque of Omron servo motors used in many industrial applications, which poses a significant threat and could cause disruption or destruction of industrial processes, leading to life-threatening scenarios.
New state-sponsored tool INCONTROLLER targeting ICS
Mandiant in partnership with Schneider Electric analyzed a new cyber-attack tool, which targets ICS devices, named INCONTROLLER. The malware was built to manipulate and disrupt industrial processes. Mandiant believes that INCONTROLLER is “very likely linked to a state-sponsored group, given the complexity of the malware, the expertise and resources that would be required to build it, and its limited utility in financially motivated operations”. However, no specific attribution was made.
INCONTROLLER consists of three tools that enable the attacker to send instructions to ICS devices using industrial network protocols. Even though the tools enable the actor to communicate with a wider range of products from different OEMs, researchers unveiled modules for specific controllers from Schneider Electric and Omron. The targeted devices range from machines automation solutions to complex modular machines in distributed architectures.
The existence of modules that target specific PLCs indicates that the actor made reconnaissance efforts on their primary target(s), which lead to the reveal of the used PLCs in those environments and the development of those modules. This means that the threat actor is unlikely to target random industries.
INCONTROLLER is compared to Triton, Industroyer, and Stuxnet in the context of its disruptive and destructive capabilities.
Mitigations
Since the malwares were not spotted in the real-life deployments yet, there are no specific indicators of compromise (IOCs). However, by analyzing these malwares, a list of TTPs (refer to appendix at the end) was prepared by CISA mapped to the MITRE ICS Framework, which can be used by security teams to evaluate whether sufficient detection capabilities are in place in their environments.
Additionally, Dragos published their own actions to mitigate impact of Pipedream, which are presented in the below table. Note that even though Dragos specifically mentioned Pipedream, these actions are recommended for all environments that use Schneider Electric or Omron PLCs and wider.
Table 1 – Defending against Pipedream, credits to Dragos Inc.
| Action | Target |
| Monitor East-West ICS networks
with ICS protocol aware technologies |
Perform network traffic monitoring with a focus on East-West communications instead of simply North-South (ingress/egress) communications. PIPEDREAM’s ability to move from Engineering Workstation to PLC and then PLC to PLC means that simply monitoring North-South communications or putting emphasis on segregation will be insufficient. Specifically look for modifications to PLCs occurring outside of maintenance periods such as the changing of logic using native ICS protocols. |
| Change default credentials | Where feasible and in conjunction with operations and site personnel on Schneider Electric TM2xx series PLCs: Beginning with firmware 5.0, the devices use default credentials’ Administrator’/’Administrator’, and these should be changed to a complex password using the EcoStruxure software. |
| Restrict access to UDP/1740-1743,
TCP/1105, and TCP/11740. |
For all Schneider Electric TM2xx series PLCs |
| Restrict access to TCP/11740. | For non-Schneider PLCs known to communicate with this port from the engineering workstation |
| Validate the engineering workstation
software – EcoStruxure Machine Expert. |
Restrict the workstation from making outbound network connections, especially to Internet services. |
| PLC network telemetry analysis | Monitor for unusual interactions with PLCs from non-standard workstations or accounts. |
| Monitor affected PLCs for new outbound connections. | Look for comms to other PLCs on the network, on UDP/1740-1743, TCP/1105, and TCP/11740. |
| Disable the Schneider NetManage discovery service | In conjunction with operations and site personnel disable Schneider NetManage discovery service as it is used by CHERNOVITE to discover PLCs (see VA-2019-02) |
| Network isolation of safety systems | Ensure network isolation for safety system components, monitor safety system networks for new connections or devices, and verify all configuration changes are in compliance with change management procedures. |
| ICS-focused Incident Response Plan | Create and update an ICS-focused Incident Response Plan with accompanying Standard Operating Procedures (SOPs) and Emergency Operating Procedures (EOPs) for operating with a hampered or degraded control system. Conduct a Table Top Exercise focused on CHERNOVITE’s ICS Cyber Kill Chain with an emphasis on PIPEDREAM; use this opportunity to identify process and collection gaps that would hinder the detection and response efforts. |
| Isolate Mission Critical Skid Systems | Consider implementing hardwired I/O between critical skid systems and distributed control systems I/O in place of direct communications if feasible. |
| Spare parts inventory | Create and update a spare parts inventory for critical control system components, including hardware, software, firmware, configuration backups, and licensing information. Develop plans and procedures for sourcing and procurement of critical control system components. Consider the implementation of cold backups for rapid replacement of ICS level one devices. |
Additionally, Conscia ThreatInsights recommends some general guidelines on proactive mitigations, based on DOE, CISA, NSA, and the FBI recommendations:
- Isolate ICS/SCADA systems and networks from corporate and internet networks using strong perimeter controls, and limit any communications entering or leaving ICS/SCADA perimeters.
- Enforce multi-factor authentication for all remote access to ICS networks and devices whenever possible.
- Have a cyber incident response plan, and exercise it regularly with stakeholders in IT, cybersecurity, and operations.
- Change all passwords to ICS/SCADA devices and systems on a consistent schedule, especially all default passwords, to device-unique strong passwords to mitigate password brute force attacks and to give defender monitoring systems opportunities to detect common attacks.
- Maintain known-good offline backups for faster recovery upon a disruptive attack, and conduct hashing and integrity checks on firmware and controller configuration files to ensure the validity of those backups.
- Limit ICS/SCADA systems’ network connections to only specifically allowed management and engineering workstations.
- Robustly protect management systems by configuring Device Guard, Credential Guard, and Hypervisor Code Integrity (HVCI). Install Endpoint Detection and Response (EDR) solutions on these subnets and ensure strong anti-virus file reputation settings are configured.
- Implement robust log collection and retention from ICS/SCADA systems and management subnets.
- Leverage a continuous OT monitoring solution to alert on malicious indicators and behaviors, watching internal systems and communications for known hostile actions and lateral movement. For enhanced network visibility to potentially identify abnormal traffic, consider using CISA’s open-source Industrial Control Systems Network Protocol Parsers (ICSNPP).
- Ensure all applications are only installed when necessary for operation.
- Enforce principle of least privilege. Only use admin accounts when required for tasks, such as installing software updates.
- Investigate symptoms of a denial of service or connection severing, which exhibit as delays in communications processing, loss of function requiring a reboot, and delayed actions to operator comments as signs of potentially malicious activity.
- Monitor systems for loading of unusual drivers, especially for ASRock drivers if no ASRock driver is normally used on the system.
Additional Resources and References
For more in-depth information on specific malwares mentioned in the post, please refer to:
- CISA Cyber Tools Targeting ICS / SCADA Devices
- Chernovite’s PIPEDREAM Malware Targeting ICS
- INCONTROLLER state-sponsored ICS Tool
Additionally, please refer to following CISA guidelines on securing OT devices:
