About the Machine
Guardian is a Hard Linux machine on Hack The Box that focuses on chaining multiple realistic web application and system misconfigurations to achieve full compromise. The machine simulates a university management portal environment where attackers must carefully pivot through web vulnerabilities, credential exposure, and privilege escalation techniques. Initial access begins with web application enumeration, where reconnaissance reveals an Apache-hosted university website that redirects users to a dedicated student portal. Further inspection leads to subdomain discovery, identifying additional internal services including the student portal and development resources.
Authentication to the portal is achieved through credential discovery via help documentation, where default login credentials are disclosed in publicly accessible support materials. Once authenticated, the attack path progresses through an Insecure Direct Object Reference (IDOR) vulnerability within the chat functionality, allowing enumeration of user conversations by manipulating ID parameters. This results in credential leakage via IDOR-exposed chat logs, providing access to internal service credentials and enabling attackers to authenticate to an internal Gitea source code repository.
Code review within Gitea reveals database credential disclosure in application source files, as well as the use of a vulnerable third-party dependency (PhpSpreadsheet v3.7.0). Exploiting improper input sanitization in sheet name handling enables stored Cross-Site Scripting (XSS), which is leveraged to perform session hijacking and privilege escalation by capturing privileged session cookies. Further application weaknesses are identified through improper CSRF token handling, allowing attackers to force administrative actions such as account creation.
With administrative access obtained, the attack continues through Local File Inclusion (LFI) enumeration, ultimately leading to Remote Code Execution (RCE) via a crafted php://filter chain payload. This provides shell access to the server and allows attackers to enumerate sensitive configuration files and database credentials stored locally. System-level enumeration reveals insecure file permissions within utility scripts, enabling privilege escalation via writable Python module injection. Finally, full system compromise is achieved through a misconfigured administrative utility, resulting in root privilege escalation via a custom Apache control script that permits arbitrary configuration injection and SUID binary creation.
Overall, Guardian is a technically demanding machine that demonstrates the importance of secure development practices, proper dependency management, access control enforcement, and privilege separation. It highlights how multiple seemingly minor vulnerabilities can be chained together to transition from external web access to complete root-level compromise in a realistic enterprise environment.
The first step in owning the Guardian 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.237.248.
Initial Enumeration
To identify the exposed services and gain an overview of the target system, I started with a full TCP port scan using Nmap:
The scan revealed that the host was reachable and responsive, with only two TCP ports open, indicating a limited external attack surface. The majority of ports were closed, suggesting the system was intentionally configured to expose only essential services.
Port 22/tcp was running OpenSSH 8.9p1 on an Ubuntu system. While no immediate vulnerabilities were identified from banner information alone, the presence of SSH indicated a potential access vector later in the attack chain if valid credentials could be obtained.
Port 80/tcp was running Apache httpd 2.4.52. Accessing the web service via the IP address resulted in an HTTP redirect to http://guardian.htb/, indicating that the application is configured using name-based virtual hosting. This suggested that further web enumeration would require mapping the hostname locally before meaningful interaction with the application could take place.
At this stage, the attack surface was clearly defined: a web application reachable through a virtual host configuration and an SSH service likely intended for post-exploitation access. Based on this information, the next step was to add guardian.htb to the local hosts file and proceed with focused web enumeration.
Hostname Resolution
Since the web service on port 80 redirected traffic to a hostname rather than serving content directly from the IP address, it was necessary to resolve the virtual host locally. To achieve this, I manually mapped the target IP address to the hostname identified during initial enumeration.
This entry ensured that requests to guardian.htb would be correctly resolved to the target system, allowing the web application to be accessed as intended. With hostname resolution in place, the web service could now be interacted with normally, enabling further enumeration of the application and its underlying functionality.
At this point, the environment was correctly configured for focused web application testing against guardian.htb, making it possible to proceed with directory enumeration and manual inspection of the site.
Web Application Enumeration
With hostname resolution configured, I navigated to the web application by visiting http://guardian.htb in the browser. The site presented itself as a public-facing university website branded as Guardian University, suggesting a deliberately realistic front-end intended to blend in as a legitimate academic portal.
The landing page exposed several publicly accessible sections, including About, Programs, Testimonials, and Contact, all of which appeared to be informational and static in nature. Initial interaction with these pages did not reveal any obvious input fields, dynamic parameters, or client-side functionality that could be directly abused.
While enumerating the content, several email addresses following a consistent format (e.g., GUxxxxxxxx@guardian.htb) were visible within the Student Testimonials section. This hinted at a structured internal user naming convention and suggested the possible existence of authenticated users behind the platform.
Most notably, the navigation bar included a Student Portal button, indicating a separate authenticated area distinct from the public-facing site. Given the lack of interaction points on the main pages, this portal stood out as the most promising attack vector and became the primary focus for further enumeration.
At this stage, the web application appeared intentionally benign on the surface, with the real functionality likely gated behind authentication. The next step was therefore to investigate the Student Portal endpoint more closely to identify potential weaknesses in access control or authentication logic.
Subdomain Discovery
While interacting with the main website, I inspected the Student Portal button more closely to understand where it redirected. Hovering over the link revealed that it pointed to a separate hostname, portal.guardian.htb, indicating that the student portal was hosted on a distinct virtual host rather than under the main domain.
To confirm this, I reviewed the page source and HTML structure, which explicitly referenced the same hostname within the footer links. This validated that portal.guardian.htb was an intended and reachable subdomain rather than a client-side artifact.
Since the application relies on name-based virtual hosting, I mapped the newly discovered hostname to the target IP address locally to ensure proper resolution.
With the hostname resolved, the student portal could now be accessed directly via the browser. The presence of a dedicated subdomain for authenticated users suggested a clear separation between the public-facing site and internal functionality, making portal.guardian.htb the most promising target for further enumeration.
At this point, focus shifted from the static university landing pages to the student portal, where authentication mechanisms and application logic were expected to reside.
Student Portal Authentication
After resolving the student portal subdomain, I navigated directly to http://portal.guardian.htb, which immediately redirected to a login endpoint located at /login.php. This confirmed that access to the portal was gated behind an authentication mechanism.
The login page presented a standard credential form consisting of username and password fields, accompanied by a prompt instructing users to authenticate using their student credentials. Notably, the username input field included a placeholder indicating the expected format: GUXXXXXXX. This provided valuable insight into the internal user identification scheme used by the application.
The presence of a defined username structure, combined with previously observed email patterns on the public-facing site, suggested that valid student identifiers follow a predictable naming convention. This significantly narrowed the scope of potential usernames and hinted at opportunities for targeted authentication testing rather than blind brute force attempts.
At this stage, the application exposed a clear authentication boundary. With both the login endpoint and expected credential format identified, the next step was to analyze the login behavior more closely to determine how credentials were validated and whether any weaknesses existed in the authentication logic.
Credential Disclosure via Help Documentation
While examining the student portal login page, I followed the Help hyperlink to identify any supporting documentation that might reveal additional information about the authentication process. This link redirected to a publicly accessible PDF located at:
Reviewing the contents of the document revealed critical authentication details intended for first-time users. In the Important Login Information section, the guide explicitly stated that all student accounts are provisioned with a default password of GU1234, which users are expected to change after their initial login.
This immediately represented a serious security misconfiguration, as the document was accessible without authentication and disclosed valid credentials. Combined with the predictable student ID format identified earlier, this allowed for direct authentication attempts using known user identifiers.
Using one of the student IDs previously observed in the Student Testimonials section of the public-facing website, I attempted to authenticate to the portal with the default credentials:
- Username: GU0142023
- Password: GU1234
The login was successful, confirming that the account was still using the default password and that no additional safeguards (such as forced password rotation or account lockout) were enforced on first login.
At this point, initial access to the student portal was achieved. With authenticated access established, the next step was to enumerate the portal’s internal functionality to identify opportunities for further privilege escalation or lateral movement.
Insecure Direct Object Reference (IDOR) in Chat Functionality
After successfully authenticating to the student portal, I was redirected to the dashboard at /student/home.php, confirming that I had valid session access as a standard student user. From the sidebar, I navigated to the Chats section to explore any interactive functionality available to authenticated users.
Upon opening a chat, I noticed that the application passed user identifiers directly through URL parameters:
This immediately stood out as a potential Insecure Direct Object Reference (IDOR) vulnerability. The application appeared to rely solely on client-supplied user IDs to determine which chat conversation to load, with no visible indication of server-side authorization checks. Since I was already authenticated, I hypothesized that iterating over these numeric identifiers might expose conversations between other users.
To test this, I first confirmed that my session was maintained using a PHPSESSID cookie, which would need to be included in any automated requests. I then generated a small numeric wordlist to represent possible user IDs:
Next, I used ffuf in clusterbomb mode to brute-force combinations of chat_users[0] and chat_users[1], ensuring the authenticated session cookie was sent with each request. I also filtered responses by line count to remove empty or default pages.
The scan quickly returned valid responses for multiple ID combinations, most notably:
and the reverse pairing:
These results confirmed that the application did not enforce proper access controls on the chat endpoint. Any authenticated user could enumerate arbitrary chat conversations simply by modifying the user ID parameters in the URL, granting unauthorized visibility into private communications between other students.
At this stage, the vulnerability was clearly identified as an IDOR in the chat system, enabling horizontal privilege abuse. The next step was to inspect the exposed chat contents to determine whether sensitive information or credentials could be leveraged for further escalation.
Credential Leakage via IDOR-Exposed Chat Logs
With the IDOR vulnerability in the chat functionality confirmed, I manually navigated to one of the valid parameter combinations identified earlier by modifying the URL directly:
This request successfully loaded a private conversation between two users that I was not authorized to access. The chat messages revealed a critical security oversight: an administrator had shared credentials directly through the messaging system.
Within the conversation, a user labeled admin provided a plaintext password for an internal service:
The recipient of the message was identified as jamil.enockson, whose reply confirmed the legitimacy of the conversation and validated that the credentials were active. Given the earlier enumeration of email address formats used across the platform, it was reasonable to infer that the corresponding username for this service followed the standard email convention.
At this point, valid credentials for an internal Gitea service were obtained:
- Username: jamil.enockson@guardian.htb
- Password: DHsNnk3V503
This confirmed a clear attack path from low-privileged student access to internal developer infrastructure via credential reuse and poor access control. The next step was to locate and access the Gitea instance to determine whether these credentials could be leveraged for further compromise of the system.
Accessing Internal Gitea Service
After obtaining valid credentials from the exposed chat logs, the next step was to locate the internal Gitea service referenced in the conversation. Based on the naming conventions used across the environment, I inferred that the service was hosted on a dedicated subdomain.
To resolve the service locally, I added the following entry to the hosts file:
With hostname resolution in place, I navigated to http://gitea.guardian.htb and attempted authentication using the previously recovered credentials:
- Username: jamil.enockson@guardian.htb
- Password: DHsNnk3V503
The login was successful, confirming that the credentials had been reused across services and that no additional access restrictions were enforced for internal infrastructure.
Once authenticated, I was presented with the Gitea dashboard, which contained multiple repositories related to the Guardian University web applications. At the bottom of the page, the application version was identified as Gitea 1.23.7. A review of publicly known vulnerabilities for this version did not reveal any immediately exploitable issues.
Additionally, an admin user account was visible within the platform, indicating the presence of higher-privileged users managing the repositories. This suggested that further opportunities for escalation might exist through source code analysis, repository misconfigurations, or credential disclosure rather than direct exploitation of the Gitea service itself.
At this point, the focus shifted from service exploitation to source code review, as access to internal repositories often exposes hardcoded credentials, misconfigurations, or deployment secrets that can be leveraged for further compromise.
Database Credential Disclosure in Source Code
With authenticated access to the internal Gitea instance, I began reviewing the available repositories to identify any sensitive configuration data. One repository of particular interest was Guardian/portal.guardian.htb, which appeared to contain the full source code for the student portal application.
While browsing the repository, I navigated to the application’s configuration file located at:
This file contained hardcoded database connection details used by the portal. The credentials were stored in plaintext within the source code:
This represented a critical security issue, as the database was being accessed using the root account rather than a restricted service user. Additionally, the presence of a static application salt value in the same file suggested that other cryptographic operations, such as password hashing or session handling, might also be improperly managed.
At this point, full database credentials had been obtained directly from source control, enabling direct interaction with the backend database. Given that the database user was root, this opened the door to extracting sensitive user data, modifying application logic at the data layer, or potentially escalating access beyond the web application itself.
With valid database credentials in hand, I can connect to the MySQL service locally and enumerate the database for further exploitation opportunities.
Vulnerable Third-Party Dependency Identified
Continuing the source code review within the Guardian/portal.guardian.htb repository, I inspected the application’s dependency configuration to identify any third-party components that could introduce additional attack vectors.
The dependency list was defined in the composer.json file, located at:
Reviewing this file revealed that the application relies on the PhpSpreadsheet library:
This immediately stood out, as PhpSpreadsheet version 3.7.0 is known to be affected by documented security vulnerabilities related to improper handling of user-supplied spreadsheet data. Applications using this library without strict input validation can be exposed to attacks such as arbitrary file reads or remote code execution, depending on how spreadsheet uploads or parsing are implemented.
The presence of this outdated dependency suggested that the portal likely includes functionality for handling spreadsheet files (e.g., grades, assignments, or reports) and that this feature could potentially be abused to achieve further compromise.
Vulnerability Research on PhpSpreadsheet
After identifying PhpSpreadsheet 3.7.0 as a dependency used by the portal application, I performed targeted vulnerability research to determine whether this version introduced any exploitable weaknesses.
A review of publicly available advisories revealed that PhpSpreadsheet is affected by multiple security vulnerabilities, particularly related to Cross-Site Scripting (XSS). Several CVEs have been disclosed affecting spreadsheet parsing and rendering logic, including but not limited to:
- CVE-2024-56366
- CVE-2024-56408
- CVE-2024-56409
- CVE-2024-56410
- CVE-2024-56411
- CVE-2024-56412
Many of these issues stem from improper sanitization of user-controlled input embedded within spreadsheet cells or metadata fields. When such files are processed and rendered by the application, malicious payloads can be executed in the context of authenticated users.
This finding was particularly significant given the portal’s functionality, which includes handling academic data such as grades, assignments, and reports - features that commonly rely on spreadsheet uploads or exports. If any user-supplied spreadsheet content is parsed using this vulnerable library, it could allow an attacker to inject malicious scripts that execute within privileged user sessions.
Identifying a File Upload Attack Surface
With the objective of obtaining an administrator session token, I returned to the student portal to look for functionality that could be abused to execute client-side payloads in a privileged user’s browser.
While reviewing the available features, I navigated to the Assignments section at:
This page allowed students to view coursework details and, more importantly, upload assignment files. The upload functionality explicitly accepted .docx and .xlsx file formats, which immediately aligned with the previously identified use of the vulnerable PhpSpreadsheet library.
The presence of an upload mechanism capable of handling spreadsheet files confirmed that user-controlled content was being parsed and processed server-side using a known vulnerable dependency. Given the documented XSS issues affecting PhpSpreadsheet, this upload feature represented a direct and practical attack vector.
This discovery marked the transition from reconnaissance to active exploitation, with the file upload feature serving as the bridge to compromise a higher-privileged account.
Stored XSS via PhpSpreadsheet Sheet Name Handling
After confirming that the portal application relies on PhpSpreadsheet v3.7.0, I examined the publicly disclosed security advisories for this library to identify an exploit path relevant to the file upload functionality discovered earlier.
A review of the official PhpSpreadsheet security advisory revealed a stored Cross-Site Scripting (XSS) vulnerability affecting versions prior to the patched releases. The issue is documented in the following advisory:
The vulnerability exists in the component responsible for converting uploaded XLSX files into an HTML representation for display. When a spreadsheet contains multiple sheets, the library dynamically generates a navigation menu listing each sheet name. Crucially, these sheet titles are inserted directly into the HTML output without proper sanitization.
As shown in the vulnerable logic, the sheet title is rendered verbatim:
Because $sheet->getTitle() can be fully controlled by the attacker through the spreadsheet file, this allows arbitrary JavaScript to be injected into the rendered page. When the processed spreadsheet is later viewed by another user such as an administrator - the malicious payload executes in their browser context.
This behavior aligns perfectly with the previously identified assignment upload feature, which accepts .xlsx files and processes them using the vulnerable library. By embedding a JavaScript payload into a spreadsheet sheet name and uploading it as an assignment, it becomes possible to achieve stored XSS, targeting any privileged user who reviews the submission.
Exploiting Stored XSS via Malicious XLSX Upload
With a confirmed stored XSS vulnerability in PhpSpreadsheet and a valid upload vector accepting .xlsx files, the next step was to weaponize the assignment submission feature to steal an administrator session cookie.
To craft a malicious spreadsheet, I used FastSheet, a browser-based Excel editor capable of exporting valid XLSX files. I created a spreadsheet containing multiple sheets, as required to trigger the vulnerable navigation rendering logic. One of the sheet names was deliberately crafted to include a JavaScript payload.
The payload was embedded directly into the sheet name, taking advantage of the fact that PhpSpreadsheet renders sheet titles into HTML without sanitization:
This payload causes the browser to issue an HTTP request to my attacking machine whenever the spreadsheet is rendered, exfiltrating the victim’s cookies via a Base64-encoded query parameter.
After renaming the sheet and exporting the spreadsheet, I returned to the Assignments section of the portal and submitted the malicious XLSX file as part of an assignment submission. At this point, the payload was stored server-side and awaited execution by a privileged user.
You should get a notification message that your assignment has been submitted successfully.
To capture incoming requests, I started a simple HTTP server on my attacking machine:
After a short delay, the server received an inbound request originating from the target system:
This confirmed that the spreadsheet had been processed and rendered most likely by an administrator reviewing submitted assignments and that the JavaScript payload had executed successfully in their browser context.
The c parameter contained the Base64-encoded session cookie. Decoding the value revealed the stolen session identifier:
Output:
At this stage, a valid administrator PHP session ID had been obtained. This completed the stored XSS attack chain, enabling full session hijacking and privilege escalation to an administrative user.
Session Hijacking and Privilege Escalation
After successfully extracting a valid PHPSESSID from the stored XSS payload, the next step was to determine whether this session belonged to a higher-privileged user.
Using the stolen session identifier:
I navigated back to the student portal and opened the browser’s developer tools. Under the Cookies tab for portal.guardian.htb, I manually replaced my existing session cookie with the newly obtained value.
Once the cookie was updated, I refreshed the page. Upon reload, the application immediately redirected from the student dashboard to:
The interface changed accordingly, revealing the Lecturer Dashboard, and the greeting confirmed the authenticated identity as sammy.treat. This behavior confirmed that the stolen session token belonged to a lecturer account and that the application failed to bind sessions to specific users or enforce additional validation checks.
At this point, full lecturer-level access had been achieved purely through session hijacking, completing the privilege escalation chain from a low-privileged student account to a higher-privileged lecturer account without requiring credentials.
Lecturer Access and Notice Board Analysis
After successfully hijacking a valid lecturer session, I gained access to the Lecturer Dashboard as sammy.treat. With elevated privileges compared to a student account, I proceeded to enumerate the available lecturer-only functionality, focusing on areas where administrator interaction was required.
One notable feature was the Notice Board section, which allowed lecturers to create notices that would later be reviewed and viewed by an administrator. Navigating to the notice creation page revealed an input field labeled “Reference Link (will be reviewed by admin)”, immediately suggesting a potential client-side injection vector.
Since the administrator is expected to manually review submitted notices, this functionality represents a high-value target for stored or reflected XSS attacks aimed at privileged users.
To better understand how administrator actions were handled, I pivoted back to the application’s source code available in Gitea and inspected the relevant admin functionality.
Admin Functionality Review
Reviewing portal.guardian.htb/admin/profile.php showed that access to the admin profile page is strictly gated by session-based role checks:
This confirms that any session carrying the admin role is trusted implicitly, making session hijacking or privilege escalation particularly impactful.
Further inspection of portal.guardian.htb/admin/createuser.php revealed more critical functionality. This endpoint allows administrators to create new users and arbitrarily assign roles, including administrative privileges. Passwords are hashed using a static application-wide salt retrieved from config.php, and user creation is only protected by a CSRF token mechanism.
Notably, the password change logic in profile.php is effectively non-functional, meaning that account management and privilege escalation primarily revolve around the user creation workflow, not password resets.
CSRF Token Weakness
The CSRF protection mechanism is implemented in config/csrf-tokens.php. Tokens are generated, stored globally in a JSON file, and validated using a simple in_array() check. Tokens are never invalidated after use, nor are they bound to a specific session or user context.
This design significantly weakens the protection and allows any previously generated token to be reused indefinitely.
Back to the Lecturer portal, I moved laterally to the Notice Board functionality to look for additional attack surfaces. From the Lecturer Dashboard, I noticed that lecturers are allowed to create notices that include a “Reference Link (will be reviewed by admin)” field. This immediately stood out as a potential client-side attack vector, since the link would eventually be opened by an administrator.
/lecturer/notices/create.php. By viewing the page source, I discovered a hidden CSRF token embedded directly in the form:![HTB: Guardian [Hard]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHNgXkJ7gQjKCb3-07RGsWtxVcCZhfYB9eX-E5AMpwCyRNoGWXmx-wAGiT3uLtwMGV-QwDpGTN3c0H4fItyxMfGJ08VQ6Uht78ZtvQ2CBON0fa4SG16cLI6X_xIEFTaRRSVz8NeDM71s785S1zCa4dsHpBSSB_Zy3z1m0yICTm1qa0HcXpL5TqTotdQPQ/s1642/bandicam%202026-02-01%2015-00-14-935.jpg "HTB: Guardian [Hard]")
This token is generated server-side but is not bound to a specific session or user. Instead, tokens are simply added to a global token pool and remain valid as long as they exist in tokens.json. This design flaw means that any valid token can be reused in a CSRF attack, regardless of who originally requested it.
From reviewing the source code in Gitea, I had already confirmed that:
- The admin user has access to
/admin/createuser.php - That endpoint allows arbitrary user creation, including setting
user_role=admin - CSRF protection relies solely on the presence of a token in the global pool
With this in mind, I prepared a malicious HTML page (exploit.html) that silently submits a POST request to /admin/createuser.php, using the leaked CSRF token and setting the new account’s role to admin:
The form is automatically submitted via JavaScript as soon as the page loads, requiring no interaction from the victim.
I then hosted this payload on my attacking machine using a simple Python web server:
Returning to the Lecturer portal, I created a new notice with benign-looking content and placed the URL to my hosted exploit in the Reference Link field.
Since this link is explicitly marked as being “reviewed by admin,” it was reasonable to assume that an administrator would eventually open it during moderation.
After a short delay, my listener received an inbound request:
This confirmed that the administrator had viewed the reference link. When their browser loaded exploit.html, the CSRF payload executed automatically in the context of the admin’s authenticated session. As a result, a new administrative user was silently created without any warning or validation.
At this point, full administrative control of the application was achieved by chaining together:
- Stored trust in user-supplied links
- Weak, globally shared CSRF tokens
- An over-privileged admin user creation endpoint
This vulnerability highlights how client-side trust combined with improper CSRF design can lead directly to full application compromise, even without stealing credentials.
Privilege Escalation – Logging in with the CSRF-Created Administrative Account
After confirming that the CSRF exploit was successfully delivered and executed by the administrator, the next step was to verify whether the malicious request had resulted in the creation of a new privileged account. The crafted payload submitted a request to the administrative user creation endpoint with predefined credentials and assigned the highest privilege level.
I navigated to the application login page and attempted authentication using the credentials embedded in the exploit:
- Username: boltech
- Password: B0ltech123
The authentication attempt was successful, and I was immediately redirected to /admin/index.php. The dashboard displayed the welcome banner “Welcome, boltech”, confirming that the account had been created and granted administrative privileges.
To further validate the level of access, I reviewed the Recent User Registrations panel within the Admin Dashboard. The newly created account appeared in the list with the Admin role assigned, verifying that the CSRF attack successfully bypassed authorization safeguards and enabled privilege escalation.
At this stage, full administrative control over the Guardian portal had been obtained. This completed the attack chain by combining stored XSS, session hijacking, and CSRF exploitation to compromise the application’s trust boundaries and gain unrestricted system access.
Local File Inclusion Enumeration
While operating within the administrative interface, I proceeded to explore additional functionality available to privileged users. Navigating to the Reports section from the sidebar revealed several reporting modules, including Enrollment, Academic, Financial, and System reports.
Selecting the Enrollment Report loaded statistical data related to student registrations and retention metrics.
During this interaction, I closely inspected the page URL and observed that the application dynamically loaded report content using a GET parameter:
The presence of a file path inside a user-controllable parameter immediately suggested a potential Local File Inclusion (LFI) vulnerability. The application appeared to rely on the report parameter to determine which PHP file to include and render within the reports interface. Since the parameter accepted relative file paths, it raised the possibility that path traversal techniques could be used to force the application to include unintended files from the server.
This behavior indicated insufficient validation and sanitization of user-supplied input before passing it to file inclusion logic. If exploitable, such a vulnerability could allow disclosure of sensitive system files, application source code, or credential storage locations, potentially enabling further escalation or remote code execution.
Recognizing the security implications of dynamic file inclusion mechanisms, I began testing whether directory traversal payloads could be leveraged to access files outside the intended reports directory, marking the beginning of LFI exploitation attempts.
Testing Direct LFI Payloads
After identifying that the report parameter was responsible for loading backend files dynamically, I began testing whether it could be abused to access sensitive files outside the intended directory. A common first step in confirming an LFI vulnerability is attempting to read system files such as /etc/passwd, which typically exists on Linux systems and can confirm file disclosure if accessible.
I modified the report parameter to directly request the system file:
However, the application responded with the message:
This response indicated that some level of input validation or filtering was implemented to prevent direct file inclusion attempts. The error suggested that the application likely enforced restrictions such as limiting file access to specific directories, validating file paths against an allowlist, or rejecting absolute path references.
Although the direct payload failed, the behavior still confirmed that the application was processing user-supplied file paths internally. In many cases, such filtering mechanisms can be bypassed using traversal techniques, encoding tricks, or alternate path formats. The denial message therefore did not eliminate the presence of an LFI vulnerability but instead suggested that further evasion techniques would be required to successfully exploit it.
Recognizing this, I continued experimenting with alternative payloads and path traversal methods to determine whether the filtering logic could be bypassed and unauthorized file access could still be achieved.
Analyzing LFI Filtering Logic in reports.php
Since direct attempts to include arbitrary files were blocked, I shifted focus toward reviewing the backend implementation responsible for loading report files. Access to the application’s source code through the internal repository provided visibility into how the report parameter was processed inside admin/reports.php.
Reviewing the code revealed the following logic:
From this snippet, it became clear that the application attempted to mitigate Local File Inclusion attacks using two defensive checks.
The first validation searched for directory traversal sequences. Any request containing .. was immediately blocked, preventing straightforward attempts to escape the intended directory structure.
The second validation enforced a regular expression restriction. The report parameter was required to end with one of four approved filenames: enrollment.php, academic.php, financial.php, or system.php. Any request that failed to match this pattern was rejected with an access denial message.
While these checks initially appeared effective, they introduced a critical weakness. The regular expression only validated whether the supplied input ended with one of the allowed filenames but did not enforce where or how the file was included internally. This meant that as long as the payload terminated with one of the permitted filenames, additional data could be prepended without being rejected.
Recognizing this, I explored alternative inclusion techniques that avoided directory traversal sequences while still allowing arbitrary content to be processed. One viable approach involved leveraging PHP stream wrappers and filter chains. These wrappers can manipulate file reads and bypass traditional path validation when improperly filtered.
By crafting a payload that appended one of the allowed filenames to a PHP filter chain, it was possible to satisfy the regex requirement while still influencing how PHP processed the inclusion request. This resulted in payloads such as:
Because the request still ended with system.php, it successfully passed the validation logic. However, the prefixed filter chain allowed the file inclusion behavior to be manipulated, effectively bypassing the intended restrictions.
This discovery confirmed that the LFI vulnerability was still exploitable despite the implemented filters. The issue stemmed from insufficient validation of user-controlled input and reliance on filename suffix matching rather than strict path enforcement or allowlist inclusion logic.
Achieving Remote Code Execution via php://filter Chain
After identifying that the report parameter could be abused through file inclusion, I shifted focus toward bypassing the filename restrictions implemented in reports.php. Since direct traversal attempts were blocked and only specific filenames were allowed, I leveraged the php://filter wrapper to construct a payload that could generate executable PHP code in memory while still satisfying the server-side validation logic.
To accomplish this, I cloned the publicly available filter chain generator designed to produce complex encoding chains capable of reconstructing PHP payloads during inclusion.
Using this tool, I generated a filter chain that would recreate a reverse shell payload once interpreted by the PHP interpreter. The payload was constructed to instruct the server to initiate a callback connection to my attacking machine.
The script returned a lengthy php://filter chain designed to reconstruct the payload through multiple encoding and decoding transformations. Although the output appears excessively complex, its purpose is to evade filtering logic and safely rebuild executable PHP code at runtime.
Before triggering the exploit, I prepared a listener on my machine to capture the incoming connection:
With the listener running, I submitted the generated filter chain through the vulnerable report parameter. To bypass the filename validation regex, I appended system.php to the end of the payload. This allowed the request to pass server-side checks while ensuring PHP still evaluated the malicious filter stream.
Shortly after issuing the request, the listener received a connection from the target system, confirming successful command execution. The callback provided an interactive shell running as the www-data user inside the web application directory.
This confirmed that the restricted file inclusion vulnerability could be escalated into full remote code execution, granting an initial foothold on the target system.
Enumerating Configuration Files and Database Credentials
With a stable reverse shell established as the www-data user, I began post-exploitation enumeration to identify potential privilege escalation paths. Since the foothold was obtained through the web application, I focused on locating configuration files that might contain sensitive credentials.
While navigating through the web root directory, I discovered a configuration file inside the application’s config directory. Inspecting this file revealed hardcoded database credentials.
The configuration file contained the database connection details, including credentials for the MySQL root user. Notably, the password appeared to follow a predictable organizational naming convention, suggesting it might be reused elsewhere on the system.
Recognizing the potential value of these credentials, I attempted to authenticate directly to the MySQL service using the recovered password.
After supplying the extracted password, authentication succeeded, granting direct access to the database server with administrative privileges.
Database Enumeration and User Credential Discovery
Once inside the MySQL console, I proceeded to enumerate available databases to identify application-specific data.
Among the default system databases, I located the guardiandb database, which appeared to be used by the web application. I switched context to this database and enumerated its tables.
The database contained multiple tables related to the university portal, including course management, submissions, messaging, and user authentication. The users table was particularly interesting as it likely stored authentication information for administrators, lecturers, and students.
To confirm this, I extracted the contents of the users table.
The query returned a large dataset containing usernames, password hashes, user roles, and personal information. Several accounts were assigned administrative privileges, indicating potential targets for credential cracking or lateral movement. The presence of hashed passwords suggested that offline cracking might yield additional valid credentials, potentially reusable across other services.
Additionally, the database contained personally identifiable information such as addresses and dates of birth, highlighting the severity of the data exposure resulting from the compromised database access.
At this stage, the successful retrieval of database credentials significantly expanded access beyond the initial web shell and provided multiple avenues for further privilege escalation and system compromise.
Cracking Administrator Password Hashes
Following database enumeration, I shifted focus toward credential recovery. The users table revealed several administrator accounts storing password hashes rather than plaintext credentials. During earlier configuration file analysis, I had also discovered a static application salt value:
Since the password hashes appeared to be generated using salted SHA256, I prepared them for offline cracking. I extracted the first two administrator hashes and appended the discovered salt using the hash:salt format required by Hashcat.
Inside the file, I structured the entries as follows:
With the hashes prepared, I initiated an offline password cracking attempt using Hashcat. Based on the application logic, I selected mode 1410, which corresponds to the sha256($pass.$salt) hashing scheme. I paired this with the widely used rockyou.txt wordlist to maximize coverage of commonly reused passwords.
Hashcat successfully identified the hashing algorithm and began processing the wordlist. Despite running in pure kernel mode, which prioritizes compatibility over performance, the cracking process completed quickly due to the use of a relatively weak password.
The attack successfully recovered one of the administrator passwords:
The cracking result confirmed that password complexity and strength were insufficient, making offline attacks viable once database access was obtained. Recovering valid administrator credentials significantly increased the attack surface, as these credentials could potentially be reused across other services or authentication portals within the environment.
Lateral Movement via Recovered SSH Credentials
After successfully cracking one of the administrator password hashes and recovering the plaintext password fakebake000, I attempted to reuse the credential across other accessible services. Since SSH was exposed during initial enumeration and multiple user accounts were identified in the database, credential reuse became a strong candidate for lateral movement.
Among the discovered accounts, the user jamil appeared to be associated with administrative privileges and internal development access. I attempted to authenticate to the target host via SSH using the recovered password.
Upon initiating the connection, the SSH client prompted for host authenticity verification. After confirming the host fingerprint, I supplied the recovered password. Authentication succeeded, granting direct shell access as the jamil user.
User Flag Retrieval and Sudo Privilege Enumeration
After gaining SSH access as the jamil user, I began standard post-compromise enumeration to identify sensitive files and potential privilege escalation paths. A quick directory listing of the home folder revealed the presence of a user flag.
The directory contained user.txt, which is commonly used in CTF environments to confirm successful user-level compromise. I displayed its contents to verify access.
The file contained the user flag, confirming full control over the jamil account and marking the completion of the user-level foothold.
Hurray!!! I got the user flag.
With user access established, the next priority was privilege escalation. To identify any commands the current user could execute with elevated privileges, I enumerated the sudo permissions assigned to jamil.
The output revealed that the jamil user was allowed to execute a Python script located at /opt/scripts/utilities/utilities.py as another user named mark without requiring authentication. The NOPASSWD directive indicated that this script could be executed directly via sudo without providing the jamil user’s password.
This configuration introduced a potential privilege escalation vector. If the script contained insecure functionality, writable dependencies, or improper input handling, it could be abused to execute arbitrary commands as the mark user. Given that the script resided in a custom utilities directory rather than a standard system location, it warranted further inspection for exploitable behavior.
At this stage, the attack path shifted toward analyzing the utilities.py script to determine whether it could be leveraged to escalate privileges from jamil to mark, potentially bringing the attacker one step closer to full system compromise.
Enumerating Writable Script Dependencies
Since the jamil user was permitted to execute /opt/scripts/utilities/utilities.py as the mark user, the next step was to analyze the script’s environment and supporting modules. Custom scripts frequently import additional files, and if any of those dependencies are writable, they can often be abused to execute arbitrary code under elevated privileges.
I navigated to the utilities directory to inspect its structure and permissions.
To confirm my current privilege context and group memberships, I verified the user identity.
The output showed that jamil was part of both the jamil and admins groups. Membership in the admins group immediately stood out because files owned by this group could potentially be writable or readable, providing an opportunity to tamper with scripts executed under elevated privileges.
Next, I listed the contents of the directory along with their permission settings.
The directory contained several Python modules, including attachments.py, db.py, logs.py, and status.py. Most files were owned by root but assigned to the admins group with restricted write permissions. However, one file stood out:
The status.py file was both executable and writable by members of the admins group. Since jamil belonged to this group, this meant the file could be modified directly. Given that the main utilities.py script was executable as the mark user, there was a strong possibility that it imported or relied on status.py. If so, modifying this module could allow injection of malicious Python code that would execute with mark’s privileges.
This discovery indicated a likely privilege escalation vector through insecure writable script dependencies, prompting further investigation into how utilities.py interacts with status.py.
Analyzing Script Execution Flow and Import Dependencies
After identifying that status.py was writable by members of the admins group, I examined the file to determine whether it could be leveraged for privilege escalation. Since writable Python modules are often imported by higher-privileged scripts, they present an ideal opportunity for code injection.
I first inspected the contents of the status.py module.
The script contained a simple function designed to display system information, including operating system details, CPU usage, and memory utilization. The module imported several libraries such as platform, psutil, and os, and defined a function named system_status() that printed system metrics. While the code itself appeared benign, the critical observation was that the file was writable by the admins group, meaning its contents could be modified.
Next, I moved back to the parent utilities directory to locate the main script responsible for execution.
The directory contained three items: an output folder, the main utilities.py script, and the utils directory housing the supporting modules.
To better understand privilege boundaries, I reviewed the permissions assigned to utilities.py.
The output showed that the script was owned by root and assigned to the admins group, with execution permissions enabled for group members but without write permissions. Although the file itself could not be modified directly by jamil, it was designed to be executed via sudo as the mark user, as discovered earlier.
This setup strongly suggested that utilities.py likely imported modules from the utils directory, including status.py. Because status.py was writable by the admins group, modifying its contents could allow arbitrary Python code to execute when utilities.py was run with elevated privileges.
Privilege Escalation via Writable Python Module Injection
After confirming that utilities.py likely imported the status.py module and observing that status.py was writable by the admins group, I attempted to exploit this insecure permission configuration. Since the jamil user was a member of the admins group and could execute utilities.py as the mark user via sudo, modifying the imported module provided a direct opportunity to inject malicious code.
To test this theory, I replaced the contents of status.py with a simple payload designed to spawn a Bash shell. This payload would execute whenever the module was imported or called by the main script.
With the malicious modification in place, I executed the utilities script using the permitted sudo rule while specifying the system-status functionality.
The script executed successfully and spawned a shell running under the mark user context. To verify the privilege escalation, I checked the current user identity.
The output confirmed that execution privileges had transitioned from jamil to mark, demonstrating successful privilege escalation through Python module injection.
This vulnerability existed due to improper file permission management, where a script executed with elevated privileges relied on modules that were writable by lower-privileged users. By modifying one of these dependencies, it became possible to execute arbitrary commands under a higher-privileged account, providing a reliable escalation path within the system.
Identifying Root Privilege Escalation via Custom Apache Control Script
After successfully escalating privileges from jamil to the mark user, I continued local enumeration to determine whether further escalation to root was possible. A common next step during post-exploitation is reviewing sudo permissions assigned to the current user, as these frequently reveal misconfigured administrative utilities.
I began by enumerating sudo privileges for the mark account.
The output revealed that the mark user was allowed to execute a custom binary named safeapache2ctl as any user, including root, without requiring a password. The NOPASSWD directive indicated that this command could be executed freely, making it a strong candidate for privilege escalation.
To better understand the functionality of this binary, I checked its usage instructions.
The help output indicated that the script was designed to run Apache using a configuration file supplied through the -f parameter. Specifically, it expected configuration files located in /home/mark/confs/. Since Apache configuration files can contain directives that execute external commands or load arbitrary modules, this suggested a potential path to root-level command execution if the configuration file could be controlled or modified.
To continue situational awareness and verify available user directories that might contain configuration files or sensitive data, I listed the contents of the /home directory.
The directory contained home folders for multiple users, including gitea, jamil, mark, and sammy. The presence of the mark directory was particularly relevant given that the Apache control script explicitly referenced configuration files stored within that user’s home directory.
At this stage, the focus shifted toward inspecting /home/mark/confs/ to determine whether configuration files could be modified or replaced. If writable, these files could potentially be abused to inject malicious Apache directives, enabling execution of arbitrary commands as root.
Root Privilege Escalation via Malicious Apache Configuration Injection
After identifying that the mark user could execute /usr/local/bin/safeapache2ctl as root without authentication, I investigated how the utility functioned. The help output indicated that the binary launched Apache using a user-supplied configuration file. Because Apache configuration files support advanced directives, including logging handlers capable of executing system commands, this presented a viable path to root-level code execution.
To exploit this behavior, I created a custom Apache configuration file inside the expected configuration directory. The configuration defined basic Apache parameters but, more importantly, abused the ErrorLog directive to execute a command whenever Apache attempted to write to the error log.
I created the directory and malicious configuration file as follows:
This configuration instructs Apache to pipe error log output to a shell command. The injected command copies the system Bash binary to /tmp/rootbash and assigns it the SUID bit, allowing it to execute with root privileges regardless of the invoking user.
With the malicious configuration prepared, I executed the custom Apache control script using the supplied configuration file.
Because the script runs with root privileges and processes the configuration file directly, the malicious ErrorLog directive executed successfully. This resulted in the creation of a SUID-enabled Bash binary located at /tmp/rootbash, effectively granting a persistent root escalation mechanism.
At this stage, the system was primed for full root compromise by leveraging the newly created SUID shell.
Obtaining Root Shell and Capturing the Root Flag
After successfully injecting a malicious Apache configuration and triggering execution through the safeapache2ctl utility, a SUID-enabled Bash binary was created at /tmp/rootbash. This binary allowed privilege escalation to root by preserving elevated privileges when executed.
To leverage this newly created SUID binary, I executed it with the -p flag, which instructs Bash to retain effective privileges.
Upon spawning the shell, I verified the privilege context to confirm successful escalation.
The output showed that while the real user remained mark, the effective user ID (euid) had escalated to root, confirming full administrative control over the system. To further validate this access, I checked the current user identity.
The command returned root, confirming that the privilege escalation was successful.
With full root privileges obtained, I navigated to the root directory and retrieved the final flag.
The contents of the file revealed the root flag, marking complete compromise of the target machine.
Hurray!!! I got the root flag and with that the machine was officially pwned.
This final step demonstrated how a chain of vulnerabilities including insecure file permissions, unsafe script execution, credential reuse, and misconfigured administrative utilities can be combined to escalate from an initial web foothold to full system ownership.
Keywords:
guardian htb writeup
guardian htb walkthrough
guardian complete htb solution
guardian htb walkthrough pdf
guardian hack the box writeup
Guardian Hack the Box Writeup
Guardian Hack the Box Machine Writeup
Guardian Hack the Box Walkthrough
Guardian Hack the Box Machine Walkthrough
Guardian HTB Writeup
Guardian HTB Walkthrough
Guardian HTB Machine Walkthrough
Guardian HTB Machine Writeup
Guardian Hack the Box HTB Machine Walkthrough Writeup
Guardian HTB Solution
Guardian Hack the Box Solution
Guardian Hack the Box Complete Walkthrough
Guardian Hack the Box Complete Writeup
Guardian Hack the Box Complete Solution
Guardian htb write up
HackTheBox Guardian Writeup
HTB Guardian Writeup.
HackTheBox Guardian writeup
HackTheBox - Guardian (writeup)
HTB writeups - Guardian
HackTheBox Guardian writeup
Guardian | HTB Writeup | Linux
HTB - guardian writeup
Owned guardian from Hack The Box
Hack The Box - HTB guardian writeup
HTB guardian detailed writeup english
HackTheBox | guardian hack the box · HackTheBox | guardian
giveback htb writeup hackthebox | Season 9
guardian htb writeup giveback
write-ups category posts hack the box blog
guardian hack the box walkthrough
guardian htb walkthrough
guardian hack the box writeup
guardian hack the box solution
htb eighteen writeup
signed.htb
eighteen walkthrough
eighteen htb walkthrough
eighteen htb
eighteen htb writeup
eighteen hackthebox
dc01.eighteen.htb
"eighteen.htb"
eighteen hackthebox walkthrough
eighteen writeup htb
editor htb
hackthebox eighteen walkthrough
eighteen hackthebox writeup
gavel.htb/includes
gavel.htb/rules
htb gavel walkthrough
eighteen walkthrough htb
gavel htb write up
gavel htb writeup
eighteen hack the box
eighteen writeup
gavel htb walkthrough
eighteen htb machine
eighteen.htb
eighteen machine htb
nanocorp walkthrough
nanocorp htb
htb editor writeup
signed htb
0 Comments