Eloquia HTB Writeup Premium

I just solved Eloquia from Hack the Box!

Eloquia Machine Summary

Eloquia is an insane-difficulty Windows machine on Hack The Box that focuses on advanced web exploitation, AngularJS Client-Side Template Injection, session hijacking, database exfiltration, SQLite extension loading, and race condition-based local privilege escalation. The machine demonstrates how a sequence of vulnerabilities ranging from client-side script manipulation and OAuth bypasses to custom DLL code execution and service binary hijacking can be chained to achieve full system compromise.

The attack began with Nmap enumeration to map exposed ports, followed by web application enumeration and host configuration to understand the application layout. Through HTML injection and AngularJS CSTI discovery, I injected payloads that facilitated admin session hijacking via stored AngularJS injection, allowing me to take over administrative sessions. I then performed admin panel database configuration, database exfiltration via SQL execution, executing the database dump, and database retrieval and verification. Following offline database enumeration, I targeted the Qooqle service using Qooqle database configuration, Qooqle database exfiltration, Qooqle database retrieval, and Qooqle database enumeration. I continued by setting up OAuth account preparation, OAuth provider manipulation, and an OAuth authentication bypass to subvert trust boundaries.

Next, I conducted database path enumeration, database table enumeration, and user credential extraction, identifying target hashes that led to hash format identification and a hash cracking attempt. To gain remote code execution, I performed malicious DLL generation, staged the malicious payload, and executed a reverse shell execution attempt. After validating the extension loading vulnerability, I used custom DLL payload compilation, custom DLL staging and execution, and compiled the malicious SQLite extension DLL. After setting up a Netcat listener setup and executing evasive reverse shell execution, I secured the initial foothold & user flag.

To pivot further, I performed edge browser artifact enumeration, edge default profile enumeration, staging browser artifacts, and prepared artifacts for exfiltration. I ran edge credential decryption using dependency acquisition, local SMB share setup, mounting the SMB share, transferring decryption files, python environment setup, and executing the credential decryptor, which enabled lateral movement & user enumeration.

For the final privilege escalation phase, I carried out Failure2Ban code enumeration and developed a Failure2Ban exploit script, compiling the C# exploit. I wrote a privilege escalation race condition script, staged the exploit files, downloaded the exploit binary, verified staged exploit, executed the race condition, and verified overwritten binary. After checking exploit execution results, I focused on revising the exploit script, compiling the revised exploit, downloading the revised binary, adjusting and executing the new race condition, and monitoring for exploit output. Finally, I succeeded in capturing the root flag, completing the compromise of the Eloquia machine.

Protected Page

The first step in owning the Eloquia 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 Kali Linux terminal and Hack the Box server has been established, I started the Eloquia machine and I was assigned an IP address (10.129.13.178).

Nmap Enumeration

I began by performing a comprehensive Nmap scan against the target to identify the exposed services, service versions, and operating system details. This provided an initial overview of the attack surface and helped me determine which services were worth investigating further during the enumeration phase.

The scan revealed that only two TCP ports were accessible: 80 (HTTP) hosting a Microsoft IIS 10.0 web server serving the Eloquia website, and 5985 (WinRM), indicating that Windows Remote Management was enabled. The service banners suggested the target was running Windows Server 2019, making the web application the primary entry point while also highlighting WinRM as a potential avenue for authenticated access later in the attack chain.

Host Configuration

After identifying the target hostname during enumeration, I added a local DNS mapping so my system could resolve the domain name correctly. This allowed me to interact with the web application using its expected hostname instead of the IP address.

By updating the /etc/hosts file, requests to eloquia.htb were redirected to the target IP address. This ensured the application loaded correctly and prevented issues with hostname-based routing during the remainder of the assessment.

Web Application Enumeration

After confirming the virtual host, I opened the application in my browser and manually explored the available functionality to understand how the platform operated. I navigated through the homepage, registration, and login pages while inspecting the available authentication mechanisms.

The application redirected requests from the IP address to http://eloquia.htb, confirming that it relied on virtual host routing. I found that users could register new accounts and authenticate through the standard login page, but I also noticed two third-party authentication options.

While the Facebook login was disabled, hovering over Sign in with Qooqle revealed the OAuth endpoint /accounts/oauth2/qooqle/authorize/, indicating that the application supported external authentication through a Qooqle OAuth provider, making it an interesting feature to investigate further.

Host Configuration

After discovering that the application referenced the Qooqle authentication provider, I added another hostname mapping to my local hosts file. This ensured that requests to the Qooqle domain resolved to the target machine for further testing.

By mapping qooqle.htb to the target IP address, I prepared my environment to interact with the OAuth authentication service without DNS resolution issues. This allowed me to continue investigating the third-party login functionality exposed by the web application.

Account Registration and Dashboard Enumeration

I registered a new user account and authenticated to the application to gain access to the user dashboard. After logging in successfully, I enumerated the available features to identify functionality that could be abused during further testing.

Once authenticated, I was redirected to the My Profile dashboard, which exposed several user-accessible features through the left navigation panel.

These included options to Create New Article, Manage My Articles, Connected Accounts, Delete My Account, Contact Us, and Logout. Since these were all available to a low-privileged user, I continued examining each feature for potential security weaknesses that could lead to privilege escalation or code execution.

Web Application Mapping

I proxied the application through Burp Suite and mapped the available endpoints to better understand the underlying technology stack and attack surface. From the intercepted responses, I identified Microsoft IIS 10.0, Django, and AngularJS 1.8.2, with the latter loaded from /static/assets/js/angular-1.8.2.min.js.

The application exposed authentication, profile-image upload, article commenting/reporting, and restricted Django administration functionality, while qooqle.htb operated as a separate OAuth2 authentication provider. Of particular interest was the article comment functionality, which used AngularJS to retrieve and render submitted content. Since the application rendered this content through $sce.trustAsHtml(), the combination of user-controlled HTML and the legacy AngularJS frontend presented a potential Client-Side Template Injection (CSTI) attack surface worth investigating further.

HTML Injection and AngularJS CSTI Discovery

I continued testing the article creation functionality through Burp Suite and confirmed that user-controlled HTML could be injected into published articles. Although some HTML elements were filtered, the application still rendered permitted markup within an AngularJS-controlled context.

Further analysis showed that article and comment content interacted with AngularJS, while comments were rendered using $sce.trustAsHtml() without adequate sanitization. This created a potential Client-Side Template Injection (CSTI) path where Angular expressions and event directives could execute in the page scope.

I also observed that the application’s sessionid cookie lacked the HttpOnly attribute, meaning client-side JavaScript could access it. Combined with the article-reporting functionality and an administrator bot that visited reported content, these weaknesses suggested a possible stored client-side attack path against the privileged session.

Admin Session Hijacking via Stored AngularJS Injection

I inserted an AngularJS payload into the article body so that when the article received focus, it copied the reviewing user's cookies into the comment field and automatically submitted the form. I then created the malicious article and clicked Report Article, causing it to be queued for review by the application's moderation team.

When the article was subsequently reviewed, the injected AngularJS payload executed in the browser and submitted the browser’s cookie value through the article’s comment functionality. Initially, I observed comments containing only my own csrftoken, confirming that the payload was executing successfully.

After the article was published, I clicked on the "Report Article" button and waited for the reported article to be reviewed.

After about 5 seconds, the comment section displayed a csrftoken, then I refreshed the page after about 15 seconds and in the comment section, there appeared an admin credential containing both a sessionid and csrftoken.

The different profile icon also indicated that the request originated from a different authenticated user (probably an Admin). This confirmed a stored client-side injection/XSS-style vulnerability in the article rendering workflow and allowed me to capture the reviewer’s authenticated session cookie for the next stage of the CTF.

Admin Session Hijacking

With the admin's sessionid and csrftoken successfully exfiltrated into the article's comments, I proceeded to hijack their active session. I opened my browser's Developer Tools and navigated to the Storage tab to modify my current site cookies.

I replaced my own cookie values with the newly stolen admin credentials to forge the session. After updating the cookies, I simply refreshed the webpage to authenticate as the compromised user.

The application accepted the forged session, successfully granting me full access to the admin's profile and dashboard.

Admin Panel Database Configuration

Now that I had successfully authenticated as an administrator, I navigated to the Django admin dashboard to explore further attack vectors.

I enumerated the available modules and discovered the SQL Explorer feature, which allowed me to configure new backend connections.

To interact directly with the application's backend, I clicked "Add database connection" and configured it to target the local database file. Then I entered the following credentials:

I deliberately left the credentials and host fields blank since SQLite relies on local file access rather than an authenticated network service. Saving this configuration successfully linked the explorer to db.sqlite3, granting me direct querying capabilities against the application's underlying data.

Database Exfiltration via SQL Execution

With the local SQLite database successfully connected, I navigated to the SQL Explorer Queries section at /accounts/admin/explorer/query/ to execute custom commands.

I clicked "Add Query" and crafted a payload to extract the entire database by abusing SQLite's built-in backup functionality.

I executed this specific SQL statement to force the application to write a full copy of the db.sqlite3 file directly into the publicly accessible static web folder. I named the query "Database Dump", linked it to the sqlite database connection I previously established, and saved the configuration. By masquerading the database dump as a .css file, I successfully created a direct download link to exfiltrate the application's sensitive backend data.

Executing the Database Dump

To trigger the payload and finalize the exfiltration, I opened my newly created query and clicked the "View on site" button within the admin panel.

This action redirected me to the active SQL Explorer execution environment where I could directly interact with the configured SQLite database.

