Skip to content

Siemphony is in beta and still being built. How a rule earns its badge.

Siemphony’s repertoire

Detect a defensive service terminating unexpectedly

AN2038 is about a security product being degraded by something other than its own management interface: "service crashes, unexpected restarts, driver unloads, telemetry gaps". This rule takes the second leg of that directly — the Service Control Manager reporting that a defensive service died without having been asked to stop (System 7031 and 7034). That is the observable that separates T1687 from T1562.001: `sc stop WinDefend`, `net stop wscsvc` and the Stop-Service cmdlet all use the sanctioned control path and produce 7035/7036, never a 7031, so a rule built on the control interface selects for the complement of this technique. Exploiting a parsing bug in the scanner, a malformed IOCTL to a vulnerable minifilter, or a bring-your-own-vulnerable- driver kill of the agent all end the same way: the service is gone and nobody sent it a control. `param1` is the service display name in the SCM message, which is why the terms are display-name fragments rather than short names. Populate it with the site's own agents — that is exactly MITRE's ProtectedServiceList knob, and no corpus rule can guess a fleet's EDR. The driver-unload arm (Sysmon EID 6 on a vendor minifilter) and the telemetry-gap arm both need a different logsource or a timer and are not expressed here. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0900, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The detection

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

title: Detect a defensive service terminating unexpectedlyid: c556764b-50cf-4d0b-a281-0e89a08eb6d8status: experimentaldescription: |  AN2038 is about a security product being degraded by something other than its  own management interface: "service crashes, unexpected restarts, driver  unloads, telemetry gaps". This rule takes the second leg of that directly —  the Service Control Manager reporting that a defensive service died without  having been asked to stop (System 7031 and 7034). That is the observable that  separates T1687 from T1562.001: `sc stop WinDefend`, `net stop wscsvc` and the  Stop-Service cmdlet all use the sanctioned control path and produce 7035/7036,  never a 7031, so a rule built on the control interface selects for the  complement of this technique. Exploiting a parsing bug in the scanner, a  malformed IOCTL to a vulnerable minifilter, or a bring-your-own-vulnerable-  driver kill of the agent all end the same way: the service is gone and nobody  sent it a control. `param1` is the service display name in the SCM message,  which is why the terms are display-name fragments rather than short names.  Populate it with the site's own agents — that is exactly MITRE's  ProtectedServiceList knob, and no corpus rule can guess a fleet's EDR. The  driver-unload arm (Sysmon EID 6 on a vendor minifilter) and the telemetry-gap  arm both need a different logsource or a timer and are not expressed here.  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0900, not hand-written and not tested by its author. Any lab result is on this rule's own page.references:  - https://attack.mitre.org/techniques/T1687  - https://attack.mitre.org/detectionstrategies/DET0900author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)date: 2026-08-16tags:  - attack.defense-evasion  - attack.t1687logsource:  product: windows  service: systemdetection:  selection:    Provider_Name: 'Service Control Manager'    EventID:      - 7031      - 7034    param1|contains:      - 'Defender'      - 'Firewall'      - 'Security Center'      - 'Windows Security'      - 'System Guard'      - 'Sysmon'      - 'Windows Event Log'  condition: selectionfalsepositives:  - "The security agent crashing on its own. A bad definition update, an out-of-memory condition, a driver conflict after a kernel patch, or a botched self-upgrade all produce exactly this event with no adversary present, and across a large fleet they are the majority of matches. MITRE's ProtectedServiceList knob says which services to watch and nothing about why they died, so this rule cannot separate a crash from an induced crash on its own — the CrashCorrelationWindow leg, correlating a preceding suspicious interaction, is what would, and Sigma has no construct for it."  - "Abrupt power transitions. Forced shutdowns, hypervisor snapshot restores and non-persistent VDI pool recycles make the SCM record services as terminated unexpectedly, in bursts, at the same times of day."  - "An administrator or a management agent killing a hung security service with `taskkill /f` rather than stopping it. That is a forced but sanctioned stop — T1562.001, not exploitation — and it reaches the SCM as the same 7031."  - "Any service whose display name merely contains one of the fragments. Matching on `Firewall` or `Windows Security` picks up third-party products with those words in their names, which may or may not be defensive components a site cares about."level: high

Splunk · SPL

Run this as a search.

index=* (Provider_Name="Service Control Manager" AND (EventID="7031" OR EventID="7034") AND (param1="*Defender*" OR param1="*Firewall*" OR param1="*Security Center*" OR param1="*Windows Security*" OR param1="*System Guard*" OR param1="*Sysmon*" OR param1="*Windows Event Log*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(winlog.provider_name) == "service control manager" AND (event.code == 7031 OR event.code == 7034) AND (TO_LOWER(winlog.event_data.param1) LIKE "*defender*" OR TO_LOWER(winlog.event_data.param1) LIKE "*firewall*" OR TO_LOWER(winlog.event_data.param1) LIKE "*security center*" OR TO_LOWER(winlog.event_data.param1) LIKE "*windows security*" OR TO_LOWER(winlog.event_data.param1) LIKE "*system guard*" OR TO_LOWER(winlog.event_data.param1) LIKE "*sysmon*" OR TO_LOWER(winlog.event_data.param1) LIKE "*windows event log*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="12">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="Provider_Name" type="pcre2">(?i)^Service Control Manager$</field>    <field name="EventID" type="pcre2">(?i)(^7031$|^7034$)</field>    <field name="param1" type="pcre2">(?i)(Defender|Firewall|Security Center|Windows Security|System Guard|Sysmon|Windows Event Log)</field>    <description>Detect a defensive service terminating unexpectedly</description>    <mitre>      <id>T1687</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. `param1` has no Sentinel column: System-channel message parameters live inside `ParameterXml`, not in a column of their own. The Sigma source is on the first tab, unchanged.

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Log in to react
Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

Log in to report a verdict.

Log in to join the discussion.

No comments yet. Someone who deploys this will have something to say about it.