Exorcist Ransomware — From triaging to deep dive

11 min readJul 24, 2020

TL;DR

On Monday 20th while hunting for some REvil samples I stumbled upon a newly introduced ransomware as a service called Exorcist. This ransomware is distributed via Pastebin embedded in a powershell script that loads it directly in memory. This script is based on “Invoke-ReflectivePEInjection.ps1” script by Joe Bialek (@JosephBialek), but it is optimised with an additional function to pass a base64 encoded executable to the main function. This powershell script is possibly generated using the Empire framework. The same technique is used by some of the Sodinokibi/REvil affiliates, and in the past by Buran.

The ransomware is not obfuscated and the majority of the strings are in plaintext stored in the “.rdata” section of the executable. The first thing that the malware does is to check the geo location of the system using the language and the keyboard layout. If the results yield one of the Commonwealth of Independent States (CIS) it quits on the spot. Then the ransomware execute a series of commands to disable and remove backups and kill processes that might interfere with the system encryption. Once it is done with the commands, it writes to disk the RSA public key, the session private key and the extension. This information is not written into a file in a straightforward manner, instead it is written in different Alternate Data Streams on the file “%temp%\\boot.sys”.Then it extracts information from the system such as username, hostname, OS version, keyboard layout, etc. and sends them via http to the server “http://217.8.117[.]26/gateinfo”. Next it gets the amount of cpu on the systems and starts multiple threats to encrypt the system files. Some directories and file extensions are excluded to avoid rendering the system unusable. Once done with the encryption another http packet is sent to the same server this time to the url “http://217.8.117[.]26/gatedrivers”. Lastly, the wallpaper of the system is changed and the ransom notes are dropped in the form of hta scripts with the name convention “<extension>-decrypt.hta”. In these notes we can find the instructions to recover the system that consist of the urls “http://217.8.117[.]26/pay”. “http://4dnd3utjsmm2zcsb[.]onion/pay”, and the “Authorization Key”.

This information will be needed to “sign in” the payment portal shown in the following screenshot:

For the IOCs go to the bottom of the page =D

Exorcist Ransomware Triaging

Once the payload is extracted (base64 encoded) from the powershell loader, we get a PE32 executable. From a quick scan of the file using Assemblyline we get the following interesting insights:

So at a first glance we can see that there are some well known executable names extracted, normally seen in ransomware and coin miners either to prevent processes from allowing access to files that will be encrypted or to free resources to mine more effectively.

Based on the API names extracted from the sample we can say it has some network capabilities as well as some cryptography ones. This is looking more and more like a ransomware!

Lastly we see there is a url extracted from the sample “http://217.8.117[.]26/pay”. If we check what we found on that website (in a secure manner ;) ) we find the following:

Our suspicion was correct, it was ransomware after all!! But what else does this ransomware do? Let’s take a look at its capabilities using the newest tool from Fireeye capa.

So, it seems that indeed this ransomware sends data via http and executes some tricks to check the system to not run on the wrong country ;). Now we are ready for a more serious deep dive!

Exorcist Ransomware Deep Dive

Now it is time to get into the details of this malware. First we are going to take a look at the file from a static point of view by analysing its strings, API calls, and code. And then to complete our analysis and better understand the inner workings of the malware we are going to study it from a dynamic point of view.

Static analysis

Loading the executable on PEstudio helps us to confirm some of the hypothesis we made during the triage and also shows us some interesting aspect of the sample that we haven’t seen so far.

So, some quick takeaways from the analysis so far:

Samples does not obfuscate strings.
It will exclude given directories and files with the extensions shown above to not render the system unusable.
As expected, the ransomware will get rid of the Shadow copies of the files to avoid the easy restoring of files.
It most likely will attempt to stop processes in a predefined list.

Let’s get our hands dirty and look at the code to discover some more capabilities of this ransomware. For this we are going to load the sample to the free version of IDA.

