Instruction: How does string matching work in Sigma?

Output: Sigma string matching uses modifiers appended with pipes: (1) No modifier - exact match: CommandLine: 'whoami' matches only exact string. (2) contains - substring anywhere: CommandLine|contains: 'mimikatz' matches 'mimikatz.exe', 'invoke-mimikatz', etc. (3) startswith - prefix match: Image|startswith: 'C:\\Temp\\' matches paths starting with that prefix. (4) endswith - suffix match: Image|endswith: '\\powershell.exe' matches any path ending with powershell.exe (recommended for process detection). Combining: CommandLine|contains|all requires ALL strings present. Case sensitivity: Default behavior varies by backend; use |contains vs |contains to control. Paths: Always use double backslashes in YAML (\\) for Windows paths.


Instruction: What is the difference between contains, startswith, and endswith in Sigma?

Output: Sigma string modifiers serve different matching needs: contains - finds substring anywhere in field value. Use for: command arguments, file content patterns, flexible matching. Example: CommandLine|contains: '-enc' matches 'powershell -enc ABC' and 'cmd /c echo -enc'. startswith - matches beginning of field value. Use for: path prefixes, specific locations, protocol schemes. Example: Image|startswith: 'C:\\Users\\Public\\' matches files in Public folders. endswith - matches end of field value. Use for: file extensions, process names regardless of path, domain suffixes. Example: Image|endswith: '\\rundll32.exe' matches C:\Windows\System32\rundll32.exe and C:\Windows\SysWOW64\rundll32.exe. Best practice: Use endswith for process detection to handle path variations, use contains for argument patterns.


Instruction: How do you handle case sensitivity in Sigma string matching?

Output: Sigma case sensitivity handling: Default behavior varies by SIEM backend - some are case-sensitive by default, others are not. Controlling case: Some backends support |i modifier for case-insensitive matching. Example: CommandLine|contains|i: 'powershell' matches 'PowerShell', 'POWERSHELL', etc. Best practices: (1) Assume case-sensitive and include variations: CommandLine|contains: ['PowerShell', 'powershell', 'POWERSHELL'], (2) Test converted queries against target SIEM, (3) For process names, Windows is case-insensitive but include common variations, (4) For Linux, case matters - match exact case. Backend specifics: Splunk: case-sensitive by default, use lower() or upper() functions. Elastic: depends on field mapping (keyword vs text). Sentinel: KQL has =~ for case-insensitive. Recommendation: Document expected case behavior in rule comments.


Instruction: How do you escape special characters in Sigma?

