Don’t Cry Wolf: Evidence based assessments of ICS Threats

Don’t Cry Wolf: Evidence based assessments of ICS Threats

Speakers: Jimmy Wylie (Malware Analyst, DRAOS); Sam Hanson (Vulnerability Researcher and Malware Analyst, DRAOS)

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=6U_CepoMSl4

Overview

In the realm of Industrial Control Systems (ICS) security, the stakes are exceptionally high. Misinformation, sensationalized reporting, or a lack of analytical rigor can lead to unnecessary panic, wasted resources, and a loss of trust within the defender community. This talk, "Don't Cry Wolf," presented by Jimmy Wylie and Sam Hanson from DRAOS, directly addresses this critical issue by advocating for an evidence-based approach to assessing threats to ICS capabilities. The speakers highlight the dangers of overhyping perceived threats, drawing from a real-world incident where a common ransomware strain was misidentified as a sophisticated, novel Advanced Persistent Threat (APT) targeting biomanufacturing facilities.

Wylie and Hanson introduce a robust, three-pronged definition of ICS malware—requiring ICS capability, malicious intent, and the ability for adverse effects—and demonstrate its application through several challenging case studies. Their methodology focuses on proactive threat hunting in publicly available data sources like VirusTotal, leveraging simple yet effective techniques to identify potential ICS-related artifacts. The core message is clear: while the threat landscape for ICS is indeed serious, it is imperative for security professionals to maintain objectivity, follow the evidence, and avoid prematurely labeling findings as sophisticated ICS threats without sufficient proof. This analytical discipline ensures that critical attention and resources are directed towards genuine risks, fostering a more effective and trustworthy defense posture for vital infrastructure.

Background

▶ Watch: Introduction and the Tardigrade/Kati ransomware mixup (0:00)

The genesis of this talk stems from a significant incident in 2021, where a seemingly routine Cobalt Strike Beacon delivering Conti ransomware was misidentified and widely reported by a security partner as a novel and "extremely sophisticated" APT dubbed Tardigrade, specifically targeting biomanufacturing. This misidentification, fueled by the sensitive context of COVID vaccine supply chains, generated widespread media headlines and caused considerable alarm among critical infrastructure operators. Despite independent analysis, including by the late Vitali Kremez, confirming it was standard Conti ransomware, the initial hype necessitated an internal report from DRAOS to reassure their customers and prevent overreaction.

This experience underscored the profound impact of mischaracterizing threats. It highlighted the potential for poor analytical rigor to lead to wasted time, misallocated resources, and undue stress for defenders. To counter this, DRAOS developed a stringent, evidence-based process for identifying and assessing ICS threats. For a sample to be classified as ICS malware, it must satisfy three criteria:

1. ICS Capable: The code must be able to perform ICS or Operational Technology (OT) actions, such as speaking OT protocols (e.g., Modbus, OPC UA), uploading/downloading ladder logic, or interacting with runtimes or engineering software.
2. Malicious Intent: There must be clear evidence that the software was intentionally designed to cause harm within OT environments, distinguishing it from red-teaming tools or legitimate software.
3. Adverse Effects: The software must have the verifiable ability to cause harm against an OT environment, such as stealing sensitive process information, enabling unauthorized access, or downloading arbitrary logic to a PLC.

The speakers emphasize that these criteria are crucial for differentiating true ICS malware from IT malware that might incidentally affect OT, research tools, or even broken/incomplete development projects. This systematic approach forms the bedrock of their emerging threat hunting hypothesis: that undiscovered ICS malware or ICS-related malware exists within platforms like VirusTotal, which historically has served as a repository for samples like FrostyGoop, Tricis, and Cosmic Energy. The ultimate goal is to identify novel ICS capabilities before their widespread deployment, a challenging but vital objective in protecting critical infrastructure.

Key Findings

▶ Watch: The three essential criteria for defining ICS malware (2:30)

The talk's key findings revolve around the effectiveness of a disciplined, evidence-based threat hunting methodology, particularly when applied to publicly available data sources like VirusTotal. The speakers demonstrated that even relatively simple queries, when combined with analytical rigor, can yield significant insights into emerging threats and, crucially, help prevent the mischaracterization of non-malicious tools as sophisticated ICS attacks.

