Information Security News
Today's diary reviews Polish malicious spam (malspam) from Tuesday 2020-06-02 pushing ZLoader malware. Also knowna s Terdot or DELoader, ZLoader is the latest variant from this family of malware that's been active for years.
I was tipped off to this activity by the following posts on Twitter:
Unfortunately, I was not able to get a copy of the emails to show what they look like. However, the subject line I found was:
The attachments from this malspam have a template that uses Polish and English language encouraging recipients to enable macros.
Infection traffic caused by this example was all HTTPS. I used the Any.Run sandbox with MITM for analysis on the spreadsheet to get a decryption key for the HTTPS traffic, and I was able to view the URLs and responses behind the encryption.
Forensics on an infected Windows host
When enabling macros on the malicious Excel spreadsheet, the victim host retrieved the ZLoader DLL as shown in the previous section, saved the DLL to the victim's Documents folder, and ran it using rundll32.exe.
Shortly after the DLL is run, it's moved to a newly-created folder under the infected user's AppData\Roaming directory, where it's made persistent through a Windows registry update. Several other decoy folders are created under the AppData\Roaming folder during the infection. If the infection runs long enough, some decoy files are placed in these decoy folders.
Indicators of Compromise (IoCs)
Date and subject of the emails:
Certificate issuer data for HTTPS traffic on 84.38.183[.]227:
SHA256 hash: 26625bd8081701ab5a248b4f6e726cd5ef07b43c817e5499b766f89980532952
SHA256 hash: 79c2eadd88f3fb91479d982e6b36d5dc7c2d465ff9580a434241f7b353c33289
SHA256 hash: ad658b2da165f31ac7649cf909c5b3330f2e3efde15f0196edc0f90f462965ea
SHA256 hash: f9f231d7b4e601b8703218d6f72fb167472060ce3e42a351743c613e6447c3cc
As always, these types of infections target out-of-date systems. They're not very effective against fully-patched and up-to-date computers running the latest version of Microsoft Windows. The default virus & threat protection settings should stop these samples of ZLoader from infecting a Windows 10 host. Real-time protection and Tamper Protection are designed to prevent such activity.
However, malware authors constantly adjust their malware in an attempt to escape detection. With the low cost of distribution through email, and with poor security practices among potential victims, campaigns pushing ZLoader and other malware will remain cost-effective. I expect we will continue to see ZLoader in the coming weeks and months.
brad [at] malware-traffic-analysis.net
Update 1: Added disassembler output.
When I teach FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques, one of the things we talk about is stackstrings. This is a technique that is used to 'hide' strings from the malware analyst (well, from normal use of the Linux
strings command) by placing a string onto the stack 1 character (byte) at a time, usually by allocating a chuch of memory and then using MOV instructions to place the string into the allocated chunk of memory. I'll call this Type 1 Stackstrings, since this is the standard stackstring most folks think of when discussing them. We also mention a couple of tools that can be used to find these. However, in my examination of shellcode, I've discovered what I'm calling Type 2 Stackstrings that these tools don't usually find, though when looking at the ASCII strings they are sort of visible. I'm sure other malware analysts have seen this, but I've never seen it explicitly documented, so I figured I'd take a little time and explain what I'm seeing (and ask if anyone has tools that pull these kind of strings, I've just opened an issue/feature request for FLOSS on Github to add this). These type 2 stackstrings are pushed onto the stack 4 bytes at a time using the actual PUSH instruction rather than MOVs. I don't usually see this type of stackstring in ordinary malware, I most often see it in shellcode, though I understand that it also gets used by Metasploit. It turns out that in x86 assembly one of the opcodes for the PUSH instruction is opcode 0x68 which when converted to ASCII is the lowercase
h character, so, you'll see
h<4 ASCII chars> followed by another
h<4 ASCII chars>, etc. to push the string onto the stack 4 bytes at a time. That is probably a bit more efficient than the allocate space then move 1 character at a time.
As I said above, if you just look at ASCII strings you can sort of see these stackstrings as noted in the 2 samples below
You can see it in the raw data
But, if I throw this is a disassembler, those strings still aren't obvious.
You can see the pieces since they get pushed in (sort of) reverse order. In the first example you can see the string
wininet being pushed, in the second there are a bunch of them (
LoadLibraryA). Hopefully, my "feature request" in FLOSS will get implemented soon, but does anyone else have tools that pull these type 2 stackstrings? Any other thoughts? I welcome your comments either here, or via our contact page, or email.
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu