As malware continues to evolve with increasingly sophisticated and unconventional tactics, it is essential for cybersecurity professionals to develop the skills required to investigate and understand the techniques employed by attackers. Hands-on experience with real-world malware not only enhances threat detection and response capabilities, but also equips professionals to proactively defend against emerging threats.
In this blog, I will build a secure lab and analyse one of the most high-profile pieces of malware - The Zeus Banking Trojan.
The Zeus Banking Trojan (also called Zbot) is a proflific trojan virus that first emerged in 2007 targeting the United States Department of Transportation, and remains a successful trojan till this day with over 573+ known variations that infect Windows computers.
The two primary goals of the Zeus Trojan were:
Malware delivery method:
Impact:
To safely analyse the Zeus Trojan malware, I set up a malware analysis lab by creating two VMs within their own isolated VLAN on my home network for compartmentalised analysis and malware detonation:
To investigate the behaviour of the Zeus Trojan, I conducted both Static and Dynamic analysis of the malware.
My analysis revealed to me the vast capabilities of the Zeus Trojan including:
It also establishes a backdoor terminal session, employs anti-analysis techniques like VM detection and evasion, and attempts outbound connections (to www.google.com for some reason?? Might be a misconfiguration on my C2 server. To be investigated).
Additionally, it creates malicious binaries such as the Msimg32.dll file, to establish persistence by infiltrating legitimate processes like Google Update, ensuring its execution during updates.
Static analysis involves examining files for signs of malicious content without executing the file or binary. This process often includes disassembling the code to analyse metadata, embedded strings, function names, and other attributes.
To obtain the Zeus Trojan binary, I downloaded the .zip file from theZoo , a github repository of live malware samples, onto my FlareVM for analysis.
The alias name for this Zeus Trojan Binary is "invoice_2318362983713_823931342io.pdf.exe"
Right off the bat from the filename, we can see the malware binary is double formatted with ".pdf.exe". It appears to be impersonating a company invoice pdf when it is really an executable.
Before diassemblying the Zeus Trojan malware, I uploaded the binary to VirusTotal to fingerprint it. This allows me to see if VirusTotal's security engines have seen this malware/file before, and whether it is classified as malicious.
Results:
Below, we can see VirusTotal as seen this "invoice_2318362983713_823931342io.pdf.exe" executable before and flagged it as malicious
VirusTotal also tells us the companies who have flagged this malware (in white) and the other names the malware has gone under (in red).
Under the details tab, we can see the hash of the malware. This is useful as we can share malware samples to other analysts and confirm we are analysing the same sample.
After confirming the binary is malicious with VirusTotal, I used PeStudio to statically analyse the malware and identify artefacts of interest such as file headers, strings, imports, libraries used etc.
Upon inspecting the binary sections of the malware, I noticed that the raw sizes and virtual sizes of each section were roughly the same.
This suggests that the malware is not compressed or packed. Compression or packing is a common technique used by attackers to hinder malware analysis, as it obfuscates the malicious features of the malware by hiding them in a compressed or encrypted format, making it harder to investigate without unpacking.
We would know if the malware is compressed/packed if the virtual sizes were drastically bigger than the raw sizes. In this case, the malware is not compressed/packed.
Inspecting the Strings inside the binary reveals the powerful capabilities of the malware:
It appears to be able to detect whether a key has been pressed (GetAsyncKeyState), get clipboard Data (GetClipboardData), grab environmental variables (GetEnvironmentVariable), take screenshots (GetCapture), write files (WriteFile), see what drives are on the machine (GetLogicalDrive), see how long the machine is on for (GetTickCount), and many more.
Judging by the format of these strings, I suspect they are function names or some sort of API calls.
There were also some suspicious gibberish strings that appear before/after references to functions inside DLLs like KERNEL32 and USER32:
These Gibberish names could be an attempt at obfuscation to hide functions that interact with the referenced DLL in some ways I don't know yet. However, obfuscation of functions is a common technique used by malware authors. In this case, the authors have used randomly, generated sequences of words in place of the function names. Eg. Instead of KERNEL32.CreateIoCompletionPort, it is JabsNaveFateLariManyLeeksecshiesBawlwoo in the malware.
To decode obfuscated strings, one can use the CLI tool called Floss which is used to extract strings from binaries including those that are obfuscated. However in this case, it yieled the same results as PeStudio.
I also searched for any hardcoded urls/domains using cmd + f for any references to .com, .net, .org etc, which yielded one result:
To see if this domain has been flagged as malicious, I searched the domain on VirusTotal:
Not malicious according to VirusTotal's search engines.
Temporarily allowing internet connection on my FlareVM, I looked up the domain on a browser to learn it does not exist (as least right now).
Considering it was mentioned in the malware, it could've existed before. Using waybackmachine, which is a website that takes snapshots of websites throughout time, I looked up corect.com at the time of 2013 when the Zeus Trojan Virus was prominent which revealed the following webpage:
It appeared to be a foreign news article. Using google-translate, it was a Romanian news article.
Without access to the HTML of the corect.com webpage, I couldn't determine whether the website was malicious. Some of my theories about this url being referenced are:
It could be anything really. My investigation into corect.com has hit a roadblock here.
To further identify some capabilities of the Zeus Trojan Virus, I used a CLI tool called Capa, which outputs what it thinks the program does by extracting features such as strings, disassembly, and control flow from the binary, and comparing it against a set of rules. Some matches could be strings of interest such as "Connect to URL".
It will also match the malware's behaviour to the MITRE ATT&CK framework as seen below:
In the above output, Capa tells us the Zeus Trojan Malware is capabable of detecting if it's in a VM, and has code in place to behave differently if it's in a VM. If a malware analyst is unfamiliar with an ATT&CK Technique or MBC Behaviour, they can look up their IDs online provided by Capa eg. T1497.001 to learn more about the malware's behaviour.
Using the verbose verbose option of Capa (-vv), it will also tell us where the capabilities are within the binary and where it's sourced from. For example, the below output reveals where the VM Evasion is happening in the binary, and where the anti-VM code is implemented from. In this case, the capability is sourced from a .cpp file from a public github repository called "al-khaser":
Time to diassemble the malware with Cutter!
Going through the diassembly of the Zeus Trojan, the first function/API call I noticed being referenced was GetTickCount - a Windows function that counts how long since the Windows machine started running:
From the graph view, it appears the flow of execution depend on the value of GetTickCount. Why does the malware need to know this? Not too sure. The rest of the malware only begins to execute after their target machine runs after a set amount of time.
From PeStudio, we saw gibberish names were defined right before DLL references in the binary. I wanted to investigate whether there were some sort of links between the gibberish name and the DLL references by analysing the diassembly.
An example of a gibberish string in the binary was "CellrotoCrudUntohighCols", so I searched for it in the diassembly and ended up at the below instruction:
As we can see, the highlighted line references "ighC" whcih is a part of the gibberish name.
Now let's checked if the referenced DLL is in close proximity to that gibberish name.
Using the same technique above, I discovered the kernel instruction/function is close to the gibberish name (just 4 lines under):
Again, I can't confirm much but as I suspected before in PeStudio, these gibberish names are probably attempts at obfuscation for the real function names of the referenced DLLs.
Dynamic analysis involves running the code/executable in real-time to examine what happens when the malware is executed.
Note: You should only do this if you are in a sandbox environment isolated from the internet!
Before I detonated the malware, there were a few things I had to do first:
Testing to see if my fake DNS service works by looking up google.com on the browser:
It does!! Time to detonate the Zeus Trojan Malware :p
When I ran the Zeuz Trojan Binary "invoice_2318362983713_823931342io.pdf.exe", it forced me to install Adobe Flash Player, before deleting itself. The executable probably deleted itself after establishing some sort of persistance. Let's check procmon:
Inside the process tree, we can see the processes spawned by the malware executable. The malware binary (invoice) appears to be still running somewhere, along with a terminal session (cmd.exe) and Adobe flashplayer.
By clicking on the process, we can see the exact command used to spawn the process, as well as the path of where the new files are installed. Below, we can see Conhost.exe is installed in \System32
And InstallFlashPlayer.exe is installed in a Temp folder.
Investigating the Temp folder, I filtered for events/processes that contained the name "invoice" (malware binary) and involves the path of where the flashplayer was installed (C:\Users\Megatron\AppData\Local\Temp) on Procmon:
As seen above, there were a lot of things happening when the malware detonated from the creation of files to files being queried.
The Invoice binary appeared to also create another file (msimg32.dll) and stored it in Temp:
I moved these 2 files of interest (InstallFlashPlayer.exe and msing32.dll) to the desktop in preperation of being uploaded to VirusTotal for scanning, when I noticed the file icons were greyed out. This indicated these 2 files the malware created were in some sort of suspended state:
These files are probably suspended because either the malware could detect it was in a VM (as one of it's behaviours we saw from Capa) and decided not to unleash it's full capabilities for analysts like us to analyse, or it's playing the long game of stealthy persistance to avoid triggering security software or user suspicion - appearing harmless/dormant untill specific conditions are met on the infected machine.
I then uploaded the 2 files onto VirusTotal to see if it has been flagged as malicious:
Msimg32.dll has been flagged but InstallFlashPlayer.exe appears to be a legitimate install executable:
Why does the Zeus Trojan need to install a legitimate Adobe Flash Player? Perhaps to install a vulnerable version of the flash player, or to mask the malicious behaviour/intent of the binary when the user downloads it.
The next step in my investigation is to check if Windows Registry keys have been created or modified when the malware was detonated. This check is important because malware often uses the registry to achieve persistence, store configuration data, or manipulate system settings to evade detection. Filtering for registry keys events in Procmon revealed many events:
Why did the malware set the registry key values for Google Update? Looking back at the process tree on Procmon, I noticed the Google-Update process is the child process of wininit.exe - a process that runs everytime a Windows machine starts up. This led me to suspect everytime google update is ran when a Windows Machine starts up, the malicious Zeus binary will also be executed. Thus, establishing persistance for the malware.
Now that I have looked at host-base indicators when the malware was detonated with Procmon, I then looked for network-based indicators ie. looking for any outbound/inbound HTTP connections.
Using Wireshark to capture network packets and detonating the malware again, I get the following result:
The malware appears to make a HTTP GET request to www.google.com for some reason. Either it tried to make a HTTP request and realised it was in a sandbox so it didn't make a subsequent malicious request, or there was a misconfiguration of my fake DNS server using inetsim that prevented the malware's intended domain being resolved correctly.
For now, this will be the end of my surface-level analysis of the Zeus Trojan. By conducting both static and dynamic analysis of this malware, I was able to learn of the vast and powerful capabilities of the Zeus Trojan such as keylogging, establishing a backdoor terminal session, employing anti-analysis techniques, and achieving persistance by overwriting Windows Registry Keys.
This project has provided me with the confidence, knowledge, and tools, to go out and dissect more malwares in the future!