0x3 - ZBot.md

Static Analysis

Background - ZBot/Zeus Trojan

• Above, we have some background information from Proofpoint about the ZBot banking trojan species, originally designed by Evgeniy Bogachev (Евгений Богачёв).

• Apparently, the malware author is on the FBI's Wanted List and was indicted in 2012 by a federal grand jury on some very hefty charges. There is currently a $3 million reward for any information leading to his arrest.

Variants

• There appear to be two major variants of ZBot, according to Proofpoint's write up.

1. The first is the generic version, which steals banking credentials via keylogging, browser data harvesting, script injection, etc.

2. The second version is named GameOver Zeus and includes CryptoLocker ransomware.

Major Capabilities

This was a fairly complex malware specimen for its time. Some of its well-known capabilities include:

• Keylogging
• Password theft (from browsers and password managers)
• Continuous banking data theft
• Integration into a botnet
• Monitoring browser activity
• Injecting malicious scripts into web pages (a feature added to later variants after the original was first seen in the wild)

Hands-on Analysis | Stage 1 - Dropper

Hash Type	File Hash
MD5	E9699457FFC92C1B1C0B26588B2FAB56
SHA1	76B843F5789E19508680FB64FE287FCD242A7286
SHA-256	A59B2CB9F6C706635B4D97EDC574A72AC54FBA47F9A4A1EAE77CF58A96CCF567

• The sample we have here is a PE disguised as a .pdf file, which matches what we might expect to see in a phishing attack, where an unsuspecting victim is inclined to click what they think is a .pdf file, but is actually a malicious executable.

• Looking at the imports, we see some of the usual DLLs - user32.dll and kernel32.dll, but we see an interesting third one - gdi32.dll.

• According to open source data, gdi32.dll (Graphics Device Interface) provides essential functions for graphical operations. It handles tasks related to drawing and managing graphics in applications, including rendering text, drawing shapes, and manipulating bitmaps.

• Interestingly, it contains some functions that can be used for malicious purposes:

Bitblt & GetDlBits - Malware can use these functions to capture the contents of the screen or specific windows. By copying the screen data to a bitmap and then reading the bitmap data, malware can effectively take screenshots of the user's desktop or active applications.

ExtTextOut & GetTextMetrics - By hooking or intercepting these functions, malware can capture text being rendered by applications, potentially stealing sensitive information such as chat messages, emails, or documents.

BitBlt & TextOut - Malware can use these functions to capture images of input fields or entire windows to infer what the user is typing, effectively performing a form of visual keylogging.

CreateCompatibleBitmap & BitBlt - Malware can create fake windows or dialogs that look like legitimate system dialogs, tricking users into providing sensitive information such as passwords or payment details.

• I'll be looking out for some of these API calls during my analysis.

• This sample doesn't appear to be packed, but ExeInfo PE does detect ACProtect v1.41, which is anti-crack software. Some of its capabilities include:

  • Code Obfuscation:
    • Renaming functions, variables, and classes to meaningless names, insert junk code, and modify control flow to confuse disassemblers and decompilers.)
  • Encryption & Packing:
    • Encrypting sections of the executable, decrypting them only at runtime. It might also use packing techniques to compress and obscure the executable's data and code.
  • Anti-Debugging Techniques:
    • Emplying various anti-debugging techniques such as:
      • Checking for the presence of debugging tools.
      • Detecting breakpoints.
      • Using API calls like IsDebuggerPresent.
      • Disrupting debugger behavior through techniques like timing checks and hardware breakpoint detection.
  • Anti-Tampering Measures:
    • Using integrity checks to verify the executable has not been altered. It might use checksums, hashes, or cryptographic signatures to detect tampering and prevent execution if modifications are detected.
  • API Hooking & Redirection:
    • Hooking important Windows API functions to control and monitor their use. This can prevent unauthorized actions like dumping memory, loading unauthorized DLLs, or modifying the program's behavior.
  • Virtual Machine Detection:
    • Checking for indicators of virtual machines (VMs) like specific hardware characteristics, software artifacts, and timing anomalies.
  • Code Injection & Runtime Protection:
    • Injecting code into the executable at runtime to monitor and protect critical functions. This can include real-time integrity checks and behavior monitoring.

• Unsurprisingly, it appears to have been written in C++.

• Visual byte analysis shows normal patterns with no visible indication of packing.

• This is further confirmed using ByteHist.

• Next, let's perform some string extractions and see what we can find.

• The static string count is very small, which makes me quite suspicious. The dynamic analysis phase might reveal some secrets.

• I've never dealt with a anti-crack protected sample before, so this will certainly be interesting.

• Taking a look through the string extraction output, my hypothesis proved correct. This sample appears to employ some heavy obfuscation.

• All we can see are the names of some DLLs, some APIs, and an application manifest.

• Let's move on to emulation with one of my favorite tools, capa.

• Disappointingly, we see limited results, with mentions of capabilities like RC4 encryption, hiding a graphical window, etc.

• Let's try again, but in verbose mode.

• That's a little better, but we'll have to do some hands-on dynamic analysis to get a deep understanding of this sample and its capabilities.

• Before we do that, let's take a look at VirusTotal and any sandboxes.

