In the Microsoft Incident Response (formerly DART/CRSP) team, we often find ourselves using the rich data available in Office 365 to help us with our investigations. During this process there are a couple of questions we consistently stumble across:
Just like traditional endpoint-based data, log data in cloud services is available based on factors largely outside of the investigator’s control. As an investigator, it is our job to work with what’s available, and sometimes work a little bit of magic to make the unavailable available! To begin, there are some differences worth highlighting in data availability in cloud vs. endpoint:
|
Endpoint |
Cloud |
Data Immutability |
Can be tampered with |
Cannot be tampered with |
Data Availability |
Primarily configuration based |
Primarily license based |
Data Retention |
Different per log source but often based on volume of data |
Based on data location and licenses available |
In addition, there is often more than one place to view a particular set of data, and each location may have different retention periods. This level of complexity is two-sided. On the plus side, it provides investigators with multiple options for data extraction, enrichment, and analysis. A drawback, however, is that it makes the barrier to entry high in terms of being able to extract the highest possible quality and fidelity of data.
In this article, we aim to provide some explanations and tips for investigators to use to be able to easily understand in any situation what data is available, and in which portal.
Figure 1. Flow of data for each of the three main log sources in Office 365
The above image shows the flow of data for the three main log sources in Office 365 through to an end web portal, demonstrating some of the complexity of how data moves through these services. The solid lines represent the ‘default’ configuration for any tenant, while the dotted lines represent those data flows which require additional configuration or additional licensing.
Let's start unpacking this diagram by looking at the different types of source data which are flowing through Office 365.
By default, this data flows to Azure AD, Microsoft 365 Defender, and, for interactive sign-ins only, the Office 365 Unified Audit Log. Additionally, data flows can be configured for the following scenarios:
Identity is the new security perimeter, and its associated data is the key to a successful investigation. By finding and following malicious sign-in activity we can understand which of the productivity services need further investigation. There are four categories of sign-ins that are important for us to consider:
Interactive |
Non-interactive |
Service Principal |
Managed Identities |
|
|
|
|
Sign-ins where a user provides an authentication factor, such as a password, a response through an MFA app, a biometric factor, or some other method. |
Sign-ins performed by a client on behalf of a user. These sign-ins don't require any interaction or authentication factor from the user. |
Sign-ins by apps and service principals that do not involve any user. In these sign-ins, the app or service provides a credential on its own behalf to authenticate or access resources. |
Sign-ins by Azure resources that have secrets managed by Azure. |
Azure Active Directory Administrative activity is stored in the Azure Active Directory Audit Log and by default, flows through to the Azure AD portal (30 days) and to the Office 365 Unified Audit Log (90 days [E3], 1 year [E5]). This log source is critical to understanding the scope of any administrative compromise to a tenant and includes the following information:
Additional data flows follow the same configuration and logic as Azure AD sign-ins.
One of the most critical data sources for any Office 365 investigation, this data is stored in the Unified Audit Log (UAL). The UAL contains all Office 365 data, including interactive sign-ins and Azure AD admin activity. Keep in mind that non-interactive, service principal and managed identity sign-ins do not appear in the UAL. Some key information about this treasure trove of information is:
This section describes the locations and web portals that this data flows to.
Located at https://aad.portal.azure.com and contains sign-ins, risk events and Azure AD admin activity. Data is displayed in a custom interface and can be filtered and exported as needed. The default time zone for viewing data is local time, but all exported data is shown in UTC time.
Located at https://security.microsoft.com, this portal surfaces two primary interfaces for viewing log data, Advanced Hunting, and access to the Unified Audit Log via the Audit Search.
Located at https://portal.cloudappsecurity.com, this portal does not include any Office 365 data unless explicitly configured. When configured, data is stored in the Activity log and multiple alert templates exist to help detect and respond to security events in the tenant (several are enabled out of the box).
With all this log data being generated, moved, and stored in so many different locations, it is easy to become overwhelmed by both the quantity of data and the unique differences in each portal and log source. Through our work investigating dozens of cloud environments every month, Microsoft Incident Response hunters usually follow a particular priority list for accessing data for analysis.
One key consideration when deciding where to hunt is the option to create and run custom queries. To this end, support for KQL (Kusto Query Language) or integration with a SIEM/SOAR solution is incredibly useful when looking to optimize hunting.
Whichever method you use for accessing log data, our hope is that after reading this blog entry, you have a better idea of where data is generated in a tenant, where it flows, and how to access it. We have a veritable treasure trove of data available to us – let’s use that power for good!
Interested in more insights into the Microsoft Incident Response cloud hunting methodology? Check out part 2 of this series, Good UAL Hunting<insert link>.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.