Maze is a recently highlighted ransomware among the ever-growing list of ransomware families. The ransomware is active from the past one year, although it came into limelight due to its new approach of publishing sensitive data of infected customers publicly.
The malware uses different techniques to gain entry like the use of exploit kits or email impersonation. These phishing emails are having a Word document attachment that contains macros to run the malware in the system.
Maze uses CHA-CHA algorithm for encryption and its key is encrypted using the RSA algorithm. Maze can run with or without mutex —it uses some Russian IPs for the webserver to sends information from the victim system(s). It uses RSA encryption request for CnC communication and it will not encrypt the system for the specific region by checking keyboard type.
Stage – I
The attached document file has a form containing an input box in which the number array of encrypted URL and path is present. The document file contains an ActiveX object. When it is executed, URL and path are decrypted post which it calls URLDownloadToFileA() that downloads an executable to the specified location.
Fig 1. URLDownloadToFileA() Call with their parameters
The number array is read from text box then converted into characters and concatenated to form a URL and path where the file is downloaded. Sometimes it also uses PowerShell to download the file. In most of the cases, file is downloaded at “C:\Windows\temp” location.
Fig 2. Characters stored in Number Array
Stage – II
The first stage of Maze ransomware is custom cryptor. This cryptor is a packed one with few imports. It loads libraries by calling LoadLibrary() and GetProcAddress() from kernel32.dll. In this cryptor, function names are stored with their adler32 checksum.
The cryptor is for anti-debugging, it passes junk strings to the function OutputDebugStringW().
Fig 3. Call to OutputDebugStringW()
In the below code, it checks whether the file is present or not, if present it will terminate. Similarly, it also checks specific command-line arguments if it is present it will change execution flow. Then malware loads the resource where actual DLL is present. The loaded resource is encrypted and XOR operation is used with key 0x41. After decryption, we get base64 encoded data.
Fig 4. Xor Loop and API resolution
After copying all data onto the stack, API names are formed and then it calls Loadlibrary() Win32 API. Then it decodes base64 data by calling CryptStringToBinaryA() API. The decrypted buffer is again decrypted using CHA-CHA 20 algorithm which brings the actual payload of Maze ransomware. Along with payload (which is a DLL of Maze), it also decrypts shellcode. By using CreateThread() API, it executes the shellcode.
Fig 5. Call to CreateThread()
In this payload code, it first loads the base address of kernel32 for PEB. The below code shows the loading of the address.
Fig 6. The address is loaded from PEB
The shellcode allocates memory using VirtualAlloc() and copies DLL file to newly allocated space. Then it creates a thread and executes code from DLL. This code changes bytes at the original entry point and then jump to OEP.
B. MAZE PAYLOAD
In decrypted payload, it first loads all the APIs and then does patching of dbgUiRemoteBreakin from ntdl.dll. It is one of the anti-debugging techniques it uses to avoid attachment of debugger.
First it calls VirtualProtect() on dbgUiRemoteBreakin with PAGE_EXECUTE_READWRITE as new flNewProtect. Then it replaces byte 6A with C3 by simple mov instruction. So, if someone tries to attach debugger it will get failed.
Fig 7. Copy 0xC3 at dbgUiRemoteBreakin Entry point
Fig 8. Code before and after patching
Then it enumerates running processes using Process32First() and process32Next(). It calls APIs using ‘je’ instruction and address is pushed onto the stack which is executed after API call. The call is replaced with ‘push’ and ‘jz’ or ‘je’ instruction.
Fig 9. Call to Process32NextW () using jz instruction
After process enumeration, it will obfuscate all the names with its algorithm which uses XMM registers. Then it calculates the hash of this obfuscated string which is then compared with some hardcoded hashes. Some of them are:
Fig 10: Compare hashes with running process hashes
When any of the process hash matches it calls TerminateProcess() and exits the running process.
It will not encrypt files for specific keyboard type. To get keyboard type it calls the function GetUserDefaultUILanguage(). For eg:
Russsian : 0x419 // NOT Encrypt For this value
Ukrainian : 0x422 // NOT Encrypt For this value
Serbian : 0x7C1A // NOT Encrypt For this value
en_US : 0x409 // Encrypt For this value
Fig 11. Check value return by GetUserDefaultUILanguage()
Then It first communicates with CnC server where the IP list is hardcoded, all below mentioned IP seems to belong to Russia.
Fig 12. Hardcoded Ip list
Then data is sent to CnC on the first request: Data which is sent is Username, Computername, OsVersion.
Malware create mutex with unique ID unique ID is created using SHA(GetComputerName() + VolumeID()) .
For the ransomware marker, it creates a unique file on root and each folder.
Maze Encryption Process:
Malware selects files for encryption based on the extension. It excludes the following extensions:
It also excludes the following files:
%windows%, @gaming%, %programdata%, %tor Brower%, %local Settings%, %appdata% etc
Fig 13. Checking folder names and if the same found it will not encrypt the folder.
It first creates key and then exports it in the “c:\programdata\data1.tmp” folder. Then it drops a ransom note in each folder before encryption. Later it will just import the key from this file and call “CryptEncrypt()”.
It retrieves drive letters and then determine type of drive using GetDriveType(). Further it enumerates using API calls FindFirstFileA() and FindNextFileA().
It deletes shadow copy by creating a fake path for wmic and then calls delete recover by calling CreateProcessW()It encrypts files using CHA-CHA algorithm and the key of chacha is encrypted using RSA. For this, it uses crypto APIs. Encrypted files are having a marker at the end which is ‘66116166’.
Fig 14. Encrypted File by Maze ransomware
It creates a thread for each drive, which then again call create thread function for each folder which does the encryption. Encryption will start from the root of C: or D: and parallelly it also accesses the shared drive by using WNetShareEnum() API. The same encryption function is used for encrypting shared drive files. The first folder which is encrypted is “$Recycle Bin”.
CreateThread() with following function for each folder. File is opened as follows. File is encrypted by calling CryptEncrypt() and it is renamed by calling moveFileEx() with extension.
Fig 15. File After encryption
Maze Malware uses many tactics for anti-Analysis:
- APIs are resolved at runtime.
- Indirect calling of API & functions using JE & JNE instructions.
- Patching DbgUiRemoteTracking to avoid attaching of debugger at runtime.
- Checking being debugged flag.
- Checking for VM.
- Checks RAM & hardware size by using API – GlobalMemoryStatusEx & GetDiskeSpaceW.
- Check process names by calculating its hashes.
Prevention measures to stay away from ransomware
Common infection vectors used by Maze Ransomware are phishing emails with MS Office attachments and fake/phishing websites laced with Exploit Kits. Hence, we advise our end users to exercise caution while handling emails from unknown sources, downloading MS Office attachments, enabling macros, and clicking on suspicious links.
Indicators of compromise
Preksha Saxena | Quick Heal Security Labs