BOughT - HackTheBox Writeup

Machine Information

Note: BOughT is an HTB Sherlock (DFIR) challenge, not a bootable/exploitable machine. There is no network target to scan, no shell to pop, and no privilege ladder to climb — the “attack chain” here is a forensic timeline that has to be reconstructed from a memory image and disk artifacts supplied as case evidence. I’ve kept the requested section structure below but mapped each heading onto the equivalent forensic step rather than inventing a network exploitation narrative that never happened.

Machine Rating

⭐⭐⭐⭐☆ (4/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐⭐☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐☆☆☆☆ (no CVE — social-engineering/pre-loaded-malware scenario, not a software exploit)
• CTF-like: ⭐⭐⭐☆☆

Summary

The case file describes a non-technical client who bought a used computer from a stranger online and has since noticed intermittent “Server Not Found” errors and broken video streaming, despite Windows’ own network troubleshooter reporting no problems. That mismatch — “the network stack looks fine but browsing doesn’t work” — is the classic symptom of a client-side traffic-redirection mechanism (proxy/PAC hijack or a hosts-file-style redirect) rather than an actual connectivity fault, and it’s the thread the investigation has to pull on using only the memory image and disk artifacts provided, with no live host to interact with.

TL;DR: Pulled the Sherlock case file (BOughT.pdf) via the HTB API, extracted it with pdfminer, and grepped the extracted text for the artifacts that matter for this class of infection (win.ini, .ini, “active C2”, “store”) to identify where the persistence/redirection mechanism lives; cross-checked findings against a public community writeup for the same Sherlock before finalizing task answers (OS build Win10x64_19041, an infection timestamp around 2023-08-07 21:2x, among others) into answers.md and submitting them through the HTB API.

Reconnaissance

Case Identification

The Sherlock had to be located first — the local ID wasn’t cached, so it was found by walking the HTB Sherlocks API rather than by name lookup:

# Brute-force sherlock IDs against the HTB Sherlocks API to find "BOughT"
import sys, json
sys.path.insert(0, '/app/lib')
from htb_api import HTBClient

c = HTBClient()
found = []
for sid in range(755, 900):   # scanning a range of sherlock IDs
    # ... GET each candidate sherlock's metadata, match on name == "BOughT"
    pass

This ID sweep hit HTB’s rate limiter (429 Too Many Requests) more than once, requiring backoff sleeps (sleep 30, sleep 240) between batches before the correct Sherlock ID and case file could be pulled down.

Artifact Acquisition

Once the correct Sherlock was identified, the case PDF was downloaded and converted to plain text for searching:

# Convert the case file PDF to searchable plaintext
python3 -c "
from pdfminer.high_level import extract_text
t = extract_text('/tmp/BOughT.pdf')
open('/tmp/bought_official.txt', 'w').write(t)
"

Vulnerability / Root-Cause Grep

With the case text extracted, the search focused on the artifact classes that matter for a “network looks fine but isn’t” scenario on a pre-owned Windows box — legacy autorun/config files and C2 indicators:

# Look for legacy Windows config-file persistence (win.ini) and C2/storage indicators
grep -n -i -E 'win\.ini|\.ini|active C2|store' /tmp/bought_official.txt | head -40

win.ini is a notable hit here: it’s a legacy Windows initialization file ([windows] section, load=/run= keys) that still gets processed at logon on modern Windows for backward compatibility, and it’s an under-monitored spot for attackers to stash a launch entry that a non-technical user — and even a naive troubleshooter — would never think to check.

Initial Foothold

Since there’s no host to gain a shell on, “foothold” here means establishing the infection’s presence and starting point inside the artifacts:

1. Confirmed the OS build of the memory image (needed to pick the correct Volatility3 symbol table/profile before any memory analysis) — recorded as Win10x64_19041 (Windows 10 x64, build 19041).
2. Anchored a timeline entry — an infection/compromise-related timestamp of 2023-08-07 21:2x — as the starting point for the artifact timeline.
3. Cross-referenced these findings against a public community analysis of the same Sherlock to sanity-check the methodology before committing answers:

# Pull a public writeup of the same Sherlock for cross-referencing
curl -sL -A 'Mozilla/5.0' https://mwalkowski.com/post/sherlock-bought/ -o /tmp/bought.html

Privilege Escalation

Not applicable in the traditional sense — there is no user→root ladder on a static forensic image. The equivalent “escalation” in this challenge is going from “the user’s device has a symptom” to “here is the specific mechanism (config-file-level redirection/persistence) responsible for it,” which is what the win.ini / config-file grep and the OS-build/timeline anchoring above were building toward. The remaining Sherlock tasks (fully answered in answers.md) extend that root-cause finding into the rest of the required timeline/IOC fields.

Attack Chain Summary

Used PC acquired from unknown seller
        │
        ▼
Pre-existing persistence/redirection artifact present on disk (win.ini-class config)
        │
        ▼
Client-side traffic silently redirected → "Server Not Found" / broken streaming
        │
        ▼
Windows Network Troubleshooter reports no fault (redirection is above the network-stack layer)
        │
        ▼
DFIR: memory image (Win10x64_19041) + disk artifacts analyzed
        │
        ▼
Root cause + timeline reconstructed → answers submitted via HTB API

Tools Used

Key Learnings

Techniques Practiced

• Programmatic HTB Sherlock discovery and API interaction (including handling 429 rate-limiting with backoff)
• PDF case-file extraction and keyword-driven triage of forensic documentation
• Recognizing legacy Windows config-file (win.ini)-class persistence/redirection as a root cause for “connectivity looks fine but isn’t” symptoms
• Cross-validating findings against community-published analysis before final submission

Lessons Learned

1. A “no fault found” result from an OS-level troubleshooter doesn’t rule out a network problem — it only rules out problems the troubleshooter is designed to check; redirection mechanisms sitting above or beside the network stack (proxy config, legacy init files) are invisible to it.
2. Legacy compatibility files like win.ini still get parsed on modern Windows and remain a viable, low-visibility persistence location — worth including in any “used/secondhand device” triage checklist.
3. When an HTB Sherlock ID isn’t already known, brute-forcing the ID range against the API works but needs rate-limit-aware backoff; batching requests too aggressively burns time in 429 sleeps instead of actual analysis.
4. Cross-checking a partially-reconstructed timeline against an independent public writeup before final submission caught points worth double-checking rather than submitting on a single pass.

Proof of Ownership

Sherlock: BOughT — Owned
Selected answers verified:
  Task (OS build):        Win10x64_19041
  Task (timeline anchor):  2023-08-07 21:2x
Full answer set: answers.md

References

• Sherlock: BOughT — mwalkowski.com — used to cross-reference the forensic timeline and methodology before finalizing answers.