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:

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 “”. Which according to Intezer no surprise it has zero code reuse from software.

Intezer Link:

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 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 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:



IP Addresses:

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

Sandbox Reports:

Making MetaData Tracking More Difficult – Ideas to Improve Signal.

Currently, Telecoms and Nation States are able to see direct correlations between the source and destination of Signal messages via MetaData of those communications. However, this is also what gives those same entities power to figure out exactly which individuals to target by tracking down the source and destinations of those messages.

However, I propose that we change this to incorporate additional methods of anonymity that have become common place in other technologies for other software. More specifically the following.

Idea – Sticking Closer to the actual SMS/MMS protocols

  1. User sends a message they intend another Signal user to receive.
  2. Signal messages have a separate envelope attached to store the recipient number in its own public key encrypted envelope that gets attached to the messages.
    1. This is padded to the max MMS size limit so the actual message size is difficult to determine.
    2. This new routing would help remove direct metadata correlation.
  3. The recipient number thats visible in the metadata is for a Signal server instead of the actual message recipient.
  4. This is then sent to the Signal servers.
  5. This gets routed through a signal server and Signal can only decrypt this new envelope to retrieve what the destination number is.
  6. Signal then removes the old envelope and attaches a new public key encrypted envelope in its place.
    1. This new encrypted envelope contains the source phone number of the text message and is public key encrypted so that the text message recipient at the end of this process can decrypt who sent the message.
    2. This envelope is padded as well to meet the maximum MMS size limit as well.
  7. Signal then waits between 5-10 seconds to send this latest text message to the recipient.
  8. Signal sends this message in bulk along with other messages that are received around the same time. To help add more complexity to timing based tracking.
  9. This message’s sender number in the cleartext metadata is for the Signal server sending the message instead of the original sender.
  10. Recipient’s signal instance receives the message decrypts the Signal envelope to determine who the source is, then decrypts the end to end encrypted content.
  11. Signal processes everything the same way within the recipients app like it normally would.

Known Problems That would still exist:

  1. Time and repeated communication based tracking is still possible. (IE same weakness TOR has)
    1. This could be fought by potentially sending of “false” messages that the signal servers would drop. This would happen periodically or intermittently between messages.
    2. Even with a short random delay between messages if a user keeps talking via SMS/MMS eventually the source and recipient can be linked together.

Personal Note:
I think the long term way to make metadata tracking as difficult as possible would be to migrate Signal into more of an end to end encrypted chat application. The constraints of the SMS/MMS protocols make identify safe communications nearly impossible. I am sure someone could invent a method, however currently I don’t believe SMS/MMS is the identity safe way of communicating even with End to End encryption.

  1. That would put more risk of government pressure on Signal itself, however the reason being is because en masse unlimited metadata collection would no longer be possible. Then the onus is on the government to have to file actual requests for metadata in targetted manners.
  2. Eventually, with the increase of nation state based pressure on companies to allow for “Backdoors” in encryption that not only allow metadata tracking but content review as well. I see open source solutions (which will likely be deemed illegal) as the only means to privately communicate. Especially in countries like China and Russia where zero privacy is expected or legally allowed on personal or business devices/communication.

50 Malicious Chrome Extensions – A minimum of 59 Million User’s Browsers Infected Over the Last 3 Years

While monitoring the latest Threat Intelligence and InfoSec news articles I came across an excellent article posted on April 17th, 2018 by the company “AdGuard” linked here. I determined a method of detection based on utilizing this campaigns unique usage of hashes in a .txt for domain comparisons. Specifically there was many hashes that are reused within 28 different plugins I had originally manually identified through the Chrome Extension Website In order for my method of detection to work I had to download 550GB worth of data off the website in order to parse it automatically using a program to search zip files for the existence of one of the sample hashes from the .txt file.

It took quite awhile to find the best method of downloading this much data and this many links in a single instance. However, after multiple tries with different programs I determined the best method was wget2. This allowed me to download from the website in multiple threads. This sped up the download process from the website itself. What caused the other methods to fail was anything from not enough system memory, to crashes to seg faults within the programs.

However, once I did manage to get the data downloaded after multiple programs were tried to parse this much data(similar issues to above) I finally was able to search the data. A program named “FileSeek” was determined to be the best program based on my tests. It took a few days due to me having to store it on spin disk on a DAS but when it was complete I was surprised with the number of unique plugins that had been utilized in this campaign.

