Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Overwatch 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.
About the Machine
Overwatch is a medium-difficulty Windows machine that focuses on Active Directory enumeration, MSSQL abuse, credential interception, and application-level privilege escalation. The machine requires chaining multiple enumeration techniques across SMB, LDAP, and MSSQL before exploiting a vulnerable internal monitoring service to achieve SYSTEM-level command execution.
The attack begins with network enumeration, where an Nmap scan reveals several services typical of an Active Directory Domain Controller, including Kerberos, LDAP, SMB, and WinRM. Further enumeration also exposes a Microsoft SQL Server instance running on a non-standard port.
SMB enumeration confirms access to several domain shares, including a custom share named software$. Browsing this share reveals a directory containing files for an internal monitoring application. From this share, the application configuration file and executable are retrieved for further analysis.
Inspecting the configuration file exposes the endpoint of an internal WCF monitoring service, while analyzing the application binary reveals that it communicates with a backend SQL database using hardcoded credentials. These credentials are validated against SMB and subsequently used to authenticate to the MSSQL server.
With authenticated access to the database, enumeration of SQL metadata reveals the presence of a linked server configuration, indicating that the SQL server attempts to connect to another host within the environment. By abusing this configuration, it becomes possible to intercept authentication attempts from the SQL server.
To exploit this behavior, a malicious DNS record is added within the domain, redirecting the linked server hostname to the attacker machine. Using Responder, the resulting authentication attempt is captured, revealing credentials for another domain account.
The newly discovered account is validated against domain services and confirmed to have access to WinRM, allowing remote management access to the target system. Using Evil-WinRM, an interactive PowerShell session is obtained, providing initial access to the machine.
Further analysis of the previously retrieved monitoring application reveals a critical vulnerability in the KillProcess WCF method, where user-controlled input is directly concatenated into a PowerShell command without sanitization. Because the service runs with SYSTEM privileges, this results in a command injection vulnerability.
Since the vulnerable service is only accessible locally, the exploit payload is delivered from within the WinRM session using a crafted SOAP request. By injecting PowerShell commands through the vulnerable parameter, arbitrary commands can be executed as NT AUTHORITY\SYSTEM.
Finally, this access is used to retrieve the Administrator root flag, completing the machine. Overall, Overwatch demonstrates how weaknesses in application design, SQL server trust relationships, and internal service exposure can be chained together to move from limited domain access to full system compromise.
The first step in owning the Overwatch 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:
Once the connection between my Kali Linux terminal and Hack the Box server has been established, I started the CCTV HTB machine and I was assigned an IP address (10.129.244.81).
Nmap Enumeration
To begin the enumeration phase, I performed a full service and version scan against the target machine to identify exposed services and gather as much information as possible about the system.
The scan revealed several open ports that immediately suggested the target was part of a Windows Active Directory environment. Multiple services commonly associated with domain controllers were exposed, including Kerberos (88/tcp), LDAP (389/tcp), SMB (445/tcp), and Global Catalog LDAP (3268/tcp). The LDAP service response confirmed the domain name overwatch.htb, indicating that the system belonged to the OVERWATCH Active Directory domain.
I also observed several Windows networking services such as MSRPC (135/tcp) and NetBIOS (139/tcp), which are typically present on Windows servers and are often useful for further enumeration. SMB was accessible on 445/tcp, although Nmap indicated that SMB message signing was enabled and required, meaning certain relay-based attacks would not be possible.
The scan also revealed that Remote Desktop Protocol (RDP) was running on 3389/tcp. The RDP service provided useful information through the rdp-ntlm-info script, which disclosed the system hostname S200401 and confirmed the fully qualified domain name S200401.overwatch.htb. The reported product version 10.0.20348 strongly suggested that the system was running Windows Server 2022.
Another interesting service exposed on the host was WinRM (5985/tcp), running on Microsoft HTTPAPI. WinRM is commonly used for remote PowerShell management and is frequently leveraged in Windows environments for remote administration. If valid credentials were obtained later, this service could potentially be used to establish a remote session using tools such as Evil-WinRM.
Additionally, DNS was running on port 53, which is expected in an Active Directory environment since domain controllers typically host DNS services for domain name resolution.
Based on the combination of Kerberos, LDAP, SMB, and Global Catalog services, I concluded that the target machine was very likely functioning as a Domain Controller within the overwatch.htb domain. With this information in hand, the next step was to begin enumerating the domain services to identify valid users, shares, or other potential entry points.
Hostname Configuration
During enumeration, several services revealed internal domain names associated with the target system, including overwatch.htb and S200401.overwatch.htb. Since these names were not yet resolvable from my attacking machine, I manually added them to my local hosts file so that I could interact with the target using its domain names instead of relying solely on the IP address.
I appended the domain entries directly to /etc/hosts, mapping the target IP address 10.129.244.81 to the discovered hostnames overwatch.htb, S200401.overwatch.htb, and overwatch.htb0. After providing my sudo password, the entries were successfully written to the file.
This configuration ensured that any tools I used going forward such as SMB, Kerberos, LDAP, or web-based interactions could properly resolve the domain names associated with the target environment. In Active Directory scenarios, correct hostname resolution is often important because many services, particularly Kerberos authentication, rely on valid domain names rather than raw IP addresses.
Full Port Scan
After completing the initial service scan, I wanted to ensure that no additional services were running on non-standard ports. To achieve this, I performed a full TCP port scan across all 65,535 ports using a higher scan rate to speed up the process.
The scan confirmed the previously discovered Active Directory-related services, including Kerberos (88), LDAP (389), SMB (445), Global Catalog LDAP (3268), RDP (3389), and WinRM (5985). These services further reinforced the conclusion that the target machine was operating as part of an Active Directory domain environment.
In addition to the ports identified earlier, the full scan revealed several additional open ports that were not detected during the initial scan. Two of these were particularly interesting:
- 6520/tcp - MSSQL
- 9389/tcp - ADWS (Active Directory Web Services)
The presence of ADWS on port 9389 is common on modern domain controllers and is used by administrative tools such as Active Directory PowerShell modules for managing directory services remotely.
The discovery of port 6520 running MSSQL was especially noteworthy. Microsoft SQL Server instances are sometimes configured to listen on non-standard ports, and in CTF environments they can often provide valuable opportunities for credential discovery, database enumeration, or privilege escalation if access can be obtained.
The scan also revealed several high-numbered dynamic ports (such as 49664, 49668, 53966, 53967, and others). These are typical in Windows environments and are commonly used by RPC services and other internal Windows components.
At this stage, the enumeration confirmed that the target system exposed a wide range of Active Directory infrastructure services, along with a potentially interesting SQL Server instance running on a non-standard port. With this information, the next step was to begin deeper enumeration of services such as SMB, LDAP, Kerberos, and MSSQL to identify potential entry points into the system.
SMB Enumeration
After identifying SMB (445/tcp) during the Nmap scan, I moved on to enumerate the available SMB shares on the target system. SMB shares can sometimes expose useful files such as scripts, configuration files, or credentials that may help in gaining an initial foothold.
I first attempted to enumerate the shares using NetExec with anonymous authentication.
The output confirmed that the target system was running Windows Server 2022 (Build 20348) and belonged to the overwatch.htb domain with the hostname S200401. It also indicated that SMB signing was enabled and that SMBv1 was disabled, which is a typical configuration for modern Windows servers.
Although the tool initially appeared to authenticate with a null session, the share enumeration failed due to a NETBIOS timeout, preventing the shares from being listed successfully.
Since NetExec did not reliably return the share list, I attempted enumeration again using smbclient, which often works better in cases where SMB tools behave inconsistently.
When prompted for a password, I simply input my Kali Linux password and pressed Enter to attempt anonymous access. This successfully returned a list of available SMB shares on the system:
- ADMIN$ - A default administrative share used for remote system administration.
- C$ - The default administrative share providing access to the system drive (typically restricted to administrators).
- IPC$ - Used for inter-process communication over SMB.
- NETLOGON - A domain controller share that stores logon scripts used during domain authentication.
- SYSVOL - A critical Active Directory share that contains Group Policy Objects (GPOs) and domain scripts.
- software$ - A custom share that appeared particularly interesting since it was not a standard Windows administrative share.
The presence of the NETLOGON and SYSVOL shares further confirmed that the target machine was functioning as a Domain Controller within the overwatch.htb domain.
Among the discovered shares, software$ immediately stood out because it appeared to be a custom share and could potentially contain files deployed internally within the organization. In many CTF environments, custom shares like this often expose scripts, installers, or sensitive files that may provide valuable information for further exploitation.
MSSQL Enumeration
During the full port scan, I discovered that port 6520 was open but initially identified as an unknown service. Since non-standard ports can sometimes host important services, I performed a targeted Nmap service and version scan against that port to determine what was running.
The scan revealed that the service running on this port was Microsoft SQL Server 2022 RTM (version 16.00.1000.00). The output also showed that the SQL instance was listening on TCP port 6520, which indicates that the server had been configured to run SQL Server on a non-default port instead of the typical 1433/tcp.
Additional information gathered from the ms-sql-info and ms-sql-ntlm-info scripts confirmed several details about the environment. The SQL service was running within the OVERWATCH domain, and the database server was hosted on the machine S200401.overwatch.htb, which matched the hostname previously identified during the initial Nmap enumeration. The output also confirmed that the underlying operating system version was 10.0.20348, further supporting the earlier conclusion that the target system was running Windows Server 2022.
The scan also revealed that the service was using a self-signed SSL certificate, which is common in internal enterprise environments and typically does not provide a direct attack vector on its own.
The presence of a Microsoft SQL Server instance on a domain controller can sometimes introduce interesting attack opportunities, particularly if authentication is misconfigured or if database credentials can be obtained from other parts of the system. In many Active Directory environments, SQL servers are integrated with Windows Authentication, meaning that valid domain credentials could potentially be used to authenticate directly to the database service.
With the SQL Server instance identified, this service became a high-value target for further enumeration, as gaining access to it could potentially reveal stored credentials, linked servers, or execution privileges that might lead to code execution or privilege escalation.
SMB Share Enumeration
Earlier, I discovered an interesting custom SMB share named software$ while enumerating the available shares on the target system. Since custom shares often store internal tools, scripts, or application files, I attempted to access the share anonymously and recursively list its contents.
I used the -N flag to authenticate anonymously and enabled recursive listing so that all directories and files within the share would be displayed.
The command successfully returned the contents of the share. At the root of the share, I discovered a directory named Monitoring, which appeared to contain the files of a deployed application.
Inside the Monitoring directory, I observed a number of .NET application components, including several Entity Framework libraries, SQLite libraries, and various system assemblies. Among these files, one particularly interesting file stood out:
overwatch.exe
Alongside the executable, there were also supporting files such as:
overwatch.exe.configoverwatch.pdb(debug symbols)- Several DLL dependencies related to Entity Framework and SQLite
The presence of these files strongly suggested that the Monitoring application was a .NET-based program that interacted with a SQLite database through Entity Framework.
Another notable file was overwatch.exe.config, which is commonly used in .NET applications to store configuration settings such as database connection strings, credentials, or application parameters. Configuration files like this often contain sensitive information, making them valuable targets during enumeration.
Additionally, I observed architecture-specific directories named x64 and x86, each containing SQLite.Interop.dll, which further confirmed that the application relied on SQLite for database interactions.
The presence of the overwatch.pdb debug symbol file was also interesting, as debug files can sometimes reveal internal function names, file paths, or other development artifacts that may assist in reverse engineering the application.
At this stage, the Monitoring application files appeared to be a strong lead, particularly the configuration file and executable. The next logical step was to retrieve these files locally in order to inspect the configuration and analyze the application behavior for potential credentials or sensitive information that could provide an entry point into the system.
Retrieving the Application Configuration File
During the enumeration of the software$ SMB share, I noticed a file named overwatch.exe.config inside the Monitoring directory. Configuration files for .NET applications often contain useful information such as service endpoints, database connection strings, or application settings, so I decided to retrieve it for further analysis.
To download the file from the share, I used smbclient with anonymous authentication and requested the file directly from the Monitoring directory.
The file was successfully downloaded to my local machine. I confirmed its presence in my working directory.
The output showed the downloaded configuration file alongside my VPN configuration.
Next, I opened the file to inspect its contents.
The configuration file revealed that the Monitoring application was implemented as a .NET WCF service. Within the <system.serviceModel> section, I observed that the application exposed a service named MonitoringService with a base address configured as:
This indicated that the application was hosting a web-accessible monitoring service on port 8000. The configuration also defined a metadata exchange endpoint (mex), which is commonly used by WCF services to expose service metadata and can sometimes be leveraged for service enumeration.
Another notable detail in the configuration was the presence of the following setting:
This option enables detailed exception messages, which can sometimes leak sensitive information during error conditions. In many cases, this type of configuration is intended only for development environments but occasionally remains enabled in production deployments.
Further down in the configuration file, I also noticed that the application supported both Microsoft SQL Server and SQLite providers through Entity Framework. This aligned with the files previously observed in the SMB share, including several SQLite-related libraries.
Although the configuration file did not immediately reveal credentials or connection strings, it provided an important lead by exposing the Monitoring service endpoint running on port 8000. With this information, the next step was to investigate whether this WCF monitoring service was accessible and potentially exploitable.
Analyzing the Monitoring Application
After identifying the overwatch.exe executable within the Monitoring directory of the software$ share, I decided to download the binary for further inspection. Executables deployed on internal shares often contain embedded configuration details, credentials, or references to backend services that can assist in further enumeration.
I retrieved the file from the SMB share using smbclient.
The download completed successfully, and the executable was saved locally. Since the binary appeared to be a .NET application, I performed a quick static inspection using the strings utility to extract readable Unicode strings from the file.
Reviewing the output revealed several interesting details about the behavior of the application. The presence of strings such as “Monitoring started”, “Monitoring stopped”, and “Already monitoring” suggested that the program functioned as a process monitoring service.
One particularly notable string referenced the query:
This indicates that the application was likely subscribing to Windows Management Instrumentation (WMI) events in order to detect when new processes were launched on the system.
Another interesting section of the output showed SQL queries used by the application to log events:
This suggested that the application recorded monitored events into a database table named EventLog.
More importantly, the strings output revealed what appeared to be a hardcoded SQL Server connection string embedded directly in the binary:
This credential immediately stood out because it indicated that the application was authenticating to a SQL Server database named SecurityLogs using the account sqlsvc with the password TI0LKcfHzZw1Vv.
Given that a Microsoft SQL Server instance had already been identified earlier during the Nmap enumeration, these credentials appeared highly relevant. Hardcoded credentials in application binaries are a common weakness and often provide a direct entry point into backend services.
At this point, the discovery of the sqlsvc database credentials suggested a clear next step: attempting to authenticate to the SQL Server instance running on port 6520 using these credentials to determine whether access to the database could be obtained.
Credential Validation
After extracting the sqlsvc credentials from the overwatch.exe binary, I wanted to verify whether these credentials were valid within the Active Directory environment. A common first step is to test the credentials against SMB authentication to confirm whether the account can successfully log into the domain.
To do this, I used NetExec to attempt authentication to SMB and enumerate available shares using the discovered credentials.
The output confirmed that the credentials were valid, as NetExec successfully authenticated to the system as overwatch.htb\sqlsvc. Once authenticated, the tool enumerated the available SMB shares and displayed the permissions associated with each one.
The results showed that the sqlsvc account had read access to several shares, including NETLOGON, SYSVOL, and software$. These shares are commonly accessible to authenticated domain users, especially on domain controllers. However, administrative shares such as ADMIN$ and C$ remained inaccessible, indicating that the account did not possess elevated privileges on the system.
With valid domain credentials confirmed, I next attempted to determine whether the sqlsvc account could be used to obtain remote access via WinRM, since the service had been identified earlier on port 5985.
Although the authentication attempt was processed by the server, the login ultimately failed. This indicated that while the sqlsvc credentials were valid for domain authentication, the account did not have permission to log in via WinRM.
At this stage, the credentials were confirmed to be legitimate but limited in privilege. The next logical step was to continue enumerating services that might accept these credentials, particularly the Microsoft SQL Server instance previously identified on port 6520, as the credentials appeared to be associated with the database service.
MSSQL Authentication
After confirming that the sqlsvc credentials were valid within the domain, I proceeded to test them against the Microsoft SQL Server instance that had previously been identified running on port 6520. Since the credentials were extracted from the monitoring application binary and appeared to be associated with the database, there was a strong possibility that they would allow authentication to the SQL service.
To verify this, I used NetExec to authenticate to the MSSQL instance and execute a couple of queries to determine the current user context and privilege level.
The authentication attempt was successful, confirming that the sqlsvc credentials were valid for accessing the SQL Server instance. The first query returned the current authenticated user as:
This indicated that the login was being performed using Windows authentication, with the domain account sqlsvc mapped to the SQL Server session.
The second query checked whether the account belonged to the sysadmin server role, which is the highest privilege level within SQL Server. The result returned 0, indicating that the sqlsvc account was not a member of the sysadmin role and therefore did not have full administrative privileges on the SQL Server instance.
Although the account did not have sysadmin privileges, gaining authenticated access to the database was still significant. Authenticated SQL access can often provide opportunities for database enumeration, credential discovery, or privilege escalation depending on how the database is configured. With access confirmed, the next step was to begin exploring the available databases, tables, and stored procedures to identify potential avenues for further exploitation.
Domain User Enumeration
After confirming that the sqlsvc credentials were valid within the domain, I wanted to determine what level of visibility this account had inside the Active Directory environment. Even low-privileged domain accounts can often enumerate useful information, such as valid usernames, which can later be used for attacks like password spraying, Kerberoasting, or targeted authentication attempts.
To enumerate the domain users, I used NetExec against the SMB service while authenticating with the discovered credentials.
The authentication succeeded, confirming again that overwatch.htb\sqlsvc was a valid domain account. Once authenticated, NetExec was able to query the domain and enumerate the list of users.
The output returned a large number of domain accounts, including several built-in accounts such as:
- Administrator
- Guest
- krbtgt
These accounts are typically present in all Active Directory environments. The krbtgt account is particularly important because it is responsible for signing Kerberos tickets within the domain.
In addition to these default accounts, I observed several service-related accounts, including:
- sqlsvc
- sqlmgmt
The presence of sqlmgmt was especially interesting, as it appeared to be another account associated with the SQL Server environment.
The enumeration also revealed a large number of regular domain user accounts, many of which followed a consistent naming convention using first name and last name formats (e.g., Charlie.Moss, Tracy.Burns, Kathryn.Bryan, etc.). In total, the query returned 105 domain users within the OVERWATCH domain.
Having access to a complete list of domain users is valuable during an engagement because it allows for more targeted enumeration of authentication services such as Kerberos. With the usernames identified, the next logical step was to investigate whether any of these accounts were vulnerable to Kerberos-based attacks, such as AS-REP roasting, which could potentially expose password hashes for offline cracking.
LDAP Enumeration
After identifying the sqlmgmt account during SMB user enumeration, I wanted to gather more information about its privileges within the domain. Since I already had valid credentials for the sqlsvc account, I used them to query the LDAP service directly and inspect the group memberships of the sqlmgmt user.
In this command, I authenticated to the LDAP service using the sqlsvc credentials and searched the overwatch.htb directory for the account sqlmgmt. Specifically, I requested the memberOf attribute to determine which security groups the account belonged to.
The query returned a single entry corresponding to the sqlmgmt user:
From this result, I learned that sqlmgmt was a member of the Remote Management Users group. This group is particularly important because members are typically granted permission to remotely access systems using services such as WinRM.
This finding immediately stood out, especially since I had previously attempted to authenticate to WinRM using the sqlsvc account and the login had failed. The membership of sqlmgmt in the Remote Management Users group suggested that this account might have the necessary privileges to establish a remote management session on the server.
The remainder of the output consisted of LDAP search references pointing to other partitions in the Active Directory environment, such as ForestDnsZones, DomainDnsZones, and the Configuration container. These references are normal in Active Directory LDAP queries and simply indicate additional directory partitions that could be queried if needed.
At this stage, the key takeaway from the LDAP enumeration was that sqlmgmt appeared to have remote management privileges, making it a promising target account for further authentication attempts against services such as WinRM.
Reverse Engineering the Monitoring Application
After downloading the overwatch.exe binary from the SMB share and extracting some interesting strings earlier, I wanted to perform a deeper analysis of the application to understand its functionality and identify any potential security weaknesses. Since the executable appeared to be a .NET application, I decided to decompile it using ILSpy, which is a common tool for inspecting compiled .NET assemblies.
First, I installed the ILSpy command-line tool globally using the .NET CLI.
The installation completed successfully, allowing me to use the ilspycmd utility to decompile .NET binaries directly from the command line.
With the tool installed, I proceeded to decompile the overwatch.exe executable to inspect its source code.
The decompiled output revealed that the application was implemented as a .NET WCF (Windows Communication Foundation) service exposing several remote operations through an interface named IMonitoringService. This interface defined three callable methods:
- StartMonitoring()
- StopMonitoring()
- KillProcess(string processName)
These methods suggested that the application was designed to act as a monitoring service capable of tracking system activity and controlling running processes.
Looking deeper into the implementation, the StartMonitoring() function enabled monitoring by subscribing to Windows Management Instrumentation (WMI) events. Specifically, the service listened for process creation events using the query:
Whenever a new process started, the service logged the event to a database through the LogEvent() function. The database connection details were also visible in the code:
This confirmed the earlier discovery from the strings analysis, showing that the monitoring service was writing logs to a Microsoft SQL Server database named SecurityLogs using the sqlsvc account.
The LogEvent() method inserted event data directly into the database using dynamically constructed SQL queries. The service recorded details such as process start events and session switch events, which suggested that it was intended to track user activity on the system.
Another interesting component appeared in the KillProcess() method. This function constructed a PowerShell command:
The command was executed through a PowerShell runspace, allowing the service to terminate arbitrary processes on the system. Since the method directly concatenated the provided process name into the PowerShell command without validation, it hinted at a potential command injection vulnerability if an attacker could control the processName parameter.
Further analysis of the Program class revealed that the service was hosted using ServiceHost, confirming that it was running as a WCF service on the system. The application also included a scheduled task that executed every 30 seconds, checking the Microsoft Edge browsing history database and logging recently visited URLs into the SecurityLogs database.
Overall, the decompiled code provided a clear understanding of how the monitoring application worked. It confirmed the hardcoded SQL credentials, revealed the internal functionality of the service, and exposed a potentially dangerous method that executed PowerShell commands based on user-supplied input. These insights would become important when investigating the Monitoring service endpoint running on port 8000, which appeared to expose these functions remotely.
MSSQL Linked Server Enumeration
After successfully authenticating to the Microsoft SQL Server instance using the sqlsvc credentials, I continued enumerating the database environment to identify additional attack paths. One common technique when assessing SQL Server environments is to check for linked servers, as they can sometimes provide indirect access to other database servers within the network.
To enumerate any configured linked servers, I executed a query against the sys.servers system catalog.
The query executed successfully and returned two entries. The first entry corresponded to the local SQL Server instance:
This confirmed that the database service running on the host was an instance of SQL Server Express installed on the machine S200401.
More interestingly, the output also revealed a second entry:
This indicated that the SQL Server instance had a linked server configured for a remote host named SQL07. Linked servers allow a SQL Server instance to execute queries against external database servers, effectively acting as a bridge between database systems.
The discovery of a linked server is significant because it can sometimes allow query execution on remote database servers, depending on the configured permissions and trust relationships. In some cases, attackers can leverage linked servers to pivot laterally within the environment, potentially accessing additional systems or databases that would otherwise be unreachable.
At this stage, the presence of the SQL07 linked server suggested that the SQL Server instance might have connectivity to another database server within the network. The next logical step was to determine whether the current SQL login had permission to interact with this linked server, which could potentially open the door to further enumeration or lateral movement.
Exploiting the MSSQL Linked Server
Earlier, I discovered that the SQL Server instance had a linked server configured for a host named SQL07. Since SQL Server linked servers often authenticate automatically when attempting to connect, I attempted to abuse this configuration to capture authentication credentials.
My approach was to redirect the SQL07 hostname to my attacker machine and capture the authentication attempt using Responder.
Starting Responder
First, I started Responder on my VPN interface so it could listen for incoming authentication requests. Responder includes several modules capable of capturing credentials from different protocols, including an MSSQL listener.
The output confirmed that multiple responder services were active, including the SQL server module, which listens for incoming SQL authentication attempts.
Once Responder was running, I verified that the MSSQL listener was actively listening on port 1433, the default SQL Server port.
The output confirmed that the service was listening on port 1433 on my tun0 interface, meaning the Responder MSSQL module was ready to capture connections.
Adding a Malicious DNS Record
Since the SQL Server instance referenced the hostname SQL07 as a linked server, I attempted to redirect that hostname to my machine by adding a DNS A record in the Active Directory DNS server.
Using the sqlsvc credentials, I leveraged the DNSUpdate.py tool to add a DNS entry mapping SQL07 to my attacker IP address.
The request completed successfully, confirming that the DNS record had been added.
By doing this, any system attempting to resolve the hostname SQL07 within the domain would now resolve it to my attacker machine.
Capturing the Authentication Attempt
Once the DNS record was in place, the SQL Server instance attempted to connect to the linked server SQL07, which now resolved to my machine. Because Responder was already listening for SQL authentication attempts, it captured the incoming connection.
Responder displayed the following output:
This output revealed that the SQL Server instance attempted to authenticate to the linked server using the account sqlmgmt, and importantly, the authentication was transmitted in cleartext.
As a result, I successfully captured the credentials:
Reviewing Captured Credentials
After triggering the SQL Server authentication attempt through the malicious DNS record, Responder successfully captured credentials from the incoming MSSQL connection. Responder stores captured authentication data in log files for later review, so I inspected the MSSQL log file generated during the attack.
The contents of the log file confirmed that the SQL Server instance had attempted to authenticate to the fake SQL07 server using the sqlmgmt account. The credentials were captured in cleartext, revealing the password associated with that account:
The entry appeared twice because the server attempted to authenticate more than once during the connection attempt. The important takeaway was that the sqlmgmt credentials were successfully recovered:
This was a significant finding. Earlier during LDAP enumeration, I had discovered that the sqlmgmt account belonged to the Remote Management Users group. Members of this group are typically allowed to access systems remotely using services such as WinRM.
With valid credentials now available for this account, the next step was to attempt authentication against remote management services to determine whether these privileges could be used to obtain an interactive shell on the target system.
WinRM Authentication
After capturing the sqlmgmt credentials from the SQL Server authentication attempt, I wanted to verify whether this account could be used to obtain remote access to the system. Earlier LDAP enumeration had revealed that sqlmgmt was a member of the Remote Management Users group, which typically allows users to authenticate through WinRM.
To test this, I attempted to authenticate to the WinRM service running on the target system using NetExec.
The authentication attempt was successful. NetExec confirmed that the credentials were valid for the overwatch.htb domain and that the account had sufficient permissions to access the WinRM service on the host S200401.
The output also included the (Pwn3d!) indicator, which means that the authenticated account has privileges that allow remote command execution via WinRM.
This result confirmed that the sqlmgmt account could be used to establish a remote management session on the target system. With valid credentials and confirmed WinRM access, the next logical step was to use a tool such as Evil-WinRM to obtain an interactive PowerShell session on the machine and begin post-exploitation enumeration.
Gaining Initial Access via WinRM
After confirming that the sqlmgmt credentials were valid for the WinRM service, I attempted to establish an interactive remote session on the target system. Since WinRM provides remote PowerShell access on Windows systems, I used Evil-WinRM, a tool specifically designed for interacting with WinRM services during penetration tests.
The connection was successfully established, and I obtained a remote PowerShell session on the target machine S200401 under the context of the sqlmgmt user.
Once inside the system, I began by exploring the user’s home directory to locate any potentially interesting files.
This confirmed that I was operating inside the directory:
The directory contained the standard set of Windows user folders such as Desktop, Documents, Downloads, Pictures, and others.
Following the typical Hack The Box workflow, I navigated to the Desktop directory to check whether the user flag was present.
Inside the Desktop directory, I discovered a file named user.txt, which is commonly used in HTB machines to store the user flag.
To retrieve the flag, I displayed the contents of the file.
The command returned the following value:
Hurray!!! I got the user flag.
.gif)
This confirmed that I had successfully obtained the user flag, indicating that I had achieved initial access to the target system as the sqlmgmt user. The next step would be to begin post-exploitation enumeration in order to identify potential privilege escalation paths that could lead to administrator or SYSTEM-level access.
Privilege Escalation - Exploiting the Monitoring Service
After successfully retrieving the user flag as the sqlmgmt user, I began investigating potential privilege escalation vectors on the system. Earlier during enumeration and reverse engineering of the Monitoring application, I discovered that the service exposed a WCF endpoint running on port 8000 at:
Although this port was firewalled externally, it was still accessible locally from within the compromised machine. This meant that I could interact with the service from my WinRM session.
During the earlier code analysis, I also identified a vulnerable method named KillProcess, which constructed a PowerShell command by directly concatenating user-supplied input:
Because the processName parameter was not sanitized, it allowed command injection. By supplying input such as:
the command executed by the service would become:
Here:
aacts as a placeholder process name;separates PowerShell commands#comments out the remainder of the original command
This technique allows arbitrary PowerShell commands to be executed by the service.
Crafting the SOAP Exploit
To trigger the vulnerable method, I needed to send a SOAP request to the WCF service. From my Kali machine, I created a PowerShell script that constructs the required SOAP payload and sends it to the local service endpoint.
I inserted the following content into the file:
This script sends a SOAP request to the KillProcess method while injecting the command whoami into the PowerShell pipeline.
Hosting the Exploit Script
Next, I hosted the exploit script from my Kali machine using a simple HTTP server so the compromised system could download it.
The server started successfully and confirmed that the target machine requested the file:
Executing the Exploit from the Target Machine
Inside the WinRM shell, I changed my working directory to a writable location:
I then downloaded the exploit script from my Kali machine:
After the script was successfully downloaded, I executed it using PowerShell:
Confirming SYSTEM-Level Command Execution
The service responded with the following SOAP response:
The output revealed that the injected whoami command was executed as:
This confirmed that the Monitoring service was running with SYSTEM privileges and that the command injection vulnerability allowed arbitrary commands to be executed with the highest privilege level on the system.
With confirmed SYSTEM-level code execution, I could now use the same technique to execute additional commands and retrieve the root flag located at C:\Users\Administrator\Desktop\root.txt, completing the privilege escalation phase of the attack.
Retrieving the Root Flag
After confirming that the Monitoring service was vulnerable to command injection and that injected commands were executed as NT AUTHORITY\SYSTEM, the next step was to leverage the same technique to retrieve the root flag from the Administrator’s Desktop.
Since the service executes PowerShell commands with SYSTEM privileges, I crafted another SOAP payload that replaced the whoami command with a command that reads the root flag file.
From my Kali machine, I created a new PowerShell script named rootscript.ps1.
I inserted the following content into the file:
This script constructs a SOAP request similar to the previous exploit, but instead of executing whoami, it executes:
Because the vulnerable service runs as SYSTEM, it has sufficient privileges to read the Administrator’s files.
Hosting the Root Exploit Script
Next, I started a simple HTTP server on my Kali machine to host the script so it could be downloaded by the compromised system.
The HTTP server logs confirmed that the target machine requested the script:
Executing the Root Exploit
Inside the WinRM session, I downloaded the script to the target machine:
Once the file was successfully downloaded to C:\Windows\Temp, I executed it using PowerShell:
The SOAP response returned the contents of the root flag file within the KillProcessResult field:
Root Flag
Hurray!!! I got the root flag.
By exploiting the command injection vulnerability in the Monitoring service, I was able to execute arbitrary commands as NT AUTHORITY\SYSTEM, allowing me to read the Administrator’s root flag and complete the machine.
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Found this walkthrough helpful?
Buying me a coffee helps power the late nights spent writing technical walkthroughs and keeping them free for everyone ☕
Comment below the machine you want me to drop next!!! You can buy me a $25 coffee for a year premium subscription with a weekly release on every active machine [you will get the HTB write ups two days after each machines are released]
Keywords:
overwatch.htb
overwatch hack the box walkthrough
overwatch htb writeup
overwatch hackthebox exploit
overwatch htb privilege escalation
overwatch hack the box root flag
overwatch hack the box user flag
overwatch htb enumeration
overwatch hack the box exploit guide
overwatch Hack The Box Walkthrough | Step-By-Step HTB Writeup
overwatch Hack The Box Walkthrough | HTB Writeup
Just completed the HackTheBox "Overwatch" machine
hack the box linux machines
s200401.overwatch.htb -u 'sqlsvc' -p 'TI0LKcfHzZw1Vv'
hack the box windows machines
HTB Certified Web Exploitation Specialist (HTB CWES)
hack the box machines writeups 2025
I just pwned Overwatch on Hack The Box!
hack the box machines tutorial youtube
Overwatch Walkthrough Htb
Owned Overwatch from Hack The Box!
overwatch.htb S200401.overwatch.htb overwatch.htb0
hackthebox-writeups overwatch
Owned Overwatch from Hack The Box!
HTB Overwatch - PWNED!
HTB-Walkthroughs/Overwatch
HackTheBox - Overwatch Writeup
Overwatch - HTB Seasonal
ctf-writeups HTB Active Overwatch GitHub
HackTheBox - Machine - Overwatch
HackTheBox - Machine - AirTouch
HackTheBox - Machine - Browsed
"Overwatch" by Hack The Box - A "Medium" Windows Box Writeup
Owned Overwatch from Hack The Box!
Overwatch HTB machine
Hackthebox CTF writeups
Overwatch HackTheBox Overwatch machine writeup
Htb Overwatch
Overwatch Htb
hack the box machines security training lab
overwatch htb writeup
CTF #Overwatch #HTB
htb overwatch solution
overwatch hackthebox writeup
overwatch htb walkthrough
Hackthebox - Overwatch
overwatch.exe.config overwatch.htb
Hackthebox - Overwatch.exe
Overwatch - HTB Writeup
HackTheBox Overwatch - Windows Server 2022 box
Overwatch WriteUp - HackTheBox
HTB: Overwatch
overwatch HTB CBBH overwatch HTB CWES!
Overwatch HackTheBox Windows machine
Overwatch HTB box
0 Comments