Detection Engineering

Detection Engineering & Sigma Rules

> Frameworks: MITRE ATT&CK v16, Sigma Rule Specification (sigmahq.io), Palantir Alerting and Detection Strategy (ADS) > Role: SOC Analyst, Security Engineer > Time: 30-60 min per detection > Output: Sigma detection rule, ADS documentation, ATT&CK coverage mapping

---

1. When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Invoke this skill when any of the following conditions are met:

• New threat intelligence -- A threat report, advisory, or campaign analysis identifies TTPs that require detection coverage in your environment.
• ATT&CK coverage gap analysis -- The team is evaluating which MITRE ATT&CK techniques have detection rules and which do not.
• Detection rule authoring -- A new Sigma rule needs to be written for a specific technique, log source, or behavioral pattern.
• Detection-as-code pipeline -- Detection rules are being managed in version control and need to follow a standardized format for CI/CD integration.
• Post-incident detection improvement -- After an incident or purple team exercise, new detections must be created for techniques that were not caught.
• Detection rule review -- Existing rules need validation against current ATT&CK mappings, log source availability, or Sigma specification compliance.

Do not use when: The task is triaging an active alert (use alert-triage), writing SIEM-specific query syntax without Sigma abstraction (use siem-rules), or performing incident response forensics (use ir-playbook).

---

2. Context the Agent Needs

Before beginning, gather or confirm:

• [ ] Target ATT&CK technique(s): The specific technique or sub-technique IDs to detect (e.g., T1059.001 -- PowerShell).
• [ ] Available log sources: What telemetry is collected? (Windows Event Logs, Sysmon, EDR, cloud audit logs, proxy logs, DNS logs, firewall logs).
• [ ] SIEM platform(s): Target SIEM for rule deployment (Microsoft Sentinel, Splunk, Elastic, Chronicle, QRadar) -- determines Sigma backend conversion target.
• [ ] Environment context: Operating systems, domain structure, cloud providers, key applications in the environment.
• [ ] Existing detection coverage: Current rules, known gaps, previous false positive history for similar detections.
• [ ] Detection priority: Is this for a known active threat, proactive coverage expansion, or compliance requirement?
• [ ] Organizational naming conventions: Rule ID format, severity taxonomy, and tagging standards used by the detection engineering team.

If the ATT&CK technique is provided but other context is missing, proceed with conservative assumptions (Windows enterprise environment, Sysmon + Windows Security logs available) and note assumptions in the output.

---

3. Process

Step 1: ATT&CK Technique Analysis

Decompose the target ATT&CK technique to understand what must be detected.

1. Identify the tactic(s) the technique serves (e.g., T1059.001 serves Execution -- TA0002)
2. Review the technique's procedure examples to understand real-world usage patterns
3. Identify the data sources and data components ATT&CK maps to this technique (e.g., Process Creation, Command Execution, Script Execution)
4. Determine which log sources in the environment provide the required data components
5. Identify sub-techniques and determine if the detection should cover the parent technique broadly or target a specific sub-technique

ATT&CK Technique Analysis:
- Technique ID:       [T1059.001]
- Technique Name:     [Command and Scripting Interpreter: PowerShell]
- Tactic(s):          [Execution (TA0002)]
- Data Sources:       [Process (Process Creation), Command (Command Execution), Script (Script Execution)]
- Required Log Sources: [Sysmon EventID 1, Windows Security 4688, PowerShell 4104/4103]
- Sub-techniques:     [.001 PowerShell, .002 AppleScript, .003 Windows Command Shell, ...]
- Detection Scope:    [Sub-technique specific | Parent technique broad]

Step 2: Detection Logic Design

Design the detection logic before writing the rule. Consider:

Detection approaches (ordered by reliability):

| Approach | Description | Example | |----------|-------------|---------| | Exact match | Known-bad indicator (hash, command string) | Specific malware hash in process creation | | Behavioral pattern | Sequence of actions characteristic of the technique | PowerShell spawning net.exe followed by nltest.exe | | Anomaly from baseline | Deviation from established normal behavior | PowerShell execution from a user who has never run PowerShell | | Threshold-based | Volume or frequency exceeding expected levels | More than 10 failed logons in 5 minutes | | Correlation | Multiple low-fidelity signals combining to high-fidelity | Suspicious logon + process creation + network connection to rare destination |

True positive / false positive analysis:

Before writing the rule, enumerate:

• Known legitimate use cases that will match the detection logic (expected false positives)
• Evasion techniques an adversary might use to avoid the detection (known blind spots)
• Tuning parameters that can reduce false positives without creating blind spots

Step 3: Author the Sigma Rule

Write the detection rule following the Sigma specification (sigmahq.io).

Sigma Rule Structure:

title: Suspicious PowerShell Encoded Command Execution
id: b5c2a0a0-7d5a-4b8c-9c3f-1a2b3c4d5e6f
status: experimental
description: |
    Detects execution of PowerShell with encoded command-line arguments,
    a technique commonly used by adversaries to obfuscate malicious
    commands and evade simple string-based detections.
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_powershell_exe
author: Detection Engineering Team
date: 2025/01/15
modified: 2025/01/15
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_process:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
    selection_encoded:
        CommandLine|contains:
            - '-enc'
            - '-EncodedCommand'
            - '-ec '
    filter_legitimate:
        ParentImage|endswith:
            - '\sccm\\'
            - '\ccmexec.exe'
        CommandLine|contains:
            - 'ConfigurationManager'
    condition: selection_process and selection_encoded and not filter_legitimate
falsepositives:
    - SCCM/ConfigMgr client operations
    - Some legitimate IT automation scripts using encoded commands
    - Software deployment tools
level: medium
fields:
    - CommandLine
    - ParentImage
    - ParentCommandLine
    - User
    - Computer

Sigma rule field requirements:

| Field | Required | Description | |-------|----------|-------------| | title | Yes | Short descriptive name (max 256 chars) | | id | Yes | UUIDv4, globally unique identifier | | status | Yes | experimental, test, or stable | | description | Yes | Detailed explanation of what the rule detects and why | | references | Recommended | URLs to ATT&CK technique, blog posts, threat reports | | author | Yes | Rule author name or team | | date | Yes | Creation date in YYYY/MM/DD format | | modified | Recommended | Last modification date | | tags | Yes | ATT&CK mappings using attack.tXXXX.XXX format | | logsource | Yes | Category, product, and optionally service | | detection | Yes | Selection criteria, filters, and condition logic | | falsepositives | Recommended | Known sources of false positives | | level | Yes | informational, low, medium, high, critical | | fields | Recommended | Fields to include in alert output for analyst context |

Sigma detection logic operators:

| Operator | Usage | Example | |----------|-------|---------| | |contains | Substring match | CommandLine|contains: '-enc' | | |endswith | Suffix match | Image|endswith: '\powershell.exe' | | |startswith | Prefix match | TargetFilename|startswith: 'C:\Windows\Temp' | | |re | Regular expression | CommandLine|re: '(?i)invoke-(mimikatz|expression)' | | |cidr | CIDR network match | SourceIP|cidr: '10.0.0.0/8' | | |all | All values must match | CommandLine|all|contains: ['-nop', '-w hidden'] | | |base64offset | Base64 encoded value match | CommandLine|base64offset|contains: 'IEX' | | condition | Boolean logic | selection_a and selection_b and not filter_main |

Step 4: Build ADS Documentation

Document the detection using the Palantir Alerting and Detection Strategy (ADS) framework. ADS ensures every detection has operational context beyond the rule itself.

ADS Framework Components:

Goal

State the objective of the detection in one to two sentences. What adversary behavior are you trying to identify?

> Example: Detect the use of encoded PowerShell commands, which adversaries use to obfuscate malicious payloads and evade command-line logging inspection.

Categorization

Map the detection to the relevant framework classifications.

| Field | Value | |-------|-------| | MITRE ATT&CK Tactic | Execution (TA0002) | | MITRE ATT&CK Technique | T1059.001 -- Command and Scripting Interpreter: PowerShell | | Kill Chain Phase | Installation / Actions on Objectives | | Data Sources | Process Creation (Sysmon EID 1, Security EID 4688) |

Strategy Abstract

Describe at a high level how the detection works without getting into implementation specifics. An analyst or manager should understand the approach from this section alone.

> Example: This detection monitors process creation events for instances of powershell.exe or pwsh.exe where the command line contains encoded command parameters (-enc, -EncodedCommand). Filters exclude known legitimate automation tools (SCCM) to reduce false positives.

Technical Context

Provide the technical details an analyst needs to understand the alert. Explain the underlying technology, why the behavior is suspicious, and what normal versus malicious usage looks like.

> Example: PowerShell's -EncodedCommand parameter accepts a Base64-encoded string and executes it as a command. Adversaries use this to bypass command-line logging that looks for plaintext strings like "Invoke-Mimikatz" or "Net.WebClient". Legitimate use exists (SCCM, some deployment tools) but is typically from known parent processes and contains identifiable content when decoded.

Blind Spots and Assumptions

Document what this detection will NOT catch and what assumptions it relies on.

• Assumption: PowerShell process creation events are being logged (Sysmon installed or advanced audit policy enabled for process creation with command-line logging).
• Assumption: Command-line arguments are captured in full (not truncated by logging configuration).
• Blind spot: PowerShell execution via the .NET System.Management.Automation namespace directly (no powershell.exe process).
• Blind spot: Encoded commands invoked through WMI or scheduled tasks where the parent process is not filtered.
• Blind spot: Use of alternative encoding or obfuscation that does not use the -EncodedCommand flag.

False Positives

List known sources of false positives and recommended tuning actions.

• SCCM/ConfigMgr client operations (filtered in rule)
• IT automation scripts using encoded commands for safe transport of complex strings
• Software packaging tools (Chocolatey, some MSI wrappers)

Tuning recommendation: Add parent process exclusions for validated automation tools after confirming their encoded command usage is benign. Document each exclusion with a ticket reference.

Priority

Define the alert priority and its justification.

| Priority | Justification | |----------|---------------| | Medium | Encoded PowerShell is a common adversary technique but also has legitimate uses. Priority should escalate to High if combined with other indicators (unusual parent process, network connection to rare domain, execution from temp directory). |

Validation

Describe how to test that this detection works correctly.

1. True positive test: Open a command prompt and execute powershell.exe -EncodedCommand ZQBjAGgAbwAgACIAdABlAHMAdAAiAA== (Base64 of echo "test"). Verify the alert fires.
2. True negative test: Execute powershell.exe -Command "Get-Process" (no encoding). Verify no alert fires.
3. Filter validation: If SCCM is in use, verify that SCCM client operations do not trigger the alert.
4. ATT&CK technique coverage: Validate with atomic red team test T1059.001 (https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1059.001/T1059.001.md).

Response

Define the analyst response procedure when this alert fires.

1. Identify the user and host: Determine who executed the command and on which system.
2. Decode the encoded command: Base64-decode the command-line argument to reveal the actual payload.
3. Assess the parent process: Is the parent process expected (explorer.exe, cmd.exe from a known admin) or suspicious (wmiprvse.exe, mshta.exe, winword.exe)?
4. Check for additional indicators: Query the SIEM for related events on the same host within a +/- 30 minute window (network connections, file writes, additional process creations).
5. Determine disposition: Classify as True Positive, Benign True Positive, or False Positive.
6. Escalate if TP: If malicious, escalate to Tier 2/IR team with decoded command, parent process chain, and correlated events.

Step 5: Detection Coverage Heatmap Methodology

Map detection coverage against the ATT&CK matrix to identify gaps.

Coverage levels:

| Level | Color | Definition | |-------|-------|------------| | None | White | No detection rule exists for this technique | | Theoretical | Light Yellow | A rule exists but has not been validated or tested | | Tested | Light Green | Rule has been validated with synthetic test data (e.g., Atomic Red Team) | | Operational | Green | Rule is deployed in production, has been tuned, and has generated actionable alerts | | Robust | Dark Green | Multiple complementary rules cover different procedure examples; rule has caught real-world activity |

Heatmap construction process:

1. Export the current ATT&CK matrix for the relevant platform (Enterprise, Cloud, ICS) from the ATT&CK Navigator (https://mitre-attack.github.io/attack-navigator/)
2. For each technique, assess the current detection coverage level based on deployed rules
3. Assign a coverage score (0-4) corresponding to the levels above
4. Prioritize gap closure using threat intelligence: techniques used by threat actors relevant to your industry should be addressed first
5. Use the ATT&CK Navigator layer file format (JSON) to visualize coverage as a heatmap
6. Review and update the heatmap quarterly or after major detection engineering sprints

Gap prioritization factors:

| Factor | Weight | Description | |--------|--------|-------------| | Threat intelligence relevance | High | Techniques actively used by threat groups targeting your industry | | Log source availability | High | Data exists to detect the technique but no rule has been written | | Attack chain position | Medium | Early-stage techniques (Initial Access, Execution) catch attacks sooner | | Ease of detection | Medium | Some techniques have clear observable artifacts; prioritize those first | | Compliance requirements | Medium | Regulatory frameworks may mandate detection of specific techniques |

Step 6: Detection-as-Code Practices

Manage detection rules as code artifacts in version control.

Repository structure:

detections/
  sigma/
    execution/
      proc_creation_win_powershell_encoded_command.yml
      proc_creation_win_mshta_execution.yml
    persistence/
      registry_

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [UnitOneAI](https://github.com/UnitOneAI)
- **Source:** [UnitOneAI/SecuritySkills](https://github.com/UnitOneAI/SecuritySkills)
- **License:** MIT
- **Homepage:** https://www.unitone.ai

Install and usage instructions live in the source repository linked above.