BazarLoader Analysis

BazarCall be like..

We will analyze BazarLoader.

Summary

BazarLoader(BazaLoader) is a backdoor Trojan which is designed to collect sensitive information, control and deliver additional malware on the infected machine. The malware has been identified as Team9 malware family which was tied to group responsible for developing Trickbot.

In the recent campaign, it utilizes combination of phishing email and the call center to force the victim to download a malicious document for the initial infection vector.

Figure 1: Chart regarding BazarCall campaing from https://unit42.paloaltonetworks.com/bazarloader-malware/

In our analysis, we will go over BazarLoader executable file and some of it’s functionality.

The execution flow of this malware in a high level is a following.

1. Unpacks and indirect call into shellcode
2. Unpacks and indirect call into DLL
3. Creates external connections

According to the above execution flow, it can be separated into three functionalities which we will look into in this analysis.

• Injection
• Anti-Analysis
• External Communications

Injection

This executable was seen to be executing 3 code injections; two shellcodes and one DLL.

The first shellcode appears to be packed and located in .wdata section of the executable, which later gets unpacked.

Figure 1: .wdata section

Figure 2: ShellCode Dumped to memory

Figure 3: First shellcode

Once the execution flow enters the first shellcode, it prepares for direct syscall by mapping ntdll.dll. This technique can be seen by some malwares to evade API hooking by malware analysts. Some of the API, which are called for the preparation are as follows.

• ZwQueryInformationFile

Figure 4: ZwQueryInformationFile call

Figure 5: File handle BC

Figure 6: ntdll.dll

• ZwOpenFile
• ZwReadFile

Figure 7: ZwReadFile call

• ZwCreateSection

Figure 8: ZwCreateSection

• ZwMapViewOfSection

Figure 9: ZwMapViewOfSection

Figure 10: Pointer to base address 96EAEFEFB0

Figure 11: View of section

Once appropriate sections are mapped, first shellcode will proceed to prepare for another injection with direct syscalls.

Figure 12: Direct syscall

Figure 13: Direct NtProtectVirtualMemory call

Figure 14: Access permission PAGE_EXECUTE_READ(20)

With combinations of various syscalls (NtCreateSection, RtlAllocateMemory, NtMapSectionMemory, and NtProtectVirtualMemory), the first shellcode allocates second shellcode and executes.

Figure 15: Second shellCode entrance

Figure 16: Second shellcode dumped to memory

The second shellcode’s main functionality was to unpack and execute the dll

Figure 17: Changing unpacked dll’s memory protection

Figure 18: Changing memory protection to PAGE_EXECUTE_READ

Figure 19: DLL

Once the execution flow enters the DLL, it will proceed to attempt creating C2 communications, which we will see in the later section.

Anti-Analysis

The executable utilizes several different anti-analysis techniques.

• Packing
• Direct syscall

Direct syscalls created in the first shellcode creates debugging more difficult since the analyst will not be able to simply create a breakpoint on the function call from the ntdll.dll.

• GetProcAddress and LoadLibrary

This combination is common, however it was also seen to use native api call for LoadLibrary(LdrLoadDll)

Figure 20: LdrLoadDll

• String obfuscation

In some of library calls, it dynamically appends characters to form a library name.

Figure 21: Dynamically appending chars for users32.dll and msvcrt.dll

• NtQueryInformationProcess

In the first shellcode, it calls NtQueryInformationProcess with ProcessDebugPort flag to check if the process is being debugged. This is done through direct syscall.

Figure 22: Direct syscall of NtQueryInformationProcess

Figure 23: ProcessDebugPort(0x7)

According to msdn documentation, return value:

Retrieves a DWORD_PTR value that is the port number of the debugger for the process. A nonzero value indicates that the process is being run under the control of a ring 3 debugger.

If the result of the NtQueryInformationProcess is nonzero value, then shellcode will terminate itself.

Figure 24: Checks the result of direct syscall

External Communication

The external communications are created by the DLL which is unpacked by the second shellcode. It attempts to create connections to following three IP addresses.

45.148.120[.]77
18.222.84[.]78
3.141.31[.]97

It will check connection result with GetLastError, and sleeps if it fails for 30 seconds, which repeats 3 times.

After the above connections, it will also attempts to create a connection to api.opennicproject[.]org, with geoip api call to retrieve OpenNIC DNS resolvers. Some malwares are seen to query their own OpenNIC DNS servers because it is difficult to track and takedown these servers due to its decentralized architecture.

Conclusion

The malware had various techniques to evade analysis and detections until it started with the actual external communications. Once infected with this malware it will likely deliver post-exploitation malwares if it succeeded with external communications. If the infection of this executable is successful, it is safe to assume that the post-exploitation download is successful. In this case, it will be recommended to isolate the machine from the network and re-install the OS.

Reference

Malware Mitigation when Direct System Calls are Used - Cyberbit

Automated Malware Analysis - Joe Sandbox Cloud Pro

BazarCall Method: Call Centers Help Spread BazarLoader Malware

New Threat Intelligence Reveals Misuse of DNS Protocol

Microsoft Windows System Call Table (XP/2003/Vista/2008/7/2012/8/10)