Service registered with an image path in a user-writable directory

Siemphony@siemphonymediumT1543.003unverified

Anchors on the same Security 4697 service-creation record as the published T1569.002 rule, but on a different field pattern, which is what keeps the two from collapsing into one analytic. T1569.002 matches ServiceFileName being a shell, script host or UNC path — the signature of a tool that abuses the service mechanism to execute something once and move on. This rule matches MITRE's ImagePathFilter knob instead, populated here with a broader set of writable-directory paths than MITRE's own worked example: MITRE's mutableElements entry names only `C:\Users\` and `C:\Temp\` directly (the `\Temp\` term below is written to catch that literal path and, as a side effect, `\Windows\Temp\` too); the additional ServiceFileName terms for `\ProgramData\` and the recycle bin are this rule's own extension of that pattern to other locations that are user-writable but atypical for a service image path, regardless of what kind of binary it is — the signature of a service meant to persist, staged somewhere services do not normally live because the adversary has no Program Files-style install path to drop into. A legitimate-looking, correctly-signed executable registered this way still matches; a shell-launching service registered from a normal install path does not, and is exactly what T1569.002 is for instead. The command-line and driver-load legs of AN1527 (`sc.exe`/PowerShell invocation, `.sys` loads via `ZwLoadDriver`) are separate events this rule does not join to the creation record, and MITRE's UnsignedBinaryAlert and ServiceNamePattern knobs need signature status and a name baseline this log source does not carry. 4697 requires the Audit Security System Extension (Success) subcategory, which is off in a default install and in the MS and CIS baselines — without it this rule is blind, not quiet. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0552, 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.

SecurityEvent| where (EventID == 4697 and (ServiceFileName contains "\\Users\\" or ServiceFileName contains "\\Temp\\" or ServiceFileName contains "\\ProgramData\\" or ServiceFileName contains "\\$Recycle.Bin\\"))

Splunk · SPL

Run this as a search.