So, one of the first thing is does is creating a mutex to avoid running multiple times on the system. Let’s check what else we find next to the hardcoded mutex string.

Here we can see some interesting strings that we have overlooked before. Seems that there are some countries listed that are most likely used together with the “get keyboard layout” capability seen before to decide if this sample should run or quit. Let’s confirm this theory!

The Ransomware uses the API “GetLocaleInfo” and “GetKeyboardLayoutList” to determine the geo location of the system and check if it should continue running or not. Let’s verify another hypothesis we had. Does the ransomware kill the processes displayed in the strings before start encrypting? For this we are going to pivot from the un-obfuscated strings to the code.

From analysing the routine we see that it is divided in two main sections, the first one running a set of predefined commands to disabled and remove shadow copies and backups, and a second one that goes through the list of processes and calls “taskkill” for each of them.

Another way to browse through the code is to use the IDA feature Xref from graph. This can be done because the sample is not obfuscated, and the windows API calls are been referred explicitly. Using this tool we can guide our analysis following the Windows API calls of interest

Well…I said we could use it, not that it was small nor easy ;). However, if we zoom into it, we can have a good understating of the different functions and have a gist of their purpose. For example:

Here we see the “ShellExecuteW ”API call (always interesting to see what the sample might try to execute) that is called right before exiting. If we go where it is called, we end up in the following routine :

The routine consists of calling the API “GetModuleFileName” with “hmodule” Null to get the path of the executable file of the current process. Then, it prepares a command line that would look like “cmd.exe open <executable path> /C timeout /T /NOBREAK && del” <executable path>\” /F”, execute the command and then exits.

By looking at the XRef graph we also notice some classic Windows API calls used to send http packets over the network. If we follow the references we find the following routine :

By exploring this routine, we see that a post request is done. But now the question is what information is been sent. In the next section we are going to find out exactly what is been sent via the post http request.

In order to fast forward the analysis, confirm some hypothesis, and discover new functionality, we will start the sample in the x32/64 debugger while having Procmon and FakeNet running next to it to get more insights.

Dynamic analysis

Now that our ransomware is running in a controlled environment we can see in more details how the different commands and processes are been killed by it.

Let’s continue where we left trying to understand what is sent to the server over an http post request. In the following screenshot we can see how the IP and Port are decoded from the string stored in the “.rdata” section of the executable.

Once it has that information the malware will start preparing the request. This means setting up the headers and the content that will be sent. Once done it will call the API call “HttpSendRequest” to send the http request. Using FakeNet we received that request and respond with a fake site to emulate the “C2”.

As the picture shows the ransomware sends a big blob encoded in base64 to the c2 server at “http://217.8.117[.]26/gateinfo”. But where is this information coming from? For this we need to go back to the code an analyse what happened so far.

In this function we see that there is a template for a json file were some details about the system are gathered and later appended to the json temple string. Examples of details that are gathered include but are not limited to:

GetCurrentHwProfileA
Gen_token (some crypto API calls are involved)
Query the registry key “SOFTWARE\Microsoft\Windows NT\CurrentVersion”
GetUsername
GetComputername
GetLocale
Etc.

Once it finished querying the system it generates a json that looks as follows:

After the information is gathered, we see that some encryption is initialised (creating encryption keys, specifying algorithms, etc) but some of the information used is queried from a file that was written in “%temp%\\boot.sys” in an earlier stage. The most interesting aspect of this, is that the information is not read from the file itself, instead it queries the file using the convention “filename.ext:string”. This means that this ransomware is using Alternate Data Streams to hide information. Using the ADS-spy tool we can inspect the content that is been read by the malware.

Hidden in this file we can find the generated unique extension, the RSApublic key, and the Private Session Key. Once these values are retrieved the encryption of the json string takes place.

The json string is encrypted with AES CBC and the symmetric key encrypted the with the public RSA key. In the following screenshot we can see the json string in plaintext and then encrypted.

