While browsing through my RSS reader, I ran into article from 09-Oct-2017, called OilRig Group Steps Up Attacks with New Delivery Documents and New Injector Trojan.
One part in the article caught my attention:
The “Run” method calls functions that has a state machine that dictates the actions taken. At a high level, these state machines attempt to create a process and inject the constructed payload into the newly created process. The use of state machines complicates analysis efforts because it makes the flow of execution jump around in a non-sequential fashion.
...
The state values jump around dramatically, which requires an analyst to also jump around the code to determine its functionality. This is an interesting anti-analysis technique we have not seen the OilRig actors use in their other tools.
.NET? State machines? Complicated technique we haven't seen before? Show me, show me, show me! 😀
Finding the DLL was relatively easy, finding the method they were describing was much harder. In the end I had to search for the constant "19" they mentioned in the article.. So, here is the method, in all its beauty:
If you're screaming "Dude, that code is obfuscated!", you're right. It is obfuscated.
If you're screaming "It's .NET Reactor!", you've spent too much time reversing .NET applications.
But you're right. It's easy to recognize the .NET Reactor by first few instructions, method renaming pattern and plenty of other things.
Have you heard of de4dot?
Let's try to run de4dot on this dll:
F:\>F:\de4dot-appveyor\de4dot.exe d.dll --dont-rename de4dot v3.1.41592.3405 Copyright (C) 2011-2015 de4dot@gmail.com Latest version and source code: https://github.com/0xd4d/de4dot Detected .NET Reactor (F:\d.dll) Cleaning F:\d.dll ERROR: ERROR: ERROR: ERROR: Hmmmm... something didn't work. Try the latest version. Press any key to exit...
So, apparently, the latest versions of de4dot are buggy. Let's use an older version:
F:\>F:\de4dot-3.0.2\de4dot.exe d.dll --dont-rename de4dot v3.0.2.3405 Copyright (C) 2011-2013 de4dot@gmail.com Latest version and source code: https://bitbucket.org/0xd4d/de4dot Detected .NET Reactor (F:\d.dll) Cleaning F:\d.dll Saving F:\d-cleaned.dll Press any key to exit...
And let's look at the method again.
Strings are still unreadable, but where's the state machine? It's gone! Because it was never part of the OilRig actors toolkit, it was just a part of .NET Reactor control-flow obfuscation. 🙂
Decode strings and rename few variables and you'll see a very ordinary RunPE (aka. process hollowing) code:
Lessons learned
The lesson is simple - you should know the subject you're writing about. And if you don't know something, ask your friends and colleagues. Otherwise you'll just embarrass yourself and your company.
Further reading
If you want to learn more about this malware, I would suggest reading analysis by DarkMatter. At least they can identify .NET Reactor correctly. 😉