Once this endpoint loaded, I clicked on "Save and run" to execute my malicious SQL statement. The application returned an alert stating "output file already exists", which served as the perfect confirmation of success. This output meant the database engine worked exactly as intended, successfully copying the target database into the accessible static web directory.

Database Retrieval and Verification

With the database successfully dumped into the static web directory, I needed to retrieve it to my local machine for offline analysis. I ran a curl command to fetch the masqueraded file directly from the target server.

Once the transfer finished, I ran a quick directory listing to ensure the file was safely in my workspace. To confirm the integrity of the downloaded payload, I ran the file utility against dump.css. The output verified that it was indeed a valid SQLite 3.x database, proving the exfiltration was a complete success and setting me up to extract sensitive credentials.

Offline Database Enumeration

To investigate the exfiltrated database, I opened the file locally using the standard SQLite command-line client. I ran the .tables command to enumerate the available data and identified several interesting targets, particularly the explorer_databaseconnection table.

Next, I ran a .schema query to inspect the exact structure of the connection table before dumping its contents. I then queried the entire table to review the stored database connections, expecting to find cleartext credentials for the primary database. However, I noticed that sensitive fields like the host, user, and password appear to be stored as BLOBs, suggesting the application is encrypting these values at rest.

Qooqle Database Configuration

To investigate the underlying data of the custom OAuth provider, I needed to manually create a connection to its database.

I navigated back to the SQL Explorer's "Database connections" section and clicked "Add database connection" to configure the new link.

I configured the connection alias as qooqle and selected the standard SQLite3 engine. By setting the database name to ../qooqle/db.sqlite3, I leveraged a relative path to traverse out of the current directory and directly target the neighboring virtual host's database file. I left the authentication and host fields blank, as local SQLite files do not require them, and saved the configuration to successfully establish the cross-application database link.

Qooqle Database Exfiltration

With the qooqle database connection successfully established, I navigated back to the SQL Explorer Queries menu to extract its contents.

I clicked "Add Query" and crafted another payload using the same SQLite backup technique, this time targeting the custom OAuth provider.

I titled this new query "Qooqle Dump" and specifically selected the qooqle database connection from the dropdown menu to ensure it ran against the correct target. I saved the configuration, which prepared the application to dump the neighboring virtual host's data into the easily accessible static web directory. 

This setup mirrored my previous exfiltration technique, allowing me to bypass file restrictions by masquerading the new database backup as a standard CSS file for download.

Qooqle Database Retrieval

After executing the query in the admin panel, I needed to download the newly created dump to my local attacking machine. I ran a curl command to fetch the masqueraded qdb.css file from the target's static assets directory.

Once the download completed, I ran a quick directory listing to confirm the file was successfully transferred to my workspace. Finally, I ran the file command against qdb.css to verify its structure and integrity. The output confirmed it was a valid SQLite 3.x database, meaning I successfully exfiltrated the Qooqle OAuth data and was ready to hunt for credentials.

Qooqle Database Enumeration

To investigate the exfiltrated Qooqle OAuth data, I opened the downloaded file locally using the SQLite command-line tool. I enumerated the available tables and queried the oauth2_provider_application to understand the target's OAuth configuration. Next, I checked the schema for the Qooqle_customuser table and dumped its contents to search for potential credentials.

Reviewing the output, I successfully extracted several usernames, including admin and m.barker, along with their associated user data. Most importantly, I recovered their corresponding PBKDF2-SHA256 password hashes. I can now save these hashes to my attacking machine and attempt to crack them offline to further compromise the environment.

OAuth Account Preparation

The database dump successfully confirmed that the m.barker user exists within the Qooqle application, which is the exact account I needed to target for my intended attack chain. Instead of continuing to enumerate the database, I shifted my focus to abusing the OAuth account linkage between the Eloquia and Qooqle platforms.

To prepare for the exploit, I navigated directly to the Qooqle application and registered a completely new account. I then authenticated into this profile with my fresh credentials. Logging in at least once was a necessary step to ensure my Qooqle account was fully initialized in the backend before attempting the OAuth manipulation.

OAuth Provider Manipulation

To exploit the OAuth integration, I returned to the Eloquia admin panel and navigated to the "Connected Accounts" section.

I clicked the "Change" button next to the active Qooqle integration, which was initially tied to m.barker@qmail.htb. The application popped up a new window redirecting me to the Qooqle authorization endpoint. Since I was already authenticated into my newly created Qooqle account, I simply clicked the "Authorize" button to approve the permissions.

By completing this flow, I successfully overwrote the linked OAuth provider, binding my controlled boltech@gmail.com@qmail.htb account to the target profile. This action establishes a persistent backdoor that allows me to log into the application using my own Qooqle credentials.

OAuth Authentication Bypass

To verify the impact of the newly established trust relationship, I needed to test the compromised authentication flow. I logged out of my current Eloquia session and navigated back to the main login page.

