Here we go again.
The Harness is Problem #1
The harness is off to work:
The harness definitely got a bit out of line on this attempt.
I told it to begin with the preserved investigation records. It responded with an unnecessary recursive directory listing and revived an earlier assumption about Chrome credential recovery that had already been disproven. Yes, it was clearly informed of that.
That's okay. We'll guide it back to center.
The next instructions restricted the harness to one file, no shell, and one answer: did the saved timeline contain a complaint, ticket, deletion event, or complaint-derived name?
This run, it was a very good boi.
The file contained ordinary browser-search history. An earlier agent had called the timeline incomplete without evidence to support the claim.
This is real progress.
Browser Remnants
The next inventory stayed inside the official ZIP and only classified filenames. It surfaced browser residual stores, without any listed NTFS metadata or unallocated-space sources.
Next stop: Chrome Local Storage.
One name appeared inside a serialized suggestion list. The harness initially omitted it from the report despite printing it in the raw artifact output. Tsk, tsk. A one-command follow-up isolated the context.
Gosh, sometimes it feels like training a puppy.
The name was a browser suggestion. Not a darn password. Not a complaint-derived identity. It was enough to justify a candidate check without opening the door to password guessing.
A Dirty Hive and a Bad Replay
Credential recovery slammed into a Windows registry problem.
The original SYSTEM hive had a valid checksum, but its sequence numbers differed. Regipy replayed the transaction logs and matched the sequence numbers, then mic-dropped an invalid checksum.
Okay. I see what's happening.
The source hive was dirty. The replayed hive was defective.
The originals were never overwritten. I used YARP to replay SYSTEM, SYSTEM.LOG1, and SYSTEM.LOG2 into a separate derived hive, then checked its structure and hash.
A successful registry replay!
Credential recovery returned the same NT hash and the same DPAPI master-key failure with the YARP output. The dirty source hive was no longer our blocker.
The previous VeraCrypt checks had their own issue. printf "%s\n" combined with --key-file=- sent each candidate with a trailing newline. We tested the observed strings plus \n, but not the strings preserved in evidence.
I repeated the command using the two exact values without the newline.
Both were rejected as VeraCrypt/TCRYPT passphrases. This time, the negative results were genuine.
New Model O'Clock
Gemini Flash was used out of convenience. This investigation needed a model with deeper reasoning capabilities.
Before returning to the evidence, I tested the new model with no-tool output, one controlled shell command, and discovery-only access to the connected MCP tools.
It passed with flying colors. I don't know why people use this figure of speech.
The harness discovered the Hayabusa scan_evtx tool without loading it, invoking it, accessing files, or wandering into another tool.
Fingers crossed that all of this work was not lost.
I could have solved this CTF myself a week ago.
Wrong Python
The first full run with the stronger model was healthy, but it checked the system Python and concluded that Impacket was missing.
Impacket was already installed inside the forensic-crypto environment. So, why the discrepancy? The harness asked the wrong interpreter.
I pointed it to the correct Python environment, the preserved case files, and the investigative paths we had already ruled out. The second run was miles better. Sorry, Gem.
Chrome's saved session became the strongest lead. The next run parsed its serialized state and related residuals.
Chrome's session files unearthed VeraSecretVault as the username and pointed to an encrypted credential in Login Data for the challenge origin. The session state did not contain the plaintext password.
Now we had the right artifact.
Proving the Wiring
Before blaming CyberStrike, I gave the harness one job: discover, load, and invoke the forensic-crypto credential-recovery tool one time and one time only.
The wiring passed. CyberStrike found the MCP tool and returned its structured result. The DPAPI master-key authentication failed. I misplaced blame.
The next investigative run combed through the remaining evidence. Despite the earlier correction, the harness checked the wrong Python environment again and decided the required DPAPI tools were unavailable.
I'm willing to look the other way...this time.
I corrected the interpreter path and continued the same session.
HOLY CRAP
It got the flag.
The harness recovered the SecureVault credential through Chrome's DPAPI chain, opened the VeraCrypt backup read-only, and extracted the financial documents.
One invoice looked promising. A binary search for the THM{...} pattern returned nothing because the flag was not stored as PDF text.
The harness rendered the invoice with pdftoppm, opened the resulting image, and found the flag there.
I validated it in TryHackMe.
Finally.