We recently helped a customer with an interesting, tricky Microsoft 365 mailbox hack. Thankfully there were no serious consequences, but there were some lessons to learn
Introduction
An existing customer recently recommended us to a supplier of theirs who recently had a near-miss cyber security incident. They fortunately happened to notice something odd in their inbox - the bank account details on an invoice had changed. Clearly in this instance it paid to be eagle-eyed, but as we know from the stories of BEC, many aren’t so lucky.
We came in to help with locking things down again. What sounded like a textbook account compromise attack was somewhat tricky to diagnose, and was a good example of some important lessons for securing Microsoft 365.
365 Mailbox trickery
The initial problem was the compromise of an important email account. Our work was all done post-compromise, but the lack of audit logs meant we couldn’t see what was going on with the 365 tenant at the time of the initial compromise. We could at least carry out an immediate response - change critical passwords and revoke logins, check the MFA configuration, and start to monitor logins.
After that, it was on to the investigation - could we see what the attacker had been up to? One of the first thing we looked for was a rule to auto-forward emails from the victims account to an address outside of the tenant. This is a very common attacker technique. Forwarding can be enabled from the online account settings:
This attack is common enough that there’s a CIS benchmark to explicitly check inboxes for forwarding rules. We had a PowerShell script that inspected each mailbox for forwarding rules, but it didn’t find anything.
Whilst there were no audit logs for the time of the incident, there were mailbox logs. And when inspecting these logs, a keen eye spotted unusual operations in the relevant mailbox:
What’s happening with the RSS Feeds folder?
Manually looking at the mailbox rules in the Exchange Online admin page, it’s easy to spot that two rules were in place. The first rule moved emails from one of three targets (presumably picked because they emailed about financial transactions) into the RSS Feeds folder, and marked them as read:
Rule 1:
The second rule, which we’ll come back to, tidied up undeliverable mail notifications:
Rule 2:
So what’s going on? Let’s run through an example, with good old Alice and Bob:
- The attacker, Eve, has access to Bob’s inbox, and notices Bob has previously got invoices from Alice.
- Eve adds a mailbox rule to Bob’s account that applies to all emails from alice.com. It marks them as read and moves them to an unused mailbox folder (RSS Feeds). Eve also adds a second rule so that failed delivery messages are automatically marked as read and deleted.
- Eve uses information from Bob’s historical emails to compose a very convincing spoofed email, pretending to be Alice and swaps out the bank account details. Eve also sets the ‘reply to’ address of the spoofed email to be an address very similar to Alice’s email (e.g. [email protected]).
- Eve sends the spoofed email to Bob (routed by an external SMTP server)
- Bob receives the fake email and replies – potentially querying the new bank account details.
- Bob’s reply (to the incorrect [email protected] address) bounces, but is caught by the attacker’s second rule and automatically deleted. Any genuine emails from Alice are caught by the first rule and silently moved to the RSS feeds folder.
- With continued mailbox access, Eve is now in a position to impersonate, intercept and manipulate any emails between Alice and Bob.
It’s interesting that they used the RSS Feeds folder as a staging folder. It’s clearly a good place to store messages, as it’s there in everyone’s mailbox, by default:
Plus who looks in their RSS Feeds folder? The one drawback to this approach, from the attacker’s perspective, is that it presumes continued access to the mailbox. So as soon as they were kicked out, they couldn’t do anything more. From a defensive perspective it had a convenient effect in that the RSS Feeds folder was a perfect record of the emails seen by the attacker, which made it clear to the victim what the attacker had and hadn’t seen.
Since we’d already sorted login and authentication, deleting the two email rules was all that was required to finish the immediate tidy-up.
Next time
Our script to collect inbox rules was only looking for forwarding rules, but thanks to this we updated the script to also grab any inbox rule, and not just forwarding rules. Running it again, and it dumps of the rules:
Lessons for 365 admins
So what are the key takeaways from this incident? Here are some suggestions.
Double check your MFA config
All admins are probably sick of thinking about MFA, but with Microsoft 365 its still easy to make a mistake with the configuration. Sure, there are thousands of articles on advanced approaches, with conditional access policies for those on the more expensive license tiers,but what if you’re on one of the cheapest tiers? There are three different ways MFA may be enabled:
- enabled via the security defaults, which many admins might not have enabled as they want more fine-grained control.
- enabled via Azure AD multi-factor authentication
- enabled via Conditional Access policies
(For reference, there’s a table on this documentation page that summarises MFA for different payment tiers)
One crucial point is that for some of the mechanisms listed above, enabled is not the same as enforced.
Frankly it’s poor that MFA is not enabled and enforced by default, even for accounts with admin roles. Maybe Microsoft should follow Google’s example in enabling it by default for Gmail. If everyone’s personal email accounts are worth protecting, the same surely applies to everyone’s work accounts?
Check up on mailbox rules
We’ve seen mailbox rules in place with many customers. There are some cases where they are benign, for example forwarding mail that comes into a shared inbox to a number of staff. However, in many cases they present a security risk. A prime example, hence the fact they’re explicitly mentioned in various security standards, is automatic forwarding to external domains. We’ve seen it for forwarding to personal email addresses, and it’s a favourite attacker technique.
Thankfully it’s easy to audit email forwarding in particular - you can get a report on forwarding rules from the Exchange Online admin pages, and you can disable external email forwarding by following these instructions.
But as we saw in this case, forwarding isn’t the only kind of dangerous mailbox rules. To investigate all rules for a given mailbox, the PowerShell command Get-InboxRule in the ExchangePowerShell module will extract the specified kinds of rules:
Get-InboxRule -Mailbox $User.UserPrincipalname | Select-Object Name, Description, Enabled, Priority, ForwardTo, ForwardAsAttachmentTo, RedirectTo, DeleteMessage, MoveToFolder, MarkAsRead
Ensure logging is turned on
This one is crucial if you want to be able to investigate historic issues, as turning on logging after an event will not help with the current investigation. There are two key sets of logs for all Microsoft 365 tenants: audit logs and mailbox logs. The former covers many different things (see the list here), the latter is just for ExchangeOnline mailboxes. By default, most audit logs are kept for 90 days
If it’s not currently enabled for a tenant, we strongly recommend setting up advanced audit for all users, and storing them for at least six months. This does mean a subscription to one of the higher licensing tiers, detailed here.
Thankfully mailbox logs are enabled by default, but it can be further configured.
Follow Up
We help our customers will all manner of security incidents and investigations. If you want to improve your security, we also complete security audits and security hardened configuration of Microsoft 365 tenants. Read more on our services page.
Related Posts
