Blog

Archive for June 2nd, 2020

Polish malspam pushes ZLoader malware, (Thu, Jun 4th)

Introduction

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.


Shown above:  Flow chart for this infection chain.

I was tipped off to this activity by the following posts on Twitter:

The malspam

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:

  • Subject: e-faktura  06.2020

The attachments

The attachments from this malspam have a template that uses Polish and English language encouraging recipients to enable macros.


Shown above:  Screenshot of an attachment from this malspam.

Infection traffic

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.


Shown above:  HTTPS traffic from the infection filtered in Wireshark with a decryption key.


Shown above:  HTTPS request and response for the ZLoader DLL.


Shown above:  HTTPS request and response for ZLoader command and control (C2) traffic.

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.


Shown above:  Infected host running the ZLoader DLL after enabling macros.

Shortly after the DLL is run, it’s moved to a newly-created folder under the infected user’s AppDataRoaming directory, where it’s made persistent through a Windows registry update.  Several other decoy folders are created under the AppDataRoaming folder during the infection.  If the infection runs long enough, some decoy files are placed in these decoy folders.


Shown above:  The Windows registry update to keep ZLoader persistent.


Shown above:  ZLoader and decoy folders under the infected user’s AppDataRoaming directory.

Indicators of Compromise (IoCs)

Date and subject of the emails:

  • Date: Tuesday, 2020-06-02
  • Subject: e-faktura  06.2020

Infection traffic:

  • 84.38.183[.]227 port 443 (HTTPS) – tlanddissipate[.]at – GET /3/rbs.dll
  • 84.38.183[.]227 port 443 (HTTPS) – militanttra[.]at – POST /owg.php

Certificate issuer data for HTTPS traffic on 84.38.183[.]227:

  • id-at-countryName=AU
  • id-at-stateOrProvinceName=Some State
  • id-at-localityName=City
  • id-at-organizationName=Some Country

Associated malware:

SHA256 hash: c0848753a51472209624f631955a9ad9ff39d5b9fc9686c6f0da0530239916e8

  • File size: 138,240 bytes
  • File name: faktura_296.xls
  • File description: Excel spreadsheet with macro for Zloader

SHA256 hash: 8e0238b207985132e60e6f5bc764a6756bce554f9c27b922f1d7e40950a3bbdc

  • File size: 662,528 bytes
  • File location: hxxps://tlanddissipate[.]at/3/rbs.dll
  • File location: C:Users[username]DocumentslLlwqJs.dll
  • File location: C:Users[username]AppDataRoamingIvrawarogyx.dll
  • Run method: rundll32.exe [filename],DllRegisterServer
  • File note: This DLL is different each time it’s retreived from tlanddissipate[.]at

SHA256 hash: 26625bd8081701ab5a248b4f6e726cd5ef07b43c817e5499b766f89980532952
SHA256 hash: 79c2eadd88f3fb91479d982e6b36d5dc7c2d465ff9580a434241f7b353c33289
SHA256 hash: ad658b2da165f31ac7649cf909c5b3330f2e3efde15f0196edc0f90f462965ea
SHA256 hash: f9f231d7b4e601b8703218d6f72fb167472060ce3e42a351743c613e6447c3cc

  • File size: 662,528 bytes
  • File location: hxxps://tlanddissipate[.]at/3/rbs.dll
  • File description: More examples Zloader DLLs retrieved from tlanddissipate[.]at
  • Run method: rundll32.exe [filename],DllRegisterServer

Final words

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 Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Stackstrings, type 2, (Mon, Jun 1st)

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 followed by another h, 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 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 (ExitProc, URLDownloadToFile, urlmon.dll, and 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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →