Cybersecurity Advisory Warns Against Threats That Can Gain Full Access to ICS/SCADA Devices
The Department of Energy (DOE), the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) yesterday released this joint Cybersecurity Advisory to warn that certain advanced persistent threat (APT) actors have exhibited the capability to gain full system access to multiple industrial control system (ICS)/SCADA devices, including:
- Schneider Electric programmable logic controllers (PLCs),
- OMRON Sysmac NEX PLCs, and
- Open Platform Communications Unified Architecture (OPC UA) servers.
The APT actors have developed custom-made tools for targeting ICS/SCADA devices. The tools enable them to scan for, compromise, and control affected devices once they have established initial access to the operational technology (OT) network. Additionally, the actors can compromise Windows-based engineering workstations, which may be present in information technology (IT) or OT environments, using an exploit that compromises an ASRock motherboard driver with known vulnerabilities. By compromising and maintaining full system access to ICS/SCADA devices, APT actors could elevate privileges, move laterally within an OT environment, and disrupt critical devices or functions.
DOE, CISA, NSA, and the FBI urge critical infrastructure organizations, especially Energy Sector organizations, to implement the detection and mitigation recommendations provided in this CSA to detect potential malicious APT activity and harden their ICS/SCADA devices.
Click here for a PDF version of this report.
Technical Details
APT actors have developed custom-made tools that, once they have established initial access in an OT network, enables them to scan for, compromise, and control certain ICS/SCADA devices, including the following:
- Schneider Electric MODICON and MODICON Nano PLCs, including (but may not be limited to) TM251, TM241, M258, M238, LMC058, and LMC078;
- OMRON Sysmac NJ and NX PLCs, including (but may not be limited to) NEX NX1P2, NX-SL3300, NX-ECC203, NJ501-1300, S8VK, and R88D-1SN10F-ECT; and
- OPC Unified Architecture (OPC UA) servers.
The APT actors’ tools have a modular architecture and enable cyber actors to conduct highly automated exploits against targeted devices. The tools have a virtual console with a command interface that mirrors the interface of the targeted ICS/SCADA device. Modules interact with targeted devices, enabling operations by lower-skilled cyber actors to emulate higher-skilled actor capabilities.
The APT actors can leverage the modules to scan for targeted devices, conduct reconnaissance on device details, upload malicious configuration/code to the targeted device, back up or restore device contents, and modify device parameters.
In addition, the APT actors can use a tool that installs and exploits a known-vulnerable ASRock-signed motherboard driver, AsrDrv103.sys, exploiting CVE-2020-15368 to execute malicious code in the Windows kernel. Successful deployment of this tool can allow APT actors to move laterally within an IT or OT environment and disrupt critical devices or functions.
APT Tool for Schneider Electric Devices
The APT actors’ tool for Schneider Electric devices has modules that interact via normal management protocols and Modbus (TCP 502). Modules may allow cyber actors to:
- Run a rapid scan that identifies all Schneider PLCs on the local network via User Datagram Protocol (UDP) multicast with a destination port of 27127 (Note: UDP 27127 is a standard discovery scan used by engineering workstations to discover PLCs and may not be indicative of malicious activity);
- Brute-force Schneider Electric PLC passwords using CODESYS and other available device protocols via UDP port 1740 against defaults or a dictionary word list (Note: this capability may work against other CODESYS-based devices depending on individual design and function, and this report will be updated as more information becomes available);
- Conduct a denial-of-service attack to prevent network communications from reaching the PLC;
- Sever connections, requiring users to re-authenticate to the PLC, likely to facilitate capture of credentials;
- Conduct a ‘packet of death’ attack to crash the PLC until a power cycle and configuration recovery is conducted; and
- Send custom Modbus commands (Note: this capability may work against Modbus other than in Schneider Electric PLCs).
APT Tool for OMRON
The APT actors’ tool for OMRON devices has modules that can interact by:
- Scanning for OMRON using (Factory Interface Network Service (FINS) protocol;
- Parsing the Hypertext Transfer Protocol (HTTP) response from OMRON devices;
- Retrieving the media access control (MAC) address of the device;
- Polling for specific devices connected to the PLC;
- Backing up/restoring arbitrary files to/from the PLC; and
- Loading a custom malicious agent on OMRON PLCs for additional attacker-directed capability.
Additionally, the OMRON modules can upload an agent that allows a cyber actor to connect and initiate commands—such as file manipulation, packet captures, and code execution—via HTTP and/or Hypertext Transfer Protocol Secure (HTTPS).
APT Tool for OPC UA
The APT actors’ tool for OPC UA has modules with basic functionality to identify OPC UA servers and to connect to an OPC UA server using default or previously compromised credentials. The client can read the OPC UA structure from the server and potentially write tag values available via OPC UA.
Mitigations
Note: these mitigations are provided to enable network defenders to begin efforts to protect systems and devices from new capabilities. They have not been verified against every environment and should be tested prior to implementing.
DOE, CISA, NSA, and the FBI recommend all organizations with ICS/SCADA devices implement the following proactive mitigations:
- 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 multifactor 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 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 potential malicious activity.
- Monitor systems for loading of unusual drivers, especially for ASRock driver if no ASRock driver is normally used on the system.
Resources
For additional information on securing OT devices, see
