TLP: WHITE https://www.us-cert.gov/tlp

Malicious Activity Report: AZORult InfostealerAuthor: Minh Hoang

Executive SummaryAZORult is a popular information stealer (infostealer) that the cyber security community first identified in 2016. In March 2019, a security researcher observed a new variant of AZORult that was written in C++ rather than Delphi,1 as were previous versions.

The sample lacked methods of achieving persistence, which we consider an indicator that it is a version still in development. We therefore expect to see updates to this version in the next several months. However, the communication method was kept intact from the previous version. AZORult sent the collected data, which was encrypted using a three byte XOR algorithm, to its command and control (C2). Of note, one of the items in the decrypted message was a screenshot of the infected computer’s desktop.

For perspective, we compared this new AZORult version to Lokibot, another infostealer, which we analyzed previously. The AZORult sample was not as straightforward, and the code quality did not appear to be as professional as Lokibot, but it nevertheless collected information from the infected machine, and user credentials from applications. We also found AZORult to be easier to detect based on a signature left by the Autoit script embedded in the original binary.

Finally, we judge that AZORult was likely being used to target individual consumers and gamers, due to the inclusion of Stream in the list of applications in the binary.

AZORult Threat CharacteristicsAZORult has been a popular information stealer since mid-2018. There have been several versions since it first appeared in the wild in 2016. Up until March, the most current version was 3.3 and it was the last AZORult binary developed in Delphi.2

AZORult’s other notable characteristic is that hides its activities by using hollow process injection3 to insert itself into a legitimate Microsoft Windows application. AZORult then collects information and credentials from infected machines and applications, including but not limited to Mozilla Firefox, Google Chrome and Stream.

IdentificationFor this paper, we analyzed a sample of the March 2019 variant of AZORult.4 We found a link to the sample5 on the Twitter account @Racco42.6

TLP: WHITE https://www.us-cert.gov/tlp

Key CharacteristicsIn early March 2019, a security researcher discovered an AZORult binary written in C++. The malware’s original author has not claimed the newest version, but the researcher suspected that he was source.7

Our sample contained an Autoit script embedded in the original binary’s resource section. In the previous version (3.3), the Autoit script was separate and had to be launched by a Windows Setup Application.8

AZORult’s normal persistence method9 was absent in our sample, leading us to assess that it is still under development and that the author may release an update containing a new version of this function in the next several months.

DependenciesWe tested the main binary in a Windows 7, 32-bit environment (x86), though we believe it can also run in Windows 7, 64-bit and later versions of Windows as well, because they are backward- compatible with x86 executables.

The victim system must have an internet connection for the binary to fully execute and communicate with its C2.

AnalysisOur dynamic and static analyses on the sample binary revealed that this AZORult sample leveraged an Autoit script to insert its main binary into svchost.exe, which is a legitimate Microsoft Windows application. This sample collected system information, user information, user application credentials, web browser cookies, and took a screenshot of the infected machine’s desktop. However, we did not observe it attempting to achieve persistence, which is unusual for modern malware.

Dynamic AnalysisWe conducted a dynamic analysis of the new AZORult sample in a safe and controlled environment with sensors and monitoring applications to observe its behavior on a vulnerable system and network. We found that AZORult collected system and user information, made a DNS request to find the IP address of a hard-coded C2 domain, and then sent encrypted information back to the C2 using two TCP POST requests.

If the infected system did not have internet access or could not resolve the C2 domain after the DNS requests were made, AZORult would terminate the process after several attempts. Since this binary sample lacks a method to achieve persistence, the threat to the victim is significantly lower if the process fails after the initial execution.

After executing, the binary invoked svchost.exe, a generic host process for Microsoft Windows Operating System (OS) services, located at %WinDir%\System32\svchost.exe (Figure 1). The full path of this file is C:\Windows\System32\svchost.exe.

Figure 1

Svchost.exe has been abused by many malware because it is a process name that Microsoft Windows uses for many of its services. From a file storage/organization standpoint, the svchost.exe processes are usually grouped under another application named services.exe” (Figure 2). In this case, we found that there was a stand-alone svchost.exe, which was suspicious and matched our monitoring tool output in Figure 1.

Figure 2

When we executed the binary in a machine without a network interface, it stopped working after two attempts to resolve a DNS request to directdns[.]duckdns[.]org. During its second attempt, we used fakedns and inetsim in an isolated environment to bypass this check and capture DNS and TCP requests made by the malware.

We then stopped the process and checked the results from fakedns and inetsim. Fakedns is a useful application to bypass simple network availability from malware because it will respond to every DNS request with a hardcoded IP that we

TLP: WHITE https://www.us-cert.gov/tlp

created. The results showed us that the binary made a DNS request for directdns[.]duckdns[.]org, and fakedns responded with our desired IP address (Figure 3).

Figure 3

After the DNS response, the malware sent two TCP POSTs. Both requests carried compressed, encrypted data, and the second request was significantly larger than the first.

