Shut Up and Hack

Cracking Orcus RAT

2016-08-09 18:30:20 by rui

After my previous post here, I got a message from an anonymous source asking me if I would like to have a look at another piece of malware written in managed code (that was also on the news recently). More precisely at the 'Orcus RAT'. I follow KrebsonSecurity blog closely and I recognized the name. If you didn't read Brian Krebs post about who's behind 'Orcus RAT' read it here. Not long after 'Palo Alto Networks' Research Group published a follow-up, read it too. Based on the small research I did about this tool I think 'Palo Alto' got their facts right.

At first I thought I could be dealing with someone trying to 'phish' me, but the offer was legit. Challenge accepted. The zip file I got is for version 1.4.2 (which is the latest version available at the 'Orcus RAT' website, at the time of this writing). The zip file is massive. Here's the whole contents of the zip file.

 Volume in drive C has no label.
 Volume Serial Number is 90AE-F306

 Directory of C:\Users\rui\Orcus1.4.2

08/07/2016  02:29 PM    <DIR>          .
08/07/2016  02:29 PM    <DIR>          ..
07/31/2016  09:07 PM    <DIR>          libraries
07/31/2016  09:05 PM        17,172,040 Orcus.Administration.exe
07/08/2016  02:38 PM             1,165 Orcus.Administration.exe.config
07/31/2016  09:05 PM         1,994,240 Orcus.Administration.pdb
               3 File(s)     19,167,445 bytes
               3 Dir(s)  23,307,132,928 bytes free

C:\Users\rui\Orcus1.4.2>dir libraries
 Volume in drive C has no label.
 Volume Serial Number is 90AE-F268

 Directory of C:\Users\rui\Orcus1.4.2\libraries

07/31/2016  09:07 PM    <DIR>          .
07/31/2016  09:07 PM    <DIR>          ..
04/06/2016  03:47 PM            78,848 Be.Windows.Forms.HexBox.dll
09/04/2015  07:28 PM            76,004 Be.Windows.Forms.HexBox.xml
05/28/2016  10:35 AM           518,656 CSCore.dll
05/28/2016  10:35 AM         1,448,738 CSCore.xml
05/12/2016  08:21 PM            72,704 Exceptionless.Extras.dll
05/10/2016  12:11 PM             4,982 Exceptionless.Extras.xml
05/12/2016  08:21 PM           694,784 Exceptionless.Portable.dll
05/10/2016  12:11 PM           641,422 Exceptionless.Portable.xml
04/06/2016  03:48 PM            44,032 FluentCommandLineParser.dll
12/16/2015  06:11 PM           140,800 FluentCommandLineParser.pdb
12/16/2015  06:11 PM           118,978 FluentCommandLineParser.xml
08/11/2014  08:28 PM            54,784 GongSolutions.Wpf.DragDrop.dll
08/11/2014  08:28 PM            95,744 GongSolutions.Wpf.DragDrop.pdb
08/11/2014  08:28 PM            27,248 GongSolutions.Wpf.DragDrop.xml
05/18/2016  08:22 PM           606,208 ICSharpCode.AvalonEdit.dll
05/18/2016  08:22 PM           552,367 ICSharpCode.AvalonEdit.xml
01/29/2016  10:31 PM           940,544 MahApps.Metro.dll
01/29/2016  10:31 PM         1,123,840 MahApps.Metro.pdb
01/29/2016  10:31 PM           346,311 MahApps.Metro.xml
02/27/2016  02:59 PM            37,104 Microsoft.Threading.Tasks.dll
02/27/2016  02:59 PM            51,059 Microsoft.Threading.Tasks.xml
08/19/2015  06:13 PM           280,576 Mono.Cecil.dll
06/13/2016  10:06 PM           526,336 Newtonsoft.Json.dll
06/13/2016  10:06 PM           523,221 Newtonsoft.Json.xml
06/12/2016  11:23 PM           529,408 NLog.dll
06/12/2016  11:23 PM         1,245,550 NLog.xml
04/06/2016  05:49 PM         2,686,464 nUpdate.dll
04/06/2016  05:47 PM           214,528 nUpdate.pdb
07/16/2015  05:14 PM           107,696 Ookii.Dialogs.Wpf.dll
07/16/2015  05:14 PM           169,200 Ookii.Dialogs.Wpf.xml
07/31/2016  09:05 PM           113,736 Orcus.Administration.Commands.dll
07/31/2016  09:05 PM           239,104 Orcus.Administration.Commands.pdb
07/03/2016  02:54 PM            84,552 Orcus.Administration.Licensing.dll
07/03/2016  02:54 PM            84,552 Orcus.Administration.Licensing.pdb
07/31/2016  09:05 PM            34,888 Orcus.Administration.Plugins.dll
07/31/2016  09:05 PM            75,264 Orcus.Administration.Plugins.pdb
07/31/2016  09:05 PM            25,672 Orcus.Administration.StaticCommands.dll
07/31/2016  09:05 PM            77,312 Orcus.Administration.StaticCommands.pdb
07/31/2016  09:05 PM            22,088 Orcus.Plugins.dll
07/31/2016  09:05 PM            36,352 Orcus.Plugins.pdb
07/31/2016  09:05 PM           298,056 Orcus.Shared.dll
07/31/2016  09:05 PM           509,440 Orcus.Shared.pdb
07/03/2016  02:54 PM            26,184 Orcus.Shared.Utilities.dll
07/03/2016  02:54 PM            36,352 Orcus.Shared.Utilities.pdb
03/11/2016  10:08 PM           498,688 OxyPlot.dll
03/11/2016  10:08 PM         1,439,232 OxyPlot.pdb
03/11/2016  10:08 PM           147,456 OxyPlot.Wpf.dll
03/11/2016  10:08 PM           423,424 OxyPlot.Wpf.pdb
03/11/2016  10:08 PM           271,094 OxyPlot.Wpf.xml
03/11/2016  10:08 PM           965,402 OxyPlot.xml
03/11/2016  10:08 PM            13,312 OxyPlot.Xps.dll
03/11/2016  10:08 PM            26,112 OxyPlot.Xps.pdb
03/11/2016  10:08 PM            11,098 OxyPlot.Xps.xml
07/03/2016  02:54 PM            44,032 Sorzus.Wpf.Toolkit.dll
07/03/2016  02:54 PM           122,368 Sorzus.Wpf.Toolkit.pdb
02/18/2016  08:05 PM           135,168 Sparrow.Chart.Wpf.40.dll
02/18/2016  08:05 PM           152,399 Sparrow.Chart.Wpf.40.xml
05/25/2016  07:20 PM            49,152 starksoft.aspen.dll
05/25/2016  07:20 PM            79,360 starksoft.aspen.pdb
05/25/2016  07:20 PM            55,969 starksoft.aspen.xml
01/29/2016  10:31 PM            55,904 System.Windows.Interactivity.dll
08/19/2015  07:04 PM            77,824 Vestris.ResourceLib.dll
08/19/2015  07:04 PM           299,347 Vestris.ResourceLib.xml
06/14/2016  01:06 PM         1,042,944 Xceed.Wpf.Toolkit.dll
              64 File(s)     21,531,973 bytes
               2 Dir(s)  23,307,132,928 bytes free

