Bumblebee - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐☆☆☆ (2/5)

Difficulty Assessment:

• Enumeration: ⭐⭐☆☆☆
• Real-world: ⭐⭐⭐⭐☆
• CVE: ☆☆☆☆☆
• CTF-like: ⭐⭐⭐☆☆

Summary

Bumblebee is an HTB Sherlock (DFIR challenge, sid 554), not a live exploitable box — the task is to reconstruct, from a web server access log and a phpBB SQLite3 database dump, how an external contractor abused Forela’s internal forum and Guest WiFi captive portal to harvest an administrator’s plaintext LDAP credentials. The provided artifact package (incident.tgz) had to be re-downloaded from the HTB API (zip-protected with the password hacktheblue) after the first copy shipped as a 0-byte file. Inside were two files: access.log (697 lines, timestamps in +0100) and phpbb.sqlite3. The story reconstructs as: a contractor account (apoole1) registers on the forum from IP 10.10.0.78, posts a malicious forum entry (post_id 9) pointing victims at a credential-stealing endpoint (http://10.10.0.78/update.php) disguised as part of the Guest WiFi captive-portal flow, an administrator authenticates through it and leaks their plaintext LDAP password (Passw0rd1), that administrator session is then observed adding itself to the Administrator group, and finally a full database backup is exfiltrated.

TL;DR: Guest WiFi captive-portal phishing → forum post (post_id 9) links to a credential-harvesting page (update.php) → administrator submits plaintext LDAP creds (Passw0rd1) → attacker escalates to Administrator group membership → attacker downloads a full database backup, completing the exfiltration.

Reconnaissance

Artifact Acquisition

The task package supplied to the solver did not match the Bumblebee challenge at all — it was a stray transcript for an unrelated Gofer Linux machine (SSH pivots against 10.129.45.45). That transcript was discarded as irrelevant, and the actual challenge was identified from the HTB API itself:

# Locate the Sherlock by keyword search against the HTB API
python3 -c "
import sys; sys.path.insert(0,'lib')
from htb_api import HTBClient
c = HTBClient()
for path in ['/sherlocks?keyword=bumblebee']:
    print(c.get(path))
"

This confirmed sid 554 and surfaced the download URL. The local copy of incident.tgz was 0 bytes, so the archive was re-pulled directly through the API client and unzipped with the known Sherlock zip password:

# Sherlock download endpoints ship the artifact as a password-protected zip
python3 -c "
import sys; sys.path.insert(0,'/app/lib')
from htb_api import HTBClient
c = HTBClient()
u = c.sherlock_download(554)
n, d = c.download_url(u)
open(n, 'wb').write(d)
"

# Extract with the standard Sherlock password (hacktheblue)
cd /tmp/ctf_bumblebee_2M5E/ex
unzip -P hacktheblue incident.zip
tar xzf incident.tgz
find . -type f | head -50
du -sh */

Results: Two artifacts of interest —

• access.log — 697 lines of web server access logs, timestamps in +0100.
• phpbb.sqlite3 — a full phpBB forum database dump, including the phpbb_log audit table.

# Quick shape of the log before diving in
wc -l access.log
head -3 access.log

# Distinct source IPs touching the server
awk '{print $1}' access.log | sort -u

Log Enumeration

The suspicious source IP (10.10.0.78) stood out immediately once cross-referenced against forum activity, and was filtered for authentication and admin-panel traffic:

# Isolate the contractor IP's interaction with login/admin endpoints
grep -n "10.10.0.78" access.log | grep -E "POST|adm/|ucp\.php|mode=login" | sed -n '1,80p'

This traced a registration event, a malicious forum post, and later a GET /update.php request pattern consistent with a credential-harvesting captive-portal redirect served from the same attacker-controlled IP.

Database Enumeration

phpbb_log (the phpBB audit log table) stores log_time as a UTC epoch — this was the key correlating field between the SQLite dump and the access log’s local (+0100) timestamps:

# Walk the phpBB schema and pull the audit trail
import sqlite3, datetime
c = sqlite3.connect('phpbb.sqlite3')
c.row_factory = sqlite3.Row
tabs = [r[0] for r in c.execute(
    "SELECT name FROM sqlite_master WHERE type='table'"
)]
print(tabs)

# phpbb_log.log_time is UTC epoch — convert for correlation with access.log
rows = c.execute("SELECT * FROM phpbb_log ORDER BY log_time").fetchall()
for r in rows:
    print(datetime.datetime.utcfromtimestamp(r['log_time']), dict(r))

Cross-referencing phpbb_log timestamps against the surrounding access.log lines (e.g. lines 673–697, which contain the database backup request) pinned down each step of the attack in UTC.

Initial Foothold

Exploitation Path (Reconstructed)

1. Contractor account registration. The account apoole1 registers on the forum from 10.10.0.78.
2. Malicious forum post. The contractor creates post_id 9, which points victims (via the Guest WiFi captive portal flow) at a credential-stealing page hosted at http://10.10.0.78/update.php.
3. Administrator falls for it. An administrator authenticates through the captive portal and submits their credentials to the stealer endpoint, leaking:

LDAP password (plaintext): Passw0rd1

This login occurred (per phpbb_log / access.log correlation) at:

26/04/2023 10:53:12 UTC

with a distinctive user agent recovered from the corresponding access log line:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

Why this works: the captive portal / update page masquerades as a normal Guest WiFi re-authentication step, so the administrator has no reason to suspect the LDAP credentials they enter are being relayed to 10.10.0.78 rather than the legitimate internal auth service. Once captured, those plaintext LDAP credentials are directly reusable against any LDAP-backed service the administrator has access to — the forum included.

Privilege Escalation

Administrator → Full Compromise

With valid administrator LDAP credentials in hand, the attacker did not need a separate technical privesc bug — the escalation is a straight abuse of legitimate access:

Added self to Administrator group (UTC): 26/04/2023 10:53:51

This event, recovered from phpbb_log, shows the attacker (now authenticated as the compromised administrator, ~39 seconds after the credential-theft login) modifying group membership so their session carries full administrative rights on the forum platform.

Finally, the elevated session is used to pull a full database backup:

Downloaded DB backup (UTC): 26/04/2023 11:01:38

This timestamp was corroborated two ways: once from phpbb_log, and once by decoding the epoch embedded in the backup filename itself, cross-checked against the surrounding lines of access.log:

# Confirm the backup-download timestamp against the raw access log
sed -n '673,697p' access.log | cut -c1-160

# Decode the epoch encoded in the backup archive's filename
python3 -c "import datetime; print(datetime.datetime.utcfromtimestamp(<epoch_from_filename>))"

Why this works: phpBB’s admin panel exposes a “download full backup” feature to any account with Administrator group membership — no additional exploit is required once that membership has been granted, which is exactly why the group-membership-change event is the pivotal escalation step in this timeline rather than a CVE or misconfiguration in the traditional sense.

Attack Chain Summary

Guest WiFi captive portal (phishing lure)
  → apoole1 registers on forum from 10.10.0.78
  → post_id 9 links to credential stealer (http://10.10.0.78/update.php)
  → Administrator authenticates through stealer, leaks plaintext LDAP password "Passw0rd1"
    (26/04/2023 10:53:12 UTC)
  → Attacker adds self to Administrator group
    (26/04/2023 10:53:51 UTC)
  → Attacker downloads full phpBB database backup
    (26/04/2023 11:01:38 UTC)

Tools Used

Key Learnings

Techniques Practiced

• Correlating a UTC-epoch audit table (phpbb_log) against a local-timezone (+0100) web access log to build an accurate timeline
• Tracing a phishing chain from account registration → malicious content post → credential harvesting endpoint
• Recognizing that “privilege escalation” in a DFIR/audit-log context can be a legitimate feature (group self-add) abused with stolen credentials, rather than a technical exploit
• Recovering a challenge artifact through an API client when the locally-provided copy was corrupted/empty, including handling a password-protected archive

Lessons Learned

1. Never trust the artifact as delivered without a sanity check. The first incident.tgz was 0 bytes; verifying file size/hash before diving into analysis would have caught this immediately instead of after wasted effort on an unrelated transcript.
2. Audit-log timestamps and access-log timestamps often live in different time references. phpbb_log.log_time was UTC epoch while access.log was +0100 local — cross-referencing them required an explicit conversion step, not an assumption that “the times will just line up.”
3. A convincing captive-portal phish doesn’t need technical sophistication to be devastating — a plaintext LDAP credential submitted once was enough to cascade into a full database exfiltration within roughly eight minutes of the initial login.

Proof of Ownership

Task Answers (10/10 owned, verified via HTB API):
1. Contractor username: apoole1
2. Account-creation IP: 10.10.0.78
3. Malicious post_id: 9
4. Credential-stealer URI: http://10.10.0.78/update.php
5. Administrator login (UTC): 26/04/2023 10:53:12
6. Plaintext LDAP password: Passw0rd1
7. Administrator user agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ... Chrome/112.0.0.0 Safari/537.36
8. Added self to Administrator group (UTC): 26/04/2023 10:53:51
9. Downloaded DB backup (UTC): 26/04/2023 11:01:38
Flag: <redacted>