Basic Logging and Attack Detection in Microsoft Graph

Introduction

Microsoft Graph has simplified access to data and actions across Microsoft's various cloud products. This is a useful single point for both legitimate use cases and for attackers seeking to turn stolen credential material into tangible impact. With Continuous Access Evaluation currently only targeting direct interaction with Exchange, Teams, and SharePoint Online, attackers can use tokens for Microsoft Graph outside of an organisation's network, ignoring Conditional Access Policies for the lifetime of the token.

The introduction of Microsoft Graph Activity Logs begins to level the playing field for defenders, granting them visibility to attacker actions. This blog post aims to give the reader a baseline understanding of how these logs, along with the existing sign-in logs in Entra ID, can give indicators of a basic attack chain involving the Microsoft Graph API. The advice outlined will have to be tuned to your environment, with deviations from the norm likely to be more useful than any simple signatures, but this will provide a base to begin that exercise.

Enabling the Logs

All the log types discussed in this post can be enabled and forwarded to a Log Analytics Workspace, Event Hub, and/or Storage Account through "Diagnostic Settings" on the relevant Entra ID tenant.

Structure of a Log Entry

The full list of fields recorded in a Microsoft Graph Activity log entry are in the documentation. The most relevant fields for attack detection are:

While Microsoft Graph Activity logs show actions taken by authenticated users, they cannot show the actual authentication events. These take place in a different part of the Microsoft Cloud ecosystem and Microsoft Graph simply takes in an uses the tickets. To get the full picture of attacker actions in Microsoft Graph, it is therefore necessary to also ingest SignInLogs and NonInteractiveSignInLogs. The matching Log Analytics Workspace tables take the names "SigninLogs" and "AADNonInteractiveUserSignInLogs".

SignIn Logs have all these fields, with one additional of interest:

Example Log Entries

To demonstrate the utility of these three log types in detecting an attack, we can look at an example path in which an attacker performs device code phishing, requests a new access token as a different client ID, and uses this to read emails. This will not go into significant depth on the attack steps to keep the focus defensive, the relevant research that does show these is linked along the way.

To begin with, we can initiate device code grant for a specific client ID within the "family of client IDs" (https://github.com/secureworks/family-of-client-ids-research/tree/main) , targeting one that matches a reasonable phishing pretext as described in the Family of Client IDs research repository (https://github.com/secureworks/family-of-client-ids-research/tree/main#device-code-phishing). For the example, we can use the tool roadtx (https://github.com/dirkjanm/ROADtools) to initiate this as follows for Microsoft Authenticator App:

If the attacker successfully convinces the target to input the device code to an authenticated session, they will receive access and refresh tokens and generate an interactive sign-in log entry.

Whilst mimicking a client such as the Microsoft Authenticator App may assist in the phishing pretext for device code phishing, the fact that this client never normally uses the device code flow should make the sign-in event stick out. The key features of this log entry would be:

Broadly, this entry covers the authentication that the user performs in the browser as they type in the device code. Another event is created in the AADNonInteractiveUserSignInLogs table for the other participating device in the authentication. When device code phishing is performed this way, a few points of interest appear in the logs:

Once an attacker has a refresh token for a client in the family of client IDs, they may attempt to use this to request a token for another client that has the permissions they want. The act of using a refresh token to request an access token lands in the AADNonInteractiveUserSignInLogs table. Such a request in roadtx, targeting the Microsoft Office client id, may look like:

Under the hood, this is simply performing the refresh token flow detailed in Microsoft documentation, which can be performed manually. However, if performed in this manner using this tool, a few IOCs are left in the logs:

The set of OAuth scopes requested has been trimmed, and can be seen in full below:

roadtx allows specifying scopes to request, but will default to requesting a ".default", which equates in this instance to a large number of scopes. This should be compared with the behaviour of legitimate Microsoft clients in an organisation over a long period of time.

Once an attacker has a token with delegated privileges to Microsoft Graph, they can begin to make requests of the API. From this point, an attacker is no longer bound by Conditional Access Policies -- until their current token expires and they need to re-refresh. An attacker can read a user's emails through Microsoft Graph roughly as follows (omitting additional parameters for filtering and specifying number of messages for simplicity):

This will leave the following in the MicrosoftGraphActivityLogs table:

Whilst this example has followed the chronology of the attack, this may not be the order that a defender receives this information. For example, if strong Conditional Access Policies are in place then an attacker would have to operate from within an organisation's network while acquiring their tokens for Microsoft Graph. If they do not believe the defenders are ingesting or alerting on Microsoft Graph Activity logs, they may then proceed to act on the Microsoft Graph API from an arbitrary IP address, potentially triggering an alert based on this IP address appearing in the final request of the chain. From there, a defender would have to work backwards through the other log sources to identify the initial authentication events.

Mapping Microsoft Graph to MITRE ATT&CK

Now we’ve seen one example of the use of Microsoft Graph logging in combination with sign-in logs, we can look at identifying which Microsoft Graph API calls could be used by attackers. To that end, I have compared Microsoft Graph API reference documentation with the MITRE ATT&CK framework and compiled this into a “layer” file for the MITRE ATT&CK® Navigator (mitre-attack.github.io). This JSON file assigns Graph v1.0 endpoints for each relevant technique. This is intended to act as a starting point for detection engineering, threat hunting, and incident response based on these actions. Microsoft obviously do not include inherently malicious Graph API endpoints, they only become malicious if used for ill. Therefore, any detections based on this logging must be based on the specific behaviour seen in your organisation.