Interesting to notice that the author includes the .pdb files on the package. According to wikipedia, Program database (PDB) is a proprietary file format (developed by Microsoft) for storing debugging information about a program (or, commonly, program modules such as a DLL or EXE). PDB files commonly have a .pdb extension. A PDB file is typically created from source files during compilation.

I started by loading 'Orcus.Administration.exe' in CFF Explorer. As you can see it is a very recent build.


SHA256: 4056ee5b23e47d172b48c84ceb5b6eca5ee68cf839dc7e5f28e984005ed7dcea

Dynamic Analysis

As usual I started by running it inside a VM without Internet access and I was presented with the following screens.

Without a license it seems I can't do anything else. While monitoring the DNS I observed queries to ''.

Reverse Engineering Managed Code

The first thing I noticed when I loaded 'Orcus.Administration.exe' in CFF Explorer was that the assembly was signed. See bellow the fields 'StrongNameSignature RVA' and 'StrongNameSignature Size'.

Meaning it wouldn't be possible to change it (I read a little bit about it while researching for my previous post). Well, I can change it, but it won't load. This signing process is best known as 'Strong Names'. Usually you use 'Strong Names' to verify an assembly publisher's identity. When you add a 'Strong Name' to an assembly you use a private key (part of an asymmetric public/private key pair) to generate a cryptographic hash and the public key is included in the assembly, along with the hash. I'm not an expert on this. I advise you read the 'References' at the end of this post if you want to know more. Which is actually what I did too. Anyway, more on this later.

I started by loading 'Orcus.Administration.exe' and all its DLL's in ILSpy.

The first surprise was that at the first glance no code obfuscation was used. Apparently I could browse the whole code without any problem. With one exception. As you can see in the picture above the DLL 'Orcus.Administration.Licensing' wasn't loaded properly. So, I opened it on CFF Explorer and noticed a few things. The MetaData had two GUID's, instead of one.