Their hunting strategy, designed for efficiency and accuracy, focuses on several core principles:

• String-Based Hunting: Leveraging ICS-related strings such as protocol names (e.g., Modbus, OPC UA), vendor names (e.g., Siemens, Rockwell Automation), and PLC models.
• Open-Source Library Detection: Identifying the use of publicly available libraries that implement industrial protocols. Threat actors often integrate these rather than developing their own, as seen with Pipere and FrostyGoop using Modbus TCP or OPC UA stacks from GitHub.
• Programming Language Focus: Prioritizing languages like Python, Go, and .NET due to their ease of static analysis, allowing researchers to quickly examine original source code or decompiled versions compared to more complex languages like C/C++.
• Malicious Indicators: Searching for generic malicious strings, CVE identifiers, or keywords like "exploit" or "attack" that often point to offensive capabilities.

Applying this methodology, Wylie and Hanson presented four distinct case studies, each illustrating a different facet of ICS threat assessment and the challenges involved:

1. IoT Exploit: A massive Python-to-C transpiled tool initially appearing highly malicious due to its extensive ICS exploitation capabilities, but ultimately assessed as a dual-use red teaming tool.
2. Kurtler SCADA: A low-sophistication VNC client marketed by an anti-Western actor, successfully used to compromise internet-exposed HMIs, highlighting that effective ICS attacks don't require advanced malware.
3. Fake Rapid SCADA Masquerade: A complex exploit chain leveraging CVE-2023-38831 (WinRAR arbitrary code execution) to steal specific files, which initially seemed like a targeted ICS information stealer, but was later identified as a likely Capture The Flag (CTF) challenge.
4. .NET Modbus Samples: A cluster of .NET downloaders that imported the EasyModbus library and made Modbus connections, but lacked clear malicious intent or adverse effects, ultimately deemed inconclusive without further context.

These examples collectively underscore the central finding: a significant portion of what initially appears to be ICS malware, upon rigorous investigation, often turns out to be red teaming tools, low-sophistication attacks, or even security research/CTF artifacts. The speakers emphasize that without their defined criteria and careful analysis, any of these samples could have been erroneously hyped as a "Tardigrade-like" sophisticated threat, causing unnecessary disruption for defenders.

Technical Deep Dive

▶ Watch: Why hunting for emerging threats in VirusTotal is crucial (4:25)

The core of the talk's technical contribution lies in the detailed analysis of four distinct samples, each presenting unique challenges to the ICS malware assessment framework.

IoT Exploit

IoT Exploit emerged as a particularly intriguing case. Discovered through hunting for Python malware with ICS-related strings, this tool was a substantial half-gigabyte zip file containing numerous Cython binaries. Cython, which transpiles Python to C, makes static analysis and decompilation exceptionally difficult due to obfuscated module names and file paths. However, the researchers got lucky: the author had liberally embedded docstrings throughout the code. By employing a simple Python trick, these docstrings could be extracted from the compiled binaries, revealing class and function definitions and significantly aiding analysis.

The analysis revealed a comprehensive toolkit:

• Identification: Its translated Chinese name was "IoT device vulnerability scanning, verification, and exploitation toolkit."
• Scope: It contained over a thousand exploits targeting IP cameras, routers, and industrial devices.
• ICS Specifics: Roughly 175 tools were dedicated to publicly disclosed vulnerabilities in common OT products, including Siemens Simatic and Rockwell Automation Micrologix.
• Protocol Support: It provided at least partial support for 19 industrial protocols, such as Ethernet/IP, Fins, and Modbus TCP.

Assessing this against the DRAOS criteria, the ICS capable and adverse effects properties were straightforward. Its protocol support and exploit capabilities clearly demonstrated ICS capability, and the effects of its exploits (e.g., denial of service, unauthorized access) confirmed adverse effects. The challenge arose with malicious intent. The tool included a JSON file with detailed vulnerability information (CVSS strings, public advisories), which is more typical of defensive or red-teaming operations. It exhibited numerous dual-use dilemmas: exploits and vulnerability scanners can be used for both offensive intrusions and defensive red teaming. It could even detect malware, a classically defensive function, though adversaries might use it to check for prior compromises. Persona information linked to an organization performing both offensive and defensive research, making attribution inconclusive. The exploits targeted publicly disclosed vulnerabilities, not zero-days, and there was no evidence of the tool's use in the wild or other intelligence. Consequently, it was concluded to be an IC red teaming tool rather than ICS malware.

