M365 Defender for Identity – Everything you Need to Know

One saying has been catching on over the last few years in IT security: “Identity is the new firewall.” This is true in the cloud world, where everyone is working from everywhere, no longer protected by our big firewall in the office. But it’s also true for identity on-premises; even if your staff isn’t in the office, the single source of truth for most businesses’ identity store is Active Directory Domain Services (AD). Yes, these accounts are very often synchronized from on-premises to the cloud using Azure AD Connect (or Azure AD Connect cloud sync), but they are managed in AD.

When an attacker gains their initial foothold in a network, their first objective is to escalate their privileges. They may have compromised an ordinary user’s account using a phishing email or a password spray attack, and now they want administrative credentials, eventually Domain Admin. All of these activities leave traces on your AD Domain Controllers (DCs) or your AD Federation Services (ADFS) servers, and this is where Defender for Identity comes into the picture.

In this article, we’re going to show you how M365 Defender for Identity works, how to deploy it, and the attacks it can detect.

History

Since this product has had several names and been housed in several different portals that you may see mentioned in blog posts and videos, a quick overview of the history of Defender for Identity is necessary.

It all started with a company (Aorato) and a product that Microsoft acquired in 2014, which was turned into Advanced Threat Analytics (ATA), an on-premises security solution for monitoring AD. ATA is now in extended support but is still available as part of Microsoft 365 E3 / EMS E3 licensing.

The cloud-based evolution of ATA was initially called Azure Advanced Threat Protection (AATP) which was a bit confusing as it had nothing to do with Azure (apart from being hosted there). It later changed its name to Defender for Identity to take its place in the overall Defender family.

Initially, AATP had its own web-based portal. Then, it was moved to the Microsoft Defender for Cloud App (formerly known as Microsoft Cloud App Security, MCAS) portal. Very recently (in preview at the time of writing), it’s moved again, this time into the Microsoft 365 Defender portal at security.microsoft.com, alongside Defender for Office 365 and Defender for Endpoint.

You need Microsoft 365 E5 / EMS E5 or standalone Defender for Identity licensing to use it, but if you want to follow along in this article, there’s a 90-day trial available. The addition of ADFS as a monitored source is a result of the Solarwinds attack, where organizations were compromised through their ADFS infrastructure, specifically those that stored root keys on the servers themselves rather than in a Hardware Security Module (HSM).

Architecture