The Assembly Tables were two also, instead of one, and the 'Culture' field had what it looked like Chinese characters. First sign of obfuscation.

And by looking at the GUID's Blobs I could see this DLL was obfuscated with ConfuserEX.

I prayed a bit (unpacking 'Confuser' can be a nightmare) and launched 'UnConfuserEx v1.0', you can find this tool in some Reverse Engineering Forums. Usually it is not that simple... but surprisingly it worked.

I went to the 'libraries' directory, renamed 'Orcus.Administration.Licensing-unpacked.exe' to 'Orcus.Administration.Licensing.dll' and loaded it again in ILSpy. It loaded like a charm. Great.

No more signs of code obfuscation (well this isn't entirely true as you will see later). Only a group of assemblies signed.

C:\Users\rui\Orcus1.4.2>sn -v Orcus.Administration.exe

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'Orcus.Administration.exe' is valid

C:\Users\rui\Orcus1.4.2>sn -Tp Orcus.Administration.exe

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key (hash algorithm: sha1):

Public key token is 851aa33cb9b88f1c


And the complete list of signed assemblies was:


Cracking Orcus RAT

I started looking at code trying to find a good place to bypass the Registration/License process. You might be wondering, what about the fact that the assemblies are signed to avoid tampering? Don't worry, I'll get there.

After a while, I found what I thought it would be the best place to bypass the licensing process. By looking at the 'Administration' class code and the method 'OnStartup(StartupEventArgs)' I've found the following lines of code:

    Application.Current.Resources.MergedDictionaries.RemoveAt(Application.Current.Resources.MergedDictionaries.Count - 3);
    FileInfo expr_F1 = new FileInfo(CommandLineArgs.Current.LicenseFilePath ?? "license.orcus");
    if (!expr_F1.Exists)
        Application.Current.ShutdownMode = ShutdownMode.OnExplicitShutdown;
        if (new RegisterOrcusWindow().ShowDialog() != true)
    App.License = License.Parse(File.ReadAllText(expr_F1.FullName));
    if (!App.License.IsValid)
        MessageBox.Show("Invalid license.", "Error", MessageBoxButton.OK, MessageBoxImage.Hand);
    Logger.Log(LogLevel.Logo, " ____  ____  ____  _     ____ \r\n/  _ \\/  __\\/   _\\/ \\ /\\/ ___\\\r\n| / \\||  \\/||  /  | | |||    \\\r\n| \\_/||    /|  \\_ | \\_/|\\___ |\r\n\\____/\\_/\\_\\\\____/\\____/\\____/");
    Logger.Log(LogLevel.Logo, string.Format("\n<<<<<<< {0}: {1} || {2}: Sorzus (Orcus Technologies) >>>>>>>", (string)Application.Current.Resources["Version"], Assembly.GetExecutingAssembly().GetName().Version, (string)Application.Current.Resources["Developer"]));

I thought, if I remove the 'Environment.Exit(0);' call inside the if statement that checks if the License is valid, the application should proceed whatever is inside the file 'license.orcus', assuming it exists.

Cool, so I only need to figure out how to bypass the signed assemblies 'thing'. To start, and avoid the risk of introducing errors by making the wrong changes in the IL code, I decided to change only the contents of the MessageBox that should be shown if the license is invalid. So, I changed it as shown below.

And here comes the trick. ILSpy, or actually the 'Reflexil' plugin, will say that it can't save the file because the assembly is signed. It gives you multiple options though.

To be honest my first approach was 'Remove Strong Name'. If you look online you will find this as a possible solution, and in fact it is. However, I couldn't make it work with 'Orcus RAT'. The usual examples and 'crackmes' you find online apply only to one executable file (see the article in References) and not to complex/big projects as 'Orcus RAT'. I tried to remove the 'Strong Name' not only for 'Orcus.Administration.exe' but also all the DLLs listed above (as signed), plus all the 'References' I could find in all these files. I still couldn't launch 'Orcus.Administration.exe' successfully, as it fails to load with a 'System.IO.FileLoadException' due to tampered signature.

After some frustrating attempts I decided to take a different approach. Even though it is possible to do it the way I was trying. If you know what I could be missing please let me know. I'm pretty sure we can do this in multiple different ways anyway.

The second option, 'Re-sign with key' doesn't apply as we don't have the private key. The first and second on the screen below aren't available because I don't have 'sn.exe' in my PATH variable (sn.exe is shipped with the Windows SDK kit), it doesn't matter because I can do it manually.

The first option 'Register it for verification skipping (on this computer)' means we can actually disable windows 'Strong Name' validation (see the 'References'). Note that disabling the strong name verification may introduce a vulnerability. A malicious assembly could use the assembly name, version, culture, and public key token of the assembly added to the skip verification list to fake its identity. Which would allow the malicious assembly to also skip verification. I advise you to do it only in a non production environment.

To accomplish this task we will use the 'sn.exe' utility. As we saw before we can use 'sn.exe -Tp ' to view the public key token, so what we are going to do now to drop the assembly verification is running 'sn.exe' the following way (as administrator).

C:\Users\rui\Orcus1.4.2>sn -Tp Orcus.Administration.exe

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key (hash algorithm: sha1):

Public key token is 851aa33cb9b88f1c

C:\Users\rui\Orcus1.4.2>sn -Vr *,851aa33cb9b88f1c

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Verification entry added for assembly '*,851aa33cb9b88f1c'


Now if you look at the registry you will see a new entry for 'Strong Name' verification skipping. Basically what we just did manually was the first option 'Reflexil' gave us before.

As you can see only the assemblies with the public key '851aa33cb9b88f1c' will be skipped, if you feel lazy or you don't care just run 'sn.exe' as follows:

sn -Vr *

An entry for all assemblies (*.*) will be added. By the way if you want to bring back your previous settings 'sn.exe -Vu ' is your friend.

Now the interesting thing, if you select option '4. Cancel and keep it delay signed' when saving your patched file with 'Reflexil' it will remove the 'Strong Name' and replace it with a delay signature, but most of the time this does not prevent the assembly from loading. And in fact it does not. Forget all the 'sn.exe' kung fu above, you don't need it.

If we run our patched 'Orcus.Administration.exe' now it will run without any problems. Well, more or less.

It seems my thought about simply create an empty 'license.orcus' file was wrong. So, I went back to the code. I was definitely in the right place to bypass the 'Registration/License' mechanism, so I decided to do the following changes instead:

Basically I replaced the IL instructions below (3 and 4) with nops (above). Note: I later found this isn't really necessary, you actually can keep these instructions.

And then I deleted all the IL instructions between lines 63 and 108 (sorry too many to list them here). I gave it a try again, and...

It works! Mission Accomplished?!

Not really. While I can bypass the registration and create the server when trying to create the 'bot' it fails with a 'System.NullReferenceException' under 'Orcus.Administration.Build.Builder.ApplySettings'. So, I started looking at the code again... and by looking at the code below I could see why. A reference to something that we bypassed earlier, 'App.License.get_HardwareId()'.

The license mechanism was bypassed so this is definitely not initialized. I tried to look at the code of this method.

Not really helpful. While still lurking around this 'Orcus.Administration.Licensing' dll code I spotted another method also called 'get_hardwareId' but under 'HardwareIdGenerator'.

However, it seems even though we were able to use 'UnConfuserEx' to unpack the code it seems that's still a layer of obfuscation here. Or am I too tired to even try to understand what this method does?

After looking around and around I've found that this method is used if you launch the application via the command line, as:

C:\users\rui\Desktop\Orcus.Administration.exe /hardwareid

Which will open the following window.

There are a few more command line options as you can see below.

None looks useful. But, we have the code to generate the 'HardwareId' inside the same dll. So if I change the code below...

To the code below... I might not get the same 'System.NullReferenceException' any more.

I tried and... yes, now it works!

Well, it wasn't that easy, I struggled a bit to get it right. Anyway, 'Mission Accomplished'. I'm not sharing the sample, sorry (unless it is for research purposes and I can easily verify your intentions are legit). Otherwise, don't ask.

I'm pretty sure I could have 'cracked' this software in a different way, if you feel like sharing your approach please e-mail me.

Orcus RAT Features

I'm not selling the RAT so I'll not go into detail about 'Orcus RAT' features. Anyway, I played a bit with the RAT and I must say that there are multiple hours of development here. What I've found most interesting was actually the architecture. See below (picture from 'Palo Alto' blog post).

More or less what I would do if I was writing a RAT, for 'Red Team' exercises of course. Basically a three-part infrastructure model. An administration panel, the client (call it 'bot' or whatever), and an intermediary server. This will increase resilience and make it harder to detect/erradicate/take down. You must assume that some of your servers are going to be found and you need to be able to redirect 'bots' to other servers. Both the infected victim and the 'Orcus RAT' operator will use the server as a proxy to exchange commands and relay information. If you want to know more read the 'Palo Alto' blog post and there's a small tutorial on hackforums and even a video on YouTube.


Managed Code Reverse Engineering

Orcus RAT technical analysis