From red-team finding to a tested Sigma rule in an afternoon

Most assessments die at the handover. The report lands, the findings are triaged into a backlog, the detection engineering team reads a paragraph of narrative written for an executive, and six months later the same technique works again because nobody translated "we escalated via an unquoted service path" into something a SIEM can evaluate. The gap is not skill. It is that the two teams produce and consume different artifacts, and nobody owns the conversion.

The conversion is an afternoon's work per finding, and it is the same afternoon every time. What follows is the shape of it.

What the finding has to carry

A finding written for remediation answers "what should we change". A finding written for detection has to answer "what would this have looked like in the logs", and that is a different set of facts. Capture them while the access still exists, because reconstructing them afterwards from memory is how rules end up matching the wrong thing.

• The exact command line, as executed. Not a cleaned-up version for the report.
• The parent process, and the process before that. Most durable rules key on lineage rather than on the leaf.
• Timestamps to the second, and the host. Without these the replay corpus cannot be cut.
• Which of the technique's parameters are essential and which were incidental choice. This is the single most valuable field and it comes from the operator's judgement, not from telemetry.
• The MITRE ATT&CK technique, so the rule joins a coverage map rather than sitting alone.

That last-but-one point deserves the attention. An operator picked a flag, a filename, a working directory. Some of those choices were forced by the technique and some were arbitrary. A detection engineer reading the transcript cannot tell which is which, and if they guess wrong the rule matches this operator and nobody else. Asking the person who ran it takes thirty seconds and is the difference between a rule with a shelf life measured in years and one that expires the moment someone renames a binary.

Writing the rule against the wrong layer first

The first draft is almost always too specific, and that is fine — write it, then climb.

Start from the literal artifact. Then ask what an attacker would have to give up in order to evade the current draft. If the answer is "nothing, they rename the file", the rule is keyed on the wrong thing and you climb a level: to the parent-child relationship, to the API being called, to the resulting state change. Keep climbing until the answer is "they would have to abandon the technique". That is where the rule belongs, and it is usually two or three levels above where the first draft sat.

title: Service binary path modified to a user-writable location
id: 9f3c0a51-4c1c-4c73-9f0e-6f2c1b5d7a48
status: experimental
description: >
  Detects reconfiguration of an existing service to execute from a path the
  invoking user can write. Keyed on the reconfiguration, not on the tool that
  performs it.
references:
  - https://attack.mitre.org/techniques/T1574/
logsource:
  product: windows
  category: process_creation
detection:
  reconfigure:
    Image|endswith: '\sc.exe'
    CommandLine|contains|all:
      - 'config'
      - 'binPath'
  writable_target:
    CommandLine|contains:
      - '\Users\'
      - '\ProgramData\'
      - '\Temp\'
  condition: reconfigure and writable_target
falsepositives:
  - Installers reconfiguring their own service during upgrade. Baseline by parent.
level: high
tags:
  - attack.persistence
  - attack.privilege_escalation

The falsepositives field is not documentation. It is the record of what you already know will fire, and it is what stops the same triage conversation happening every quarter with a different analyst.

Proving it fires

A rule that has never fired is a hypothesis. Two tests separate the two, and both are quick.

The true-positive test is to re-run the technique in a lab and confirm the rule matches. Run it more than once, and vary the incidental parameters — different filename, different directory, different invoking user. If any of those variations evades the rule, you climbed one level too few. This is where the operator's essential-versus-incidental annotation earns its place.

The false-positive test is the one people skip. Replay the rule against a window of real production telemetry — thirty days is a reasonable default — and count the matches. The number tells you what to do next:

• Zero matches: good, assuming the true-positive test passed. Ship it.
• A handful, all explicable: identify the source, add a tuned exclusion keyed on something an attacker cannot trivially assume, and record it in falsepositives.
• Hundreds: the rule is wrong for this environment. Either the behaviour is normal here, or you keyed on something too generic. Do not ship it behind a filter stack; a rule that needs nine exclusions to be usable will be silently disabled within a month.

Backtesting against historical data costs one query and settles the argument before an analyst has to have it at two in the morning.

A detection you have not deliberately triggered is not a control. It is an intention with YAML syntax.

Closing the loop

The rule merges. That is not the end of the workflow, because a rule that fires into a queue nobody triages has changed nothing.

Three things finish the job. The alert needs a response action attached — the analyst who receives it should not have to derive what to do from the rule title. The finding in the report gets a reference to the rule ID, so the remediation ticket and the detection are visibly connected. And the technique goes onto a re-test list, because the correct final state is that the same technique is attempted again later and the rule fires, in production, unannounced.

That last step is what converts an assessment from a document into a measurement. It also tends to expose the uncomfortable cases — the rule that fired correctly into a queue with a four-day backlog, or the rule that was disabled in week three because it was noisy in a business unit nobody consulted. Those are more useful findings than the original escalation path was.

Where the afternoon actually goes

The rule takes twenty minutes to write. The technique replay takes an hour if the lab already exists. Backtesting is one query. The remainder — and it is most of it — is the conversation between the operator who ran the technique and the engineer who has to detect it, about which details mattered.

Protect that conversation. Everything else in this workflow is mechanical and can be templated. That part cannot, and it is the reason the rule works against the next attacker instead of only against the last one.