Azure AD Identity Protection Integrations with Microsoft Security Solutions

Updated 20.12.2022 – To contain the latest info about the enhanced capabilities of bi-directional sync between M365D-IPC & M365D-MDA. Sections that I’ve removed or changed are highlighted in the chapters below either in ~~strikethrough~~ or italic font.

Azure AD Identity Protection (IPC) has significantly improved over the last few years. The first enhancement was improved Identity Protection signal quality and visibility, improved IPC, and reduced false/positive alerts (even though those still exist).

The second one announced in October 2022, integration with M365 Defender (MDA integration was in place earlier) closed the gap between the AAD Identity Protection and the Microsoft security stack and brought IPC together with the M365 Defender solution stack.

In this blog, I will share details on how these integrations are actually working underneath the hood. I will also emphasize what needs to take into account when planning the integration in general and from the SIEM solution point of view.

Background Info – Inter-Connections

Identity security monitoring visualization made by Thomas Naunheim describes security solutions positioning and interconnections. This visualization is part of the ‘Azure AD Attack & Defense Playbook‘ I’ve written in the last two (2) years period with Thomas.

Microsoft 365 Defender Incidents can be fully integrated with Microsoft Sentinel and offers a bi-directional sync. The unified connector will replace the previous single connector for MDE, MDI, MDO, and MDA. In addition, advanced hunting tables can be ingested into Microsoft Sentinel.

Portal Convergence

Microsoft has done a great job in the security portals convergence project for helping SOC organizations work more efficiently. In the past, the challenge has been a number of different security portals where an analyst needed to jump between when doing an incident investigation.

Now, the Azure AD Identity Protection (IPC) alerts are integrated into Microsoft 365 Defender. The IPC alerts are also now correlated with related incidents along with alerts from the other security domains and can be viewed directly in the Microsoft 365 Defender portal for a full attack story.

What happens underneath the hood

Those who have been working with Microsoft security solutions are aware that one of the best synergy advantages comes with using the full stack which leverages the interconnections (sharing signals, events, alerts) between the solutions. Most of the integrations are enabled out of the box but some you need to enable by yourself. In this blog, I’m only focusing on IPC-M365D integration; all other integrations are out of scope.

The picture below describes Microsoft security solutions’ integrations with the IPC integrations highlighted. Pay attention to the following integrations:

M365 – IPC
IPC – Security Graph
MDA – IPC
MDE – IPC

What are IPC Detections?

For background information, it’s important to understand how IPC actually works. The following picture below shows a high-level architecture of the solution (picture source ‘Microsoft IPC presentation’).

Side note: the pictures have example detections and the full list of IPC detections is found on learn.microsoft.com.

The IPC has the following detection mechanisms:

Real-time detections

Real-time detections are based on the detection rules that are evaluated during the authentication pipeline. The initial purpose is to detect possible malicious activity during the authentication process. Latency with real-time detections before showing up in the reports is 5-10 minutes. Examples detections:

Unfamiliar sign-in properties – This risk detection type considers past sign-in history to look for anomalous sign-ins. The system stores information about previous sign-ins, and triggers a risk detection when a sign-in occurs with properties that are unfamiliar to the user.
Anonymous IP address – This risk detection type indicates sign-ins from an anonymous IP address (for example, Tor browser or anonymous VPN). These IP addresses are typically used by actors who want to hide their sign-in information (IP address, location, device, and so on) for potentially malicious intent.

Offline detections

Offline detections are detected after the user has been signed in and is doing possible malicious activity after the initial sign-in. Offline detections may not show up in the reporting for 48 hours but in my experience. it can take several days before the malicious activity is shown on the reports. Example detections:

