// ThreatHuntingLabs  ·  writeup

From SEO Poisoning to Custom RMM and Cobalt Strike — Detection Engineering (Case Lab 3/4)

ThreatHuntingLabs EDR TelemetryKQL

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.

Scenario

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

Executive Summary

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.

Case Profile

FieldValue
PlatformThreat Hunting Labs, Case 0011
TrackDetection Engineering (14 questions, 12 of them rule builds)
EvidenceElastic Endpoint EDR, Windows event logs, Sigma detection export, Arkime network sessions
Query languageKQL (Azure Log Analytics, hard mode)
Hosts in scope1 workstation, 1 domain controller
Companion readingTHL intrusion report, MalBear Labs malware analysis

Skills Practiced

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.

MITRE ATT&CK

TechniqueID
User Execution: Malicious FileT1204.002
System Binary Proxy Execution: MsiexecT1218.007
Process Injection: Asynchronous Procedure CallT1055.004
Access Token Manipulation: Parent PID SpoofingT1134.004
Ingress Tool TransferT1105
Remote Access SoftwareT1219
Command and Scripting Interpreter: PowerShellT1059.001
Command and Scripting Interpreter: PythonT1059.006
Create or Modify System Process: Windows ServiceT1543.003
Abuse Elevation Control Mechanism: Bypass User Account ControlT1548.002
Impair Defenses: Disable or Modify ToolsT1562.001
Credentials from Password Stores: Credentials from Web BrowsersT1555.003
OS Credential Dumping: Security Account ManagerT1003.002
Scheduled Task/Job: Scheduled TaskT1053.005
Account Discovery: Domain AccountT1087.002
Remote Services: SMB/Windows Admin SharesT1021.002

Pyramid of Pain

LevelCount
Hash values0
IP addresses0
Domain names0
Network / host artefacts6
Tools4
TTPs16

Takeaways

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.

Conclusion

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.