Dridex Analysis

Breaking my spirit…

In this analysis, we will go over anti-analysis techniques that was utilized within this Dridex Sample.

Dridex

Dridex is a Banking Trojan, which was originally found around 2014. The malware is known to be constantly evolving through additions of new features and upgrades. Because of the constant updates, this malware is known to be one of the most sophiscated malware.

Summary

One of the infection chain Dridex is currently known for is below.

1. Victim receives a Phishing Email with malicious Micorsoft Office document attached. The document type can be varied.
2. Victim opens attached file, and proceeds “enable content” which triggers malicious macro.
3. Malicious macro will execute a PowerShell, which creates an external connection to C2 Server to download Dridex.
4. Dridex can execute various malicious executions:
   - Persistence through registering itself within the Autorun.
   - Infostealing capabilities.
   - Utilized evasion techniques
   - Code injections

As this malware is more sophiscated then the previous malware samples, we will focus on the anti-analysis techniques which I have observed in this malware. Also to note, not all of the techniques were identified, since I was not able to fully execute the sample.

Personally, I wanted to analyze Atom Bombing, which Dridex is currently supporting, however in this Analysis we were not able to observe this activity…

Hands on Analysis

In this Analysis, we will dissect the sample that is retrieved from the C2 server. As always, we will conduct this analysis in our VMware Windows 10 guest box with the following tools.

1. IDA Freeware
2. PE-Bear
3. x64dbg

Packing

When sample is loaded into IDA, we receive a following error.

Figure 1: IDA cannot disassemble the code correctly.

While loading this into PE-Bear, it is evident that this sample is packed from looking at the header in Figure 2.

Figure2: Dridex sample header.

Figure 3: Unpacked header seen in other PE files.

From the analysis of this sample, it appears to be utilizing its own packing technique with XOR method. As the sample is packed, we would need to find a way to retrieve the unpacked version to analyze further.

This sample appears to be a DLL file, which needs to be exectuted via rundll32.exe with random function name “test,” since we do not know which function to call, or if it even export any function.

rundll32.exe <directory>\dridex.dll,test 

Above will call the main entrypoint for the dll file and allows us to debug a sample.

Unpacking process needs to first allocate memory and possibly change the memory protection. To analyze this, setting a breakpoint on memory allocation api call would usually lead to this point. In this sample, setting a breakpoint on VirtualAlloc lead to the unpacking process.

Figure 4: VirtualAlloc being called

Figure 5: VirtualAlloc being called

As we can see from the Figure 6, the memory allocated by the VirtualAlloc have written a PE file, which is evident from the header.

Figrue 6: Unpacked region

From this we can dump the memory and retrieve the unpacked sample to analyze further via IDA. The sample appears to be have loaded successfully within IDA and this can be evident from the Import Table shown in Figure 7.

Figure 7: Import Table after unpacked

This sample also does export a function called “SetEndOfLog,” which can be useful for further investigation with the unpacked sample.

Figure 9: Exporting a function

In the resource section of the unpacked sample, it appears this sample is masquarading as SweetScape’s Hex Editor as we can see from Figure 8.

Figure 9: Hex Editor file information

Filename Detection

Some malware evades dynamic analysis and Sandboxes by checking it’s own filename.

Figure 10: Checking to see if it is running under “testapp.exe”

In Figure 10, we can see the sample is calling LoadLibraryW to load filename “testapp.exe.”

In MSDN documentation, LoadLibrary is stated as follows.

"If the function succeeds, the return value is a handle to the module.
If the function fails, the return value is NULL. To get extended error information, call GetLastError."

Since LoadLibrary will return the Handle of the file that it loads, this can be the indicator if the filename exists or not. From Figure 11, it is evident that the file is checking the return value(eax register) of LoadLibrary.

Figure 11: Return value is being checked

If the filename did match(meaning proper Handle was returned), the sample would divert the code to enter never ending “push ss” cycle.

Figure 12: If the filename existed, it would return to this push ss cycle

This sample appears to be checking the following file names.

sample.exE
testapp.exe
self.exe

Dynamic Library Resolving

In Static Analysis, many of the Analysts would look into Import Table of the sample to understand the behavior of the malware. Many times the combinations of WinAPI can be an indicator of certain malware behavior.