To view the raw data regarding this please visit the following google doc’s page which shows all of the details regarding each individual plugin:

Screenshot of Search Program and Some of the results Below:

Being the skeptic I am I didn’t believe at first that there could have possibly been 50 malicious plugins or 133 malicious versions in this campaign. As such I started digging through the results and eventually verified that each and every result had not only the malicious code but the .txt file with the list of lookup hashes in the plugin itself.

Screenshot of One of the .zip files:

Screenshot showing one of the .txt files that are used for domain lookups(based on salted md5 hashes):

Screenshot of the inside of one of these .txt files used for the domain lookups:


It is worth noting that OSINT on the domain itself pulled up some interesting results. While nothing conclusively links the domain registrant with any advance threat actor one of the domains the threat actor for these plugins registered did appear in the following ThreatConnect Report titled “What’s in a Name… Server?” as a “Additional Shady Domain”. I would rate the link to that threat intelligence report low to medium-low at best. It is interesting however that this report is specifically regarding the DNC breach and the OSINT available regarding APT 28/APT 29 and their TTPs during the breach itself.

Screenshot of whois information – cloudfiare[.]com:

Screenshot of whois information – Using Passivetotal Free for Lookup – g[.]qyz[.]sx:

My Personal Opinion as an InfoSec Analyst is that while it may have not been an APT it was much more advanced observed tactics than most the observed malicious plugins than I have seen publicly documented previously. Specifically, the use of Salted MD5 hashes of domains intended to be spied on by the plugin that never get decrypted, the use of legitimate plugin code that is only backdoored periodically and generally is not left with the current version backdoored in the play store(likely to avoid detection), use of Steganography, the code is split up in multiple places in the javascript and encoded so its not one big set of base64 encoded code, and the fact that when I ran the md5’s with their salts against the Alexa Top 1 Million it only decoded 19,000 of the domains being spied on.

List of 19,000 Decrypted Domains from MD5 List in .txt file being used for lookups to determine what domains to spy on:

Detecting Ursnif Infected Word Documents through metadata.

Good Afternoon,

I have recently been working on methods to detect an Information Stealer/Trojan known as Ursnif. The difficulty in detection relies on the use of encrypted Word documents. These documents use an additional encryption pack that comes by default with Office 2007 SP2 or higher. The encryption pack is known as the “High Encryption Pack”. It is used to encrypt the documents in something other than RC6 so simple and automated decryption is more difficult. It also has the added benefit of being extremely fast and not practical to brute force for each variant as the password changes on every email.

The threat actor’s opted to use AES256 for encryption and SHA512 for hashing to make document modifications harder to accomplish without being detected. These are effectively some of the highest settings for encryption and hashing that is available in Microsoft Word. Finally, they purposely implant fake random document summary and summary information into the document to make it appear more legitimate even though it’s malicious. I will go over how I utilized all of these clues in order to detect and block waves of this campaign. As well as an example Yara rule you can implement that targets the specific characteristics of those documents. It should be noted that while the Yara rule is as targeted as possible there is still the potential for false positives in the rare case an end user matches the same exact settings. As such the result should be implemented with caution and approval from your upper management.

This first screenshot shows how the start of the file looks with the magic bytes highlighted. That is the first check the Yara Rule performs. This is also very useful for reducing total number of false positives.

This second screenshot shows the next set of highlighted fields that the Yara rule searches for in order to determine if the document is encrypted. The fields being selected here are also to help target the documents further.

This is the third screenshot it shows additional highlighted fields that are searched for by the Yara rule. If you notice this and the previous screenshot show that the Yara rule’s focus is mainly on the document is encrypted and then secondly verifying the settings preferred by the Ursnif campaign are matched.

This final screenshot shows the varying sizes which demonstrates why the final check for the documents is based on file size. It is set to be less than 200KB in order to reduce the total number of potential false positives. It should also lower the documents needing to be scanned further to make this rule slightly more efficient.

Analysis of my Thought Process:
The document’s when analyzed in their still encrypted state did not have much data to key off of to detect the documents as potentially malicious. As such when analyzing the files I had to key off of the few things I could that when combined were enough to build a valid and effective signature. For every variant I have had a chance to run this rule against it has detected the sample without issues 100% of the time. Unless the threat actor’s were to change their techniques, which is unlikely since thats the least likely thing to change in campaigns. Then this rule should continue to work without fail. Again the only down side of analyzing the encrypted versus decrypted documents is the potential for false positives.