Output: Escaping special characters in Sigma: (1) Backslashes - use double backslashes in YAML: 'C:\\Windows\\System32\\' represents C:\Windows\System32\. (2) Quotes - use opposite quote type or escape: "it's" or 'say "hello"'. (3) YAML special characters - colons, brackets may need quoting: 'http://example.com'. (4) Regex metacharacters - when using |re, escape: \., \*, \?, \[, etc. (5) Wildcards in non-wildcard context - wildcards (* ?) are interpreted, escape if literal needed. Common issues: Forgetting double backslash for Windows paths is the most common error. YAML interprets single backslash as escape sequence. Path example: Wrong: 'C:\Windows\' Right: 'C:\\Windows\\'. URL example: Should quote: 'https://evil.com/path?param=value'. Testing: Validate YAML syntax with linter before testing rule logic.


Instruction: Explain Sigma Regular Expressions.

Output:
Sigma Regular Expressions: The 're' modifier enables regular expression matching in Sigma selections. Regex provides powerful pattern matching for complex detection scenarios like variable encodings, obfuscation patterns, or structured data extraction. However, regex can be expensive in large-scale SIEM queries, so use sparingly and optimize patterns for performance.

Use cases:
- Matching obfuscation patterns
- Variable command syntax
- Encoded payload detection


Instruction: What is the structure of Sigma Regular Expressions?

Output:
Syntax for Sigma Regular Expressions:

```
# Regex modifier
CommandLine|re: 'powershell.*-e[ncodedcommand]*\s+[A-Za-z0-9+/=]{20,}'

# Case-insensitive regex
CommandLine|re|i: 'invoke-?(mimikatz|kerberoast)'
```

The 're' modifier enables regular expression matching in Sigma selections. Regex provides powerful pattern matching for complex detection scenarios like variable encodings, obfuscation patterns, or structured data extraction. However, regex can be expensive in large-scale SIEM queries, so use sparingly and optimize patterns for performance.


Instruction: Give a practical example of Sigma Regular Expressions.

Output:
Example of Sigma Regular Expressions:

```
detection:
    selection:
        EventID: 1
        Image|endswith: '\\powershell.exe'
        CommandLine|re: '(?i)-e(nc(odedcommand)?)?\s+[A-Za-z0-9+/=]{50,}'
    condition: selection
```

The 're' modifier enables regular expression matching in Sigma selections. Regex provides powerful pattern matching for complex detection scenarios like variable encodings, obfuscation patterns, or structured data extraction. However, regex can be expensive in large-scale SIEM queries, so use sparingly and optimize patterns for performance.


Instruction: What problems does Sigma Regular Expressions solve?

Output:
Use cases for Sigma Regular Expressions:

- Matching obfuscation patterns
- Variable command syntax
- Encoded payload detection

The 're' modifier enables regular expression matching in Sigma selections. Regex provides powerful pattern matching for complex detection scenarios like variable encodings, obfuscation patterns, or structured data extraction. However, regex can be expensive in large-scale SIEM queries, so use sparingly and optimize patterns for performance.


Instruction: What are recommendations for Sigma Regular Expressions?

Output:
Best practices for Sigma Regular Expressions:

- Anchor patterns where possible
- Test regex performance
- Use simpler modifiers when sufficient
- Document complex regex patterns

Avoid these mistakes:
- Expensive regex slows SIEM queries
- Not all backends support full regex
- Overly complex patterns are hard to maintain


Instruction: What mistakes should you avoid with Sigma Regular Expressions?

Output:
Common pitfalls with Sigma Regular Expressions:

- Expensive regex slows SIEM queries
- Not all backends support full regex
- Overly complex patterns are hard to maintain

To avoid these issues:
- Anchor patterns where possible
- Test regex performance
- Use simpler modifiers when sufficient


Instruction: When should you use regex in Sigma rules?

Output: Use regex (|re modifier) in Sigma when: (1) Pattern has variable components - 'powershell.*-enc' catches 'powershell -enc' and 'powershell.exe -nop -enc'. (2) Detecting obfuscation - matching encoded strings, character variations. (3) Complex alternatives - '(invoke|iex|iwr)-' is cleaner than multiple contains. (4) Structured patterns - matching specific formats like base64, hex, or IP addresses. Avoid regex when: (1) Simple string match suffices - use contains/endswith instead. (2) Performance is critical - regex is slower than simple matching. (3) Pattern is maintainable with alternatives - multiple selections may be clearer. Performance tips: Anchor with ^ or $ when possible, avoid .* at start, test against large datasets. Example: Use |re: 'certutil.*-urlcache' instead of separate contains when order matters.


Instruction: How do you write efficient regex patterns in Sigma?

Output: Efficient Sigma regex patterns: (1) Anchor when possible - '^powershell' faster than 'powershell' alone. (2) Use character classes - '[A-Za-z0-9]' instead of '.'. (3) Limit quantifiers - '{20,100}' instead of '+' for expected lengths. (4) Avoid backtracking - '.*?' (lazy) can be slower than specific patterns. (5) Case handling - use (?i) prefix or |i modifier for case-insensitive. (6) Test performance - measure query time with and without regex. Example patterns: Encoded PowerShell: '(?i)-e(nc(odedcommand)?)?\s+[A-Za-z0-9+/=]{50,}'. Base64 detection: '[A-Za-z0-9+/]{40,}={0,2}'. IP address: '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'. Obfuscated invoke: '(?i)i`?n`?v`?o`?k`?e'. Backend consideration: Not all backends support all regex features - test conversion output.


Instruction: What regex patterns are useful for detecting obfuscation?

Output: Regex patterns for obfuscation detection: (1) Caret insertion: 'p\^?o\^?w\^?e\^?r\^?s\^?h\^?e\^?l\^?l' - matches p^o^w^e^r^s^h^e^l^l. (2) Tick obfuscation (PowerShell): '`?[pP]`?[oO]`?[wW]' - matches `p`o`w variants. (3) Variable expansion: '\$\{?[a-zA-Z]' - matches ${e}xec patterns. (4) String concatenation: '(\'[^\']++\')\s*\+' - matches 'po'+'wer'+'shell'. (5) Base64 with variations: '[A-Za-z0-9+/]{40,}={0,2}|[A-Za-z0-9-_]{40,}' - standard and URL-safe. (6) Hex encoding: '(\\x[0-9a-fA-F]{2})+' - matches \x70\x6f\x77. (7) Char/chr calls: '\[char\]\s*\d+|chr\(\d+\)' - matches [char]112 or chr(112). Detection strategy: Layer multiple obfuscation patterns, combine with execution context (PowerShell process + obfuscation = higher confidence).


Instruction: Describe Sigma Wildcards for detection engineering.

Output:
Sigma Wildcards: Sigma supports wildcards using asterisk (*) for multiple characters and question mark (?) for single character. Wildcards provide simpler pattern matching than regex for common scenarios like file path variations or partial string matches. Wildcards are converted to appropriate syntax (LIKE, wildcard queries) for each backend.

Use cases:
- Variable path components
- File naming variations
- Partial argument matching


Instruction: What is the structure of Sigma Wildcards?

Output:
Syntax for Sigma Wildcards:

```
# Multiple character wildcard
CommandLine|contains: '*mimikatz*'
Image: 'C:\\Windows\\*\\cmd.exe'

# Single character wildcard
Image|endswith: '\\svchost?.exe'
```

Sigma supports wildcards using asterisk (*) for multiple characters and question mark (?) for single character. Wildcards provide simpler pattern matching than regex for common scenarios like file path variations or partial string matches. Wildcards are converted to appropriate syntax (LIKE, wildcard queries) for each backend.


Instruction: Give a practical example of Sigma Wildcards.

Output:
Example of Sigma Wildcards:

```
detection:
    selection:
        EventID: 1
        Image: 'C:\\Users\\*\\AppData\\*\\*.exe'
        CommandLine|contains: '-enc*'
    condition: selection
```

Sigma supports wildcards using asterisk (*) for multiple characters and question mark (?) for single character. Wildcards provide simpler pattern matching than regex for common scenarios like file path variations or partial string matches. Wildcards are converted to appropriate syntax (LIKE, wildcard queries) for each backend.


Instruction: What are the use cases for Sigma Wildcards?

Output:
Use cases for Sigma Wildcards:

- Variable path components
- File naming variations
- Partial argument matching

Sigma supports wildcards using asterisk (*) for multiple characters and question mark (?) for single character. Wildcards provide simpler pattern matching than regex for common scenarios like file path variations or partial string matches. Wildcards are converted to appropriate syntax (LIKE, wildcard queries) for each backend.


Instruction: How do you properly use Sigma Wildcards?

Output:
Best practices for Sigma Wildcards:

- Use wildcards for path flexibility
- Prefer wildcards over regex for simple patterns
- Be aware of performance impact

Avoid these mistakes:
- Leading wildcards are expensive
- May not work identically across backends
- Overuse leads to broad matching


Instruction: What should you avoid when using Sigma Wildcards?

Output:
Common pitfalls with Sigma Wildcards:

- Leading wildcards are expensive
- May not work identically across backends
- Overuse leads to broad matching

To avoid these issues:
- Use wildcards for path flexibility
- Prefer wildcards over regex for simple patterns
- Be aware of performance impact


Instruction: How do wildcards work in Sigma?

Output: Sigma wildcards enable flexible pattern matching: (1) Asterisk (*) - matches zero or more characters: Image: 'C:\\Users\\*\\AppData\\*.exe' matches any user's AppData executables. (2) Question mark (?) - matches exactly one character: Image|endswith: '\\svch?st.exe' matches svchost.exe and variations. Usage contexts: Value matching: CommandLine: '*whoami*' (note: typically use contains modifier instead). Field values with variables: Image: 'C:\\Windows\\*\\cmd.exe' handles System32/SysWOW64. Wildcards vs modifiers: 'CommandLine: "*mimikatz*"' is equivalent to 'CommandLine|contains: "mimikatz"'. Prefer modifiers for clarity. Performance: Leading wildcards (*something) are expensive - SIEM must scan all values. Backend conversion: Wildcards convert to LIKE (SQL), wildcard query (Elastic), or regex depending on target.


Instruction: When should you use wildcards vs contains/regex in Sigma?

Output: Choosing between wildcards, modifiers, and regex: Use |contains/startswith/endswith when: Matching specific position in string, clearer intent for readers, better backend optimization. Use wildcards when: Variable path components (C:\\Users\\*\\), embedded in field value with other text, simple variable substitution patterns. Use |re (regex) when: Complex patterns with alternatives, variable repetition counts, case-insensitive matching needed, patterns wildcards can't express. Examples - Same detection, different approaches: Substring: 'CommandLine|contains: "mimikatz"' (preferred) vs 'CommandLine: "*mimikatz*"'. Path variation: 'Image: "C:\\Windows\\*\\cmd.exe"' (wildcards appropriate). Complex pattern: 'CommandLine|re: "invoke-?(mimi|kerberos)"' (regex needed). Rule: Use simplest approach that achieves detection with acceptable performance.


Instruction: What is Sigma Field Existence?

Output:
Sigma Field Existence: Sigma can check whether fields exist (have any value) or are null/empty. This is useful for detecting events where the presence or absence of a field is significant. Field existence checks use the 'exists' modifier or null checks in selections.

Use cases:
- Filtering incomplete logs
- Detecting unusual field patterns
- Data quality validation


Instruction: What is the syntax for Sigma Field Existence?

Output:
Syntax for Sigma Field Existence:

```
# Field exists (has value)
selection:
    CommandLine|exists: true

# Field is null/empty
selection:
    ParentImage|exists: false
    # Alternative: field value is null
    ParentImage: null
```

Sigma can check whether fields exist (have any value) or are null/empty. This is useful for detecting events where the presence or absence of a field is significant. Field existence checks use the 'exists' modifier or null checks in selections.


Instruction: Give a practical example of Sigma Field Existence.

Output:
Example of Sigma Field Existence:

```
detection:
    selection:
        EventID: 1
        Image|endswith: '\\powershell.exe'
    filter_no_cmdline:
        CommandLine|exists: false
    condition: selection and not filter_no_cmdline
```

Sigma can check whether fields exist (have any value) or are null/empty. This is useful for detecting events where the presence or absence of a field is significant. Field existence checks use the 'exists' modifier or null checks in selections.


Instruction: When should you use Sigma Field Existence?

Output:
Use cases for Sigma Field Existence:

- Filtering incomplete logs
- Detecting unusual field patterns
- Data quality validation

Sigma can check whether fields exist (have any value) or are null/empty. This is useful for detecting events where the presence or absence of a field is significant. Field existence checks use the 'exists' modifier or null checks in selections.


Instruction: What are recommendations for Sigma Field Existence?

Output:
Best practices for Sigma Field Existence:

- Handle missing fields explicitly
- Consider logging gaps
- Use existence checks in filters

Avoid these mistakes:
- Assuming fields always exist
- Null vs empty string differences
- Backend support variations


Instruction: What mistakes should you avoid with Sigma Field Existence?

Output:
Common pitfalls with Sigma Field Existence:

- Assuming fields always exist
- Null vs empty string differences
- Backend support variations

To avoid these issues:
- Handle missing fields explicitly
- Consider logging gaps
- Use existence checks in filters


Instruction: How do you check for field existence in Sigma?

Output: Sigma field existence checks detect whether fields have values: (1) Field exists (has value): 'CommandLine|exists: true' - matches events where CommandLine has any non-null value. (2) Field is null/missing: 'ParentImage|exists: false' or 'ParentImage: null' - matches events without that field. Use cases: Exclude incomplete events: filter logs where CommandLine wasn't captured. Detect anomalies: process creation without parent is suspicious. Data quality: identify logging gaps. Backend behavior: Null/existence handling varies - Splunk uses 'isnotnull()', Elastic uses 'exists' query. Some backends treat empty string differently from null. Testing: Validate existence checks against actual SIEM with sample events. Best practice: Always consider missing field scenarios in detection logic.


Instruction: Why would fields be missing in security logs?

Output: Fields can be missing from security logs due to: (1) Logging configuration - field not enabled in audit policy or Sysmon config, (2) Log source limitations - some events don't include certain fields by design, (3) Parsing issues - SIEM didn't extract field from raw log, (4) Truncation - field value exceeded size limits and was dropped, (5) Evasion - attacker manipulated process to have empty parent, (6) System behavior - some legitimate processes have unusual field patterns. Examples: CommandLine missing: Process creation logging not enabled, or old Windows version. ParentImage null: Direct process creation via kernel or certain injection techniques. User field empty: Service accounts or SYSTEM-level processes. Detection implications: (1) Don't assume fields exist - filter out null values explicitly, (2) Missing fields can be detection signals themselves, (3) Test rules against real logs to see actual field population, (4) Existence checks help rule out incomplete data before alerting.


Instruction: Explain Sigma Numeric Comparisons.

Output:
Sigma Numeric Comparisons: Sigma supports numeric comparisons for fields containing numbers using comparison modifiers. These enable detection based on thresholds, ranges, or specific numeric values. Common uses include port numbers, event IDs, process IDs, and byte counts.

Use cases:
- Port number detection
- Threshold-based detection
- Numeric field filtering


Instruction: Show the format for Sigma Numeric Comparisons.

Output:
Syntax for Sigma Numeric Comparisons:

```
# Greater than
DestinationPort|gt: 1024

# Less than
BytesSent|lt: 100

# Greater than or equal
EventID|gte: 4624

# Less than or equal
ProcessId|lte: 4

# Range (between values)
DestinationPort|gte: 49152
DestinationPort|lte: 65535
```

Sigma supports numeric comparisons for fields containing numbers using comparison modifiers. These enable detection based on thresholds, ranges, or specific numeric values. Common uses include port numbers, event IDs, process IDs, and byte counts.


Instruction: What does Sigma Numeric Comparisons look like in practice?

Output:
Example of Sigma Numeric Comparisons:

```
detection:
    selection:
        EventID: 3
        Initiated: 'true'
        DestinationPort|gt: 1024
        DestinationPort|lt: 49152
    condition: selection
```

Sigma supports numeric comparisons for fields containing numbers using comparison modifiers. These enable detection based on thresholds, ranges, or specific numeric values. Common uses include port numbers, event IDs, process IDs, and byte counts.


Instruction: When is Sigma Numeric Comparisons appropriate?

Output:
Use cases for Sigma Numeric Comparisons:

- Port number detection
- Threshold-based detection
- Numeric field filtering

Sigma supports numeric comparisons for fields containing numbers using comparison modifiers. These enable detection based on thresholds, ranges, or specific numeric values. Common uses include port numbers, event IDs, process IDs, and byte counts.


Instruction: How do you properly use Sigma Numeric Comparisons?

Output:
Best practices for Sigma Numeric Comparisons:

- Use appropriate comparison operator
- Consider boundary values
- Validate numeric field types

Avoid these mistakes:
- String vs numeric field types
- Backend conversion differences
- Off-by-one errors in ranges


Instruction: What are common pitfalls with Sigma Numeric Comparisons?

Output:
Common pitfalls with Sigma Numeric Comparisons:

- String vs numeric field types
- Backend conversion differences
- Off-by-one errors in ranges

To avoid these issues:
- Use appropriate comparison operator
- Consider boundary values
- Validate numeric field types


Instruction: How do numeric comparisons work in Sigma?

Output: Sigma numeric comparisons use modifiers: (1) |gt - greater than: DestinationPort|gt: 1024 matches ports above 1024, (2) |gte - greater than or equal: EventID|gte: 4624 matches 4624 and higher, (3) |lt - less than: BytesSent|lt: 100 matches small transfers, (4) |lte - less than or equal: ProcessId|lte: 4 matches low PIDs. Ranges: Combine gte and lte in same selection: DestinationPort|gte: 49152 AND DestinationPort|lte: 65535 matches ephemeral ports. Use cases: Port-based detection (web on non-standard port), Threshold alerts (excessive data transfer), Process anomalies (low PID typically system processes). Backend conversion: Most backends support numeric comparison, verify with target SIEM.


Instruction: What are common numeric-based detections?

Output: Common numeric-based detection scenarios: (1) Non-standard ports - Web traffic on ports other than 80/443: 'DestinationPort|gt: 443' with HTTP protocol. (2) High port connections - Outbound to ephemeral range suggests C2: 'DestinationPort|gte: 49152'. (3) Low process IDs - PIDs under 100 are typically system: 'ProcessId|lt: 100' on user-spawned process. (4) Data thresholds - Large file operations: 'FileSize|gt: 10000000' (10MB). (5) Event ID ranges - Authentication events: 'EventID|gte: 4624' with 'EventID|lte: 4634'. (6) Failed attempts - Brute force: count failed logins above threshold. (7) Unusual times - Hour-of-day for off-hours activity (with time extraction). Implementation note: Ensure field is numeric type in SIEM - some fields are strings requiring type conversion.


Instruction: Explain Sigma Lists and OR Logic.

Output:
Sigma Lists and OR Logic: Sigma selections can include lists of values, creating implicit OR conditions. When a field has multiple values in a list, the selection matches if ANY value matches. Lists are written as YAML arrays and are essential for matching multiple indicators, alternative tool names, or multiple suspicious patterns.

Use cases:
- Multiple tool detection
- Event ID grouping
- Alternative indicators


Instruction: What is the structure of Sigma Lists and OR Logic?

Output:
Syntax for Sigma Lists and OR Logic:

```
# List of values (OR logic)
selection:
    Image|endswith:
        - '\\mimikatz.exe'
        - '\\procdump.exe'
        - '\\lazagne.exe'

# Multiple EventIDs
selection:
    EventID:
        - 4624
        - 4625
        - 4648
```

Sigma selections can include lists of values, creating implicit OR conditions. When a field has multiple values in a list, the selection matches if ANY value matches. Lists are written as YAML arrays and are essential for matching multiple indicators, alternative tool names, or multiple suspicious patterns.


Instruction: What does Sigma Lists and OR Logic look like in practice?

Output:
Example of Sigma Lists and OR Logic:

```
detection:
    selection:
        EventID: 1
        Image|endswith:
            - '\\powershell.exe'
            - '\\pwsh.exe'
            - '\\cmd.exe'
        CommandLine|contains:
            - 'whoami'
            - 'net user'
            - 'net group'
    condition: selection
```

Sigma selections can include lists of values, creating implicit OR conditions. When a field has multiple values in a list, the selection matches if ANY value matches. Lists are written as YAML arrays and are essential for matching multiple indicators, alternative tool names, or multiple suspicious patterns.


Instruction: What problems does Sigma Lists and OR Logic solve?

Output:
Use cases for Sigma Lists and OR Logic:

- Multiple tool detection
- Event ID grouping
- Alternative indicators

Sigma selections can include lists of values, creating implicit OR conditions. When a field has multiple values in a list, the selection matches if ANY value matches. Lists are written as YAML arrays and are essential for matching multiple indicators, alternative tool names, or multiple suspicious patterns.


Instruction: What are best practices for Sigma Lists and OR Logic?

Output:
Best practices for Sigma Lists and OR Logic:

- Group related indicators in lists
- Use consistent formatting
- Consider list length and performance

Avoid these mistakes:
- Very long lists impact performance
- Mixing different indicator types in one list
- Not using all modifier when all items required


Instruction: What are common pitfalls with Sigma Lists and OR Logic?

Output:
Common pitfalls with Sigma Lists and OR Logic:

- Very long lists impact performance
- Mixing different indicator types in one list
- Not using all modifier when all items required

To avoid these issues:
- Group related indicators in lists
- Use consistent formatting
- Consider list length and performance


Instruction: How do lists work in Sigma detections?

Output: Sigma lists create OR conditions within selections: Format: YAML array under field name. Behavior: Selection matches if ANY list value matches. Example: 'Image|endswith: ["\\cmd.exe", "\\powershell.exe"]' matches either process. Multiple fields: Each field with a list is OR'd within itself, but fields are AND'd together. So: Image|endswith: [cmd.exe, powershell.exe] AND CommandLine|contains: [whoami, net] means (cmd.exe OR powershell.exe) AND (whoami OR net). Ordering: List order doesn't affect matching, organize for readability. Performance: Very long lists may impact query performance - consider splitting into multiple rules if list exceeds 50-100 items. Formatting: Use YAML array syntax for clarity, one item per line for longer lists.


Instruction: What is the difference between lists and the 'all' modifier?

Output: Lists vs 'all' modifier behavior: (1) Lists (default) - OR logic: 'CommandLine|contains: ["whoami", "net user"]' matches if EITHER string is present. (2) |all modifier - AND logic: 'CommandLine|contains|all: ["powershell", "-enc"]' requires ALL strings present. Use cases: OR (lists): Alternative tools, multiple IOCs where any is suspicious, event ID groups. AND (all): Required combination, multiple arguments that together indicate malice. Example comparison: Detecting credential dumping tools: 'Image|endswith: ["mimikatz.exe", "procdump.exe"]' - OR, any tool is suspicious. Detecting specific technique: 'CommandLine|contains|all: ["procdump", "lsass"]' - AND, requires both for high-confidence LSASS dump. Common pattern: 'selection|contains|all' for command line patterns where order doesn't matter but all elements required.


Instruction: Describe Sigma AND/OR/NOT Conditions for detection engineering.

Output:
Sigma AND/OR/NOT Conditions: Sigma conditions combine selections using boolean operators: 'and' requires all selections match, 'or' requires any selection match, 'not' negates a selection. Parentheses group operations. The condition field defines the final boolean expression determining when the rule fires.

Use cases:
- Combining detection criteria
- Excluding false positives
- Complex detection logic


Instruction: What is the structure of Sigma AND/OR/NOT Conditions?

Output:
Syntax for Sigma AND/OR/NOT Conditions:

```
# Simple AND
condition: selection1 and selection2

# Simple OR
condition: selection1 or selection2

# NOT (exclusion)
condition: selection and not filter

# Complex with parentheses
condition: (selection1 or selection2) and not (filter1 or filter2)

# Multiple exclusions
condition: selection and not filter1 and not filter2
```

Sigma conditions combine selections using boolean operators: 'and' requires all selections match, 'or' requires any selection match, 'not' negates a selection. Parentheses group operations. The condition field defines the final boolean expression determining when the rule fires.


Instruction: Provide an example rule for Sigma AND/OR/NOT Conditions.

Output:
Example of Sigma AND/OR/NOT Conditions:

```
detection:
    selection_process:
        Image|endswith: '\\powershell.exe'
    selection_encoded:
        CommandLine|contains: '-enc'
    selection_hidden:
        CommandLine|contains: '-w hidden'
    filter_admin:
        User|contains: 'admin'
    condition: selection_process and (selection_encoded or selection_hidden) and not filter_admin
```

Sigma conditions combine selections using boolean operators: 'and' requires all selections match, 'or' requires any selection match, 'not' negates a selection. Parentheses group operations. The condition field defines the final boolean expression determining when the rule fires.


Instruction: When should you use Sigma AND/OR/NOT Conditions?

Output:
Use cases for Sigma AND/OR/NOT Conditions:

- Combining detection criteria
- Excluding false positives
- Complex detection logic

Sigma conditions combine selections using boolean operators: 'and' requires all selections match, 'or' requires any selection match, 'not' negates a selection. Parentheses group operations. The condition field defines the final boolean expression determining when the rule fires.


Instruction: What are best practices for Sigma AND/OR/NOT Conditions?

Output:
Best practices for Sigma AND/OR/NOT Conditions:

- Use parentheses for clarity
- Name selections descriptively
- Keep conditions readable
- Test complex logic carefully

Avoid these mistakes:
- Operator precedence confusion
- Overly complex conditions
- Forgetting parentheses changes logic


Instruction: What goes wrong with Sigma AND/OR/NOT Conditions?

Output:
Common pitfalls with Sigma AND/OR/NOT Conditions:

- Operator precedence confusion
- Overly complex conditions
- Forgetting parentheses changes logic

To avoid these issues:
- Use parentheses for clarity
- Name selections descriptively
- Keep conditions readable


Instruction: How do boolean operators work in Sigma conditions?

Output: Sigma boolean operators combine selections: (1) AND - requires all to match: 'selection1 and selection2' fires only when both match, use for requiring multiple indicators. (2) OR - requires any to match: 'selection1 or selection2' fires when either matches, use for alternative indicators. (3) NOT - negates: 'not filter' excludes matching events, use for false positive filtering. Precedence: NOT binds tightest, then AND, then OR. 'a and not b or c' = '(a and (not b)) or c'. Use parentheses to clarify: '(a and b) or c' vs 'a and (b or c)'. Common patterns: 'selection and not filter' - positive match with exclusion, '(sel1 or sel2) and required' - alternatives plus required indicator, 'selection and not (filter1 or filter2)' - exclude multiple FP patterns.


Instruction: How do you structure complex Sigma conditions?

Output: Structuring complex Sigma conditions for clarity: (1) Name selections by purpose: selection_process, selection_cmdline, filter_legitimate. (2) Group related logic: selection_* for positive matches, filter_* for exclusions. (3) Use parentheses always: Even when not required, they clarify intent. (4) Break down complex logic: Instead of one huge condition, consider multiple rules. Example structure: detection: selection_target: Image... (what process), selection_behavior: CommandLine... (what it does), filter_known_good: ParentImage... (legitimate source), filter_user: User... (authorized users), condition: selection_target and selection_behavior and not filter_known_good and not filter_user. Testing approach: Test each selection independently, then combine. Verify positive matches still fire after adding filters. Document logic in description field.


Instruction: Explain Sigma Aggregation Conditions.

Output:
Sigma Aggregation Conditions: Sigma supports aggregation conditions for threshold-based detection using count(), sum(), min(), max(), and avg() functions. Aggregation conditions enable detecting behaviors based on frequency or volume rather than single events, such as brute force attempts or data exfiltration thresholds.

Use cases:
- Brute force detection
- Volumetric anomalies
- Rate limiting alerts
- Threshold-based detection


Instruction: What is the structure of Sigma Aggregation Conditions?

Output:
Syntax for Sigma Aggregation Conditions:

```
# Count threshold
condition: selection | count() > 10

# Count by field
condition: selection | count(DestinationIP) > 5

# Count with grouping
condition: selection | count() by SourceIP > 10

# Near correlation (events within timeframe)
condition: selection | count() > 3 | timeframe: 5m
```

Sigma supports aggregation conditions for threshold-based detection using count(), sum(), min(), max(), and avg() functions. Aggregation conditions enable detecting behaviors based on frequency or volume rather than single events, such as brute force attempts or data exfiltration thresholds.


Instruction: Give a practical example of Sigma Aggregation Conditions.

Output:
Example of Sigma Aggregation Conditions:

```
title: Potential Brute Force Attack
detection:
    selection:
        EventID: 4625
    condition: selection | count() by TargetUserName > 5
timeframe: 5m
level: high
```

Sigma supports aggregation conditions for threshold-based detection using count(), sum(), min(), max(), and avg() functions. Aggregation conditions enable detecting behaviors based on frequency or volume rather than single events, such as brute force attempts or data exfiltration thresholds.


Instruction: What are the use cases for Sigma Aggregation Conditions?

Output:
Use cases for Sigma Aggregation Conditions:

- Brute force detection
- Volumetric anomalies
- Rate limiting alerts
- Threshold-based detection

Sigma supports aggregation conditions for threshold-based detection using count(), sum(), min(), max(), and avg() functions. Aggregation conditions enable detecting behaviors based on frequency or volume rather than single events, such as brute force attempts or data exfiltration thresholds.


Instruction: How do you properly use Sigma Aggregation Conditions?

Output:
Best practices for Sigma Aggregation Conditions:

- Set appropriate thresholds
- Use timeframe for rate detection
- Group by relevant fields
- Consider baseline volumes

Avoid these mistakes:
- Thresholds too low cause noise
- Not all backends support aggregation
- Missing timeframe for rate detection


Instruction: What are common pitfalls with Sigma Aggregation Conditions?

Output:
Common pitfalls with Sigma Aggregation Conditions:

- Thresholds too low cause noise
- Not all backends support aggregation
- Missing timeframe for rate detection

To avoid these issues:
- Set appropriate thresholds
- Use timeframe for rate detection
- Group by relevant fields


Instruction: How do aggregation conditions work in Sigma?

Output: Sigma aggregation conditions enable threshold-based detection: (1) count() - number of matching events: 'selection | count() > 10' fires after 10+ matches. (2) count(field) - unique values: 'selection | count(DestinationIP) > 5' fires when connecting to 5+ unique IPs. (3) count() by field - group and count: 'selection | count() by SourceIP > 10' counts per source IP. (4) timeframe - time window: Combined with count to detect rate: 'count() > 5' in 'timeframe: 5m'. (5) Other functions: sum(), min(), max(), avg() for numeric aggregations. Backend support: Not all SIEMs support all aggregation functions - verify with target platform. Common use cases: Brute force (failed logins > threshold), Port scanning (connections to many ports), Data exfiltration (large byte counts).


Instruction: How do you tune aggregation thresholds in Sigma?

Output: Tuning aggregation thresholds requires baselining: (1) Start high - begin with threshold above normal, reduce gradually: Initial brute force rule: count() > 20, tune down based on FP rate. (2) Analyze baseline - understand normal volumes: Query historical data for typical count() by user per hour. (3) Segment by context - different thresholds for different environments: Admin accounts may have more failed logins legitimately. (4) Time window impact - shorter windows = more sensitive: 5 failed logins in 1 minute vs 1 hour are very different. (5) Grouping matters - count() vs count() by SourceIP: Global count catches distributed attacks, per-source catches targeted. (6) Document rationale - record why threshold was chosen: 'Threshold 10 based on 95th percentile of normal user failed logins'. Iteration: Deploy to logging first, analyze alert volume, adjust threshold, repeat until acceptable FP rate.


Instruction: Explain Sigma Near Correlations.

Output:
Sigma Near Correlations: Near correlations in Sigma detect multiple related events occurring within a specified time window. This enables detection of attack sequences where individual events are benign but the combination within a short timeframe indicates malicious activity. Near correlations use the 'timeframe' field with aggregation conditions.

Use cases:
- Attack sequence detection
- Multi-stage attack correlation
- Behavioral patterns


Instruction: What is the syntax for Sigma Near Correlations?

Output:
Syntax for Sigma Near Correlations:

```
# Events within time window
timeframe: 5m
condition: selection | count() > 1

# Sequence detection (ordered events)
detection:
    selection_recon:
        CommandLine|contains: 'whoami'
    selection_access:
        CommandLine|contains: 'net user'
    condition: selection_recon and selection_access
timeframe: 1m
```

Near correlations in Sigma detect multiple related events occurring within a specified time window. This enables detection of attack sequences where individual events are benign but the combination within a short timeframe indicates malicious activity. Near correlations use the 'timeframe' field with aggregation conditions.


Instruction: Provide an example rule for Sigma Near Correlations.

Output:
Example of Sigma Near Correlations:

```
title: Reconnaissance Followed by Credential Access Attempt
detection:
    selection_recon:
        EventID: 1
        CommandLine|contains:
            - 'whoami'
            - 'net user'
    selection_cred:
        EventID: 1
        Image|endswith:
            - '\\mimikatz.exe'
            - '\\procdump.exe'
    condition: selection_recon and selection_cred
timeframe: 10m
level: high
```

Near correlations in Sigma detect multiple related events occurring within a specified time window. This enables detection of attack sequences where individual events are benign but the combination within a short timeframe indicates malicious activity. Near correlations use the 'timeframe' field with aggregation conditions.


Instruction: When should you use Sigma Near Correlations?

Output:
Use cases for Sigma Near Correlations:

- Attack sequence detection
- Multi-stage attack correlation
- Behavioral patterns

Near correlations in Sigma detect multiple related events occurring within a specified time window. This enables detection of attack sequences where individual events are benign but the combination within a short timeframe indicates malicious activity. Near correlations use the 'timeframe' field with aggregation conditions.


Instruction: How do you properly use Sigma Near Correlations?

Output:
Best practices for Sigma Near Correlations:

- Set realistic timeframes
- Test correlation logic
- Consider event ordering needs
- Document expected sequence

Avoid these mistakes:
- Too long timeframe increases FPs
- Not all backends support correlation
- Complex correlations may not convert well


Instruction: What should you avoid when using Sigma Near Correlations?

Output:
Common pitfalls with Sigma Near Correlations:

- Too long timeframe increases FPs
- Not all backends support correlation
- Complex correlations may not convert well

To avoid these issues:
- Set realistic timeframes
- Test correlation logic
- Consider event ordering needs


Instruction: How do near correlations work in Sigma?

Output: Near correlations detect related events within a time window: (1) timeframe field - specifies window: 'timeframe: 5m' looks for events within 5 minutes. (2) Multiple selections - define related events: selection_first for initial action, selection_second for follow-up. (3) Condition combines - 'selection_first and selection_second' requires both within timeframe. Use cases: Reconnaissance then credential access, Failed login then successful login, Process creation then network connection. Backend considerations: Correlation support varies significantly - Splunk (transaction), Elastic (EQL sequence), Sentinel (joins). Simple correlations convert better than complex multi-event sequences. Testing: Validate timing logic in target SIEM, ensure events have accurate timestamps.


Instruction: What attack sequences can be detected with correlations?

Output: Detectable attack sequences with Sigma correlations: (1) Spray then success - multiple failed logins followed by success indicates password spray: 'selection_fail | count() by TargetUser > 5' then 'selection_success' in 10m. (2) Recon then action - discovery commands followed by malicious tool: whoami/net user commands then mimikatz/procdump within 5m. (3) Download then execute - certutil download followed by execution from temp folder: certutil -urlcache then process creation from download path. (4) Disable then attack - security tool stopped then suspicious process: services.exe stopping AV then encoded PowerShell. (5) Lateral then dump - RDP/WinRM connection followed by credential access: network logon type 10 then LSASS access. (6) Persistence then callback - scheduled task creation then outbound connection: schtasks /create then network connection to external IP. Design approach: Map attack kill chain, identify observable transitions, set appropriate time windows.


Instruction: What is Sigma All Modifier?

Output:
Sigma All Modifier: The 'all' modifier requires all values in a list to be present in the field, changing the default OR logic to AND logic. This is essential for detecting command lines where multiple specific arguments must all appear, regardless of order. Without 'all', list values match if any single value is present.

Use cases:
- Multi-argument command detection
- Required indicator combinations
- High-fidelity matching


Instruction: What is the syntax for Sigma All Modifier?

Output:
Syntax for Sigma All Modifier:

```
# Without 'all' - matches ANY value (OR)
CommandLine|contains:
    - 'powershell'
    - '-enc'

# With 'all' - requires ALL values (AND)
CommandLine|contains|all:
    - 'powershell'
    - '-enc'
    - '-nop'
```

The 'all' modifier requires all values in a list to be present in the field, changing the default OR logic to AND logic. This is essential for detecting command lines where multiple specific arguments must all appear, regardless of order. Without 'all', list values match if any single value is present.


Instruction: Show an example of Sigma All Modifier.

Output:
Example of Sigma All Modifier:

```
detection:
    selection:
        EventID: 1
        CommandLine|contains|all:
            - 'certutil'
            - '-urlcache'
            - '-split'
            - '-f'
            - 'http'
    condition: selection
```

The 'all' modifier requires all values in a list to be present in the field, changing the default OR logic to AND logic. This is essential for detecting command lines where multiple specific arguments must all appear, regardless of order. Without 'all', list values match if any single value is present.


Instruction: What problems does Sigma All Modifier solve?

Output:
Use cases for Sigma All Modifier:

- Multi-argument command detection
- Required indicator combinations
- High-fidelity matching

The 'all' modifier requires all values in a list to be present in the field, changing the default OR logic to AND logic. This is essential for detecting command lines where multiple specific arguments must all appear, regardless of order. Without 'all', list values match if any single value is present.


Instruction: What are best practices for Sigma All Modifier?

Output:
Best practices for Sigma All Modifier:

- Use for command line patterns where all elements required
- Combine with OR selections for alternatives
- Test that all required elements are common in attack

Avoid these mistakes:
- Forgetting 'all' leads to high FPs
- Over-specifying makes rule easy to evade
- Order variations may still evade


Instruction: What mistakes should you avoid with Sigma All Modifier?

Output:
Common pitfalls with Sigma All Modifier:

- Forgetting 'all' leads to high FPs
- Over-specifying makes rule easy to evade
- Order variations may still evade

To avoid these issues:
- Use for command line patterns where all elements required
- Combine with OR selections for alternatives
- Test that all required elements are common in attack


Instruction: When should you use the 'all' modifier in Sigma?

Output: Use the 'all' modifier when ALL list items must be present: (1) Command line arguments - 'CommandLine|contains|all: ["certutil", "-urlcache", "-f"]' requires all arguments, not just any one. (2) Required combinations - attack requires specific combination: 'CommandLine|contains|all: ["powershell", "-enc", "-nop"]' catches encoded, no-profile PowerShell. (3) Reducing false positives - without 'all', matching 'powershell' alone is too broad. Examples - with vs without 'all': '|contains: ["net", "user"]' matches 'net time' or 'net user admin' (either). '|contains|all: ["net", "user"]' only matches 'net user admin' (both). Best practice: Use 'all' for command line detections where multiple indicators together indicate malice. Combine with process selection for additional context.


Instruction: How do you combine 'all' with other modifiers?

Output: Combining 'all' with other modifiers: (1) contains|all - all substrings present: 'CommandLine|contains|all: ["powershell", "-enc"]' both must appear anywhere. (2) With selections - multiple selections can mix: 'selection_proc: Image|endswith: "\\powershell.exe"' (single value), 'selection_args: CommandLine|contains|all: ["-enc", "-nop"]' (requires both). (3) Complex patterns - combine in condition: 'condition: selection_proc and selection_args and not filter'. (4) Cannot combine with OR in same field - for some required + some optional, use separate selections: 'selection_required: CommandLine|contains|all: ["certutil", "-urlcache"]', 'selection_optional: CommandLine|contains: ["-decode", "-encode"]', 'condition: selection_required and selection_optional'. Common pattern: Use 'all' for core indicators, separate selection with list for variations.


Instruction: Describe Sigma Base64 Modifiers for detection engineering.

Output:
Sigma Base64 Modifiers: The base64 and base64offset modifiers detect strings that may appear in Base64-encoded form within logs. The base64 modifier converts the search string to its Base64 equivalent. The base64offset modifier accounts for Base64 encoding offset variations (the same string encodes differently depending on position). These modifiers are crucial for detecting encoded PowerShell, obfuscated commands, and encoded payloads.

Use cases:
- Encoded PowerShell detection
- Obfuscated command detection
- Encoded URL detection


Instruction: How do you write Sigma Base64 Modifiers?

Output:
Syntax for Sigma Base64 Modifiers:

```
# Simple Base64 match
CommandLine|base64: 'IEX'

# Base64 with offset variations (recommended)
CommandLine|base64offset|contains:
    - 'http://'
    - 'https://'
```

The base64 and base64offset modifiers detect strings that may appear in Base64-encoded form within logs. The base64 modifier converts the search string to its Base64 equivalent. The base64offset modifier accounts for Base64 encoding offset variations (the same string encodes differently depending on position). These modifiers are crucial for detecting encoded PowerShell, obfuscated commands, and encoded payloads.


Instruction: Show an example of Sigma Base64 Modifiers.

Output:
Example of Sigma Base64 Modifiers:

```
title: Base64 Encoded PowerShell Download
detection:
    selection:
        EventID: 1
        Image|endswith: '\\powershell.exe'
        CommandLine|base64offset|contains:
            - 'http://'
            - 'https://'
            - 'Invoke-WebRequest'
            - 'DownloadString'
    condition: selection
level: high
```

The base64 and base64offset modifiers detect strings that may appear in Base64-encoded form within logs. The base64 modifier converts the search string to its Base64 equivalent. The base64offset modifier accounts for Base64 encoding offset variations (the same string encodes differently depending on position). These modifiers are crucial for detecting encoded PowerShell, obfuscated commands, and encoded payloads.


Instruction: What problems does Sigma Base64 Modifiers solve?

Output:
Use cases for Sigma Base64 Modifiers:

- Encoded PowerShell detection
- Obfuscated command detection
- Encoded URL detection

The base64 and base64offset modifiers detect strings that may appear in Base64-encoded form within logs. The base64 modifier converts the search string to its Base64 equivalent. The base64offset modifier accounts for Base64 encoding offset variations (the same string encodes differently depending on position). These modifiers are crucial for detecting encoded PowerShell, obfuscated commands, and encoded payloads.


Instruction: What are recommendations for Sigma Base64 Modifiers?

Output:
Best practices for Sigma Base64 Modifiers:

- Use base64offset for comprehensive matching
- Combine with process context
- Test with actual encoded samples

Avoid these mistakes:
- base64 alone misses offset variations
- Not all backends support base64 modifiers
- Performance impact on large datasets


Instruction: What should you avoid when using Sigma Base64 Modifiers?

Output:
Common pitfalls with Sigma Base64 Modifiers:

- base64 alone misses offset variations
- Not all backends support base64 modifiers
- Performance impact on large datasets

To avoid these issues:
- Use base64offset for comprehensive matching
- Combine with process context
- Test with actual encoded samples


Instruction: How do base64 modifiers work in Sigma?

Output: Sigma base64 modifiers detect encoded content: (1) |base64 - converts search string to Base64 equivalent: 'CommandLine|base64: "IEX"' searches for 'SUVY' (Base64 of IEX). (2) |base64offset - handles encoding position variations: Same string encodes differently based on byte alignment - 'IEX' can be 'SUVY', 'lFWC', or 'JRVg' depending on position. The modifier searches all three variations. Usage: 'CommandLine|base64offset|contains: "http://"' finds Base64-encoded URLs regardless of position in encoded string. Why needed: Attackers encode PowerShell commands to evade detection - 'powershell -enc [base64]'. Without base64 modifiers, you'd need to decode logs or miss encoded content. Recommendation: Always use base64offset over base64 for comprehensive detection.


Instruction: What strings should you search for with base64 modifiers?

Output: High-value strings for base64 detection: PowerShell indicators: 'IEX', 'Invoke-Expression', 'Invoke-WebRequest', 'DownloadString', 'DownloadFile', 'New-Object', 'Net.WebClient'. URLs: 'http://', 'https://', 'ftp://'. File paths: 'C:\\Windows', 'C:\\Users', 'AppData'. Common payloads: 'powershell', 'cmd.exe', '/c ', 'Start-Process'. Detection approach: (1) Start with known-bad strings from threat intel, (2) Combine base64offset with process context (PowerShell execution), (3) Test against actual encoded samples: echo 'IEX' | base64 shows encoding. Example rule combining multiple indicators: 'CommandLine|base64offset|contains: ["http", "IEX", "WebClient", "DownloadString"]' - any encoded download/execution indicator.


Instruction: What is Sigma Wide String Modifier?

Output:
Sigma Wide String Modifier: The 'wide' modifier matches strings in UTF-16LE encoding (wide character strings), common in Windows APIs and memory. Wide strings have null bytes between characters ('A' becomes 'A\x00'). This modifier is essential for detecting strings in process memory dumps, registry values, and Windows internal structures where wide encoding is used.

Use cases:
- Memory content scanning
- Registry value matching
- Windows API string detection


Instruction: How do you write Sigma Wide String Modifier?

Output:
Syntax for Sigma Wide String Modifier:

```
# Wide string matching
CommandLine|wide|contains: 'mimikatz'

# Combined with ascii
CommandLine|wide|ascii|contains: 'password'
```

The 'wide' modifier matches strings in UTF-16LE encoding (wide character strings), common in Windows APIs and memory. Wide strings have null bytes between characters ('A' becomes 'A\x00'). This modifier is essential for detecting strings in process memory dumps, registry values, and Windows internal structures where wide encoding is used.


Instruction: Provide an example rule for Sigma Wide String Modifier.

Output:
Example of Sigma Wide String Modifier:

```
title: Credential Keyword in Memory
detection:
    selection:
        EventType: 'ProcessAccess'
        TargetImage|endswith: '\\lsass.exe'
        CallTrace|wide|contains:
            - 'sekurlsa'
            - 'kerberos'
    condition: selection
```

The 'wide' modifier matches strings in UTF-16LE encoding (wide character strings), common in Windows APIs and memory. Wide strings have null bytes between characters ('A' becomes 'A\x00'). This modifier is essential for detecting strings in process memory dumps, registry values, and Windows internal structures where wide encoding is used.


Instruction: When should you use Sigma Wide String Modifier?

Output:
Use cases for Sigma Wide String Modifier:

- Memory content scanning
- Registry value matching
- Windows API string detection

The 'wide' modifier matches strings in UTF-16LE encoding (wide character strings), common in Windows APIs and memory. Wide strings have null bytes between characters ('A' becomes 'A\x00'). This modifier is essential for detecting strings in process memory dumps, registry values, and Windows internal structures where wide encoding is used.


Instruction: What are recommendations for Sigma Wide String Modifier?

Output:
Best practices for Sigma Wide String Modifier:

- Use wide|ascii for comprehensive matching
- Apply to appropriate data sources
- Understand when wide encoding appears

Avoid these mistakes:
- Not all log sources contain wide strings
- Unnecessary on ASCII-only fields
- Backend support varies


Instruction: What should you avoid when using Sigma Wide String Modifier?

Output:
Common pitfalls with Sigma Wide String Modifier:

- Not all log sources contain wide strings
- Unnecessary on ASCII-only fields
- Backend support varies

To avoid these issues:
- Use wide|ascii for comprehensive matching
- Apply to appropriate data sources
- Understand when wide encoding appears


Instruction: When should you use the wide modifier in Sigma?

Output: Use the 'wide' modifier for UTF-16LE encoded strings: (1) Process memory content - Sysmon CallTrace, memory dumps contain wide strings from Windows APIs. (2) Registry values - many registry strings are stored in wide format. (3) File content scanning - PE strings, config files may use wide encoding. (4) Windows event data - some fields contain wide-encoded data. How it works: 'mimikatz' wide becomes 'm\x00i\x00m\x00i\x00k\x00a\x00t\x00z\x00'. When NOT to use: Command line arguments (usually ASCII/UTF-8), Standard text log fields, Network protocol data. Combined usage: '|wide|ascii|contains' searches both encodings - recommended when unsure. Backend conversion: Wide modifier converts to appropriate encoding search in target SIEM.


Instruction: How do you detect strings in process memory with Sigma?

Output: Detecting strings in process memory requires wide-aware rules: Data sources: Sysmon Event 10 (ProcessAccess) with CallTrace enabled, EDR memory scanning events, Custom memory dump analysis. String encoding: Windows process memory typically uses wide (UTF-16LE) strings, APIs and internal structures are wide-encoded. Rule approach: 'CallTrace|wide|contains: "sekurlsa"' for Mimikatz module detection. Common patterns: Credential keywords: 'password', 'credential', 'secret' in memory, Mimikatz modules: 'sekurlsa', 'kerberos', 'lsadump', Injection artifacts: shellcode signatures, known payload strings. Example - LSASS access with suspicious strings: selection: TargetImage|endswith: '\\lsass.exe', CallTrace|wide|contains: ['sekurlsa', 'wdigest', 'kerberos']. Limitation: Not all SIEMs support CallTrace analysis - verify data availability.


Instruction: What is Sigma Placeholders?

Output:
Sigma Placeholders: Sigma placeholders enable dynamic value substitution at conversion time, allowing rules to adapt to environment-specific values. Placeholders are defined in the rule and replaced with actual values from a configuration file during backend conversion. Common uses include domain names, admin account patterns, and organization-specific paths.

Use cases:
- Environment-specific exclusions
- Organization-specific patterns
- Portable rules with customization


Instruction: How do you write Sigma Placeholders?

Output:
Syntax for Sigma Placeholders:

```
# Placeholder in rule
User|startswith: '%Admins%'

# Placeholder configuration (sigma config)
placeholders:
    Admins:
        - 'DOMAIN\\Admin'
        - 'Administrator'
        - 'svc_admin'
```

Sigma placeholders enable dynamic value substitution at conversion time, allowing rules to adapt to environment-specific values. Placeholders are defined in the rule and replaced with actual values from a configuration file during backend conversion. Common uses include domain names, admin account patterns, and organization-specific paths.


Instruction: Show an example of Sigma Placeholders.

Output:
Example of Sigma Placeholders:

```
title: Non-Admin User Running Admin Tool
detection:
    selection:
        Image|endswith:
            - '\\psexec.exe'
            - '\\mimikatz.exe'
    filter_admins:
        User: '%Admins%'
    condition: selection and not filter_admins
```

Sigma placeholders enable dynamic value substitution at conversion time, allowing rules to adapt to environment-specific values. Placeholders are defined in the rule and replaced with actual values from a configuration file during backend conversion. Common uses include domain names, admin account patterns, and organization-specific paths.


Instruction: What problems does Sigma Placeholders solve?

Output:
Use cases for Sigma Placeholders:

- Environment-specific exclusions
- Organization-specific patterns
- Portable rules with customization

Sigma placeholders enable dynamic value substitution at conversion time, allowing rules to adapt to environment-specific values. Placeholders are defined in the rule and replaced with actual values from a configuration file during backend conversion. Common uses include domain names, admin account patterns, and organization-specific paths.


Instruction: What are best practices for Sigma Placeholders?

Output:
Best practices for Sigma Placeholders:

- Document required placeholders
- Provide sensible defaults
- Keep placeholder names descriptive

Avoid these mistakes:
- Forgetting to configure placeholders
- Placeholder config not distributed with rules
- Over-reliance on placeholders reduces portability


Instruction: What mistakes should you avoid with Sigma Placeholders?

Output:
Common pitfalls with Sigma Placeholders:

- Forgetting to configure placeholders
- Placeholder config not distributed with rules
- Over-reliance on placeholders reduces portability

To avoid these issues:
- Document required placeholders
- Provide sensible defaults
- Keep placeholder names descriptive


Instruction: How do Sigma placeholders work?

Output: Sigma placeholders enable environment customization: (1) In rules - use %PlaceholderName% syntax: 'User: %Admins%' matches whatever Admins is configured as. (2) In config - define values in sigma configuration file: 'placeholders: Admins: ["DOMAIN\\Admin", "Administrator"]'. (3) At conversion - pySigma substitutes placeholder with configured values. Use cases: Admin accounts - vary by organization but pattern is consistent, Domain names - 'LogonDomain: %Domain%' for organization's domain, Service accounts - '%ServiceAccounts%' for known legitimate services, Sensitive paths - '%DataPaths%' for PCI/sensitive data locations. Benefits: Write generic rules, customize for environment, update config instead of rules. Requirement: Placeholder config must be maintained alongside rules - document required placeholders in rule metadata.


Instruction: What are common placeholders in Sigma rules?

Output: Common Sigma placeholders for customization: (1) %Admins% - administrative user accounts to exclude: 'User: %Admins%' in filter to exclude known admin activity. (2) %ServiceAccounts% - legitimate service accounts: 'SubjectUserName: %ServiceAccounts%' to exclude service activity. (3) %Domain% - organization's AD domain: 'LogonDomain: %Domain%' for domain-specific filtering. (4) %DomainControllers% - DC hostnames: 'ComputerName: %DomainControllers%' for DC-specific rules. (5) %AdminTools% - sanctioned admin tool paths: 'Image|startswith: %AdminTools%' to exclude legitimate admin tool locations. (6) %SensitiveServers% - critical systems: 'TargetServer: %SensitiveServers%' for high-priority alerting. Configuration: Maintain organization-specific sigma config, version control alongside rules, document placeholder requirements.


Instruction: What is pySigma Backend Conversion?

Output:
pySigma Backend Conversion: pySigma is the Python library for converting Sigma rules to SIEM-specific query languages. It replaces the older sigmac tool with better maintainability and features. pySigma supports numerous backends including Splunk, Elasticsearch, Microsoft Sentinel, and more. Conversion requires specifying the target backend and optionally a pipeline for field mapping and transformations.

Use cases:
- Deploying Sigma rules to SIEMs
- CI/CD detection pipelines
- Rule testing and validation


Instruction: What is the structure of pySigma Backend Conversion?

Output:
Syntax for pySigma Backend Conversion:

```
# Install pySigma
pip install pysigma pysigma-backend-splunk

# Convert rule to Splunk
from sigma.rule import SigmaRule
from sigma.backends.splunk import SplunkBackend

rule = SigmaRule.from_yaml(open('rule.yml').read())
backend = SplunkBackend()
print(backend.convert_rule(rule))
```

pySigma is the Python library for converting Sigma rules to SIEM-specific query languages. It replaces the older sigmac tool with better maintainability and features. pySigma supports numerous backends including Splunk, Elasticsearch, Microsoft Sentinel, and more. Conversion requires specifying the target backend and optionally a pipeline for field mapping and transformations.


Instruction: Show an example of pySigma Backend Conversion.

Output:
Example of pySigma Backend Conversion:

```
# Command line conversion
sigma convert -t splunk rule.yml
sigma convert -t elasticsearch rule.yml
sigma convert -t microsoft365defender rule.yml

# With pipeline
sigma convert -t splunk -p sysmon rule.yml
```

pySigma is the Python library for converting Sigma rules to SIEM-specific query languages. It replaces the older sigmac tool with better maintainability and features. pySigma supports numerous backends including Splunk, Elasticsearch, Microsoft Sentinel, and more. Conversion requires specifying the target backend and optionally a pipeline for field mapping and transformations.


Instruction: When is pySigma Backend Conversion appropriate?

Output:
Use cases for pySigma Backend Conversion:

- Deploying Sigma rules to SIEMs
- CI/CD detection pipelines
- Rule testing and validation

pySigma is the Python library for converting Sigma rules to SIEM-specific query languages. It replaces the older sigmac tool with better maintainability and features. pySigma supports numerous backends including Splunk, Elasticsearch, Microsoft Sentinel, and more. Conversion requires specifying the target backend and optionally a pipeline for field mapping and transformations.


Instruction: What are recommendations for pySigma Backend Conversion?

Output:
Best practices for pySigma Backend Conversion:

- Use appropriate pipelines for data sources
- Test converted queries
- Automate conversion in CI/CD
- Keep pySigma updated

Avoid these mistakes:
- Field mapping differences between SIEMs
- Not all Sigma features supported by all backends
- Converted queries may need tuning


Instruction: What are common pitfalls with pySigma Backend Conversion?

Output:
Common pitfalls with pySigma Backend Conversion:

- Field mapping differences between SIEMs
- Not all Sigma features supported by all backends
- Converted queries may need tuning

To avoid these issues:
- Use appropriate pipelines for data sources
- Test converted queries
- Automate conversion in CI/CD


Instruction: How do you convert Sigma rules to SIEM queries?

Output: Converting Sigma rules to SIEM queries using pySigma: (1) Install backend: 'pip install pysigma pysigma-backend-splunk' (or elasticsearch, sentinel, etc.). (2) Command line: 'sigma convert -t splunk rule.yml' outputs SPL query. (3) Python API: 'from sigma.backends.splunk import SplunkBackend; backend.convert_rule(rule)'. Pipelines: Handle field mapping between Sigma generic fields and SIEM-specific fields. Example: 'sigma convert -t splunk -p sysmon rule.yml' applies Sysmon field mappings. Common backends: splunk, elasticsearch, opensearch, microsoft365defender, sentinelone, crowdstrike. Batch conversion: 'sigma convert -t splunk rules/' converts directory of rules. Output: Native query language for target SIEM, ready for deployment.


Instruction: What are Sigma processing pipelines?

Output: Sigma processing pipelines transform rules during conversion: Purpose: Map generic Sigma fields to SIEM-specific field names, apply transformations. Common pipelines: (1) sysmon - maps Sysmon field names: Image -> process.executable. (2) windows - Windows event log mappings. (3) splunk_windows - Splunk-specific Windows data model mappings. (4) ecs - Elastic Common Schema mappings. Usage: 'sigma convert -t elastic -p ecs rule.yml' applies ECS field mapping. Pipeline functions: Field mapping (Sigma field -> SIEM field), Value transformation (path normalization), Log source mapping (logsource -> index/sourcetype), Condition modification (backend-specific adjustments). Custom pipelines: Create for organization-specific field names, data models. Example: If your Splunk uses 'process_name' instead of 'Image', create mapping pipeline. Pipeline stacking: Multiple pipelines can be applied in sequence: '-p sysmon -p custom_org'.


Instruction: How does Sigma Rule Testing work?

Output:
Sigma Rule Testing: Testing Sigma rules validates that detections work correctly before production deployment. Testing includes syntax validation, logic verification against sample events, false positive assessment, and backend conversion testing. Automated testing in CI/CD pipelines catches issues early and ensures consistent rule quality.

Use cases:
- Pre-deployment validation
- CI/CD integration
- Rule quality assurance


Instruction: Show the format for Sigma Rule Testing.

Output:
Syntax for Sigma Rule Testing:

```
# Syntax validation
sigma check rule.yml

# Test against sample data (with pySigma)
sigma convert -t splunk rule.yml | splunk search

# Unit test framework
# tests/test_rules.py
import pytest
from sigma.rule import SigmaRule

def test_rule_syntax():
    rule = SigmaRule.from_yaml(open('rule.yml').read())
    assert rule.title is not None
    assert rule.logsource is not None
```

Testing Sigma rules validates that detections work correctly before production deployment. Testing includes syntax validation, logic verification against sample events, false positive assessment, and backend conversion testing. Automated testing in CI/CD pipelines catches issues early and ensures consistent rule quality.


Instruction: What does Sigma Rule Testing look like in practice?

Output:
Example of Sigma Rule Testing:

```
# GitHub Actions CI example
name: Sigma Rule Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install pySigma
        run: pip install pysigma
      - name: Validate rules
        run: sigma check rules/
      - name: Test conversion
        run: sigma convert -t splunk rules/
```

Testing Sigma rules validates that detections work correctly before production deployment. Testing includes syntax validation, logic verification against sample events, false positive assessment, and backend conversion testing. Automated testing in CI/CD pipelines catches issues early and ensures consistent rule quality.


Instruction: What are the use cases for Sigma Rule Testing?

Output:
Use cases for Sigma Rule Testing:

- Pre-deployment validation
- CI/CD integration
- Rule quality assurance

Testing Sigma rules validates that detections work correctly before production deployment. Testing includes syntax validation, logic verification against sample events, false positive assessment, and backend conversion testing. Automated testing in CI/CD pipelines catches issues early and ensures consistent rule quality.


Instruction: What are recommendations for Sigma Rule Testing?

Output:
Best practices for Sigma Rule Testing:

- Automate testing in CI/CD
- Test against sample events
- Verify backend conversion
- Include negative tests

Avoid these mistakes:
- Only testing syntax, not logic
- Not testing against real data patterns
- Skipping backend conversion tests


Instruction: What goes wrong with Sigma Rule Testing?

Output:
Common pitfalls with Sigma Rule Testing:

- Only testing syntax, not logic
- Not testing against real data patterns
- Skipping backend conversion tests

To avoid these issues:
- Automate testing in CI/CD
- Test against sample events
- Verify backend conversion


Instruction: How do you test Sigma rules before deployment?

Output: Sigma rule testing should cover multiple aspects: (1) Syntax validation: 'sigma check rule.yml' verifies YAML structure and field names. (2) Conversion testing: 'sigma convert -t [backend] rule.yml' ensures rule converts without errors. (3) Logic testing: Run converted query against sample events - should match attack samples. (4) False positive testing: Run against baseline of normal activity - should not match. (5) Field validation: Verify fields exist in target log source. Testing workflow: Local: sigma check during development, CI: Automated validation on PR, Staging: Test converted rules against sample data, Production: Deploy with monitoring before alerting. Tools: pySigma for conversion testing, custom scripts for logic validation, GitHub Actions/GitLab CI for automation.


Instruction: How do you set up CI/CD for Sigma rules?

Output: Setting up CI/CD for Sigma rules: (1) Repository structure: rules/ for Sigma YAML, tests/ for test cases, .github/workflows/ for CI config. (2) CI pipeline stages: Lint - YAML syntax validation, Check - sigma check for Sigma-specific validation, Convert - test conversion to all target backends, Test - run against sample event data if available. (3) GitHub Actions example: 'on: [push, pull_request]', steps: checkout, install pySigma, 'sigma check rules/**/*.yml', 'sigma convert -t splunk rules/'. (4) Advanced testing: Include sample events in tests/, run converted queries against samples, validate expected matches/non-matches. (5) Deployment automation: On merge to main, convert rules, push to SIEM via API, track deployment status. Benefits: Catch errors before deployment, consistent quality, enable collaboration through PR reviews.


Instruction: What do security professionals need to know about Sigma Rule Packs?

Output:
Sigma Rule Packs: Sigma rule packs are curated collections of rules organized around specific threats, techniques, or data sources. The primary community rule pack is SigmaHQ, containing thousands of community-contributed rules. Organizations can create custom rule packs for internal detections. Rule packs enable efficient deployment of comprehensive coverage and sharing of detection knowledge.

Use cases:
- Deploying comprehensive coverage
- Community rule sharing
- Threat-specific detection packages


Instruction: What is the structure of Sigma Rule Packs?

Output:
Syntax for Sigma Rule Packs:

```
# Clone SigmaHQ rules
git clone https://github.com/SigmaHQ/sigma.git

# Structure
sigma/
├── rules/
│   ├── windows/
│   │   ├── process_creation/
│   │   ├── sysmon/
│   │   └── ...
│   ├── linux/
│   ├── cloud/
│   └── ...
├── rules-emerging-threats/
└── rules-threat-hunting/
```

Sigma rule packs are curated collections of rules organized around specific threats, techniques, or data sources. The primary community rule pack is SigmaHQ, containing thousands of community-contributed rules. Organizations can create custom rule packs for internal detections. Rule packs enable efficient deployment of comprehensive coverage and sharing of detection knowledge.


Instruction: What problems does Sigma Rule Packs solve?

Output:
Use cases for Sigma Rule Packs:

- Deploying comprehensive coverage
- Community rule sharing
- Threat-specific detection packages

Sigma rule packs are curated collections of rules organized around specific threats, techniques, or data sources. The primary community rule pack is SigmaHQ, containing thousands of community-contributed rules. Organizations can create custom rule packs for internal detections. Rule packs enable efficient deployment of comprehensive coverage and sharing of detection knowledge.


Instruction: What are recommendations for Sigma Rule Packs?

Output:
Best practices for Sigma Rule Packs:

- Regularly update from SigmaHQ
- Review rules before deployment
- Customize for environment
- Track rule pack versions

Avoid these mistakes:
- Deploying all rules without review
- Not updating rule packs
- Missing dependencies or pipelines


Instruction: What mistakes should you avoid with Sigma Rule Packs?

Output:
Common pitfalls with Sigma Rule Packs:

- Deploying all rules without review
- Not updating rule packs
- Missing dependencies or pipelines

To avoid these issues:
- Regularly update from SigmaHQ
- Review rules before deployment
- Customize for environment


Instruction: What is SigmaHQ and how do you use it?

Output: SigmaHQ is the primary community repository for Sigma detection rules: Content: 3000+ rules covering Windows, Linux, cloud, network, organized by log source and technique. Structure: rules/ (stable), rules-emerging-threats/ (recent threats), rules-threat-hunting/ (hunting queries). Usage: (1) Clone: 'git clone https://github.com/SigmaHQ/sigma.git', (2) Browse by log source or technique, (3) Convert desired rules: 'sigma convert -t splunk rules/windows/process_creation/', (4) Deploy to SIEM. Best practices: Don't deploy all rules blindly - review for relevance, Start with stable rules matching your log sources, Update regularly for new threat coverage, Customize rules for your environment (add filters). Integration: Use as git submodule for version tracking, automate updates with review process.


Instruction: How do you create a custom Sigma rule pack?

Output: Creating custom Sigma rule packs for your organization: (1) Structure: Mirror SigmaHQ structure for familiarity - rules/[logsource]/[category]/rule.yml. (2) Metadata: Add custom fields for tracking - 'custom_pack: internal-threat-intel', 'custom_owner: soc-team'. (3) Documentation: README explaining pack purpose, coverage, dependencies, deployment instructions. (4) Version control: Git repository with semantic versioning (v1.0.0), changelog for updates. (5) Testing: Include test cases, CI/CD validation, sample events for logic testing. (6) Distribution: Internal package registry, Git repository access, or integration with SIEM. Pack types: Threat-specific (APT29 TTPs), Compliance-focused (PCI logging), Data source specific (custom app logging), Hunting queries (proactive searches). Maintenance: Assign ownership, schedule reviews, track effectiveness metrics.


Instruction: What is Sigma Correlation Rules?

Output:
Sigma Correlation Rules: Sigma correlation rules detect complex attack patterns by combining multiple simple rules into sequences, groups, or threshold conditions. Correlations enable detection of multi-stage attacks where individual events are benign but the combination indicates malicious activity. Sigma supports various correlation types including event sequences, temporal groups, and conditional chains.

Use cases:
- Multi-stage attack detection
- Kill chain correlation
- Behavioral sequences


Instruction: How do you write Sigma Correlation Rules?

Output:
Syntax for Sigma Correlation Rules:

```
# Correlation rule structure
name: Credential Access After Reconnaissance
type: event_count
rules:
    - recon_*
    - credential_*
group-by:
    - ComputerName
timespan: 10m
condition:
    gte: 2
```

Sigma correlation rules detect complex attack patterns by combining multiple simple rules into sequences, groups, or threshold conditions. Correlations enable detection of multi-stage attacks where individual events are benign but the combination indicates malicious activity. Sigma supports various correlation types including event sequences, temporal groups, and conditional chains.


Instruction: Give a practical example of Sigma Correlation Rules.

Output:
Example of Sigma Correlation Rules:

```
title: Lateral Movement Followed by Credential Dump
type: temporal
rules:
    lateral_movement_rdp:
        title: RDP Login
        logsource:
            product: windows
            service: security
        detection:
            selection:
                EventID: 4624
                LogonType: 10
            condition: selection
    credential_dump:
        title: LSASS Access
        logsource:
            product: windows
            service: sysmon
        detection:
            selection:
                EventID: 10
                TargetImage|endswith: '\\lsass.exe'
            condition: selection
timespan: 30m
ordered: true
condition: lateral_movement_rdp -> credential_dump
```

Sigma correlation rules detect complex attack patterns by combining multiple simple rules into sequences, groups, or threshold conditions. Correlations enable detection of multi-stage attacks where individual events are benign but the combination indicates malicious activity. Sigma supports various correlation types including event sequences, temporal groups, and conditional chains.


Instruction: What problems does Sigma Correlation Rules solve?

Output:
Use cases for Sigma Correlation Rules:

- Multi-stage attack detection
- Kill chain correlation
- Behavioral sequences

Sigma correlation rules detect complex attack patterns by combining multiple simple rules into sequences, groups, or threshold conditions. Correlations enable detection of multi-stage attacks where individual events are benign but the combination indicates malicious activity. Sigma supports various correlation types including event sequences, temporal groups, and conditional chains.


Instruction: How should you implement Sigma Correlation Rules?

Output:
Best practices for Sigma Correlation Rules:

- Start with simple correlations
- Test correlation logic thoroughly
- Consider performance impact
- Document expected attack flow

Avoid these mistakes:
- Complex correlations hard to debug
- Backend support varies significantly
- Timespan too long increases false positives


Instruction: What mistakes should you avoid with Sigma Correlation Rules?

Output:
Common pitfalls with Sigma Correlation Rules:

- Complex correlations hard to debug
- Backend support varies significantly
- Timespan too long increases false positives

To avoid these issues:
- Start with simple correlations
- Test correlation logic thoroughly
- Consider performance impact


Instruction: How do Sigma correlation rules work?

Output: Sigma correlation rules combine multiple detections: (1) Rule references: Link existing Sigma rules by name or inline definition. (2) Correlation types: event_count - threshold of matching events, temporal - events within time window, value_count - unique values exceeding threshold. (3) Group-by: Correlate events sharing field values (same host, user, IP). (4) Timespan: Time window for correlation (5m, 1h, 1d). (5) Condition: Logic for triggering (gte: 5, ordered: true for sequences). Example: Detect reconnaissance (whoami, net user) followed by credential access (mimikatz) on same host within 10 minutes. Backend support: Correlation support varies - Splunk (transaction), Elastic (EQL), Sentinel (KQL joins). Complex correlations may require manual implementation in some SIEMs.


Instruction: What attack patterns require correlation detection?

Output: Attack patterns requiring correlation detection: (1) Kill chain sequences: Initial access -> execution -> persistence -> credential access. Each stage may be benign alone. (2) Brute force + success: Multiple failed logins followed by successful login indicates password spray success. (3) Lateral movement chains: RDP to server A, then RDP from A to B, then credential dump on B. (4) Data staging: Multiple file access events followed by compression followed by network transfer. (5) Defense evasion + attack: Security tool disabled followed by malicious activity. (6) Reconnaissance + action: Discovery commands followed by targeted action based on findings. Correlation approach: Identify attack stages, map to observable events, define temporal relationship, set appropriate time windows, group by common entity (user, host, session). Testing: Validate with attack simulation, ensure timing reflects real attack speed.


Instruction: Describe Sigma Field Mapping for detection engineering.

Output:
Sigma Field Mapping: Field mapping translates generic Sigma field names to SIEM-specific field names during rule conversion. Different SIEMs use different field naming conventions for the same data. Sigma uses generic names (Image, CommandLine, User) that map to SIEM-specific fields (process.executable, process.command_line, user.name) via processing pipelines or backend configurations.

Use cases:
- Cross-SIEM rule portability
- Custom data model integration
- Standardized rule authoring


Instruction: How do you write Sigma Field Mapping?

Output:
Syntax for Sigma Field Mapping:

```
# Sigma generic fields
Image          # Process executable path
CommandLine    # Process command line
ParentImage    # Parent process path
User           # Username
SourceIP       # Source IP address

# Example mapping (Elastic ECS)
Image -> process.executable
CommandLine -> process.command_line
ParentImage -> process.parent.executable
User -> user.name
```

Field mapping translates generic Sigma field names to SIEM-specific field names during rule conversion. Different SIEMs use different field naming conventions for the same data. Sigma uses generic names (Image, CommandLine, User) that map to SIEM-specific fields (process.executable, process.command_line, user.name) via processing pipelines or backend configurations.


Instruction: What does Sigma Field Mapping look like in practice?

Output:
Example of Sigma Field Mapping:

```
# Pipeline configuration example
name: my_siem_mapping
transformations:
  - id: field_mapping
    type: field_name_mapping
    mapping:
      Image: endpoint.process.path
      CommandLine: endpoint.process.args
      ParentImage: endpoint.process.parent.path
      User: auth.user.name
```

Field mapping translates generic Sigma field names to SIEM-specific field names during rule conversion. Different SIEMs use different field naming conventions for the same data. Sigma uses generic names (Image, CommandLine, User) that map to SIEM-specific fields (process.executable, process.command_line, user.name) via processing pipelines or backend configurations.


Instruction: What problems does Sigma Field Mapping solve?

Output:
Use cases for Sigma Field Mapping:

- Cross-SIEM rule portability
- Custom data model integration
- Standardized rule authoring

Field mapping translates generic Sigma field names to SIEM-specific field names during rule conversion. Different SIEMs use different field naming conventions for the same data. Sigma uses generic names (Image, CommandLine, User) that map to SIEM-specific fields (process.executable, process.command_line, user.name) via processing pipelines or backend configurations.


Instruction: How do you properly use Sigma Field Mapping?

Output:
Best practices for Sigma Field Mapping:

- Document custom field mappings
- Validate mappings against actual data
- Use standard pipelines when available
- Maintain mapping version control

Avoid these mistakes:
- Incorrect mappings cause silent failures
- Field name typos
- Not accounting for nested fields


Instruction: What are common pitfalls with Sigma Field Mapping?

Output:
Common pitfalls with Sigma Field Mapping:

- Incorrect mappings cause silent failures
- Field name typos
- Not accounting for nested fields

To avoid these issues:
- Document custom field mappings
- Validate mappings against actual data
- Use standard pipelines when available


Instruction: How does Sigma field mapping work?

Output: Sigma field mapping translates generic field names to SIEM-specific names: (1) Generic names: Sigma uses standard names like Image (process path), CommandLine (arguments), User (username). (2) Processing pipelines: Define mappings from generic to specific: 'Image -> process.executable' for Elastic ECS. (3) Backend application: During conversion, pySigma substitutes field names based on pipeline. Standard mappings: Built-in pipelines for common formats - 'sysmon' (Sysmon fields), 'ecs' (Elastic Common Schema), 'splunk_windows' (Splunk CIM). Custom mappings: Create pipeline for custom SIEM or data model with organization-specific field names. Validation: After conversion, verify field names match actual log data structure. Example: Rule with 'Image|endswith: "\\cmd.exe"' converts to 'process.executable:*\\cmd.exe' with ECS pipeline.


Instruction: How do you create custom field mappings for Sigma?

Output: Creating custom Sigma field mappings: (1) Identify fields: List Sigma generic fields used in your rules. (2) Map to SIEM: Document corresponding field names in your SIEM data. (3) Create pipeline: Write YAML pipeline configuration with field_name_mapping transformation. (4) Test conversion: Convert sample rules, verify field names are correct. (5) Validate queries: Run converted queries against actual data to confirm matches. Pipeline structure: 'name: custom_org, transformations: [{type: field_name_mapping, mapping: {Image: your.field.name}}]'. Common custom scenarios: Custom EDR with non-standard fields, Data lake with different schema, Legacy SIEM with unique naming. Maintenance: Update mappings when log sources change, version control pipeline configs, document mapping rationale. Testing: Create test rule with all common fields, convert and validate each field maps correctly.


Instruction: How does YARA Rule Format work?

Output:
YARA Rule Format: YARA is a pattern matching tool designed for malware research and detection. YARA rules describe patterns in files or memory using text strings, hex patterns, and conditions. A rule consists of three main sections: meta (metadata), strings (patterns to match), and condition (logic for when rule triggers). YARA is used for malware classification, threat hunting, and automated file scanning.

Use cases:
- Malware detection
- Threat hunting
- File classification
- Memory scanning


Instruction: What is the structure of YARA Rule Format?

Output:
Syntax for YARA Rule Format:

```
rule RuleName {
    meta:
        description = "Rule description"
        author = "Author Name"
        date = "2024-01-15"
    strings:
        $string1 = "malicious text"
        $hex1 = { 4D 5A 90 }
    condition:
        any of them
}
```

YARA is a pattern matching tool designed for malware research and detection. YARA rules describe patterns in files or memory using text strings, hex patterns, and conditions. A rule consists of three main sections: meta (metadata), strings (patterns to match), and condition (logic for when rule triggers). YARA is used for malware classification, threat hunting, and automated file scanning.


Instruction: Give a practical example of YARA Rule Format.

Output:
Example of YARA Rule Format:

```
rule Mimikatz_Detection {
    meta:
        description = "Detects Mimikatz credential dumping tool"
        author = "Security Team"
        reference = "https://github.com/gentilkiwi/mimikatz"
        severity = "high"
    strings:
        $s1 = "mimikatz" ascii wide nocase
        $s2 = "sekurlsa::logonpasswords" ascii
        $s3 = "privilege::debug" ascii
        $s4 = { 6D 69 6D 69 6B 61 74 7A }
    condition:
        uint16(0) == 0x5A4D and 2 of ($s*)
}
```

YARA is a pattern matching tool designed for malware research and detection. YARA rules describe patterns in files or memory using text strings, hex patterns, and conditions. A rule consists of three main sections: meta (metadata), strings (patterns to match), and condition (logic for when rule triggers). YARA is used for malware classification, threat hunting, and automated file scanning.


Instruction: When should you use YARA Rule Format?

Output:
Use cases for YARA Rule Format:

- Malware detection
- Threat hunting
- File classification
- Memory scanning

YARA is a pattern matching tool designed for malware research and detection. YARA rules describe patterns in files or memory using text strings, hex patterns, and conditions. A rule consists of three main sections: meta (metadata), strings (patterns to match), and condition (logic for when rule triggers). YARA is used for malware classification, threat hunting, and automated file scanning.


Instruction: What are best practices for YARA Rule Format?

Output:
Best practices for YARA Rule Format:

- Include comprehensive metadata
- Use descriptive rule names
- Test against malware samples
- Avoid overly broad conditions

Avoid these mistakes:
- Too specific rules miss variants
- Too broad rules cause false positives
- Not testing against clean files


Instruction: What are common pitfalls with YARA Rule Format?

Output:
Common pitfalls with YARA Rule Format:

- Too specific rules miss variants
- Too broad rules cause false positives
- Not testing against clean files

To avoid these issues:
- Include comprehensive metadata
- Use descriptive rule names
- Test against malware samples


Instruction: What is YARA and how is it used for detection?

Output: YARA is a pattern matching tool for malware identification and classification. Key uses: (1) Malware detection - scan files for known malicious patterns, (2) Threat hunting - search file systems and memory for IOCs, (3) Classification - categorize malware families by shared characteristics, (4) Incident response - identify malicious files during investigations. Structure: Rules contain meta (metadata), strings (patterns), and condition (matching logic). Deployment: YARA rules run via command line (yara), integrated into security tools (VirusTotal, THOR, Loki), or embedded in EDR/sandbox solutions. Example workflow: Analyze malware sample -> extract unique strings/patterns -> write YARA rule -> test against known samples -> deploy for detection. YARA excels at file-based detection where Sigma targets log-based detection.


Instruction: What are the main sections of a YARA rule?

Output: YARA rules have three main sections: (1) meta - metadata about the rule (not used in matching): description, author, date, reference URLs, severity, tags. Optional but highly recommended for documentation. (2) strings - patterns to search for: Text strings ($s = "malware"), Hex patterns ($h = { 4D 5A }), Regular expressions ($r = /pattern/). Each string has a variable name starting with $. (3) condition - boolean logic determining when rule matches: References string variables, uses operators (and, or, not), can include file properties (filesize, entry point). Example: 'condition: $s1 and $s2' requires both strings, 'condition: any of them' matches if any string found. Execution: YARA evaluates strings section first, then checks condition. Rule triggers when condition evaluates to true.


Instruction: How does YARA differ from Sigma?

Output: YARA and Sigma serve different detection purposes: YARA: (1) Scans file content and memory, (2) Pattern matching on binary data, (3) Used for malware detection and classification, (4) Runs against files, processes, network captures, (5) Detects known malicious artifacts. Sigma: (1) Queries log data in SIEMs, (2) Pattern matching on structured events, (3) Used for threat detection in telemetry, (4) Runs against event logs, network logs, cloud audit trails, (5) Detects behaviors and actions. Complementary use: YARA catches malware files landing on disk, Sigma detects the execution and behavior of that malware. Example: YARA rule detects Mimikatz binary, Sigma rule detects Mimikatz behavior (LSASS access). Integration: Some tools (THOR, Velociraptor) combine both for comprehensive detection.


Instruction: Where can YARA rules be deployed?

Output: YARA rule deployment options: (1) Command line - yara binary for manual scanning: 'yara rules.yar /path/to/scan'. (2) EDR platforms - CrowdStrike, Carbon Black, SentinelOne support custom YARA. (3) Malware sandboxes - Cuckoo, Joe Sandbox, ANY.RUN run YARA on submitted files. (4) Threat intelligence - VirusTotal Hunting, YARA Livehunt for internet-scale scanning. (5) DFIR tools - THOR, Loki for forensic scanning of endpoints. (6) Network security - Suricata, Zeek can apply YARA to network traffic. (7) Email gateways - scan attachments with YARA rules. (8) Custom scripts - yara-python library for integration. Best practices: Test rules locally first, deploy to sandbox for validation, then roll to production. Performance: YARA is optimized for speed but complex rules on large filesets can be slow.


Instruction: What do security professionals need to know about YARA Meta Section?

Output:
YARA Meta Section: The meta section contains descriptive information about the YARA rule. It doesn't affect matching but provides crucial context for rule management, attribution, and understanding. Common meta fields include description, author, date, reference, severity, and tags. Well-documented meta sections enable efficient rule portfolio management and incident response context.

Use cases:
- Rule documentation
- Attribution and ownership
- Threat context
- Portfolio management


Instruction: Show the format for YARA Meta Section.

Output:
Syntax for YARA Meta Section:

```
meta:
    description = "Detects malware family X variant"
    author = "John Doe"
    date = "2024-01-15"
    modified = "2024-02-01"
    reference = "https://example.com/threat-report"
    hash = "a1b2c3d4..."
    severity = "high"
    tags = "malware, trojan, apt"
    mitre = "T1059.001"
    tlp = "white"
    version = "1.0"
```

The meta section contains descriptive information about the YARA rule. It doesn't affect matching but provides crucial context for rule management, attribution, and understanding. Common meta fields include description, author, date, reference, severity, and tags. Well-documented meta sections enable efficient rule portfolio management and incident response context.


Instruction: What problems does YARA Meta Section solve?

Output:
Use cases for YARA Meta Section:

- Rule documentation
- Attribution and ownership
- Threat context
- Portfolio management

The meta section contains descriptive information about the YARA rule. It doesn't affect matching but provides crucial context for rule management, attribution, and understanding. Common meta fields include description, author, date, reference, severity, and tags. Well-documented meta sections enable efficient rule portfolio management and incident response context.


Instruction: What are recommendations for YARA Meta Section?

Output:
Best practices for YARA Meta Section:

- Always include description and author
- Add reference links to threat intel
- Include sample hashes for validation
- Use consistent field naming

Avoid these mistakes:
- Missing or outdated metadata
- No references for context
- Inconsistent date formats


Instruction: What goes wrong with YARA Meta Section?

Output:
Common pitfalls with YARA Meta Section:

- Missing or outdated metadata
- No references for context
- Inconsistent date formats

To avoid these issues:
- Always include description and author
- Add reference links to threat intel
- Include sample hashes for validation


Instruction: What metadata should be included in YARA rules?

Output: Essential YARA meta fields: (1) description - clear explanation of what rule detects, (2) author - rule creator for questions/attribution, (3) date - creation date (YYYY-MM-DD format), (4) reference - URL to threat intel, report, or source. Recommended fields: (5) hash - sample hash for rule validation testing, (6) severity/confidence - high/medium/low for prioritization, (7) mitre - ATT&CK technique ID if applicable, (8) tags - categorization (malware family, threat actor, etc.), (9) tlp - Traffic Light Protocol classification, (10) version - rule version for change tracking. Example: meta: description="Detects Emotet dropper", author="SOC Team", date="2024-01-15", reference="https://threat-report.com/emotet", hash="abc123", severity="high", mitre="T1059.005". Good metadata enables: rule triage, investigation context, portfolio management, update tracking.