I clicked the Qooqle login option, which immediately redirected me to the third-party authorization prompt.

Because I had successfully linked my attacker-controlled Qooqle account to the targeted profile, I simply authorized the login request to proceed. I authenticated seamlessly and was logged back into the Eloquia admin dashboard without needing the original password, completing the account takeover.

Database Path Enumeration

After regaining access to the admin dashboard, I pivoted back to the SQL Explorer at /dev/sql-explorer to look for a path to Remote Code Execution. I needed to find the absolute physical path of the application on the Windows filesystem to facilitate potential file writes or malicious extension loading. To extract this information, I ran a built-in SQLite command to query the active backend database connection details.

The query executed successfully and returned the active file locations. The output explicitly revealed the database was located at C:\Web\Eloquia\db.sqlite3, effectively leaking the exact absolute directory path of the web root for further exploitation.

Database Table Enumeration

To further understand the backend structure from within the SQL Explorer, I enumerated the available tables in the connected database. I crafted a standard SQLite payload to query the master schema and retrieve a complete list of table names.

The execution successfully returned the internal structure, revealing key Django and application-specific targets like Eloquia_customuser and django_session. By mapping out these tables, I gained a comprehensive overview of the application's data storage to guide my next extraction efforts.

User Credential Extraction

Knowing that Eloquia_customuser is the primary user table from my previous enumeration, I targeted it to extract sensitive account data. I ran a straightforward SQL query within the SQL Explorer execution environment to dump the complete contents of this table.

The execution successfully returned the application's internal user records. I enumerated the results and gathered valuable information like email addresses, administrative privileges, and profile image paths. Most importantly, I successfully extracted the PBKDF2-SHA256 password hashes for several accounts, giving me the material needed to attempt offline password cracking.

Hash Format Identification

With the password hashes extracted from the database, I needed to determine their exact format before attempting an offline dictionary attack. I enumerated the structure of the exfiltrated strings and immediately noticed the distinct pbkdf2_sha256$ prefix. To confirm the specific cracking module required, I navigated my browser to the official Hashcat example hashes wiki.

I matched my target strings against the known reference formats. The structure aligned perfectly with module 10000, confirming they are indeed standard Django (PBKDF2-SHA256) hashes. With the hash type successfully identified, I now have the necessary parameters to configure my cracking tools.

Hash Cracking Attempt

With the target's password hashes extracted and the format confirmed as Django PBKDF2-SHA256, I saved them into a local file to attempt an offline dictionary attack. I ran nano to populate my target list and then executed Hashcat against the rockyou.txt wordlist to crack the credentials.

Unfortunately, the execution failed immediately with a CL_PLATFORM_NOT_FOUND_KHR error because my current environment lacks the necessary OpenCL or CUDA GPU drivers. Since I couldn't crack the hashes locally due to these hardware limitations, I had to pivot my strategy. I realized I needed to abandon the password cracking route and focus on finding an alternative method to achieve Remote Code Execution directly.

Malicious DLL Generation

To find an alternative path to Remote Code Execution, I researched SQLite vulnerabilities and discovered CVE-2024-47881, which permits arbitrary library execution via the load_extension function. I further enumerated the admin panel's article creation feature and found that the banner upload functionality allows unrestricted file uploads, giving me a way to plant a payload. To weaponize this vector, I ran msfvenom to craft a malicious Windows DLL configured with a reverse TCP shell back to my attacking machine.

The payload compiled successfully into pwn.dll. My plan is to upload this file through the vulnerable banner endpoint to stage it securely on the Windows filesystem. Once the file is staged and its path is revealed, I will use the SQL Explorer to execute a SELECT load_extension('path/to/pwn.dll') query, forcing the backend to execute the library and send me a reverse shell.

Staging the Malicious Payload

To stage the reverse shell for execution, I navigated to the "Articles" management section within the Django admin panel and clicked "Add article". I uploaded my compiled pwn.dll directly into the "Banner" field, capitalizing on the missing file extension checks.

I populated the required fields, including assigning martin.rose@hotmail.com as the author, and clicked "Save" to commit the new entry to the database. This action successfully created "Article object (14)". Upon inspecting the newly created object, I confirmed the application saved my payload to a predictable, publicly accessible directory: static/assets/images/blog/pwn.dll. This verified path provides the exact argument I need for the upcoming SQLite load_extension command.

Reverse Shell Execution Attempt

To trigger the payload, I first set up a netcat listener on my attacking machine to catch the incoming connection. Next, I navigated to the SQL Explorer Queries section and created a new query titled "rev shell" designed to execute the staged library.

I saved the configuration, clicked "View on site", and ran the SQL command, hoping to spawn a reverse shell. However, the execution failed and nothing connected back to my listener. I tested the binary execution locally and deduced that the standard msfvenom DLL was likely being blocked by an active Antivirus on the target server. Because standard framework payloads are easily signatured, I realized I needed an evasion technique to successfully bypass the endpoint protections.

Validating the Extension Loading Vulnerability

To confirm whether the load_extension function was actually enabled in the backend, I needed to test its behavior without triggering the antivirus again. I navigated back to the SQL Explorer, created a new test query and intentionally ran it with a fake file path to observe the resulting error.

After clicking to execute it, the application returned "The specified module could not be found", which is an OS-level LoadLibrary failure rather than SQLite's typical "not authorized" error. This proved that enable_load_extension(True) was actively configured in the Django app's SQLite setup and the function wasn't explicitly blacklisted. Crucially, Windows executes a DLL's DllMain function during LoadLibrary before SQLite formally validates the extension, meaning a properly crafted custom DLL will execute our code the moment it is loaded, regardless of any subsequent initialization errors.

Custom DLL Payload Compilation

To bypass the Antivirus that blocked my standard msfvenom payload, I decided to write and compile a custom, evasive C script. I ran nano to create shell.c and wrote a simple library that hooks into DllMain to execute code the moment it is loaded by the system. Specifically, I programmed it to run a whoami command and pipe the result directly into a text file within the publicly accessible web directory.

After saving the source code, I ran the MinGW cross-compiler to successfully package the script into a shared Windows library named evil.dll. Finally, I enumerated my local workspace using the dir command to verify that my new payload was compiled and ready for staging on the target.

Custom DLL Staging and Execution

To deploy my evasive payload, I returned to the article creation page in the admin dashboard and uploaded the custom evil.dll into the Banner field. I saved the entry to create "Article object (15)" and verified the file was staged at the publicly accessible path static/assets/images/blog/evil.dll.

With the payload successfully planted, I navigated to the SQL Explorer Queries menu and created a new query titled "DLL attack verification" using the SQL command SELECT load_extension('static/assets/images/blog/evil.dll');

After saving the query successfully, I clicked the "View on site" button to access the active execution environment.

I clicked "Save & Run" to execute the SQL payload ("bandicam 2026-08-04 18-10-53-400.jpg"), forcing the Windows backend to load the library and trigger my embedded whoami command via the DLL attachment routine.

To verify the attack, I navigated my browser to the designated output file at http://eloquia.htb/static/assets/images/blog/out.txt.

The page successfully returned the string eloquia\web, confirming that the execution succeeded and I had finally achieved Remote Code Execution on the target server.

Compiling the Malicious SQLite Extension DLL

I created a custom Windows DLL (dll_winsock.cpp) that exports the sqlite3_extension_init() function so it can be loaded as a valid SQLite extension. When the DLL is loaded, DllMain() automatically starts a new thread that initializes Winsock, connects back to my attacker machine (10.10.15.71:4444), and launches a hidden cmd.exe process with its input and output redirected over the socket, giving me a reverse shell. I then compiled the source code into a 64-bit Windows DLL using the MinGW cross-compiler and linked it against the Winsock library (ws2_32).

The compilation completed successfully and produced dll_winsock.dll, which I would later use as the malicious SQLite extension during the exploitation phase.

Netcat Listener Setup

With the evasive Winsock DLL payload successfully compiled, I needed a way to catch the incoming connection once it executed on the target. I opened a new terminal window on my attacking machine and set up a netcat listener to bind to my designated port.

I ran this command to wait silently for the reverse shell to connect back to my host. Once the listener was actively listening on all interfaces, my local staging was complete. I was now ready to upload and trigger the final payload through the SQL Explorer vulnerability.

Evasive Reverse Shell Execution

To deploy the final payload, I navigated back to the Eloquia administration panel's "Articles" section. I initiated the process by clicking the "Add article" button to stage my custom library.

I populated the necessary fields, uploaded dll_winsock.dll into the Banner field, and saved the entry. I enumerated the newly created "Article object (16)" and confirmed the payload was successfully staged at the application path static/assets/images/blog/dll_winsock.dll.

With the payload securely planted, I proceeded to the SQL Explorer Queries menu. I clicked "Add Query" to begin building the final execution trigger.

I configured a new query titled "dll_winsock query" using the exact SQL command shown above. Crucially, I utilized the absolute Windows filesystem path I discovered earlier, ensuring the SQLite load_extension function could accurately locate my file on the C: drive. After filling in the required title and description details, I saved the query configuration to the database.

I navigated into the newly saved query and clicked the "View on site" button to bring up the active execution interface.

To trigger the exploit, I ran the command by clicking "Save & Run" against the backend database.

This action forced the underlying Windows system to load my compiled Winsock DLL. Because of how the API functions, it executed the hidden reverse shell routine immediately upon attachment. After waiting a few seconds, I checked my netcat terminal and saw a successful callback connection on my listening port. I successfully authenticated as the local service account, bypassing the previous restrictions. This landed me a fully interactive command prompt directly at C:\Web\Eloquia>.

