Windows Security tray process executing from an unexpected path

Siemphony@siemphonymediumT1685.003unverified

AN0868 is written as a correlation — the Defender tray UI reporting healthy while WinDefend/MsMpEng are actually stopped — but neither log source in its brief can carry "what the UI displayed": System 7036 only records a service's own start/stop transitions, and it fires constantly for normal service management across the whole machine, not just Defender, so a rule built on it cannot tell an adversary's stop from an admin's `net stop`. What the Sysmon process-creation leg can carry is the other half of AN0868's own `FakeUIProcessPatterns` knob: a masquerading binary that borrows the filename of the two processes that actually render the Windows Security tray icon, `SecurityHealthSystray.exe` and `SecurityHealthService.exe`, run from outside the directories Windows ships them in. This rule matches on that name-and-path mismatch and is a masquerading detection, not a health/UI-mismatch detection — it catches a dropped or renamed fake UI executed as a new process, not a legitimate SecurityHealthSystray.exe whose rendering has been hooked or patched in place, which leaves the recorded Image path untouched and is invisible here. AN0869 (Linux) and AN0870 (macOS) are not authored: both briefs describe the same behaviour in prose only — "execution of processes mimicking Apple Security & Privacy GUIs" — with no process name, path, or message pattern given, so any predicate for those platforms would be authored from nothing rather than derived from the brief. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0311, 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.

DeviceProcessEvents| where ((FolderPath endswith "\\SecurityHealthSystray.exe" or FolderPath endswith "\\SecurityHealthService.exe") and not ((FolderPath startswith "C:\\Windows\\System32\\" or FolderPath startswith "C:\\Windows\\SysWOW64\\")))

Splunk · SPL

Run this as a search.

index=* ((Image="*\\SecurityHealthSystray.exe" OR Image="*\\SecurityHealthService.exe") AND NOT ((Image="C:\\Windows\\System32\\*" OR Image="C:\\Windows\\SysWOW64\\*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*\\\\securityhealthsystray.exe" OR TO_LOWER(process.executable) LIKE "*\\\\securityhealthservice.exe") AND NOT ((TO_LOWER(process.executable) LIKE "c:\\\\windows\\\\system32\\\\*" OR TO_LOWER(process.executable) LIKE "c:\\\\windows\\\\syswow64\\\\*")))

Wazuh · XML rule

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

<group name="sigma,windows,process_creation,">  <!-- 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="Image" type="pcre2">(?i)(\\SecurityHealthSystray\.exe$|\\SecurityHealthService\.exe$)</field>    <field name="Image" negate="yes" type="pcre2">(?i)(^C:\\Windows\\System32\\|^C:\\Windows\\SysWOW64\\)</field>    <description>Windows Security tray process executing from an unexpected path</description>    <mitre>      <id>T1685.003</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: defense_evasion_disable_tools
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 2067d343-d9b7-46a4-8b83-495ad66d911a

ATT&CKT1685.003

T1685.003Modify or Spoof Tool UI

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.

Lessondefense evasion disable tools

defense evasion disable toolsAI draft — unreviewed

01 · What this rule detects

A process running under the filename SecurityHealthSystray.exe or SecurityHealthService.exe — the two binaries that render the Windows Security tray icon — launched from outside the System32/SysWOW64 directories Windows ships them in. This is a masquerading detection: a dropped or renamed fake UI binary trying to pass as the healthy Defender status indicator.

02 · Telemetry you need

Sysmon EventID 1 (process creation), category: process_creation, product: windows. No special audit policy is required beyond Sysmon installed with its default process-creation config — Image and full path are captured out of the box.

03 · How the logic works

Two blocks. selection_names matches Image ending in either target filename. filter_legit_path excludes Image starting with C:\Windows\System32\ or C:\Windows\SysWOW64\. The condition is selection_names and not filter_legit_path — right name, wrong location, fires. AN0868's own analytic is written as a correlation between the tray UI reporting healthy and WinDefend/MsMpEng actually being stopped, but neither log source in its brief can carry "what the UI displayed": System 7036 records generic service start/stop machine-wide, not Defender specifically, and can't tell an attacker's stop from an admin's net stop. This rule instead uses the other half of AN0868's FakeUIProcessPatterns knob — the process names themselves — which is why it catches masquerading, not the health/UI mismatch MITRE actually describes. It will miss a real, unmodified SecurityHealthSystray.exe that has been hooked or patched in place, since Image never changes for that case.

04 · Common false positives

Windows servicing and feature updates stage these binaries briefly outside System32 (via Windows Update or WinSxS staging) before placing them during a build upgrade. Detection-engineering and atomic-test runs that deliberately place a same-named test binary elsewhere will also fire. Portable technician toolkits sometimes repackage a renamed copy of these executables onto USB media for support work. Any unrelated third-party software that happens to name a component identically and installs under Program Files will match too — filename alone can't distinguish that from impersonation.

05 · Detection maturity

tier_1: Never run against a log line — lowest DeBMM tier. It needs deployment against real Sysmon data to measure false-positive volume from servicing and staging paths, and a team decision on whether this masquerading proxy is sufficient or the fuller health-state correlation AN0868 describes needs to be built separately, likely against System 7036 with per-service filtering this brief doesn't offer.

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

Add a WinSxS staging exception to filter_legit_path (currently only System32/SysWOW64) if OS-servicing noise proves significant in your fleet. Treat any hit as a masquerading candidate, not confirmation that the Defender tray is lying — the rule can't see the health-state correlation MITRE's analytic actually describes, so don't read a match as "UI confirmed spoofed." Consider adding a known-technician-toolkit hash or path allowlist if support workflows are a recurring source.

Declared by the author

Windows servicing and feature-update staging, where these binaries execute momentarily from a Windows Update or WinSxS staging directory before being placed in System32 as part of a build upgrade.
Detection-engineering and atomic-test validation runs that deliberately place a same-named test binary outside System32 to exercise this rule rather than to impersonate the security UI.
Portable diagnostic or repair toolkits that repackage a renamed copy of these executables into a technician's USB or troubleshooting bundle for legitimate support work, run from a Downloads or removable-media path.
Third-party software that happens to name an unrelated component SecurityHealthSystray.exe or SecurityHealthService.exe and installs it under Program Files rather than System32; the filename match alone cannot distinguish this from impersonation.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 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 T1685.003, evaluated against their process_creation events.

Share this rule

/u/siemphony/2067d343-d9b7-46a4-8b83-495ad66d911a

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.

Windows Security tray process executing from an unexpected path

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it