If you ever wondered if file and registry auditing has value and worth doing, look no further than the latest Dridex malware variants as a perfect example of why you should start doing it.
The latest variants of Dridex are delivered using specialty crafted Word or Excel documents. The malicious documents contained macros and VB Scripts that when opened and content enabled, or un-patched 0-Day (MS15-070), drops and executes the Dridex malware.
There have been many variants of this malware largely delivered with malicious Microsoft Office docs. The malwarians use an interesting approach in that they drop VB Script in a
In one of the latest variants of Dridex, the malwarians have utilized some morphing and anti-virus avoidance by generating a new file name with a different hash and varying file sizes each time the system reboots! More importantly the malware on system startup deletes the only payload file which is a DLL that is obfuscated with possibly version 4 of the Armadillo packer and uses the .TMP file extension. To avoid detection, Dridex malware launches on system startup, injects its malicious code into Explorer.exe, deletes itself from disk and deletes the Run key entry it used to launch itself all before the user logs in! On shutdown Dridex writes itself back to disk, albeit with a differnet name and hash, and updates the Run key to allow restart on the launch of Explorer at the next boot.
When the system is up and running and a user logged on, there are no files on disk or no autorun values in registry to detect the Dridex malware. The only Key or keys that exist are a subkey in HKCU Explorer\CLSID that stores what looks to be configuration data written just before the Run Key is deleted on startup.
So how does someone detect malware of this type? Well your properly configured logs of course! If you follow the 'Windows Logging Cheat Sheet' you would catch the malware launching with several 4688 'New Process Created' events. But how do you detect a condition where malware deletes itself on startup and writes back to disk on shutdown and more importantly how do you clean or remediate it? Furthermore how do you remediate it at scale, say over 100 systems?
Your best friend will be file and registry auditing to catch 4663 'File' and 4657 'Registry' events. Where and What locations do you need to audit? For files, the users AppData directories and for the registry the autorun locations. This way when new file(s) drop or get deleted, file auditing will catch this behavior and allow you to match the process execution 4688 events with the file auditing 4663 event along with any autorun registry changes with 4657 events. If you enable Windows Firewall logging (Packet Filtering) you will get the 5156 events listing the process and IP's that match the 4688 events as Dridex communicates with the Command and Control servers.
Applying file auditing on the \Users\
This particular variant uses a random 4 letter file name with the .tmp as the extension; but is actually a DLL that also includes padding that changes the file size and hash and a packer (possibly Armadillo v4) to obfuscate the malware from detection by anti-virus and avoid obvious string discovery during analysis.
File and registry auditing detects the new file being created and the HKCU Run key being updated on shutdown and deleted on startup. New process execution on startup will catch RunDll32 calling the random named (e.g. A32B.tmp) .TMP file found in the %AppData% Roaming root directory, which normally never contains executable files, or .tmp files for that matter; a key indicator of nefarious activity.
Directories used:ARTIFACTS/IOC's:
Registry Keys used:
- %temp% - used for initial dropped scripts and infector malware
- %LocalAppData% - Used by previous versions of Dridex for dropped files
- %AppData% - Where the main payload <4 char random>.TMP file is written on shutdown
- HKCU\Software\Microsoft\Windows\CurrentVersion\Run
- HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\<GUID>
\ShellFolder Type of REG_BINARY Data (varying length HEX data)
The ShellFolder key is the only artifact that can be discovered while the system is running. Look for a key named "ShellFolder" that is of Type REG_BINARY and has one or more 16 character random Value names and data fields of approximately 80-120 byte length. A new value is created each time the system reboots which can tell you when the system was first infected.
CLEANUP/REMEDIATION
Below are two articles that discuss how to clean Dridex off a system. Those methods discussed would work fine if you are doing one system at a time, but those do not scale for tens or hundreds of systems in multiple office locations.
Workstations versus servers:
Servers often have a way to kill the power of the system by using a management interface from the chassis or virtual management console. This can come in handy for the types of infections that live only in memory with no way to restart until the system shuts down and writes the launch sequence to disk. This method provides servers an option not readily available to workstations. Pulling the power on a server will interrupt the hook of the malware and kill its ability to write to disk since the system does not perform a proper shutdown, rather the power is just cut off. Of course you should shutdown databases and applications before using this method to avoid data corruption. For workstations you can just pull the plug and Dridex is gone, but this is not the best approach for scale if there is another way, and with Dridex and many other malware, there is.
Dridex hooks Explorer.exe which loads itself with the following Run key entry:
- Rundll32.exe C:\Users\
\AppData\Roaming\3309.tmp asd34dfghjklzx
The random length code or key following the .tmp file is required for the malware to persist, most likely the key to unlock the obfuscated packed code.
Once Explorer.exe calls RunDll32.exe and loads the
Knowing Explorer.exe is hooked, which can be verified by doing a memory dump and analyzing the strings, Dridex can be unhooked.
All that is needed is to terminate the Explorer process which is what users see as their desktop environment. Once Explorer is terminated Dridex is killed and the desktop is no longer useable. No fear, all that is needed is the three finger salute... CTRL-ALT-DELETE and logoff or reboot the system. The three-finger-salute also requires a person physically touch the keyboard, but easier than booting into Safe Mode.
For true scalability and remote management and no keyboard required on the target, terminating Explorer.exe can be scripted or remotely executed using the /S option of the following built-in utilities to specify a remote system with proper admin credentials. Use Tasklist.exe to identify the PID Explorer is running on or just use Taskkill.exe /IM Explorer.exe to terminate Explorer and then execute the Shutdown.exe command to reboot the system. Many remote management solutions have a reboot the system option, so all that is needed is to execute the proper Taskkill command line and then reboot. You can also script the deletion of the config settings found in the ShellFolder key listed above, but the key is benign once Dridex is terminated.
There you go, all you need to know on the current stealthy variant of Dridex. Now go do some malware infections and play... In an isolated lab of course.Happy Hunting!
RESOURCES
Virus Research article on Dridex removal using Safe Mode
Lexsi Security article on cleaning Dridex in Safe Mode and an incomplete tool
MalwareBattle article on Christmas Dridex
Blue live article on Dyre and Dridex malware
Stop Malvertising article on Dridex / Cridex / Feodo / Bugat
#InfoSec #MalwareArchaeology #LOG-MD, #Dridex