System DLL loaded from outside the Windows system directories

Siemphony@siemphonymediumT1574.001unverified

Matches Sysmon Module Load where the loaded module carries the file name of a library that Windows ships only under its own system directories, yet the path it was loaded from is not System32, SysWOW64 or WinSxS. That name-plus- location mismatch is the shared shape of the three abuses in this technique — a planted copy next to a trusted executable (side-loading), a copy earlier in the search order than the real one (search-order hijacking), and a file created where the loader looked and found nothing (phantom hijacking). The DLL names are authored for this rule, chosen as libraries Windows itself installs only under its system directories — several of them (version.dll, dbgcore.dll) are nonetheless carried privately by legitimate applications, which is the first false positive below. MITRE's AllowedDllPaths and ProcessAllowList knobs are the intended place for an estate to record its own exceptions, and the path filter here is the minimum viable version of the first. That filter is anchored on the drive-root colon (':\Windows\System32\') rather than on the bare directory name, because a bare '\Windows\System32\' substring is cleared by any lookalike directory an adversary can create in a writable location, and the filter is the only discriminator this rule has. This is deliberately not the same test as the T1129 rule already in this corpus, which keys on temp, roaming and UNC paths together with a non-Valid signature: a DLL planted inside a properly signed application folder in Program Files passes that test and fails this one. What this rule cannot see is a hijack that replaces the real file in place under System32, since the path filter clears it, and it says nothing about whether the module was malicious — only about where it came from. Requires Sysmon with Module Load enabled; the event is absent from a default Windows install and is among the first trimmed in shipped Sysmon configurations for volume, so an empty result means blind rather than clean. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0201, 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.

DeviceImageLoadEvents| where ((FolderPath endswith "\\version.dll" or FolderPath endswith "\\wtsapi32.dll" or FolderPath endswith "\\dbgcore.dll" or FolderPath endswith "\\secur32.dll" or FolderPath endswith "\\sspicli.dll" or FolderPath endswith "\\userenv.dll" or FolderPath endswith "\\profapi.dll" or FolderPath endswith "\\cryptsp.dll" or FolderPath endswith "\\dwmapi.dll" or FolderPath endswith "\\uxtheme.dll" or FolderPath endswith "\\propsys.dll" or FolderPath endswith "\\edputil.dll" or FolderPath endswith "\\textinputframework.dll" or FolderPath endswith "\\winhttp.dll" or FolderPath endswith "\\wininet.dll" or FolderPath endswith "\\apphelp.dll") and not ((FolderPath contains ":\\Windows\\System32\\" or FolderPath contains ":\\Windows\\SysWOW64\\" or FolderPath contains ":\\Windows\\WinSxS\\")))

Splunk · SPL

Run this as a search.

index=* ((ImageLoaded="*\\version.dll" OR ImageLoaded="*\\wtsapi32.dll" OR ImageLoaded="*\\dbgcore.dll" OR ImageLoaded="*\\secur32.dll" OR ImageLoaded="*\\sspicli.dll" OR ImageLoaded="*\\userenv.dll" OR ImageLoaded="*\\profapi.dll" OR ImageLoaded="*\\cryptsp.dll" OR ImageLoaded="*\\dwmapi.dll" OR ImageLoaded="*\\uxtheme.dll" OR ImageLoaded="*\\propsys.dll" OR ImageLoaded="*\\edputil.dll" OR ImageLoaded="*\\textinputframework.dll" OR ImageLoaded="*\\winhttp.dll" OR ImageLoaded="*\\wininet.dll" OR ImageLoaded="*\\apphelp.dll") AND NOT ((ImageLoaded="*:\\Windows\\System32\\*" OR ImageLoaded="*:\\Windows\\SysWOW64\\*" OR ImageLoaded="*:\\Windows\\WinSxS\\*")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(file.path) LIKE "*\\\\version.dll" OR TO_LOWER(file.path) LIKE "*\\\\wtsapi32.dll" OR TO_LOWER(file.path) LIKE "*\\\\dbgcore.dll" OR TO_LOWER(file.path) LIKE "*\\\\secur32.dll" OR TO_LOWER(file.path) LIKE "*\\\\sspicli.dll" OR TO_LOWER(file.path) LIKE "*\\\\userenv.dll" OR TO_LOWER(file.path) LIKE "*\\\\profapi.dll" OR TO_LOWER(file.path) LIKE "*\\\\cryptsp.dll" OR TO_LOWER(file.path) LIKE "*\\\\dwmapi.dll" OR TO_LOWER(file.path) LIKE "*\\\\uxtheme.dll" OR TO_LOWER(file.path) LIKE "*\\\\propsys.dll" OR TO_LOWER(file.path) LIKE "*\\\\edputil.dll" OR TO_LOWER(file.path) LIKE "*\\\\textinputframework.dll" OR TO_LOWER(file.path) LIKE "*\\\\winhttp.dll" OR TO_LOWER(file.path) LIKE "*\\\\wininet.dll" OR TO_LOWER(file.path) LIKE "*\\\\apphelp.dll") AND NOT ((TO_LOWER(file.path) LIKE "*:\\\\windows\\\\system32\\\\*" OR TO_LOWER(file.path) LIKE "*:\\\\windows\\\\syswow64\\\\*" OR TO_LOWER(file.path) LIKE "*:\\\\windows\\\\winsxs\\\\*")))

Wazuh · XML rule

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

<group name="sigma,windows,image_load,">  <!-- 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="ImageLoaded" type="pcre2">(?i)(\\version\.dll$|\\wtsapi32\.dll$|\\dbgcore\.dll$|\\secur32\.dll$|\\sspicli\.dll$|\\userenv\.dll$|\\profapi\.dll$|\\cryptsp\.dll$|\\dwmapi\.dll$|\\uxtheme\.dll$|\\propsys\.dll$|\\edputil\.dll$|\\textinputframework\.dll$|\\winhttp\.dll$|\\wininet\.dll$|\\apphelp\.dll$)</field>    <field name="ImageLoaded" negate="yes" type="pcre2">(?i)(:\\Windows\\System32\\|:\\Windows\\SysWOW64\\|:\\Windows\\WinSxS\\)</field>    <description>System DLL loaded from outside the Windows system directories</description>    <mitre>      <id>T1574.001</id>    </mitre>  </rule></group>

At a glance

Logsource: image_load / windows
Level: medium
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: bce3d878-923d-4cf5-b7fe-1a7c7fe39bd6

ATT&CKT1574.001

T1574.001DLL

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.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

AN0577 asks a defender to correlate file creation, registry changes and module loads to spot DLL hijacking. This rule authors the module-load half alone: a Sysmon Module Load whose loaded file carries the name of a library Windows ships only under its own system directories, loaded from a path that is not one of those directories. That name-plus-location mismatch is the shape shared by all three abuses in the technique — a copy planted beside a trusted executable, a copy placed earlier in the search order, and a file created where the loader looked and found nothing. What the rule does not say is whether the module is malicious. It says only where it came from.

02 · Telemetry you need

category: image_load / product: windows, copied verbatim from AN0577 — the Sysmon EventID 7 vocabulary, so ImageLoaded is the only field used. Module Load is absent from a default Windows install and is among the first events trimmed from shipped Sysmon configurations for volume, so an empty result means blind, not clean. All four backends render the rule.

03 · How the logic works

A selection minus a filter: selection_system_dll and not filter_system_paths. selection_system_dll is ImageLoaded|endswith over sixteen library names — version.dll, wtsapi32.dll, dbgcore.dll, secur32.dll, sspicli.dll, uxtheme.dll, winhttp.dll, apphelp.dll and the rest. That list is authored here; MITRE supplies no values. On its own the selection matches every load of sixteen extremely common libraries, i.e. almost everything. So the filter is the only discriminator this rule has, which is why its shape matters more than the list. It is ImageLoaded|contains over ':\Windows\System32\', ':\Windows\SysWOW64\' and ':\Windows\WinSxS\', anchored on the drive-root colon rather than the bare directory name. Written bare, \Windows\System32\ is a substring any adversary clears with one mkdir — C:\Users\Public\Windows\System32\version.dll would have passed the filter and disabled the whole rule while the board looked clean. The anchoring costs something, and it should be visible to whoever tunes this: a load Sysmon reports as a device path (\Device\HarddiskVolume3\Windows\System32\…) is no longer cleared and arrives as a false positive.

04 · Common false positives

Heavily, on an unbaselined estate. Applications that ship a private copy of a Windows library next to their own executable look identical to a side-load at this level of detail, and installer and crash-reporting frameworks do exactly that with version.dll and dbgcore.dll — a handful of such products account for most of what a managed fleet returns.
Behind it: self-extracting installers and .NET single-file apps unpacking their dependencies into %TEMP% and loading from there; portable tooling run from a profile, a share or a USB volume; software mid-update running from a staging directory. Genuine system locations the filter omits also surface — :\Windows\SysArm32\ on ARM64, and :\Windows\servicing\ or :\Windows\SystemTemp\ during servicing.
Note the level: medium sits above what those entries support. Until the allowlists are populated this is a hunting surface, not an alertable signal.

05 · Detection maturity

tier_1: the lowest tier, and it stays there until the rule has been run against real data. It was authored from a MITRE scaffold containing no query logic and has never been executed against a log line; the DLL list is a plausible selection, not a measured one.
tier_2: run read-only, rank hits by loading process and path, and turn the top of that list into the two allowlists.
tier_3: ** correlate with the file creation that preceded the load inside MITRE's TimeWindow knob, which is what AN0577 actually describes.

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

Populate MITRE's AllowedDllPaths knob for the estate. The first two entries
Use MITRE's ProcessAllowList knob for the development and installer
Add a process gate as the first narrowing once volume is measured — loads by
Do not expect it to see in-place replacement of a real system DLL; the path

Declared by the author

Applications that ship a private copy of a Windows library next to their own executable under Program Files, which crash-reporting and installer frameworks in particular do with version.dll and dbgcore.dll. The load event looks exactly like a side-load at this level of detail, and on a managed fleet a handful of such products account for most of what this rule returns.
Self-extracting installers and .NET single-file or self-contained applications, which unpack their whole dependency set into %TEMP% or %LOCALAPPDATA% and load it from there on every launch, then disappear.
Portable run-from-a-folder tooling — support toolkits, forensic suites and developer utilities executed from a user profile, a removable volume or a file share — that carries its own copies of Windows libraries so it works on older builds.
Software mid-update, where the new payload runs from a staging or rollback directory for a few seconds before the final files are placed under System32 or serviced into WinSxS.

Noise check0 of 2 fired

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

Share this rule

/u/siemphony/bce3d878-923d-4cf5-b7fe-1a7c7fe39bd6

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.

1 thread

@owen-mackay
26 Aug 2026
version.dll is the highest-value entry in that list and also the noisiest — every crash reporter on earth ships a private copy next to its own binary. If you can only afford one tuning pass, allowlist by the loading process's signer rather than by path. The path list grows forever and each addition is a hole; the signer list converges after about a week.
- @tomas-eriksen
  27 Aug 2026
  Agreed. One thing I checked expecting to find a gap and did not: the WinSxS filter is a `contains`, so it also covers the servicing stack loading out of a WinSxS temp directory mid-patch. Tighten that to a `startswith` and you will page the on-call every patch window. Leaving it broad looks sloppy and is actually the correct choice.

System DLL loaded from outside the Windows system directories

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it

1 thread