IRONGATE malware simulation provides valuable insight into ICS attacks

Tue, 7th Jun 2016

FYI, this story is more than a year old

By Sara Barker, Copywriter and Senior News Editor

A joint research effort between four cybersecurity organisations has released research about IRONGATE, a type of ICS malware that is not so much an active threat as a proof of concept.

FireEye, iSIGHT Intelligence, FLARE and Mandiant recently released researched which discovered the mechanisms behind the malware.

IRONGATE can enter sandboxes to avoid detection, which suggests that its development was malicious, and not a legitimate operation. The research says that VMware or Cuckoo Sandbox environments seem to stop IRONGATE droppers from running.

The researchers discovered the potential malware when analysing droppers used with PyInstaller, which is a method some malicious programmes can adopt.

Strings also found in the dropper also included the word 'payload', which is a common malware keyword.

IRONGATE's most dangerous feature is that it can operate a man-in-the-middle (MitM) attack by entering through a Dynamic Link Library (DLL). This malicious DLL can record five of seconds normal activity through the PLC on Siemens products.

IRONGATE then simulates the traffic while sending different information through to the PLC, which means any attack could control systems without legitimate users knowing.

While statements from Siemens Product Computer Emergency Readiness Team (ProductCERT) show that IRONGATE is not an active threat to any Siemens products, it does demonstrate the potential effects an attack could have.

ProductCERT says that they acknowledge the potential attack as a test case, proof of concept or a research activity for ICS malware attacks.

ICS malware is also dangerous as it uses DLLs to manipulate single and specific processes and while it's not quite the same as STUXNET, it uses some of the same attack methods.

The research concludes that although there is no threat, it recommends that users:

Implement integrity checks and code signing for both vendor and user-generated code. Cryptographic verification will prevent MitM and replacement attacks from occurring.
Use specific processes for sanity checking IO data, which could include independent sensing and backhaul, and comparison of process states. Awareness of process states can thwart attack attempts.