Why Microsoft Defender for Identity

Within the family of the Microsoft 365 Defenders, there is one that perhaps has the longest pedigree having started life via an acquisition around a decade ago. It was first released in response to many customers becoming victims to a particular style of attack called Pass-the-Hash. Its original name was Microsoft ATA (Advanced Threat Analytics) and was a founding member of the Enterprise Mobility & Security (EMS) security suite from Microsoft and became an E3 licensed feature. Mainstream support ended in 2021, and its successor (after Azure ATP) became known as Microsoft Defender for Identity (MDI) and is part of the Microsoft 365 Defender dashboard and progressed to becoming an E5 licensed service. Microsoft Defender for Identity (MDI) has always been slightly anomalous in the Defender suite, as it’s the only product that protects on-premises resources, in this case Active Directory, exclusively.

What does it do?

At the heart of the product, a network filter is installed on Windows Domain Controllers (DCs, also known as servers) to carry out network packet inspection on all authentication traffic. That is any device (Windows or otherwise) that attempts to authenticate against a domain controller using any authentication protocol will be inspected. Over time, more features have been added to this service including an ability to collect security events from Windows event logs, RADIUS sources, an ability to read into the Windows Active Directory to enumerate group memberships and resolve entity names.

Having started life focused only on Windows DCs it quickly grew to encompass Windows ADFS (Active Directory Federation Services) and more recently, in August 2023, Active Directory Certificate Services (ADCS).

Once the sensors have been installed, preferably on all Windows DCs, the service will start to model each entity as it produces authentication traffic. The service will build a baseline for each account over a 30-day period (for each DC) and so if Fred logs in every workday morning at 9am, works in accounts in Edinburgh and goes home at 5pm regularly then the baseline will show this. If, suddenly, Fred starts logging in from a different location (based on IP location), perhaps at different times suggesting a different working day and starts trying to access documents outside of his core working group, an alert will be created!

MDI can capture intrusion attempts (successful and otherwise) at multiple points:

• Reconnaissance – models user (or rather, account) behaviour, a user entity behavioural analysis (UEBA) tool
• Credential attacks – monitors brute-force password attacks and group membership changes of key Active Directory groups
• Lateral movement – any evidence of an attacker breaching the network and spanning out to discover a DC, this is the typical Pass-the-Hash attack
• Domain dominance – often discovered after MDI has been deployed, which then discovers attackers resident in the Active Directory service already!

MDI does monitor all authentication traffic and so can be used as a cunning approach to detecting older machines on company networks as they will often use clear-text passwords for authentication and older protocols such as NTLM v1 and v2 as opposed to say Kerberos.

Use Case 1: Active Directory discovery and security posture monitoring

Many organisations have iterated and changed their Active Directory footprint over the years it’s been in place. New domains, forests and trusts could have changed a once-simple Active Directory implementation into a more complex beast. This is compounded with historical knowledge leaving the organisation through staff attrition.

Once the MDI sensor is installed on all DCs, a variety of proactive, identity posture assessment items will begin to populate in Secure Score. These assessments shine a torch on areas that security teams might have been blind to, highlighting concerns such as default values in Active Directory that may be unsecure if left alone, resolving unsecure account attributes like SID history, or showing where there may be dormant accounts in sensitive groups, like Domain or Enterprise Admins.

Use Case 2: Reduce Microsoft Sentinel running costs

MDI is part of Microsoft 365 Defender and by default for Quorum Cyber customers, the security alerts and incidents from this product are piped into Microsoft Sentinel. As these are curated alerts (as opposed to raw data) the ingestion costs are included within the licence. Many organisations will collect thousands of alerts from all their Windows DCs and pipe them all into their security information and event management (SIEM) system of choice. In fact, for many environments DCs represent the second largest source of ingestion cost into Microsoft Sentinel after firewalls!

Therefore, allow MDI to collect and analyse data from the DCs and ingest the intelligent output directly into Microsoft Sentinel at no extra cost! Will it collect all the logs? Well, no it doesn’t, but arguably it does collect the most critical ones that indicate an attack. A nice review of all the alerts it collects from the servers it’s installed on can be found here.

Use Case 3: The art of deception

Honeypots are typically servers, or a set of applications running on a server, pretending to host a website, file share or database. The idea of a honeypot is to lure attackers to a particular service first, to act as an early warning system of an attack in progress. MDI can be used to extend this detection ability by using honeytokens. The token element represents a more granular component to that of a pot, examples being a file, an account (user or service) or an individual database.

User accounts in particular make for a nice base to a deception service. As a side note, Quorum Cyber offers a managed deception service that utilises elements of MDI as well as features within Microsoft Sentinel and from a company called Thinkst. Back to user accounts, the best ones to use are those of recently departed employees. This is because attackers will check creation dates, group membership join dates amongst other attributes to outwit any deception service, so an account with history will always look more plausible. These deception accounts (honeytokens) are labelled with an entity tag within MDI, so alerting is automatic when an attacker attempts any logon method as this user.

So, the next time an employee departs your company don’t delete their account (naturally counter to all good security advice!), remove access rights to anything remotely sensitive and instead tag it within MDI as honeytoken.

An excellent article on the art of deception with MDI with more recommendations and practices can be found here.

A look to the future

As the world increasingly moves to cloud-based resources including identity platforms such as Azure Active Directory – well, now called Microsoft Entra ID – will MDI continue to have a role to play? It will, for the following reasons:

• On-premises (or virtualised versions) Windows DCs will exist in the majority of enterprises for at least the next decade. It is rare to find any company that has managed to migrate fully to the cloud without a virtual DC in sight, although Quorum Cyber has!
• The MDI roadmap suggests the MDI sensor will become part of the Microsoft Defender for Endpoint (MDE) agent which should help with future deployments.
• The MDI roadmap also suggests that Azure AD Identity Protection (now known as Microsoft Entra ID Protection) will be rolled into MDI so the product will protect both cloud and on-premises identity platforms, therefore securing its future.