As I stated in this video I’m going to be focusing much more on RAT analysis. My reasons are given in the second portion of the video for anyone who is interested. I decided to look at a fairly popular RAT called ‘Imminent Monitor’. I downloaded the cracked version which many should note as this may differ from the original in some ways, I’ve tried to only include things which I’m sure are wrong with the original as well. There is something positive about analysing cracked malware, as the majority of criminals probably don’t want to pay for RAT’s.
Darkcomet RAT is still actively used today even though it is no longer developed and has been proven to have exploits in this. With this in mind, this version of cracked software will most likely distribute around the internet and be used more than the paid version due to it simply being free. I thought I was going to have a fairly long wait to find how to extract the config out of the RAT but it was really as easy as 1-2-3. Literally looking at the first classes constructor.
One of the first threat indicators I can provide to malware guys is that Imminent RAT creates a folder which is always the same, it is quite unique. It creates a directory called “Imminent” in the application data of the current user. This does not hold the executable but instead holds information to be sent over to the client. Like logs.
The binary uses cases to make it harder for researchers to make out whats going. Imminent uses a XOR like function but to what I see isn’t exactly XOR. I’m thinking of creating a deobfuscator for this sort of code later on, but for now I solved it manually, which wasn’t particularly challenging. The more I look at it the more it looks like XOR, but I’m terrible at checking these things so I’m just going to call it XOR-like.
This XOR like functions is used to encrypt logs and other parts included in the “Imminent” application data. I successfully tested my algorithm against the original and got the same result, this was also verified by breakpointing the function to where it was encrypting to make sure the plain text was the same.
With the same algorithm we can decrypt logs that Imminent creates. It does it by a format of month/day/year, showing the author could be American origin. An interesting thing about the use of what looks to be XOR is the key provided for the operation, the developer decided to use “sampleKey”. Or did he? A person who doesn’t copy and paste an algo usually chooses a different key than sampleKey, infact someone who does copy and paste an algorithm usually changes the key.
byte path = System.Text.Encoding.UTF8.GetBytes(“C:\\Documents and Settings\\L!NK\\Local Settings\\Application Data\\Startup Folder Name\\MyFile.exe”);
byte pass = System.Text.Encoding.UTF8.GetBytes(“sampleKey”);
byte ax = xorlike(path, pass);
public static byte xorlike(byte byte_1, byte byte_2)
int num = 11;
int num5 = 13;
int num3 = 257;
int num6 = byte_2.Length – 1;
for (int num7 = 0; num7 <= num6; num7++)
num3 += num3 % (int)(byte_2[num7] + 1);
int num4 = byte_1.Length – 1;
for (int num2 = 0; num2 <= num4; num2++)
num3 = (int)byte_2[num2 % byte_2.Length] + num3;
num = (num3 + 5) * (num & 255) + (num >> 8);
num5 = (num3 + 7) * (num5 & 255) + (num5 >> 8);
num3 = (num << 8) + num5 & 255;
byte_1[num2] ^= (byte)num3;
result = byte_1;
I’ve decided to show an example of it’s operation. You can use this for any defense against Imminent if you choose to make one. The code is obviously deciding to encrypt the startup path and saved in the Imminent folder as “Path.dat”, a rough location of a user is also saved “Geo.dat”, which uses a site called iptrackeronline.com to longitude, lattitude, city and finally country.
I discovered a file which deals with processes, I’m not sure at the moment, if its the file updater, download and execute or persistence. I’m more leaning towards it being a process watchdog but have many things to explore. I discovered it here:
The file was written in C++ which is interesting as most .NET malware doesn’t drop anything like C++, turns out to be a dll which I assume is injected for persistence, although as I say I don’t want to rule out anything yet.
I couldn’t debug in Immunity properly because I use an XP machine with some of the C++ redistributables not installed. This file required GetModuleHandleEx which was provided in 2011 from my research, but I might be wrong.
I’m not going to show a lot of IDA, but it checks for a debugger, creates a thread, opens processes and creates them too. It is also uniquely identifiable because of some of the strings that are given. That is indeed a md5 hash which is “killswitch” in plain text.
You can see that correctly, the file is also FUD and still is as I write this article 3 days later.
I was starting to test out how I could break Imminent Monitor as well and found that the RAT does not like showing files when a file is out of its format, I named a file in the keylogger file “ao” and entered a small amount of data. It proceeded to not show any of the keylogging files that were available to it. This is it in a broken state.
The task manager disabler functionality that Imminent provides is also quite bad. It simply executes the task manager and makes it invisible. Not exactly to rootkit standards, but I guess does the trick to the average joe?
In the cracked version the process protection is broken or non-existant, I am able to kill the process with ease. I am to do more research on Imminent Monitor, it’s been fun to look at so far and I haven’t looked through all of it because of time constraints in my life. What I have provided is some threat indicators for AV’s so that this RAT can be removed from peoples computers with ease, even if crypted. The static path declaration provides an opportunity to remove this RAT from most machines.
I’ve been looking more at how Imminent can be broken remotely, I’ve had a few sucesses with random things, but must look at them in more depth before I decide to release them publicly. A reminder for anyone reading this, if you have an original build that isn’t from a cracked client, I would like to have it so please contact me.
Thanks for looking.
Remember a time where people said you should look at the address bar to verify whether or not it’s a phishing attempt? A friend of mine recently got an email which is fairly interesting to me. This attack provides a decent amount of SE to make a user think it’s a legit, correct, the green “padlock” isn’t there, but google.com is.
It all started with a email which looked to be fairly normal, the one problem with it is ofcourse is the Google attachment. I don’t use Google as a provider for this email and so having a Roundcube email client and Google attachment doesn’t work out. The attackers are just taking into account the majority of people will be using Google accounts and so it’s worth making something look like this.
The URL is redirected twice until it reaches its destination, pretty common with phishing attacks most likely so they can dynamically redirect if a site is reported on and falls down. The code here refreshes and uses the data: functionality that browsers have available. There are spaces from the google.com text to the <script> tags, this is to ensure that the browser shows only the Google text in the URL bar, making it deceptive to most people. The text in the URL isn’t actually the location, but infact code itself.
The final result? You’ve already seen it but it’s rather convincing to a person who isn’t to confident with computers. Maybe we need to have a look at modifying how data URI’s are used. Here’s a video showing it live.