Kurtler SCADA

Kurtler SCADA was identified via a simple query for Python scripts with "SCADA" in the name, submitted from Iran, reflecting the geopolitical tensions and increased interest from activist groups like Cyber Avengers in attacking OT systems. This tool was a compiled Python binary. Decompilation of Python binaries is usually straightforward with tools like PICDC or uncompyle6. However, Kurtler SCADA was compiled with Python 3.12, a version too new for older decompilers. The researchers successfully utilized Pilingual, a newer AI-based transformer tool that supports Python 3.10 and later, to decompile the code.

The decompiled code revealed a "glorified VNC client." Its functionality was simple:

• It accepted a list of IP addresses (presumably gathered by the operator via Shodan).
• It iterated through these addresses, brute-forcing VNC server authentication with a small list of hard-coded credentials.
• Upon successful connection, it captured a screenshot of the compromised server to prove access.

Further investigation, pivoting off the tool's name, led to a Telegram channel ("Kurtari Kurtlar Cyberlab") where an actor with pro-Iranian and anti-Western ideology was selling the tool, even offering discounts for targeting the West. This channel, which had about 7,000 subscribers before being banned by Telegram, boasted videos and screenshots of mass scanning and exploiting HMIs. Notably, the actor took steps to modify the HMI screens, adding images of "Elliot from Mr. Robot throwing his hands in the air" after a successful hack. While lacking complex ICS capabilities, its explicit targeting of ICS organizations and HMIs, coupled with clear malicious intent and adverse effects (unauthorized access, HMI modification), made it a serious concern. DRAOS contacted CISA to notify victims, emphasizing that even unsophisticated techniques can be highly effective against poorly secured, internet-exposed HMIs. One vendor's statement, "We have currently chosen not to implement these means [security layers] in order to avoid too much complexity," starkly highlighted the defensive challenge.

Fake Rapid SCADA Masquerade

This sample was discovered by searching VirusTotal for files with CVE tags (five or more detections) and "SCADA" in the metadata. The sample masqueraded as an update for Rapid SCADA, a legitimate open-source industrial software. It was a zip file containing a fake readme.exe batch file, which exploited CVE-2023-38831, a WinRAR arbitrary code execution vulnerability. This vulnerability, with public Proofs of Concept (PoCs), had been exploited in the wild by various threat groups.

The exploit chain was as follows:

1. A user receives a zip file, likely via email.
2. Previewing readme.ext within WinRAR (which is actually a malformed PNG) triggers the exploit.
3. A batch file executes, modifying shell open command registry keys for various browsers and the HTTP/HTTPS protocols.
4. Subsequently, any attempt to open an HTML file or URL causes an encoded firmware.exe binary to execute.

The firmware.exe binary performed several actions:

• It immediately killed the task SCADAManager.exe.
• It searched the desktop directory for specific file types: PDFs, XLSX, XLS, DOCX, and files containing "power plant SCADA" or "firewall" in their names.
• It exfiltrated these files to a hardcoded custom C2 server.

Initial assessment pointed to a custom, albeit strangely specific, information stealer with a clear ICS angle due to the Rapid SCADA masquerade, the SCADAManager.exe kill, and the targeted file names. The use of an exploit, obfuscated scripts, and binary further suggested malicious intent. However, a critical piece of evidence emerged: the C2 server shared an SSL certificate with a domain operated by hackros.com, a known CTF and security training website. This single piece of high-confidence evidence nullified the malware theory, strongly suggesting the sample was a custom challenge designed by HackRox. Despite attempts to contact HackRox for confirmation, they stopped responding, leaving the final assessment as "likely a CTF" – a frustrating but necessary conclusion adhering to evidence.

