Availability-critical Windows service terminating unexpectedly

Siemphony@siemphonylowT1499.004unverified

AN0850 describes exploitation followed by a service crash, restart or repeated failure, and only the last part of that has an observable in the brief's log sources. This rule takes the System channel leg: the Service Control Manager reporting that a service died without having been sent a control request (EventID 7031 and 7034), scoped by display-name fragment to the web, database and remote-access tiers whose loss is the denial of availability this sub-technique is about. The other two legs cannot carry the behaviour. Sysmon EventID 1 is a launch record with no crash, fault or resource field, and Application EventID 1000 exposes the faulting binary only through unnamed Data elements with no field vocabulary this corpus can rely on. Note what the SCM does not see: a worker process killed by an exploit is not a service termination. An IIS application pool dying takes w3wp.exe with it and is reported by WAS on this same System channel under the Microsoft-Windows-WAS provider, not by the Service Control Manager, so the two IIS fragments below match only if the W3SVC or IISADMIN host process itself dies — the commonest web-exploitation crash on this platform is invisible here, and the same holds for any engine that isolates work in child processes. MITRE's TargetApplication knob names the tier to watch and is populated here with a generic starter list that every site must replace with its own service display names; MITRE's TimeWindow knob asks for repetition (for example five crashes in an hour), and lib/sigma models no aggregation, no timeframe and no near, so the repetition that would separate a re-exploited persistent DoS from one bad afternoon is not expressed. A single match therefore means one critical service died uncommanded, not that anything was exploited. This is the same SCM signal the published T1687 rule uses; the two differ only in which services they name, T1687 watching defensive agents being degraded and this rule watching availability of the service tier, and their name lists do not overlap. Unlike the process-creation legs elsewhere in this brief, 7031 and 7034 need no audit policy — the SCM writes them by default. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0304, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

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

Splunk · SPL

Run this as a search.

index=* (Provider_Name="Service Control Manager" AND (EventID="7031" OR EventID="7034") AND (param1="*World Wide Web Publishing*" OR param1="*IIS Admin*" OR param1="*SQL Server*" OR param1="*MySQL*" OR param1="*PostgreSQL*" OR param1="*Apache*" OR param1="*Routing and Remote Access*" OR param1="*Remote Desktop Services*"))

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(param1) LIKE "*world wide web publishing*" OR TO_LOWER(param1) LIKE "*iis admin*" OR TO_LOWER(param1) LIKE "*sql server*" OR TO_LOWER(param1) LIKE "*mysql*" OR TO_LOWER(param1) LIKE "*postgresql*" OR TO_LOWER(param1) LIKE "*apache*" OR TO_LOWER(param1) LIKE "*routing and remote access*" OR TO_LOWER(param1) LIKE "*remote desktop services*"))

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="5">    <!-- 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)(World Wide Web Publishing|IIS Admin|SQL Server|MySQL|PostgreSQL|Apache|Routing and Remote Access|Remote Desktop Services)</field>    <description>Availability-critical Windows service terminating unexpectedly</description>    <mitre>      <id>T1499.004</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.

At a glance

Logsource: system / windows
Level: low
Category: impact_destruction
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 8566a296-824e-4277-beb1-27dd4dfa0a3d

ATT&CKT1499.004

T1499.004Application or System Exploitation

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonimpact destruction

impact destructionAI draft — unreviewed

01 · What this rule detects

The rule watches the Windows System log for the Service Control Manager announcing that a service died without being told to: EventID 7031 ("terminated unexpectedly, will restart") and 7034 ("has done this N times"). It narrows those to services whose display name looks like a web, database or remote-access tier — the services whose loss is the denial of availability this sub-technique names. MITRE's AN0850 describes exploitation followed by a crash, restart or repeated failure; only the crash half has an observable in the brief's Windows log sources, and this rule is that half.

02 · Telemetry you need

The windows/system channel, forwarded from the servers that host the application tier — not just domain controllers and workstations, which is where System-log collection usually stops. Unlike most rules in this corpus there is no audit-policy prerequisite: the SCM writes 7031 and 7034 in a default install. What you do have to check is your normaliser. The service display name lives in the event's first insertion string, mapped here as param1; pipelines that flatten Windows events into a message blob, or that name insertion strings differently, will silently drop the only field doing the scoping and leave you matching every service crash on the estate.

03 · How the logic works

One selection with three conditions that must all hold. Provider_Name pins the source to the Service Control Manager so that no other component's 7031 can slip in. EventID accepts either 7031 or 7034. param1|contains then requires the display name to include one of eight fragments — the IIS pair, three database engines, Apache, and the two remote-access services. There is no filter block and no negation; the condition is the bare selection. Two blind spots are structural. A worker process killed by an exploit is not a service termination, so an IIS application pool dying takes w3wp.exe with it and is reported by WAS, not by the SCM — the two IIS fragments only fire if the W3SVC or IISADMIN host process itself dies. The same holds for any engine that isolates work in child processes. And MITRE's TimeWindow knob asks for repetition (its example is five crashes in an hour); Sigma models no aggregation, so a single match means one critical service died uncommanded, not that anything was exploited.

04 · Common false positives

Software faults dominate. A database engine or Apache dies from memory exhaustion, a corrupt config, a full disk or a post-patch driver conflict, and the SCM records this exact event with no adversary present. Power loss, hypervisor snapshot restores, live-migration failures and storage path flaps produce bursts of it across many services at once. Upgrades that stop a service by killing it rather than through the control interface do the same, once per host in a rollout window. And contains is generous: any third-party product whose display name embeds "SQL Server" or "Apache" matches too.

05 · Detection maturity

tier_1: Lowest tier. This rule was derived from MITRE ATT&CK DET0304 and has never been run against a log line — no measured volume, no confirmed field mapping, no true positive. Treat the level of low as an unverified guess and re-rate it after a week of real data.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE's TargetApplication knob names the tier to watch; the eight fragments below it are the pipeline's own generic starter list and every site must replace them with its own service display names, taken from Get-Service on the real servers. Anchor them tightly enough to exclude bundled instances you do not consider critical. Add the Microsoft-Windows-WAS provider as a separate rule if IIS matters to you. Then rebuild the repetition MITRE asked for outside Sigma, as a SIEM correlation on this rule's output.

Declared by the author

Ordinary software faults in the service host itself. A database engine or an Apache service dies on its own from memory exhaustion, a corrupt configuration file, a full disk or a driver conflict after a patch, and the SCM records exactly this event with no adversary present — across any server fleet these are the majority of matches. Nothing in a single 7031 distinguishes a bug from an induced crash, which is why this rule is scored low.
Abrupt power transitions and infrastructure operations. Forced shutdowns, hypervisor snapshot restores, live-migration failures and storage path flaps make the SCM record running services as terminated unexpectedly, usually several at once and often in scheduled maintenance windows.
Product upgrades and patch installs that stop a service by killing it rather than through the control interface, so the SCM sees a termination it never asked for. A rollout across the fleet produces a burst of these within the same change window.
Any service whose display name merely contains one of these fragments. Matching on Apache or SQL Server picks up unrelated third-party products that embed those words, including bundled instances a site does not consider availability-critical.

Noise checknot tested

No baseline event covers this rule’s log type (system / windows), so the rule was never evaluated. This is missing data, not a clean result — nothing was checked either way.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1499.004, evaluated against their — events.

Share this rule

/u/siemphony/8566a296-824e-4277-beb1-27dd4dfa0a3d

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

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

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.

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

Availability-critical Windows service terminating unexpectedly

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it