THM Management Wants a Word

root 11 August 2026
TryHackMe Difficulty · Hard Windows DFIR Room 214 Status · Solved

Case File №214 — Hacker Holidays, Day 14 Management Wants a Word

A laptop left behind after an early checkout. A guest named Vera. A KAPE triage image, a browser that remembers more than it should, and a 100 MB file called backup that isn't a backup at all. This is the full trail — including the dead ends.

Subject
Vera — Room 214
Evidence
KAPE triage image
Core artifact
VeraCrypt container
Outcome
Flag recovered
01 — Intake

What we were handed

Housekeeping found a laptop after an early checkout, registered to a guest named Vera. IT ran a full KAPE triage before wiping the machine for the next guest. The brief: hunt down the artifacts scattered across the disk, follow them to a password Vera never meant to leave behind, and use it to open something she was keeping very quiet.

An in-thread hint from @0xMia flagged two things worth chasing: that "a browser will remember things you never told anyone else," and that a hidden file doesn't always need a password cracker — sometimes it just needs a good memory. A stray detail — the number 1.26.29 — was dropped with no explanation.

Artifact
What it turned out to be
Yield
SAM / SYSTEM / SECURITY
Registry hives — held the bootkey and Vera's local password hash.
key evidence
vera/ntuser.dat.LOG1
Only the transaction log was collected — the live hive itself was gone.
incomplete
AppData/Roaming/…/Protect/
DPAPI master-key blobs tied to Vera's profile SID.
key evidence
Chrome/User Data/Default/Web Data
Form autofill only — a red-herring "username" value, no saved logins.
misleading
Chrome/User Data/Default/Login Data
The real saved-password store — DPAPI-encrypted, needed the local password to open.
key evidence
Documents/backup
104,857,600 bytes, ~7.9999 bits/byte entropy. Not a backup — a VeraCrypt volume.
the vault
02 — Chain of Custody

The trail, wrong turns included

The clean version of this solve is four steps long. The real version has a couple of hours of me arguing with AES-XTS in the middle. Both are below.

1

Lead

The autofill entry

Web Data → autofill held exactly one row: field name username, value VeraSecretVault. Looked exactly like the "browser remembers what it shouldn't" clue — a password typed into a field the site hadn't marked as sensitive.

2

Lead

A site to pin it to

Preferences and DIPS both placed Vera on http://bytelotus.thm:8080, with a form on that page marked as filled. Now there was a candidate password and a place it plausibly belonged.

3

Lead

Documents/backup is a VeraCrypt volume

100 MB, byte-value entropy of 7.9999/8 — indistinguishable from random. No legible header. Every sign of a VeraCrypt (or TrueCrypt) container rather than an actual backup file.

✕

Dead end

Hand-rolled PBKDF2 + AES-XTS header decryption

Implemented the VeraCrypt header spec myself — PBKDF2-HMAC over the 64-byte salt, AES-XTS decrypt of the 448-byte encrypted header, checked for the VERA magic. Tried VeraSecretVault and variants against SHA-512 / SHA-256 / RIPEMD-160 / BLAKE2s at their default iteration counts. Nothing.

for pw in candidates:
    for hashname, iters in [("sha512",500000), ("sha256",500000),
                             ("ripemd160",655331), ("blake2s",500000)]:
        dk  = pbkdf2(pw, salt, iters, 64, hashname)
        dec = xts_decrypt(dk, sector=0, enc_header)
        # dec[:4] != b'VERA' — every single time
✕

Dead end

Reading 1.26.29 as a PIM value

Guessed the stray "version number" was really a Personal Iterations Multiplier in disguise — stripped the dots (12629), ran VeraCrypt's PIM formula (15000 + PIM×1000 ≈ 12.6M iterations), retried the password list. Still nothing — and each attempt now took ~15 seconds instead of milliseconds.

!

Turning point

The math was fine. My code wasn't.

Installed hashcat to sanity-check the approach, and fed my own decryptor hashcat's published example hash with its known-correct password (hashcat). It failed. That proved the bug was in my hand-rolled XTS implementation, not in the password guesses — the whole manual-crypto branch of the investigation had been unreliable from the start.

hashcat -m 13721 -a 0 example_header.bin wordlist.txt
example_header.bin:hashcat          Status: Cracked
# my own decrypt(salt, header, "hashcat") → garbage. Verdict: trust the tool, not the script.
4

Lead

SAM + SYSTEM → minivera

The bootkey from SYSTEM unlocks the password hashes in SAM. Cracking Vera's hash surfaced her actual Windows account password: minivera.

5

Lead

minivera → DPAPI → Chrome's real vault

That password unlocks the DPAPI master key tied to Vera's profile SID in AppData/Roaming/Microsoft/Protect/. That master key decrypts Chrome's actual saved-credential store — not the autofill red herring — for bytelotus.thm:8080. The real vault password was there all along: Wh4t1sV3raD0inG0nTh1sH0st.

6

Lead

1.26.29 was never a code

It's just the VeraCrypt release version — confirmed against VeraCrypt's own downloads page, which lists veracrypt-console-1.26.29-* builds verbatim. Flavor text, not a cipher. It only pointed at which tool to use.

7

Lead

Mount, browse, find the invoice

Documents/backup mounts cleanly with Wh4t1sV3raD0inG0nTh1sH0st. Inside: a FAT32 filesystem containing secret_financial_documents/important_invoice_byte_lotus.pdf. The flag was embedded in the invoice image itself.

03 — Post-Mortem

What each clue actually meant

"a browser will remember things you never told anyone else"
Not the plaintext autofill table — the DPAPI-protected saved-password store, unlockable only once you have the user's real login password.
"not every hidden file needs a password cracker, some just need a good memory"
Same clue restated: don't brute-force the container — recall (crack) the Windows password once, and everything downstream unlocks for free.
the username = VeraSecretVault autofill entry
A genuine artifact, but a decoy — it primed the "browser secrets" theory without being the actual secret.
"why did Patch tell me this version number 1.26.29"
Literally VeraCrypt's version string — its only job was to name the encryption in play, not encode a PIM or password.
04 — Evidence Recovered

The flag

Extracted from important_invoice_byte_lotus.pdf inside the mounted volume.

Recovered flag
THM{1t_w4s_V3r4_A11_Al0ng?!}

Solve path, condensed

  1. Crack Vera's SAM hash (with the SYSTEM bootkey) → local password minivera.
  2. Decrypt the DPAPI master key for her profile using that password.
  3. Open Chrome's real saved-credential store → vault password for bytelotus.thm:8080: Wh4t1sV3raD0inG0nTh1sH0st.
  4. Mount Documents/backup as a VeraCrypt volume with that password.
  5. Read secret_financial_documents/important_invoice_byte_lotus.pdf for the flag.

Case №214 — closed · Hacker Holidays, Day 14