However malware authors would not want their software to be easily understood and reversable. They would often hinder this analysis by resolving and loading the libraries dynamically at runtime. By using this method, the libaries would not show up in the Import Table and would not allow Analysts to know which APIs are being used just from Static Analysis.

In this sample it was interesting because the WinAPI name that was being resolved at runtime was allocating each character at runtime.

In Figure 13, the sample is allocating each characters from “VirtualAlloc” Dynamically onto stack.

Figure 13: Dynamically resolving VirtualAlloc

Figure 14: Characters gets concatenated one by one onto a stack

This sample utilizes combination of LoadLibrary and GetProcAddress to retrieve the API it needs at the runtime. The LoadLibrary allocates dll files into memory and then it will retreive the function via GetProcAddress.

Figure 15: GetProcAddress call

Figure 16: GetProcAddress loading LCMapstringA from Kernel32.dll

These calls appear to be done as one of the unpacking procedures, to create a proper import table.

Figure 17: Import Table creation afte unpacking

The list of these APIs are as follows.

FreeConsole
DisableThreadLibraryCalls
VirtualQuery
LCMapStringA
IsBadReadPtr
HeapValidate
GetStringTypeA
GetStartupInfoA
GetLocaleInfoA
LoadLibrary
GetConsoleOutputCP
FreeEnvironmentStringsA
FlushFileBuffers
DebugBreak
CreateFileA
GetLastErrorA
GetEnvironmentStrings
OutputDebugStringA
MessageBoxW
GetUserNameW

DisableThreadLibraryCalls

According to MSDN documentation, this API will disables the DLL_THREAD_ATTACH and DLL_THREAD_DETACH notifications for dlls. This is often utilized to optimize the performance for Applications that utilizes multiple dlls, frequently creating and deleting the thread.

However this API call also detaches the DLL_LOAD signal, which will prevent the malicious DLL loading event that may take place in the future. This API can increase the invisibility of possible malicious dll injections.

From Figure 18 and Figure 19, it appears this sample is calling itself for DisableThreadLibraryCalls, which may be the indication of creating invisibility on future DLL injection of itself to other processes.

Figure 18: DisableThreadLibraryCalls function call on the original DLL.

Figure 19: Stack of DisableThreadLibraryCalls, which we can see loading the original dll.

rtlAddVectoredExceptionHandler

When Exceptions are raised, it is first handled by debuggers. If an exception is raised, but no other facility was able to process it, the exception is passed to Structured Exception Handling(SEH). Malware often manipulates SEH at runtime in order detect if it is being debugged.

Vectored Exception Handling(VEH) is an extension to SEH and it can be also utilized to detect debugger. However while debugging I was not abe to identify the location of where this Exception was triggered for anti-debugging…

Interrupts

Breakpoint interrupts in software will be interpreted as Software Breakpoints by debuggers and this can be often utilized with combinations of SEH Handler to detect whether the sample is being debugged.

While debugging, the sample ran into EXCEPTION_BREAKPOINT which stopped it from running.

Figure 20: EXCEPTION_BREAKPOINT

From Figure 21, it is evident this EXCEPTION_BREAKPOINT occurs due to int3 instruction, which appears to be placed by malware authors intentionally.

Figure 21: EXCEPTION_BREAKPOINT

While this can be bypassed with patching the int3 to NOP instruction, it appears to divert the code into non-executable memory location and triggers EXCEPTION_ACCESS_VIOLATION

Figure 22: Replaced int3 with NOP instruction

Figure 23: Returns to non-executable locatoin

Figure 24: EXCEPTION_ACCESS_VIOLATION

The non-executable memory allocation was done by API call RtlCreateHeap.

From further research on SEH, it appears some malware authors create read-only memory location and divert the code flow if the malware detects a debugger, which is likely the case.

Conclusion

Malware almost always includes some anti-analysis technique to hinder Analysts from analyzing and reversing. In this Analysis, we went over anti-analysis technique which I saw in this sample. I’m sure there were more, as I was not able to identify the antidebug technique which lead me to the non-executable memory location. The art of malware is deep and more you know, the more I become aware that I still have long way to go…

Reference

Dridex | Malware Trends Tracker

Stopping Serial Killer: Catching the Next Strike - Check Point Research

I Hash You: A Simple But Effective Trick to Evade Dynamic Analysis

LoadLibraryA function (libloaderapi.h) - Win32 apps