This is a guest post from Vishal Thakur, a Security Incident Handler, APAC CSIRT for Salesforce. In this article Thakur takes a deep drive into the technical aspects of a new AZORult variant that Salesforce found globally targeting computers. Those infected would have the Aurora Ransomware installed as well as a information stealing Trojan.
For those who are interested in step-by-step look at the reverse engineering of a malware sample, you will find this post very interesting.
Towards the end of July 2018, we saw a new version of the AZORult trojan being used in malware campaigns targeting computers globally. In this article, we will dive into the malware and analyze its execution flow and payloads.
The initial infection vector is a phishing email that comes with a downloader malware attached. On execution, it downloads and executes the main malware.
This version of the malware comes with two payloads. These are embedded in the main binary and are simply dropped on to the disk and executed. The first payload to be executed is an information stealer that targets local accounts, browsers, saved credentials etc (this is the AZORult part). The second payload is the Aurora ransomware.
We also identified the MalActor “Oktropys” running the Aurora ransomware campaign in this case.
The main goal of this article is to analyze the malware from an incident response/threat neutralization point of view. We will try to understand the code structure and see if we are able to extract some useful IOCs from the binaries.
Analyzing the dropper
Let’s start the analysis by looking at the main binary. As stated earlier, this binary comes with the payloads embedded. You can simply extract these payloads by un-archiving the PE.
To unarchive the binary, we use the 7-Zip program as shown below.
As you can see, we were able to dump the archived data into a folder. Step into the folder two levels and you’ll find the extracted folders:
Step into the folder $1
Now we step into the folder 1337 and find the embedded payloads:
Now, instead of getting to the payloads directly, we’ll follow the malware execution and see how it is using these embedded payloads.
Let’s start by taking a look at the main dropper. On execution, it loads a number of modules that you can see in the image below.
Now we’ll have a look at the interesting modules and their functions that are called on by the malware.
As pointed out earlier, the malware drops two payloads. The first one to be dropped on execution is AU3_EXE_2018–07–18_23–01.exe.
As you can see in the image below, function CreateFileA is used to create the file before the process is launched.
Next step is to create the process:
Once the process is ready, it’s time to launch it by execution:
As you can see in the image below, the process has now been launched.
The next step for the malware is to move on to the next payload. It follows a similar flow to create and launch the second payload.
It calls on the function CreateProcess:
Next, it calls CreateProcessInternal, which will launch the process:
And in the image below you can see the second payload has now been launched.
Now that we know how the main binary loads and executes these payloads, it’s time to get into the payloads and analyze them separately.
Payload #1: AZORult Stealer
In this section, we’ll take a look at the first payload, which is the AZORult Stealer. Let’s start by listing the modules that are loaded by the malware and then picking the ones that are of interest to us.
Note that the above list of modules is the complete list and is only available after the process has loaded completely. As we start the analysis, this list should be considerably shorter.
The malware extracts some important information about the victim’s computer. This information is then sent to the malware’s C2.
Here’s an example of the function GetUserName:
Among other things, the malware also tries to steal browser login data. The images below show you the function call and stack values. We’ll look at some other information that is targeted later in the article.
In order to connect to the C2, the process will now call on function InternetConnectURL and we should be able to see the URL value being passed on to the stack. We can capture this IOC at this point:
Next step is to canonicalize the URL so that it can be used over the wire for establishing a connection to the C2:
Next step is to call the proxy functions before the connection call is made. InternetInitializeAutoProxyDll refreshes the internal state of proxy configuration information from the registry.
Now let’s take a quick look into the crypto functions that are called to encrypt the data before it is sent back to C2.
The malware uses a couple of Crypto functions, but the code seems to be incomplete as some major functions are not called/executed. No hash is generated/duplicated, the actual cryptEncrypt function is not called, key is not destroyed in the end and the context is not released. Crypto functions can still be executed the way they have been implemented in the code but cannot be re-used without problems. It’ll be interesting to see if the authors are trying to move towards full AES encryption for future releases as we saw in the case of Emotet.
This function is called on to get the cryptographic service provider (CSP).
The provider is returned and passed on to the stack as a variable:
The returned value is dumped into the memory space:
Now, the next function, CryptGenRandom is called so that a random key can be generated.
The networking information is now passed on to the stack and then dumped into the memory space. Please note that the data is in the little endian format.
The malware also reads through the cookies that are available on the disk:
Example of the bing.com cookie being accessed:
The malware now tries to send data back to the C2 using a POST request. This is how that request is constructed:
The values are passed into memory, step by step using the ‘memcpy’ function:
And here’s the final request:
The C2 responds with a base64 encoded string that outlines the information that the malware tries to steal (Browsers, filePaths, fileNames etc).
The malware comes with loads of DLLs that are dumped in the directory: C:\Users\Administrator\AppData\Local\Temp\2fda
After successful execution, the process spawns a cmd.exe, which in turns spawns a timeout.exe. Both these process are benign.
Payload #2: Aurora Ransomware
The second payload dropped by the malware dropper is the the Aurora ransomware. Upon successful execution, it encrypts data on the victim’s computer and directs the victim to pay $150 using bitcoins.
The malware is a very basic ransomware and for that reason, we’ll only analyze the networking functions and try to the get the IOC from them.
When executed, here is a list of modules loaded by this malware:
This ransomware is geo-targeted or at least it has that functionality built into it. To perform geolocation it attempts to connect to a geo-location site and get the location of the victim computer. Here’s the call that is made for this purpose:
And the script that runs on the server:
This script reaches out to MaxMind in the background and gets the geo-location of the victim computer. Here’s how that actually works:
At this time it looks like the MalActor is avoiding infections in Russia based on the geo-result from the above functionality.
And here’s the C2 information for the Aurora Ransomware:
Now let’s take a quick look at the connections that are made to the C2 and how the information is passed in both directions.
The server uses a php script to generate a one-time public key, which is then used to encrypt the files on the disk. This key is created based on a computer ID that is generated based on the local information extracted from the computer.
This malware uses ws2_32.dll for all networking operations. Look at the image below to see how the connection is constructed:
First the event is created:
The next step is to load it in memory:
IP passed on to the stack
Now, the request is ready to be sent to the C2:
And here’s the result with the generated key:
Next, let’s take a look at the actual encryption process. As you can see in the image below, the data is loaded into memory, then written to the files (over-written) to encrypt them:
Below is an example of a file in process of being encrypted. This was achieved by inserting interrupts on the function “memcpy” and then executing the process:
And finally, this is the ransom note being written to the disk as a txt file:
The ransom being asked by this MalActor is $150. Here’s the ransom note:
We were able to get to the admin panel of the campaign, which is the back-end for the Aurora ransomware. In this campaign, we can see that the MalActor running the campaign is someone called “Oktropys”, who has been seen running ransomware campaigns in the past and has been quoted as ‘Oktropys ransomware’ in some publications, which is not completely accurate.
At this time there have been two transactions on the associated wallet.
AZORult trojan has been around for quite some time and has been successfully used by criminals to steal critical personal information from their victims. The stolen passwords have been used widely to gain unauthorized access to bank accounts, email accounts and other online applications.
This new version is another example of malware authors bundling in different payloads to maximize the returns. In this case, they have included a ransomware and are asking for $150 for the decryption key, which is being managed by MalActor Oktropys.
The initial vector for this infection is an email campaign, that comes with a downloader (macro-based) that, on execution, downloads the malicious binary, which in turns drops two malware payloads and infects the victim computers.
Main Dropper: 09ffaa1523fbdceb7c0e6fa2be7221c161b5499dd45fc5dd4c210425fb333427 Stealer: 5151d9245858f3e28fa45f696421a49307436808d3ec18ff9e36f7876b0696d3 Ransomware: 41d35a960b3f28b1a729cdae920573de3ccefef7fdd3bbdb9d3ce729b6aa5277