10 - BruCON 0x0D - Chasing the White Whale of Malware

### Overview In this BruCON presentation, Daniel and Rushikesh discuss the distinct challenges and methodological approaches involved in hunting and identifying operational technology (OT) and industrial control systems (ICS) malware—described as the rare "white whale" of cyber threats. Historically, purpose-built cyber-physical malware (such as Stuxnet, Industroyer, Havex, and Triton/Trisis) is exceedingly rare, highly targeted, and almost always discovered only after physical disruption or safety hazard has occurred. The speakers explore why conventional IT security tooling fails in OT contexts and outline a structured, technical methodology termed "tests of deduction" to distinguish genuinely relevant cyber-physical binaries from the overwhelming noise of benign or generic software.

### Key Topics - **Context and Scarcity of OT Malware**: Drawing on incident response experiences from incidents like the 2017 Triton attack against Schneider Electric Triconex safety systems via the TriStation protocol, the presentation highlights how rare purpose-built OT malware is compared to IT threats. - **Challenges with Conventional Tooling**: Standard antivirus solutions and automated dynamic analysis sandboxes struggle with OT binaries. Sandboxes frequently produce false positives—mislabeling legitimate industrial control routines as malicious—or fail to execute proprietary code that requires specific industrial hardware or configurations. - **Concept of Intermediary Systems**: Mandiant's perspective focuses on software that operates between IT networks and field controllers, managing sensor data collection, engineering workstations, and human-machine interfaces (HMIs). - **Sample Sourcing**: Collecting candidate binaries relies on in-house environment captures, vendor interactions, specialized engineering discussion forums, and multi-scanner malware analysis platforms (such as VirusTotal or specialized firmware initiatives like adolescent-focused repositories such as Adolus).

### Technical Details Rushikesh outlines the "tests of deduction" framework used to inspect candidate binaries using tools like Radare2, Ghidra, and FireEye's FLOSS: - **Static and Dynamic Strings**: Basic static string extraction often surfaces terms like `PLC station number`, but attackers can embed arbitrary text to mislead researchers. Dynamic string extraction using FLOSS extracts memory-resident and deobfuscated strings to verify operational context. - **Functions of Interest and API Calls**: Investigating specific file and device interactions, such as `open_file` calls or API sequences, helps locate instructions interfacing with physical devices. Disassembly in Radare2 demonstrated locating error handlers like `error accessing coil register address field file`, directly linking code execution to Modbus communication structures. - **Symbol and Function Analysis in Ghidra**: Inspecting symbol trees, imports, exports, and data types (such as `DEFINE_IF_TYPE_PLC`) allows analysts to identify industrial logic. Analysis of substation-oriented binaries revealed direct references to electric power and automation protocols, including IEC 60870-5 (IEC 101, IEC 102, IEC 103, IEC 104), IEC 61850 (including GOOSE messaging), and SPA-bus, with distinct master (`_m`) and slave (`_s`) implementations. - **Device and Network Probing**: Searching for protocol bridges such as `eth2serial` and tracking serial or network device interactions helps establish whether a binary actively communicates with field equipment. - **Fuzzy and Import Hashing**: Standard cryptographic hashes change with minor modifications. Selective fuzzy hashing or import hashing targets repetitive, shared components common in proprietary or closed-source industrial development. - **Limitations of Yara Rules**: While widely used in threat hunting, generic Yara rules generated massive alert volumes—sometimes producing upwards of 100,000 binaries per day that required hours of sorting—highlighting the necessity of more targeted behavioral and memory artifact detection.

### Takeaways Finding ICS/OT malware proactively requires moving beyond generic string matching and traditional sandboxing. By implementing multi-step deductive tests—verifying protocol functions, memory strings, and hardware/device communication patterns—analysts can automate the filtering process, dramatically cut through noise, and identify authentic cyber-physical functionality.