Cutaway Security ICS Watch Dog

ATT&CK Rule Tagging Convention

Every detection rule in an ICS Watch Dog curated configuration is tagged with the MITRE ATT&CK technique it is designed to detect. The technique identifier, technique name, and a site-specific detection description are packed into the Sysmon rule name attribute, which Sysmon writes verbatim into the Windows Event Log RuleName field. This page documents the convention so that SOC analysts, SIEM engineers, and threat hunters can extract structured ATT&CK data directly from Sysmon events.

Why Tag Rules With ATT&CK?

Without tagging, Sysmon events tell you what happened (a process started, a file was created, a registry key was modified) but not why the rule fired. Analysts have to maintain external lookup tables that map rule names to attacker techniques, and the mapping drifts as configs evolve.

With ATT&CK tags embedded directly in the rule name:

This convention is a strict superset of the format used by olafhartong/sysmon-modular. SIEM parsers written for that project will work on ICS Watch Dog tags with one minor change (rename the technique_name field to technique), and can optionally surface the additional detection field.

The Format

Sysmon supports only one labeling mechanism per rule: the name attribute. There is no description attribute, no aliases, and no multiple name fields. To carry ATT&CK context, the canonical technique name, and site-specific detection intent into a single attribute, ICS Watch Dog uses a structured delimited format:

technique_id=<ID>[|<ID2>...],technique=<ATT&CK Name>[,detection=<Site Context>]

Field Definitions

FieldRequiredFormatPurpose
technique_id Required ATT&CK technique ID such as T1003.003. Pipe-delimited list for multiple techniques: T1003.003|T1003.006 Machine parseable identifier
technique Required Free text using the canonical short ATT&CK technique name Human readable name without requiring an ATT&CK lookup
detection Optional but recommended Free text describing what specifically triggered the rule Site-specific detection intent (preserves context like "DC ntdsutil execution" or "Cobalt Strike default named pipe")

Examples

Single Technique

A rule that detects ntdsutil execution on a Domain Controller. ntdsutil is the canonical Microsoft tool for AD database manipulation, and one of the most common NTDS.dit credential extraction vectors.

<Image name="technique_id=T1003.003,technique=NTDS,detection=DC ntdsutil execution"
       condition="end with">\ntdsutil.exe</Image>

Multiple Techniques

Some detections cleanly map to more than one ATT&CK technique. The technique_id field uses pipe (|) as the delimiter. The technique field carries the primary ATT&CK technique name. The detection field can explain why multiple techniques apply.

<CommandLine name="technique_id=T1059.001|T1027|T1140,technique=PowerShell,detection=Encoded PowerShell suggests obfuscation"
             condition="contains">-encodedcommand</CommandLine>

ICS ATT&CK Techniques

OT-focused configs use the MITRE ATT&CK for ICS matrix (T0xxx) for industrial protocol monitoring, firmware files, and OT-specific behaviors. Enterprise ATT&CK techniques (T1xxx) are still used for IT-context detections.

<DestinationPort name="technique_id=T0830|T0855,technique=Adversary-in-the-Middle,detection=Process connecting to Modbus TCP port 502"
                 condition="is">502</DestinationPort>

Composite Rule

Composite rules using <Rule> elements with groupRelation="and" tag the parent <Rule> only. Inner field conditions stay untagged to avoid duplicate names in the event log. (Note: as of v3.0 there are no composite rules in the curated configs, but this convention applies if any are added later.)

<Rule name="technique_id=T1003.003,technique=NTDS,detection=Shadow copy NTDS extraction" groupRelation="and">
  <Image condition="end with">\vssadmin.exe</Image>
  <CommandLine condition="contains">create shadow</CommandLine>
</Rule>

Exclude Rules

Exclude rules are noise reduction, not detection. They do not receive ATT&CK tags. Instead, they use a simpler convention with the exclude= prefix and a site-specific context. The exclude= prefix makes intent obvious in SIEM queries when filtering exclusion-related events during threat hunting.

<Image name="exclude=Windows Defender MsMpEng" condition="is">C:\Program Files\Windows Defender\MsMpEng.exe</Image>
<Signature name="exclude=Microsoft signed driver" condition="contains">Microsoft</Signature>
<PipeName name="exclude=lsass system pipe" condition="is">\lsass</PipeName>

Field Constraints

Three rules govern the name attribute content. Validation will flag any rule that violates them.

Length Limits

Forbidden Characters in Field Values

CharacterReason
, (comma)Field separator. Must not appear in technique or detection values.
| (pipe)Multi-technique separator inside technique_id. Must not appear in any other field.

If a description needs a comma, use a semicolon or "and" instead. If a description needs a pipe, rephrase. Equals sign (=) inside values is permitted but discouraged for parser-simplicity reasons.

Coverage in Curated Configs

As of release v3.0, every detection rule in every curated config is tagged. Statistics across all eight curated configurations:

ConfigurationTotal RulesInclude Rules TaggedExclude Rules Tagged
IT Workstation Baseline1197445
IT Server Baseline1157738
Server: AD / Domain Controller15910455
Server: Database + Web Services18813157
OT Baseline14510342
OT Enhanced18514342
OT Advanced20115942
Jump Host / Bastion1018021
Total1,213871342

SIEM Parsing Examples

The structured format makes it easy for SIEM platforms to extract ATT&CK data from the Sysmon RuleName field. Examples for common platforms:

Splunk SPL

index=sysmon
| rex field=RuleName "technique_id=(?<technique_id>[^,]+),technique=(?<technique>[^,]+)(,detection=(?<detection>.*))?"
| eval techniques=split(technique_id, "|")
| stats count by technique_id, technique

Elastic / Kibana KQL + ESQL

FROM logs-windows-sysmon-*
| WHERE winlog.event_data.RuleName LIKE "technique_id=*"
| DISSECT winlog.event_data.RuleName "technique_id=%{tid},technique=%{tname},detection=%{detect}"
| STATS count = COUNT(*) BY tid, tname

Microsoft Sentinel / KQL

SysmonEvent
| where RuleName startswith "technique_id="
| extend parsed = parse_csv(RuleName)
| extend technique_id = extract("technique_id=([^,]+)", 1, RuleName)
| extend technique    = extract("technique=([^,]+)", 1, RuleName)
| extend detection    = extract("detection=(.+)$", 1, RuleName)
| summarize count() by technique_id, technique

Adapt the field separators and regex syntax to match your SIEM. The format is consistent across all ICS Watch Dog curated configs, so a single parser handles every rule.

ATT&CK Matrices Used

Use CaseMatrixID Format
IT and host techniques (process creation, registry, credential dumping, lateral movement) MITRE ATT&CK Enterprise T1xxx or T1xxx.xxx
Industrial protocols, ICS firmware, OT-specific behaviors MITRE ATT&CK for ICS T0xxx
Mixed (rule applies to both IT and OT context) Both, pipe-delimited T1xxx|T0xxx

Maintainer Comment Blocks

Each tagged include rule (or logically grouped set of related rules) is preceded by an XML comment block in the source XML file. These comments document the ATT&CK reference, the rule's purpose, and brief investigation guidance. They exist for maintainers and contributors -- XML comments are not written to the event log.

<!--
  T1003.003 NTDS
  ntdsutil is the canonical Microsoft tool for AD database manipulation.
  Legitimate use is rare on DCs and should be auditable. Investigate every match.
  Reference: https://attack.mitre.org/techniques/T1003/003/
-->
<Image name="technique_id=T1003.003,technique=NTDS,detection=DC ntdsutil execution"
       condition="end with">\ntdsutil.exe</Image>

Read the source XML files to see the full set of comments and the per-rule context they provide.

What Rules Are Not Tagged

The following rule categories intentionally use plain descriptive names rather than ATT&CK structured tags:

References