More on COSMICENERGY. Previously we said that LIGHTWORK had a 98% function overlap with lib60870-c, turns out it's even more than that. Their main code is based on an example from that project, simple_client.c #ICS#malware (1/13) github.com/mz-automation/…
Going back in the Github history, and looking at various artifacts, like dangling if statements, and some sleep calls, and such, it looks like it's based on the version from March 28, 2019 (2/13): github.com/mz-automation/…
I'm going to forego a line by line comparison of all the functions, but if you want to take a look, here are screen shots of the handler functions and their corresponding decompilations. First: rawMessageHandler and connectionHandler (3/13)
And here is the last handler asduReceivedHandler. They're all basically 1:1 copies, with slight differences explained by the compiler (like the switch statements becoming an if, or simple printfs becoming puts). (4/13)
The last function in the example project is main, and here is where you see some slight differences where the LIGHTWORK authors changed the code. I'll go through this bit in a couple chunks for readability. (5/13)
In the first part of main, they added an argument. "input_command = atoi(argv[3])" (my annotation), and removed setting the asduReceivedHandler. The extra argument is the ON or OFF command.
(6/13)
The next part where they create the connection and do some set up (to be brief), is exactly the same (7/13)
Now here's where the real change happens. LIGHTWORK takes the next bit where the github example creates and sends one Single Command, and wraps it in a loop so it can send 8 of them to an array of IOAs that it initializes just before. (8/13)
The rest of the code is the same. I made notes and by my count, Lightwork is entirely the same as lib60870's simple_client.c, except for 1 line removed, and about 11 additional lines in decompilation.
(9/13)
In their actual source, that array initialization probably happens on 1 line, which means it's probably closer to 4 or 5 additional lines:
1 for the extra argument
1 for the array initalizer
2 for the for loop header and ending brace
+ the mods to make loop body work.
(10/13)
So what does this mean? LIGHTWORK with the exception of (let's just be generous) 6 lines of code, is exactly the same as an example IEC104 client project from lib60870. Personally, I think this lends credence to the theory that this is a test or research tool. (11/13)
The more I think about it the more I think that the authors were creating a "discount CRASHOVERRIDE emulator" to test detections. Use of xp_cmdshell and IEC104 match already known TTPs from that event.
(12/13)
The combination of naming (using a Mitre ATT&CK technique number), inclusion of symbol information, all the python errors, and an almost 1:1 copy of an example from github doesn't add up to COSMICENERGY (at least this version of it) seeming like serious malware.(13/13)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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)
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)