Red Teaming
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.
Phase: Enumeration.
Tactic: Active Directory (AD) username enumeration Loading Preview...
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 Loading Preview... Loading Preview...
This tool uses Kerberos Pre-Authentication Loading Preview...
Related read: A beginner-friendly (visual) guide to Kerberos authentication and security Loading Preview...
This method does not generate Windows event ID 4625: An account failed to log on Loading Preview...
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.
👉 Recommended read for all defenders: Active directory hardening checklist & best practices Loading Preview...
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.
Windows attack & defense course
Interactive training on the most commonly abused and fruitful attacks against Active Directory, allowing horizontal and vertical privilege escalations as well as lateral movement.
Learn different prevention techniques, detection methods, and how to implement honeypots (if possible) to trap attackers executing various attacks.
Finish the course with a practical hands-on skills assessment to test your newly developed skills.
Phase: Foothold/lateral movement.
Tactic: Password spraying Loading Preview...
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 Loading Preview...
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 Loading Preview...
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.
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.
Hone your AD skills with Zephyr
Zephyr is a new Pro Lab designed for anyone with the foundational knowledge of Active Directory TTPs looking to expand their skill set in AD enumeration and exploitation.
Upon completion, players will earn 40 (ISC)² CPE credits and learn essential aspects of AD penetration testing, such as:
Lateral movement and crossing trust boundaries
Password cracking
Privilege escalation
Web application, SQL, and relay attacks
Pivoting
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) Loading Preview...
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:
Event log monitoring
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.
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.
Phase: Privilege escalation/domain compromise.
Tactic: Attacks involving Active Directory Certificate Services (AD CS) have become popular since the Certified Pre-Owned white paper Loading Preview...
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:
The Certificate Authority (CA) grants enrollment rights to low-privileged users (meaning they can request certificates),
Approval is not required by a “manager” user for certificate requests,
Certificate requests do not need to be signed,
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.
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 Loading Preview...
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 Loading Preview...
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 Loading Preview...
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.
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.
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 Loading Preview...
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 Loading Preview...
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 Loading Preview...
On Windows, this can be performed with the Mimikatz Loading Preview...
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.
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.
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 Loading Preview...
Once the Golden Ticket is forged, a pass-the-ticket can be performed with Mimikatz or Rubeus Loading Preview...
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.
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.
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 Loading Preview... Loading Preview...
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. Loading Preview... |
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 Loading Preview... Loading Preview... |
Community
Blog Upcoming Events Meetups Affiliate Program SME Program Ambassador Program Parrot OSGet Help
Help Center Contact SupportCommunity
Blog Upcoming Events Meetups Affiliate Program SME Program Ambassador Program Parrot OSGet Help
Help Center Contact Support