Since the publication of the SolarWinds attack in December 2020, there have been countless breakdowns of the malware used, how it works, and what the implications are for organizations using Orion products in their IT infrastructure. As extensive as the coverage of the attack has been, we haven’t heard much regarding the risk posed to operational technology (OT) networks and systems by this attack. In this article, we will cover a summary of the attack with some basic, easily digestible, details as well as explore how it can impact OT systems in a hypothetical attack scenario. The SUNBURST malware attack on SolarWinds clients was implemented by injecting malicious code into the Orion platform’s software updates, which compromised their products that received these updates. The attacker could then send commands to the affected software to perform tasks such as file transfer and execution, system profiling, and disabling of system services.
How the SolarWinds malware works
Once the compromised software update is installed, it will wait for several days before beginning its routines. The malware starts by generating a hash from system information such as driver paths and process and service names, which will be checked against a list of known antivirus, monitoring, and other security software. If any of these are detected, services will be disabled one by one until a hash containing no blocked values can be created. The hash will then then be appended as a subdomain to one of the following:
.appsync-api.eu-west-1[.]avsvmcloud[.]com .appsync-api.us-west-2[.]avsvmcloud[.]com .appsync-api.us-east-1[.]avsvmcloud[.]com .appsync-api.us-east-2[.]avsvmcloud[.]com
The malware will then ‘phone home‘ by sending an HTTP request to that subdomain, which will allow our attacker to start sending commands back. Several other domains have also been detected in use with this malware, which include:
avsvmcloud.com digitalcollege.org freescanonline.com deftsecurity.com thedoccloud.com virtualdataserver.com
So far, the list of commands supported by the malware is relatively short, with only 18 commands known. However, it doesn’t take an entire library of commands to cause problems when if malware sits in a position in which Orion platform services are often found. Included are commands to both write to and delete files that can be accessed from the Orion server, which places both the integrity and availability of data in immediate jeopardy on infected networks. Tasks can also be killed or started, which could allow the attacker to take control of processes that have been previously whitelisted or otherwise unmonitored.
Like other network management and monitoring products, Orion relies on Simple Network Management Protocol (SNMP) to collect information and modify behavior of the networked devices. Compromising this puts the attacker in a position to immediately begin profiling your entire network architecture, and any security countermeasures in place. From there, the target asset(s), which can range from file and database servers to IoT devices, as well as any security measures such as firewalls and traffic monitors, can be assessed to determine the next step in the attacker’s goals.
An infected OT network scenario
The implications of an infection of this nature on an IT network can be severe. However, the compromise of an OT network introduces new consequences and impacts that can threaten safety, the environment, and even human life.
OT protocols were by and large created with uptime and availability in mind, in a time where cyber-attacks did not present a prevalent threat. Once access to an OT network is established, an advanced attacker will have multiple tools at their disposal for both the observation and disruption of OT protocols.
Imagine, if you will, a turbine power plant which uses the SolarWinds Orion suite for their IT (but not OT) network management, and the update containing the malicious payload was installed
- Once the malware is ‘activated‘, our attacker begins scanning the network, only to find that the SCADA system controlling plant operation is on a separate network. What they did find, however, is that plaintext FTP is being used to transmit data between the enterprise and production network, which transmits the credentials unencrypted, as well as the data. After collecting the credentials of several users, the attacker uses them to attempt Windows logins, and while not all of the users share passwords between FTP and Windows, one of those that do is an engineer who has full access to the OT network from their workstation.
- So now our attacker has access to the OT network, which they can silently monitor to find connected devices and identify the OT protocols being used.
- We find that the Modbus protocol, a well-known protocol that can be easily manipulated, is being used to transmit critical operational data to PLC‘s ensuring safe operation.
- Suppose that one of these Modbus devices is transmitting steam pressure data back to the PLC, which needs to be kept at an optimal level to ensure both safe and productive operation. While the pressure inside the turbine is stable initially, the PLC begins to receive input of lower pressure.
- To which it responds by increasing the steam flow to the turbine, causing the actual pressure to increase past safe and intended values, ultimately resulting in a catastrophic failure of the turbine.
- If we are lucky, no workers were close to the turbine in question, nobody was hurt, and our only immediate problem is the downtime caused by the supposed mechanical failure. However, if the data manipulation was not detected by any network safety and security solutions, the attacker may be able to strike again in a similar fashion, indefinitely jeopardizing both the safety of plant employees and the ability of the plant to operate reliably going forward.
Our hypothetical network
To paint a better picture of this attack scenario, I’ve included a diagram of our hypothetical target network, with the arrows showing the path taken from the internet to the industrial assets being manipulated, and corresponding numbers to the above scenario to visualize the order of operations here:
While it can be difficult to anticipate compromises of the software, we use to run our businesses, the risk can be mitigated with the careful implementation of holistic security strategies, such as well-defined access control, network segmentation, and restriction of HTTP traffic to and from external hosts.
Additional indicators of compromises
Additional known indicators of compromise (IOCs) include the following SHA256/SHA1 hashes:
Found in the following files:
C:\Program Files (x86)\N-able Technologies\Windows Software Probe\bin\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\Solarwinds\Network Topology Mapper\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\Solarwinds\Network Topology Mapper\Service\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\DPI\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\NCM\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\Interfaces.Discovery\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\DPA\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\HardwareHealth\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\Interfaces\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\NetFlowTrafficAnalysis\SolarWinds.Orion.Core.BusinessLayer.dll C:\Program Files (x86)\SolarWinds\Orion\NPM\SolarWinds.Orion.Core.BusinessLayer.dll
For further reading:
- Cybersecurity visibility across the organization, a case study
- Design for Security – Why Proper Architecture Matters to ICS Security
About Jonathan Bundy
Jonathan Bundy is an industrial cybersecurity consultant. He joined ThreatGEN in 2021 after several years as a systems administrator and security analyst for some of the largest names in the web hosting industry. He is passionate about meeting the always evolving challenge of security through honest, thorough evaluation of risk, and sound network design.
About ThreatGEN Threat Services
Founded in Sugar Land, Texas in 0217, ThreatGEN delivers a solution to bridge the Operational Technology (OT) Cybersecurity skills gap” utilizing its ThreatGEN® Red vs. Blue gamification and ThreatGEN Services.
ThreatGEN Services are delivered worldwide by world-renowned OT cybersecurity experts (we literally wrote the books industry uses) using strategically chosen partnerships to create a holistic service offering. The division is led by Pascal Ackerman.