My analysis of Dridex malware (Part Two)

In the last post, I analyzed a dropper associated with Dridex. This post will focus on analyzing the assa.exe that was dropped.

File name: assa.exe
MD5: 8a996e195337c68d3c4b0a82a285f70b
SHA1: 5bf78a6cd73e20393960a4187833028bee179dd6
SHA256:21f596cae35b2cb7e61c1a93bfa60ebf590d60b9b9f936f820aec96932ca11c7
(I am throwing the hashes in these posts to help my fellow Googlers.)

To analyze assa.exe, I used a handful of tried and true tools:
Sysinternals tools (procmon, sigcheck, etc...)
Wireshark
ResEdit
Some batch scripting
VMware Workstation

So here is how I did the behavioral analysis of the assa.exe.

  1. I opened a Windows 7 32-bit SP1 VM I had laying around that has Sysmon installed on it.
  2. I fired up procmon and wireshark.
  3. Took a snapshot in VMware so I could revert back to clean state as needed.
  4. Copied the assa.exe to C:\Users\User\Desktop and ran it.
  5. Waited about...3 mins.
  6. Saved the Procmon output, Wireshark pcap, sysmon log, and a memory dump to a share.
  7. Reverted to snapshot.

First thing I did was read the Process Monitor log. I opened the file up from the network share and setup a filter to only look at assa.exe for now.
Screen Shot 2015-03-23 at 9.00.44 AM
If you are new to ProcMon, the signal to noise ratio can make it difficult to read but here are the highlights:

Assa.exe then generates the following network traffic:

I will take a crack at decoding that blob of nonsense later but for now, I will keep going.

This looks to be the a third stage payload. For those who aren't familiar with the IRP_MJ_CREATE Operation, Microsoft says

The I/O Manager sends the IRP_MJ_CREATE request when a new file or directory is being created, or when an existing file, device, directory, or volume is being opened.

When hashed, the tmp file gave me nothing to work with. No matter. I'll come back to that later as well.

0928AC45920A48C1E11D207E55797CF0 appears to be a 32 bit tracking signature for the infected computer. The idea is you need a way to uniquely identify 100,000 computers that could have very similar characteristics. Computer Names, User names, IP/MAC addresses by themselves could cause collisions in a botnet. The likelihood that another machine is going have the same ComputerName, Username, InstallDate and MachineGuid starts to become very slim.
A little later in the Procmon output we see this:

Since the tmp file is a dll, that means we can look at it with a wide variety of Tools. I grabbed ResEdit:
reseditor
So this file is dressed up like a copy of c:\Windows\System32\DInput8.dll from copy of Windows XP Pro with the Russian language pack. In case, anyone is curious, there are some subtle differences between the real and the fake. Most importantly, the real one is digitally signed.
sigcheck
DInput8.dll is a valid Windows DLL used for Microsoft DirectInput. DirectInput enables an application to retrieve data from input devices even when the application is in the background. At this point, I do not think this technology has anything to do with this malware's capabilities.

Finally, we see ASSA.EXE gracefully exits after running for only 4.0371401 seconds by my math.

To summarize, ASSA.EXE's purpose in life is 3 fold:

  1. Download the latest third stage from 95.163.121.33:80. The payload I received was a PE file cleverly disguised as a valid but unsigned Windows driver.
  2. Run the third stage payload using Rundll32.exe
  3. Tag the target computer with a unique botnet identifier based on specific characteristics found in the Registry. The tag is a 32-bit hex string stored HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{354BCA22-B264-2DB5-DC3F-114C655B5C92}\ShellFolder\0

I am going to dive deeper into the this tmp/dll file in the next blog post because that is where the really interesting stuff happens.