To fingerprint the GOAD lab for signs of ADCS I began by running an nmap scan:
nmap -sV -sC -iL goad_hosts.txt -oA goad_initial_scan
From the initial scan there are a few indications of certificate authorities being present. Nmap successfully retrieves information about certificates being used for https, ldaps, rdp and more. For further information I also connected the ports with openssl. The most interesting information pertains to the name of the Certificate Authorities, which we can later use when attempting to exploit vulnerable certificates and CA configuration.
kingslanding.sevenkingdoms.local 10.3.0.10
This machine is a domain controller for the sevenkingdoms.local domain. Nmap picked up some interesting info regarding certificates in the domain.
LDAP and LDAPS ports have certificate with an OID 1.3.6.1.1.1.311.25.1, which according to the Microsoft documentation is used as a Subject Alternative Name to specify the GUID of the Directory itself. The dns name is kingslanding.sevenkingdoms.local and indeed the certificates CommonName is SEVENKINGDOMS-CA. Even more information on the root certificate can be revealed by using openssl s_client to directly bind to the LDAP ports and view the certificate:
Interestingly, there is an IIS server running on port 80, however nmap did not indicate a certificate for this port nor port 443 (HTTPS) running. Closer investigation reveals the default IIS page.
Fuzzing for common iis directories it can be determined that some form of ADCS Web Enrollment is running on kingslanding.
gobuster dir -u http://10.3.0.10 -w /usr/share/wordlists/seclists/Discovery/Web-Content/IIS.fuzz.txt
As this site does not use HTTPS, it may be susceptible to NTLM authentication and, therefore, NTLM relay attacks. This technique is detailed in SpecterOps’ Certified Pre-Owned paper as ESC8. NTLM authentication to the certsrv page can be verified by viewing the response headers via curl.
The relay attack can be successful if there is a method to coerce authentication via another vulnerability. Then with this credential relayed to certsrv, a user/machine certificate can be requested, which potentially could be used for client authentication, i.e., persistence beyond the limitations of an NTLM authenticated session by authenticating with the certificate using Kerberos.
winterfell.north.sevenkingdoms.local 10.3.0.11
This machine appears to be a domain controller as well, as it advertises ports 53 (DNS), 88 (Kerberos), and the various LDAP ports. Although this appears to be a child domain, certificates for LDAPS originate from the same Certificate Authority hosted on kingslanding (sevenkingdoms-CA).
mereen.essos.local 10.3.0.12
This machine is the domain controller for the essos.local domain. Again, here the CA for the domain is identified as essos-CA however it is unclear which server hosts the CA, or issuing Certificate authority.
castelblack.north.sevenkingdoms.local 10.3.0.22
This server contains the MSSQL service. However, it seems to use self-signed certificates for this service and Remote Desktop. It is a member of the north.sevenkingdoms.local domain, and if it is vulnerable to a coercion attack could possibly be used for NTLM relay to the sevenkingdoms-CA. Also, as this is not a domain controller, we may be able to use this server for SMB relay attacks to achieve NTLM authentication, as signing is enabled but not required. SMB signing wards off relay attacks because authentication is cryptographically bound to the machine that requests it, checking for integrity like a digital signature. Signing is enabled and required by default on Domain Controllers but is not on Domain Computers.
braavos.essos.local 10.3.0.23
This machine is setup very similar to castelblack in that a MSSQL server with self-signed certificates is present. However, investigating the IIS server on this machine revealed that this is likely the CA for the essos.local domain.
Takeaways
We have two Certificate authorities, one handling certificates for the sevenkingdoms.local and north.sevenkingdoms.local domains the other for the essos.local domain. Both domains contain installations of Active Directory Certificate Authority Web Service and hosting the site without SSL/TLS. In the next post I will enumerate certificates using a non-privileged user account and identify vulnerabilities regarding certificate templates, web enrollment, and the servers themselves.
Hackers With a heart 