Some attacks don't fire an alert. They fail a hypothesis. – introducing MARS playbooks

Every SOC I've sat in front of has the same problem: the good hunts live in someone's head, in a wiki page nobody's opened since the last incident, or in the muscle memory of the analyst who just left. The knowledge is real. It's just not a system.

We just shipped Hunt Templates in Mars (we call them playbooks), and I want to nerd out on what's actually inside one – because most "hunt library" features in this space are glorified saved-search folders, and this isn't that.

Why detection rules can't do this alone

Some use cases / detection can't be real-time. Not because the tuning is off – because the answer isn't in one event. It's in five events across three systems, correlated over a long lookback window, with a process you actually have to walk and reason while you are doing it: pull this, filter to that, check whether it also shows up over there, create a new baseline, check if this is new etc.... A detection rule fires on a pattern in a single stream. It can't ask "is this source a domain controller" AND "did that host also request a service ticket for the replication service" AND "has this identity ever done this before" in one shot – that's not detection, that's an investigation. And until now, investigation lived entirely in an analyst's head, redone from scratch every time.

Playbooks are the bridge. Not a replacement for real-time detection – the layer that validates and tests your actual current state for everything too complex to alert on directly: multi-data-point correlations, a process that needs reviewing step by step, a hypothesis that takes four or five (or ten) pivots to confirm or kill. Same rigor as a detection rule, aimed at what a detection rule structurally can't do.

A playbook is a hypothesis, not a query

A Mars playbook isn't a query. It's a hypothesis, structured the way an actual hunter thinks:

Suspected behavior – the specific TTP, mapped to ATT&CK. Our DCSync template opens with T1003.006: a directory replication request (DRSUAPI IDL_DRSGetNCChanges) from a host that isn't a legitimate DC.

What would confirm it – a 4662 object-access event for DS-Replication-Get-Changes* rights, or DRSUAPI/RPC traffic on port 135 / dynamic RPC to a DC, sourced from something that isn't a DC or an allowlisted sync service. That 4662 event only fires if SACL auditing is enabled on the domain object – most environments haven't turned it on, so the playbook flags that as a coverage gap rather than assuming the telemetry exists.

What would disprove it – the same telemetry, except every hit traces back to a real DC or an approved backup/IdM tool.

Likely benign explanation – spelled out up front, so your analyst isn't reinventing "could this just be the backup job" at 2am.

Steps as a codified investigation, not a flat checklist

Then the steps – numbered Query and Pivot operations that explicitly declare their own dependencies ("uses step 1," "uses steps 2, 3"). A playbook is a codified investigation, not a flat checklist:

1. Pull every 4662 event on the DCs referencing replication rights
2. Filter to sources that aren't DCs or on the sync allowlist
3. Correlate DRSUAPI/RPC network sessions into the same set
4. Pull Kerberos 4769 tickets on those hosts to confirm the auth context

Nothing here runs against a copy of your data sitting in our environment. It queries live, at the source, across whatever SIEM, EDR, identity provider, or cloud logs you already run – because that's the entire point of the federated query layer everything in Mars sits on top of. No ingestion pipeline to babysit, no new blind spot to introduce.

Governance, versioning, and run history

Every playbook also carries a lookback window, keeps a run history, and is versioned with a real author. Because "who wrote this hunt, and when did it last change" is a question your auditors – or your incident post-mortem – will eventually ask.

Event-driven, not just manual

Side note: a playbook doesn't just sit in a library waiting to be run manually or on a cron schedule (though it can do both). It can also fire itself off the back of an event – a dark web exposure hit comes in, runs a playbook. CrowdStrike throws an alert, runs a playbook. The hunt becomes the automatic next step after the alert, not a separate task someone has to remember to kick off.

Pull from the built-in MARS library or author your own from scratch (Using AI.. just prompt and edit). Either way it graduates from "a query someone ran once" to a governed, schedulable asset your whole team owns.

Threats have evolved. Detections haven't. We're bridging this gap every day.