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.
C:\Users\rui\Orcus1.4.2>dir 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.
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 ‘collector.exceptionless.io’.
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): 00240000048000009400000006020000002400005253413100040000010001002983fb7aeaa4de 53d88a60e791a73e94711f04846b90b2a0b91030f1f680b6ea135ee2a1e7ddc9d903535c91f729 d8005200b9724a6dc7a22d0d50b7be54ee77b8dfc03b8cc59e1ee057ed6faacbe222ad98fcda47 7fdcd77e99c261df8a5d57e2828acaaef45e68417953e59ebf06252427a78c8a5f6c3237efdd21 8fc71be5 Public key token is 851aa33cb9b88f1c C:\Users\rui\Orcus1.4.2>
And the complete list of signed assemblies was:
Orcus.Administration.exe libraries/Be.Windows.Forms.HexBox.dll libraries/Exceptionless.Extras.dll libraries/Exceptionless.Portable.dll libraries/FluentCommandLineParser.dll libraries/nUpdate.dll libraries/Orcus.Administration.Commands.dll libraries/Orcus.Administration.Licensing.dll libraries/Orcus.Administration.Plugins.dll libraries/Orcus.Administration.StaticCommands.dll libraries/Orcus.Plugins.dll libraries/Orcus.Shared.dll libraries/Orcus.Shared.Utilities.dll libraries/Sorzus.Wpf.Toolkit.dll
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:
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.
1. Register it for verification skipping (on this computer)
2. Re-sign with key
3. Remove Strong Name
4. Cancel and keep it delay signed
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
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): 00240000048000009400000006020000002400005253413100040000010001002983fb7aeaa4de 53d88a60e791a73e94711f04846b90b2a0b91030f1f680b6ea135ee2a1e7ddc9d903535c91f729 d8005200b9724a6dc7a22d0d50b7be54ee77b8dfc03b8cc59e1ee057ed6faacbe222ad98fcda47 7fdcd77e99c261df8a5d57e2828acaaef45e68417953e59ebf06252427a78c8a5f6c3237efdd21 8fc71be5 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' C:\Users\rui\Orcus1.4.2>
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
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:
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