Zero-trust security is not a product or service, it is a mindset. We need to understand the importance of this approach and implement relevant controls where ever possible. Especially with the pandemic, the word “Zero-Trust” is echoing in the tech industry and it is completely making sense due to the following reasons.
1. Today IT security getting more and more complex. Security is no longer someone’s job. Everyone has a role to play when it comes to IT security. We have more and more devices connecting to corporate networks and data from remote locations. The attacks also getting more and more sophisticated.
2. “Perimeter defense” security strategy is no longer working. We have data, applications running on on-prem as well as in the cloud. Users are connecting these services from everywhere. We no longer can define boundaries for networks. As the attack surface is been expanding new attack scenarios have also been used by attackers. Once they have an initial breach they do not stop there. Instead, they will laterally move to the cloud or other remote networks. Nobelium attack is one of the great examples of this.
3. Attackers have shifted their interest to identity attacks. Over the years we see the number of identity attacks is rising. It has been the most successful method for attackers as asserts are appearing more and more in unsecured networks.
Out of those concerns, if we consider “identities” specifically, we can see the complexity of enterprise identity is growing and that can create room for attackers to be a success. Enterprises are moving assets to the cloud due to accelerating digital transformation. It means the enterprise identities are starting to appear in the public cloud, SaaS applications, partner systems, BYOD, and mobile devices. When the complexity is growing,
1. Engineers can miss certain security settings, rules, or configurations. In most scenarios, these can only get a notice during a pen-test or vulnerability scan.
2. Threats can be coming from anywhere. It can be from on-premises, BYOD, applications, clouds, and so on. So, protecting all of these areas can be difficult and costly.
3. Security teams can get overwhelmed by the amount of data, logs, and alerts they gathering and it is possible to miss important data.
Microsoft identified these challenges came up with Defender for identity, a cloud-based solution that monitors signals from on-premises Active Directory Domain Controllers and ADFS servers to identify, detect and investigate identity threats and malicious activities.
What is Microsoft Defender for Identity?
Microsoft Advanced Threat Analytics (ATA) is an on-premises platform to help us protect our identity infrastructure from advanced targeted attacks by automatically analyzing, learning, and identifying normal and abnormal behavior (from users, devices, and resources). Microsoft also had a cloud version of it as Azure Advanced Threat Protection (Azure ATP). This cloud service is now renamed as Defender for Identity. Microsoft ATA mainstream support ended on January 12, 2021 so going forward users only can use the cloud-based Defender for identity.
When we consider a typical attack kill chain, we can identify four main areas to protect.
1. Applications
2. Endpoints
3. Identity
4. Data
Microsoft has security solutions to protect all these areas.
1. Applications – Microsoft Defender for Office 365, Microsoft Cloud App Security (MCAS)
2. Endpoints – Microsoft Defender for Endpoints
3. Identity – Microsoft Defender for Identity, MCAS
4. Data – Microsoft Defender for Office 365, MCAS
Microsoft has grouped these four products – Microsoft Defender for Office 365, Microsoft Defender for Endpoints, Microsoft Defender for Identity & MCAS and created a unified pre and post-breach enterprise defense suite called “Microsoft 365 Defender” which can provide integrated protection for all four areas. So, Microsoft Defender for Identity is one pillar of a far greater solution. If you want to achieve unified protection in stages, it is recommended to start with identity protection first and then move to other products in the suite as identity is the key to everything.
Defender for Identity benefits
Defender for identity has the following key capabilities which will help to streamline SecOps operations.
1. Proactive – Detect vulnerabilities proactively and prevent attacks even before it happens.
2. Efficient – Automatic analysis and Automatic responses help SecOps teams to allocate their time to investigate critical issues.
3. Prioritize – By reducing false positives, the defender for identity will help SecOps teams to prioritize their time to deal with real issues.
When it comes to identity protection, Microsoft Defender for identity focuses on four main deliverables.
Prevent
Defender for identity helps SecOps teams to identify hidden vulnerabilities in their environments. These are mostly due to misconfiguration of services/products and lack of system updates. Defender for identity security posture assessment can detect vulnerabilities such as,
• Exposing credentials in clear text
• Legacy protocols in use
• Unsecure Kerberos delegation
• Dormant accounts in sensitive groups
• Weaker cipher usage
• Print spooler service in Domain controllers
• Not managing local administrator accounts centrally (Microsoft LAPS)
• Lateral movement paths
• Unmonitored domain controllers
• Unsecure account attributes
• Unsecure SID history attributes
Defender for Identity not only detects these issues but also advises what should do to fix these issues. Also, the report shows how many times these issues have been reported, their impact level, and their resolution status. This rich information helps SecOps teams to improve their security posture and prevent attacks proactively.
Detect
In the Zero Trust security approach, we need to assume a breach. We can’t close all the doors. But more importantly, if there is a breach, we need to way to “detect” it fast so we can prevent further damage and also use that information to improve the security further. Microsoft Defender for Identity can detect identity attacks faster as its analysis of rich information from a variety of data sources.
• Network traffic analytics – Defender for identity analysis network traffic pass through domain controllers in real-time. It can inspect traffic from a protocol such as NTLM, LDAP, DNS, SMB, RPC.
• Active Directory security events and Active Directory Data – One of the requirements during defender for identity deployment is to enable Advanced auditing for Domain controllers. This allows defender for identity to collect sensitive security events which helps to detect potential attacks. It also profiles active directory data for users, groups, and resources.
• User behavior analytics – Defender for identity analysis user behavior to identify what is anomalous.
• Cloud-based detection – Defender for identity use cloud to enrich data with additional information (such as IP details). It helps to detect attacks in real-time.
• ADFS support – Defender for identity now support running identity sensors in ADFS servers and collecting information to detect attack such as Nobelium.
A typical identity attack has different stages. First of all, an attacker needs to find details about the environment he is attacking. We call this as “Reconnaissance” stage of the attack. Defenders for identity can detect the following type of reconnaissance events.
• LDAP enumeration
• Group membership enumeration
• Users and IP enumeration
• DNS enumeration
• Suspicious resources access activities
• Reconnaissance by targeted entity attributes
After reconnaissance, the next step of an attacker is to gain some sort of access to the system. For that attacker can use many different methods. Defender for identity can detect the following type of credential access events.
• Brute force attacks (ADDS & ADFS)
• Login/failed suspicious activities
• Suspicious DC password change suing NetLogon
• Suspicious Kerberos SPN exposure
• Honeytoken account activities
• Suspicious VPN activities
If an attacker has a successful initial breach, the next step will be to latterly move within the infrastructure and try to gain more privileges. Most of the time, the initial breach is a typical end-user account. To do significant damage, attackers will need higher privileges. So they will keep compromising systems until they have access to keys to the kingdom which is Enterprise/Domain Admin accounts. Defender for identity can detect the following type of events which helps to identify lateral movement attempts.
• Pass-the-ticket attack
• Pass-the-hash attack
• NTLM relay and NTLM tampering
• Overpass-the-hash
• Suspicious certificates
• Suspicious group membership changes
• Suspicious SID history injection
If the attacker, has access to privileged accounts, he can go further and compromise the rest of the systems to have full control over the infrastructure. If it’s a hybrid setup, the attacker can try to extend the attack to the cloud resources. Defender for identity can detect the following type of events which helps to detect attack progress in the above degree.
• Golden ticket attack
• Data exfiltration
• Code execution/service creation on DC & ADFS servers
• SMP manipulation
• Skelton key
• DNS remote code execution attempt
• Golden ticket leveraging
• Suspicious print spooler registration
It is important to know if the attack is progressing on the above-mentioned stage, which means the attacker already has access to most of the system. In such a situation, we need to act fast to minimize the impact.
Investigate
When there is a security event, SecOps teams may get overwhelmed by the number of events, alerts they are receiving. Prioritization of these events mostly depends on the skills of the engineers. Also, if a large number of alerts have been produced, it’s possible for engineers to miss some critical events.
Defender for identity not only alert about security incidents, but it also help to priorities the investigation efforts of SecOps teams. As an example, “User investigation priority score” for a user account will help to shortlist the accounts which required immediate attention. In there, a higher score means higher attention is required. This value is calculated based on alerts involved with the user and abnormal activities detected from the user account.
Some attacks involve a large number of users. In such a situation, we can use impact ranking (Low to High) to easily identify the users who need immediate attention. Each attack can have multiple incidents. Defender for identity marks each incident with a “severity” score (Low to High) which also helps SecOps teams to identify which incidents to focus on first.
Apart from that, Defender for identity also allows creating custom detection rules which help SecOps teams to focus on environment-specific security events.
We also can use Microsoft 365 Defender advanced threat hunting to query data from cross-domains to investigate security events further. For that, we need to use KQL queries.
Respond
So far, we have seen how Defender for identity can increase the efficiency of detection and prioritization of incidents. This also helps to reduce the time it takes from initial detection of the event to final fix.
Not only that, when it comes to incident response, we can use Microsoft 365 Defender to automate the incident response process. For more information about automated remediation, please visit https://docs.microsoft.com/en-us/microsoft-365/security/defender/m365d-autoir?view=o365-worldwide
Microsoft Defender for Identity Architecture
The preceding images explain the components involved in Microsoft Defender for Identity setup. Let’s go ahead and see what is the role of each of these components.
Microsoft Defender for Identity Portal – This portal allows us to configure defender for identity instance. Using this portal we can download MDI sensors, check the status of MDI sensors, configure honeytoken accounts, configure email settings, and so on. We also can view and investigate security incidents of the environment by using Microsoft defender for the identity portal.
MDI sensors – Microsoft defender for identity collects security events, analyze network traffic, and monitor active directory entities via MDI sensors. These sensors need to install in each domain controller and ADFS server in the environment for best results. Defender for identity also has a standalone sensor. Instead of installing the sensor in each Domain controller, we can configure a dedicated server as a sensor. Then we need to configure port mirroring in domain controllers to pass traffic through the stand-alone sensor. However, this standalone sensor can’t collect Event Tracing for Windows (ETW) log entries which use for multiple detections. Microsoft’s recommendation is to install sensors on Domain controllers and ADFS servers for best results.
Microsoft 365 Defender Portal – Defender for identity is a product under Microsoft 365 Defender suite. It uses one portal to collect data from different products and then analyze the data to identify attacks spread through different cross-domains. Using this portal SecOps teams can also do advanced threat hunting. If we need to configure automated remediation or custom detection rules, we need to use this portal to do it. Microsoft defender for identity portal also forward activity data, alerts, and metadata to Microsoft 365 Defender Portal. It is recommended to use Microsoft 365 Defender Portal for investigation as it contains rich data from different sources.
Microsoft cloud app security – Prior to Microsoft 365 defender portal, the same data was forwarded to Microsoft cloud app security and engineers were able to investigate by using the cloud app security portal.
In the next section we are going to look into things we need to consider before the Microsoft defender for identity deployment.
Microsoft Defender for Identity prerequisites
Before we deploy Microsoft Defender for identity, it is important to look into the following prerequisites.
Licenses
Microsoft Defender for Identity required Enterprise Mobility + Security E5 (EMS E5/A5), Microsoft 365 E5 (M365 E5/A5/G5), or standalone license. These licenses can purchase through Microsoft 365 portals or via Cloud Solution Partner (CSP).
Connectivity to the Defender for Identity Cloud Service
It is common best practice to block/limit internet access to domain controllers. Unless you are using standalone sensors, all domain controllers with MDI sensors should be able to communicate with Defender for Identity Cloud Services. More info about the links and proxy configuration is available on https://docs.microsoft.com/en-us/defender-for-identity/configure-proxy
Service Accounts
Microsoft Defender for Identity required a service account to connect to Active Directory. This service account must have read permissions to all objects in the domain.
Microsoft Defender for Identity supports two types of services accounts.
1. Stand-alone Service Account
2. Group Managed Service Account (gMSA)
If the sensors machines are running Windows Server 2012 or above, the recommended type of service account is Group Managed Service Account (gMSA).
If you are using an older operating system than Windows Server 2012, you will have to use a stand-alone service account.
Honey Token Account
During the reconnaissance or lateral movement phase of an attack, the hackers will try to access different user accounts. The honey token account helps MDI to detect such activities quickly. This account should be set up as a standard company account but should never use to log in. If any activity is detected in this honey token account, it will immediately flag by Microsoft defender for identity.
Firewall Ports
There are certain ports that need to be open in firewalls for Internal and External communications of Microsoft Defender for identity.
| Protocol | TCP/UDP | Port | To/From | Direction |
| SSL | TCP | 443 | Defender for identity cloud services | Outbound |
| SSL | TCP | 444 | Sensor service | Both |
| DNS | TCP and UDP | 53 | Sensors to DNS Servers | Outbound |
| Netlogon | TCP/UDP | 445 | Sensors to all devices | Outbound |
| RADIUS | UDP | 1813 | RADIUS to sensors | Inbound |
| NTLM over RPC | TCP | 135 | Sensors to all devices | Outbound |
| NetBIOS | UDP | 137 | Sensors to all devices | Outbound |
| TLS to RDP | TCP | 3389 | Sensors to all devices | Outbound |
For standalone sensors, the requirements of the port are different and more info about that available on https://docs.microsoft.com/en-us/defender-for-identity/prerequisites
Advanced Audit Policies
Defender for identity detects 4726,4728,4729,4730,4732,4733,4753,4756,4757,4758,4763,4776,7045 and 8004 Windows event logs from Domain controllers. Some of these event logs are only appearing if the Advanced Audit Policies are enabled in Domain controllers.
To capture the above events, we need to enable the following advanced audit policies.
1. Account Logon | Audit Credential Validation
2. Account Management | Audit User Account Management
3. Account Management | Audit Distribution Group Management
4. Account Management | Audit Computer Account Management
5. Account Management | Audit Security Group Management
We need to capture Success and Failure events for all above policies.
NTLM Auditing
Windows Event 8004 contains NTLM authentication data. By enabling NTLM Auditing, we can allow Microsoft defender for identity to enrich event data by displaying source user, source device and accessed resource.
NTLM auditing should be enabled on Domain controllers. We can enable this by using GPO settings under Computer configuration | Policies | Windows Settings | Security Settings | Local Policies | Security Options.
To collect relevant data, we need to enable the following policy settings.
1. Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers (Audit All)
2. Network Security: Restrict NTLM: Audit NTLM authentication in this domain (Enable all)
3. Network Security: Restrict NTLM: Audit incoming NTLM Traffic (Enable auditing for all accounts)
Once settings are in place, MDI will display NTLM data in Resource Access over NTLM and Failed log on events.
SAM-R Permissions
Microsoft Defender for Identity can detect lateral movement paths. To do that MDI should be able to query local administrators on any computer. This query uses SAM-R protocol and Microsoft defender for identity service account. By default, the service account can’t do this query and we need to grant relevant permissions by using GPO. This policy setting should apply to all computers except domain controllers. To update the settings, go to Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options and add the service account to list under Network access – Restrict clients allowed to make remote calls to SAM policy.
Sizing Tool
Microsoft Defender for Identity sensor required a minimum of 2 cores and 6GB of RAM. However, this can be changed based on network traffic, server roles, and the server’s current resource usage. Therefore, it is best to run the sensor sizing tool before the installation. This tool will automatically analyze current systems and make recommendations for resource upgrades. To download the tool please go to https://github.com/microsoft/Microsoft-Defender-for-Identity-Sizing-Tool
This completes the prerequisites section for Microsoft Defender for Identity. Please note in here I didn’t mention much about stand-alone sensors and it is because it has limitations and it is also not the recommended method.
This marks the end of part 01 of the MDI blog series. In the next blog, I am going to demonstrate how to configure some of the above prerequisites. If you have any questions feel free to contact me on rebeladm@live.com also follow me on Twitter @rebeladm to get updates about new blog posts.
Very informative.