How CyberX Would Have Detected Industroyer/Crash Override

How CyberX Would Have Detected Industroyer/Crash Override
June 21, 2017 Hagar

June 21, 2017 – CyberX Threat Research Bulletin

By now you’ve probably read about Industroyer/Crash Override, the ICS-specific malware that was discovered by ESET earlier this week.

Here’s some information that describes how CyberX’s continuous monitoring and anomaly detection can protect you in the future from new types of sophisticated malware like Industroyer.


  • This is a sophisticated example of automated malware that communicates directly with ICS devices using their native industrial protocols — in order to hijack them (like STUXNET).
  • The malware communicates using ICS protocols IEC101, IEC104, and IEC61850.
  • It also scans and maps ICS targets using the OPC protocol, which is readily accessible from HMIs.
  • The malware is modular and could easily be evolved to attack US infrastructures — using DNP3, for example, which is widely-used in US electric utilities.
  • Unlike BlackEnergy, there are no reconnaissance features in this malware — it was specifically designed to cause damage via ICS devices.

How it Works

CyberX’s behavioral analytics would immediately identify anomalous behavior exhibited by this malware — even if it has never seen the malware before.

Unlike anti-virus and IDS technologies, CyberX does not rely on predefined rules or signatures. Rather, CyberX uses its deep understanding of M2M communications in your ICS environment to rapidly identify unusual or unauthorized behavior, using our patent-pending M2M behavioral analytics algorithms.

Here are just a few examples of how the CyberX platform would immediately detect this type of anomalous behavior:

  • SCANNING: Industroyer scans the network using OPC to identify its targets. CyberX would immediately recognize this as anomalous activity, since the malware is scanning all devices in the network and also generating an unusually high volume of traffic.
  • MANIPULATION OF ICS DEVICES: An infected host will start reading and writing all of its targets using multiple protocols, and using many different tags, which will cause a deviation from the baseline.
  • COMMAND FAILURES: The 60870 modules attempt to probe the PLCs by iterating across ranges of IOAs (Information Object Addresses), many of which don’t exist. The PLCs will then return an error for those attempts, which will be identified as anomalous activity. Also, to determine which object types support specific commands, it will attempt to execute these commands on all the addresses that were found, some of which are of a type that don’t support this operation, and will therefore return an error.
  • COMMAND-AND-CONTROL: The main backdoor communicates with a C2 server via a local proxy that was deployed by the attackers before the backdoor installation. The malware continues beaconing until it finds the proxy, which is listening on TCP 3128. After authentication, the malware communicates with an external C2 server via TOR. All of this activity would immediately be flagged by the CyberX platform as anomalous.

What are your thoughts on Industroyer?  How will it change the way your organization addresses industrial cybersecurity?

For more information