Active lab. Threat Hunting Labs does not permit public writeups that reveal answers, queries or investigation paths for live cases. This page covers the case at a summary level only. Full notes are kept privately and will be published if the case is opened up.

Unusual activity has been reported in the environment. Investigate and determine what occurred.

The same intrusion as the Threat Hunting and Incident Response tracks, looked at from the detection side. An administrator’s workstation ran two malicious RVTools-branded packages. The discovery route was reported as SEO poisoning. One package used an unsigned MSI custom action to inject a suspended browser and stage further executables, and that browser path later delivered a Python-hosted Cobalt Strike Beacon. The Beacon elevated through an auto-elevating Windows binary, excluded its own runtime from Defender, staged the credential hives from a shadow copy and relaunched itself through a scheduled task. The other package installed a commercial RMM, which used a SYSTEM shell reading commands from standard input to push a second, custom agent as a service. The track has you write rules for each of those behaviours and reconcile them with the Sigma alerts the environment had already raised.
| Field | Value |
|---|---|
| Platform | Threat Hunting Labs, Case 0011 |
| Track | Detection Engineering (14 questions, 12 of them rule builds) |
| Evidence | Elastic Endpoint EDR, Windows event logs, Sigma detection export, Arkime network sessions |
| Query language | KQL (Azure Log Analytics, hard mode) |
| Hosts in scope | 1 workstation, 1 domain controller |
| Companion reading | THL intrusion report, MalBear Labs malware analysis |
Most rules in this track describe a behaviour that spans several events, such as an injection followed by credential access, a shadow link followed by hive copies, or a task registration followed by recurring launches. Hard mode rules out joins and let statements, so each rule has to correlate its stages within a single pass: pull every relevant event type, label each one as a stage, and summarize the stages together so the rule can require all of them, in order, within a time window. Working inside that constraint is the main technical skill the track teaches.
The scoring rewards precision and correct linkage, not just a hit. Rules that caught the right activity but tied the stages together only by host and time consistently scored lower than rules that shared a real identity between stages: a process entity ID, the orchestrating parent, the runtime executable path or a Windows logon session ID. The same goes for evidence quality. Requiring successful outcomes, unbacked target memory or a self-referencing exclusion lifted rules that were otherwise correct.
The track also has you reconcile your own rules with existing detections. The Sigma export raises several alerts for a single process event, and those alerts have to be grouped by their source event before you can triage the activity as one incident.
| Technique | ID |
|---|---|
| User Execution: Malicious File | T1204.002 |
| System Binary Proxy Execution: Msiexec | T1218.007 |
| Process Injection: Asynchronous Procedure Call | T1055.004 |
| Access Token Manipulation: Parent PID Spoofing | T1134.004 |
| Ingress Tool Transfer | T1105 |
| Remote Access Software | T1219 |
| Command and Scripting Interpreter: PowerShell | T1059.001 |
| Command and Scripting Interpreter: Python | T1059.006 |
| Create or Modify System Process: Windows Service | T1543.003 |
| Abuse Elevation Control Mechanism: Bypass User Account Control | T1548.002 |
| Impair Defenses: Disable or Modify Tools | T1562.001 |
| Credentials from Password Stores: Credentials from Web Browsers | T1555.003 |
| OS Credential Dumping: Security Account Manager | T1003.002 |
| Scheduled Task/Job: Scheduled Task | T1053.005 |
| Account Discovery: Domain Account | T1087.002 |
| Remote Services: SMB/Windows Admin Shares | T1021.002 |
| Level | Count |
|---|---|
| Hash values | 0 |
| IP addresses | 0 |
| Domain names | 0 |
| Network / host artefacts | 6 |
| Tools | 4 |
| TTPs | 16 |
Detect the chain, not the artefact. None of the rules here depend on a hash, a domain or a filename. Each one describes a sequence of behaviour, such as an unsigned installer queuing code into a suspended browser, or a browser reading its credential stores moments after being injected. Those rules would still fire if the attacker rebuilt every payload tomorrow.
Link stages by identity, not proximity. Host plus a time window gives you a lead, not a detection. The strong rules carry a real identity from one stage to the next: the injected process’s entity ID, the parent that drove both the shadow link and the copies, the runtime that registered a task and was then launched by it. Processes reuse PIDs in this dataset, so entity IDs are the safe join key.
One process event, many alerts. The existing Sigma coverage fired several rules on the same command line. Grouping alerts by source event turns alert volume back into a count of incidents, and it shows you which behaviours are covered twice and which aren’t covered at all.
Parent fields need their own detection. Several stages set a false parent. A rule comparing the recorded parent with the creator the EDR actually observed catches the browser injection chain no matter which names the attacker borrows.
Report authentication, share access and execution separately. A network logon to a domain controller is not lateral movement. Rules that return each of those as its own confirmed or unconfirmed finding, linked by logon session, keep detection output honest and give responders what they need to decide quickly.
Every stage of this intrusion used signed binaries, borrowed parents or legitimate management software, so none of it can be caught by indicators. The detections that hold up are the ones that follow the behaviour from one event to the next and prove each link with an identity rather than a timestamp.
