Zeus Malware Analysis- Remnux

Today we’re looking at dynamic malware analysis of Zeus with Remnux Linux. I wanted to RE a windows file this week, and am just not getting anything good on my RDP honeypot (yet). I thought, what better way to start windows malware analysis than with a old piece of malware? That way if I’m missing anything, plenty of documentation exists to aid me in my analysis adventure. 

I have windows 10 and remnux machine running in my honeypot sandbox, so first thing was to get everything setup. On the windows machine, I set the default gateway and DNS server to the remnux machine, and downloaded the Zeus payload from the malware zoo: https://github.com/ytisf/theZoo/tree/master/malwares/Binaries/ZeusBankingVersion_26Nov2013

On remnux, I forward ip traffic through the host, and setup fakedns to respond to queries by the malware

remnux@remnux:~$ sudo net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Since Zeus reaches out to download files, I set the fakedns server to

remnux@remnux:~$ fakedns

I also fired up wireshark on the remnux machine, and was sniffing on eth0:

On the windows machine, I started process monitor:

Then executed the malware:

After about 30 seconds, we can see a request to fpdownload.macromedia.com:

pyminifakeDNS:: dom.query. 60 IN A
Respuesta: v20.events.data.microsoft.com. ->
Respuesta: self.events.data.microsoft.com. ->
Respuesta: www.bing.com. ->
Respuesta: www.msn.com. ->
Respuesta: nav.smartscreen.microsoft.com. ->
Respuesta: assets.msn.com. ->
Respuesta: img-s-msn-com.akamaized.net. ->
Respuesta: fpdownload.macromedia.com. ->

Then an adobe popup, which attempts to download adobe flash player:

The download is unsuccessful, but since the malware sample is 7 years old, this is to be expected. I installed flash player manually to see if the malware would use an existing version, but that doesn’t seem to be the case.

Then the file deleted itself:

From a users perspective, that seems to be all the malware does. After killing my wireshark and process monitor apps, I exported the files to those compatible with procdot (CSV/PCAP).

After importing the data into procdot, it produces a graph details all of the actions taken:

I ran through the timeline and pulled out interesting actions taken by the malware. Zeus queried and wrote data to a number of registry entries, but I omitted some to cut down on length.

  1. Malware is executed
    1. Thread 1980-n110 of process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) loads file “C:\Users\IEUser\Downloads\Malware\ZeusBankingVersion_26Nov2013\invoice_2318362983713_823931342io.pdf.exe” as module
  2. Zeus queries IP over port 53. This happens a number of times through the process executing
    1. Process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) sends UDP traffic to port 53
  3. Zeus injects into the explorer.exe process
    1. Thread 1980-n110 of process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) injects thread 2072-n119 into process “Explorer.EXE” (PID: 228)
  4. Zeus sets an autostart registry key in Google Update. I assume each time chrome updates, the malware will execute again
    1. Thread 1980-n110 of process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) sets autostart registry key “HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Google Update”
  5. Zeus writes to msimg32.dll in AppData
    1. Thread 1980-n110 of process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) writes data to file “C:\Users\IEUser\AppData\Local\Temp\msimg32.dll”
  6. It attempts to download and write to the file “InstallFlashPlayer.exe.”
    1. Thread 1980-n110 of process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) writes data to file “C:\Users\IEUser\AppData\Local\Temp\InstallFlashPlayer.exe”
  7. It creates the cmd.exe process, which runs conhost.exe
    1. Thread 644-n118 of process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) creates process “cmd.exe” (PID: 5412)
    2. Thread 6900-n354 of process “cmd.exe” (PID: 5412) creates process “Conhost.exe” (PID: 6916)
  8. Conhost.exe is unsuccessful, as the process tree stops at its branch. The malware then kills its own process
    1. Thread 1980-n110 of process “invoice_2318362983713_823931342io.pdf.exe” (PID: 2016) kills its own process
  9. InstallFlashPlayer looks like it successfully downloads data, which it writes to a temp file in AppData
    1. Thread 5044-n346 of process “InstallFlashPlayer.exe” (PID: 6500) creates file “C:\Users\IEUser\AppData\Local\Temp\CEB6.tmp”
  10. Flash player attempts to reach out to the same IP address as the malware over port 55
    1. Process “InstallFlashPlayer.exe” (PID: 6500) sends UDP traffic to port 53
  11. Lastly, the cmd.exe process kill itself, and the malware seems to go dormant.
    1. Thread 6900-n354 of process “cmd.exe” (PID: 5412) kills its own process

While the malware didn’t successfully connect my machine to a CnC server, it was a good intro to windows malware analysis. In a real-world scenario, we would have identified some IOCs to pass off to threat hunters to further investigate across an environment.

In my next article, I’m going to run the same malware through an automated analysis engine and compare the differences. This will give me a good idea if my analysis was accurate or I’m missing something. 

Leave a Reply

Your email address will not be published. Required fields are marked *