Tips · 10 MIN READ · JON HENCINSKI · FEB 14, 2019 · TAGS: Cloud security / Get technical / How to / Managed security / SOC
Remember the old days when all of those Nigerian princes were emailing you to offer giant sums of money? All you’d need to do, of course, was click that suspicious-looking link, share your bank account information and you’d be living large. (Finally, a good reason to stop buying all those Powerball tickets.)
That scam is the old school version of a type of attack called a business email compromise (BEC). While those generous Nigerian princes have long since vanished, BEC has gotten far more sophisticated over the years, turning even the savviest internet users into unwitting victims.
As attackers behind BEC attacks find ever more clever tactics to use, it’s getting trickier for businesses to protect themselves. But there are some telltale signs you can look for that are tip-offs that something’s amiss.
What is business email compromise (BEC)?
First things first, though. You’ve got to know what you’re looking for. Business email compromise (BEC) is a sophisticated, email-based scam targeting organizations and individuals just about everywhere. Many people think that BEC is only associated with wire transfer fraud, but the reality is that BEC is much more than that. It’s really an umbrella term that includes things like W2 scams, romance scams, real estate scams and lottery scams.
You’re probably sitting there thinking, “Do people really fall for these tricks?”
They sure do. And it happens more often than you think.
In fact, between October 2013 and May 2018, there were 78,617 domestic and international BEC incidents, with victims from over 150 countries and all 50 U.S. states.
BEC fraud has become so widespread that it’s now the target of major international law enforcement efforts coordinated domestically and abroad by organizations like the FBI and U.S. Department of Justice. Just this past summer, a BEC takedown effort named Operation WireWire resulted in 74 arrests globally, including 42 in the U.S. They nabbed nearly $2.4 million and recovered approximately $14 million in fraudulent wire transfers.
Now for the good news: There are ways that you can spot BEC attacks and stop them before they compromise unsuspecting employees.
Three common categories of BEC scams
1. CEO Impersonation
During a CEO fraud scam, the hacker will impersonate the CEO or another executive at the org in an attempt to trick any level of employee to divulge private information. These requests can range from sending confidential client information or tax information via email to executing wire transfers that are not authorized. In some cases, these schemes can be spear-phishing attacks where an employee is convinced to download a file or software onto a work computer.
2. Full Account Takeover
One of the biggest goals for a cyberattacker is full takeover. This category of BEC scams can be the most devastating. Interestingly, a report from IDG Communications found that more than 56 percent of orgs reported falling victim to a breach caused by their vendor.
3. False Invoice Scheme
False invoice schemes typically target a member of the financial or accounting department. More experienced cyberattackers will alter a legitimate invoice’s bank account numbers but leave the rest of the document unchanged, making it very challenging to notice the invoice is fake. From there, the possibilities are endless. Some attackers increase the payment amount or create a double payment, among many other common hacking techniques.
How to spot (and alert on) BEC activity
Through the Expel SOC’s investigate work responding to many BEC activities in Office 365 (O365), we’ve observed threat actors reusing certain techniques to gain and maintain access to victims’ mailboxes. Take a look at this example of a recent investigation where a threat actor used BEC to access a victim’s mailbox and then set up mailbox Inbox rules to redirect any emails that contained the words “statement,” “outstanding,” “pastdue,” “payment,” “invoice” or “wire” to a Gmail account.
Here are some common hallmarks of crafty BEC attacks, that our own SOC analysts here at Expel have detected in the last few months by using the Expel Workbench.
We’re going to share some of the techniques that we see attackers using again and again so you can take steps to protect your own org. As a bonus, we’ll even share log samples and example SIEM queries (we’re using Sumo Logic) if you want to query your own tools for related activity. Plus we’re sharing our perspective on how likely you are to get false positives from these rules.
You’ll probably notice that there’s a theme to these often-used attacker techniques: the creation of new mail inbox rules. Why are we focusing so much on inbox rules? Because the attackers running these scams generally create inbox rules to hide evidence from their victims that the victim’s mailbox is being used to perpetuate those clever BEC activities.
The good news is that since attackers use this tactic so often, it creates a great detection opportunity, because there are only so many rules an attacker can create to cover his or her tracks.
As you look for evidence of BEC attempts, you should be alerting on:
1. Inbox rules to automatically forward emails to any of the following folders: RSS subscriptions, junk email or notes
During a recent investigation, we detected a threat actor creating an inbox rule to automatically forward emails containing “WeTransfer” in the email subject or body to the “RSS subscriptions” folder of the victim’s mailbox.
Log example:
"Operation":"New-InboxRule", "RecordType":1, "ResultStatus":"True", "UserType":2, "Version":1, "Workload":"Exchange", " { "Name":"AlwaysDeleteOutlookRulesBlob", "Value":"False" },{ "Name":"Force", "Value":"False" },{ "Name":"MoveToFolder", "Value":"RSS Subscriptions" },{ "Name":"Name", "Value":".." },{ "Name":"SubjectOrBodyContainsWords", "Value":"WeTransfer" },{ "Name":"MarkAsRead", "Value":"True" },{ "Name":"StopProcessingRules", "Value":"True" }],
Sumo Logic query example:
(""New-InboxRule"" OR ""Set-InboxRule"") AND "Name":"MoveToFolder", "Value":"RSS Subscriptions""
Expected false positive rate: Low (In our world, “low” means that you can enter this into an alert management workflow with minimal tuning work required.)
2. Inbox rules to automatically delete messages
Similar to folder redirection, we’ve detected threat actors creating new inbox rules to silently drop any emails that contained words like “virus,” “hacked,” “hack,” “spam” or “request” in the email subject or body. You can start by creating an alert for the creation of inbox rules to automatically delete messages with keywords, but we recommend alerting on any new inbox rule that’s designed to automatically delete messages.
Log example:
"Operation":"New-InboxRule", "Parameters":[{ "Name":"AlwaysDeleteOutlookRulesBlob", "Value":"False" },{ "Name":"Force", "Value":"False" },{ "Name":"SubjectOrBodyContainsWords", "Value":"virus;hacked;hack;spam;request" },{ "Name":"DeleteMessage", "Value":"True" },{ "Name":"MarkAsRead", "Value":"True" },{ "Name":"StopProcessingRules", "Value":"True" }]
Sumo Logic query example:
(""New-InboxRule"" OR ""Set-InboxRule"") AND "Name":"DeleteMessage", "Value":"True""
False positive rate: Low
3. Inbox rules to redirect messages to an external email address
Using this technique, the message isn’t delivered to the original recipients and no notification is sent to the sender or the original recipients. We’ve detected threat actors creating inbox rules to redirect emails that contained words like “statement,” “outstanding,” “past due,” “payment,” “invoice” or “wire” to email accounts outside of the organization’s domain (for example, a Gmail account).
Log example:
"Operation": "New-InboxRule", "Parameters": "[rn {rn "Name": "AlwaysDeleteOutlookRulesBlob",rn "Value": "False"rn },rn {rn "Name": "Force",rn "Value": "False"rn },rn {rn "Name": "RedirectTo",rn "Value": "<redacted>@gmail.com"rn },rn "Name": "SubjectOrBodyContainsWords",rn "Value": "statement;outstanding;past due;payment;invoice;wire"rn },rn {rn "Name": "StopProcessingRules",rn "Value": "True"rn }rn]",
Sumo Logic query example:
(""New-InboxRule"" OR ""Set-InboxRule"") AND "Name":"RedirectTo""
False positive rate: This alert is susceptible to false positives since it’s not uncommon for users to forward work-related emails to a personal webmail account. If you’ve integrated O365 with your SIEM, modify the query or rule set to alert and filter out known false positives.
4. Inbox rules that contain BEC keywords
You’re probably starting to see a theme emerge in these first three examples: using keywords to redirect emails. We’ve detected threat actors by alerting anytime we see any inbox rule created using a value in our BEC keyword list. Here’s a snippet of our own BEC keyword list to get you started:
-
- Virus
- Dropbox
- Password
- Fraud
- W2
- Invoice
- Docusign
- Deposit
- Wire
- Tax
- Postmaster
- Utilpro
- Payroll
Sumo Logic query example:
(""New-InboxRule"" OR ""Set-InboxRule"") AND ("wetransfer" OR "document" OR "invoice" OR "postmaster")
False positive rate: Low
5. New mailbox forwarding to an external address
This technique doesn’t involve inbox rules. Instead, it watches for wiley attackers who are configuring an external email address in the victim’s account settings menu. While the setup is a bit different, the intent is the same: the attacker is trying to hide evidence from the victim that his or her mailbox is being used to perpetuate BEC fraud.
Log example:
"Operation":"Set-Mailbox",{"Name":"ForwardingSmtpAddress","Value":"smtp:<redacted>"},{"Name":"DeliverToMailboxAndForward","Value":"True"}],"application-action":"Set-Mailbox","triggered-by":{"app-username":",<redacted>","privileges":[{"level":"admin"}],"new-values":{"additional-properties":{"DeliverToMailboxAndForward":"True"},"forward-to-address":"smtp:<redacted>"
Sumo Logic query example:
(""New-InboxRule"" OR ""Set-InboxRule"" OR ""Set-Mailbox"") AND "Name":"DeliverToMailboxAndForward""
False positive rate: This alert is also susceptible to false positives since it’s not uncommon for users to forward work-related emails to a personal webmail account. If you’ve integrated O365 with your SIEM, modify the query or rule set to alert and filter out known false positives.
6. New mailbox delegates
This rule looks for threat actors that are gaining access to a victim’s account through mailbox delegate access rights. Take a look at this example of a potential BEC threat we detected for one of our customers just last week that involved suspicious mailbox permissions:
Log example:
{"Name":"AccessRights","Value":"FullAccess"},{"Name":"InheritanceType","Value":"All"}]"application-action":"Add-MailboxPermission","status":{"code":"Success"}
Sumo Logic query example:
("Add-MailboxPermission") AND "Name":"AccessRights"" AND "Value":"FullAccess""
False positive rate: This alert is also susceptible to false positives as it’s not uncommon for organizations to enable access to the mailbox and calendar of high ranking employees to schedule meetings and travel. You’ll need to tune this to your environment a bit.
7. Successful mailbox logins within minutes of denied logins due to conditional access policies
Through O365 and Azure AD, you can implement conditional access policies to deny logins based on conditions like source country, source IP address or a sign-in risk score calculated on the backend by Microsoft. One very important detail: conditional access policies are enforced after the first-factor of authentication. Here’s what it looks like in Expel Workbench:
In the example above, O365 recorded a failed login from a foreign country due to a conditional access policy. Unfortunately, this can be bypassed using a virtual private network (VPN) service provider.
Take a look at this example from a recent investigation where a threat actor circumvented conditional access policies by simply turning on their VPN. At 22:17:40 UTC, O365 logs recorded a login failure due to a conditional access policy set to deny authentications from a list of foreign countries. Minutes later at 22:22:40, O365 logs recorded a successful login to the same account from a popular virtual private network service provider.
If you’re sending O365 logs to your SIEM or have a way to implement time-based detections, fire an alert when O365 records a successful login within minutes of a failed login due to conditional access policies for the same account. Another option is to fire an alert when O365 records a successful login originating from a virtual private network service provider within minutes of a failed login due to conditional access policies for the same account.
If you don’t have an easy way to do this, start by reviewing alerts for failed logins due to any existing conditional access policies to get a better understanding of what’s going on in your environment.
You found a lead. Now what?
If you identify something that doesn’t look quite right, here are some investigative tips to help you chase down a potential lead into BEC activity:
Identify the source of the activity
Whether you’re chasing down a suspicious mailbox Inbox rule or a usual email delegate, identify the source IP address associated with the successful authentication into the account when the activity in question occurred. Next, look up the additional information about the IP address, such as categorical and location information. This will allow you to understand if the IP address in question associated with an internet service provider (ISP) in your organization’s geographic area or if the IP address in question is part of a VPN service provider range or located in another country based on GeoIP records.
Review login activity for the user
Next, review 30 days’ worth of login activity for the user in question. This research will help you determine if the user typically logs in to O365 from the IP address in question. Also, review user-agent activity to understand typical operating system and browser combinations. If you’re chasing something down that doesn’t pass the smell test, do you suddenly see a login from an odd IP address using a version of Google Chrome running on Windows when the user normally logs in from a fixed ISP line using a version of Chrome on macOS? Establish a sense of what “normal” looks like and watch out for deviations.
We follow this same approach when pursuing leads into suspicious O365 activity in Expel Workbench where we can take advantage of automation to speed things up a bit. Take a look at this example where, with the help of some automation, we’re able to quickly review 30 days of login activity based on IP address and user-agent combinations.
Review mailbox activity for the user
This is a really good step if your initial lead into possible BEC activity was something like a suspicious login to an account that originated from a VPN service provider. If you already have O365 mailbox auditing enabled, review mailbox activity for the user and be on the lookout for the threat actor techniques we mentioned above. Don’t be afraid to review 30 days worth of mailbox activity. Does the user account in question typically delegate mailbox permissions or create inbox rules to help manage their email? Context matters.
Review login activity for the IP address
The next step is to review 30 days’ worth of login activity for the IP address in question. Do you see successful authentications into multiple accounts from the IP address? Or do you only see activity into the user account in question? By reviewing login activity from the IP address in question, you’re gaining greater context. This is also a valuable scoping action if the threat actor is accessing multiple accounts from the same IP address.
Scope and pivot!
Finally, through the investigative process you might establish new leads into BEC activity like a new external IP address used to authenticate into victim mailboxes or an inbox rule configured to silently drop any emails containing the word “document.” Make sure to pursue them to properly scope the activity.
Let’s say that through scoping you observed a BEC threat actor authenticate into a victim’s mailbox from a popular VPN service provider. With this knowledge in hand, set out to answer how many other accounts the threat actor accessed from the VPN service provider. Here’s another example: if you know the threat actor is creating inbox rules to silently drop messages, figure out if O365 logs recorded similar activity for any other account. And if you find new leads through that? Pursue them!
How do I get started?
To take advantage of the alerting opportunities based on the different scenarios we described above, here are a couple #protips to get started:
- Enable mailbox auditing in O365. Microsoft is in the process of enabling mailbox auditing by default across all its business users, but it doesn’t hurt to double check that mailbox auditing within your organization is enabled. You’ll gain visibility into mailbox login activity and actions typically performed in BEC attacks. Not sure how to enable mailbox auditing? Just follow these easy instructions.
- Integrate O365 with your SIEM. This step allows your team to centralize alerts coming from O365, integrating them into the same workflow you’re already using. Here are step-by-step instructions on integrating O365 with your SIEM.
- Or we could totally just do all of this for you if you’re looking for an “easy” button.
Have more questions about BEC? You can always drop us a note — we’d love to chat.
