Epsilon
Detailed Walkthrough
Initial Access
Upon establishing a connection to the VPN, the tester initiated the assessment by performing a service enumeration. This process revealed the following open ports:
22/tcp open OpenSSH 8.2p1
80/tcp open Apache httpd
5000/tcp open Werkzeug Python 3.8.10
The tester navigated to http://epsilon.htb:5000/ and accessed a custom application named Epsilon Costume Shop, which provided an authentication form.
On the other hand, http://epsilon.htb/ uncovered a website that was restricted from access returned a Forbidden.
As part of the enumeration, the tester proceeded to ran Feroxbuster tool revealing a new available paths for enumeration.
By Followig /track endpoint, this exposes an internal tracking function, but it currently lacks authentication and is therefore unusable.
During enumeration of http://epsilon.htb/, a .git folder was found, providing the ability to dump the repositories and server configuration files, revealing valuable insights into the backend logic.
Using git_dumper, the .git repository was dumped, allowing successful extraction of two internal Python scripts from the application, providing insight into its backend logic and configuration.
File: server.py: Flask Server configuration including all the paths and authentication process without secret that is utilized to create the authentication access cookie.
File: track_api_CR_148.py: AWS Lambda to create a zip files which exposed a new subdomain
cloud.epsilon.htbwithoutaws_access_key_idoraws_secret_access_key
Reviewing the repository’s commit history showed that the first commit had hardcoded AWS credentials (aws_access_key_id and aws_secret_access_key), exposing sensitive information that could be leveraged for further exploitation.
After recovering and configuring the AWS credentials, the aws CLI was used against the internal endpoint to enumerate Lambda functions.
While enumerating costume_shop_v1, a ZIP archive was retrieved that contained the hardcoded secret from server.py. With this secret a valid JWT session cookie could be crafted, allowing immediate impersonation of the admin account.
File: lambda_function.py
Once the auth cookie was set, the application granted access to administrative functionalities.
During enumeration, it was observed that the costume field from processed orders was reflected in the web application, making the endpoint susceptible to Server‑Side Template Injection (SSTI).
The request was intercepted with Burp Suite, confirming that the costume parameter was user‑controlled.
The tester crafted a payload and sent it, which resulted in remote code execution and compromise of the server.
SSTI Payload:
Privilege escalation
During privilege‑escalation, pspy was used to monitor system activity and revealed a root‑executed cron job invoking /usr/bin/backup.sh.
The script was designed to create a backup of /var/www/app/ in /opt/backups/, generate a checksum, wait 5 seconds, and then create a final archive containing the application backup and the checksum in /var/backups/web_backups/. The use of tar with the -h (dereference) option made the process vulnerable to local privilege escalation via symbolic‑link manipulation.
The tester replaced the checksum with a symbolic link pointing to /root, waited for the cron job to run, and copied the produced backup archive to /dev/shm. After extracting the archive and setting proper permissions on the recovered private key, the tester used it to SSH into the host as root, resulting in full system compromise.
Credentials
👤 Users wordlist
🔑 Password wordlist
Subdomains / Hosts
cloud.epsilon.htb
10.10.11.134
host a lambda function.
Host Discovered
Epsilon
10.10.11.134
Scans
Scripts / Automations
track_api_CR_148.py
Server.py
Privilege Escalation script
Flag Discovered
User
10.10.11.134
tom
SSTI
<SNIF>
Root
10.10.11.134
root
Local Privilege escalation via Symbolic Links
<SNIF>
Last updated