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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
And the complete list of signed assemblies was:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
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:
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