Service installed under a well-known Windows service display name

Siemphony@siemphonymediumT1036.004unverified

AN0324 asks for service creation "with names or descriptions mimicking legitimate entries." MITRE's own knob for this, TaskNameSimilarityThreshold, calls for a fuzzy comparison — its description names Levenshtein distance — that lib/sigma has no function for; nothing in this pipeline can compute a string-edit distance inside a Sigma condition. This rule substitutes a narrower, exact-match proxy that is entirely its own, not MITRE's: rather than a near-miss of a legitimate name, it looks for an exact reuse of one, paired with an image path outside where that name is ever legitimately installed. EventID 7045 on the System channel is written by the Service Control Manager on every install with no audit policy to enable, and its `ServiceName` field is populated from the display name passed to CreateService, not the internal service key — which is precisely what makes this observable real: a duplicate of an internal key name would be rejected at creation and 7045 would never fire, but nothing stops an installer from reusing a display name that is already in use elsewhere on the system, since display names carry no uniqueness constraint. The twelve names in `selection_known_name` are core, universally-present Windows service display names populated by this pipeline, not sourced from MITRE, chosen because a genuine instance of any of them only ever installs from `\Windows\System32\` or `\Windows\SysWOW64\`; `filter_expected_path` excludes exactly those two locations so the rule fires only when the name and the path disagree. Two of MITRE's other knobs go unreached here: BinaryReputationScore needs an external reputation source no local field carries, and ExecutionContext asks for the account context of a later, anomalous execution of the installed binary — a second, correlated event this single service-creation record does not join to. The Linux leg (AN0325) is not attempted. Its one usable logsource, {product: linux, service: auditd}, reduces — once the fuzzy-name comparison is set aside for the same reason as above — to "a file was written under a systemd unit-file search path," which is exactly what the published T1543.002 rule already covers on that same logsource; re-authoring the identical PATH selector under this technique ID would double-count one signal rather than add coverage, and PATH records carry only a bare filename with no way to tell `networks.service` (a masquerade) from `network.service` (the real unit) beyond a string comparison a reviewer has to make by hand regardless of which technique tagged the alert. AN0325's other two sources, {product: linux, service: osquery} and {product: linux, service: cron}, have no established Sigma field vocabulary anywhere in this corpus. The macOS leg (AN0326) is not attempted either: both its logsources, {product: macos, service: unifiedlog} and {product: macos, service: endpointsecurity}, are unstandardised in this pipeline — the same blocker already recorded against these exact sources for T1037.002, T1059.002, T1548.004 and T1546.006. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0117, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 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

Sentinel · KQL

Run this as a search.

Event| where (((Source =~ "Service Control Manager" and EventID == 7045) and (ServiceName =~ "Windows Update" or ServiceName =~ "Windows Defender Antivirus Service" or ServiceName =~ "Print Spooler" or ServiceName =~ "Background Intelligent Transfer Service" or ServiceName =~ "DHCP Client" or ServiceName =~ "DNS Client" or ServiceName =~ "Windows Event Log" or ServiceName =~ "Remote Procedure Call (RPC)" or ServiceName =~ "Task Scheduler" or ServiceName =~ "Windows Management Instrumentation" or ServiceName =~ "Server" or ServiceName =~ "Workstation")) and not ((ImagePath contains "\\Windows\\System32\\" or ImagePath contains "\\Windows\\SysWOW64\\")))

Splunk · SPL

Run this as a search.

index=* (((Provider_Name="Service Control Manager" AND EventID="7045") AND (ServiceName="Windows Update" OR ServiceName="Windows Defender Antivirus Service" OR ServiceName="Print Spooler" OR ServiceName="Background Intelligent Transfer Service" OR ServiceName="DHCP Client" OR ServiceName="DNS Client" OR ServiceName="Windows Event Log" OR ServiceName="Remote Procedure Call (RPC)" OR ServiceName="Task Scheduler" OR ServiceName="Windows Management Instrumentation" OR ServiceName="Server" OR ServiceName="Workstation")) AND NOT ((ImagePath="*\\Windows\\System32\\*" OR ImagePath="*\\Windows\\SysWOW64\\*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (((TO_LOWER(winlog.provider_name) == "service control manager" AND event.code == 7045) AND (TO_LOWER(service.name) == "windows update" OR TO_LOWER(service.name) == "windows defender antivirus service" OR TO_LOWER(service.name) == "print spooler" OR TO_LOWER(service.name) == "background intelligent transfer service" OR TO_LOWER(service.name) == "dhcp client" OR TO_LOWER(service.name) == "dns client" OR TO_LOWER(service.name) == "windows event log" OR TO_LOWER(service.name) == "remote procedure call (rpc)" OR TO_LOWER(service.name) == "task scheduler" OR TO_LOWER(service.name) == "windows management instrumentation" OR TO_LOWER(service.name) == "server" OR TO_LOWER(service.name) == "workstation")) AND NOT ((TO_LOWER(ImagePath) LIKE "*\\\\windows\\\\system32\\\\*" OR TO_LOWER(ImagePath) LIKE "*\\\\windows\\\\syswow64\\\\*")))

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="7">    <!-- 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)^7045$</field>    <field name="ServiceName" type="pcre2">(?i)(^Windows Update$|^Windows Defender Antivirus Service$|^Print Spooler$|^Background Intelligent Transfer Service$|^DHCP Client$|^DNS Client$|^Windows Event Log$|^Remote Procedure Call \(RPC\)$|^Task Scheduler$|^Windows Management Instrumentation$|^Server$|^Workstation$)</field>    <field name="ImagePath" negate="yes" type="pcre2">(?i)(\\Windows\\System32\\|\\Windows\\SysWOW64\\)</field>    <description>Service installed under a well-known Windows service display name</description>    <mitre>      <id>T1036.004</id>    </mitre>  </rule></group>

At a glance

Logsource: system / windows
Level: medium
Category: masquerading
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 5b6f127f-92cc-4b85-9d0a-62b1943c1046

ATT&CKT1036.004

T1036.004Masquerade Task or Service

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.

Lessonmasquerading

masqueradingAI draft — unreviewed

01 · What this rule detects

A Windows service creation (EventID 7045) whose ServiceName is one of twelve well-known built-in display names, installed from a binary path outside \Windows\System32\ or \Windows\SysWOW64\. AN0324 asks for service creation "with names or descriptions mimicking legitimate entries" — this rule is a narrower, exact-match reading of that.

02 · Telemetry you need

product: windows, service: system. EventID 7045 is written by the Service Control Manager on every install with no audit policy to enable — one of the few observables in this corpus with no prerequisite gate. ServiceName is populated from the display name passed to CreateService, not the internal service key, which is what makes the observable real: an attacker cannot duplicate an internal key (creation would fail) but nothing stops reuse of a display name, since display names carry no uniqueness constraint.

03 · How the logic works

MITRE's own knob, TaskNameSimilarityThreshold, calls for a fuzzy comparison — its description names Levenshtein distance — that lib/sigma cannot express; nothing in this pipeline can compute string-edit distance inside a Sigma condition. The rule substitutes an entirely different, narrower proxy that is its own, not MITRE's: exact reuse of a real name, paired with a path where that name is never legitimately installed. The twelve literal names in selection_known_name are core, universally-present Windows services chosen by this pipeline because a genuine instance only ever installs from System32 or SysWOW64; filter_expected_path excludes exactly those locations so the rule fires only on name/path disagreement. Two other MITRE knobs go unreached: BinaryReputationScore needs an external reputation source no local field carries, and ExecutionContext asks for the account context of a later, correlated execution this single creation record does not join to. The Linux and macOS legs of the same strategy are declined outright — Linux reduces to a PATH selector already covered by the published T1543.002 rule, and both macOS sources are unstandardised anywhere in this corpus. A defect a reviewer found and this lesson must flag directly: the review verdict notes selection_known_name matches against twelve literal English strings. Windows service display names are localized per system UI language — on a French, German or Japanese install, EventID 7045's ServiceName for the genuine service carries the localized string, not "Print Spooler," and so would any masquerading service an attacker names to blend in on that host. On any non-English Windows fleet, this selection currently matches nothing at all, real or malicious — a silent, complete blind spot the rule's own description never discloses. Treat this build as English-locale-only until the twelve names are translated to the target build's localized strings.

04 · Common false positives

The false-positive list names EDR and deception products that deliberately install decoy services under common built-in names as lateral-movement tripwires — precisely what this rule is built to catch, so overlap is structural, not accidental. Offline-servicing pipelines (DISM, MDT, SCCM task sequences, WinPE recovery) can also legitimately re-register a core service from a staging drive mid-provisioning, and OEM recovery-partition tools may reinstall Windows Update or BITS from a repair path. level: medium sits below the rule's implicit confidence because none of these three sources are rare.

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from DET0117, never run against a log line. The twelve names, the locale assumption, and the System32/SysWOW64 filter are all unvalidated.
tier_2: needs the English-locale gap closed before this rule is trustworthy outside a US/UK English fleet.

Tuning & false positivesexperimental · 3 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

Exclude known EDR/deception vendor paths once identified in your estate. Time-box or tag alerts that fall inside a known provisioning window (SCCM task sequence logs, imaging schedules) rather than suppressing the path outright. Before deploying anywhere non-English, replace or extend the twelve names with the target locale's actual display strings — verify against a genuine 7045 event on that build first, not against a translation guess.

Declared by the author

EDR and deception-technology products that deliberately install decoy services carrying common built-in display names such as Print Spooler or Windows Update from their own install directory as a tripwire for lateral-movement and service-enumeration tooling — the product this rule is aimed at catching is exactly what these are designed to resemble.
Offline-servicing and imaging pipelines — DISM offline package injection, MDT and SCCM task sequences, WinPE-based recovery tools — that stage or re-register a core OS service from a temporary build drive or staging directory partway through provisioning, before the final image places it back under \Windows\System32\.
OEM recovery-partition tools and system-repair utilities that reinstall a named Windows service such as Windows Update or BITS from a repair or recovery-image path to fix a corrupted installation, rather than from the live System32 tree.

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 T1036.004, evaluated against their — events.

Share this rule

/u/siemphony/5b6f127f-92cc-4b85-9d0a-62b1943c1046

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.

Service installed under a well-known Windows service display name

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it