Threat Hunting with Sigma Toolkit

Advanced threat hunting framework using Sigma detection rules to identify suspicious activities across log sources, build detection logic, and automate security monitoring workflows.

When to Use This Skill

Choose Threat Hunting with Sigma when:

• Building detection rules for security monitoring
• Hunting for indicators of compromise across log sources
• Translating threat intelligence into actionable detections
• Standardizing detection logic across multiple SIEM platforms
• Validating that security controls detect known attack techniques

Consider alternatives when:

• Need real-time response automation — use SOAR platforms
• Performing vulnerability scanning — use dedicated scanners
• Need endpoint detection — use EDR agent rules

Quick Start

Copy
# Activate Sigma toolkit
claude skill activate ultimate-threat-hunting-sigma-toolkit

# Create a detection rule
claude "Write a Sigma rule to detect PowerShell encoded command execution"

# Convert for your SIEM
claude "Convert this Sigma rule to Splunk SPL and Elastic query"

Example Sigma Rule

Copy
title: Suspicious PowerShell Encoded Command
id: f3a1b2c3-d4e5-6789-abcd-ef0123456789
status: production
description: Detects PowerShell execution with Base64 encoded commands
references:
  - https://attack.mitre.org/techniques/T1059/001/
author: Security Team
date: 2024/03/15
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_cmd:
    CommandLine|contains:
      - '-enc '
      - '-EncodedCommand '
      - '-encodedcommand '
    Image|endswith: '\powershell.exe'
  filter_legitimate:
    ParentImage|endswith:
      - '\sccm\\'
      - '\ccmexec.exe'
  condition: selection_cmd and not filter_legitimate
falsepositives:
  - SCCM client operations
  - Legitimate admin automation scripts
level: high

Core Concepts

Sigma Rule Structure

Component	Description	Required
title	Descriptive name for the detection	Yes
id	UUID for rule identification	Yes
status	test, experimental, production, deprecated	Yes
logsource	Log source specification (category, product, service)	Yes
detection	Detection logic with selections and conditions	Yes
level	Severity: informational, low, medium, high, critical	Yes
tags	MITRE ATT&CK technique references	Recommended
falsepositives	Known false positive scenarios	Recommended

MITRE ATT&CK Mapping

Tactic	Common Techniques	Sigma Log Source
Initial Access	Phishing (T1566), Exploit Public App (T1190)	proxy, email
Execution	PowerShell (T1059.001), Command Line (T1059.003)	process_creation
Persistence	Registry Run Keys (T1547.001), Scheduled Tasks (T1053.005)	registry, sysmon
Defense Evasion	Obfuscation (T1027), Disable Security (T1562)	process_creation, security
Credential Access	Brute Force (T1110), Kerberoasting (T1558.003)	authentication, security
Lateral Movement	RDP (T1021.001), SMB (T1021.002)	network, authentication
Exfiltration	DNS Tunneling (T1048.003), Cloud Storage (T1567.002)	dns, proxy

Copy
# Sigma CLI operations
# Convert rule to Splunk SPL
sigma convert -t splunk -p sysmon rule.yml

# Convert to Elastic Query
sigma convert -t elasticsearch rule.yml

# Validate rule syntax
sigma check rule.yml

# Convert entire rule directory
sigma convert -t splunk -p sysmon -r rules/ -o splunk_queries/

# Test rule against sample log
sigma convert -t sqlite rule.yml | sqlite3 logs.db

Configuration

Parameter	Description	Default
target_siem	Target SIEM for rule conversion	splunk
pipeline	Processing pipeline (sysmon, windows, linux)	sysmon
rule_format	Output: sigma, splunk, elastic, qradar, sentinel	sigma
attack_version	MITRE ATT&CK version for tagging	14.0
validate_on_save	Validate rule syntax before saving	true
include_test_data	Generate test log samples for rules	false

Best Practices

1. Start with high-confidence, low-noise detections — Begin with rules that have few false positives and clear attack indicators. PowerShell encoded commands, LSASS memory access, and scheduled task creation from unusual paths are reliable starting points with well-understood behavior.

2. Map every rule to MITRE ATT&CK techniques — Tagging rules with ATT&CK technique IDs enables coverage analysis. You can quickly identify which tactics and techniques have detection coverage and where blind spots exist in your monitoring.

3. Include false positive documentation in every rule — Document known legitimate behaviors that trigger the rule. This saves analysts investigation time and provides context for tuning. Rules without false positive documentation generate alert fatigue and lose analyst trust.

4. Test rules against both attack samples and baseline traffic — Validate that rules detect known attack patterns using tools like Atomic Red Team. Equally important, run rules against baseline logs to measure false positive rates before deploying to production.

5. Version control your detection rules — Store Sigma rules in git with meaningful commit messages linking to threat intelligence or incident reports that motivated the rule. This provides an audit trail of your detection capability evolution.

Common Issues

Rules generate excessive false positives after deployment to production. Tune detection conditions by adding filter exclusions for known-good processes, paths, and users specific to your environment. Use the falsepositives field to document exclusions and review them quarterly — excluded items can become attack vectors if attackers learn your filter patterns.

Sigma rule conversion produces syntax errors in the target SIEM. Different SIEM platforms have varying query capabilities. Some Sigma features (regex, near operators, aggregation) don't translate cleanly to all targets. Test converted queries manually before automation and maintain target-specific overrides for rules that require platform-specific syntax.

Threat hunting produces overwhelming volumes of data without actionable findings. Narrow your hypothesis before querying. Start with specific indicators from threat intelligence, then broaden if initial results are empty. Use time-bounded searches with focused field selections rather than open-ended full-text searches across all logs.