This confirmed that the Antivirus evasion was successful and my initial foothold on the target was complete.

Initial Foothold & User Flag

After catching the reverse shell, I ran some basic enumeration commands to verify my current context on the target. I executed whoami and hostname to confirm I was authenticated as the eloquia\web service account on the Eloquia machine.

Next, I enumerated the C:\Users directory to identify the active user profiles, finding an interesting Olivia.KAT folder alongside my current web user. To quickly locate the first objective, I ran a recursive where search for user.txt across the user directories. The search immediately revealed the flag on the web user's desktop, so I used the type command to read the file and successfully capture the user flag.

Edge Browser Artifact Enumeration

To search for potential privilege escalation vectors, I decided to enumerate the compromised user's local browser data. I targeted the Microsoft Edge installation and ran a directory listing on the User Data folder to check for stored credentials, cookies, or active sessions.

The output revealed a standard Edge profile structure, highlighting the presence of the Default directory and the Local State file. I enumerated these specific artifacts because the Local State file contains the DPAPI-encrypted master key. Obtaining this key is a critical next step, as it will allow me to decrypt any passwords or session tokens stored within the browser's SQLite databases to escalate my privileges.

Edge Default Profile Enumeration

After identifying the Local State file containing the DPAPI master key, I needed to locate the actual SQLite databases storing the saved credentials. I enumerated the contents of the Default profile directory to find the specific files holding the user's browser data.

I ran this directory listing and carefully reviewed the output to identify my next targets. The scan revealed the Login Data file, which is the standard SQLite database Edge uses to store encrypted passwords. With both the encrypted Login Data database and the Local State key file successfully located, I now have the artifacts required to attempt local credential extraction.

Staging Browser Artifacts

To prepare the Edge browser data for exfiltration and local decryption, I needed to isolate the critical files from their deeply nested directories. I copied the Local State file containing the DPAPI master key and the Login Data database holding the encrypted passwords directly to my current working directory on the Desktop.

I ran the dir command to enumerate the Desktop directory and verify the file transfers. The output confirmed that both artifacts were successfully staged alongside the user.txt flag, readying them for immediate download to my attacking machine for offline decryption.

Preparing Artifacts for Exfiltration

To ensure the targeted Edge browser artifacts could be easily transferred and handled on my attacking machine, I needed to rename them with identifiable file extensions. I copied the staged files from the Desktop into the main web user directory, appending a .json extension to both to prevent any parsing issues during the download process.

I ran the dir command against both newly created destinations to verify that the copy operations completed without errors. I enumerated the resulting output to confirm that local_state.json and login_data.json were successfully stored with their original file sizes intact, perfectly positioned for exfiltration over my reverse shell.

Edge Credential Decryption

To extract the plaintext passwords from the staged browser artifacts, I needed to interact directly with the Windows Data Protection API (DPAPI). I ran nano to craft a custom Python script that parses the local_state.json file to unwrap the AES-GCM master encryption key.

With the master key unlocked, I programmed the script to target the login_data.json SQLite database and decrypt the ciphertext stored inside. I enumerated the internal logins table, iterating through each row to extract the target URLs, usernames, and their successfully decrypted passwords. By automating this extraction, I gave myself a clean, formatted output of all saved browser credentials to assist with further privilege escalation.

Dependency Acquisition

To execute my custom decryption script successfully, I needed to supply the target environment with the missing Python dependencies. I enumerated the necessary package repositories from my Linux machine to manually download the required Windows wheel files.

I navigated to PyPI and downloaded the pycryptodomex-3.23.0-cp37-abi3-win_amd64.whl package. Next, I accessed an external package index to retrieve the pywin32-306-cp311-cp311-win_amd64.whl file. 

I staged both of these compiled dependencies locally, preparing them for transfer over my reverse shell so I could install them and extract the browser credentials.

Local SMB Share Setup

To transfer my custom decryptor script and the newly downloaded Python dependencies to the target, I needed to establish a local file share. I ran Impacket's smbserver utility on my attacking machine to host my current working directory as a network share named "DORK".

I authenticated the server by configuring specific credentials to ensure the connection was securely isolated from unauthorized access. Additionally, I explicitly appended the flag to enable SMB2 support, guaranteeing compatibility with the target's modern Windows networking stack. With the server actively listening, I was fully prepared to pull the required staging files directly onto the compromised host.

Mounting the SMB Share

To transfer my staging files onto the target system, I needed to mount the SMB share I had just created on my attacking machine. I authenticated to the network drive using the net use command with the custom credentials I configured earlier. Next, I enumerated the contents of the mounted share to confirm my custom decryptor and Python dependencies were accessible.

The output verified that all my staged payloads, including the .whl packages and decryptor.py script, were successfully exposed to the target environment. Finally, I ran the cd /d command to navigate directly to the main web user directory to prepare for the dependency installation phase.

Transferring Decryption Files