Atypical travel – This risk detection type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behavior. The algorithm takes into account multiple factors including the time between the two sign-ins and the time it would have taken for the user to travel from the first location to the second. This risk may indicate that a different user is using the same credentials.
Anomalous token – This detection indicates abnormal characteristics in the token such as an unusual token lifetime or a token that is played from an unfamiliar location. This detection covers Session Tokens and Refresh Tokens.
Password spray – A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access. This risk detection is triggered when a password spray attack has been successfully performed. For example, the attacker is successfully authenticated, in the detected instance.

IPC Detection Examples

Let’s start with the detection source, Azure AD Identity Protection. The IPC detects malicious activity based on the detection rules that can be offline or real-time detections.

Example 1 – Anonymous IP address involving one user

In this IPC alert, the risk detection indicates sign-ins from an anonymous IP address (for example, Tor browser or anonymous VPN). These IP addresses are typically used by actors who want to hide their sign-in information (IP address, location, device, and so on) for potentially malicious intent.

IPC pushes all alerts to Microsoft Security Graph which has two (2) versions, v1.0 & beta. The latter provides more granular and useful information as you can see from the pictures below. On the left is legacy and on the right is beta API.

Key differences are the following

URLs for alerts & incidents are found in the beta API
Evidence is found from the beta API

IPC alerts compared between the APIs in VsCode.

The same alert is found from M365 Defender (M365D) and with bi-directional sync also from Sentinel. With bi-directional sync capabilities, the incident and related alerts are closed from all security solutions, including MS Security Graph. What’s super cool – the AADIP detection alert is remediated on the AADIP side!!

~~But, it will remain open in Azure AD Identity Protection where you need to mitigate the risk using IPC API or from the M365D portal.~~

From the MDA UEBA page, you are able to mark a user as compromised. Currently, this works on the MDA portal but is not rolled out to the M365D portal. Left below the MDA portal and on the right M365D portal. From this announcement, it’s clearly seen that this feature is working on some of the tenants already.

Side note: When user identity is marked as compromised the following actions take place

Azure AD will move the user risk to High [Risk state = Confirmed compromised; Risk level = High] and will add a new detection ‘Admin confirmed user compromised’.
- What happens next depends on AAD Conditional Access (or IPC) policies. This activity alone doesn’t block access or push auto-remediation to your high-risk end users

Key Takeaway:

Bi-directional sync works seamlessly between Microsoft Sentinel & Microsoft 365 Defender (+ XDR solutions on the backend) but not with IPC. The detections (alerts) remain open in IPC even though the incident/alert status is updated in Sentinel, M365D & Security Graph.

~~Based on the research, in some cases, alert status was not synced to Security Graph as seen in the pictures above.~~

Bi-directional sync works seamlessly through the whole ecosystem, Microsoft Sentinel & Microsoft 365 Defender (+ XDR solutions on the backend), and with IPC. The detections (alerts) are dismissed/remediated in the IPC and also the incident/alert status is updated in Sentinel, M365D & Security Graph.

Example 2 – Multi-Stage incident involving initial access & credential access involving one user reported by multiple sources

In this multi-stage incident, the best sides of using the whole Microsoft Security stack are seen. M365 Defender makes creates an incident of several alerts and makes correlations on behalf of an analyst. This speeds up the investigation a lot and gives more time for the core work, the investigation because all of the information pieces are seen on the same portal.

In this incident, the user has had several malicious activities and IPC has created several alerts including both, real-time (Anonymous IP address) and offline (Password Spray) detections.

Detections in Azure AD Identity Protection:

Incidents in Sentinel:

The same incidents are found from the M365D & MDA portals with the updated status. This is made possible by the new enhancements published earlier this year.

In the M365D, you can find detailed IPC information and it’s not necessary to jump between the portals anymore. But, there is always a but, if you have a multi-stage incident on your hands, all relevant information might not be seen in the M365D portal. In such a case, you might need to jump to the IPC portal. Luckily, there is a deep link in M365D that leads you to a user detection page (based on an entity found from the alert).

It’s worth mentioning that the alert status is synced to Security Graph but in some cases, I’ve found that the status was not updated on the individual alerts. If you see a similar situation in your environment it’s most probably caused by individual sync errors in the backend. This definitely should work and all alerts status should be updated on the Security Graph.

Key takeaway:

IPC integration with M365 Defender brings a truly unified experience underneath the same portal and together with bi-directional sync between the security solutions is a game changer. Take into account that some of the alert statuses were not updated in my environment on the Security Graph. This might affect the scenario if you are using 3rd party SIEM solution and integrating all alerts & incidents from MS Security Graph. In some rare cases, you might see errors in the sync but the sync should work seamlessly between all security solutions (Sentinel-M365D-IPC) or (Sentinel-M365D-MDA).

When a user does self-remediation based on the IPC/CA policies the following actions take place:

The user risk status on the IPC blade is updated
IPC RiskyUsers API is updated
Updated info is synced to the Azure Log Analytics
On the alerts & incidents side, there isn’t any update, and alerts/incidents will remain open

Additional Information

I’ve found that in some rare cases the IPC detections and risky users were not synced from Azure AD to Azure Log Analytics (this is different from M365D integration). This data is coming through Azure AD diagnostic settings where you can define ‘User Risk Events’ & ‘Risky Users’ data to be exported to the Azure Log Analytics. The same behavior was identified in two (2) tenants.

In the table below, you can find an example timeline when MDA is a detection source for IPC alerts.

Detection Name & Activity	Time Generated	Source
Detection of ‘New Country’ in Defender for Cloud Apps	7:57:02	MDA
A New Country alert was added to an incident	7:57:25	M365 (added to the incident)
New Country detection alert synced to Log Analytics	8:12:46	LA
Incident containing the ‘New Country’ alert updated in Sentinel	8:14:09	Sentinel / LA

Microsoft Sentinel as a SIEM

Most of the organizations that have Microsoft Sentinel as SIEM are also utilizing M365 Defender XDR security solutions (MDA, MDE, MDI & MDO). In such a case, there are several options to configure the IPC data connector and alert flow into Sentinel.

In the recent Sentinel updates by MS, the IPC was added as a source of M365 Defender. This means that you have two options to ingest IPC alerts into Sentinel:

Use native Sentinel Azure AD Identity Protection data connector
Use M365 Defender as a source for the IPC alerts

Depending on your configuration and environment needs the following Microsoft guidance shows the different options for the configuration.

M365 Defender configuration options are seen below. Take into account that the scope is ‘high-impact’ alerts, not high-severity alerts. This means that Microsoft’s AADIP/IPC detection mechanism decides what’s considered a high-impact alert. In case, you are wondering why medium severity alerts are coming through (like I was).

The IPC data connector in Sentinel needs to be enabled even though M365 Defender would be used as a source of the IPC alerts, just don’t enable the incident creation to avoid duplicate incidents in the Sentinel queue.

Reason for this: the IPC data connector is used to get all alert data to the underlying Azure Log Analytics workspace. With this data, Sentinel Fusion engine detection rules are able to detect possible multi-stage attacks in the environment. At the time of writing, there is a total of 36 detection rules and in 23 of them, IPC is mentioned as a data source.

The IPC alerts are actually coming through Azure AD API (or IPC’s own API behind the scenes), it can be seen from the following pictures:

Scenarios detected by the Microsoft Sentinel Fusion engine.

From the pictures below is seen the IPC incidents & alerts inside the Azure Log Analytics workspace (LAWS). In one example environment, the last 30 days period contained 65 incidents and 169 alerts on the LAWS.

On the left – Incidents on Log Analytics workspace
- It’s visible that based on the configuration on the M365 side incidents are modified accordingly
- If a playbook has been run it’s also visible from the data
On the right – Alerts on Log Analytics workspace
- It’s seen that ALL alerts are flowing in

KQL for the incident & alert queries

//SecurityIncidents from the last 30 days related to AAD Identity Protection
//Using let variable here because this can be easily expanded to another solutions as well
let FilteredProduct = dynamic (["Azure Active Directory Identity Protection"]);
SecurityIncident
| where TimeGenerated >ago(30d)
| extend Products = tostring(parse_json(AdditionalData).["alertProductNames"])
| where Products contains "Identity Protection"
| where ProviderName contains "Microsoft 365 Defender" 
| project TimeGenerated, Title, Description, Products, ProviderName, Severity, Status, ModifiedBy


//Get SecurityAlerts from the last 30 days
SecurityAlert
| where TimeGenerated >ago(30d)
| where ProviderName contains "IPC" 
|project TimeGenerated, ProviderName, ProductName, AlertName, AlertType, AlertSeverity

Another change related to the IPC data connector that was announced recently is:‘Account enrichment fields removed from Azure AD Identity Protection connector’. I’m highlighting this because it affects some parts of the incidents created by Sentinel and it hasn’t been communicated widely. The main change is that ‘Azure AD Identity Protection’ data connector doesn’t include anymore the following fields:

CompromisedEntity
ExtendedProperties[“User Account”]
ExtendedProperties[“User Name”]

It means that in custom rules and in some of the Sentinel built-in rules user entity is not included in the incidents. Now, you need to get a user entity from the ‘IdentityInfo’ table instead. One built-in rule I’ve identified is the Sentinel rule: ‘Correlate Unfamiliar sign-in properties and atypical travel alerts’.

In week 50, Microsoft announced new built-in rules and templates for enriching the incoming data with user entity-related data. Detailed information in here.

3rd Party SIEM

Most of the organizations I work with are using Microsoft Sentinel but there is a minority of organizations that uses 3rd party SIEM. In these cases, the integrations need to be planned differently and there are several considerations.

Defender for Cloud Apps (MDA) has integration with Azure AD Identity Protection (IPC) which can be enabled manually. This integration brings some of the IPC alerts to MDA and from there to M365D with bi-directional sync capability. But, this integration is only seen in the legacy portal and my assumption is that it will be deprecated in the near future and fully replaced by M365D-IPC integration.

MDA integration will bring ‘leaked credentials’ & ‘risky sign-ins’ types of alerts from IPC to MDA. From MDA those are flowing to MS Security Graph out of the box but without bi-directional sync capabilities. More information about the legacy method is here.

With 3rd party SIEM scenario, I would use Microsoft Security Graph Beta API to get incidents (including alerts) from the MS cloud to the SIEM. The new API, called also M365 Defender API, provides more granular information than the current v1.0 API. Detailed info about the beta API is found in MS Security Graph API docs.

Beta vs v1.0API differences are highlighted below:

Summary of the Azure AD Identity Protection and M365 Integration

I really like the IPC as a security solution even though it has had a history of a high number of false/positives. The benefit is crystal clear, I’ve seen it prevent identity breaches in multiple environments. It has been lacking integration with other MS security solutions but it has been now tackled with M365D integration.

If Microsoft Sentinel is in use organization has several options for the configuration depending on the needs. The most common approach I’ve seen has been to configure data ingestion through M365D and ingest only high-impact alerts from IPC and let M365D do the correlation & create incidents on behalf of the organization.

I would like to emphasize that even though you would have M365 integration in place keep Sentinel Azure AD Identity Protection data connector at an enabled state. It’s crucial for getting the IPC alerts into underlying Azure Log Analytics. The ingested data is used by the Sentinel Fusion engine for data correlation.

Azure AD Identity Protection is known also to be quite noisy which has led to a situation where some organizations don’t ingest the alerts created by IPC at all into Sentinel. I wouldn’t recommend this approach based on my own experience but every organization has its own needs.

If 3rd party SIEM is in use I would recommend ingesting IPC alerts into the SIEM. Options are MS Security Graph or Event Hub depending on how integration has been established in the first place. Also, configuration differs on the cloud side in this scenario but still, the M365D configuration would be dominant.