AZORult Trojan family was first observed in 2016. This Trojan is a highly sophisticated malware that steals information. Since 2016, different variants of AZORult have been observed. The flaws and deficiencies found in earlier versions are fixed by redevelopment of this Trojan in Delphi and C++ languages. Adversaries use this Trojan for stealing information such as browsing history, cookies, credentials, Cryptocurrency information etc.
The malware sample assessed in this report is compiled in the Borland Delphi i.e. Pascal based development language. An important consideration here is that Borland is compatible with Windows environment. AZORult v3 variants are developed in Delphi language.
The variant analyzed in this report is an Information stealer. It uses base64 algorithm to encrypt the communication with its Command and Control (C2) while stealing the information stored in different browsers’ directories.
Following are the summarized characteristics of the assessed AZORult malware sample as per MITRE ATT&CK tactics and techniques and Cyber Kill Chain (CKC) steps.
|Observed Characteristics||MITRE ATT&CK||CKC|
|Phishing i.e. T1566 is observed for propagation and spreading via different phishing campaigns.||Initial Access||Delivery|
|User Execution i.e. T1204 technique is used by this AZORult variant. No Auto-Execution observed during sandbox analysis, nor any auto-execution parameter was observed while studying the code.||Execution||Exploitation|
|Event Triggered Execution i.e. T1546 and Create or Modify System Processes i.e. T1543 techniques are used to hijack SVCHOST process for information stealing.||Persistence||Installation|
|De-obfuscate/Decode files or information i.e. T1140 using base64 stream, Exploitation for Defense Evasion i.e. T1211 by gaining Windows Defender permissions, Modifies Registry i.e. T1112 by adding registry values are the major techniques used to evade detection.||Defense Evasion||Installation|
|File and Directory Discovery i.e. T1083 technique is used for discovering different default browser directories where user data and cookies are stored.||Discovery||Reconnaissance|
|Collection of local data i.e. T1005 and Screen Capture i.e. T1113 capabilities were found during analysis||Collection||Action on the Objective|
|Application layer Protocol i.e. T1071 technique using port 80 to communicate with C2 Server||Command and Control||Command and Control|
|Exfiltration over C2 channel i.e. T1041 is observed for exfiltration of information.||Exfiltration||Action on the Objective|
Following are the identity information of the assessed malware sample.
|File Type||Borland Delphi 4.0|
|File Info||Portable Executable 32|
|File Size||726.00 KB (743424 bytes)|
|Virus Total Score||58/69|
|Hybrid Analysis Score||17%|
“An information stealer (or info stealer) is a Trojan that is designed to gather information from a system. The most common form of info stealer gathers login information, like usernames and passwords, which it sends to another system either via email or over a network.”
The unique identification of this malware i.e. SHA256 hash value is “8480058fc20ebfef47d1ebccbb54b88f656715b99c2d4e80ad46b05906ff4dbe”. First, we reviewed the HEX value of the executable (.exe) file. At the first offset i.e. 0000000, the ASCII value is MZP which confirms that this is an executable (.exe) package.
In Memory, the .rdata section is an important section which stores literal strings, constants, and debug directory information that is used for import and export of subjected malware. As shown in the evidence below, the executable was packed, hence no other information was found during Hex analysis.
Now, we need to identify the packing technique used in development of this malware. Mostly malwares are packed using customized packing techniques. This executable was packed using a custom packer. However, the development language was identified as Borland Delphi language as shown in evidence.
Looking inside the assembly code, the malware was coded for Sandbox Defense Evasion techniques. Upon execution, the malware senses the environment in which it was executed. It called GetTickCount function to retrieve the time information in milliseconds that have been elapsed since the system was started.
After the GetTickCount function, malware was coded to sense the display resolutions of the environment in which it was running. GetMonitorInfo function retrieves the resolution of the display. Sandboxes hosted on the VM have different display resolutions than the normal Laptop and Desktop display.
The malware was not coded to sense only basic sandbox characterstics, CreateToolHelp32Snapshots observes the presence of monitoring tools. It compares the value of running processes (specifically process monitoring tools) with the hardcoded values defined in the code.
If process value matches, that means the malware finds out if a monitoring tool is running in the environment, it therefore breaks the function and goes to sleep mode. As CMP register shows, this function is comparing the retrieved information with the hardcoded process name.
We prepared two sandbox environments to test this behavior. A sandbox was setup running monitoring tools with their default naming conventions. The other sandbox was setup with modified naming convention of monitoring tools.
Then we executed the malware in both sandboxes. In the sandbox having default names of monitoring tools, the malware detects that it is running in a sandbox environment and jumps to sleep function as defined in the code.
CreateToolHelp32Snapshots condition in the code was comparing the default process naming (such as “Procmon” in our case) and jumps to the SLEEP API function along with NtDelayExecution to make itself sleep and delay its own execution.
Now, let’s discuss what we observed in the second sandbox (sandbox running the process with modified names). We found malware in running state. It first called Windows API i.e ActivateKeyboaredLayout. It was collecting the retrieved keyboard layout values in hkl parameter. This function resembles the behavior of Credential Stealers.
Then it is found loading the LoadResource module to modify registry keys. It disabled the Windows Error Reporting feature by modifying HKLM\Software\Microsoft\Windows\WindowsErrorReporting\ WMR\ key to disable it (also defined in below in figure 16). Malware prevented the machine from sending any error report to Microsoft. Evidence of all registry keys are discussed in registry changes section below.
While reviewing the DLLs associated with the malware, we found WININET.DLL i.e. used to initiate an internet connection. This is an important DLL which indicates the internet connection requirement. There was a number of DLLs found in the code, those DLLs were observed in behavior as well. The complete list of DLLS are discussed in DLL section in this report.
In packet capture, we found C2 communication at IP address 184.108.40.206 via TCP steam as shown below.
The base64 encoded stream was observed in packet capture containing the queries from the C2 server. Complete base64 encoded strings and decoded strings can be viewed from Decoded Base64 Strings from C2 Server as referral. Some considerable queries from C2 server are discussed below.
We found instructions for the malware to look into the Microsoft\Windows\Cookies in the APPDATA directory of the current user (as highlighted in the evidence). The malware was attempting to steal information from other directories as well as the ones instructed by its C2 server.
The malware, after stealing the browser’s cookie information, writes the stolen information into the text (.txt) file using the WriteFile function. We found newly created text (.txt) files as shown in the evidence.
An interesting observation to highlight here is that the C2 was accepting the responses in gzip/deflate encoding. The AZORult uses gzip/deflate encodings to send user name and password file. Here we can see the sandbox responding to the queries of C2 to steal information in gzip/deflate format.
Following are some considerable queries we observed from the C2 Server. For complete base64 encoded strings and decoded strings you can use this link Decoded Base64 Strings from C2 Server for reference.
SQLite3 Query Language were also found retrieving username and password including the details of credit cards, as also shown below:
Another attempt was observed to retrieve the cookies through the query.
It is also found retrieving vaultcli.dll which is Credential Vault Client Directory.
Note: Vaultcli.dll is statically linked to the following files (all of them were noticed during code analysis and API functions mentioned above in the respective section)
The following strings were observed in the network packets in encoded format. Decoding the packet exposed the following keywords which are the different browsers used popularly.
Other than browsers, following bitcoin related keywords were also observed
Following keywords were observed indicating the email clients
Following list indicates legitimate Sub DLLs used by this malware to perform its activities.
Upon execution, the malware modified the following directories.
To create its persistence, this malware was adding registry “HKCU\Software\borland\Locales” as shown below:
It disables the Windows error response by adding key value “1” into the registry address of “HKLM\Software\Microsoft\Windows\Windows Error Reporting\WMR\Disable” which definitely means that windows error reporting was disabled.
Following are the dependencies observed in this malware file.
In conclusion, the AZORult malware variant observed was found stealing the information stored in the browser’s directories. Encoded communication with its C2 reveals the encoded queries looking for different directories. Being a highly sensitive malware with defense evasion technique, it has hiding capability. Presence of C2 and DLLs may advance the behavior of this Trojan. Keeping the anti-virus up-to-date and not executing any suspicious file is recommended to prevent execution of such info stealing malware by mistake.
The above analysis is performed in a controlled environment in Rewterz Threat Intelligence Labs. In case, you have any malware samples, binaries, that need to be analyzed, contact us at firstname.lastname@example.org.