Reverse Engineering an Unknown RAT – Lets call it SkidRAT 1.0

While monitoring a blogspot page that keeps embedding malicious scripts to execute on victim systems I seen some code changes that interested me. Specifically they added another payload for victim systems to retrieve.

A casual glimpse at the blog post below wouldn’t make you think that the post was malicious. However, it does contain embedded code that victims who are either currently infected or served a maldoc will execute. This blog post is located here.

Malicious Blogspot Link:
hxxps://b67x[.]blogspot[.]com/p/10.html

Blog Post:

Static Analysis – Triage/Overview:

In the interest of time I am going to not include the screenshots of the analysis of the initial “setup.exe” that gets served on the page above. Instead I am going to summarize what process led me to finding and analyzing the embedded backdoor.

The setup.exe file is a Nullsoft Installer(NSIS) when decompressed with 7zip there is a nice separation of each of the files that are embedded in it. The important file to analyze though gets dropped by the embedded InstallShield installer during the “installation” process.

One thing I will mention of interest is that the embedded installer claims to have a company name of “Amazon.com”. Which according to Intezer no surprise it has zero code reuse from Amazon.com software.

Intezer Link: https://analyze.intezer.com/#/analyses/c6be3f33-e928-48f0-804f-327a7fe88d45

Analysis of of the backdoor I’m naming “SkidRat 1.0”:

This RAT is much smaller in file size compared to other RAT’s the are commonly seen. The actual binary is only 30kb in size.

Initial checks using Detect it Easy, ExeInfoPE, and PE Studio indicated that the sample was likely not packed based on multiple indicators. The entropy was low, the sample had very visible strings, the sections in the binary didn’t indicate they would be over written later, etc.

Static Analysis Screenshots – Quick check for use of a packer:

Main Function:

These initial checks also helped identify that the sample was written in .net. As such I knew I could use my favorite .net decompiler dnSpy

The main function that initiates the backdoor can be seen below. The first thing it does is construct the “MakeRequest” object. Followed by then calling the “MakeSubmitRequest” function within that object.

C2 Callout Variant #1:

  • This is the main workhorse of the program – It covers C2 functionality, calls for system information collection, etc.
    • It defines what the full “requestUrlString” is by concatenating the “this.baseUrl” string with the “applypoliciesrules” string.
    • It then uniqueKey, information and requestUri objects.
    • The newly created “information” object then gathers the DNS Hostname, whether it was identified as a VM, externalIP, MAC address, manufacturer, country name, the clients unique id(generated post infection), Operating System Name, CPUID and Hard Disk Serial number.
    • It then inputs this data into the string “name” after converting it from Json to a string.
    • This string is then encrypted via a call to “UnqiueKeyGenerate.Encrypt(name)”. Then base 64 encoded in the same function call.
    • The string then has the number 9 preceeding it for one of multiple potential reasons. This could be to through off base64 decoding from functioning correctly from casual analysis by Analysts. Or it could be an identifiable “egg” to help processing the data on the server side.
    • The User Agent: “Mozilla/5.0 (Windows NT 6,2; WOW64; rv:19.0) Gecko/201001o1 Firef0x/19,0” is set and used for C2 callouts.
    • The HTTP request is then built and sent to the C2 as a HTTP POST request. The full URL of this request is “hxxp://18[.]218[.]2[.]135/service1.svc/applyingpoliciesrules”
    • After this it returns back to the execution of the main function.

Primary Function “WindowsUpdate” in the WindowsUpdate class.

If arguments/commands are passed as a paremeter to the application then it will call the first version of WindowsUpdate.
WindowsUpdate(string getCommand) – Creates Handle, creates hidden window, performs an internet check, sleeps and then gets re-executed repeatedly(due to the main function).

If there is no arguments then it will call the same function but with an empty string as a parameter.

Internet Check:

The internet connection check attempts to visit https://www.google.com. If this check succeeds then the program will return true to the calling function, if it fails then it will return false.

In the case of it succeeding then the “DoSmartWork” function gets called which in turn calls the “GoOnline” function.