We did not observe the binary attempting to achieve persistence in the infected machine at any time during the dynamic analysis.

Static AnalysisIn our static analysis, we determined that the data AZORult attempted to send back to its C2 was encrypted using a three byte XOR algorithm. We also detected an Autoit signature in the original binary’s resource section, as well as analysis evasion techniques.

Extracting and Decrypting AZORult Data to Send Back to C2

The compressed and encrypted data from the TCP POSTs contained information that the binary collected after infecting the system. Using information from our prior research, we were able to determine that the encryption used a three byte key XOR algorithm.10

• Unlike one byte key XOR algorithms, which are relatively easy to guess based on raw data, three byte key XOR algorithms require brute forcing and educated guesses to obtain the XOR key.

The key for our sample turned out to be \x03\x55\xae. It allowed us to decrypt the data in the second POST request and obtain the unencrypted message, which contained system and user information such as application credentials.

However, not all the data in the unencrypted message was readable. There was a large unreadable data blob as well as hex encoded data. The latter included the reference “PK,” which happened to be the first two bytes of the ZIP archive

file header. It was followed by “..” which usually indicates the presence of unreadable characters (Figure 4).

There were multiple PK strings in the decrypted message. We viewed the file in hex rather than ASCII and discovered that it had two different types of headers. One was \x50\x4b\x03\x04 and the other was \x50\x4b\x01\0x02 or \x50\x4b\x05\0x06 (Figure 4). According to standard ZIP archive file structure,11 the first header is the local file header, and the second is the directory header inside the ZIP archive file. Having multiple PK strings meant that there were multiple files and directories in one ZIP archive file.

Figure 4

Knowing this, we extracted the ZIP archive blob from the decrypted message to a HEX editor to save as a separate file with a ZIP extension. We then decompressed the file, which revealed a list of files and a folder (Figure 5).

Among them, we found PasswordList.txt, which contained credentials for the applications that the AZORult binary successfully collected. In this case, the applications were Mozilla Firefox, Google Chrome, and Outlook POP3 and SMTP (Figure 6).

We also found src.jpg, which was a screenshot of the infected machine’s desktop. Other files included a list of cookies from the web browsers installed in the infected machine, the system information, and the infected machine’s IP address. The web browser history and metadata were stored separately in the Browsers folder (Figure 5).

Figure 5

Figure 6

TLP: WHITE https://www.us-cert.gov/tlp

Autoit Signature

Based on the metadata of the sample, the binary did not appear to be packed, which is unusual. We noticed a trace of an Autoit script hidden in the binary resources (Figure 7). Autoit is popular among malware authors for packing, unpacking, and executing malware, and finding it in the binary resources indicates that it was used to inject the main binary into another application, known as hollow process technique.

Figure 7

The malware author may have thought that hiding the script in resources would be an improvement on the previous version of AZORult because it can help the binary avoid being detected by file header signature checks and auto decompilers or decoders. However, it introduced a signature for YARA rules, which can detect the whole binary in strings or binary.

Detection and Analysis Evasion Techniques

We discovered that the binary had anti-analysis techniques such as detecting debugging and using GetTickCount to check how long the OS had been running.

We encountered the debugging detection very early in our static analysis. This technique is effective, but easy for a reverse engineer to bypass. The binary used the detector to dynamically check whether it was being executed in a debugger by calling another function built-in to Windows OS - IsDebuggerPresent (Figure 8) - and checking for the BeingDebugged flag in the Process Environment Block (PEB).12 A return value of 0x1 would indicate the process was in debugged mode. We bypassed this by modifying the value to 0x0.

Figure 8

The GetTickCount detection is popular, but only effective against some sandboxes. It returns an integer number in milliseconds, which shows how long the OS has been running.13 This check is a quick way for the binary to see whether a sandbox was started from a shutdown state.

We also found the binary using another legitimate function: CreateMutex, which created a mutex string based on unique information from the infected machine. Malware have been known to use a mutex to prevent themselves from running into an identical, legitimate process.

If any one of these functions failed, the binary would redirect to an error message and terminate the process (Figure 9).

Figure 9

Figure 10

Next, the main binary used hollow process injection on svchost.exe. The technique is not new, but injecting itself into legitimate applications is still an effective method for the binary to hide and evade analysis. There are two requirements for this technique to work:

• The binary must first execute a legitimate Windows appli-cation that is available and stored in the same location as most Windows OSs. This will make sure that the binary is able to run in multiple Windows OS versions. In this case, it used svchost.exe, which is located at C:\Windows\Sys-tem32\svchost.exe.

• The malware must also invoke the application in a memory space where it has full permission to read, write, and execute.

The binary can then replace the legitimate application’s code with its own, which will execute when it is run.

In most cases, all that is left for the original binary to do is call the WriteProcessMemory function to write the main binary (Figure 10) into allocated memory. Once this function runs, we can usually find the main binary in the memory map. In our sample, it was in a space (described in the second bullet above) with a memory allocation type of 0x3000, which is commit and reserve,14 and a protection type of 0x40, which is read and write permissions.15

