Welcome to another Hack the Box walkthrough. In this blog post, I have demonstrated how I owned the Facts machine on Hack the Box. Hack The Box is a cybersecurity platform that helps you bridge knowledge gaps and prepares you for cyber security jobs.
About the Machine
Facts is an Easy Linux machine on Hack The Box that focuses on web application enumeration, CMS exploitation, cloud storage misconfigurations, credential harvesting, and privilege escalation through insecure system tooling. The machine demonstrates how multiple low-risk misconfigurations can be chained together to achieve full system compromise.
The attack begins with web enumeration, which reveals a Camaleon CMS-powered website along with accessible administrative endpoints. Further admin interface enumeration exposes a publicly accessible registration portal that allows user account creation. After gaining admin panel access, enumeration of backend functionality highlights weaknesses within user management features.
Through profile functionality enumeration, analysis of the password update mechanism reveals insecure parameter handling. During password update request analysis, parameter tampering enables privilege escalation by modifying role attributes. Logging back into the application confirms successful privilege escalation through expanded administrative interface access.
With administrative privileges established, vulnerability research leads to the discovery of CVE-2024-46987, a path traversal vulnerability affecting Camaleon CMS. Exploiting this flaw enables arbitrary file read exploitation, allowing retrieval of sensitive system files and local user enumeration.
Further investigation of backend configuration results in cloud storage credential discovery, revealing AWS S3 access keys stored within the CMS filesystem settings. Using these credentials enables AWS S3 enumeration, exposing internal storage buckets containing user home directory backups.
From the storage bucket, SSH key extraction yields a private key belonging to a local system user. After cracking the key passphrase, the credentials provide an initial foothold via SSH access to the host. Local enumeration then reveals sudo privileges for the facter utility, leading to privilege escalation enumeration.
Exploitation of facter’s custom fact loading functionality allows execution of arbitrary Ruby code as root. Through privilege escalation via facter custom fact injection, the attacker sets the SUID bit on the bash binary, ultimately obtaining full root access.
Overall, Facts is a well-structured machine that emphasizes the importance of secure role validation, proper handling of cloud credentials, and the risks associated with overly permissive sudo configurations. It provides a realistic attack chain that highlights how small security oversights across different system components can lead to complete compromise.
The first step in owning the Facts machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Once the connection between my terminal and Hack the Box server has been established, I started the Guardian machine and I was assigned an IP address 10.129.244.96.
Initial Enumeration
I began enumeration by performing a full TCP scan against the target to identify exposed services, service versions, and potential attack vectors. To achieve this, I ran Nmap with default scripts, version detection, and aggressive enumeration enabled:
The scan confirmed that the host was reachable and revealed two open TCP ports. Port 22 was running OpenSSH 9.9p1 on Ubuntu, indicating that SSH access was available on the system. The service exposed ECDSA and ED25519 host keys, both of which use modern cryptographic algorithms. Based on the service version alone, I did not identify any immediate vulnerabilities, which suggested that gaining SSH access would likely require valid credentials or key material obtained during later enumeration.
I also discovered that port 80 was open and running nginx 1.26.3, hosting a web application titled facts. Since web applications commonly provide entry points in HTB machines, I prioritized this service for further investigation. The HTTP server headers confirmed the application was hosted on an Ubuntu-based system, which aligned with the SSH service fingerprint.
Host Configuration
During enumeration, I noticed that the Nmap scan resolved the target IP address to the hostname facts.htb, indicating that the web application was likely configured to respond to requests directed at this domain. To ensure proper name resolution and avoid potential virtual host routing issues, I manually added the domain mapping to my local /etc/hosts file.
To accomplish this, I appended the target IP address and hostname using the following command:
This allowed my system to resolve facts.htb directly to the target machine. Configuring local DNS resolution is often necessary in CTF environments, as many applications rely on hostname-based routing and may not function correctly when accessed directly via IP address.
With the hostname properly configured, I proceeded with further enumeration of the web application using the facts.htb domain to ensure accurate interaction with the target service.
Web Enumeration
After confirming that the web service on port 80 was accessible, I proceeded with directory and file enumeration to identify hidden endpoints, application functionality, and potential attack surfaces. To accomplish this, I used Feroxbuster with a commonly used medium-sized directory wordlist:
The scan returned several valid endpoints that provided insight into the structure of the web application. Multiple accessible pages were discovered, including /search, /page, /sitemap, and /rss, which indicated that the application was likely content-driven and dynamically generated. Several article-style pages such as /first-impressions, /cute-animals, /anne-frank, and /dark-chocolate were also identified, suggesting the site was hosting blog-style or CMS-managed content.
While reviewing the results, I observed references to assets associated with Camaleon CMS, specifically within the /assets/themes/camaleon_first/ directory. The presence of these files strongly suggested that the target application was built using Camaleon CMS, which provided valuable context for potential vulnerability research and attack surface identification.
The enumeration also revealed that the /randomfacts/ directory returned a 403 Forbidden response. This indicated that the directory existed but access was restricted, making it a potential candidate for bypass attempts or deeper enumeration later in the assessment.
Most notably, Feroxbuster discovered the /admin endpoint, which redirected to /admin/login via an HTTP 302 response. The presence of an administrative login portal immediately stood out as a high-value target, as CMS administrative panels often become entry points through credential attacks, authentication bypasses, or CMS-specific vulnerabilities.
With confirmation that the target was running a CMS platform and an administrative login interface exposed, I prioritized further investigation of the application’s authentication mechanisms, accessible content, and potential CMS-specific vulnerabilities.
Admin Interface Enumeration
While continuing to enumerate the administrative functionality of the application, I navigated to the /admin/register endpoint by visiting:
Accessing this endpoint presented a user registration interface that allowed the creation of new accounts within the application. The registration form required personal information fields including first name, last name, and email address. In addition, the page requested authentication details such as a username and password, along with a CAPTCHA verification step designed to prevent automated registrations.
The presence of a publicly accessible administrative registration page immediately suggested the possibility of self-service account creation. In CMS-based applications, exposed registration portals can sometimes allow unauthorized users to create accounts with elevated privileges if role validation or access controls are improperly implemented.
Since authentication mechanisms often serve as entry points in web-based CTF challenges, I identified this functionality as a high-value target for further testing. I proceeded to analyze how user accounts were provisioned, whether role assignment could be manipulated during registration, and if the CAPTCHA or input validation mechanisms could be bypassed.
Admin Panel Access
After successfully creating a user account through the registration portal, I authenticated using the newly created credentials. Upon login, I was redirected to the administrative dashboard located at /admin/dashboard, confirming that account registration granted access to the backend management interface.
Once inside the admin panel, I began reviewing the interface to understand the underlying platform and identify potential attack vectors. During this inspection, I observed a footer banner displaying Camaleon CMS along with the application version number. The footer confirmed that the site was running Camaleon CMS version 2.9.0.
Identifying the CMS and its version was a significant finding, as it allowed me to shift enumeration efforts toward researching publicly known vulnerabilities, misconfigurations, or exploit chains associated with this specific version. CMS platforms frequently contain plugin ecosystems, file upload functionality, and administrative features that can introduce exploitable weaknesses.
With confirmation of the exact CMS version in use, I proceeded to investigate Camaleon CMS 2.9.0 for known vulnerabilities and potential exploitation paths that could lead to further access or remote code execution.
Profile Functionality Enumeration
After gaining access to the administrative dashboard, I continued enumerating available functionality within the backend interface. While reviewing the navigation options, I accessed the user dropdown menu located in the top-right corner of the dashboard and selected the Profile option. This action redirected me to the user profile management section of the application.
Navigating through profile-related functionality is an important enumeration step, as account management features frequently contain logic flaws, insecure input validation, or authorization weaknesses that can be leveraged for privilege escalation or credential manipulation.
From the profile page, I proceeded to the profile edit endpoint located at:
Upon accessing this page, I observed functionality allowing modification of user account details. Notably, selecting the Change Password option triggered a modal window prompting for a new password and confirmation input.
The presence of password modification functionality introduced a potential attack surface worth further investigation. Profile update and password reset mechanisms are commonly targeted during web application assessments, as they may expose vulnerabilities such as weak validation controls, insufficient authorization checks, or opportunities for parameter tampering.
Based on this discovery, I prioritized analyzing the password update workflow to determine whether it could be manipulated to affect other users, bypass security controls, or introduce privilege escalation opportunities.
Password Update Request Analysis
While reviewing the password change functionality, I decided to intercept the request using Burp Suite to better understand how the application handled profile update operations. I initiated a password change from the profile edit page and captured the request in Burp Suite before forwarding it to the Repeater tab for manual testing.
The intercepted request revealed that password updates were processed through the /admin/users/6/updated_ajax endpoint using a POST request. The request body contained parameters responsible for updating the password fields, including password[password] and password[password_confirmation], along with an authenticity token used for CSRF protection.
During inspection of the request structure, I noticed that user-related attributes were passed as nested parameters within the request body. This raised the possibility of parameter tampering, specifically targeting fields that might not be properly validated or restricted by the backend application.
To test this theory, I appended an additional parameter to the request body:
This modification attempted to assign the admin role to my account during the password update process. After adjusting the request and updating the content length accordingly, I sent the modified request through Burp Repeater.
The server responded with an HTTP 200 OK status and issued updated session cookies, indicating that the request had been successfully processed without triggering validation errors or authorization checks. The absence of input filtering or role enforcement suggested that the application accepted the manipulated parameter and applied it to the user account.
This behavior confirmed the presence of a parameter tampering vulnerability, allowing modification of user privilege levels through unauthorized request manipulation. By exploiting this flaw, I was able to elevate my account privileges beyond the originally assigned role.
With administrative privileges potentially obtained through this vulnerability, I proceeded to re-evaluate accessible functionality within the CMS backend to identify further exploitation opportunities.
Privilege Escalation Confirmation
To verify whether the parameter tampering attack successfully elevated my privileges, I logged out of the application and authenticated again using the same account credentials. Upon logging back into the administrative portal, I observed a significant change in the available interface functionality.
Previously, my account had limited access within the backend panel. After re-authentication, the navigation sidebar displayed several additional administrative modules, including Contents, Media, Comments, Appearance, Plugins, Users, and Settings. The presence of these sections confirmed that my account had been granted elevated privileges consistent with an administrator role.
Access to these administrative modules substantially expanded the attack surface of the application. In particular, sections such as Plugins, Appearance, and Media are commonly associated with file upload functionality, theme customization, and plugin management, which frequently introduce opportunities for code execution or configuration manipulation in CMS-based platforms.
This confirmed that the earlier request manipulation successfully resulted in privilege escalation. With administrative access now established, I proceeded to enumerate available backend features to identify functionality that could be leveraged for further exploitation.
Vulnerability Research
After confirming that the target application was running Camaleon CMS version 2.9.0, I shifted focus toward researching publicly disclosed vulnerabilities affecting this platform. Identifying the CMS version provided a valuable starting point, as CMS platforms frequently contain version-specific weaknesses that can be leveraged for further exploitation.
During this research phase, I discovered CVE-2024-46987, a vulnerability affecting Camaleon CMS. The vulnerability is classified as a Path Traversal flaw that allows authenticated users to perform arbitrary file reads through the application’s MediaController. Successful exploitation of this vulnerability can expose sensitive server-side files, including configuration files, credentials, and application secrets.
While reviewing available resources related to this vulnerability, I located a publicly available proof-of-concept (PoC) exploit hosted on GitHub. To prepare for testing the vulnerability against the target system, I cloned the repository to my local machine using the following command:
After cloning the repository, I navigated into the project directory and reviewed its contents:
The repository contained a Python script named CVE-2024-46987.py, along with a README file describing the exploit. The documentation confirmed that the PoC targets Camaleon CMS versions 2.8.0 through 2.8.2, but it also indicated that the exploit remains functional against version 2.9.0, which matched the version identified on the target system.
Since the vulnerability requires authenticated access and I had already obtained administrative privileges, the exploit presented a promising method for retrieving sensitive files from the server. With the PoC prepared locally, I proceeded to analyze the script and adapt it for use against the target environment.
Arbitrary File Read Exploitation
With the proof-of-concept exploit prepared locally and valid credentials already obtained, I proceeded to test whether the CVE-2024-46987 vulnerability was exploitable on the target system. Since the vulnerability allows authenticated users to perform arbitrary file reads via a path traversal flaw, I attempted to retrieve the contents of the system password file, which is commonly used to enumerate local users on Linux systems.
To perform this test, I executed the PoC script while supplying valid application credentials:
The exploit successfully returned the contents of the /etc/passwd file, confirming that the vulnerability was present and functioning on the target system. The output revealed multiple system and service accounts, which are typically expected on a Linux host. More importantly, the output also disclosed two regular user accounts: trivia and william.
The presence of these user accounts was particularly valuable, as valid local users often represent potential pivot points for gaining shell access or performing credential-based attacks. Additionally, the /etc/passwd file revealed that both accounts were associated with interactive shells, further indicating that they could be legitimate login users on the system.
This confirmed that the path traversal vulnerability could be leveraged to read sensitive server files, providing a reliable method for gathering reconnaissance data. With the ability to retrieve arbitrary files from the system, I proceeded to search for additional sensitive information, such as configuration files, credential stores, and application secrets that could facilitate further access.
Cloud Storage Credential Discovery
After confirming administrative access and successfully exploiting the file read vulnerability, I returned to the CMS backend to continue enumerating sensitive configuration data. Administrative panels frequently store integration credentials for external services, which can often be leveraged for lateral movement or data exfiltration.
While navigating through the admin interface, I accessed Settings → General Site and selected the Filesystem Settings tab. This section contained configuration details related to external file storage used by the CMS.
During this review, I discovered that the application was configured to store files using AWS S3. The configuration page exposed several sensitive credentials, including the AWS access key, secret key, and associated region. The settings also revealed the configured S3 bucket name and endpoint information, indicating that the CMS relied on cloud-based storage for handling uploaded content.
The exposure of AWS credentials represented a significant security weakness, as these keys could potentially grant access to cloud storage resources associated with the application. Cloud storage environments often contain user uploads, backups, application assets, or configuration files that may include additional sensitive information.
With valid AWS credentials identified, I proceeded to test whether the keys provided access to the associated S3 bucket and whether any sensitive data could be retrieved from the storage environment.
AWS S3 Enumeration
After discovering AWS credentials within the CMS filesystem configuration, I attempted to validate whether the keys granted access to the associated cloud storage environment. To do this, I configured the AWS CLI locally using the recovered credentials:
I supplied the exposed access key, secret key, and region obtained from the admin panel. Once configured, I attempted to enumerate available S3 buckets using the custom endpoint specified in the CMS configuration.
The command successfully returned two accessible buckets named internal and randomfacts, confirming that the credentials were valid and provided access to the storage service. The presence of an internal bucket was particularly interesting, as bucket names containing internal references often store sensitive application or system-related data.
To further investigate, I enumerated the contents of the internal bucket:
The listing revealed several directories and files commonly associated with a user home directory, including .ssh, .bundle, .cache, .bashrc, .profile, and other shell-related configuration files. The presence of an .ssh directory immediately stood out, as it often contains authentication keys that can potentially be used for SSH access.
The discovery of user environment files inside the storage bucket suggested that sensitive system data was being stored within the S3 environment. Since SSH configuration directories frequently contain private keys or authorized key files, this bucket represented a high-value target for further enumeration.
SSH Key Extraction
While enumerating the contents of the internal S3 bucket, I identified an .ssh directory containing an id_ed25519 file. Since SSH private keys frequently provide direct system access, I attempted to retrieve the file from the bucket using the AWS CLI:
The command successfully downloaded the private key to my local machine. Inspecting the file contents confirmed that it was an OpenSSH private key, which could potentially be used to authenticate to the target system.
Before attempting to use the key, I adjusted its permissions to meet SSH security requirements:
Ensuring proper file permissions is necessary because SSH clients refuse to use keys that are accessible by other users on the system.
SSH Key Cracking
After preparing the key, I attempted to use it for authentication but suspected that it might be protected with a passphrase. To verify this, I converted the SSH key into a crackable hash format using ssh2john:
With the hash generated, I used John the Ripper alongside the commonly used rockyou.txt wordlist to attempt passphrase cracking:
The cracking process completed successfully and revealed the passphrase associated with the SSH private key. The recovered passphrase was:
Successfully recovering the passphrase confirmed that the SSH private key could now be used for authentication attempts. With both the private key and its passphrase available, I prepared to test SSH access to the target system using the discovered credentials.
Initial Foothold
With the SSH private key and recovered passphrase available, I attempted to authenticate to the target system as the trivia user using the extracted key:
After supplying the cracked passphrase, authentication was successful, granting shell access to the target host. The login banner confirmed that the system was running Ubuntu 25.04 and verified that I had obtained a valid interactive session on the machine.
Once access was established, I began performing local enumeration within the trivia home directory to understand the user environment and identify potential privilege escalation paths. Listing the contents of the home directory revealed standard user configuration files along with directories such as .ssh, .cache, .bundle, and .local. Additionally, the .bash_history file was configured as a symbolic link to /dev/null, indicating that command history logging had been intentionally disabled.
To identify additional users on the system, I navigated to the /home directory and enumerated available user accounts:
The output revealed two user directories: trivia and william. Since privilege escalation between local users is common in CTF environments, I proceeded to enumerate the william directory to determine whether it contained accessible files.
Navigating into /home/william and listing its contents revealed several standard configuration files along with a file named user.txt. Notably, the file was owned by the root user but assigned to the william group. Despite this ownership, the file permissions allowed it to be read by the current user.
I accessed the file using:
The file contained the user flag, confirming successful initial access to the system and completion of the user-level objective.
Hurray!!! I got the user flag.
.gif)
With user-level access established, I continued enumerating the system to identify potential privilege escalation vectors that could lead to root-level access.
Privilege Escalation Enumeration
After obtaining user-level access as trivia, I began enumerating the system for privilege escalation opportunities. A common first step in local enumeration is checking whether the current user has permission to execute commands with elevated privileges via sudo. To perform this check, I ran:
The output revealed that the trivia user was permitted to execute the /usr/bin/facter binary as root without requiring a password. This immediately stood out as a potential privilege escalation vector, since binaries that can be executed with unrestricted sudo privileges often allow attackers to leverage functionality that results in arbitrary command execution.
To better understand how the binary functioned, I inspected its file type:
The result showed that the binary was actually a Ruby script rather than a compiled executable. Scripts executed with elevated privileges can sometimes be abused if they load external libraries, execute system commands, or rely on environment variables that can be manipulated.
To further analyze the script’s behavior, I reviewed its source code:
The script imported several Ruby modules and ultimately executed the CliLauncher.start() function, which processes user-supplied arguments. Since the script relies on external Ruby libraries, this raised the possibility that the script might be vulnerable to library loading manipulation or environment-based exploitation.
Given that the script was allowed to run with root privileges and relied on Ruby module loading, it became a strong candidate for privilege escalation through module hijacking or argument-based command execution. I proceeded to investigate how the script loaded dependencies and whether any of the required libraries could be manipulated to achieve code execution with elevated privileges.
Privilege Escalation via Facter Custom Fact Injection
Since the sudo -l output revealed that the trivia user could execute /usr/bin/facter as root without a password, I investigated how Facter processes external input. Facter supports loading custom facts from user-specified directories, which raised the possibility of injecting malicious Ruby code that would execute with elevated privileges.
To test this, I created a directory to host a malicious custom fact:
I then created a Ruby script that would act as a custom fact. The script was designed to execute a privileged command that sets the SUID bit on /bin/bash, allowing it to run with root privileges:
With the malicious fact prepared, I executed facter while specifying the custom directory containing the injected script:
The command successfully executed and returned the output custom_fact=exploited, confirming that the custom Ruby code was executed with root privileges.
To verify whether the payload executed successfully, I checked the permissions of /bin/bash:
The output showed that the SUID bit had been applied to the binary, indicating that it would now execute with root privileges regardless of the calling user.
I then launched a privileged shell using:
After spawning the shell, I confirmed that the privilege escalation was successful:
The command returned root, confirming full system compromise. I proceeded to access the root directory and retrieve the final flag:
Hurray!!! I got the root flag.
This confirmed successful privilege escalation to root and completion of the machine.
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Keywords:
Htb Writeup
HTB-writeups
Hack the Box (HTB) machines walkthrough series
HackTheBox - Facts Writeup
HackTheBox (MEDIUM) Machine [FACTS]
541 Virtual Machines | Learn To Hack
My writeups for Fact HTB machines and challenges
Facts box on HTB
Facts HTB Writeup
HTB Season 10 Episode 1 | Facts Easy Linux Machine | Tips & Review
HackTheBox Facts Writeup
HTB Business CTF Write-ups
HTB: Writeup - 0xdf hacks stuff - GitLab
HTB Season 10 Episode 1 | Facts Medium
chazapp/htb-writeups: My HackTheBox write ups
Hack the Box Write-ups | HTB Writeups
HackTheBox writeup
HTB-Facts
Owned Facts from Hack The Box!
Hack The Box - Season 10 HTB Facts Writeup - Easy - Weekly
Writeup (Easy)
Writeup (Medium)
Writeup (Hard)
Writeup (Insane)
HackTheBox "Facts" Walkthrough
Mastering Facts: Beginner's Guide from HackTheBox
HTB Season 10 - Ibrahim Isiaq Bolaji
HTB-writeup
Write-ups Category Posts | Hack The Box Blog
HackTheBox Facts Writeup
Hack The Box :: Forums
htb 16. HackTheBox Facts Writeup HackTheBox Facts Writeup HackTheBox eighteen Writeup HackTheBox AirTouch Writeup
Facts HTB
facts HTB Writeup
Hack The Box (HTB) Write-ups Repository
HTB write-ups with detailed walkthroughs, screenshots, and tutorials for ethical hacking, CTF challenges, and penetration testing.
HTB | facts| Walkthrough
HackTheBox Writeup - Player - Ibrahim Isiaq Bolaji - Medium
Streaming / Writeups / Walkthrough Guidelines
facts HTB Writeup - Ibrahim Isiaq Bolaji
Hackplayers/hackthebox-writeups
#hackthebox #giveback #htb #ctf #hacking | Ibrahim Isiaq Bolaji
facts Writeup (HackTheBox Medium Machine) previous.htb giveback.htb eighteen.htb eighteen walkthrough
Offsec Hack The Box
hackthebox-writeups
HTB-writeups. Writeups of HackTheBox retired machines
HTB Facts Writeup. BOX SUMMARY | by Ibrahim Isiaq Bolaji
Facts HTB Writeup
HackTheBox Facts Writeup
My WriteUps for HackTheBox CTFs, Machines, and Sherlocks
My write up for the recently retired HackTheBox machine
htb-fact-writeup - HackTheBox
Facts HTB Writeup
hackthebox-writeups "pwned" on the CTF-like platform, HackTheBox. security hacking penetration-testing pentesting redteam
Facts Hack The Box machine
ctf-writeups
Facts Hack the Box Walkthrough
Facts HTB Walkthrough
Facts Hack the Box Writeup
Facts HTB Writeup
facts htb complete solution
facts hack the box complete writeup pdf
facts hack the box Linux machine
facts htb
0 Comments