• 65/71 engines detect malicious characteristics. The remaining 6 must be working for the Russians.

• We do see a mention of DNS Fast Flux with regards to a Snort rule match.

• DNS Fast Flux is a technique used by cybercriminals to obscure the location of their malicious infrastructure, making it difficult to take down. This technique involves rapidly changing the IP addresses associated with a domain, typically within minutes or even seconds.

• Fast Flux DNS has two major variations:

  • Single Fast Flux:

    • DNS A records (which map domain names to IP addresses) change rapidly. Each DNS query for the same domain name returns a different IP address from a large pool of addresses.

  • Double Fast Flux:

    • Not only do the A records change rapidly, but the NS (Name Server) records also change frequently. This means that the authoritative DNS servers for the domain are also constantly changing, adding an additional layer of obfuscation.

• Here's an example of how Fast Flux DNS would work in action:

1. Malicious Domain Setup:

   • A cybercriminal sets up a domain, malicious-example.com, and configures it to use fast flux DNS.

2. DNS Query:

   • A user's computer makes a DNS query for malicious-example.com.

3. DNS Response:

   • The DNS resolver returns an IP address from a pool of addresses. This address points to a compromised machine in the botnet.

4. Frequent IP Change:

   • A few minutes later, another user queries malicious-example.com, and the DNS resolver returns a different IP address from the pool.

5. Redirection to Malicious Server:

   • Each compromised machine in the botnet acts as a proxy, forwarding traffic to the actual command and control server or malicious content server.

Network-Based IOCs

• This particular sample is known to communicate with talonstamed.com. Specifically, VirusTotal reports that it contacts hxxps://talonstamed[.]com/images/1m6r[1].exe

• Contacted IP addresses include various IPs in North America and Europe (Germany).

• It is known to drop 3 files, including what appears to be another PE file in the AppData\Local\Temp\ directory.

• The file dropped in the AppData\Local\Temp\ directory appears to be another ZBot PE. I am unsure if this was a blunder by the submitting researcher or if the malware genuinely duplicates itself in another directory.

• Here's what the MITRE ATT&CK Navigator results look like:

• It looks like there might be some registry modifications and auto-start key locations as well.

Dynamic Analysis

• The time has come to detonate this sample. Let's start with fakedns, inetsim, and wireshark running on the Remnux machine.

• Next, we'll start up Procmon, Process Hacker, and Regshot to get an overview of system, disk, and network activity during the infection period.

• The very first thing we notice is that, after launching, the malware sample proceeded to download and run a PE file. In this case, INetSim served it a generic default GUI binary.

• Going back to INetSim on the Remnux machine, here is the initial DNS callout to the C2 server, which matches what we saw in VirusTotal.

• After running the second stage payload, the sample terminates itself.

• Next, we take a look at the Regshot results, which show some bam key values added (very normal activity). We are not looking at the registry keys themselves, the file paths contained therein tell us that a new file got dropped in AppData\Local\Temp\ named ghyted.exe.

• We'll want to take a look at that. I wonder if it's the file that was downloaded from the C2 server.

Screenshot - Registry Values Added

Screenshot - Files Added

Screenshot - Files Deleted

Screenshot - Folders Added

• Just looking at these results, it looks like the following happened:

  • The sample copied itself to C:\Users\REM\AppData\Local\Temp\ghyte.exe
  • It then wrote another file to the same directory named ghyted.exe
  • It created a new folder at C:\Users\REM\AppData\Local\Microsoft\Windows\INetCache\IE\SRVFBAY5\
  • It downloaded the second-stage payload 1m6r[1].exe from the C2 server and placed it in this newly created folder.

• We'll stop here with the second (and third?) stage payloads because the C2 infrastructure is no longer active. From here on out, we'll continue analyzing the stage 1 (dropper).

• Let's go to Wireshark. Here we can see the initial DNS callout (also seen in our FakeDNS logs) followed by a TLS handshake to initiate the HTTPS connection.

• If we follow this down, it is followed by a transfer of application data in packet # 91 (encrypted with TLS, and therefore unreadable), and an eventual [FIN, ACK] to finally close the connection. This indeed appears to be the download sequence for the second stage payload.

• Next, let's take a closer look at the Procmon output.

• There's not a whole lot of new information here. It mostly matches what we've seen already.

• ProcDOT did identify what looks like a registry ASEP key. I saw this before, but didn't realize it was an AutoStart location. Very interesting.

• As expected, we also see where the second stage of the infection kicks off with the ghyte.exe parent process spawning ghyted.exe.

Summary

• This specimen is a ZBot Trojan dropper. It does not contain all the core functionalities of ZBot, but is intended to be delivered via phishing email as an .exe file disguised as a .pdf using a fake icon, which gets run by the unsuspecting victim.
• Manual analysis of the assembly code will take many years off of your life and is not for the weak. In addition to using anti-crack software, the author also used indirect API calls via indirect function resolution with several complicated loops and very complicated execution flow with a lot of misdirection techniques.
• Once executed, it (possibly) achieves persistence with a registry ASEP key, and then attempts to download the second stage payload from the C2 server at talonstamed[.]com and launch said payload on the victim machine.