index=* (EventID="4697" AND (ServiceFileName="*\\Users\\*" OR ServiceFileName="*\\Temp\\*" OR ServiceFileName="*\\ProgramData\\*" OR ServiceFileName="*\\$Recycle.Bin\\*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (event.code == 4697 AND (TO_LOWER(ServiceFileName) LIKE "*\\\\users\\\\*" OR TO_LOWER(ServiceFileName) LIKE "*\\\\temp\\\\*" OR TO_LOWER(ServiceFileName) LIKE "*\\\\programdata\\\\*" OR TO_LOWER(ServiceFileName) LIKE "*\\\\$recycle.bin\\\\*"))

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="EventID" type="pcre2">(?i)^4697$</field>    <field name="ServiceFileName" type="pcre2">(?i)(\\Users\\|\\Temp\\|\\ProgramData\\|\\\$Recycle\.Bin\\)</field>    <description>Service registered with an image path in a user-writable directory</description>    <mitre>      <id>T1543.003</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: service_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 559b945a-36fd-43d2-805c-ef532569d74b

ATT&CKT1543.003

T1543.003Windows 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.

Lessonservice persistence

service persistence

01 · What this rule detects

Services and daemons registered, altered or invoked so that attacker code runs with high privilege, starts before anyone logs in and survives a reboot. Windows services and kernel drivers, systemd units and timers, launch daemons and agents. It also covers the short-lived variant, where a service is created only to execute one command on a remote host and removed immediately afterwards, and the service enumeration that usually precedes both.

02 · Telemetry you need

System log 7045 (service installed: ServiceName, ImagePath, ServiceType, StartType) and 7040 (start type changed) — written by the Service Control Manager with no audit policy required, which makes them among the few genuinely useful Windows events that are on by default; 7036 exists alongside them but is state-change noise
Security 4697 (a service was installed by the system) — richer, because it names the account that did it, but it needs Audit Security System Extension, which is off by default
Sysmon EventID 12 and 13 on HKLM\SYSTEM\CurrentControlSet\Services covering both ImagePath and, for svchost-hosted services, Parameters\ServiceDll — a rule watching only ImagePath misses every ServiceDll hijack, and Sysmon records nothing under this key unless the configuration includes it
Sysmon EventID 1 with ParentImage of services.exe, and EventID 11 for the binary written to disk — often over an administrative share — shortly before the registration
auditd watches on /etc/systemd/system, /usr/lib/systemd/system, /run/systemd/system and the per-user unit directory under a home profile: with no watch loaded on those directories, a unit file write is recorded nowhere at all, and journald tells you only that a unit started, never what the unit contained
macOS file events under /Library/LaunchDaemons, /Library/LaunchAgents and the per-user LaunchAgents directory, plus process telemetry for launchctl

03 · How the logic works

The trap is 7045. It fires on every legitimate software installation, every driver package and every agent deployment, so a bare 7045 rule is a software inventory feed with an alert queue attached. The signal is not that a service was installed but what was installed: where ImagePath points, whether the file there is signed and by whom, and whether it is a service binary at all. A service whose ImagePath is a command interpreter, a script host, a proxy binary or an executable with inline arguments is not a service any vendor ships — and it usually fails to start, producing a start-failure event that corroborates the finding rather than hiding it.

Location does most of the remaining work. A service binary under a user-writable directory, a profile path or a UNC path is a different population from one under Program Files or the system directory, and that single condition converts the rule from inventory into detection. Keep kernel driver registration separate: drivers arrive through the same 7045 with a driver service type, the legitimate volume is much lower, and a driver loaded from a user-writable path is the shape of the bring-your-own-vulnerable-driver technique, which deserves its own severity.

For the remote-execution variant, do not anchor on the service name. The best-known tool renames its service on request and every reimplementation picks its own, so a name match catches the demo and nothing else. Anchor on the sequence instead: a binary written to an administrative share, a service created, one command run, the service deleted, all inside a few minutes; or services.exe as the parent of something that is not a service binary. A service that appears and disappears in the same window is worth an alert even when the binary was signed.

On Linux, the write to the unit file is the event — but a unit is only as interesting as its ExecStart, so the rule needs the file contents or the execution that follows, not merely the path. Three coverage gaps are worth memorising: the per-user unit directory is missed by every rule scoped to /etc/systemd/system, and a user unit with lingering enabled runs without anyone logged in; timers are the scheduled-task equivalent and hang off the same mechanism; and a transient unit created directly through the systemd run helper has no file to watch at all. Service discovery — listing services locally or remotely — is not worth an alert by itself, but enumeration followed by service creation from the same session is a considerably stronger pairing than either half alone.

04 · Common false positives

Every software installation and update: the installer registers the service, and enterprise patching produces bursts of 7045 across the whole fleet within one maintenance window
Endpoint protection, monitoring and management agent deployment — the agent installs a service on every host, and each upgrade reinstalls it
Remote administration and deployment tooling that installs a temporary service to do its work, including software distribution push installs, credentialed vulnerability scans and remote execution modules in configuration management — genuinely the same behaviour as the attack, performed for a good reason
Driver installation for printers, graphics hardware, VPN clients and virtualisation tooling, which registers kernel services as a matter of routine
Linux package installation and upgrade: dpkg and rpm write and reload unit files continuously, as do container runtimes, snap packages and cloud-init on first boot, and certificate renewal tooling installs a timer
Application servers and databases registering per-instance services during setup, which produces unfamiliar service names in unfamiliar directories on exactly the hosts you care most about

05 · Detection maturity

Tier 1 — starting point: Matches service installation events and known remote-execution service names as they occur.
Tier 2 — tuned: Conditions service registration on where the binary lives and whether it is an interpreter, covers ServiceDll and the systemd unit directories, and excludes deployment tooling by signed path and source host.
Tier 3 — correlated: Correlates the registration with the file written just before it, the signature and fleet rarity of that file, the start failure or deletion that follows, and any service enumeration from the same session.

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

Judge ImagePath by its directory and its signature, not by the service name or the binary name — both names are free to the attacker and the signed path is not
Make 'ImagePath contains an interpreter, a script host or a command-line switch' its own rule at high severity; it is near-silent and it is the shape of almost every hand-built service persistence
Exclude deployment tooling by source host and by the signed publisher of the installed binary, never by the service names it happens to use this quarter
Separate kernel driver registration from user-mode service registration — different volume, different owners, different meaning, and merging them buries the rarer one
Cover ServiceDll wherever you cover ImagePath, and check the rule fires for both; the svchost-hosted route is a standard way past a rule that only knows about ImagePath
On Linux, load the auditd watches first and confirm a test unit write produces an event — an unwatched directory returns nothing, and nothing reads as clean
Pair creation with deletion: a service registered and removed inside the same short window is worth an alert on the sequence alone

Declared by the author

Consumer and line-of-business software that stages a background helper or update service under %ProgramData%\<vendor>\ instead of Program Files — printer and OEM utilities, cloud-sync backends and some security suites all do this by design, and it is likely the largest source of matches on a typical fleet.
IT-run remote-support and diagnostic tools that register a temporary service pointing at a binary copied into a technician's profile or %TEMP% for the duration of a single session.
Application self-updaters that stage the next version's executable under %ProgramData% during an upgrade and re-point the existing service at it before the old file is cleaned up.
Endpoint-security or backup agents whose repair, quarantine or recovery component is deliberately installed from a %ProgramData% cache directory rather than the product's main install path.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

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.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

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

Recordings of T1543.003, evaluated against their — events.

Share this rule

/u/siemphony/559b945a-36fd-43d2-805c-ef532569d74b

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 registered with an image path in a user-writable directory

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it