Event ID 7036 explained: service state changes for DFIR triage

Event ID 7036 — "The {service} service entered the {state} state" — fires on the System channel every time the Service Control Manager (SCM) sees a service transition. Each service start, stop, pause and resume produces one. By itself it is high-volume and easy to dismiss; paired with 7045 (service installed) it is the difference between a backdoor was installed and a backdoor was installed and ran.

For incident response, this is the cheapest "did it execute?" record the OS gives you.

Where it lives

Always the System channel on the host the service ran on. No DC involvement, no per-channel forwarding to worry about — it's right there in System.evtx. The provider is Service Control Manager.

What the record contains

<UserData>
  <EventXML>
    <param1>Background Intelligent Transfer Service</param1>
    <param2>running</param2>
    <Binary>42004900540053000000</Binary>
  </EventXML>
</UserData>

That's it. Two parameters and a binary tag — much smaller than most Security records, which is why analysts skip it.

• param1 — the display name of the service (not the short name). Background Intelligent Transfer Service here is the user-facing name for BITS. To pivot to the service definition you'll often need the short name; the SCM also stamps that into Binary as a UTF-16 encoded blob (the 42 00 49 00 54 00 53 00 here decodes to BITS).
• param2 — the new state: running, stopped, paused, resumed, or one of a handful of pending intermediates (start pending, stop pending). The running and stopped transitions are what most rules key off.

There is no AccountName, no ImagePath, no ProcessId — 7036 tells you what changed state, not who triggered the change. To get the why, pair with other records (see below).

7036 vs 7045 vs 7035 vs 7034

Four service-related System-channel events get confused constantly:

The pattern matters: a 7045 followed seconds later by a 7036 running for the same display name is the textbook "installed and ran" sequence. A 7045 with no matching 7036 means the service was registered but never executed — either the attacker cleaned up, the installer aborted, or the start was deferred.

The triage patterns

1. Persistence verification — pair with 7045

[7045] "A service was installed: PSEXESVC, C:\Windows\PSEXESVC.exe, LocalSystem, demand start"
[7036] "The PSEXESVC service entered the running state"
[7036] "The PSEXESVC service entered the stopped state"

Three records, one PsExec lateral-execution event. The 7036 pair tells you the service actually ran (not just got installed). For a persistent backdoor the second 7036 (stopped) may be missing or may appear hours/days later when the host reboots.

A 7045 with no 7036 running within minutes is its own anomaly — investigate why the install didn't fire. Common causes: the installer is staged for next reboot, the service was set to manual start and the attacker hadn't triggered it yet, or the start failed (look for 7034 / 7000 errors).

2. Defense-evasion signal — stopping security services

The most-abused pattern: an attacker stops WinDefend, MsMpEng, Sense, SecurityHealthService, EventLog, WdNisSvc, or an EDR product's service. Each generates a 7036 stopped for the corresponding display name. If audit-policy / Defender tampering is being attempted, this is one of the records that survives.

The names to alert on (display names; vary by Defender / EDR version):

• Windows Defender Antivirus Service → service WinDefend
• Microsoft Defender Antivirus Network Inspection Service → WdNisSvc
• Windows Defender Advanced Threat Protection Service → Sense
• Security Center → wscsvc
• Windows Event Log → EventLog
• Anything matching *CrowdStrike*, *SentinelOne*, *Carbon*, *Cylance*, *Sophos*, *ESET*, *Symantec*

A 7036 stopped for any of these — especially outside a scheduled maintenance window — should be a hard alert. Many attackers use sc stop, net stop, Stop-Service, or taskkill /im — all four produce a 7036.

3. Service-name typosquatting

7036 fires for the display name even when the underlying service is malicious. Watch for display names that look legitimate but don't actually match any installed Microsoft service: Windows Update Service (real name is Windows Update), Windows Defender Service (real name is Windows Defender Antivirus Service), Microsoft Telemetry (no such service). Run a baseline of display names from a known-good host and diff.

4. Boot anomalies

After a reboot the SCM brings up auto-start services in a roughly stable order. A new auto-start service appearing in the boot 7036 sequence — especially one that wasn't there in the prior boot — is a new persistence point. Cross-reference with the matching 7045 on or before the previous shutdown.

Sample Sigma rule — security service stopped

title: Security Service Stopped via 7036
id: 1d0b3a3a-94a4-44f7-9d29-3c0fbf2c9a91
status: stable
description: A security/defense service transitioned to the stopped state.
references:
  - https://attack.mitre.org/techniques/T1562/001/
logsource:
  product: windows
  service: system
detection:
  selection:
    Provider_Name: 'Service Control Manager'
    EventID: 7036
    param2: 'stopped'
  defender:
    param1|contains:
      - 'Windows Defender'
      - 'Microsoft Defender'
      - 'Microsoft Monitoring'
      - 'Windows Event Log'
      - 'Security Center'
      - 'CrowdStrike'
      - 'SentinelOne'
      - 'Carbon Black'
      - 'Cylance'
      - 'Sophos'
      - 'ESET'
      - 'Symantec'
  condition: selection and defender
falsepositives:
  - Scheduled maintenance windows
  - Vendor uninstall / upgrade workflows
level: high
tags:
  - attack.defense_evasion
  - attack.t1562.001

Sample KQL — 7045 → 7036 sequence

The headline pivot. Persistence install followed by execution within 5 minutes on the same host:

let installs =
    Event
    | where Source == "Service Control Manager" and EventID == 7045
    | extend XmlData = parse_xml(EventData)
    | project InstallTime=TimeGenerated, Host=Computer,
              ServiceName=tostring(XmlData.EventData.Data[0]["#text"]),
              ImagePath=tostring(XmlData.EventData.Data[1]["#text"]),
              AccountName=tostring(XmlData.EventData.Data[3]["#text"]);
Event
| where Source == "Service Control Manager" and EventID == 7036
| extend XmlData = parse_xml(EventData)
| where tostring(XmlData.EventXML.param2) == "running"
| project RunTime=TimeGenerated, Host=Computer,
          DisplayName=tostring(XmlData.EventXML.param1)
| join kind=inner (installs) on Host
| where RunTime between (InstallTime .. InstallTime + 5m)
| project InstallTime, RunTime, Host, ServiceName, DisplayName, ImagePath, AccountName
| order by InstallTime desc

The DisplayName from 7036 won't always literally equal ServiceName from 7045 (one is display, one is short) — match heuristically or precompute a map for the small set of services that matter.

Sample Splunk

index=wineventlog SourceName="Service Control Manager" EventCode=7036
  ( param1="*Defender*" OR param1="*Sense*" OR param1="*EventLog*" OR param1="*Security Center*" )
  param2="stopped"
| table _time host param1 param2

ATT&CK mapping

• T1562.001 — Impair Defenses: Disable or Modify Tools: 7036 stopped for security services.
• T1543.003 — Create or Modify System Process: Windows Service: 7036 running paired with 7045 for the same service.
• T1569.002 — System Services: Service Execution: 7036 running for an ImagePath pointing at a non-standard binary, often as part of lateral movement (PsExec, SCM-based remote execution).
• T1489 — Service Stop: targeted at availability — stopping services to enable other actions (ransomware stopping SQL Server before encrypting databases).

False positives that look exactly like attacks

• Routine Windows Update restarts a dozen services in a predictable sequence. The pattern is recurring and quick.
• Defender signature updates sometimes restart WinDefend itself — a stopped quickly followed by running from MsSecFlt.exe is the normal pattern. The malicious one is no running after the stopped.
• EDR upgrades stop and restart the EDR service. Tag the vendor's upgrade windows.
• System sleep / hibernate generates batches of stopped records at sleep and running records at wake. Combined with wake source events these are obvious; don't alert on them in isolation.
• Container / Hyper-V workloads bring services up and down constantly.

What 7036 doesn't tell you

• No AccountName: the record doesn't say which security context the service is running under. Pull that from the matching 7045 or from the SCM database.
• No PID: you cannot map a 7036 directly to a 4688 / Sysmon 1 record without correlating by ImagePath and timestamp.
• No initiator: you don't see who called Stop-Service. For that you need 7035 (often disabled by default), 4688 for the calling net stop / sc stop / taskkill, or 4104 for Stop-Service.
• Service-short-name mapping: the display name is in param1; the short name is in the binary blob and must be decoded. Most parsers do this automatically; if you're querying raw EventData you have to handle it.

Where 7036 fits in a timeline

The lateral-execution + defense-evasion combo:

1. 4624 — LogonType 3 from an attacker-controlled host, AuthenticationPackage Kerberos.
2. 4688 — services.exe spawning a child for SCM operations (or PsExec's psexesvc.exe).
3. 7045 — service installed, ImagePath outside standard install paths.
4. 7036 running — the install actually fired. This is your execution confirmation.
5. 7036 stopped for WinDefend / EDR — defense evasion before the payload runs.
6. 4688 — payload process under the service account.
7. 7036 stopped for the installer service — cleanup.

7036 appears in steps 4, 5 and 7 — three different stages of the same intrusion. On its own it's hard to use; in context it ties the persistence record (7045) to the actual execution and to the surrounding defense-evasion actions.