Blog From Microsoft
Hi, my name is Raymond Roethof, and I am a Microsoft Security enthusiast with over fifteen years of experience within the Microsoft landscape. My focus has been Microsoft Security, and specifically with the last three years out of six as a Red Teamer. In this blog post, I will go through an attacker or Red Teamer's challenges when Microsoft Defender for Identity is in place
Many organizations go through a digital transformation by the increasing use of cloud services. Understanding the current state of the cloud service is essential as maintaining the state is a shared responsibility between the company and its cloud provider.
Many Red Teamers and attackers use the on-premises environment as a stepping stone to the cloud. So, a company must understand the comprehensive set of security controls and capabilities available in Microsoft Azure, Microsoft 365, and on-premises. Active Directory can be a source for lateral movement and an excellent initial attack vector due to the high-value information it holds.
Microsoft Defender for Identity is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization. Defender for Identity also protects Active Directory Federation Services (AD FS) in your environment by detecting advanced threats and providing visibility into authentication events generated by AD FS.
The default Active Directory authentication protocol is Kerberos, an authentication protocol based on tickets, and is known for being the target method of many attacks. Kerberos is an authentication protocol developed by MIT and adopted by Microsoft since Windows 2000. Kerberos can also be complicated and as a result, hard to secure.
This blog post will go through attacking Active Directory as a Red Teamer and having Defender for Identity in place to protect this high-value information. What do I have to consider before I make my next move? Let's find out how Defender for Identity makes my job so difficult.
Attack Kill Chain
As a Red Teamer or an attacker, you want to reach your goal as quickly as possible, preferably without noticing. The purpose and time it takes to perform the attack differs in every scenario. Attackers are mainly financially driven as Red Teamers have a specific pre-defined objective to reach.
Most of the attacks require multiple steps to reach their goal. Red Teamers or attackers use some form of an attack kill chain as a process.
(Figure 1 - an example of an attack kill chain process)
Note: With the digital transformation to the cloud and the complexity of most attacks, a one-size-fits-all kill chain is not feasible anymore, but the Cyber Attack Kill Chain is a good indication of how a Red Teamer or attacker performs an attack. The graphic shown above is more focused on compromising an endpoint, for example.
Reconnaissance of Active Directory
Reconnaissance is a critical and consistent step in any kill chain. Most information found is likely used during an attack at a later stage. Information like server names, IP addresses, operating systems, forest architecture, trusts, service principal names (SPNs), groups and memberships, access control lists, and well-known security misconfigurations is probably part of every reconnaissance phase within Active Directory.
The challenge as a Red Teamer (or an attacker - assume I'm referring to both throughout this blog) starts with Defender for Identity being enabled at the reconnaissance phase.
A Red Teamer needs to have a valid set of credentials, a hash, or any form of authentication to communicate with Active Directory. Attacks like phishing e-mails can contain a malicious payload that runs under the user context. This way, a Red Teamer or attacker can perform an attack as an authenticated user. Without any authentication, a Red Teamer uses an attack like AS-Rep roasting and password sprays. If you are a Red Teamer or an attacker, Defender for Identity detects this kind of attack and alerts in almost real time.
Lateral Movement Active Directory
The ultimate objective for a Red Teamer is data. For most organizations, data is one of the most valuable assets. Getting access to all data at the initial entry is rare for a Red Teamer or attacker, so it is common to see lateral movement during an attack.
Let us say a Red Teamer gets a foothold, either remotely or on the network, within the environment without being noticed as an authenticated user. The next step would be to seek identities with higher privileges or an identity to access high-value assets, like data.
Attacks like Kerberoasting are also common since service accounts mainly have high privileges to services that contain high-value assets. Kerberoasting is also an attack that Defender for Identity detects. Defender for Identity also detects newer attacks like PetitPotam as well since version 2.158.14362.
Extended Detection and Response
With Extended Detection and Response (XDR), Microsoft delivers a new approach to provide intelligent, automated, and integrated security across domains to help defenders connect seemingly disparate alerts and get ahead of attackers. Due to signal sharing between Microsoft Defender for Endpoint and Defender for Identity, an indicator shows if the endpoint contains an alert within Defender for Endpoint. An analyst can isolate the endpoint within seconds, and as a Red Teamer, you will need to find another entry point to continue your journey. The analyst is also probably more alert and now monitoring the environment even closer as a result.
(Figure 2 - an illustration of an attacker navigating a minefield)
Every step we take next as a Red Teamer or an attacker is like walking in a minefield.
From on-premises to the cloud
Although many organizations go through digital transformation by the increasing their use of cloud services, attackers can use the on-premises environment as a stepping stone to the cloud. One of my blog posts describes creating a forged security token to authenticate to Azure AD using a private key from the AD FS server. Unfortunately for me, Defender for Identity now detects this method of attack as well: