Pentester vs. SOC: Active Directory hardening, attack, and defense

In this post, we're pitting our Head of Security, Ben Rollin, against our Defensive Content Lead, Sebastian Hague.

Calling on more than a decade of field experience in offensive security, Ben takes on the role of a crafty threat actor launching a Golden Ticket attack on an Active Directory (AD) network—a complex and dangerous attack that can cause serious damage if left undetected.

But Seb isn't going to let Ben get the upper hand easily. He shares insights on the detection and hardening measures he'd deploy to defend against the tactics and techniques at each phase of the attack.

Enumerating Active Directory usernames with Kerbrute 

Phase: Enumeration.

Tactic: Active Directory (AD) username enumeration is performed as a precursor to further attacks. While this tactic can be performed from an external perspective, for our purposes we will discuss performing it when connected to the internal network. 

The goal of this stage of testing is to create a list of valid AD users that can then be used to mount a password spraying attack against the domain.

Attack method(s): There are multiple ways that one can enumerate valid AD users but we will focus on using the tool Kerbrute to validate users against a large word list from a source such as the statistically-likely-usernames GitHub repository. 

This tool uses Kerberos Pre-Authentication, a much faster and potentially stealthier way to perform password spraying. However, it can still be detected if the organization is set up to look for it. 

Related read: A beginner-friendly (visual) guide to Kerberos authentication and security.

This method does not generate Windows event ID 4625: An account failed to log on or a logon failure which is often monitored for. The tool performs username enumeration by sending TGT requests to a domain controller without Kerberos Pre-Authentication. 

If the Key Distribution Center (KDC) responds with the error PRINCIPAL UNKNOWN, the username is invalid. Whenever the KDC prompts for Kerberos Pre-Authentication, this signals that the username exists, and the tool will mark it as valid. 

This method of username enumeration does not cause logon failures and will not lock out accounts. Catching username enumeration early can prevent an attacker from ever being able to start down the path of a password spraying attack. 

Detection: Detecting Kerbrute activity involves monitoring Windows Security Event Log for Event ID 4768 (A Kerberos authentication ticket was requested) followed by Event ID 4771 (Kerberos pre-authentication failed) for a large number of failed authentication attempts across multiple accounts within a short period.

An additional method of detection for more generic AD enumeration attacks can be keeping an eye out for Windows Security Event Log for Event ID 4776 (The domain controller attempted to validate the credentials for an account). 

An unusually high number of these events could indicate an ongoing enumeration attempt.

Hardening Active Directory against username enumeration:

• Account lockout policies: Implement account lockout policies to lock accounts after a certain number of failed login attempts, thus slowing down or stopping enumeration attempts.

• Limiting LDAP access: Restrict access to LDAP by implementing network segmentation and access controls to reduce exposure.

Password spraying to gain a foothold

Phase: Foothold/lateral movement.

Tactic: Password spraying is a type of attack that involves attempting to gain access to a system or network by trying a small number of commonly used passwords against a large number of usernames. 

The goal of this attack is to find a password that works for at least one of the usernames, allowing the attacker to gain access to the system or network. 

For this post, we will focus on password spraying in an AD environment which does not always give us direct admin access to one or more hosts, but can be the starting point for enumerating the AD domain and planning further attacks that can lead to lateral movement, privilege escalation, and domain compromise. 

Attack method(s): This attack can be performed with Kerbrute as mentioned previously or another tool such as CrackMapExec against the SMB protocol.

Tools such as CrackMapExec that rely on the SMB protocol for password spraying are much “noisier” and easier to detect as they typically generate many instances of event ID 4625: An account failed to log on. 

This is why a savvy attacker may attempt one or very few password sprays, spread out over hours or days, to avoid locking out AD accounts and reduce the risk of detection. 

Attackers often target external endpoints, too, as a means to gain internal network access. These may include but are not limited to:

• Microsoft Office 365.

• Outlook Web Access.

• Exchange Web Access.

• Skype for Business.

• Lync Server.

• Microsoft Remote Desktop Service (RDS) portals.

• Citrix portals configured to use AD authentication. 

• VDI or VPN implementations using AD authentication.

• Custom web applications designed to work with AD. 

Detection: We’re going to break this detection down into three sections—Windows event logging, O365, and threshold-based detection.

Event logs: Inspect Windows Security Event Log for Event IDs 4625 (An account failed to log on), 4771 (Kerberos pre-authentication failed), and 4768 (A Kerberos authentication ticket was requested) for a large number of failed authentication attempts across multiple accounts within a short period.

In Office 365 environments, detecting password spraying attempts involves monitoring the Unified Audit Log in the Security & Compliance Center. 

Look for multiple failed login attempts with error codes such as 50126 (Invalid username or password) or 50053 (Account locked) across different accounts in a short time frame. 

You can also use Azure AD Sign-in logs, which provide detailed information on authentication attempts and can be filtered to identify patterns indicative of password spraying.

Threshold-based alerts: Set up alerts for a specified number of failed logins within a given time frame to help identify potential password spraying attempts.

Hardening Active Directory against password spraying attacks:

• Strong password policies: Enforce complex password policies, including minimum length, character diversity, and password age.

• Multi-factor authentication (MFA): Implement MFA to provide an extra layer of security, making it significantly more challenging for attackers to gain unauthorized access.

• Regular user training: Educate users on the importance of strong passwords and identifying suspicious activity, such as phishing attempts.

Kerberoasting to escalate privileges 

Phase: Lateral movement.  

Tactic: Kerberoasting is a lateral movement/privilege escalation technique in Active Directory environments that targets accounts configured with Service Principal Names (SPNs). SPNs are unique identifiers that Kerberos uses to map a service instance to a service account in whose context the service is running. 

Attack method(s): Domain accounts are often used to run services to overcome the network authentication limitations of built-in accounts such as NT AUTHORITY\LOCAL SERVICE. Any user in an AD environment can request a Kerberos ticket for any service account in the same domain. 

All an attacker needs to perform a Kerberoasting attack is any AD user account's (regardless of the permission level) cleartext password (or NTLM hash), a shell in the context of a domain user account, or SYSTEM level access on a domain-joined host.

After a successful Kerberoasting attack, the attacker will receive a Kerberos ticket (TGS-REP) that is encrypted with the service account’s NTLM hash. With this in hand, the attacker can perform an offline brute-force attack with a tool such as Hashcat and potentially obtain the account’s cleartext password. 

It is not uncommon for an account with Domain Admin (or equivalent privileges) to be configured with an SPN with a weak, easily crackable password so this attack has a high probability of leading to domain compromise right after an initial foothold is obtained. 

Another common scenario is that an attacker is able to crack the password for a service account that has access to resources such as MSSQL servers or other high-value targets within an internal network. This could lead to sensitive data disclosure or further down an attack chain toward domain compromise. 

Detection: We can break the detections for kerberoasting down into two categories: 

1. Event log monitoring 

2. Utilizing honeypot accounts. 

Event logging: Monitor Windows Security Event Log for Event ID 4769 (A Kerberos service ticket was requested) for suspicious patterns or excessive service ticket requests.

Employing honeypots: Create service accounts with weak passwords and monitor their usage to detect potential Kerberoasting attempts.

Hardening Active Directory against Kerberoasting:

• Implement a strong password policy requiring complex and lengthy passwords for service accounts to minimize the likelihood of cracking password hashes. 

• Enable LDAP Signing and LDAP Channel Binding which can help protect against man-in-the-middle attacks that could lead to unauthorized access to service accounts.

• Use Group Managed Service Accounts (gMSAs) which provide automatic password management and help mitigate the risk of password hash exposure.

• Audit service account permissions regularly to ensure they are appropriate for each account’s role. 

• Implement Privileged Access Management (PAM) to help limit the exposure of privileged credentials and reduce the attack surface for Kerberoasting. 

AD CS enumeration & compromising the domain with the ESC1 attack

Phase: Privilege escalation/domain compromise.

Tactic: Attacks involving Active Directory Certificate Services (AD CS) have become popular since the Certified Pre-Owned white paper was released in 2021. 

It disclosed eight different attacks against AD CS (specifically those involving misconfigured certificate templates), with the attack labeled ESC1 arguably being the most widespread in AD environments and easiest to pull off with readily available tools from a Windows or Linux attack host. 

This attack is possible if certain criteria are met: 

1. The Certificate Authority (CA) grants enrollment rights to low-privileged users (meaning they can request certificates), 

2. Approval is not required by a “manager” user for certificate requests, 

3. Certificate requests do not need to be signed, 

4. A certificate template exists that grants enrollment rights to low-privileged users, meaning a user is able to request and obtain a certificate based on the given template. 

5. The last condition (that makes this attack so powerful) is that the given certificate template allows the requestor to specify a Subject Alternate Name (SAN). 

If this configuration is present, an attacker can request a certificate specifying any account name in the AD environment, meaning they can authenticate as any user (i.e., a Domain Admin) and access any resources that this user has access to. 

It often results in quick domain compromise, with the entire attack being performed with just a single low-privileged AD user account. 

Attack method(s): An attacker can use various methods to perform this attack from a Linux host. The most straightforward is using the Certipy tool to first enumerate vulnerable certificate templates. 

If any are discovered, this tool can then be used to request a certificate on behalf of a Domain Admin, or other privileged user. 

With this certificate in hand, an attacker can authenticate and obtain an NTLM password hash for this account—which can be combined with different tools to perform a pass-the-hash attack and compromise the domain. 

This can also be performed from a Linux attack host using the tool Certi, but then multiple other tools are needed in the process. Though these two methods achieve the same end goal, Certipy is more streamlined as it wraps all of the steps to complete the attack into one, reducing the complexity and room for error. 

There have been times when some stage of the attack using Certipy failed for me and I had to follow the more “manual” process using Certi along with other tools as there was more opportunity for debugging along the way. 

This same attack can be performed from a Windows host using the Certify tool to enumerate vulnerable certificate templates, and then request a certificate for a privileged user. 

The ticket must then be converted using OpenSSL before it can be used with Rubeus to request a TGT Kerberos ticket and perform a pass-the-ticket attack to compromise the domain. 

Detection: We can break this down into event logging, analyzing network traffic & inspecting any certificate requests. 

Event logging: First ensure AD CS logs are enabled and then review the AD CS logs to identify potential enumeration attempts or suspicious certificate requests. Look for Event ID 4886 (Certificate Services received a certificate request) and Event ID 4887 (Certificate Services approved a certificate request) in the Windows Application Event Log.

Analyzing network traffic: Keep an eye on network traffic related to certificate requests. Unusual traffic spikes or patterns related to certificate services may indicate an ongoing attack.

Inspecting certificate requests: Regularly review certificate requests to identify any suspicious patterns or anomalies, such as requests for certificates with high privileges or from unexpected sources.

Hardening Active Directory against the ESC1 attack:

• Secure AD CS configurations: Ensure that your AD CS setup follows best practices, such as restricting certificate templates to the necessary permissions and limiting the types of certificates users can request.

• Implement the Principle of Least Privilege: Grant users, computers, and services only the minimum necessary privileges to perform their tasks, reducing the risk of unauthorized certificate requests.

• Regularly audit AD CS: Periodically review your AD CS setup, checking for misconfigurations or potential vulnerabilities that could be exploited by attackers.

• Monitor issued certificates: Keep track of issued certificates and their associated permissions. Revoke any suspicious or unnecessary certificates to limit attackers' abilities to exploit them.

Stealing AD password data with DCSync 

Phase: Post-exploitation.

Tactic: DCSync is a technique for stealing the Active Directory password database. The attack grants an attacker privileges over the built-in Directory Replication Service Remote Protocol, which is used by Domain Controllers to replicate domain data. 

This allows an attacker to mimic a Domain Controller and, in turn, retrieve user NTLM password hashes by requesting a Domain Controller to replicate passwords via the DS-Replication-Get-Changes-All extended right. This access control right allows for the replication of secret data within an AD environment. 

To perform the DCSync attack, an attacker must have control over an account that has these rights set, or obtain the rights to grant these rights to an account under their control. (Domain Admin and Enterprise Admin accounts have these rights by default.)

Attack method(s): Once these rights have been obtained an attacker can perform this attack remotely from a Linux machine within the internal network using the secretsdump.py tool from the Impacket toolkit. 

On Windows, this can be performed with the Mimikatz tool. These tools work by using the Windows API to simulate the domain controller replication process and extracting credentials from the replicated data. The attack can be performed with a cleartext password, via pass-the-hash, or via pass-the-ticket. 

This attack uses built-in permissions in AD. So prevention consists of hardening against AD attacks far earlier in the attack chain to ensure that an attacker is unable to grant an account these rights or take over an account that already has these rights. 

Detection: We will break this down into methods of detecting Mimikatz, whilst also covering generic Windows Event logging for DCSync detection. 

Let's first cover the Mimikatz detection with what to monitor for in reference to process detection or detecting command line arguments! 

Monitoring process creation: Inspect Windows Security Event Log for Event ID 4688 (A new process has been created). Look for entries with the process name "mimikatz.exe" or other known Mimikatz binaries, such as "mimikatz_trunk.exe."

Detecting command-line arguments: Monitor command-line arguments associated with Mimikatz usage. Examine Event ID 4688 (A new process has been created) for command-line arguments indicative of Mimikatz DCSync usage, such as "lsadump::dcsync" or "lsadump::dcsync /user:."

Finally, we can now cover the more generic event IDs for detecting a DC sync attack. 

Windows Event Logging: Inspect Windows Security Event Log for Event ID 4662 (An operation was performed on an object). Look for entries with properties "Replicating Directory Changes" and "Replicating Directory Changes All," which indicate a potential DCSync attack.

Hardening Active Directory against DCSync:

• Restrict sensitive permissions: Limit the number of accounts with permissions to perform replication activities. Ideally, only domain controllers and necessary administrative accounts should have these permissions.

• Employ the Principle of Least Privilege: Ensure users, computers, and services have only the minimum necessary privileges to perform their tasks. This reduces the risk of attackers exploiting overprivileged accounts to perform DCSync attacks.

• Regularly audit AD permissions: Periodically review permissions in your AD environment to identify and remediate any unnecessary or excessive privileges that could be exploited by attackers.

• Implement security monitoring and alerting: Set up alerts for suspicious activities, such as unauthorized replication requests or the use of known DCSync-related tools.

Using the Golden Ticket attack to access resources

Phase: Post-exploitation/persistence.

Tactic: The Golden Ticket attack is a persistence mechanism that allows an attacker to forge and sign Ticket Granting Tickets (TGTs) using the built-in krbtgt AD account. This account acts as a KDC service account for domain controllers and is used to encrypt and sign all Kerberos tickets in the domain. 

These tickets are considered valid due to being signed with the krbtgt account’s NTLM password hash and can even be created for a user that does not exist and then used to access resources in the domain. 

This is an excellent persistence mechanism because a Golden Ticket can be created for real users that exist in the domain and can be difficult to detect because:

• They are valid TGTs. 

• Windows event logs do not alert on a maliciously created TGT.

• Resetting an impersonated account’s password does not invalidate the Golden Ticket. 

To invalidate a Golden Ticket, the password for the krbtgt account must be changed twice. One caveat to this is that the first change needs to be replicated across the entire domain before the second password change can happen, which can take up to 24 hours. 

If an attacker is able to obtain the krbtgt NTLM hash again before the second password change, the process must be repeated. It is always a good idea to change this password on a set schedule, ideally after an organization undergoes an internal penetration test that results in domain compromise. 

Attack method(s): This attack can only be performed after domain compromise, resulting in obtaining the NTLM hash for the krbtgt account either via dumping the NTDS.dit AD database and extracting credentials, or via the DCSync attack discussed previously. 