.NET Modbus Samples

The final case involved a cluster of .NET executables found using a Yara rule that searched for samples statically linking to open-source Modbus libraries. These samples shared common patterns: they were all .NET, downloaded and executed a second stage, and contained the EasyModbus library. A peculiar observation was that most samples imported the library but never called its functions, except for one specific sample.

The code for this particular sample, though heavily obfuscated (with symbols renamed for clarity), proceeded as follows:

1. It imported the EasyModbus library.
2. It connected to a specific hostname (LDUG) over port 502 using a Modbus client connection.
3. It then created an instance of an unidentified "Zclass."
4. Crucially, it downloaded, deobfuscated, and executed a second-stage binary fetched from Discord's content distribution network (CDN). This download function involved an HTTP GET request to Discord CDN, followed by a Base64 decode, and then a swap character algorithm to reconstruct the plain text binary.
5. Upon execution, the second-stage binary returned an IP address.
6. The original sample then connected to this returned IP address using Modbus, but critically, it did not issue any Modbus control commands thereafter.

The analysis was hampered by the unavailability of the second-stage payload, as it was no longer hosted on Discord's CDN and hadn't been captured by VirusTotal. This lack of visibility meant that the full functionality of the second stage, or what the Modbus connection was intended for, remained unknown. Without evidence of victims or targeting, and with the absence of any actual Modbus control commands, the researchers could not confidently assess malicious intent or adverse effects. It was deemed "not ICS malware in its current state," potentially being development malware, a research project, or an incomplete tool. This case highlighted the importance of context and the limitations of capability-alone analysis, underscoring that sometimes, despite suspicious indicators, there simply isn't enough high-confidence evidence to make a definitive assessment.

Demo / Proof of Concept

▶ Watch: Simple and effective ICS malware hunting with strings (5:50)

While the talk did not feature a live, interactive demonstration in the traditional sense, the entire presentation served as a comprehensive "proof of concept" for the speakers' evidence-based assessment methodology. Each of the four detailed case studies—IoT Exploit, Kurtler SCADA, Fake Rapid SCADA Masquerade, and the .NET Modbus samples—functioned as a practical demonstration of how their analytical rigor and three-pronged definition of ICS malware are applied in real-world threat hunting scenarios.

For IoT Exploit, the speakers demonstrated the process of overcoming obfuscation in Cython binaries by leveraging docstrings, then meticulously analyzing its vast array of ICS exploits and protocols, ultimately concluding it was a red-teaming tool. With Kurtler SCADA, they showcased the use of advanced decompilation tools like Pilingual for Python 3.12, uncovering its simple VNC client functionality, and then extending the investigation to open-source intelligence (Telegram channels) to confirm its malicious intent and impact on HMIs. The Fake Rapid SCADA Masquerade illustrated a deep dive into an exploit chain involving CVE-2023-38831 and detailed file exfiltration, only to have the entire malicious assessment overturned by a single, high-confidence piece of evidence—the shared SSL certificate with a CTF platform. Finally, the .NET Modbus samples exemplified the challenges of incomplete visibility, where a suspicious downloader with Modbus capabilities could not be definitively labeled as ICS malware due to a missing second-stage payload and the absence of actual Modbus control commands.

These examples collectively served to "demo" the DRAOS team's practical application of their framework, showing how they navigate dual-use dilemmas, overcome technical analysis hurdles, and integrate open-source intelligence to arrive at accurate, evidence-driven conclusions, thereby preventing the "crying wolf" scenario in ICS security.

Defensive Implications

▶ Watch: Identifying ICS malware by detecting open-source library use (6:08)

The insights from "Don't Cry Wolf" offer several critical defensive implications for organizations protecting ICS environments:

1. Adopt Analytical Rigor: Defenders must internalize and apply a rigorous, evidence-based assessment process for all potential ICS threats. The DRAOS definition of ICS malware (ICS capable, malicious intent, adverse effects) provides a robust framework. This prevents overreaction to tools that are merely ICS-related or dual-use, saving valuable resources and maintaining focus on genuine threats.
2. Prioritize Basic Cyber Hygiene: The Kurtler SCADA example vividly illustrates that even unsophisticated attacks can be highly effective against poorly secured ICS assets. Organizations must prioritize fundamental security controls, such as:

• Strong, Unique Passwords: Especially for internet-exposed devices like HMIs and VNC servers.
• Network Segmentation: Limiting direct internet exposure of OT devices.
• Vulnerability Management: Regularly patching known vulnerabilities, as highlighted by the WinRAR exploit in the Fake Rapid SCADA Masquerade.
• Principle of Least Privilege: Restricting access to only what is necessary.
• User Awareness Training: Educating users about phishing, malicious attachments, and the dangers of opening suspicious files (e.g., the WinRAR exploit).

1. Context is King: As demonstrated by the .NET Modbus samples and the HackRox CTF, the capability of a tool alone is insufficient for a high-confidence assessment. Defenders need to seek broader context, including evidence of targeting, actor attribution, and the full kill chain, before making definitive judgments about malicious intent and impact. When context is missing, assessments should remain appropriately cautious and provisional.
2. Proactive Threat Hunting: Organizations should integrate proactive hunting for emerging threats into their security operations, utilizing techniques similar to those presented:

• Leverage Public Repositories: Continuously monitor platforms like VirusTotal for ICS-related artifacts.
• String-Based Searches: Employ specific keywords related to ICS protocols, vendors, and device models.
• Open-Source Intelligence (OSINT): Monitor forums, Telegram channels, and other public sources for discussions or sales of ICS-related tools and campaigns.

1. Understand Dual-Use Tools: Many tools, like IoT Exploit, can serve both offensive and defensive purposes. Defenders should be aware of such tools, understand their capabilities, and ensure that their internal red-teaming and penetration testing activities are clearly demarcated and not mistaken for external threats.
2. Foster Trust through Accuracy: By presenting accurate, evidence-based assessments, security professionals build trust within the community. When real, significant threats emerge, the community will be more likely to listen and act decisively, rather than suffer from "alert fatigue" or dismiss warnings as overhyped.

In essence, the talk is a call for maturity in ICS threat intelligence and defense, moving beyond knee-jerk reactions to a more measured, analytical, and effective approach that prioritizes facts over fear.

Key Takeaways

• Analytical Rigor Prevents Hype: It is crucial to apply a strict, evidence-based methodology when assessing potential ICS threats to avoid misidentifications and overhyping, which can waste resources and erode trust.
• The Three Pillars of ICS Malware: True ICS malware must demonstrate ICS capability, malicious intent, and the ability to cause adverse effects on OT environments. Without all three, it’s likely something else.
• Simple Hunting Yields Results: Effective threat hunting for ICS-related artifacts can often begin with simple queries, combining programming language indicators (e.g., Python, .NET) with ICS-specific keywords (protocols, vendor names) in platforms like VirusTotal.
• Low Sophistication Can Be Highly Effective: Attacks targeting ICS do not always require advanced, nation-state-level capabilities. Basic techniques like brute-forcing poorly secured, internet-exposed HMIs (as seen with Kurtler SCADA) can still achieve significant impact.
• Context is Paramount: The technical capability of a sample alone is insufficient for a definitive assessment. External intelligence, evidence of targeting, and the full operational context are often necessary to confirm malicious intent and differentiate between malware, red-teaming tools, and CTF challenges.
• Trust is Earned Through Evidence: Maintaining the community's trust relies on accurate, unbiased reporting. When the "real bad" threats emerge, a history of credible, evidence-driven assessments ensures that warnings are taken seriously.

About the Speaker(s)

Jimmy Wylie is a Malware Analyst at DRAOS. In his role, he focuses on the analysis and assessment of malicious software, particularly within the context of Industrial Control Systems. His work involves detailed investigation of samples, often navigating complex obfuscation and dual-use dilemmas, to provide evidence-based threat intelligence.

Sam Hanson serves as a Vulnerability Researcher and Malware Analyst at DRAOS. He brings a dual expertise to the team, combining in-depth vulnerability research with malware analysis. Sam's contributions include developing and applying methodologies for hunting emerging threats in ICS environments and conducting detailed technical deep dives into discovered artifacts.