Blog Post

Security, Compliance, and Identity Blog
5 MIN READ

Attacking Active Directory as a Red Teamer or as an Attacker

thalpius's avatar
thalpius
Brass Contributor
Sep 16, 2021

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:

 

(Figure 3 - A screenshot showing the alert status of an AD FS DKM key read with supporting evidence)

 

Conclusion

 

When I'm attacking Active Directory, it is challenging for me to access an environment unnoticed when Defender for Identity is enabled. One misstep as a Red Teamer could lead to an unsuccessful attack. Like I mentioned in the text above, attacking a Microsoft environment that contains Microsoft Defender security products is like walking on thin ice. Not to mention automation, which could stop an attack within seconds. Defender for Identity is just one of many Microsoft security products you will have to tip toe around as a Red Teamer.

 

Even when your organization goes through a digital transformation to the cloud, keep an eye on the on-premises environment. The on-premises environment is a good stepping stone to the cloud, and often, it's harder to detect any subsequent threats targeting your cloud instance since the attack is now coming from inside a trusted network.

 

Updated Sep 23, 2021
Version 2.0
  • Thanks for the post. Some thought about the MDI detection with constrained delegation. Maybe you've got some answers.

     

    The topic is Service for User (S4U) detection. Attackers can use enumeration to identify accounts for which constrained delegation has been enabled. They can then target those accounts and take advantage of features of the S4U constrained delegation extensions to facilitate lateral movement and privilege escalation within a targeted environment.

     

    With access to a constrained delegation account and that account’s plaintext password or NTLM hash, for example, attackers can use tools such as Kekeo to request a Kerberos TGT, execute an S4U TGS request and access the target service.

    While it can limit the attack with a sensitive account, it can still not detect attacks that take advantage of constrained delegation.

     

    The "account is sensitive and cannot be delegated can detect" only a few artifacts\half of the attack. Do you know when MDI can detect the constrained delegation complete attack?

  • Hi Daniel Naim ,

     

    The spscific golden ticket does not cover a full s4u, but let assume that it only covers the rbcd and not kud or kcd (in this attack method, not others!). Hence, the MDE still cannot identify the su4. 

     

    If I'm generally taking the scenario of constrained and unconstrained delegations when the delegation attributes are set on the impersonating service. However, with rbcd, these attributes are placed on the final resource or computer account itself.

     

    In both ways, MDI cannot recognize the movement and actions. Done on a few MDI environments.