With the local SMB share successfully mounted, I pulled my custom Python decryptor script and the necessary Windows wheel dependencies directly from my attacking machine onto the target. I ran the copy command to transfer decryptor.py, along with the pycryptodomex and pywin32 packages, straight into the current working user directory.

I enumerated the directory contents using the dir command to verify that all the files had copied safely on the host. The output confirmed that the script and both wheel dependencies were successfully staged alongside the previously harvested browser artifacts, leaving everything in place for local execution.

Python Environment Setup

To run my custom decryption script, I verified the local Python interpreter version and installed the offline wheel packages I transferred via SMB. I ran the pip installation commands to set up the necessary cryptographic dependencies under the user profile.

I enumerated the environment by testing the package imports to ensure everything was functional. The terminal successfully returned the verification message, confirming that both win32crypt and Cryptodome were ready for action.

Executing the Credential Decryptor

With the Python environment fully configured and all required modules installed, I was ready to execute my custom decryption script against the harvested browser data. I navigated to my working directory and invoked the script using the full path to the Python interpreter.

I ran this script to parse the local state master key and unlock the encrypted contents of the Edge login database. I enumerated the retrieved results and successfully extracted several sets of saved credentials from the output. Among them, I uncovered a promising password (S3cureP@sswdIGu3ss) associated with the user Olivia.KAT, providing me with the exact credentials needed for the next phase of the challenge.

Lateral Movement & User Enumeration

Armed with the harvested password from the Edge browser database, I targeted the user account belonging to Olivia. I authenticated against the remote Windows target using the Evil-WinRM utility with the recovered credentials.

I ran this connection command to establish a remote PowerShell session and successfully escalated my access. Once logged in, I enumerated the files on Olivia's desktop to find potential privilege escalation vectors. The directory listing revealed several interesting files, including a Todo.txt and a Process Monitor log (Logfile.PML), setting up my next phase of investigation.

Failure2Ban Code Enumeration

To investigate potential local privilege escalation vectors within the custom software, I examined the project files associated with the running service. I read the Todo.txt file and searched the filesystem using PowerShell to locate the application configuration and source code directory.

I ran these commands to locate the software files under the Qooqle IPS installation path. I enumerated the subdirectories and discovered various source files, including Service1.cs, App.config, and a log directory containing historical service logs. This structural analysis pointed me directly toward the custom service logic for further analysis.

Failure2Ban Exploit Script

To leverage the high-privileged service behavior I discovered, I wrote a custom C# proof-of-concept payload to copy the restricted root flag to a readable path. I ran nano to create Failure2Ban.cs, programming it to extract the administrator flag and write execution diagnostics to a public directory.

I wrote this script to verify code execution under the service context and confirm privilege escalation. Once executed by the backend scheduler, it would read the protected file and grant me access to the final objective.

Compiling the C# Exploit

To compile my custom C# exploit script into a functional Windows executable from my Linux workstation, I needed to check for the Mono C# compiler. I ran the which command to locate the binary on my system and verified that mcs was available.

I compiled the script using mcs with the anycpu platform flag to ensure compatibility with the target architecture. Next, I enumerated the compiled file properties using file and ls -lh to confirm it built correctly as a standard MS Windows .NET assembly executable.

Privilege Escalation Race Condition Script

To successfully replace the high-privileged binary while the service was running, I needed to automate a file-overwrite race condition using PowerShell. I ran nano to create a custom script named race.ps1 that continuously attempts to overwrite the target binary in a loop.

I wrote the script to target the Failure2Ban.exe executable inside the restricted program files directory. I enumerated the loop logic to sleep briefly between iterations, ensuring that as soon as the service relinquished its file lock, the payload would instantly slip into place.

Staging the Exploit Files

To host and transfer my compiled binary and race condition script over to the target system, I prepared an HTTP server from my Linux workstation. I ran a quick check to verify the file permissions and sizes, ensuring both Failure2Ban.exe and race.ps1 were ready for deployment.

I ran this built-in Python module to serve the working directory over port 8000. I enumerated the active bindings to confirm the server was up and running, allowing me to fetch the privilege escalation files directly from my remote session.

Downloading the Exploit Binary

To fetch the compiled exploit from my attacking machine into the remote target session, I utilized PowerShell's web request cmdlet. I ran the Invoke-WebRequest command to download Failure2Ban.exe directly from my HTTP server and save it into Olivia's Documents folder.

I enumerated the file attributes and tested its existence to ensure the transfer completed successfully. The output confirmed the correct file size and path integrity, validating that the payload was fully staged for execution.

Verifying Staged Exploit

To confirm that my exploit binary was successfully downloaded to the correct path, I navigated to the Documents directory on the remote target. I ran the directory listing command to verify the presence of the compiled payload.

I enumerated the folder contents and confirmed that Failure2Ban.exe was present with its expected size. This verification ensured the payload was in position for the upcoming race condition execution.

