Quiet as the Grave: A Threat Hunt Case Study (TryHackMe SOC)

What this is

Quiet as the Grave is a TryHackMe threat-hunting scenario, again set at TryHatMe Studios. Unlike an alert-driven SOC queue, a hunt starts from a hypothesis, not an alert: threat intelligence attributed to a group called Pinstripe Moth suggested the studio may have been compromised through a lure sent to a developer, with the actor then using valid credentials and ordinary Windows tooling to move toward the studio's unreleased NeuralNexus work.

The room builds its own attack chain interactively, stage by stage, and ends by handing the analyst an AI-generated threat report summarizing the findings. That last part is what makes this scenario worth a separate writeup from Repossessed: the AI report got two things wrong, and catching those errors rather than accepting a confident-sounding summary is the actual lesson here.

The attack chain

Stage names and technique IDs below are corrected from the room's own display, where verification during the hunt showed otherwise: stage 3 is persistence (T1547, Run Key), not T1137 as initially shown; stage 7 is a denied Kerberos ticket request against the domain controller, not a confirmed authentication, based on PowerShell error event 4100 ("Access is denied").

Checking the AI-generated threat report

This room hands the analyst a polished, AI-written threat report once the chain is built, styled as an executive summary from a "Senior Threat Hunter." Confident formatting is not the same as correct content, and this one had two concrete errors worth catching rather than citing.

The second error matters more than the first: it's the difference between "the actor reached the domain controller" and "the actor tried and failed to reach the domain controller." A report that overstates the second as the first inflates both the severity rating and the remediation urgency exactly the kind of overclaim the honest-wording principle exists to catch, whether the author is a person or a model.

The hypothesis verdict

The hunt asks directly: has the hypothesis been proven or disproven?

For the lure-to-exfiltration-attempt path, the evidence supports proven: a developer-targeted lure led to execution, persistence, discovery, two hops of lateral movement using a valid service account, and an attempted exfiltration of staged data, each stage backed by a specific event, not an inference.

For the domain-controller piece specifically, the honest answer is narrower: the actor attempted Kerberos ticket requests against the DC and was denied. Folding that into a blanket "proven" verdict, the way the AI report's language invites, overstates what actually happened. The right framing keeps both parts visible: the hypothesis holds for the path that reached NeuralNexus's release materials, and stays unconfirmed specifically denied, not merely unproven for the deeper domain compromise the report implied.

Indicators and queries, by stage

What the logs could not prove

• How the lure reached s.reyes. The script's execution from Explorer is observed; the delivery mechanism (email, a shared link, a trojanized package) is not.
• Where svc-studioops credentials came from. The account is used for lateral movement starting at stage 5; nothing in the available logs shows how it was obtained.
• Whether the domain controller was actually reached. This is the correction above, restated as a limitation: event 4100 shows a denial, not a silent success elsewhere that simply wasn't logged. State the denial; don't assume a quieter compromise behind it without evidence.
• What review-cache.zip actually contained. The archive-build command is observed; its contents, and therefore the real scope of data exposure, are not.

What this exercise was for

The technical chain here lure, beacon, Run key persistence, two hops of lateral movement with a valid service account, a denied Kerberos attempt, staged and uploaded data is a useful pattern on its own. But the specific skill this room tests is different from Repossessed: it's whether an analyst will verify a confident AI-written summary against the raw timestamps and error codes, or just forward it. A 30-second arithmetic error and an overstated domain-compromise claim both sat inside professional-looking prose; neither survived a direct check against the logs.

This is a TryHackMe threat-hunting scenario, not a real intrusion, and the "Senior Threat Hunter" byline on the AI report is itself part of the simulation. It's written up here as a demonstration of verification method, not blind trust in generated reports, including ones a tool like this produces, in keeping with the room's own guidance on sharing writeups.