By Calista Gasper
For this blog topic, I wanted to investigate a strand of malware that arose in light of our lovely world-wide pandemic. I had conducted a research project in the summer of 2020, and I knew firsthand how much of a risk the massive work-from-home pandemic was from a security perspective. Many companies weren’t adequately prepared to support an entire corporation securely via telework. Adversaries saw this as their window of opportunity to do what they do best: wreak havoc.
Bring on the ransomware. Not a new concept to many of us security personnel, but a new one to many corporations this past year.
According to zeguro.com, “Ransomware, which encrypts and holds a company’s data for money, was a threat long before the pandemic. Though it may not be new, it is increasing. New ransomware samples have grown by 72% over the first half of 2020.”
These ransomware attacks have started targeting SEC registrants, they have started incorporating data exfiltration, and they have become more targeted.
According to the Cybersecurity and Infrastructure Security Agency, one malware to have been on the lookout for was known as the Dridex Malware. This malware, originally making its debut in 2011, became more prevalent again on December 05, 2019. It entered the top ten malware list for the first time and became the third most prevalent malware in March of 2020.
Because of its role in our recent global events, and the fact that it’s still fairly new, I decided to reverse engineer a part of this strand of malware using numerous tools. The reason why I say “part”, is because this malware infects in two parts: a downloader, and downloaded malware. This analysis includes the downloader. Mind you, the ransomware aspect comes in part 2. This analysis is to see how it initially compromises a system!
My goal is let my discoveries provide more insight to how this malware works and understand how to potentially protect against it.
Put simply, Dridex P.1 falls into three malware categories: malspam, emotet and trojan. They all go hand-in-hand in this malware – but before I explain how, let me define those key words:
- Malspam is considered malicious spam emails that deliver malware.
- Emotet, “… is a Trojan that is primarily spread through spam emails (malspam). The infection may arrive either via malicious script, macro-enabled documents, or malicious link” according to Malwarebytes.com.
- A trojan is a form of malware that misleads users of its true intent.
We can see exactly how those classifications fit together when reading the Dridex malware description from techtarget.com: “This malware will target Windows users by delivering spam email campaigns to fool individuals into opening an email attachment for a Word or Excel file. Hidden within these files is the Dridex malware, which will then infect computers in order to steal personal information, mainly banking credentials.”
It took me quite a while to find a live strand of the malware that I could use. Honestly, it took about a day of searching – I guess it’s a good thing that it’s so difficult to find live strands of malware?
Figure 1 – Source of Malware
When I finally did find it, I got a zip file containing 4 different executable files, and four word documents containing the malware in macros. It took me a little while to get familiar with the items in the zip file – wasn’t malware just a single executable? Why were there four? Why were there four word documents?
It took me a bit of analysis to realize they were just different instances of the same part of the malware. I realized later that Dridex utilizes a downloader to obtain the bank-credential stealing malware. More to come on this later. The word documents all held the malicious macros pointing to the first part of Dridex. And the numerous macros were returning identical to one another, which supported my theory.
Using PEview, I threw the binaries in there to see what information I could find. For 1.exe, I could see numerous DLLs the malware uses, and function calls that are used from each DLL:
Figure 2: PEview 1.exe
Figure 3: PEview 1.exe DLLs
Figure 4: PEview 3.exe
I found it very interesting in 3.exe (the only password protected binary file) some of the functions that I found. The functions I highlighted in Figure 3 were such functions of interest. Considering Dridex is a banking credential stealing malware, finding functions referencing encryption and key scanners (indicative of key loggers?) was interesting.
For the remaining executables, they returned the same results as 1.exe and 3.exe so I didn’t include repetitive screenshots in this post.
PEiD and Dependency Walker
Taking the search to PEiD, I wanted to determine if any of the executables were packed/obfuscated with a scheme. Below are the screenshots which indicate that no packing schemes were identified.
Alright, so none of the files were packed. That makes my analysis easier, since I don’t have to worry about any obfuscations throwing me in crazy directions right off the bat.
To glean more information on the DLLs I found in PEview, I used a tool called Dependency Walker. Again, to save on space and time, I will only include screenshots on things I found very interesting, such as the fact that 1.exe appears to handle file manipulation:
Figure 5: 1.exe File Manipulation Functions
I wonder if this is to be used in manipulating the malicious word document. Or is there another file that will be altered in advanced dynamic analysis?
Figure 6: 1.exe Dependency Walker
I also came across these functions, which are clearly analyzing the states and accesses of certain things. For example, a function to check if all access is granted, versus any… A function to check if file APIs are in ANSI, or if there are logoff and shutdown scripts…
This information just provides a nice amount of information to look into when we get deeper into our reverse engineering process.
Unpredicted Discovery – Thank You Windows Defender
There came a point in my investigating process where I had to restart my VM. When I came back, Windows Defender on my VM had alerted me that malicious items were discovered and quarantined on my machine. Looking into it (prepared to see the executable files being the things quarantined), I was surprised to find that it was actually the Microsoft word documents.
Figure 7: Windows Defender Alert
As aforementioned, I had seen in my research that Dridex was also classified as a Trojan. This makes sense, considering it’s hidden in Microsoft word documents that present themselves as seemingly harmless invoice files.
Reading into the alert, I began to realize how this malware actually runs. When I saw “Trojan Downloader”, some lightbulbs went off. The DOC files are dispersed via malspam. When a user opens the unsuspecting DOC file, the malicious macros in the document initiate the downloading of the actual Dridex malware that installs itself to steal your banking credentials.
Afterall, that is what a downloader is – a piece of malware that goes and downloads another piece of malware form the internet and executes it on a local system. Therefore, we know it will need internet connection.
As we can see above, the file in question is Invoice-490087-06.doc because of the oleObject1.bin embedding.
OldObject1.bin, I discovered, is what can be found to hold embedded Excel chart objects. It is my understanding that this one of the embedded malicious macros.
Analyzing the Word Documents
So, of course, what did I do? Open it – duh.
I ran RegShot to be able to compare the state of my system before and after opening the file. I also had ProcMon and ProcessExplorer open and running in the background so I could see what processes triggered when I opened the files.
When I opened it, though, I realized I didn’t have Microsoft word on my VM. Such as, the file wouldn’t open right away. So, I decided to open it in Notepad just to see what the contents were, and I was amused to find it was encrypted:
Figure 8: Invoice-40087-06
Food for Thought: So, if Dridex DOCs need Microsoft Word to open (to access the macros), will the malware be proven ineffective if the user uses any other word processor to open the invoice? Or, does it beacon out regardless of how it’s opened? Is the DOC extension just there for inconspicuousness?
Any time I tired to open another file, I would get this windows system error:
Figure 9: Opening Invoice-707198-06
After “allowing it on my machine” I was able to open it in notepad. It was jibberish just like any of the other ones:
Figure 10: Invoice-707198-06
I had quadruple-checked all the settings on my VM to ensure that the malware couldn’t leak out once I ran it. So, with shaking hands, I ran 3.exe.
I also had ProcMon and ProcessExplorer running in the background to gather any data happening on the backend.
Figure 11 – Running Dridex 3.exe
When I executed it, immediately things started acting weird on my computer. To an unsuspecting user, they would think their computer was lagging out a bit. I noticed the process monitors started freezing a bit, and the VM became unresponsive for a few moments before a command line prompt window opened on the screen and then just as quickly disappeared.
Despite that, everything else seemed “normal”. The CPU had some increased activity, but the number of sockets remained at 1 (I was wondering if another socket would be created for the malware to be downloaded from) and the other statistics remained the same.
I also noticed the executable was deleted from the directory originally placed, and I couldn’t find it in the recycling bin either. I had presumed that the malware deletes itself after running. But when I checked Windows Defender, I saw the following alert:
Figure 12 – Windows Defender Backdoor 3.exe
At first I thought malware deleted itself, then I didn’t. I thought Windows Defender had been doing its job and removed the threat from the computer before (I presume) any action could be taken to compromise the system. But, when I walk through x32dbg, I wasn’t quite sure what caused the malware to delete (more on that later).
The information returned by Windows Defender provides a lot of information on how this malware operates, and I was very intrigued by it!
We realize here that Dridex is trying to open a backdoor. We understand how the malware accesses the victim machine, now. Also, it attacks running processes on a system – such as PID 640. I wonder if the downloader malware opens up key components (such as the backdoor) for the downloaded malware to continue access in.
Let’s recover the 3.exe binary and run it through x32dbg to see what we can find.
Figure 13 – Opening in x32dbg
As we can see, the very first thing that occurs when opening the binary into x32dbg is this command prompt window that appears in the background. Because a breakpoint in the code has been reached, and the program is not actively running, the program halts here. This was the window that I discussed earlier as having flashed open and then closed itself when I ran the malware directly.
Also, notice that LdrInitializeProcess is stored in EDI, and then a file path to ldrinit.c in ESI? It isn’t uncommon for malware authors to try and hide the DLL files associated with their code. One way they can do this is using an LDR.
Figure 14 – Critical Section
I found a “critical section” in the malware shortly after. This section appears to be obtaining the necessary dlls required for operation (depicted in Figure 14).
Figure 15 – DLL in Use
I believe my analysis from the prior screenshots were correct, considering what I found later into the code. This section, titled Set Event, continually calls edx, which will hold the same value to a ntdll every time. I believe this section to be accessing the required functions from the dll that we retrieved in the Critical Section. This would also make sense, considering if the malware cannot access the DLL, then they cannot access the required functions – hence why it is “critical” for it to obtain the DLL handle.
Figure 16 – Control Flow Guard Enforced
Now, above is something that I found incredibly interesting. The malware will check to see if Control Flow Guard is enforced. According to trendmicro.com, “The RtlRemoteCall function is CFG valid, so an attacker can call it out of context. RtlRemoteCall will call the LdrControlFlowGuardEnforced function (see Figure 3), which will check the ntdll!LdrSystemDllInitBlock offset 0x60 value, and it restores the CFGBitmap address (see Figure 4). If the value not zero, the module is CFG enabled, RtlRemoteCall will do nothing and return 0xC0000002U.” And ironically enough, on that website the following screenshot of code that looks almost identical to the preview of LdeControlFlowGuardEnforced:
This is how I drew my conclusions. The malware is looking to see if there is any form of memory tampering protection in place, and I wouldn’t be surprised if later it changes the state of it if it is enabled – such as accessing a PID and injecting process instructions in it.
If we continue to go father, we reach a chunk of code that has “Access violation – no RTTI data!” present quite often, alongside a “Actx” value.
Figure 17 – Process Manipulation
The beautiful thing about reverse engineering and the internet, is you can google anything you don’t understand. Considering I saw “Access violation – no RTTI data!” so many times through this section of code, I presumed it must be important.
Google returned the following from support.laserfiche.com:
“If your Toolkit program shares a connection object across processes, you may receive the following error message when the second process attempts to retrieve repository information:
Access violation – no RTTI data!
You can also receive this error if you are sharing a connection object across threads in a .NET program.”
All of the DLLs and function calls are cryptic – as in, I cannot determine what a particular ntdll.######### call is doing by function name – but considering there is a lot of movement and manipulation of this error code I can presume that this section is starting the process compromising state.
Recall we had a Windows Defender error stating PID 640 was targeted by the malware? Considering the explanation above about how a Toolkit program will trigger this error if a second process tries accessing repository information, I believe this is a reasonable conclusion to make.
Figure 18 – Process Manipulation Con’t.
Ultimately, we can chalk up the first few steps of this malware to be process and memory/heap manipulation which all makes sense considering the information we have on how the downloader works.
Figure 19 – Call to Allocate Heap
Above is a call to RtlAllocateHeap which, “… allocates a block of memory of the specified size from the specified heap” according to docs.microsoft.com.
Something incredibly interesting that I discovered following the Heap Allocation call is depicted below:
Figure 20 – WoW64 Hooking Exemplified
The Wow64Transition call caught my attention immediately. A few Google searches later and I started getting a feel for what this thing may be.
The “lightbulb moment” explanation I found was from wbenny.github.io:
“The Wow64Transition is mostly known to be exported by SysWOW64\ntdll.dll, but there are actually multiple of Windows’ WoW DLLs which exports this symbol. You might be already familiar with the term “Heaven’s Gate” – this is where the Wow64Transition will point to on Windows x64 – a simple far jump instruction which switches into long-mode (64-bit) enabled code segment. On ARM64, the Wow64Transition points to a “nop” function,” according to wbenny.github.io.
Particularly the line mentioning how the Wow64Transition points to a nop function? In Figure 19 we can see the jump to the transition followed by numerous “init3”’s, and concluded, eventually, with “nop”. And below in Figure 20 we can see the nop sled that we found in IdaPro:
Figure 21 – Nop Sled Found in IdaPro
According to Wikipedia WoW64, “… aims to create a 32-bit environment that provides the interfaces required to run unmodified 32-bit Windows applications on a 64-bit system.” Apparently, WoW64 is also used commonly in hooking!
From all this research, I concluded that the malware prepares itself to be compatible with whatever system is running on the infected machine – x32 and x64.
Key Point: This malware may not be exclusive to a particular computer’s architecture. This is something to keep in mind when trying to protect against it. No system can be assumed safe just because of its CPU architecture.
Stepping into the Wow64Transition function, the code took me to a function call sitting atop the nop sled that was mentioned earlier. Stepping into that, because I wanted to see what was in it…..
Figure 22 – Get Current Process
AH-HA! We find exactly where the malware acquires the process ID to compromise. This must support my conclusion that the process manipulation we saw earlier was setting up the grounds for compromise, such as heap allocation and the like. Entering the Wow64 content, we access the actual process that will be attacked (such as PID 604).
Figure 23 – Calling GetCurrentProccessId
Figure 24 – Returned PID by GetCurrentProcessId
I spent forever making through this loop which, in all honestly, confused me for the longest while.
Figure 25 – Loop
The loop continued to iterate through the code that we see above. It keeps passing through the wsprintfw function call, which takes a list of arguments that are values, and returns them as a printf-style string. Formatting parameters perhaps?
If I set a break point at a specific location in the loop, I can continue skipping through at a faster rate. I noticed that with each iteration, the ECX value increases by 4. Although, I do not know for sure what the purpose of this is yet. I wonder if it’s iterating through parts of processes to determine which it can compromise?
Figure 26 – Loop Altering
Finally, the loop ends with “c54223400000074E-d”. Then it continues to GetBinaryTypeW, and passes the directory of the 3.exe file, and the value above. GetBinaryTypeW checks to see if the file in question is an executable file, and if it is, what subsystem it runs on (according to docs.microsoft.com).
It continues to run through the loop a few more times, and then I reach the point where the computer freezes, the command window closes, the 3.exe removes itself from the directory, and x32dbg terminates the process and removes the assembly code.
When 3.exe removed itself, I didn’t receive any Windows Defender notification that action had been taken. Remember when I ran the malware earlier and Defender took over? That didn’t happen this time. After the malware ran via x32dbg, it deleted itself, and Defender wasn’t triggered. Because of this, I couldn’t be sure what makes the malware delete itself. I wouldn’t be surprised if it does delete itself? And that’s the file manipulation being implemented that we saw earlier when analyzing the DLLs and function calls?
At that point, the malware runs the executable with the process ID of the process to compromise, and the system is compromised.
Malspam. Emotet. Trojan. Downloader. Backdoor.
All of these words I would use to describe the Dridex malware – at least the first part of it.
All of those words I discovered from my reverse engineering. None of them I knew were associated with Dridex before starting this project.
From this research I was able to discover how the malware is spread, what makes the documents malicious, how Windows machines will handle instances of the malware (if they’re up to date and patched)…
I also was able to analyze how the downloader takes control of a system and prepares it for the “second wave”.
We could see that the downloader goes through many aspects of the system, gathering data and determining how it will hook the system. We could identify where it was preparing to compromise a running process, and where it took control. We saw the decreased performance, blinking command line prompt, and removal of associated files when the malware was executed.
I’m sure that if I had my VM connected to the internet, we would see the second half of the malware being loaded and executed.
Protecting Against It
To protect yourself from this malware, I would advise users to take the already-very-well-known-steps of NOT clicking on unknown files or links in emails from people. Even if a file looks like it’s harmless, do not click on it. Welcome to the world of Trojan’s. They are designed to not make you suspicious!
Also, I raised a question earlier about if a system doesn’t have Microsoft Word, will they still be susceptible to the malicious macros embedded in the doc(x) files? That question would require a bit more research, but I can reach another conclusion:
Macros are used in Microsoft Word to automate frequently used tasks. We now know that Dridex hides the downloader malware in malicious embedded macros. Considering macros are only there for better user experience, but not critical functionality, an organization may look into a way to stop the use of Word macros. Or, they may look into another word processor that either doesn’t use macros for performance, or are not compatible with Word macros (making the adversaries work a little harder to make it compatible for a different word processor).
I am aware that would be very inconvenient for the average user, but it is a security step that may be taken if so desired.
Windows Defender also came between me and the malware on numerous occasions while I was working. For this, I cannot be upset. It was simply doing its job – and it did it very well! From an engineering standpoint it was annoying to constantly have to go replace the files that were removed. But from a user standpoint? Windows Defender has your back. I would always ensure that it is up to date and running at peak performance, as it did a very good job at mitigating any risks.
I believe a great successor to this initial project is to reverse engineer what happens after the downloader is run. Connect the VM to the internet in an Air Gap lab, and let it run. I’d be very intrigued to analyze how malware compromises the system and waits to steal banking credentials from users – I’m fascinated by how elaborate malware has become.