There are three components of Defender for Identity: the portal, the sensor that runs on your DCs, and the cloud service itself, where all the analysis is done. In this article, we’ll use the new portal (https://security.microsoft.com) rather than the current portal (https://portal.atp.azure.com/) for all examples.

The portal is where you create the Defender for Identity instance and set up your sensors. It’s also where you configure the integration with other Defender products, see the data the sensors have collected, and monitor suspicious activities and attacks.

When you first open Settings – Identities, you have to create your instance of Defender for Identity, which will take a little while. Once that’s been initialized in the cloud, other settings can be configured.

Start by downloading the sensor to a DC. The sensor needs to run on every DC in your environment. But if your security team just had a fit reading that sentence, you can install the sensor on a standalone server and then set up network packet capture using port mirroring and Windows event forwarding to gather the necessary data. On the installation page, you’re given an access key that you’ll need to enter during the sensor setup.

The installation itself is pretty much a next, next affair. Select where it’s going to be installed and enter the Access key and you’re good to go.

Notice how the installer detects whether it’s on an ADFS server, a standalone server or on a DC.

Once installed, you need to configure an account in AD that will read the relevant information. In earlier versions, this was simply a user account (and you still need that if you’re running servers on Server 2008 R2 SP1), but an option now is to use a Group Managed Service Account (gMSA). This is a better option as AD takes care of rolling over the password (every 30 days by default), and it can be used on all DCs in your forest. Defender for Identity supports multi-forest environments, including ones that don’t have a trust established.

I followed the steps in this article and used PowerShell to configure a gMSA. You’ll also need to give this account permission to log on as a service in the relevant user rights GPO, which in my case was the one for Domain Controllers. I then went into MDI Settings again and added the newly created account.

Once these steps are done, data will start flowing from on-premises into the cloud service. Note that the sensor will automatically update when there’s a new version. If you want some control over this process, you can delay the update on an individual sensor level for 72 hours. You would then leave one or two sensors to update immediately and monitor them for any issues.

The cloud service uses the relevant Windows event logs entries and captured packets to monitor activities and build profiles of all entities (user and device accounts), also known as User Entity Behavior Analytics (UEBA). This makes it easier to spot when abnormal actions are taken, perhaps by an account that’s been compromised. MDI also calculates lateral movement paths, showing that when the attacker has compromised this account and can access this workstation over here, they can compromise this server, etc. Knowing about these is vital so you can segment your networks accordingly.

Microsoft Defender for Identity Tutorial

Configuration

If you’re using a VPN for client access, you can integrate MDI with RADIUS to collect accounting information, which will help during investigations. Microsoft, F5, Check Point, and Cisco ASA VPNs are supported.

You can tag sensitive accounts (administrators, C suite accounts, etc.) and create Honeytoken accounts, which are traps that your own staff should never use. Create a few accounts with juicy names like SQL Administrator / Server admin etc. You can also add Exchange servers to MDI, which will automatically tag them as sensitive.

If you have some accounts that raise a lot of false positives, you can exclude them globally or just from one or more detection rules (preferred).

Finally, under Notifications, configure email accounts to receive notifications of health issues with Defender for Identity and alerts. You can also configure MDI to send syslog notifications to a third-party system. If you’re using Microsoft Sentinel, integrate the two so that your SOC analysts receive alerts in the UI where they work. The new connector is for the whole of Microsoft 365 Defender (Defender for Endpoint, -Identity, -Office 365, and -Cloud Apps) to feed alerts and log data into Sentinel. It’s also bidirectional, so if you close an incident in Sentinel, it’s closed in M365 Defender as well.

If you’re using Defender for Endpoint, make sure to go back to Settings and configure this integration under Endpoint – Advanced Features. As a side note, this was one time when I had to go back to the old portal to enable that integration; for some reason, this setting isn’t available in the M365 Defender portal. Also, be aware that since Defender for Identity is only looking at AD on-premises, if you have devices that are only Azure AD joined but are not present in your on-premises directory, they won’t be included in the integration.

Detections

The power of Defender for Identity and ATA before it is that it’s laser-focused on a single thing: spotting anomalies in your AD (and ADFS) environment.

MDI helps at every stage of the attack kill chain, the steps that most attacks will go through. It starts with Reconnaissance, where the attacker enumerates User and Group accounts, followed by Compromised credential alerts, where the attacker is using various tactics to further compromise identities. As the attacker moves laterally in your network, they’ll leave other clues. Here you’ll find alerts for pass-the-hash and pass-the-ticket techniques, along with many others. Once an attacker has access to high-privilege accounts, they want to achieve domain dominance and create Golden Tickets or Skeleton keys or set up a workstation as a “pretend DC” for a DCShadow attack to obtain a copy of the whole AD database. The final stage is Exfiltration of sensitive data over SMB or DNS.

If any of these activities are detected, they’ll be surfaced under incidents/alerts, alongside information from Endpoints and Office 365 email/collaboration protections. Apart from its ability to spot bad actors in AD quickly, the other strength of MDI is this integration that gives you a true eXtended Detection and Response (XDR) solution. 

Often, an attack might start with a phishing email (hopefully caught by Defender for Office 365) or an intrusion through a third-party SaaS cloud service (Defender for Cloud Apps), followed by a compromised endpoint (Defender for Endpoint) and then lateral movement/attacks against AD (Defender for Identity). Instead of having to correlate this data across disparate tools, here it’s all in a single console.

And if you need to go digging, all the stored data is available through KQL queries.

Conclusion

If you’re using Active Directory on-premises today and not monitoring it with an advanced tool such as Defender for Identity, you’ve got a huge blind spot in your defenses. Any time an attacker attempts lateral movement and other attacks against AD, they leave clues in the DCs event logs and on the network, but you need the right tool to spot them quickly.

Remember that Defender for Identity can be part of an overall security strategy when combined with Hornet Security’s 365 Total Protection, for example, to avoid putting all your eggs in a single vendor’s basket or if you find Microsoft’s licensing costs too high.

A common criticism of Defender for Identity has been its power to alert for suspicious activity but lack of remediation. This is being fixed soon with the ability to automatically disable compromised accounts, both in AD and in AAD, as well as isolate compromised devices (through Defender for Endpoint).