Malware Analysis – AZORult Info Stealer

Introduction

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.

AZORult ATT&CK Summary

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.

Malware Specimen Identity

Following are the identity information of the assessed malware sample.

“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.”

Analysis

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 136.144.237.217 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.

Decoded base64 Strings

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)

• msvcrt.dll
• ntdll.dll
• KERNEL32.dll
• RPCRT4.dll
• ADVAPI32.dll
• USER32.dll

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.

• GoogleChrome
• GoogleChrome64
• InternetMailRu
• YandexBrowser
• ComodoDragon
• Amigo
• Orbitum
• Bromium
• Chromium
• Nichrome
• RockMelt
• 360Browser
• Vivaldi
• Opera
• GoBrowser
• Sputnik
• Kometa
• Uran
• QIPSurf
• Epic
• Brave
• CocCoc
• CentBrowser
• 7Star
• ElementsBrowser
• TorBro
• Suhba
• SaferBrowser
• Mustang
• Superbird
• Chedot
• Torch

Other than browsers, following bitcoin related keywords were also observed

• Bitcoin
• Litecoin
• Electrum

Following keywords were observed indicating the email clients

• ThunderBird
• Outlook

Legitimate DLLs

Following list indicates legitimate Sub DLLs used by this malware to perform its activities.

• api-ms-win-core-console-l1-1-0.dll
• api-ms-win-core-datetime-l1-1-0.dll
• api-ms-win-core-debug-l1-1-0.dll
• api-ms-win-core-errorhandling-l1-1-0.dll
• api-ms-win-core-file-l1-1-0.dll
• api-ms-win-core-file-l1-2-0.dll
• api-ms-win-core-file-l2-1-0.dll
• api-ms-win-core-handle-l1-1-0.dll
• api-ms-win-core-heap-l1-1-0.dll
• api-ms-win-core-interlocked-l1-1-0.dll
• api-ms-win-core-libraryloader-l1-1-0.dll
• api-ms-win-core-localization-l1-2-0.dll
• api-ms-win-core-memory-l1-1-0.dll
• api-ms-win-core-namedpipe-l1-1-0.dll
• api-ms-win-core-processenvironment-l1-1-0.dll
• api-ms-win-core-processthreads-l1-1-0.dll
• api-ms-win-core-processthreads-l1-1-1.dll
• api-ms-win-core-profile-l1-1-0.dll
• api-ms-win-core-rtlsupport-l1-1-0.dll
• api-ms-win-core-string-l1-1-0.dll
• api-ms-win-core-synch-l1-1-0.dll
• api-ms-win-core-synch-l1-2-0.dll
• api-ms-win-core-sysinfo-l1-1-0.dll
• api-ms-win-core-timezone-l1-1-0.dll
• api-ms-win-core-util-l1-1-0.dll
• api-ms-win-crt-conio-l1-1-0.dll
• api-ms-win-crt-convert-l1-1-0.dll
• api-ms-win-crt-environment-l1-1-0.dll
• api-ms-win-crt-filesystem-l1-1-0.dll
• api-ms-win-crt-heap-l1-1-0.dll
• api-ms-win-crt-locale-l1-1-0.dll
• api-ms-win-crt-math-l1-1-0.dll
• api-ms-win-crt-multibyte-l1-1-0.dll
• api-ms-win-crt-private-l1-1-0.dll
• api-ms-win-crt-process-l1-1-0.dll
• api-ms-win-crt-runtime-l1-1-0.dll
• api-ms-win-crt-stdio-l1-1-0.dll
• api-ms-win-crt-string-l1-1-0.dll
• api-ms-win-crt-time-l1-1-0.dll
• api-ms-win-crt-utility-l1-1-0.dl

Registry Changes

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.

Dependencies

Following are the dependencies observed in this malware file.

1. This malware is designed for 32-bit windows environment.
2. This malware requires Internet Connection to communicate with its C2 server.
3. This malware is highly environment sensitive. It deeply senses the environment before its complete execution.
4. This malware sample keeps itself in sleep mode when procmon.exe is running. It may sense other sandbox tools including procmon.

Remediation

• Block subjected IP “136.144.237.217”
• Update the Hash “8480058fc20ebfef47d1ebccbb54b88f656715b99c2d4e80ad46b05906ff4dbe” on your EDR controls.
• Regularly monitor the internet communications for suspicious connections.
• Keep system up-to-date and patched.
• Do not execute suspicious/unknown files.
• If unknown files are found on system, immediately scan the system with updated anti-malware scanner.
• Frequently Scan the Endpoints with Anti-malware engine.
• Avoid clicking on Ads prompts while visiting websites.
• Do not open suspicious emails.
• Beware of social engineering techniques employed by cyber criminals— ensure employee awareness for identifying phishing emails, impersonated calls, and fraudulent businesses and domains —and learn how to respond to a suspected compromise.

Conclusion

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 info@rewterz.com.