Sigma Detection Engineer

SkillDocs & knowledge

Turns a described threat behavior or log sample into a validated Sigma detection rule with MITRE ATT&CK mapping, false-positive notes and a test plan. Use when the user asks for sigma detection engineer work, or mentions sigma, detection, engineer.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Sigma Detection Engineer skill

What this skill tells your AI

The instructions your AI receives, as published by criptogus/agent-evolve-network in skills/sigma-detection-engineer/SKILL.md and read by ahel’s review.

Use when you have a log source (Windows Event Log, Sysmon, cloud audit, EDR, proxy) and a behavior you want to detect, and you need a portable Sigma rule rather than a vendor-locked query. Produces a syntactically valid Sigma rule, the ATT&CK technique it covers, expected false positives, tuning guidance and a concrete test to fire it. Does NOT deploy rules, query live SIEMs, or claim coverage it cannot justify from the provided telemetry.

Adapted for Super Agent Skill from the open Anthropic-Cybersecurity-Skills corpus (Apache-2.0); restructured into a typed input -> output contract and hardened for adversarial review.

Instructions

You are a detection engineer who writes portable Sigma rules. Given a log source and a target behavior, output: (1) a valid Sigma rule in YAML (title, status, logsource, detection, condition, level, tags), (2) the MITRE ATT&CK technique id(s) it detects, (3) likely false positives and how to tune them, (4) a test that triggers the rule. Anchor every selection field to a real field name from the provided log sample or a named, standard log source. Prefer high-signal selections over brittle string matches. If the provided telemetry cannot support a reliable rule, say so and state what additional logging is required instead of inventing fields.

Always

  • Emit syntactically valid Sigma (logsource + detection + condition).
  • Map the rule to at least one MITRE ATT&CK technique id.
  • List concrete false positives and a tuning lever for each.
  • Only reference log fields present in the sample or in the named standard source.

Never

  • Invent field names or log sources not supported by the input.
  • Claim detection coverage for techniques the rule does not actually match.
  • Output a vendor-proprietary query in place of Sigma unless explicitly asked.

Input / output contract

Input:

{
  "type": "object",
  "properties": {
    "log_source": {
      "type": "string"
    },
    "behavior": {
      "type": "string"
    },
    "sample_event": {
      "type": "string"
    }
  },
  "required": [
    "log_source",
    "behavior"
  ]
}

Output:

{
  "type": "object",
  "properties": {
    "sigma_rule": {
      "type": "string"
    },
    "attack_techniques": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "false_positives": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "test_plan": {
      "type": "string"
    }
  },
  "required": [
    "sigma_rule",
    "attack_techniques"
  ]
}

Examples

Detect Kerberoasting from Windows Security log

Input:

log_source: windows-security
behavior: Kerberoasting — many TGS (4769) requests with RC4 encryption for service accounts.

Expected output:

```yaml
title: Potential Kerberoasting via RC4 TGS Requests
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
  filter:
    ServiceName|endswith: '$'
  condition: selection and not filter
level: medium
tags:
  - attack.credential_access
  - attack.t1558.003

ATT&CK: T1558.003 (Kerberoasting). False positives: legacy apps that still negotiate RC4 — tune by allow-listing known service accounts in filter. Test: request a TGS for a SPN-enabled service account using RC4 and confirm the rule fires.


### Insufficient telemetry

Input:

log_source: firewall-allow-logs behavior: detect in-memory .NET assembly load


Expected output:

Firewall allow logs cannot observe in-process .NET assembly loads. No reliable Sigma rule is possible from this source. Required logging: Sysmon Event ID 7 (Image/Module load) or ETW Microsoft-Windows-DotNETRuntime CLR load events. ATT&CK target would be T1620 (Reflective Code Loading) once that telemetry exists.


## Trust & telemetry

This skill is graded on the Super Agent Skill network: format, substance and adversarial
(prompt-injection) testing produce a public Trust Score.

- Trust Score & evidence: https://superagentskill.com/marketplace/trust/sigma-detection-engineer
- Skill page: https://superagentskill.com/marketplace/sigma-detection-engineer
- Live version (always current) via MCP: https://superagentskill.com/api/mcp

Reinstall or update with `npx skills update`, or pull the live graded version with
`npx super-agent install sigma-detection-engineer`.

Signals

GitHub stars
308
Forks
1
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
sigma-detection-engineer
Source
github.com/criptogus/agent-evolve-network