---
name: detection-rule-bypass-analyzer
description: Helps detection engineers identify coverage blind spots in system command execution detection rules, evaluate bypass risks, and reduce false negatives. Strictly limited to system command execution rules; not applicable to browser credential theft or abnormal process creation without command semantics.
author: SOCLabs
version: 2.0
---

# Detection Rule Bypass Analyzer

## 1. Overview
Trigger this Skill when a user asks "**Is it possible to bypass this rule?**" or "**Is the detection logic comprehensive?**". This Skill is exclusively designed to analyze **system command execution** detection rules. By deconstructing the rule logic and combining it with real OS command parsing characteristics (e.g., POSIX standards, Windows command-line parsing mechanisms), it accurately pinpoints blind spots in parameter coverage, order, aliases, and abbreviations, and outputs specific bypass test cases.

**Core Principle**: Do not stay at the surface level of syntax. You must complete the full analytical chain: "Understand attack intent -> Deconstruct matching logic -> Verify real command semantics -> Determine bypass feasibility -> Output bypass cases".

## 2. Scope and Boundaries
Applicable only when the rule targets **system command execution** and the user's goal is to **find detection blind spots/bypass methods**.

| Scenario | Applicable | Description |
| :--- | :---: | :--- |
| Asking if a detection rule (e.g., Sigma, EQL, SPL) can be bypassed | ✅ Yes | The core target must be system command execution. |
| Seeking variant/equivalent commands to achieve the same malicious goal | ✅ Yes | Must deduce based on real system command semantics. |
| Analyzing non-command rules like browser credential theft, memory injection, network beacons | ❌ No | Prompt user: "This rule belongs to a non-command execution category and is beyond the scope of this Skill." |
| Analyzing only parent-child process anomalies without specific command parameter semantics | ❌ No | Prompt user: "Lacks specific command semantics; beyond the scope of this Skill." |

## 3. Core Workflow

### Step 1: Identify Rule Background and Attack Intent
- **Penetrate literals**: Don't just look at what strings the rule matches. Point out the **ultimate security objective** behind the command (e.g., privilege escalation, persistence, backdoor account creation, defense evasion, credential access).
- **Auto-completion**: If the user doesn't provide the background, infer it based on command semantics. For example, the intent of `usermod -u 0 -o` is "Create/modify a privileged backdoor account".

### Step 2: Deconstruct Rule Matching Logic
Extract and clarify the current rule's detection boundaries:
1. **Core Command**: The native system command involved (e.g., `usermod`, `powershell`, `xattr`).
2. **Matching Fields**: CommandLine, ProcessName, Image, etc.
3. **Matching Operators**: Exact match (==), contains, regex, wildcard (*), etc.
4. **Hardcoded Conditions**: Hardcoded strings, parameters, order, or paths in the rule.
5. **Filter Conditions**: Whitelist exclusions.

### Step 3: Verify Based on Real System Semantics (Guessing is Strictly Prohibited)
Must verify using real OS command help documentation (`--help`, `man`) or official parsing characteristics:
- **Parameter Control**: Which parameters truly determine the success of the malicious behavior?
- **Parameter Flexibility**: Is reordering allowed? Are they optional? Are there mutually exclusive parameters?
- **Equivalent Expressions**: Long/short options (`-u` vs `--uid`), synonymous commands.
- **Parsing Characteristics**: Linux option bundling (`-ds`), Windows prefix abbreviations (`-Enc` vs `-EncodedCommand`).

### Step 4: Determine Bypass Possibility
Based on the above analysis, provide a clear qualitative conclusion:
- 🔴 **Clear Bypass Exists**: Found commands that achieve the same malicious intent and will definitely not be hit by the current rule.
- 🟡 **Potential Bypass Exists**: Rule coverage is narrow, but whether it can be bypassed depends on the underlying log collector (e.g., whether the EDR normalizes the command line before collection).
- 🟢 **No Obvious Bypass Found**: The current rule logic is rigorous, and no valuable equivalent bypass commands were found.

