Multi-source telemetry: finding business email compromise

This post is the first of a multi-part blog series on various sources of telemetry.

At LimaCharlie, we’re a firm believer in visibility. The more an analyst can see about their environment, the more impactful decisions they can make. We are huge fans of multi-source telemetry, bringing visibility from almost anywhere in your environment to one place for analysis, detection, and response capabilities. Whether it’s on-prem or cloud, a laptop or a server, or assets spread across multiple cloud providers, the goal is the same: get visibility to make informed decisions.

To help our customers realize as much visibility as possible, we have built Adapters for multiple external data streams. You can see this list and associated documentation here. Many of our customers utilize Adapters to stream from third-party providers, like AWS, O365, Duo, or Google Cloud - to name a few among many. Furthermore, even if there is an output that we don’t have an Adapter for, LimaCharlie users can simply ship JSON data to the platform, and we can make that telemetry available for your team to use.

Receiving O365 Logs

In a recent discussion with a LimaCharlie user, they sought the ability to write directions against O365 logs. In particular, they wanted to know if within the LimaCharlie platform they could detect certain operations like the creation of Outlook mailbox rule creation. We knew exactly what they were looking to identify. Mailbox manipulation and forwarding of emails via inbox rules is a classic example of Business Email Compromise (BEC),  one of the most prolific and profitable attacks over the past decade.

Our good friends over at Recon InfoSec put together a great blog post on BEC and wire transfer fraud. To quote Recon, it’s easy to see why security teams would want to defend against this type of attack:

If anyone in your organization handles financial transactions, invoices, or payroll changes over email, you're at risk of wire transfer fraud.

If your organization utilizes O365 or M365, these are logs you certainly should be collecting and writing detections with. Let’s see how this can be done with LimaCharlie.

Utilizing an O365 Adapter, events can be brought in and viewed via our sensor Timeline. See Figure 1, below.

Furthermore, we can also examine each event individually for more granularity. Zooming in on the New-Mailbox operation, the platform automatically parses the log entry and presents it in an easier-to-consume manner (Figure 2, below).

There is a wealth of information in O365 logs, however the ‘Operation’ is our first term of interest. It gives insight into what is happening “in” the mailbox, and will capture mailbox manipulation commands.

Knowing how the platform receives O365 data and parses a log entry, we can begin to write a detection for events of interest. Navigating over to Microsoft support and guidance pages, we can see that rules created via the Outlook Web App may utilize the New-InboxRule activity (note: there are other operations associated with Inbox rule creation, however this is the one we’ll focus on for this blog post). 

Writing an O365 Detection

Crafting this rule in LimaCharlie is super simple, especially via telemetry brought in via the O365 Adapter. Using LimaCharlie’s D&R documentation, we know we’re building on the following:

• The event of interest is New-InboxRule

• We need to ensure the platform is Office365

• We also want to add some information about this rule; what did we find, what does it mean? For this, we’ll link to the MITRE ATT&CK Matrix, specifically technique T1114. We’re going to add this data in the ‘Response’ part of our detection.

We’ll first build out the detection portion of our alert:

Did that seem really simple? That’s the power of using our Adapters. O365 events become easily addressable within LimaCharlie, and we can write directly against mailbox operation events.

Next, we’ll decide our response actions. What do we want to do when this activity is detected? Not all inbox rules are malicious, so we might not want to assume. Instead, we’ll tag and report, so our security analysts can analyze further.

Notice that within LimaCharlie we can add arbitrary metadata fields, allowing us to customize this rule as much as needed.

A little copy/paste, and lets bring it all together:

And that’s it! This is how easy LimaCharlie’s platform makes it. We could of course rotate amongst multiple O365 operations, swapping out each event for different events, or utilize or parameters to build one “mega-rule”. The goal is for your analysts or security team to have as much flexibility in authoring detections as they need.