Final Thoughts:
If your environment is able to detect the passwords in the emails proactively and decrypt the files then there is way more metadata that can be key’d off of. And that data would be much more accurate for detection with even lower possibilities of false positives. As such I would recommend if at all possible to analyze the decrypted version of the documents when possible.

Link to Yara Rule:

New PowerPoint Mouseover Based Downloader – Analysis Results


I would like to thank “Marry Trame” at for posting about this new method that was discovered for a malware downloader. A link to the original post can be found at the bottom of this analysis. I would like to note that I edited the domain to my own in the PowerPoint so it wouldn’t actually successfully reach to the C&C server for the Malicious .jse file.

Analysis Summary:
This PowerPoint Document was interesting to analyze. First of all this document was interesting as it did not rely on Macros, Javascript or VBA for the execution method. Which means this document does not conform to the normal exploitation methods. When the user opens the document they are presented with the text “Loading…Please wait” which is displayed as a blue hyperlink to the user. When the user mouses over the text(which is the most common way users would check a hyperlink) it results in Powerpoint executing PowerShell. This is accomplished by an element definition for a hover action. This hover action is setup to execute a program in PowerPoint once the user mouses over the text. In the resources definition of slide1 “rID2” is defined as a hyperlink where the target is a PowerShell command. Due to its length it can be seen in the step by step screenshot explanations below.

When that PowerShell is executed it reaches out to the domain “” for a c.php file and downloads it to disk as a file named “ii.jse” in the temp folder. That gets executed in wscript.exe and then that drops a file named “” which the JavaScript then executes certutil.exe with the -decode parameter. certutil.exe then supplies as the file to decode and saves it in the temp folder as “484.exe”. Then “484.exe” is executed and it spawns mstsc.exe to allow RDP access to the system. After this 484.exe was observed being renamed and saved to AppData\Roaming\Microsoft\Internet Explorer\sectcms.exe by mstsc.exe and then it gets re-executed from the new location. A .bat file was observed being written to disk then executed in cmd.exe. The purpose of this bat file appears to have been to change the attributes of the sectcms.exe program to be hidden, marked as a system file and set as read only. It also deletes any of the files with the following extensions in the temp folder .txt/.exe/.gop/.log/.jse . I sandboxed the payload for 8 hours but no threat actors connected to the system. So I was unable to see what other purpose the backdoor might have if the threat actors had taken specific interest in the system.

Screenshots of Analysis:
Screenshot of Slideshow user is presented after opening PowerPoint:

Warning Message Displayed When User Mouses Over the “Loading…Please wait” text:

If User Enables the Content then they are presented with the following Powershell prompt which quickly hides itself:

Here is a modified callout I did just to test if the powershell was proxy aware – I did this by editing the XML in the PowerPoint Slide:

This is the Slide1 Element Definition for the “rID2” element – It is easy to see that a PowerShell command is set as the target for the Hyperlink:

This is the Slide1 XML for the slide itself. It is easily visible in the red highlighted section how the hoveraction is defined in Slide1:


Sysmon Screenshots:

Sysmon Logging of PowerPoint initially opening:

Sysmon Logged the Execution of the Powershell Command Aswell in its decoded form:

Sysmon Logged the initial Process Creation of the Malicious Payload:

Followed By the Process Creation of the mstsc.exe process which is used for RDP access to an exploited system:

Then the Original Payload process is logged as being Terminated:

Sysmon then logged the file creation of a copy of the original payload. It was named sectcms.exe and hidden under the App Data folder:

Sysmon then captured the re-execution of the newly moved payload:

Sysmon then Logged a bat file being created in the Temp Folder:

Sysmon Then logged the execution of the .bat file through cmd.exe. The source program of the execution was mstsc.exe:

One of the functions of the .bat file were to add the hide, system and read only flags to the payload under AppData:

Sysmon then logged the process creation of a second instance of the sectcms.exe payload:

Finally, Sysmon then logged the termination of one of the two instances of the payload which is named sectcms.exe:

