Malspam links to password-protected Word docs that push IcedID (Bokbot)

Published: 2018-12-18
Last Updated: 2018-12-18 00:26:00 UTC
by Brad Duncan (Version: 1)
3 comment(s)

Introduction

Malicious spam (malspam) using some form of password protection is nothing new.  I've blogged about it before, and yesterday Didier Stevens posted an example.

I've been tracking a long-running campaign that uses password-protected Word documents to push various types of malware (more info here).  This campaign recently updated its tactics.  Previously, its malspam had been using attached Word documents to distribute (mostly) Nymaim malware.  However, last week I saw a tweet about the same type of password-protected Word document pushing IcedID (a banking Trojan also known as Bokbot).  On Monday 2018-12-17, MyOnlineSecurity.co.uk reported the same campaign continued to push IcedID, but it had switched to links in the emails instead of using attachments.  Otherwise, the method of infection is remarkably similar to previous waves of this malspam.

Today's diary examines an infection from this campaign that I generated on Monday 2018-12-17.


Shown above:  Flow chart for recent infection traffic from this campaign.

The malspam

Unfortunately, I don't have any copies of this malspam.  Below is a screenshot I created from one of the images in the report by MyOnlineSecurity.co.uk.  These emails contain links using Google that direct traffic to a URL designed to return a password-protected Word document.


Shown above:  Screenshot of a malspam example reported by MyOnlineSecurity.co.uk.

That URL was still active when I checked on Monday, so I used it to download a password-protected Word document.  After unlocking the Word document with the password 1234, I enabled macros infect a vulnerable Windows host.  This Word document used the same template I saw in a recent example that pushed Nymaim last week.


Shown above:  Downloading a password-protected Word document from one of the URLs reported by MyOnlineSecurity.co.uk.


Shown above:  After unlocking the password-protected Word document, enable macros to infect a vulnerable Windows host.

Infection traffic

After the initial traffic returned a password-protected Word document, the next HTTP request returned a Windows executable from 209.141.61[.]249.  Post-infection traffic caused by IcedID was similar to previous IcedID infections I've seen during the past few weeks.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  Certificate data from the HTTPS/SSL/TLS traffic caused by IcedID (1 of 2).


Shown above:  Certificate data from the HTTPS/SSL/TLS traffic caused by IcedID (2 of 2).


Shown above:  HTTP websocket traffic caused by IcedID.

Forensics on the infected host

As usually seen in password-protected Word documents from this campaign, the Windows executable was initially saved as C:\Users\[username]\AppData\Local\Temp\qwerty2.exe.  When the executable was run, it dropped a handful of seemingly random files under the AppData/Local/Temp directory.  The IcedID executable was copied to a folder under the C:\ProgramData directory.  IcedID was made persistent through a scheduled task.


Shown above:  Artifacts from this infection created in the user's AppData\Local\Temp directory.


Shown above:  IcedID made persistent through a scheduled task.

Indicators

The following are indicators from an infected Windows host.  Any malicious URLs, IP addresses, and domain names have been "de-fanged" to avoid any issues when viewing today's diary.

Traffic from an infected Windows host:

  • 209.141.42[.]165 port 80 - 13207303642.aircq[.]com - GET /88924438472
  • 139.59.147[.]170 port 80 - 139.59.147[.]170 - GET /important.doc
  • 209.141.61[.]249 port 80 - 209.141.61[.]249 - GET /23.exe
  • 185.223.163[.]26 port 443 - labadegmc[.]com - HTTPS/SSL/TLS traffic caused by IcedID
  • 185.223.163[.]26 port 80 - emirpa[.]host - GET /data2.php?E846C913B2BC88F9 (caused by IcedID)
  • 195.69.187[.]56 port 443 - seirfa[.]pw - HTTPS/SSL/TLS traffic caused by IcedID
  • 185.223.163[.]26 port 443 - emirpa[.]host - HTTPS/SSL/TLS traffic caused by IcedID
  • DNS queries for foxpartsearch[.]com (not answered)

malware from an infected Windows host:

SHA256 hash: 4b95bb2a583713acb3cfee2996975573f892021a0b4c8880e659bbd569662e64

  • File size: 40,960 bytes
  • File location: hxxp://139.59.147[.]170/important.doc
  • File name: important.doc
  • File description: Password-protected Word doc from links in malspam

SHA256 hash: f476342981c639d55ce2f5471c3e9962fd2d5162890e55d2b4e45ddc641f207f

  • File size: 157,816 bytes
  • File location: hxxp://209.141.61[.]249/23.exe
  • File location: C:\Users\[username]\AppData\Local\Temp\qwerty2.exe
  • File description: IcedID retrieved by the word macro

SHA256 hash: 4028187ea85858aa7372eafb6813e33fe7345f8bc96a4d5291a359255982144b

  • File size: 157,816 bytes
  • File location: C:\ProgramData\{E10EAEFD-3D5F-E2EA-0DBD-B1174931C85D}\gbwwwwj.exe
  • File description: IcedID persistent on the infected Windows host

Final words

A pcap of the infection traffic and malware associated with today's diary can be found here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

3 comment(s)

Comments

As usual, these analyses are interesting to note the subtle changes in tactics.

Also, +1 for the Funkadelic references. Make my funk the P-Funk.
Would this work with Squid as Proxy since it doesn't support Websocket Upgrade? :)
[quote=comment#42120]Would this work with Squid as Proxy since it doesn't support Websocket Upgrade? :)[/quote]

That is a good question. I've never used Squid as a proxy, so I couldn't tell you. I wonder if anyone else has tried it.

Diary Archives