The Maze ransomware has recently been making the news due to some high-profile infections. In addition to requesting, in some instances, ransoms of 6+ million USD to regain access to the files, the group behind the malware has also leaked some of these files if the ransom was not paid.
In this post, we will look at the detected behaviors and IOCs from the Maze ransomware as identified by RSA NetWitness Endpoint and Network.
The following is the malware sample tested within this post.
SHA256: fc611f9d09f645f31c4a77a27b6e6b1aec74db916d0712bef5bce052d12c971f
Execution of Maze
When the victim gets infected, he will 1st notice that some of his open applications, such as Word and Excel, will get closed. After some time, once the execution of the ransomware is completed, the user’s background will be changed as seen in the below screenshot, instructing the victim to pay the ransom.
The victim can also notice a new text file on his folder (which would get automatically open at reboot). The file provides the detailed instructions on how to do the payment.
RSA NetWitness Endpoint
By leveraging RSA NetWitness Endpoint, we can look at the behavior of the malware on the victim’s machine.
If we first look at the overall details for that specific workstation, we can see:
- An elevated overall risk score (93)
- Some specific suspicious behaviors, such as
- Deletes Shadow Volume Copies: this is a typical ransomware technique to stop the victim from restoring his files
- Run/Writes Malicious File by Reputation Service: the ransomware itself has a known malicious hash value
- Floating Module: might be loading DLLs in memory
By going to the list of processes, we can see the “maze.exe” file (the filename could be different) with a risk score of 76 based on its behavior on the system, and with a known reputation of “Malicious” based on the file hash value.
If we then look at the loaded libraries, we can see that in fact, the ransomware has loaded a DLL in memory:
If we then look at the files to run at startup, we can see that the text files have been added to the startup folders, to get automatically opened at startup and display the payment instructions for the user:
If we finally look at the overall behavior of the ransomware on the system:
- The ransomware is executed
- It closes Excel
- It loads the DLL in memory
- It communicates over the network with multiple public IP address (more details in the RSA NetWitness Network part)
- It deletes the shadow copies
- All the multiple readDocument actions are the ransomware encrypted all the user’s documents
RSA NetWitness Network
By leveraging RSA NetWitness Network, we can then look at the behaviors the ransomware has done from the network’s perspective. In addition, from the Endpoint side, we already know and have confirmed that the ransomware has initiated connections to the Internet.
By filtering on outbound traffic over HTTP, we can identify multiple suspicious behaviors.
- Based on the user agent, the tool used to generate those sessions advertises itself as being IE 11 on Windows 7 (this doesn’t HAVE to be true). Being from IE11 would indicate that we should expect these connections to be from a human/browser, and not from a tool/script/application…
- Direct to IP connections, without a hostname. Even though this can be normal (specially when done to private IP addresses within the local network), it is more suspicious when done over the Internet as it is unlikely for a user to remember public addresses and directly input them in the browser’s address bar (which would be what the tool wants us to believe as it advertised itself as IE11).
- The lack of a referrer header. This header usually includes the previous page that linked to this one. Especially when dealing with direct to IP requests, having a referrer would be needed, as a user doing such a request because he followed a link could be seen as more normal compared to the user directly typing public IP addresses.
- HTTP Post methods without Gets. This is also a suspicious behavior when dealing with HTTP sessions initiate by a human/browser. Typically for a user to “POST” data to a website, he first needs to request and “GET” a webpage that includes a form. Directly posting data is unusual for a human and is usually expected only from tools/applications/APIs …
We can then go to the session reconstruction view to look in more details at one of those sessions.
By reconstructing the session, we can:
- Identify again the user-agent, which can be used as an IOC to identify other infected machines
- The “Host” field having an IP address instead of a hostname, as it should be expected
- Missing expected headers, such as a referrer
- The Entropy meta (between 0-10,000) showing a high entropy level for the request. Entropy allows us to do statistical analysis on the payload and assess how randomized it is. Low entropy would indicate clear-text content, while high-entropy would indicate encrypted content. An encoded payload would be somewhere in between. When using HTTP, which is a clear-text protocol, we would expect either clear-text, or in some cases encoded payloads. A user, through a (supposed) browser connection, wouldn’t be expected to post highly random/encrypted payloads.
A combination of these different indicators does lead to identifying these suspicious network sessions initiated by the ransomware, including:
- Direct to IP requests
- Missing headers (referrer)
- Post without Get HTTP methods
- High entropy for a clear-text protocol
Indicators of Compromise
The below as some IOCs that could be used on RSA NetWitness Network and Endpoint to identify potential Maze infections in your environment. It should be noted that these are based on the specific variant tested as part of this post, and these could vary for different variants. It’s usually recommended to leverage behaviors and techniques instead of specific signatures, such as the ones discussed in this post under the RSA NetWitness Network and Endpoint sections, which would allow to overcome changes in specific signatures.
File Hash
MD5: e69a8eb94f65480980deaf1ff5a431a6
SHA-1: dcd2ab4540bde88f58dec8e8c243e303ec4bdd87
SHA-256: fc611f9d09f645f31c4a77a27b6e6b1aec74db916d0712bef5bce052d12c971f
IP Addresses
91.218.114.4
91.218.114.11
91.218.114.25
91.218.114.26
91.218.114.31
91.218.114.32
91.218.114.37
91.218.114.38
91.218.114.77
91.218.114.79
Domain Names (the malware doesn’t initiate connections there, but this is where the victim needs to go to for the payment/more info)
mazedecrypt[.]top
User-Agent
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko
