This write-up documents my approach to solving the B3dr0ck room on TryHackMe — a Flintstones-themed challenge that focuses on TLS certificate mismanagement and privilege escalation through sudo misconfigurations.

What makes this room interesting from a security perspective is how it mirrors real-world scenarios: services exposing sensitive credentials over unprotected channels, improper certificate management, and overly permissive sudo configurations.

Phase 1: Enumeration

Every engagement starts with understanding the attack surface. I ran a full port scan using Nmap with the -p- flag to ensure nothing was missed.

nmap -sC -sV -p- <TARGET_IP>

Open ports discovered:

• 22, SSH, OpenSSH
• 80, HTTP, Nginx-redirects to 4040
• 4040, HTTP, Custom TLS web server (ABC)
• 9009, TCP, pichat-custom TCP service
• 54321, SSL, TLS-secured helper service

Port 80 immediately redirects to port 4040, which hosts a placeholder page for "ABC — Abbadabba Broadcasting Company." The page itself contained no actionable information — no hidden directories, no interesting source code, no forms.

Port 9009 stands out as unusual. A custom service named pichat running on a non-standard port is always worth investigating. And port 54321 appears to be an SSL/TLS service — but connecting to it requires client-side certificates, which we don't have yet.

With ports 80/4040 offering nothing useful and port 54321 requiring certificates, port 9009 became the obvious next target. When standard web services don't yield results, always explore the unusual ports.

Phase 2: Initial Foothold via Port 9009

Phase 2 — Initial Foothold via Port 9009

nc <TARGET_IP> 9009

This dropped me into an interactive chat service. Through interaction with this service, I discovered it was designed to provide TLS credentials — specifically, a client certificate and a private key.

Security Issue #1: Sensitive TLS credentials were being served over an unencrypted TCP channel with no authentication. In a production environment, this would be a critical vulnerability — anyone on the network could obtain valid client certificates.

I saved both files locally:

With these credentials in hand, I could now authenticate to the TLS service on port 54321 using socat:

socat stdio ssl:<TARGET_IP>:54321,cert=barney.cert.pem,key=barney.key.pem,verify=0

Connection successful. The service greeted me as an authorized user and offered a help menu. After testing several Linux commands (which were not supported — this was a restricted service, not a shell), I found that the service specifically provided login credentials and password hints.

I requested the password hint, which returned an MD5 hash associated with the user Barney Rubble.

Flag 1

Upon successful login, we land directly in barney's home directory. The first flag is right there (just cat it)

cat user_flag.txt

Phase 3 : Lateral Movement

After landing as Barney, the next objective was to move laterally to the second user account, Fred Flintstone.

I checked Barney's sudo permissions:

sudo -l

Barney could run /usr/bin/certutil as root. This is a custom binary on this machine (not the standard NSS certutil) that manages TLS certificates for the ABC service.

Therefore i use certutil to generate new TLS credentials for Fred, then use those credentials to authenticate to the TLS service on port 54321 and obtain Fred's SSH password — the same workflow I used for Barney.

The Rabbit Hole

My first attempt was to run:

sudo /usr/bin/certutil fred fred.flintstone

This generated a certificate and private key.

I saved them and attempted to connect via socat — but the credentials didn't work as expected. The service authenticated me, but with the wrong identity.

The lesson here was important: I had generated new credentials for a fabricated user, rather than retrieving Fred's existing credentials.

The Correct Approach

Going back to certutil, I listed the existing certificates.

sudo /usr/bin/certutil ls

This revealed the actual certificate files stored on the system. I extracted Fred's real private key and certificate from the existing store, saved them to local files.

After that i tried to connected again:

socat stdio ssl:<TARGET_IP>:54321,cert=fred.cert.pem,key=fred.key.pem,verify=0

This time, the service correctly identified me as Fred and provided his password hint.

Then I logged in via SSH:

ssh fred@<TARGET_IP>

Flag 2

We land directly in fred's home directory. Then capture the flag.

Security Issue #2: The certutil tool was executable with sudo privileges, allowing any user with this permission to read, generate, or manipulate certificates for any user on the system. This is equivalent to giving someone the keys to every lock in the building.

Phase 4: Privilege Escalation

With access as Fred, I again checked sudo permissions:

sudo -l

Fred had two interesting entries:

(ALL : ALL) NOPASSWD: /usr/bin/base32 /root/pass.txt (ALL : ALL) NOPASSWD: /usr/bin/base64 /root/pass.txt

This meant Fred could read /root/pass.txt — a file normally only accessible to root — by encoding it with base32 or base64. The NOPASSWD tag meant no password was required.

Exploitation

sudo /usr/bin/base64 /root/pass.txt

This output a base64-encoded string. However, decoding it didn't immediately reveal a password — it revealed another layer of encoding:

The final output was an MD5 hash. I submitted it to CrackStation, which returned the plaintext password for the root account.

su root

Security Issue #3: Allowing users to run encoding tools on sensitive files via sudo is a well-known privilege escalation vector. The base64/base32 commands effectively grant read access to any file specified in the sudo rule. This technique is documented on GTFOBins, a resource every security professional should bookmark.

Flag 3

You can grab the last flag at root directory.

Blue Team Perspective

This is where I want to bridge the gap between offensive and defensive security. This is what i think a blue team would flag.

1. Unencrypted Credential Service (Port 9009)

Network monitoring tools (Zeek/Suricata) should flag any service transmitting certificate material over unencrypted TCP. A SIEM rule matching on keywords like BEGIN CERTIFICATE or BEGIN RSA PRIVATE KEY in plaintext traffic would catch this immediately.

Never serve credentials over unencrypted channels. Use mutual TLS or at minimum require authentication before distributing certificates.

2. Unusual Socat/OpenSSL Connections

Endpoint Detection and Response (EDR) tools should alert on socat establishing outbound SSL connections, especially to non-standard ports. A SIEM correlation rule could flag:

socat process + SSL connection + non-443 port = investigate.

Application whitelisting to restrict which binaries can make network connections.

3. Sudo Abuse for File Reading

Audit logs (/var/log/auth.log) would show repeated sudo invocations of base64 and base32. A SIEM rule looking for "sudo + encoding utilities + sensitive file paths" is straightforward to implement.

Never grant sudo access to encoding/decoding tools on sensitive files. If file access is needed, use proper file permissions or dedicated access mechanisms.

4. Certificate Manipulation

Monitor certutil usage in audit logs. Any certificate generation or listing outside of scheduled maintenance windows should trigger an alert. Restrict certificate management tools to dedicated admin accounts with proper change management processes.

Thanks for reading! If you found this helpful, feel free to give it a clap and follow for more cybersecurity and tech content.