GoOnline – Creates a “MakeRequest” object, calls the “onlineFunction” under the MakeRequest class. That function actually creates a new thread then returns. Then the GoOnline function calls “startupTimer_Elapsed” which in turn calls the “InformationAfterInstall” function. Finally there is a 30,000 msec interval set and the function ends.

The “InformationAfterInstall” is another interesting function.

InformationAfterInstall – This function creates a new MakeRequest object, and calls “normalRunInformation”. This function then sets a local bool variable to the same value as the global variable “runAfterInstallation”. Which in this RAT is default to false.

If the new bool is equal to true then the RAT will run the “Execute_Cleaner” function. the startup timer is stopped and then disabled. Then the function will exit.

The catch statement at the bottom is really not worth mentioning as it should only be hit if there is no internet connection and will just keep checking for an internet connection every 30,000 msecs.

C2 Callout Variant #2:

The “normalRunInformation” function attempts to hit another URL variant of the C2. The full URL of this request would look like “hxxp://18[.]218[.]2[.]135/service1.svc/getInfoAfterInstall”.

This function calls “uniqueKey.generator” which returns the cpuid, and volume serial key into the “dynamicJson” string. This is then sent to the URL above via a HTTP POST request.

The rest of this functions the same as the “MakeSubmitRequest” function.

VM Detection:

The VM Detection function is titled “detectVM”. Specifically, this function performs a WMI request to get information from the “Win32_ComputerSystem” object. After that it then loops through all of the returned objects looking for the Manufacturer “microsoft corporation” and the Model containing the word VIRTUAL(to detect HyperV).

The next things it checks are for the manufacturer to contain the text vmware or VirtualBox.

If any of the checks come back as true then 1 is returned, otherwise 2 is returned.

Persistence:

Persistence is Achieved through the Run registry key within windows. This can be seen in the below two functions. It is worth noting that start menu based persistence in the ‘StartUp” folder is also created however I believe it may be created by the installer and not the backdoor. I couldn’t find anywhere in the backdoor code did this.

Code to Write Backdoor Binaries to Disc

The binary is copied to multiple locations on disk however its primary location seems to be under the C:\ProgramData\WindowsUpdate\ folder. This can be seen in the below screenshots.

Encryption Function:

This is the function where data before it is sent to the C2 HTTP POST requests is encrypted. The best way I can describe this encryption function is the following.

This function takes in string input, the password “qwertyuiopasdfghjklzxcvbnm” is used as the password for the encryption. After the encryption process is completed the result is encoded in Base64 to allow it to safely be sent out afterwords over an HTTP POST request.

Master IOCs List:

URLs:
hxxps://b67x[.]blogspot[.]com/p/10.html
hxxps://gullgas[.]weebly[.]com/uploads/1/2/3/0/123060154/setup.exe
hxxp://18[.]218[.]2[.]135/service1.svc/getInfoAfterInstall
hxxp://18[.]218[.]2[.]135/service1.svc/applyingpoliciesrules:

Hashes:
93197644664f818b877f86c3ae746791f38b01afcd3c6b0789351100a152d070
abe945b3dbd1edc983c3085c65a85acb036aadcfa2e7e53f726683e28318a330
99f086822b234ad3105d16cf6b2a6778b4255c540cafa42a85e98290fe9e615d
99d5ad0eaa6adb5c892bedde7316abc2e2953e0adcfc1c03dd2f8f62b62a1444

IP Addresses:
18[.]218[.]2[.]135

PDB Debug Symbol Path:
C:\Users\Administrator\Downloads\New folder\New folder\isse banao sabkuch\WindowsUpdate\WindowsUpdate\obj\Debug\WindowsUpdate.pdb

Sandbox Reports:
https://app.any.run/tasks/1e852f4a-031a-41da-a41f-e7d5fefa47cd
https://app.any.run/tasks/67cb5e89-fe45-4e8c-99aa-f4ba5204acc7
https://app.any.run/tasks/d98fd4b8-b655-494b-85cc-07d44ac91a0a

By dodgethissecurity_1ooun4

I am a Cyber Intelligence Analyst at a Fortune 50. Each day I have the goal to have improved the life and security of those around myself. I have always been fascinated with computer security. As such I feel the need to share the information and research I have done. So others can learn about how and why things function the way they do in Security.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.