After encryption, the json is base6 4encoded and then added to the http post request as already shown.

What about the file encryption? After all, this is a ransomware, right? So once the first beacon is sent to the server the ransomware starts the file encryption in a multithreaded fashion. This can be seen in the following screenshots:

Once it finished it sends yet again another beacon with data to the server but this time to “http://217.8.117[.]26/gatedrivers”. In the following picture we can find an example of a ransom note that is left in every directory. The name convention for them is “<extension>-decrypt.hta”

So this will be all for now, there are quite some more interesting aspects to research into like how the file encryption is performed at a cryptographic level, how are some of the other interesting strings (powershell get host by address) used, does this ransomware implement persistence mechanisms, etc. Feel free to contact me for comments and questions. Constructive feedback is always welcomed!

IOCs

Samples:

https://bazaar.abuse.ch/sample/027d99aaaa6803a07d07ce0ba1fa66964388129d3b26dcf8621a3310692b0a61/
https://bazaar.abuse.ch/sample/a7e27cc38a39ff242da39d05e04b95ea9b656829dfe2e90e8226351da8813d7d/
https://bazaar.abuse.ch/sample/8d684a790a5683b8decde9fb5a819c4a164d3032723a151a30ff26d3c2b1aabf/
https://bazaar.abuse.ch/sample/bf6e5f9d060ebc5bb70144ca6e795bfc249c6590ab9f45e258ec9b5f3d49eeb6/
https://bazaar.abuse.ch/sample/8da469200a4b3899b23a34232eec537f12c621aa3c8766a9745d8ff721ef5296/
https://bazaar.abuse.ch/sample/b1bcc54ef15f91d9291357eca02862174bd6158e95813eff1ab0c16ba48ff10e/

MD5:

79385ed97732aee0036e67824de18e28
f4009abe9f41da41e48340c96e29d62c
fa4c4ac8b9c1b14951ae8add855f34e8
f188cf267d209a0209a25bda4bb75b86
5a63e7d371dd69c5625f5b48da426c14
cb3a1463f4fd3e74b8f1ca5e73b81816
7e415d5a1b1235491cb698eb14817d31

SHA256:

8d684a790a5683b8decde9fb5a819c4a164d3032723a151a30ff26d3c2b1aabf
6db3aae21a6d80857c85f58c4c8b2cf9c6b7f8b8a9ab1d5496d18eaf9bd0bd01
bf6e5f9d060ebc5bb70144ca6e795bfc249c6590ab9f45e258ec9b5f3d49eeb6
027d99aaaa6803a07d07ce0ba1fa66964388129d3b26dcf8621a3310692b0a61
b1bcc54ef15f91d9291357eca02862174bd6158e95813eff1ab0c16ba48ff10e
8da469200a4b3899b23a34232eec537f12c621aa3c8766a9745d8ff721ef5296
a7e27cc38a39ff242da39d05e04b95ea9b656829dfe2e90e8226351da8813d7d

URLs:

http://217.8.117[.]26/pay
http://217.8.117[.]26/gateinfo
http://217.8.117[.]26/gatedrivers
http://4dnd3utjsmm2zcsb[.]onion/pay

IPs:

217.8.117[.]26

Tria.ge Sandbox reports:

https://tria.ge/reports/200724-gmz55kbvr2/behavioral1
https://tria.ge/reports/200724-2v2mzfsjwx/behavioral1
https://tria.ge/reports/200724-kfjg2xf1b2/behavioral1
https://tria.ge/reports/200724-64rls1gjl2/behavioral1
https://tria.ge/reports/200724-b5zwteacds/behavioral1
https://tria.ge/reports/200724-15z7parj4x/behavioral1
https://tria.ge/reports/200724-zxydprrjys/behavioral1

Acknowledgements:

Special thanks to @rikvduijn and @ValthekOn for helping me figure some of the details out and my team at @kpnsecurity for supporting my crazy projects and reviewing this writeup =D