Compatibility to Compromise

A lot of relevantly recent research has been coming out for Active Directory Certificate Services (ADCS), spearheaded by the team at SpectorOps. It has been prevelent in the wild and allowed for pretty quick and easy wins for malicious actors and penetration testers alike. Now a normal requirement to abuse these services is some form of domain access, usually a domain user or authenticated user depending how the templates and CA's are configured.

Now you may be saying, "Well no one will get access. All my users can spot every phish, I have a 20 character password limit, no roast-able users or services, and no legacy protocols leaking my hashes on the network!". While that is great, recent research into computer accounts have brought out some interesting findings that you may not even be aware of.

TrustedSec recently released a blog discussing the pre-creation of computer accounts found at https://www.trustedsec.com/blog/diving-into-pre-created-computer-accounts/ and some interesting properties a checkbox can have. I suggest giving it a read if you are interested in more technical details.

TLDR: Pre-created Computer accounts have random passwords by default but if it is set as Pre-2000 compatible, the password is set to the computer name without the "$" up to 14 characters. If the machine name is longer, anything past 14 is truncated and discarded. There are also cases of these having a blank password depending on what created it. Any reset accounts fall back to this same default password format. Since machine accounts are also considered user accounts to some degree in Active Directory, these can be used for initial footholds and enumeration. A potential chain is to find a valid computer account and use it to enumerate ADCS services.

Starting off in a lab environment, we have access to an internal Kali instance. Lets enumerate the subnet we are on to see where we are in the environment.

Looks like we have a domain controller and a possible ADCS server. This will be useful later. Now there are several approaches to handling internals, but I like to always check DCs for null binds, whether to SMB or less common but powerful is LDAP.

enum4linux -a 192.168.254.138

So we have some ability to enumerate, but not via RPC on 139. We did gain some useful knowledge such as the password policy, which could be useful when paried with known usernames. Next, let us check ldap to see if we need credentials for enumeration. We can use ldapsearch to run a base query and get some general inforamtion from ldap, including the naming context for the root domain.

ldapsearch -x -H ldap://192.168.254.138 -s base //Base query

Next we will alter the ldap query to see if we can access any objects under the domain context without a password. A failed bind may look like this:

Let us see if we get the same result. Since we are looking for computer accounts, I'm limiting the search to computer objects.

ldapsearch -LLL -x -H ldap://192.168.254.138 -b 'DC=LAB,DC=LOCAL' "(objectClass=computer)" cn sAMAccountName logoncount > ldap_comps

Looks like we are in buisness, null LDAP sessions are possible on this DC. We see the accounts that were enumerated earlier, but also some computer accounts with interesting names that indicate they are pre-created accounts. Using this information, we can build a hostname list to be run through a tool created by an Optiv consultant called Pre2k. Pre2k allows unauthenticated and authenticated enumeration of computer accounts in a domain environment, performing password guessing looking for Pre-2000 compatible machine accounts. I'll fire it up and see if these are indeed vulnerable.

pre2k unauth -d lab.local -dc-ip 192.168.254.138 -inputfile  hosts.txt -save -verbose

Looks like we have valid credentials. As suspected, it is a pre-created machine accounts with Pre-2000 compatiablity. Lets confirm this:

The errors shown do not indicate invalid logon errors, which means the password is indeed correct but the DC isn't allowing the login to SMB services due to the default, unchanged password. This doesn't mean the account is useless, actually far from it. You can go about using these in two main ways, change the passwords via RPC, ldap, or kerberos. The easiest and already implemented into a impacket pull request is via RPC with rpcchangepw.py. The other is to pull a kerberos ticket for the account, which pre2k already does for you with the --save flag. These can be used for kerberos authentication.

Now that we have a valid account, let us check out that ADCS server using certipy.

certipy find -u pre2k\$@lab.local -k -dc-ip 192.168.254.138 -ns 192.168.254.138 -target dc01 -no-pass

You can also use the -enabled and -vulnerable flags to pull just those templates.

Looks like we have a template that is vulnerable to ESC1 privilege escalation. I'll use Certipy's request module to abuse it.

certipy req -u pre2k\$@lab.local -ca ADCS -k -dc-ip 192.168.254.138 -ns 192.168.254.138 -target ADCS -no-pass -template ESC1 -upn labadmin@lab.local

certipy auth -pfx labadmin.pfx -dc-ip 192.168.254.138

Just like that, I now own one of the domain admin's accounts, which effectively means I own this domain. Even if this account raises alarms, and someone else was to password reset it, I can simply use the current certificate to pull the NTLM hash since the certificate doesn't expire for over a year and has no requirements on being used with the current password! This showcases just how powerful and persistence these domain escalation paths are and why its important organizations take this seriously. To prove I have elevated access, I'll use CME to test it.

There you have it, how legacy compatibility options for machine accounts and misconfigured ADCS services can lead to complete domain compromise in the same amount of time as ordering a pizza or making a 5th cup of java. This is just the tip of the iceberg, as there has been several different paths outlined as I mentioned in my post https://redheadsec.tech/new-role-new-ad-takeover/ along with CVE-2022-26923. Patches and best practices have been released from Microsoft and other security researchers to mitigate these issues and common misconfigurations and I encourage red and blue teams to get up to speed on these issues.

Special thanks for the teams at SpectorOps, TrustedSec, Optiv, and independent researchers who continue to uncover these issues and provide guidance for the community.

Till next time, farewell and happy hacking!