A Golden Ticket can be created on a Windows host using Mimikatz or ticketer.py from Impacket from a Linux attack host after obtaining the NT hash, AES 128, or AES 256 key for the krbtgt account along with the domain SID. 

Once the Golden Ticket is forged, a pass-the-ticket can be performed with Mimikatz or Rubeus to authenticate using the ticket from Windows. The ticket can then be used alongside various Impacket tools and others from a Linux host to access resources in the target’s domain and maintain persistence. 

Detection:

Windows Event Logging: Inspect Windows Security Event Log for Event ID 4769 (A Kerberos service ticket was requested) and Event ID 4672 (Special privileges assigned to new logon). Look for unusual patterns, such as short ticket lifetimes, inconsistent encryption types, or unusually high privileges.

Hardening Active Directory against Golden Ticket attacks:

• Secure the krbtgt account: Regularly change the password for the krbtgt account to limit the attacker's ability to create valid Golden Tickets. Ensure that the account's password is complex and not reused across other accounts.

• Limit sensitive permissions: Restrict the number of accounts with high privileges, such as Domain Admins, to minimize the risk of attackers gaining unauthorized access through Golden Tickets.

• Employ the Principle of Least Privilege: Ensure users, computers, and services have only the minimum necessary privileges to perform their tasks. This reduces the risk of attackers exploiting overprivileged accounts to perform Golden Ticket attacks.

• Implement security monitoring and alerting: Set up alerts for suspicious activities, such as unusual Kerberos ticket requests or the use of known Golden Ticket-related tools like Mimikatz.

Great offense and defense go hand in hand

Exploring the attack path above is a useful way to learn more about how to attack, detect, and harden to reduce the attack surface of your Active Directory environments. 

By understanding the tactics and techniques used by attackers, Blue teams can take a proactive approach to security and implement effective measures to reduce the attack surface of their AD environments.

On the other hand, Red teamers and penetration testers can gain a better understanding of how they might be detected or restricted in real-world scenarios. This can help them improve their skills and become more effective at identifying vulnerabilities and potential attack paths.

So whether you're on the offensive or defensive side of security, there's much to be gained from learning each other's skills and approaches. 

Finally, if you’re interested in learning more about Active Directory or defensive/offensive security content, browse our expert-crafted cybersecurity courses on the HTB Academy or practice with our hands-on cyber Labs. 

Author bio: Ben Rollin (mrb3n), Head of Information Security, Hack The Box Ben Rollin has over 13 years of information security consulting experience focusing on technical IT Audits, risk assessments, web application security assessments, and network penetration testing against large enterprise environments. He has a strong interest in Active Directory security and focuses time on research in this area as well as remaining current with the latest tactics, techniques, and procedures (TTPs). Ben has a bachelor's degree in Business Administration, as well as several industry certifications including Certified Information Systems Security Professional (CISSP), Certified Information Systems Auditor (CISA), Offensive Security Certified Expert (OSCE), and Offensive Security Certified Professional (OSCP). Feel free to connect with him on LinkedIn.

 

Author Bio: Sabastian Hague (sebh24), Defensive Content Lead, Hack The Box Sabastian Hague is a seasoned cybersecurity professional with over eight years of experience in the field. After serving in the Royal Air Force as a specialist in all things SOC, he went on to work for Vodafone's global CERT team before taking on a role as a senior security consultant with SpiderLabs and working on numerous high-profile incidents. He is now the Defensive Content Lead at Hack The Box. Seb has numerous industry certifications including GIAC Certified Detection Analyst (GCDA), GIAC Continuous Monitoring Certification (GMON), GIAC Certified Incident Handler (GCIH), GIAC Certified Intrusion Analyst, Offensive Security Certified Professional (OSCP), Blue Team Level 1 (BTL1), Blue Team Level 2 (BTL2), Cybereason Threat Hunter (CCTH).  You can connect with him on LinkedIn or Twitter.