Sigma Rules for Detecting Injection Attacks: from web request to child process

Was I hacked?

Perhaps. A web log containing a suspicious quote, SQL keyword or shell metacharacter is evidence of input, not proof that an interpreter obeyed it. Internet-facing applications receive a daily allotment of nonsense from scanners, broken clients and researchers who have forgotten which test window they opened. Treat the request as a lead. Then ask whether it reached a vulnerable sink and whether anything changed afterwards.

The strongest injection investigation joins three kinds of evidence:

1. a suspicious request or application validation failure;
2. an application, database or identity event showing that the request was interpreted unexpectedly;
3. a consequence, such as a web-server process launching a shell, an unusual database query, a new account or an unauthorised data read.

Sigma is useful because it expresses this detection logic in portable YAML. A backend converts the rule into a query for Splunk, Elastic, Microsoft Sentinel or another supported platform. Sigma is not a web application firewall, an exploit scanner or a magical proof-of-compromise machine. It is a common language for telling a SIEM what evidence deserves attention.

This lab builds three layers: a request indicator, a structured application event and a high-confidence process consequence. Use them only on systems and logs you are authorised to monitor.

Before writing a rule, make the telemetry worth detecting

A beautifully indented Sigma rule cannot recover a field that was never logged. For a web application, collect at least:

Do not log passwords, session cookies, API keys or complete request bodies merely to improve a detection. Prefer a request identifier, route template, actor identifier and stable validation rule ID. OWASP's logging guidance recommends recording security-relevant events while excluding secrets and sensitive personal data.

A useful application event might look like this:

{
  "EventType": "input_validation_failure",
  "RuleId": "INJECTION_SEARCH_TERM_01",
  "SourceIp": "192.0.2.44",
  "ActorId": "user-1842",
  "Route": "/api/search",
  "RequestId": "req-7f1f3d",
  "Outcome": "blocked"
}

The event says what the application decided without preserving the hostile value itself. The example IP belongs to the documentation-only 192.0.2.0/24 range.

Rule 1: suspicious SQL-injection strings in web requests

SigmaHQ maintains an upstream rule named SQL Injection Strings In URI, ID 5513deaf-f49a-46c2-a6c8-3f111b5cb453. At the time of review it is marked test, uses the generic webserver log source and matches a set of encoded and unencoded strings in the URL. Use the current upstream version rather than copying a frozen pattern list into a wiki and discovering three years later that the wiki has become archaeology.

Start by placing the official rule in your rules repository and mapping its URL field to your web telemetry. Then tune it around routes and clients you actually operate. A deliberately smaller teaching rule looks like this:

title: Possible SQL Injection Syntax In Web Request
id: 8d43f76d-cd62-47cb-9f69-16ce7f805d69
status: experimental
description: Detects several SQL-like fragments in a decoded request target. Requires local tuning.
references:
  - https://github.com/SigmaHQ/sigma/blob/master/rules/web/webserver_generic/web_sql_injection_in_access_logs.yml
author: notmyfault.fail Research
date: 2026-09-05
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - "union select"
      - "information_schema"
      - "sleep("
      - "waitfor delay"
  condition: selection
fields:
  - c-ip
  - cs-method
  - cs-uri-stem
  - cs-uri-query
  - sc-status
falsepositives:
  - Security documentation containing SQL examples
  - Approved vulnerability scanning
  - Search features that legitimately index source code
level: medium

This is an indicator rule, not a verdict. It can miss obfuscation and it can alert on harmless documentation. Make sure your pipeline decodes or normalises URL data consistently; matching both raw and decoded values without labelling them can double the alerts and halve the analyst's patience.

When it fires, pivot on RequestId, source IP, actor, route and a narrow time window. Check whether the response was a rejection, whether the same actor tried variants, and whether the database recorded an unusual statement or row count. If all you have is the string, classify the event as an attempt or probe until stronger evidence appears.

Rule 2: repeated application validation failures

The application knows more than the reverse proxy. If it emits stable, structured security events, Sigma can detect repeated failures without storing attacker-supplied payloads.

title: Repeated Injection Validation Failure Event
id: 145f9189-0719-4413-aec6-8686e80c3458
status: experimental
description: Detects an application event raised when injection-oriented validation blocks a request.
references:
  - https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
author: notmyfault.fail Research
date: 2026-09-05
logsource:
  product: custom_application
  service: application_security
  definition: Requires mapped EventType, RuleId, SourceIp, Route and RequestId fields
detection:
  selection:
    EventType: input_validation_failure
    RuleId|startswith:
      - "INJECTION_"
      - "SQLI_"
      - "COMMAND_"
  condition: selection
fields:
  - SourceIp
  - ActorId
  - Route
  - RequestId
  - RuleId
  - Outcome
falsepositives:
  - Approved security testing
  - Misconfigured API clients
level: medium

The title says “repeated”, but a base Sigma rule does not create a portable threshold merely by wishing very hard. Use this selection as the event rule, then configure aggregation in your target SIEM: for example, alert when one actor or source generates five matching events against one route within ten minutes. Keep the unaggregated event available for correlation.

Your conversion pipeline must map the custom fields to the names in your data platform. Without that mapping, the YAML is valid but operationally decorative. Document the expected schema next to the rule and add one example event to the test fixtures.

Rule 3: a web server launches an unexpected child process

Command injection and web shells may cause a web worker to start a command interpreter or administration utility. SigmaHQ's fuller upstream rule Suspicious Process By Web Server Process, ID 8202070f-edeb-4d31-a010-a26c72ac5600, covers a broader list of web-server parents and suspicious children. A compact Windows teaching version is:

title: Web Server Spawning Command Interpreter
id: fa6ef548-6837-48e1-9faf-8d6b922cc76c
status: experimental
description: Detects common Windows web workers spawning command or script interpreters.
references:
  - https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_webshell_susp_process_spawned_from_webserver.yml
author: notmyfault.fail Research
date: 2026-09-05
logsource:
  category: process_creation
  product: windows
detection:
  parent:
    ParentImage|endswith:
      - "\\w3wp.exe"
      - "\\httpd.exe"
      - "\\nginx.exe"
      - "\\php-cgi.exe"
  child:
    Image|endswith:
      - "\\cmd.exe"
      - "\\powershell.exe"
      - "\\pwsh.exe"
      - "\\wscript.exe"
      - "\\cscript.exe"
  condition: parent and child
fields:
  - Computer
  - User
  - ParentImage
  - Image
  - CommandLine
  - ProcessId
  - ParentProcessId
falsepositives:
  - Documented application maintenance or deployment jobs
level: high

This signal is substantially stronger than a suspicious URL, but it still needs context. Some legacy applications launch scripts for reporting, image conversion or deployment. Inventory those jobs, identify their expected executable paths and service accounts, and build narrow exclusions. Do not exclude every powershell.exe child from a web process because one scheduled task is noisy; that cures the alert by removing the smoke alarm.

For Linux, use process telemetry from auditd, eBPF or your endpoint agent and create an equivalent rule for nginx, apache2, httpd, php-fpm or the application runtime spawning shells and download utilities. Parent-child fidelity varies by sensor, so validate it on the actual host.

Convert the rules for your SIEM

The current Sigma CLI documentation offers a standard Python installation and backend plugins:

python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install --upgrade pip sigma-cli
sigma plugin install splunk
sigma convert --target splunk --pipeline splunk_windows ./rules

If you use uvx, the same documentation shows an isolated one-command approach:

uvx --from sigma-cli --with pysigma-backend-splunk \
  sigma convert --target splunk --pipeline splunk_windows ./rules

Replace the backend and pipeline with ones supported for your platform. Read the generated query before deploying it. Confirm that field names, case handling, URL decoding and process paths correspond to your data. A successful conversion proves that the translator understood the YAML; it does not prove that your logs contain the required fields.

Validate safely with synthetic events

For each rule, keep a small test set containing:

• one event that must match;
• one near-miss that must not match;
• one known benign event from your environment;
• one event with missing or differently cased fields;
• one production-shaped event with secrets removed.

Send the fixtures into a test index or use your SIEM's rule preview. For the process rule, create a benign lab event representing w3wp.exe spawning cmd.exe; do not expose or exploit a vulnerable server simply to make the dashboard turn red. Verify that the alert contains the host, actor, parent, child and request-correlation fields needed by the responder.

After deployment, run the rule in observation mode for several days. Measure match volume, unique routes, approved scanners and known maintenance jobs. Tighten exclusions around identified business behaviour, never around a broad attacker-controlled field.

Correlate the layers

The useful story is a sequence, not a single match:

suspicious request
        ↓ same request ID, actor, host or short time window
application accepted or failed to reject it
        ↓
database anomaly or web-server child process
        ↓
identity, file or configuration change

Cross-source correlation is usually implemented in the SIEM because field normalisation and time-window syntax differ between platforms. Require at least two signals before escalating a medium-confidence probe to a likely incident. A high-confidence consequence such as an unexpected web worker launching a shell may justify immediate isolation even when the original HTTP request is missing.

If you see that consequence, preserve evidence, isolate the affected workload according to your incident plan, rotate credentials available to the process, inspect persistence and rebuild from a known-good source when integrity cannot be established. The companion data-injection detection playbook explains the application and SOC workflow in more depth.

Common mistakes

• Treating every matched SQL word as successful SQL injection.
• Logging full payloads, tokens or cookies for “better visibility”.
• Copying a community rule without pinning its source and review date.
• Deploying a rule before checking whether its fields exist.
• Suppressing a noisy parent-child combination globally instead of narrowing the known job.
• Looking only at ingress logs and ignoring database, process and identity consequences.
• Testing detection in production with attack payloads when synthetic events would answer the question.

Handover checklist

• The rule has an owner, review date and upstream reference.
• Required log sources and retention are documented.
• A pipeline maps every field used by the rule.
• Positive, negative and benign fixtures pass.
• Secrets and personal data are excluded from application security logs.
• Approved scanners and maintenance jobs have narrow, explained exceptions.
• The alert includes a request ID or another usable correlation key.
• Responders know when to classify an event as a probe, attempted injection or confirmed compromise.
• The related response playbook is linked from the alert.

Sigma gives a detection team a maintainable vocabulary. Its real value appears when the application emits sensible events, the endpoint records consequences and the analyst can join both without guessing. Begin with one well-tested rule per evidence layer. More YAML is not the same thing as more visibility.

Related reading

• What is Data Injection?
• How Data Injection Attacks Work
• Data Injection Examples
• How to Detect Data Injection
• Data Injection Prevention

References

• Sigma documentation
• Sigma rule specification
• Sigma rule conditions
• SigmaHQ main rule repository
• OWASP Logging Cheat Sheet
• OWASP Injection Prevention Cheat Sheet

Safety boundary

Use these detections on systems and telemetry you own or are authorised to monitor. The examples intentionally focus on log design, safe synthetic validation and defensive correlation. They do not require exploiting a live application.