Now that I've had some distance from the analysis of #PIPEDREAM, I've been thinking a lot about knowledge gain, across #CRASHOVERRIDE, #TRISIS, and PIPEDREAM. Here's a quick summary of how I'm seeing the advancement of knowledge by adversaries seeking to impact ICS. (1/13)
2016, #CRASHOVERRIDE impacts a substation in UKRAINE. The toolkit encompassed 4 protocols: IEC101, IEC 104, 61850/MMS, and OPC-DA, capable of targeting breakers and switchgear that use those protocols, along with a custom DOS utility targeting a Siemens SIPROTEC relay. (2/13)
#CRASHOVERRIDE demonstrated a breadth of protocol knowledge with a lack of depth. (Aside: I only analyzed the 61850, and OPC modules along with the Siprotec stuff). These modules were sloppily put together. (3/13)
The 61850/MMS module looked like they had simply copy-pasted bytes from wireshark and replayed them with some basic replacements. Due to the implementation of OPC-DA, they could use COMCAT.h functions to do what they needed pretty easily to target the 5 control points. (4/13)
That said, the module could only target those 5 control points. It was completely automated. The SIPROTEC DOS didn't even work correctly. The payload was correct, but they screwed up endianness with the IP addresses so it's unlikely it ended up working against the target. (5/13)
Given the code it isn't evident to me that the #CRASHOVERRIDE devs really understood the ins and outs of the protocols involved, and having looked at a majority of the toolkit (aside from just protocol stuff), it all looked like very effective glue and toothpicks. (6/13)
#TRISIS was completely different. Instead of the breadth of protocols knowledge, the devs researched in-depth the TRISTATION protocol to achieve what appears to be reconnaissance of running logic (Program Upload), as well as running malicious logic (Program Download). (7/13).
To do this they wrote an entire python library that encompassed both the TRISTATION (high level) and TCM (low-level) protocols. Combining that with knowledge of the Triconex firmware, they were able to download logic to the controller that led to multiple plant shutdowns. (8/13)
Looking at #PIPEDREAM, I can't help but think they've got the combination of breadth from CRASH with the depth from TRISIS: Custom-written CODESYS libraries, interactive tools for manipulating devices over OPC-UA, and FINS, as well as basic recon using Modbus. (9/13)
The adversary has a similar breadth of knowledge as Crash: 4 protocols, along with the depth of knowledge of #TRISIS across the protocols and devices. Except instead of just being 1 device, it's several potentially 100s more. (10/13)
2016 to 2022, we've gone from attackers understanding the bare minimum needed to achieve an effect in one vertical (CRASH) to affecting just one device expertly (TRISIS) in potentially more than one vertical, to (11/X)
remotely and interactively affecting several devices expertly across devices. The adversary has evolved from having a dumb hammer to a swiss army knife that will help them both research and recon targets and achieve impacts. (12/13).
This is what I mean when I said, "This stuff is scary" and "Assholes keep getting better". It's not just about the capabilities of #PIPEDREAM, it's the rate of knowledge gain and expertise across adversary groups in such a short time that has me very concerned. (13/13)
Slight correction that doesn’t change my point. It’s actually 5 protocols, as they take advantage of Schneiders Discovery Broadcast protocol too.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I know I tweet alot about IDA. That's because I used to be an instructor, and realize how difficult it can be for new reversers to become accustomed to it (and to learn RE generally). But, owning IDA is not a barrier for entry into the RE community. #reverseengineering 1/5
There's tools like Ghidra, Radare, x64dbg, Windbg, gdb that are all free. Binary Ninja comes in at a much lower price point if you get a personal license. You can also download IDA Free, if you'd like to become more familiar with IDA. 2/5
The fact is reverse engineering is a process, and each of these tools facilitates that process in different ways, sometimes for the better, and sometimes not so much. If you give an experienced RE any one of these tools, given some spinup time, they'd still get the job done. 3/5
IDA's remote debugger is my go-to for debugging malware so that I never have to restore my VM and lose. If you're interested in trying it, I've attached some instructions on how to set it up to debug a DLL. (1/4) #malware#reverseengineering
1. Copy the remote debugger for your platform from the "dbgsrv" directory in your IDA installation directory to the debugging target and execute. -h will show you other options for configuring a password, port number etc. (2/4)
2. On the machine running IDA, select "Remote Windows Debugger" from the debugger dropdown. 3. Select Debugger -> Process Options from the menu, and fill in the parameters. Below I've included a sample configuration. 4. Select OK, and start the debugger like normal. (3/4)