Live Webinar:

Join us Apr. 1st for a Town Hall as Robert M. Lee shares insights from his testimony before the U.S. House of Representatives Subcommittee on Cybersecurity and Infrastructure Protection.

Skip to main content
The Dragos Blog

07.16.18 | 4 min read

Questions and Considerations from Alleged Ukraine Chemical Plant Event

Joe Slowik

On 11 July 2018, Interfax-Ukraine released a short, somewhat ambiguous, but very concerning press release from the Security Service of Ukraine (SBU) on a thwarted attack on a chlorine production plant. The plant itself appears to produce chlorine for water and wastewater treatment applications. Chlorine is a dangerous chemical, especially in industrial application concentrations, making such an attack extremely alarming.

Before proceeding further, the following statement is necessary: targeting such infrastructure, which could cause immediate harm to personnel onsite or nearby and potential longer-term civilian harm by impacting water treatment capability, represents an indefensible action. Whether applying various permutations of the Laws of War or Just War theory, this purely civilian facility represents a target that must be considered “off limits” for any party remotely hoping to maintain some level of moral justification for or ethical guidance to a conflict. This behavior is unacceptable and reprehensible.

From a technical perspective, details on the attack are maddeningly sparse. The press release provides the following:

“Specialists of the cyber security service established minutes after [the incident] that the enterprise’s process control system and system for detecting signs of emergencies had deliberately been infected by the VPNFilter computer virus originating from Russia. The continuation of the cyber attack could have led to a breakdown in technological processes and a possible accident.”

While the SBU deserves praise and credit for stopping or interdicting an alleged attack on a piece of infrastructure where a physical impact would almost certainly result in, at minimum, injuries, the provided statement raises far more questions than it answers.

Much of this ambiguity deals with the malware blamed for the event, VPNFilter. Cisco Talos led a coordinated Cyber Threat Alliance effort to disclose and defend against a rapidly-spreading firmware infection focusing on small office/home office (SOHO) network devices and some commercial equipment – with a geographic focus on Ukraine – dubbed “VPNFilter”. Cisco Talos’ original report highlights a multistage, modular malware framework targeting network devices capable of various functions, from data collection to manipulation to device self-destruction. What caught many researchers’ eyes – and which a follow-on report covered extensively- was a module designed for ICS applications.

VPNFilter contains a module designed to capture Modbus traffic, a protocol used for managing and controlling distributed field devices (generally programmable logic controllers) from a master station. Interfering with or manipulating Modbus traffic gives an adversary a number of options for manipulating devices, yet analysis from Cisco Talos as well as work internally performed at Dragos identify this module as data collection only, and even then within a very limited scope.

First, Cisco Talos, only identified the module itself in conjunction with a specific device: “This sample is a packet sniffer that is looking for basic authentication as well as monitoring ICS traffic, and is specific to the TP-LINK R600-VPN.” The device in question falls into the SOHO category, although it is possible such a device could be used in limited field deployments or remote sites even for larger, more mature organizations.

Second, the module only possesses the capability to view – not modify – traffic to a predefined IP address communicating to TCP 502. And then, only packets 150 bytes or larger are actually examined – with this size encompassing the entire TCP packet and headers, rather than just the Modbus payload. Finally, only source IP, source port, destination IP, and destination port are logged with no data recorded.

Based on some further analysis, the traffic captured would be extremely narrow with few “hits” as configured. A notable exception to this limited capture capability is that the module would likely capture engineering access requests for PLCs – a very useful item to record, except the malware is only recording connection metadata and not actual connection information. While this could be a useful mechanism for mapping an environment to identify both management nodes and managed PLCs, the way this is implemented seems unnecessarily complex for this functionality.

In any event, no known functionality of VPNFilter allows for modification or manipulation of traffic, which would be necessary to weaponize the network device implant. As noted by Cisco Talos researchers, “Very significant changes would be required to implement functionality that could modify traffic.” That of course does not mean such a disruptive module is not possible or does not exist, but no evidence is currently available identifying such a capability as part of VPNFilter.

Furthermore, the range of devices targeted by VPNFilter, although extended in Cisco Talos’ updated report, remains focused on SOHO and some lower-end enterprise/commercial networking gear. Some of these, such as the TP-LINK VPN concentrator mentioned above in conjunction with the Modbus module, would be valuable to access or profile traffic going to an ICS network where installed. But none appear related to likely legitimate applications within such environments (outside of “shadow IT” installations of non-approved gear). Even then, SBU’s report makes a claim that process equipment, not networking gear, was infected:

“…the enterprise’s process control system and system for detecting signs of emergencies had deliberately been infected by the VPNFilter computer virus…”

If this statement is true, it represents a dramatic increase in scope and capability for what we presently know about VPNFilter, as well as indicating some potential details on the operation itself. First, “deliberately” implies a malicious entity directly impacted the target device, which in turn further implies successfully penetration of the process control network rather than the victim of some wormable infector (like WannaCry). Second, the sentence begins by stating process control and (presumably) safety systems were impacted, implying multiple infections of ICS-specific gear. This goes against all that we know about VPNFilter’s capabilities to date in terms of device applicability. Essentially, VPNFilter is only known to infect various types of network gear and not embedded systems and ICS operations equipment.

It is likely, based on available evidence and knowledge of VPNFilter, that the chemical plant identified this malware on its network, but adversaries only used it within its stated capability as a traffic analysis and collection platform with limited scope for manipulation, and none for ICS-specific protocols. As such, this would provide valuable information to the attacker to prepare for a subsequent, potentially more damaging attack using unknown tools to directly impact the production or safety processes.

This is good work by SBU in stopping and identifying a potential attack-in-progress, but information released to date seems insufficient to draw any definitive conclusions. Essentially, VPNFilter as it is currently known and documented could not have been directly responsible for this attack. Instead, VPNFilter’s likely contribution to such an event comes only in an enabling, data collection role providing support for future disruptive activities. If the attacker used VPNFilter, or some close variant thereof, this represents a dramatic increase in capability and installation scope, rendering a significant number of devices in ICS environments all over the world vulnerable to a similar attack. Because of the risk involved to other infrastructure by either further attacks from the same entity as this case or “copycat” attacks if the methodology is leaked or proliferates, the ICS community must hope that SBU provides additional technical details on this event.

Ready to put your insights into action?

Take the next steps and contact our team today.