The malware campaign known as Dragonfly has surprised those of us concerned with industrial cyber security on several fronts. Initially, it was notable as the first malware since Stuxnet in 2010 to specifically target Industrial Control Systems (ICS) components.
Then, research done by Joel Langill of RedHat Cyber, showed that its target was most likely the pharmaceutical industry, rather than the energy industry as initially reported. This represented the first time that a sophisticated attack vector had gone after the discrete manufacturing sector.
Next, although Dragonfly collected information on industrial control systems, it did not harm these systems. Instead, it gathered information for the likely purposes of counterfeiting or competitive intelligence. (It would, nonetheless, be easy for its creators to modify its modules for destructive purposes in the future.)
Dragonfly was also remarkable because of the devious methods and pathways it took to get to the control system. Joel coined the apt term “Offense in Depth” to describe the diversified arsenal of attack vectors it employed.
Today, we are releasing the final two parts of our white paper on Dragonfly. These are Part C – Assessing the Consequences and Part D – Defending Industrial Control Systems. These analyses reveal another concerning aspect of Dragonfly, in particular how “usual” security solutions would not have defended against it. Thankfully though, there are techniques and products available to defend against it.
The Dragonfly malware campaign used devious Offense in Depth techniques to access control systems. While “usual” security solutions would not have defended against it, there are techniques and products that would have been effective.
The Impact of Dragonfly on ICS Systems
Let’s be clear, Dragonfly did not directly impact the performance of ICS systems and did not install malware on mission-critical ICS devices. Instead, it installed its malware on HMIs and engineering stations that would have had direct connections to critical process assets. The ultimate consequence of its attacks was likely the theft of valuable proprietary information.
Having said that, there are lessons to be learned for any security risk assessment. In particular, it is very useful to understand how the techniques and breaches the Dragonfly attackers used could potentially damage manufacturing systems in the future. These included:
- Allowing malicious code to be executed on the systems by users not authorized to do things such as install or update applications. This made it possible for any user – be it engineer or operator – to install damaging software on any industrial system regardless of the permissions officially granted to them.
- Establishing persistence on internal ICS hosts, especially mobile and remote access computers, to take advantage of the Internet access these computers may have on occasion.
- Focusing on Windows XP-based computers, which are widely used by industry, difficult to migrate away from and now impossible to patch.
- Extracting sensitive information, such as passwords, that could be re-used at a later time to allow unauthorized remote access to critical systems.
- Exploiting trusted and authorized remote access systems (used by suppliers or maintenance groups) to give the attackers a pathway to multiple control systems.
- Demonstrating a proof-of-concept for providing unauthorized write access to control functions, in this case using the OPC protocol.
- Exploiting the trust end users have for software products supplied by ICS vendors in order to bypass security controls, such as whitelisting and antivirus software.
Ineffective Defenses Against Dragonfly: Software Whitelisting and Blacklisting
Dragonfly’s operators were particularly devious in the ways they used “insider” tactics to penetrate their victims’ ICS. They had innocent authorized personnel initiate their actions in each phase of the attack, using components obtained from trusted suppliers and “assumed” authentic.
As a result, many common security measures were ineffective against Dragonfly. For example, consider application whitelisting (AWL). It is one of the most commonly proposed solutions to defend against today’s sophisticated threat actors.
Dragonfly was able to bypass AWL because it trojanized software from credible ICS vendors. Users thought the software they were installing was legitimate and, thus, would have deliberately disabled their AWL defenses when installing upgrades.
In theory, this “window of opportunity” for malware to bypass AWL controls can be countered by using traditional antivirus (AV) or “blacklisting” applications. Unfortunately, the leading AV suppliers did not release signatures for the malware until mid-2014, past the peak window of activity for Dragonfly.
Effective Defenses Against Dragonfly: Network and Application Whitelisting
Unlike application whitelisting, the concept of network whitelisting is to tightly control the types of messages any device or computer can send or receive on a network. At its most basic, a computer might have host firewall rules to limit the TCP and UDP port numbers it can send or receive to only those protocols needed for proper ICS operation. This is a limited defense, however, because if the computer is compromised by malware, then it’s likely its firewall settings will be changed to open up network access.
For this reason, it is recommended network whitelisting be managed externally from any device that might be an attractive attack entry point (such as computers used for remote access). To achieve this external control of traffic, a transparent or bridged firewall, like the Hirschmann Industrial Security Router or Tofino Industrial Network Security Appliance, can be very effective.
TCP/IP rules in these devices can tightly limit what the computer can transmit into the network and who it can talk to. Security devices can also warn when the computer suddenly tries to send new protocols or scan new ICS devices. In the case of Dragonfly, the traffic its protocol scanning modules sent would have been an immediate indication that something was very wrong on the ICS network.
Effective Defenses Against Dragonfly: Protocol Whitelisting
TCP/IP level network whitelisting also has limitations. This method of whitelisting only blocks unauthorized protocols from entering the network. It does not provide the ability to limit the functions that each of these protocols can perform.
This requires the ability to filter based not only on the TCP and UDP ports used, but also the actual high-level application content. Deployed on a network, this is commonly referred to as Deep Packet Inspection (DPI), and it provides the ability to restrict messages on the network to those performing approved functions, such as reading a specific PLC register.
For example, a controls engineer may use DPI to limit Modbus/TCP functions to read-only services to a critical PLC. This requires a device that can be installed in industrial environments and has application awareness of the industrial protocols used.
Such devices are typically deployed close to the equipment they are protecting. The Tofino Industrial Network Security Appliance is specifically designed to provide this capability and supports a wide range of industrial protocols. It has the ability to limit function codes and services (such as read-only, read-write, no programming, etc.), plus limit the device registers or objects accessed over the network.
Defending Industrial Control Systems from Threats like Dragonfly
The defenses listed above are but a few of the ineffective and effective defenses for Dragonfly that are described in Part D of the white paper available below. Each defense is described in detail and the paper also includes a summary of ineffective and effective defenses for quick reference.
Eric Byres has this conclusion about how organizations need to defend themselves from advanced persistent threats:
“If Dragonfly has taught us anything, it is that when defending ICS systems from today's sophisticated attackers, the ‘usual’ security solutions may not be the right security solutions. Technologies and procedures like Restricted User Accounts, Patching and VPNs actually played into the attackers’ hands.
“Instead of deploying security policies because ‘everyone does it this way’ or the ‘check list tells us to,’ ICS security needs to be evaluated on a holistic risk basis. And in that analysis, we have to assume that the bad guys will breach our defenses at some point.
“Preventing breaches is desirable, but being able to detect and address a breach rapidly and effectively will prove to be a more important capability for every industrial company in the next few years.”
Although Dragonfly had the means to damage critical control systems, the good news is that there are techniques and technologies that can be used to defend against advanced malware campaigns. To learn about them, download the white paper below.What are your thoughts on defending against threats like Dragonfly? Has this malware changed your approach to Defense in Depth? I look forward to hearing from you.
Additional Materials on Dragonfly
- RedHat Cyber home page: Cyber Security Services for Industrial Control Systems
- Blog: How Dragonfly Hackers and RAT Malware Threaten ICS Security
- Press Release: Belden Research Reveals Dragonfly Malware Likely Targets Pharmaceutical Companies
- Blog: A New Era for ICS Security – Dragonfly Introduces Offense in Depth
Related Cyber Security Topics
- White paper download webpage: Understanding Deep Packet Inspection for SCADA Security
- White paper download webpage: Windows XP End of Service: Practical Options for Industrial Applications
- Blog: Patching Has Its Place in SCADA and ICS Security
Partial List of Belden Products for Defense in Depth