Blog
Co-founder
Part 3: INDUSTROYER
We covered some basics of intelligence-based detections in Part 1 of this series, and Part 2 delved into the diversity and variation of ICS environments and their implementations.
Now let’s combine the two concepts using a well-known and documented example use case from the industry.
INDUSTROYER 📢
📢📢📢 <insert air horn sound effect>
INDUSTROYER Links
News of the Attack
https://www.reuters.com/article/us-ukraine-cyber-attack-energy-idUSKBN1521BA
Analysis by First to Report (ESET)
https://www.welivesecurity.com/2017/06/12/industroyer-biggest-threat-industrial-control-systems-since-stuxnet/
INDUSTROYER Background
A well-known cyber attack against Ukrenergo’s “North” substation caused power outages in and around Ukraine’s capital of Kyiv on December 17th, 2016. If you are in the industrial cyber security space, you’ll recognize this attack and previous 2015 events as watershed “proof points” that direct and specific attacks against power systems are happening.
Like Stuxnet deployed in 2007 and uncovered in 2010 (quick, somebody alert https://twitter.com/StuxnetMentions), the Ukrenergo use case became well documented and often misrepresented among cybersecurity professionals. Finally, the industry had a specific and targeted attack against a substation where the actor achieved its objectives. This was huge… the theoretical had become a reality. While this was still an attack in a far-off land for some, industrial cyber consultants, advisers, and vendors had the evidence they needed to back the messaging.
However, for those in the IOC and analytics shops, it was still a difficult task to convert this deep intelligence history and information into actionable results. Thankfully, MITRE has broken out and mapped each of the INDUSTROYER components for us to digest.
MITRE ATT&CK for ICS
INDUSTROYER Software Case
What is MITRE ATT&CK for ICS?:
ATT&CK for ICS is a valuable knowledge base for describing the actions an adversary may take while operating within an ICS network. The knowledge base can be used to better characterize and describe post-compromise adversary behavior.
from https://collaborate.mitre.org/attackics/index.php/Software/S0001
Review the in-depth matrices MITRE put together describing every action an adversary can take in an ICS network. These categories help bucketize all known, unknown, and future attacks into common nomenclature to improve the community’s ability to defend and respond.
Actions and Outcomes
For INDUSTROYER, MITRE attaches nearly 30 actions and outcomes as a result of the attack. Ranging from denial of service to loss and manipulation of view/protection/view and everything in between, MITRE lays out the attack in all of its pieces and parts.
The concept here is that a defender could break the attack chain at any given point, potentially disrupting the adversary’s end objectives of causing a power outage.
From a monitoring, visibility, and detection stance, it’s still very difficult to translate these components into analytics that matter across the board. By reading the first in the list, the challenge is apparent:
The Industroyer SIPROTEC DoS module places the victim device into “firmware update” mode. This is a legitimate use case under normal circumstances, but in this case, is used by the adversary to prevent the SIPROTEC from performing its designed protective functions.
Sleepy time for SIPROTEC relay
Many other techniques utilized or abused current functionality within the substation SCADA systems. This further complicated the idea that these TTPs (tactics, techniques, and procedures) could be codified into detection rules. One part of the attack did stand out, however:
❓ Question: How do you make a SIPROTEC relay go to sleep?
👉 Answer: Send specific data over UDP 50000
With a background in penetration testing control systems for many years, I’ve learned that sending garbage data to listening control ports is the simplest and least elegant way to brick a control system.
Born from this concept are the horror stories of well-meaning vulnerability assessors taking down systems with Nmap and Nessus. In the case of INDUSTROYER, causing a line of power relays to become unresponsive just needed packets on UDP/50000 with a certain 18-byte payload. That was it.
While there is much more to the INDUSTROYER event than this particular packet, it was one of the few actionable detections directly related to the event (more on this context in a bit). Here’s what happened:
INDUSTROYER – What Happened Next?
CISA released a specific advisory for a known (and patched) vulnerability exploited by the adversary in this instance (https://www.cisa.gov/uscert/ics/advisories/ICSA-15-202-01).
The great folks at Cisco Talos released a snort rule looking for the specific 18 bytes in UDP/50000 (https://www.snort.org/rule_docs/1-43177).
Some YARA rules for INDUSTROYER were created (https://www.cisa.gov/uscert/sites/default/files/file_attach/ICS-ALERT-17-206-01.yara)
IOCs were released, a collection of IP addresses that were TOR node exits, files hashes, and the like (https://www.cisa.gov/uscert/sites/default/files/publications/TA-17-163A_IOCs.csv)
But for an attack that will most likely never be seen in this form again, how useful are these for proactive monitoring and detection? Observation biases aside, you’re more likely to detect penetration testing teams trying things out, than you are to detect Russian adversaries.
Continuing our Journey
Universally the intelligence and history lesson here is good, but there are no magic analytics for the INDUSTROYER attack. The attack itself was a series of stitched together nonindustrial-specific tactics and techniques to gain initial access. This was followed by highly specialized malicious applications that ended up abusing completely normal industrial protocols.
Where we at SynSaber are looking to affect positive change is an opportunity for Operator-Based Intelligence over Threat-Based Intelligence. Give security and industrial operators the ability to codify the intelligence of how their systems function, what’s anomalous or unusual, and place firmly in their capable hands the ability to control their destiny.
Detections are the safety net; everyone is going to want or require that your organization be able to detect known bads. The disconnect with our handful of ICS-specific examples is the expectation (and maybe the marketing) that ICS threat intelligence directly translates to analytics and detections.
But as the INDUSTROYER example shows us, there are numerous value-adds at this stage in our journey. In past years, a lot of time and effort was spent convincing the industry that threats are real and action is required. But silver bullet analytics based solely on threat intelligence isn’t doing cyber threat intelligence for industrial any justice.
In our final part of this series, we’ll take a positive look at what proper threat intelligence can do for converged IT and OT programs and the importance of clear visibility into all parts of the environment. I look forward to continuing our journey!
~Ron 💜🚀
Become a Subscriber
SYNSABER WILL NEVER SELL, RENT, LOAN, OR DISTRIBUTE YOUR EMAIL ADDRESS TO ANY THIRD PARTY. THAT’S JUST PLAIN RUDE.