TLP: WHITE https://www.us-cert.gov/tlp

Once we began analyzing the dumped binary, we found that the target application list included more applications than were available in our testing environment. Therefore, we were able to discover that the malware also sought to harvest victim information from Skype and Steam from Valve, if they were installed (Figure 11).

The main binary strings contained the C2 domain that we observed in our dynamic analysis, and showed how AZORult collected the saved credentials and history for Mozilla Firefox (Figure 12).

Comparison to LokibotAZORult and Lokibot are both popular, active infostealers. They share some characteristics such as using a hollow process injection technique and using a mutex, but they differ significantly in code quality, target application lists, and injection method for the main binary.

We observed that AZORult and Lokibot tend to focus on different applications on a system, which could indicate that they prioritize different types or groups of users. AZORult appears to target consumer machines while Lokibot has the capability to steal information from a wider range of systems.

• AZORult focuses on consumers and probably gamers, based on the presence of Steam on the application target list.

• Lokibot targets many Chromium and Mozilla-based web browsers, including Google Chrome and Mozilla Firefox, as well as file transfer applications in both FTP and SSH protocols.

• These applications can be installed and operated on desktops and server machines, which indicates Lokibot can target both consumer and business systems.

AZORult is comparatively easy to detect but more challenging to analyze. AZORult’s use of Autoit - a third party software - to deliver its main binary creates a signature that is simple for anit-virus tools to detect. However, when malware uses the hollow process injection technique, it is harder to dump the main binary from svchost.exe because it is not clear when the process should be paused for extraction. In addition, using a third party software poses a risk to the malware author because it can introduce vulnerabilities that he/she cannot control.

Figure 11

Figure 12

In contrast, Lokibot is harder for antivirus applications to detect but is more straightforward to analyze. Lokibot uses an obfuscated custom packer developed in the .NET framework, which does not leave signatures for detection. However, it is simpler to analyze and extract the main binary because a .NET binary can be decompiled relatively easily.

ConclusionAlthough this AZORult binary sample was not as large and complex as Lokibot, it was still dangerous and capable of stealing system information and user credentials from applications such as Mozilla Firefox, Google Chrome, Outlook, Skype, and Steam.

AZORult used a hollow process technique to inject its final binary into the svchost.exe Windows OS application to mask its behavior (when viewed in a process viewer) as a legitimate process and thereby evade antivirus applications. Unlike Lokibot, it used Autoit, which was hidden in the original binary resources, to invoke svchost.exe and inject the main binary into this application.

AZORult appears to be more focused than Lokibot due to its smaller set of targeted systems and users. In contrast, Lokibot had a larger set of targeted applications, but most of them were outdated or unpopular, making it unclear who the intended victim set was supposed to include.

Static Analysis

Infoblox is leading the way to next-level DDI with its Secure Cloud-Managed Network Services. Infoblox brings next-level security, reliability and automation to on-premises, cloud and hybrid networks, setting customers on a path to a single pane of glass for network management. Infoblox is a recognized leader with 50 percent market share comprised of 8,000 customers, including 350 of the Fortune 500.

Corporate Headquarters | 3111 Coronado Dr. | Santa Clara, CA | 95054 +1.408.986.4000 | 1.866.463.6256 (toll-free, U.S. and Canada) | info@infoblox.com | www.infoblox.com

© 2019 Infoblox, Inc. All rights reserved. Infoblox logo, and other marks appearing herein are property of Infoblox, Inc. All other marks are the property of their respective owner(s).

Endnotes

1. https://securelist.com/azorult-analysis-history/89922/

2. https://securelist.com/azorult-analysis-history/89922/

3. See Michael Ligh’s “Malware Analyst’s Cookbook”: https://www.wiley.com/en-us/Malware+Analyst%27s+Cookbook+and+DVD%3A+Tools+and+Techniques+for+Fighting+Malicious+Code-p-9780470613030

4. sha256: B465C81CCD2D315E09C4358E9AF7AD8FDA12394851A875879FBC1D20AEB089F0

5. https://urlhaus.abuse.ch/url/153879/

6. https://twitter.com/Racco42/status/1103435627343822848

7. https://securelist.com/azorult-analysis-history/89922/

8. https://blog.minerva-labs.com/analyzing-an-azorult-attack-evasion-in-a-cloak-of-multiple-layers

9. https://blog.minerva-labs.com/azorult-now-as-a-signed-google-update

10. https://www.proofpoint.com/us/threat-insight/post/new-version-azorult-stealer-improves-loading-features-spreads- alongside

11. https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html

12. https://docs.microsoft.com/en-us/windows/desktop/api/winternl/ns-winternl-_peb

13. https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-gettickcount

14. https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-virtualallocex

15. https://docs.microsoft.com/en-us/windows/desktop/Memory/memory-protection-constants