Over my career as a member of blue teams and a pentester, I have noticed a trend of common attack paths I have used to exploit Active Directory (AD) whether to get domain admin or reach target systems. For this blog, I have chosen to highlight the following five (5) paths:
• LLMNR, mDNS, and NBT-NS spoofing
• NTLM Relay
• Misconfigured AD CS Certificate Templates – ESC1
• Kerberoasting
• GPO Delegation misconfiguration
I have seen each of these repeatedly over the years. What do they have in common? They are both easy to exploit, and easy to remedy. Some of these attack paths are commonly used with other listed paths but are not the only ways to use them so that is why they are listed separately.
I will not cover each mechanism in detail (there are already so many great explanations online), instead I want to focus on how to fix the vulnerabilities. But for those of you are interested in the ins and outs of how the processes work, there is a list sources at the end of this blog, and I highly recommend checking those out for yourself.
LLMNR (Link-Local Multicast Name Resolution), mDNS (multicast domain name service), NBT-NS (NetBIOS Name Service) are common techniques used when standard DNS is unable to resolve a hostname in the Windows environment. In these instances, it is possible for an attacking machine to spoof the authoritative source for name resolution using these services.
This attack is typically performed with a tool called Responder that stands up separate servers to respond to LLMNR/NBT-NS/mDNS traffic. From there, Responder receives the username and NTLMv2 hash from hosts that belong to a resource that requires identification/authentication. Tools, such as Hashcat, can then crack it offline.
All the remediation steps can be done via group policy, though NBT-NS is a bit more complex. NBT-NS requires deploying a script via group policy due to the nature of the registry values used to enable/disable it.
Disable LLMNR
• Go to the group policy editor and create a new GPO (group policy object)
• Edit the new GPO.
• Go to Computer Configuration -> Administrative Templates -> Network -> DNS Client
• Enable the setting “Turn off multicast name resolution.”
Disable mDNS
• Go to the group policy editor and create a new GPO (group policy object)
• Edit the new GPO.
• Go to: Computer Configuration -> Preferences -> Windows Settings -> Registry
• Right click the right panel -> New -> Registry Item
• Action: Update
• Hive: HKEY_LOCAL_MACHINE
• Key Path: SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
• Value name: EnableMDNS
• Value type: DWord
• Value data: 0
Disable NBT-NS
• Go to the group policy editor and create a new GPO (group policy object)
• Edit the new GPO.
• Go to Computer Configuration -> Policies -> Windows Settings -> Scripts -> Startup- > PowerShell Scripts
• Add a .ps1 file to the scripts list with the below PowerShell script.
• $regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
• Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}
If you are needing one of the above settings to remain enabled for work related functions, a mitigating factor is having a strong password policy to help prevent the captured hashes from being cracked.
Over the years, Microsoft has continued to evolve its recommended password policies including getting rid of maximum password age. The one key flaw I have found about Microsoft’s changes to its recommendations is that if a password hash has been dumped without the knowledge of the organization, that hash (and eventual cracked password) can continue to be used. I have included a link to Microsoft’s suggested guidelines along with adding recommendations that attempts to mitigate that potential vulnerability. Auditing your users’ passwords semi-regularly should also be considered (a domain admin can dump ntds.dit and put them through a password cracker like Hashcat with common wordlists) Common wordlists include:
• Character length: 14 minimum
• Password Complexity rules: enabled
• Password maximum age: 90 days
• Minimum password age: 7 days
• Password history: 10
• Ban common passwords
o This will require additional software or an Azure AD environment.
NTLM relay allows an attacker to intercept legitimate authentication requests and forward them to a server, which then authenticates the attacker with the same permission set as the victim. This can be very bad if the victim account being relayed is a domain administrator. Common methods/tools to initiate NTLM relay are responder with ntlmrelayx or exploiting PtetitPotam to force NTLM authentication to ntlmrelayx. NTLM Relay is also used to exploit AD CS HTTP endpoints (ESC8).
Enable SMB Signing on all systems (some older software may not support SMB signing)
• Go to the group policy editor and create a new GPO (group policy object).
• Edit the new GPO.
• Go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
• Enable the following options:
o Microsoft network server: Digitally sign communications (always); and
o Microsoft network client: Digitally sign communications (always).
Disable NTLM where it is not necessary (e.g., Domain controllers, AD CS)
• Go to the group policy editor and create a new GPO (group policy object).
o This one should be placed in an OU that only contains Domain controllers and AD CS server.
• Edit the new GPO.
• Go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
• Enable setting:
o Network Security: Restrict NTLM: Incoming NTLM traffic.”
Set to: Deny all accounts.
Disable/remove the NTLM provider in the Internet Information Services (IIS) running the selected role services (CertSrv)
• Bring up IIS Manager on the webserver hosting web services for AD CS.
• Go to %SERVER% -> Sites -> Default Web Site -> CertSrv -> Authentication -> Windows Authentication -> Providers.
• Remove all enabled providers except for NegotiateKerberos.
More information on NTLM relay: https://en.hackndo.com/ntlm-relay/
Privilege Escalation
One of the most common vulnerabilities involving Active Directory Certificate Services (AD CS) are misconfigured certificates templates (ESC1). These require a specific set of circumstances to be exploited including Enterprise CA granting low-privileged users enrollment rights, manager approval being disabled, no authorized signatures being required, and the certificate template allowing requesters to specify a subjectAltName (SAN) in the certificate signing request (CSR).
These settings allow a low-level user to create a certificate to authenticate as any principal in the domain via Kerberos or SChannel. Tools such as Certify or Certipy (Python) are used to exploit this vulnerability and can easily lead to impersonating a domain administrator or other privileged user. Some reasons these settings may be enabled are to allow products or deployment services to generate HTTPS certificates or host certificates on the fly. If this is the use case for needing to be able to add a SAN to a certificate, then limit these privileges to a specific secure service account instead of domain users or domain computers.
• Find vulnerable template with the tool certify (can be run on any domain connected workstation or run as a domain user on a windows system).
o Syntax: Certify.exe find /vulnerable
• Can also use Certipy if running from a Linux system.
o Syntax: Certipy find -u %username%@%domain%.%tld% -p %password% -dc-ip %dcIPaddress%
• Open up certsrv on the AD CS server.
• Go to %CA% -> Certificate Templates -> right click “Certificate Templates” -> Manage
• Open the vulnerable template -> Go to Security tab
• Make necessary changes to remove groups or users who do not need access to this template.
More resources on Misconfigured AD CS Certificate Templates (ESC1): https://www.thehacker.recipes/ad/movement/ad-cs/certificate-templates
Kerberoasting is an attack method that exploits the capability of how Windows handles services that run on behalf of user accounts in AD. The attack harvests the TGS ticket for these services which are encrypted with keys derived from user passwords. Any domain user account can be used to request TGSs to pull down the ticket, with a tool such as GetUserSPNs.py (Linux), Rubeus.exe (Windows), or setspn.exe (Windows). From there, the password hash can be extracted and cracked offline with Hashcat. To note, only user accounts are exploitable this way, as computer account passwords are strong randomly generated passwords.
• Set up Group Managed Service Account (gMSA) for services as the account created has a sAMAccountType set to MACHINE_ACCOUNT which like computer accounts has a random and complex password.
• You can enable the setting “This account supports Kerberos AES 128/256 bit encryption” in the Active Directory Users and Computers user properties.
o To note it is possible for the attacker to get an RC4 encrypted ticket by specifying RC4 as the only supported encryption algorithm we support in the TGS request body.
• Each service account should only be used for one service and have limited permissions.
• Each service account should have a much stronger password then typical user accounts, as service account passwords tend to not change.
• Disable service accounts once they are no longer being used.
More info on Kerberoasting: https://en.hackndo.com/kerberos/
Misconfigured group policy objects (GPOs) are an interesting attack path. Unless proper monitoring is setup, it is an easy win for a threat actor to get administrative rights on a system by pushing it via GPO. GPOs tend to be forgotten about after being implemented and a full audit of group policy can take a long time depending on the side of the AD environment.
As a pentester, I look for misconfigurations such as domain users having GenericAll (all privileges), GenericWrite (write access to the GPO) access, or even WriteDACL (make changes to ACLs of GPO giving my compromised account full access to the GPO) among others. From there I could easily add a scheduled task to run a payload, or even have it add the compromised account as a local admin to the system via scheduled task (using cmd.exe).
• GPO audits can take a long time, so a quicker way to find vulnerabilities in GPO ACLs (or AD object vulnerabilities in general) is with a tool called Bloodhound (and Sharphound).
o Sharphound is used to make all the quarries of AD before putting all the information into a zip file.
o You then take that zip file and place it into Bloodhound which first loads it into a neo4j database then the GUI allows you to quarry the database to find specific vulnerabilities.
• If you want to do this a bit manually (to not have to deploy a kali image or setup bloodhound/neo4j on a system), you can use a tool, such as PowerSploit to look for vulnerabilities
• Once you find your vulnerable GPO you can go to group policy management on your DC (or another system and connect to the DC through it).
• Go to: Forest: %forestname% -> Domains -> %domainname% -> Group Policy Objects -> select the vulnerable group policy -> Delegation tab.
• Select the user, group, computer object that is vulnerable and click either remove (if you want to remove the object completely), or properties (then security tab) to change specific permissions.
More information on Group Policy Delegation misconfiguration:
• https://www.thehacker.recipes/ad/movement/group-policies
• https://bloodhound.readthedocs.io/en/latest/data-analysis/edges.html
https://www.truesec.com/hub/blog/mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-adv210003-kb5005413-petitpotam
https://woshub.com/how-to-disable-netbios-over-tcpip-and-llmnr-using-gpo/
https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation
https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/kerberoast
https://dev-2null.github.io/Kerberoasting-AES-Encryption-Protected-Users-Group-and-gMSA/
US: 877.487.8160
watchmen@fortalicesolutions.com
EMEA: 0800.824.7030
emea@fortalicesolutions.co.uk
