My next class:

Keep an Eye on Remote Access to Mailboxes

Published: 2019-10-30. Last Updated: 2019-10-30 09:13:03 UTC
by Xavier Mertens (Version: 1)
2 comment(s)

BEC or "Business Email Compromize" is a trending thread for a while. The idea is simple: a corporate mailbox (usually from a C-level member) is compromized to send legitimate emails to other employees or partners. That's the very first step of a fraud that could have huge impacts.

This morning, while drinking some coffee and reviewing my logs, I detected a peak of rejected authentications against my mail server. There was a peak of attempts but also, amongst the classic usernames, bots tested some interesting alternatives. If the username is "firstname", I saw attempts to log in with:

firstname
okfirstname
mailfirstname
emailfirstname
firstnamemail
domain_firstname
...

And also the classic generic mailboxes ('noreply', 'info', webmaster', 'admin', etc)

The peak of activity was interesting:

Email remains an easy attack vector and is often very easy to compromise. Access to a corporate mailbox can be disastrous based on what people store in their mailbox (documents, passwords, pictures, etc) and mail servers remain often available in the wild. Keep an eye on remote accesses to mailboxes, especially for sensitive accounts! (Do you remember my diary about considering people as IOC's?[1])

[1] https://isc.sans.edu/forums/diary/May+People+Be+Considered+as+IOC/25166/

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

2 comment(s)
My next class:

Comments

Hi,
Good read and I had dealt with this exact situation recently. Curious to know which tool you are using or have configured to do your audit logs for Exchange remote access?
You can also use this as an early warning system if your log server can let you add a little smarts. For instance, in the syslog daemon I wrote in Nodejs one christmas vacation, I wrote various "post processor" modules to do simple log analysis. For instance, if you see > X failed logins from an IP, followed by any successful logins from that same IP, throw an alert. Yeah, that could have some false positives but not if you make X large enough. Also, if you see any logins from an IP that are clearly bogus (ie, all your usernames are First Initial plus Last Name and you see first.last type login attempts, any successful logins from that same IP are suspicious.

You can also do similar things with email logs. For instance, in kibana I had a dashboard for possible spearphishing attempts. Given the names of some CEOs, VPs, and various spear-phishing targets, I'd search for any email with a from username using various permutations of their names. For instance, for Fred Flintstone I'd search for any from address where the domain was not our domain and the from Username was fflintstone, fred.flintstone, fredf, etc. Again, there'd be the occasional false positive that I'd bang in an exception rule for but it DID yield some interesting results (especially to the targeted CEOs).

In our case, we required VPN with MFA to access email. Period. That made us a LOT less vulnerable to compromised email accounts being used to send phish bypassing any filters we'd setup (or being used to phish our vendors/partners which would've been embarrassing).

Diary Archives