Dridex Analysis
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.
- Victim receives a Phishing Email with malicious Micorsoft Office document attached. The document type can be varied.
- Victim opens attached file, and proceeds “enable content” which triggers malicious macro.
- Malicious macro will execute a PowerShell, which creates an external connection to C2 Server to download Dridex.
- 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.
- IDA Freeware
- PE-Bear
- x64dbg
Packing
When sample is loaded into IDA, we receive a following error.
While loading this into PE-Bear, it is evident that this sample is packed from looking at the header in Figure 2.
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.
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.
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.
This sample also does export a function called “SetEndOfLog,” which can be useful for further investigation with the unpacked sample.
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.
Filename Detection
Some malware evades dynamic analysis and Sandboxes by checking it’s own filename.
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.
If the filename did match(meaning proper Handle was returned), the sample would divert the code to enter never ending “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.
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.
These calls appear to be done as one of the unpacking procedures, to create a proper import table.
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.
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.
From Figure 21, it is evident this EXCEPTION_BREAKPOINT occurs due to int3 instruction, which appears to be placed by malware authors intentionally.
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
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…