Indicators of Compromise:
File: order.ppsx
MD5: 823c408af2d2b19088935a07c03b4222
SHA1: df99061e8ad75929af5ac1a11b29f4122a84edaf
SHA256: f05af917f6cbd7294bd312a6aad70d071426ce5c24cf21e6898341d9f85013c0
SHA512: 2cc9e87e0d46fdd705ed429abb837015757744783bf1e904f9f22d56288b9554a1bc450142e2b1644a4912c12a522391b354d97956e4cb94890744266249b7f9

File: C:\Users\Current User\AppData\Local\Temp\
MD5: 9B5AC6C4FD5355700407962F7F51666C
SHA: 9FDB4CD70BBFB058D450AC9A6985BF3C71840906
SHA-256: E97B266D0B5AF843E49579C65838CEC113562A053B5F87A69E8135A0A82564E5
SHA-512: AB85132D845437A7900E03C2F3FA773433815A4893E16F7716A5F800558B5F01827F25463EAFF619F804C484A1D23CDD5F2BCCC0F91B4B4D0C117E87D830B1B3

File: C:\Users\Current User\AppData\Local\Temp\484.exe
File: C:\Users\Current User\AppData\Roaming\Microsoft\Internet Explorer\sectcms.exe
MD5: 13CDBD8C31155610B628423DC2720419
SHA: 7633A023852D5A0B625423BFFC3BBB14B81C6A0C
SHA-256: 55C69D2B82ADDD7A0CD3BEBE910CD42B7343BD3FAA7593356BCDCA13DD73A0EF
SHA-512: 19139DAE43751368E19C4963C4E087C6295CC757B215A32CB95E12BDD82BB168DB91EA3385E1D08B9A5D829549DFBB34C17CA29BFCC669C7EAE51456FCD7CA49

File: C:\Users\Current User\AppData\Local\Temp\ii.jse
MD5: F5B3D1128731CAC04B2DC955C1A41114
SHA: 104919078A6D688E5848FF01B667B4D672B9B447
SHA-256: 55821B2BE825629D6674884D93006440D131F77BED216D36EA20E4930A280302
SHA-512: 65D8A4CB792E4865A216D25068274CA853165A17E2154F773D367876DCC36E7A7330B7488F05F4EE899E40BCAA5F3D827E1E1DF4915C9693A8EF9CAEBD6D4BFB

C2 Communications:

IP Address of C2/Payload Domain:


Emotet/Geodo Updated Analysis

Good Morning Everyone,

I have created a passivetotal project for tracking of the Downloader and payload domains. Information can be found in the link below as to 214 different domains that we have observed thus far over the last 3 days. We are estimating 128 unique domains per day but are still encountering various variants. Basic Regex detection of the file names would be [0-9]{4}[.]exe and a generic partial detection which could improved upon [a-zA-Z0-9]+[\_\ ]+[a-zA-Z0-9]+[\_\ ]+[a-zA-Z0-9]+[\_\ ]+(2017|[0-9]{10,11})[.](js|exe|zip).

Sandbox Results – Payloads:

Sandbox Results – Downloader:

Email Subjects:
DHL On Demand Delivery
DHL On Demand Delivery for your attention
DHL On Demand Delivery so far
DHL Urgent Delivery
Get Your Bill
Get Your Bill is Ready
Get Your Vodafone Bill is Ready
Have Your Bill is Ready
My O2 Business – Your O2 Bill is ready
Obecny stan przesylki DHL
On Demand DHL Delivery
Pls, have Your Bill is Ready
Sprawdź stan przesylki DHL
Vodafone Bill is Ready
Your Bill
Your Bill for Vodafone
Your Bill has been already Ready
Your Bill is Ready
Your Bill is already Ready
Your O2 bill hasa been ready
Your O2 bill is already ready
Your O2 bill is ready
Your O2 billing
Your O2 bill is ready
get DHL On Demand Delivery for your attention
get Your O2 bill is ready
get Your O2 bill ready
receive Your O2 bill is ready
DHL Intraship – Shipment notification

File Names:
DHL__Report__Apr___12___2017___number __5940856348.js

File Hashes:


Emotet/Geodo Domains

Good Morning,

While researching a wave of what other analysts alerted as Emotet/Geodo I found 128 different domains that are hosting the javascript based downloader and the payloads.

The list of domains can be found at the following Pastebin, I dont want to link them here as Google will mark my blog malicious if I hotlink the malicious pages.

Pastebin Link: