MCAS and AAD Identity Protection threat detection and automatic response

Now it’s time for part 2 around MCAS. (Part 1)

This blog post is about threat detection and automatic response where we start with
Azure AD Identity Protection.

Azure AD Identity Protection monitor and responds on threats against our Azure AD identities. Based on behavior and existing information from Microsoft graph (that analyses 6.5 trillion signals per day) our sign-ins and users get a risk investigations score. The risks are categorizes into three tiers: low, medium, and high. We can define a Sign-in risk policy that either enforce MFA or block the specific sign-in based on the risk.
We can also define a User risk policy that act on the AAD account itself. My recommendation for most organizations is to enforce MFA followed by password reset for internal user accounts classified as High Risk. There is a low false-positive rate, and it indicates that the account has been breached in some way.

There are major benefits with the automatic risk detection that you get from Microsoft. However, there may be other signals and activities where you want to impose the same consequence with enforced MFA followed by a password reset.

For instance, we have Defender for Identity (previously known as Azure ATP) that is cloud based version of the deprecated Advanced Threat Analytics, ATA. Defender for Identity detects threats against our local Active Directory and its accounts in a similar way as AAD Identity Protection. Historically, the solution has “only” monitored and alerted in case of intrusion and other suspected behaviors. But now we can also generate an automatic response based on activities from Defender for Identity.

This is done by Microsoft Cloud App Security (MCAS) that can integrate both Azure AD Identity Protection as well as Defender for Identity. This gives us insight where we can track events by the same user both in the on-premises environment and in the cloud.

There are cases where we have false positive of low-risk alertss in both solutions but if we see multiple alarms for the same user in different environments, it is probably something we should act on!

The strength with MCAS is also that it is integrated by default and monitors activities in Office 365 as well as the Azure platform but can also be extended to monitor other cloud services such as Google, Dropbox, Amazon, etc.

This allows us to follow through MCAS if, for example, we have less suspicious sign-in attempts to activities with data exfiltration from both on-premises file servers and other cloud services with the same account. We can automatically ACT on these activities with MCAS

Let’s take a look at MCAS and the new Policies categorization.

Here we find the threat detection category, which includes, among other things, the standard policies imported from AAD Identity Protection and Defender for Identity.

We also have the option to create our own activity policies based on activities from the different sources and best of all, we can also configure an action.

As you can see in the image above, we have an Action column.

If we start by looking at a policy that triggers potential ransomware activities. In this case, if files with common ransomware file extensions are detected, we have defined an action for this.

Although it is rare for an account to be hijacked during a ransomware incident, there is reason to reset the user’s password. As in this example, we will stop syncing data for this user when this alarm is triggered.

We can, among other actions, impose Confirm user compromised.

The reason I started this blog post with AAD Identity Protection and recommended settings for a User Risk policy is because this is a prerequisite for this action to work.

Based on whether we have configured the User Risk Policy to block the user account or enforce the password reset, we get this result when the MCAS policy triggers.

When this happens, we can see that the user loses all access to Office 365 and for example that OneDrive stops syncing data.

MCAS-AADIDPRansomware In larger environments, there is a longer delay than the example above before the policy is triggered!

We had also triggered an alert (which in itself cannot be read until the current user has the right to reach their email again) but the alert could also be sent to someone’s manager.
The advantage of a custom notification is that we can customize the explanation to why an account is forced to change a password.

The Security Operation team can monitor this event either through the MCAS policy or through AAD Identity Protection.

There has also been a long-awaited Policy where I would recommend some actions.

MCAS calculates an investigation priority score based on all signals of the monitored services for all identities in our environment. The MCAS dashboard includes a top list of accounts with the highest risk score. This is not something that previously existed as a dedicated alert.

We have now a new Policy in preview called Investigation Priority Score Increased that alerts if a user has a hefty increase in risk score.

Here I have some recommended settings to evaluate this. It is common for service accounts and other non-user accounts to be detected so my recommendation is to evaluate this on a defined group of user accounts.

We can then automate an action that both sends an alert and enforce the user for MFA and Password Reset. When this is done it will automatically lower the user’s risk score.