Attackers routinely use mail rules to exfiltrate sensitive data and get persistent access to victim accounts.
Attackers routinely use mail rules to exfiltrate sensitive data and get persistent access to victim accounts.
In a new report from Expel, the managed detection and response (MDR) vendor found that of all the incidents detected in their SOC, 56% were account compromise and account takeover. Perhaps most surprising, though, is that in around half of those incidents, Expel’s SOC analysts found attackers had created new inbox rules to delete or hide emails that could give them away. Essentially, it’s a living off the land (LOTL) detection evasion technique hackers use to cover their tracks during a Business Email Compromise (BEC) attack.
At Push, we dub those attacker-created email rules “malicious mail rules,” and they’re not only useful for hiding attacks. They can also be used to exfiltrate sensitive data and as a way to get persistent access to victim accounts.
There are a few different ways that an attacker can compromise an email account and set up malicious mail rules.:
Phishing attack: The attacker tricks their victim into giving them their email account credentials.
Credential stuffing attack: The attacker uses credentials that have already been compromised, possibly from another account that shares the same credentials as their email account.
Brute force attack: The attacker breaks into the victim’s email account by trying common passwords and their known email username.
Consent-phishing attack: The attacker creates a malicious, but legit-looking, SaaS app, or compromises a genuine SaaS application. The victim consents (or has already consented) that application access to their data, including email, using OAuth 2.0 protocol.
Once the attacker has gained email access through either of the attacks above, they’ll create custom mail rules, which allow them to:
Forward and delete emails containing sensitive data from employee inboxes to their own:
Usually attackers will forward emails matching sensitive keywords, like ‘invoice,’ ‘payment,’ or ‘confidential’ to an external email address controlled by the attacker. This is what happened during the SANS data breach in 2020.
Delete important emails from particular senders, as seen in this Reddit thread, so the attacker can masquerade as an executive at the company for social engineering purposes. Attackers will mark emails from impersonated executives as read and then delete them to improve their social engineering attack. That stops the victim from receiving genuine emails from those execs, which may arouse their suspicions and stop them from responding to the fake exec/attacker.
Move laterally to other accounts, by forwarding and deleting password reset emails to an attacker. This allows attackers to compromise and take over other accounts the victim has with other services.
Monitor whether their attack has been detected by forwarding emails that contain any language consistent with the investigation of a potential compromise.
We’ve written more about this here. As well as being stealthy, mail rules also give the attacker persistent access to data in their victim’s mailbox, even if they change their password, turn on MFA, or even completely rebuild their workstation.
How to detect suspicious mail rules
Since this is such a common and often-overlooked or hidden attack vector, it’s one of the first features we build into our product at Push. We knew from our time spent as incident responders that it’s a really reliable way to uncover account compromise.
In Push, whenever a new mail rule gets created, we detect it and automatically message the employee who owns the email account to ask whether they just created it. We do this via Slack or Teams and it’s one of our ChatOps messages with the highest and fastest response rates, because employees can instantly say “yes, it was me - I created that mail rule” or “No, I didn’t create it.” They don’t need to know a thing about security to respond to the prompt.
If they say they don’t recognize it, we alert your security team and they can disable or delete the rule immediately in the alert.
Remember, creating malicious mail rules are a post-compromise activity and rarely the attacker’s sole objective, so you need to determine what else the attacker has gotten up to. They’re a reliable indicator of compromise (IoC) that should trigger an investigation to determine the scope of the incident and the steps necessary to eradicate the attacker from your environment.
Use Push for free - sign up today to start detecting suspicious mail rules that can indicate an ongoing attack.
Shouldn’t I just disable mail rules to prevent these attacks from happening?
Short answer: No! They can be really useful.
Longer answer: Banning external auto-forwarding of email is too heavy-handed and employees who have legitimate business reasons for using the feature.
Legitimate reasons for using mail rules…
Many companies/teams will outsource or automate certain processes by forwarding emails. A few common examples of this:
Some tools and SaaS apps don't allow you to set a billing email. So the user that signs up and pays receives the receipt, but needs to get that over to their accounts payable contact.
Many finance and billing apps and tools provide customers with a random email address (on their domain) to forward receipts to, which employees use for expenses
A bit less clear…
A use case that’s in a bit more of a grey area is when you’re working with contractors. Some security-minded companies will provide a company email address to the contractor to prevent them from having to worry about the security of the individual contractor’s email service. Contractors, however, may not want to be checking their corporate email when they’re working with many other companies and having to check separate company email accounts, Slack messages, and so on, so they’ll set up a forwarding rule so they have visibility of all of their contract work in a single email inbox and only use the official corporate email if they need to send an email to that company’s internal team.
That particular use case is clearly problematic from a security perspective, but you’ll need to find the balance between keeping the company secure and not overly-restricting employees (or contractors) from getting their work done. There’s no clear right answer for that one.
Limit, but don’t restrict completely
In our opinion, you want to limit the risk without blocking employees and becoming, once again, the dreaded “Department of No.”
We’ve provided a lot of practical options for how to limit the risks mail rules present here, including how to manage this risk manually via Google Workspace and Microsoft 365. Of course, we'll also explain how Push can automate these processes for you.