The Future is Cloudy with a Chance of Microsoft Office 365

This blog post is part nineteen of the "Hunting with Splunk: The Basics" series. This year, one of my goals is to really understand how to use the data from Microsoft Cloud in incident response and hunting. I'm not gonna lie, it's been challenging—the documentation is spotty and the backend of Microsoft Cloud logging is moving to a "graph." This post will hopefully give you some idea of the fields and values that are of use that HOPEFULLY stay around for awhile. – Ryan Kovar

Maybe you’ve heard of the gateway cloud? It’s called “Office 365” and it's what gets you hooked on all the other clouds. By 2019, Microsoft expects that 66% of all Microsoft Office customers will be using it.^[1] No pressure, but don’t you want to be like everyone else? :-) Okay, you’ve done it? You’ve moved to the cloud? That’s pretty awesome. Welcome to the 21st century!

Now Splunk it.

What? Don't you know how? Easy—check out the blog posts by Ryan Lait (scroll down on his author page). Done? Great. Now let’s get to the point of this post: What do you do with Microsoft Cloud data once you have it.

TL;DR - Skip to the part in the middle where I point out how to use the data.

Learning Your Data

First off, this isn’t your grandfather’s Microsoft NT 4.0 logs (yeah, it's been 22 years). Microsoft Cloud logs aren’t broken into “Security” and “Application,” no no no… Now they are json formatted and pulled from the cloud via ephemeral PowerShell scripts. Remember, things are different, and they'll continue to be different because Cloud technology moves fast. It doesn’t matter if you are talking about Microsoft, Amazon, Splunk, or Google, they're all pushing the edge of technology. One of the core tenets of Cloud is being “agile” and “dynamic,” which sadly leads to some pretty crappy (or perhaps dodgy) documentation.

However, at least in the case of Microsoft Office 365, there are some gems. Before you get too far into this blog post, I recommend you skim/read an article from 2017 titled “Detailed properties in the Office 365 audit log” from Microsoft. (Learn more about audit logs in this blog post.) This post digs deep into the fields and expected values you will see in an Office 365 log, plucked from the Cloud. It's kind of like the 21st version of TechNet CDs.

Once you’ve peeked at that blog post I mentioned above, take a look at this:

That's how the fields and values from the Microsoft Blog are represented in Splunk. JSONy with a hint of schema-on-the-fly… MMMMmmmMMMMMmmm.

Using Your Data

So you might have noticed that Office 365 is more than just software for email. Not only is it an “Exchange” application, but it's also a SharePoint, Lync, and Yammer and even a “Security and Compliance” application. If you read the Microsoft blog post that I outline above, you might have noticed the field called “Workload.” Workloads are how Microsoft delineates different applications. If you are new to Office 365 in Splunk, first review the Workloads you have in Splunk using the following command:

sourcetype="ms:o365:management"
| stats count by Workload

Notice I used the sourcetype “ms:o365:management”... I’ll be honest, this sourcetype could change. Splunk is constantly upgrading our Office 365 TA. For now, concentrate on the field “Workload” and notice how it describes all of the Workloads from which my Splunk instance has collected events.

In this next example, we want to see what “operations” the Workload or rather the Office 365 application performed. Thankfully, it’s fairly easy to guess what the field is named… Ding ding ding! Operation!

sourcetype="ms:o365:management" Workload=Sharepoint
| stats count by Operation

Looks pretty reasonable right? These are all actions that the Workload SharePoint has performed.

In the search below, we broaden our search to make it a little more useful. Notice that I show the values of src_ip and ClientIP. These are identical because src_ip is aliased for the Office 365 value “ClientIP.” Finally, you will see the UserId field. UserId is the user that performed the action.

sourcetype="ms:o365:management" Workload=Sharepoint
| stats VALUES(src_ip) VALUES(ClientIP) VALUES(Operation) count by UserId

We’ve been using Sharepoint for the above examples, but it looks similar if we use other Workloads like AzureActiveDirectory.

Just One More Thing…

Another log that Microsoft provides with Office 365 is Exchange Message Trace. These are the logs that (theoretically) allow you to track email correspondence that traverses the Office 365 Exchange system. In the search below, I call out the (scant) fields that are useful for hunting in Office 365 message traces: FromIP, SenderAddress, Size, Subject, and RecipientAddress.

sourcetype="ms:o365:reporting:messagetrace"
| stats VALUES(FromIP) VALUES(SenderAddress) VALUES(Size) Values(Subject) by RecipientAddressConclusion

Listen, there are more fields and sourcetypes than I listed here. These are just a sampling of things that I have found useful right from the git-go. (If you're interested in more fields, make sure to check out the Microsoft blog post I mentioned earlier). That post is the only post I've found from Microsoft that gives a “detailed” view of the logs from Office 365. If you're interested in Microsoft Cloud Azure logs, take a look at the next post in this "Hunting with Splunk" series.

As always, Happy Hunting! :-)

^{[1] https://www.zdnet.com/article/microsoft-well-have-two-thirds-of-office-users-in-the-cloud-by-fiscal-2019/}