### Step 5: Deduce and Output Bypass Variants
Exhaustively list valuable bypass commands from the following four dimensions (ignore simple process name bypasses using `sh -c`; focus on the parsing characteristics of the **command parameters themselves**):

1. **Parameter Morphology Changes**:
   - Long/short option substitution (`-u` ↔ `--uid`)
   - Assignment method changes (space-separated ↔ `=` assignment ↔ seamless concatenation, e.g., `-u 0` ↔ `--uid=0` ↔ `-u0`)
2. **Syntax and Parsing Characteristics**:
   - Parameter reordering, interleaved operands (`cmd arg1 -a arg2`)
   - Option bundling (POSIX feature, e.g., `xattr -d -s` ↔ `xattr -ds`)
   - Parameter prefix abbreviations (Windows feature, e.g., PowerShell's `-ec`, `-enc`, `/e`)
3. **Equivalent Substitution and Omission**:
   - Omit unnecessary parameters that are hardcoded in the rule
   - Use other parameter combinations that achieve the same effect (e.g., clear attributes ↔ delete attributes)
4. **Obfuscation and Escaping** (if the rule doesn't use regex or normalization):
   - Extra spaces, quote wrapping (`"u"sermod` or `usermod -u '0'`)
   - Substitution between absolute and relative paths

---

## 4. Output Format Standard

Strictly follow this Markdown structure to output the analysis results:

### 🎯 1. Rule Background & Detection Objective
> **Detection Objective**: [A one-sentence description of the attacker's ultimate malicious purpose using this command, e.g., Using usermod to change a user's UID to 0 to create a Root privilege backdoor]

### 🔍 2. Rule Matching Logic Deconstruction
> **Current Logic**: [A one-sentence summary of the rule's matching conditions, e.g., Requires the command line to contain "usermod", "-u", "0", and "-o" simultaneously and in order]
> **Flaws**: [Point out logical flaws, e.g., Hardcoded parameter order, missing long options]

### ⚠️ 3. Bypass Feasibility Conclusion
> **Conclusion**: [🔴 Clear Bypass Exists / 🟡 Potential Bypass Exists / 🟢 No Obvious Bypass Found]

### 🛡️ 4. Bypass Test Cases
*Note: The following commands can all execute successfully in a real system and achieve the same malicious objective.*

| Command | Result | Bypass Technique | Reason for Miss/Hit |
| :--- | :---: | :--- | :--- |
| `[Original Hit Command]` | 🟢 Hit | Original Baseline | Fully matches the rule's hardcoded features |
| `[Variant Command 1]` | 🔴 Miss | Parameter Reordering | Rule requires A before B; variant places B before A |
| `[Variant Command 2]` | 🔴 Miss | Long Option Substitution | Rule only matches short option `-u`, missed `--uid` |
| `[Variant Command 3]` | 🔴 Miss | Option Bundling (POSIX) | Rule matches `-a -b`, variant uses `-ab` |

---

## 5. Reference Knowledge Base (Parsing Characteristics Memo)

- **Linux/macOS (POSIX) Parsing Characteristics**:
  - Supports option bundling: `-a -b` is equivalent to `-ab`.
  - Option and value concatenation: `-u 0` is equivalent to `-u0`.
  - Equals sign assignment: `--uid 0` is equivalent to `--uid=0`.
  - Interleaved positional parameters: `cmd -a file -b` is usually equivalent to `cmd file -a -b`.
- **Windows (PowerShell/CMD) Parsing Characteristics**:
  - Symbol substitution: `/` can replace `-` (e.g., `/c` ↔ `-c`).
  - Prefix abbreviation matching: PowerShell parameters support the shortest unambiguous prefix. For example, `-EncodedCommand` can be abbreviated as `-Encod`, `-Enc`, `-e`, or even `-ec`.
  - Character obfuscation: CMD supports the `^` escape character; PowerShell supports the backtick `` ` `` escape character.