Hacker Holidays –Day 7 – Do Not Disturb

Bybwright

Category: Boot2Root
Difficulty: Medium
Platform: TryHackMe – Hacker Holidays 2026

Overview

The Do Not Disturb room begins with an unsettling Concierge Briefing and an equally mysterious comic. Both hint that active user sessions are being reused, unauthorized transactions are occurring, and someone else has already established a foothold inside the environment.

Rather than attacking a service blindly, this challenge rewards careful observation. Small clues point toward authenticated functionality, template rendering, exposed debugging services, and ultimately privilege escalation through the underlying operating system.

The objective wasn’t simply to gain a shell—it was to follow the same path the attacker had already taken.

Spoiler-Free Notice

This walkthrough focuses on methodology and defensive lessons learned. It intentionally omits both challenge flags.

Initial Enumeration

The Concierge Briefing immediately suggested several themes:

  • Existing authenticated sessions
  • Session cookies
  • Long-running authenticated users
  • Internal services
  • Shell access

Instead of brute forcing credentials, I began examining how authentication behaved.

Step 1 – Investigating Authentication

One of the first observations was that the application accepted unexpected input during authentication.

Example request:

curl -i -s \
  -c cookies.txt \
  --data 'username=<user>&password=<value>' \
  http://TARGET/login

After authenticating, I stored the session cookie for later requests.

curl -b cookies.txt http://TARGET/staff

What I learned

  • Authentication relied on a session cookie.
  • Authenticated requests could easily be replayed.
  • Session management became the foundation for the rest of the room.

Step 2 – Exploring the Staff Portal

The staff interface included functionality that rendered templates.

A simple mathematical expression confirmed that server-side template rendering was occurring.

Example test:

curl \
  -b cookies.txt \
  --data-urlencode "template=<%=7*7%>" \
  http://TARGET/staff/preview

Receiving the evaluated result confirmed that template expressions were executed by the server.

Why this mattered

Server-Side Template Injection (SSTI) can allow an attacker to execute arbitrary code if user input is rendered without proper validation.

Step 3 – Confirming Code Execution

Once template execution was confirmed, the next goal was determining whether operating system commands could be executed.

A simple identity command verified this.

Example:

id

This demonstrated that template execution had progressed into operating system command execution.

Step 4 – Establishing Interactive Access

Once command execution was confirmed, I established a reverse shell.

First, prepare a listener:

nc -lvnp 4444

After receiving the connection:

whoami
hostname
pwd

At this stage I had an interactive shell running as the application’s service account.

Step 5 – Internal Enumeration

Once inside the system, I shifted from external enumeration to internal reconnaissance.

Useful commands included:

id
whoami
hostname
pwd

Process discovery:

ps -ef

Listening services:

ss -tlnp

Mounted filesystems:

findmnt

These commands often reveal hidden attack paths that aren’t visible externally.

Step 6 – Discovering an Internal Debug Service

One of the more interesting discoveries was an internal debugging port.

Checking listening sockets:

ss -tlnp

Examining running processes:

ps -ef

The process list suggested that the application had been started with Node.js debugging enabled.

After identifying the port, I confirmed the debugger endpoint was reachable locally.

curl http://127.0.0.1:<debug-port>/json

This returned information describing the active debugging session.

Why this mattered

Leaving production debugging interfaces exposed is extremely dangerous.

Developer tooling often provides functionality that was never intended to be accessible after deployment.

Step 7 – Following the Attacker’s Trail

The room’s theme repeatedly hinted that someone else had already been here.

Instead of looking for another vulnerability, I followed the artifacts left behind:

  • active sessions
  • exposed debugging interfaces
  • long-running application processes
  • internal services
  • service account permissions

Each clue naturally led to the next stage.

Privilege Escalation

With sufficient local access established, attention shifted toward the underlying operating system.

Filesystem investigation became increasingly important.

Useful commands included:

findmnt
mount
lsblk

Understanding how the root filesystem was mounted ultimately led toward the final privilege escalation path.

Tools Used

ToolPurpose
curlInteracting with the web application
NetcatReverse shell listener
ssEnumerating listening sockets
psInspecting running processes
findmntIdentifying mounted filesystems
BashLocal enumeration

What I Learned

This room demonstrated several common security issues working together rather than relying on a single vulnerability.

Key takeaways included:

  • Never trust user input inside template engines.
  • Session management failures can become footholds.
  • Internal services deserve the same security controls as public ones.
  • Debug interfaces should never be exposed in production.
  • Thorough post-exploitation enumeration often reveals the intended privilege escalation path.

Defensive Considerations

Organizations can reduce the likelihood of this attack chain by:

  • Validating and sanitizing template input.
  • Disabling Node.js debugging outside development environments.
  • Restricting localhost services to only what is absolutely required.
  • Rotating session identifiers after authentication.
  • Monitoring for unusual template rendering activity.
  • Auditing long-lived authenticated sessions.

Cartoon Analysis

The included comic wasn’t just artwork—it acted as a roadmap.

Several panels foreshadowed the techniques used throughout the room:

  • “A session goes warm…” hints that authenticated sessions are central to the challenge.
  • “A wallet signs a transaction…” reinforces the idea of session hijacking or unauthorized actions.
  • “A shell on the beach answers back.” suggests gaining remote command execution.
  • “I’ll pull the authentication logs.” encourages investigating authentication artifacts rather than attacking blindly.
  • “Someone’s already inside.” perfectly captures the theme of following an attacker’s existing path instead of creating your own.

Key Takeaways

  • Begin by understanding how authentication works.
  • Carefully inspect every authenticated feature.
  • Confirm server-side behavior before attempting exploitation.
  • Enumerate thoroughly after gaining a foothold.
  • Internal debugging services can dramatically increase an attacker’s capabilities.
  • Read every hint—this room’s story and artwork directly guided the intended attack path.

https://tryhackme.com/room/hh-donotdisturb-84a45644

Similar Posts