Building a Detection Rule From Scratch: A Complete Sigma Walkthrough With Real Examples

The first question for any detection rule is not 'what Sigma fields should I use?' It is 'what does this technique actually look like on the wire and in logs?'

For PSExec-style lateral movement (MITRE ATT&CK T1569.002, System Services: Service Execution), the attacker:

1. Copies a binary to the target host's ADMIN$ share (the C:\Windows share, accessible over SMB)
2. Creates a remote service on the target host using the Windows Service Control Manager (SCM)
3. Starts that service, which executes the binary
4. Optionally deletes the service and binary after use

Each of these steps leaves traces in different log sources:

For a Sigma rule, we want to find the detection signal that is:

• High specificity (not generated by legitimate tools constantly)
• Available in most environments without special audit configuration
• Hard for attackers to suppress or modify

The best candidate is Windows System Event 7045 (A new service was installed in the system). Legitimate service installation happens infrequently and through known paths. Remote service creation with a random service name, a binary path in a temp directory, and a binary that was just copied over the network is distinctive.

A Sigma rule is a YAML document with these top-level fields:

title: <human-readable title> id: <UUID> status: <experimental | test | stable> description: <one paragraph of what this detects> references: <list of URLs> author: <your name or handle> date: <YYYY-MM-DD> modified: <YYYY-MM-DD> tags:

• attack.<tactic>
• attack.<technique_id> logsource: category: <logsource category> product: <product> service: <service> detection: <selection_name>: <field>: <value> condition: <selection_name> falsepositives:
• <list of known benign triggers>

level: <informational | low | medium | high | critical>

The three sections that determine everything are logsource, detection, and condition.

Sigma's logsource taxonomy has three fields that work together:

• category: Defines the normalized log type (e.g., process_creation, network_connection)
• product: The platform (e.g., windows, linux)
• service: The specific Windows service generating the log (e.g., system, security, sysmon)

For Windows System Event 7045, we use:

logsource: product: windows service: system

This tells sigma-cli to look for the Windows System event log, and Sigma's backend will map this to the correct index or data source in each target SIEM.

For a rule that detects service creation via Sysmon (which gives richer process context), you would use:

logsource: category: process_creation product: windows

We will write both variants.

Service installations that look like PSExec or similar tools share predictable characteristics:

• The service name is randomly generated or uses known PSExec patterns (PSEXESVC)
• The ImagePath (binary path) points to an unusual location, often a temp directory or the Windows root
• The service type is typically User-Mode Service (type 0x10 or 0x20)
• There is no corresponding scheduled deployment or software inventory entry

Here is the core detection block:

title: Suspicious Remote Service Installation - PSExec Pattern id: a8b5a9d1-4c2e-4f8a-b5c6-d7e8f9012345 status: experimental description: | Detects the creation of a Windows service that matches patterns associated with PSExec-style lateral movement. PSExec and similar tools create short-lived services on target hosts to execute commands remotely. This rule triggers on service names and ImagePath patterns consistent with this behavior. references:

• https://attack.mitre.org/techniques/T1569/002/
• https://docs.microsoft.com/en-us/sysinternals/downloads/psexec author: Your Name date: 2026-05-20 tags:
• attack.lateral_movement
• attack.t1569.002
• attack.execution logsource: product: windows service: system detection: service_install: EventID: 7045 service_psexec_name: ServiceName|contains:
  • 'PSEXESVC'
  • 'psexesvc' service_suspicious_path: ImagePath|contains:
  • '\ADMIN$'
  • '\IPC$'
  • '\C$\Windows\Temp'
  • 'C:\Windows\PSEXESVC' service_random_name: ServiceName|re: '^[A-Za-z]{4,8}[0-9]{4,8}$' condition: service_install and (service_psexec_name or service_suspicious_path or service_random_name) falsepositives:
• Legitimate remote administration tools using service-based execution
• Software deployment systems that create temporary services
• Security tools that test for this behavior level: high

Let us break down the detection logic:

service_install: Filters to only Windows Event ID 7045. Everything else is scoped out.

service_psexec_name: Checks for the literal PSEXESVC service name, which is the default name PSExec uses. This is a high-specificity signal: very few legitimate tools use this name.

service_suspicious_path: Checks if the ImagePath (where the service binary lives) contains UNC path patterns (network shares) or known PSExec destinations. A service binary that lives on a network share is almost never legitimate.

service_random_name: A regex to catch renamed PSExec variants. The pattern ^[A-Za-z]{4,8}[0-9]{4,8}$ matches names like 'abcd1234' or 'svchost9182', which are common patterns in random service name generation.

condition: We require a service install event AND at least one of our three suspicious indicator sets. This reduces false positives compared to triggering on any service install.

When you have Sysmon deployed, you can write richer rules that include the parent process context. PSExec on the remote target creates a child process under the PSEXESVC service. The parent process is services.exe (the Windows Service Control Manager), and the command line shows the executed command.

title: PSExec Remote Execution via Service - Sysmon id: b9c6a2d3-5d3f-4g9b-c6d7-e8f9012346ab status: experimental description: | Detects remote command execution patterns associated with PSExec on the target host. PSExec creates a service (PSEXESVC) and executes commands as child processes of services.exe with network logon context. This rule targets the process creation pattern on target hosts. references:

• https://attack.mitre.org/techniques/T1569/002/ author: Your Name date: 2026-05-20 tags:
• attack.lateral_movement
• attack.t1569.002 logsource: category: process_creation product: windows detection: process_parent_service: ParentImage|endswith: '\services.exe' process_psexec_service: ParentCommandLine|contains: 'PSEXESVC' process_suspicious_child: Image|endswith:
  • '\cmd.exe'
  • '\powershell.exe'
  • '\wscript.exe'
  • '\cscript.exe'
  • '\mshta.exe' process_network_logon: LogonType: '3' condition: process_parent_service and process_psexec_service and process_suspicious_child falsepositives:
• Legitimate remote management solutions that create services level: high

Before you deploy any rule, you need to answer: what legitimate behavior does this also match?

For the 7045-based rule, the common false positives are:

Software deployment systems. SCCM, Intune, and similar tools often install temporary services during patch deployment. These will have consistent naming patterns (usually matching the software being deployed) rather than random names. You can reduce noise by adding an allowlist for known deployment service names:

filter_deployment: ServiceName|startswith: - 'SCCM_' - 'MicrosoftUpdate' - 'WindowsUpdate' condition: service_install and (service_psexec_name or service_suspicious_path or service_random_name) and not filter_deployment

Security tools. Some vulnerability scanners and EDR tools create temporary services during scans. Get a list of the service names your tools use and add them to the filter.

RMM platforms. ConnectWise, Kaseya, and similar remote management platforms use service-based execution. These should have consistent, identifiable service names.

The goal is not zero false positives (that is too aggressive and will miss real attacks). The goal is a false positive rate that is low enough for your tier-1 analyst to triage the alerts in a reasonable time, typically fewer than 5-10 per day for a rule at 'high' severity.

If your rule would generate hundreds of alerts per day from legitimate tools, either:

1. Add more specific filters to exclude the legitimate traffic
2. Reduce the severity level so it goes into a lower-priority queue
3. Convert to a hunting query rather than an alert rule

Once your Sigma rule is written and reviewed, use sigma-cli to convert it to your SIEM's native format.

Install sigma-cli and backends:

pip install sigma-cli pip install pySigma-backend-splunk pip install pySigma-backend-elasticsearch pip install pySigma-backend-microsoft365defender

Convert to Splunk:

sigma convert -t splunk -p splunk_windows path/to/your/rule.yml

Output: EventID=7045 (ServiceName="PSEXESVC" OR ServiceName IN ("\ADMIN$", "\IPC$", "C:\Windows\PSEXESVC") OR ServiceName=~"^[A-Za-z]{4,8}[0-9]{4,8}$")

Convert to Elasticsearch/OpenSearch (EQL):

sigma convert -t elasticsearch -p ecs_windows path/to/your/rule.yml

Convert to Microsoft Sentinel (KQL):

sigma convert -t microsoft365defender path/to/your/rule.yml

Convert to YAML for Elastic Security detection rules:

sigma convert -t elasticsearch -p ecs_windows -f kibana_ndjson path/to/your/rule.yml

After conversion, always manually review the output query in your SIEM. Backend conversion is not perfect, and field name mappings occasionally differ between environments. Run the query against historical data before enabling it as an alert to confirm it behaves as expected.

Test against three datasets:

1. Synthetic true positives. Run PSExec (or a tool that generates equivalent events) in a test environment. Confirm your rule fires on the events generated. If you cannot reproduce the technique in a lab, use the sample logs from the SigmaHQ repository's test data.

2. Historical production data. Run your converted query against 30 days of production logs with no alerting. How many results does it return? Are they actual suspicious events, or known-good tools? This tells you your baseline false positive rate.

3. Sigma's built-in test framework. The sigma-cli testing feature lets you define expected true and false positive events in a .yml test file and run automated validation against the rule. This is valuable for regression testing when you modify rules.

If your rule detects something not already covered in the SigmaHQ community repository, consider contributing it back. The process:

1. Fork the SigmaHQ/sigma repository on GitHub
2. Add your rule to the appropriate subdirectory under rules/ (organized by OS and category)
3. Follow the naming convention: <verb>_<noun>.yml (e.g., psexec_lateral_movement.yml)
4. Ensure the rule passes the SigmaHQ linting checks: sigma check path/to/rule.yml
5. Submit a pull request with a description of what the rule detects, what log source it requires, and any test data you have

High-quality community contributions that are properly scoped, have reasonable false positive rates, and include complete metadata (ATT&CK tags, references, description) are generally accepted within a few weeks.

Detection rules are not write-and-forget. They require ongoing maintenance:

Platform updates change field names. When your SIEM vendor releases a major update, field names sometimes change or are normalized differently. A rule that worked for 18 months may suddenly produce no results because a field name changed.

Attacker tools evolve. PSExec has many successors (Impacket, SharpExec, wmiexec) that avoid the PSEXESVC service name. Your rule that detects the original PSExec behavior will miss variants that changed a single parameter. Track ATT&CK technique updates and threat intel on tool evolution.

Your environment changes. When you onboard a new RMM platform, run a software deployment tool, or deploy a new security product, audit your detection rules for new false positive sources introduced by that tool.

Log sources go offline. A forwarder misconfiguration, a network change, or a Windows audit policy reset can silently stop events from flowing to your SIEM. Build detection coverage monitoring (an alert that fires if you see zero service creation events in a 24-hour window) so you know when a log source has gone dark.

Schedule a quarterly review of your top 20 detection rules to confirm they are still firing correctly on test data and that false positive rates remain acceptable.