Stuxnet-like malware that is targeting industrial control systems has been uncovered by security researchers at FireEye.
The malware, named Irongate, was first submitted to VirusTotal in 2014 but appears to have gone unnoticed until it was identified in the course of FireEye’s research into droppers compiled with PyInstaller in late 2015.
Irongate bears some similarities to Stuxnet, the notorious malware that targeted Iran’s Natanz uranium enrichment facility and attacked centrifuge rotor speeds.
Siemens Product Computer Emergency Readiness Team (ProductCERT) has confirmed in a blog post published by FireEye that although this malware can operate within a simulated Siemens control system environment, it is not able to function in an operational environment.
As a result, it does not affect any product of Siemens.
Irongate is, however, able to perpetuate man-in-the-middle (MitM) attacks against process input and output and process operator software within industrial process simulators. The malware substitutes a malicious DLL to act as a broker between programmable logic controllers (PLCs) and legitimate monitoring software. The covert data transmission to the PLC is facilitated by the aforementioned DLL that captures five seconds of normal traffic from a PLC to the user interface and replaying it continuously.
Sandbox evasion is another interesting feature of this malware, convincing researchers that this is not a tool for legitimate purposes.
Five out of six python-based droppers accessed by the Irongate malware check for the existence of VMware or Cuckoo Sandbox environment and upon identification of such an environment, they keep dormant and will not deploy the .NET executable payload (scada.exe) to the host. This is clearly an attempt by the malware to avoid detection and analysis.
Comparing Irongate and Stuxnet, both look for a single and highly specific process to manipulate by replacing DLL but there are two noticeable differences between them.
Firstly, Irongate utilises sandbox evasion while Stuxnet tries to escape anti-virus detection.
Secondly, Irongate tries to hide its manipulation and presence by replying the legitimate captured traffic while Stuxnet does not.
According to FireEye, Irongate’s characteristics suggest categorising it as a proof-of-concept or a security research project but it provides insight into the importance of cryptographic verification in controlled industrial processes. Implementation of integrity check, code signing, and I/O data sanity checking mechanism could prevent manipulation in industrial solutions.
Even though Irongate has been called “in the wild” malware, Siemens’s statement of the inability of this malware to perform in an operational environment leads us to conclude that is rather more a proof-of-concept, exploring attack techniques against industrial control systems.
Irongate reminds us of the danger of failing to pay attention to threats against industrial control systems, as Dan Scali of FireEye told ThreatPost:
“We have generally not seen a lot of progress since Stuxnet to address the issues that Irongate brings up. The concern is as the capability to do these types of attacks gets easier over time we need to bolster our defenses as a counterweight.”
Mystery remains around who might have been responsible for creating the Irongate malware.
Theories offered by FireEye include that someone was trying to encourage others to port their code from the simulated Siemens environment to a version which would work in the real world. Another is that the code was being tested in a simulated environment, and it was uploaded to VirusTotal in an attempt to determine which anti-virus products (if any) might detect it. Finally, FireEye speculates that Irongate could be the work of a security researcher who simply abandoned their code.
For more thoughts on Irongate, check out the article from the SANS Industrial Control Systems Security blog.