Executing the Race Condition

To finish staging my attack, I needed to download the race condition script and execute it to replace the legitimate service binary. I ran Invoke-WebRequest to pull race.ps1 from my HTTP server and listed the directory to confirm both files were ready.

I enumerated the Documents folder to verify the script's presence before execution. I ran the script to initiate the overwrite loop, and the terminal quickly returned a [+] SUCCESS message, confirming my malicious binary had successfully hijacked the service path.

Verifying Overwritten Binary

To confirm that my malicious payload successfully replaced the legitimate application binary in the restricted program directory, I inspected the file properties. I ran a PowerShell command to query the target path and cross-referenced it with my source file.

I enumerated the file attributes to check their exact byte lengths and last write timestamps. The output matched perfectly, confirming that the race condition had successfully overwritten the service executable with my custom exploit.

Checking Exploit Execution Results

To verify whether my replaced service binary had executed under high privileges and extracted the administrator flag, I checked the public directory paths. I ran several path-validation and content retrieval commands using PowerShell to test for the expected output files.

I enumerated the public directory and attempted to read the root flag directly, but the commands returned path-not-found errors and access denials. This indicated that the service had not yet triggered or executed the payload, meaning I needed to wait for the scheduled service restart to trigger the exploit.

Revising the Exploit Script

To bypass potential permission issues when trying to read the copied flag from a low-privileged context, I revised my C# exploit code. I ran nano to create a new script named Failure2Ban2.cs that explicitly grants read access permissions to the target user account.

I wrote this updated logic to output the root flag and execution logs directly into Olivia's Documents directory. I enumerated the security access control rules within the code, ensuring that the resulting files would automatically grant read permissions to Olivia.KAT upon execution.

Compiling the Revised Exploit

To compile the updated permission-aware C# script into a Windows executable, I invoked the Mono compiler from my Linux workstation. I ran the mcs command with the appropriate security assembly reference and platform flags to build the payload.

I enumerated the resulting binary using the file and ls -lh utilities to verify its structure and dimensions. The checks confirmed a successful compilation into a 4.5KB .NET assembly executable, ready for deployment.

Downloading the Revised Binary

To pull the updated permission-aware exploit onto the target machine, I leveraged my remote PowerShell session. I ran the Invoke-WebRequest command to download the revised executable from my HTTP server and save it as Failure2Ban-new.exe.

I enumerated the file attributes to confirm that the download completed successfully and that the file size matched the newly compiled 4.6KB build. With the updated payload in place, I was ready to repeat the race condition and capture the root flag.

Adjusting and Executing the New Race Condition

To deploy the updated permission-aware executable, I needed to modify my original race condition script to target the new binary. I ran a series of PowerShell string-replacement commands to update the source path in race.ps1 and saved the output as race2.ps1.

I enumerated the script contents to confirm the changes before execution. Once verified, I ran the new race condition script, which quickly returned a [+] SUCCESS message, indicating that the revised exploit binary had successfully replaced the service executable.

Monitoring for Exploit Output

To capture the flag as soon as the high-privileged service executed my compiled payload, I set up a continuous monitoring loop in PowerShell. I ran a while loop to check the Documents directory every few seconds for any files matching the system-* naming convention.

I enumerated the recurring directory items to watch for incoming results. The output successfully populated with system-root.txt and system-proof.txt, confirming that the exploit triggered under the system context and delivered the final flag.

Capturing the Administrator Flag

To verify the final results of my privilege escalation payload, I authenticated back into the target host using a fresh Evil-WinRM session with Olivia's credentials. I ran the connection command followed by content retrieval cmdlets to inspect the generated proof and flag files.

I enumerated the contents of system-proof.txt to confirm execution under NT AUTHORITY\SYSTEM. Finally, I read system-root.txt to successfully retrieve the root flag, completing the challenge.

Keywords:

eloquia htb

Eloquia Htb walkthrough

Eloquia HTB Writeup

I just solved eloquia from Hack the Box

Eloquia - HackTheBox

qooqle.htb

eloquia.htb

Eloquia failure2ban

Eloquia - Hack the Box Walkthrough

HTB Writeup - Eloquia

Eloquia Hack the Box Writeup

Rooted Eloquia from Hack the Box

Eloquia HTB machine user flag hint

eloquia htb season 9 machine root flag hint

Eloquia - HackTheBox Season 9 Machine Complete Walkthrough

DarkZeroReturn htb

admin@dzcampaigns.htb

dzcampaigns.htb

josh@dzcampaigns.htb

cohort htb walkthrough

cohort htb writeup

cohort.htb

Cohort HTB Write Up

Cohort Hack the Box Writeup

Cohort - HackTheBox Season 11 Complete Walkthrough

HTB Cohort - Season 11 root flag hint

Cohort - HackTheBox Season 11 Machine user flag hint

I just solved Cohort from Hack the Box