Unsigned DLL loaded into LSASS as a notification package

Siemphony@siemphonymediumT1556.002unverified

AN1303 asks for a three-way correlation: a registry write to the Notification Packages value, a new DLL file appearing on disk, and LSASS loading it during logon or a password change. RegistryPath, AllowedDLLs and the TimeWindow knob are all built for that join, and Sigma has no correlation operator to hold it together. Two of the three logsources also carry the trap AUTHORING.md rule 12 warns about: the brief maps Security EventID 4657 onto the registry_set category, but 4657 splits the changed value across ObjectName and ObjectValueName, while registry_set's real vocabulary — TargetObject and Details — belongs to Sysmon EventID 13, which this analytic never lists as a source; writing TargetObject against 4657 would parse cleanly and never match. So this rule is built on the one leg that is both a single event and unambiguous in its own vocabulary: Sysmon EventID 7, the moment LSASS loads the new filter DLL. It matches any module load into lsass.exe whose SignatureStatus is not Valid. Most legitimate password filters, and most LSA plugins generally, ship signed, so an unsigned or unavailable-signature load into LSASS is a real but coarse anomaly — coarser than the technique itself, since it also catches any other unsigned LSA notification or authentication package, not password filters specifically. Confirm Sysmon's own config actually captures image loads targeting lsass.exe: EventID 7 is high-volume and most shipped configs, including SwiftOnSecurity's, either exclude it globally or restrict it to a short target-process list that may not include lsass.exe. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0472, 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 (InitiatingProcessFolderPath endswith "\\lsass.exe" and not (SignatureStatus =~ "Valid"))

Splunk · SPL

Run this as a search.

index=* (Image="*\\lsass.exe" AND NOT (SignatureStatus="Valid"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.executable) LIKE "*\\\\lsass.exe" AND NOT (TO_LOWER(file.code_signature.status) == "valid"))

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="Image" type="pcre2">(?i)\\lsass\.exe$</field>    <field name="SignatureStatus" negate="yes" type="pcre2">(?i)^Valid$</field>    <description>Unsigned DLL loaded into LSASS as a notification package</description>    <mitre>      <id>T1556.002</id>    </mitre>  </rule></group>

At a glance

Logsource: image_load / windows
Level: medium
Category: account_manipulation
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 69af3cf4-b6ff-4ae3-a58a-04ff70dd05ea

ATT&CKT1556.002

T1556.002Password Filter DLL

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.

Lessonaccount manipulation

account manipulationAI draft — unreviewed

01 · What this rule detects

MITRE's analytic AN1303 asks for a three-way correlation: a registry write to the Notification Packages value, a new DLL appearing on disk, and LSASS loading it during logon or a password change. Sigma has no operator to hold that join together, and two of the brief's three logsources carry a real trap: the brief maps Security EventID 4657 onto the registry_set category, but 4657 splits the changed value across ObjectName/ObjectValueName while registry_set's actual vocabulary — TargetObject/Details — belongs to Sysmon EventID 13, never listed here. Writing TargetObject against 4657 would parse cleanly and never match. So this rule is built on the one leg that is a single event and unambiguous in its own vocabulary: Sysmon EventID 7, the moment LSASS loads the new filter DLL.

02 · Telemetry you need

Sysmon EventID 7 (image_load), specifically module loads targeting lsass.exe. EventID 7 is high-volume and most shipped Sysmon configs, including SwiftOnSecurity's, either exclude it globally or restrict it to a short target-process allowlist that may not include lsass.exe. Confirm your config actually captures image loads into LSASS before trusting this rule to be quiet rather than blind.

03 · How the logic works

Two blocks, ANDed together. selection_lsass matches any Image ending in \lsass.exe. filter_valid_signature matches loads where SignatureStatus equals Valid. The condition is selection_lsass and not filter_valid_signature — so the rule fires on any module load into LSASS whose signature is not Valid, which includes Invalid and Unavailable alike. It says nothing about which registration mechanism caused the load; it only sees the load itself.

04 · Common false positives

Most legitimate password filters and LSA plugins ship signed, so an unsigned load into LSASS is a real anomaly — but a coarser one than the technique itself. The identical event fires for an unsigned Security Support Provider (T1547.005) registered under Security Packages, an unsigned Authentication Package, or any other unsigned code that ends up in LSASS by a mechanism that never touches Notification Packages at all. A hit cannot tell you which of those happened — confirming that requires the registry-value correlation this single-event rule cannot express. Three named false-positive sources: third-party MFA and credential-provider software (Duo, RSA SecurID, Azure AD Password Protection's DC agent) registering its own legitimate LSA package, some of which Sysmon reports as Unavailable rather than Valid; endpoint security and DLP agents injecting into LSASS for their own credential-theft self-protection; and a freshly imaged host where the local certificate store hasn't caught up yet, causing Sysmon to misreport genuinely signed Microsoft binaries as Invalid. Level is medium, reflecting that the signal is real but structurally ambiguous.

05 · Detection maturity

tier_1: Lowest DeBMM tier: authored from MITRE's prose, never executed against a single log line. It stays there until it has run against real EventID 7 telemetry and someone has confirmed the unsigned-LSASS-load signal actually correlates with password-filter abuse in this environment, rather than with the MFA and DLP agents named above.

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

MITRE names four knobs on AN1303. RegistryPath and TimeWindow both belong to the correlation leg this rule cannot reach. AllowedDLLs — a baseline of known-good password filter DLLs — and FilePathPatterns — expected install directories for legitimate filters — could both tighten a real deployment, but neither maps onto anything image_load exposes about the DLL's origin path versus its expected location; applying them here would mean inventing fields not present in this logsource. Building a SignatureStatus allowlist for the specific MFA and DLP vendors in your environment is the pipeline's own suggestion, not one of MITRE's stated knobs.

Declared by the author

Third-party MFA, smart-card and credential-provider software, for example Duo, RSA SecurID or Azure AD Password Protection's DC agent, that installs its own LSA notification or authentication package — a legitimate LSASS-loaded plugin, and some ship in a state Sysmon reports as Unavailable rather than Valid at load time.
Endpoint security and DLP agents that inject their own module into LSASS for credential-theft self-protection, which is functionally the same load event this rule is built to catch.
A freshly patched or re-imaged host where the code-signing root or intermediate certificate is not yet trusted locally, causing Sysmon to report SignatureStatus as Invalid for genuinely signed Microsoft binaries until the local certificate store catches up.

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 T1556.002, evaluated against their image_load events.

Share this rule

/u/siemphony/69af3cf4-b6ff-4ae3-a58a-04ff70dd05ea

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.

2 threads

@hana-kobayashi
23 Aug 2026
Across our tenants the single biggest source is MFA software installing its own LSA notification package on the domain controllers. Any product in that category does structurally the same thing this rule is built to catch, which is the uncomfortable part: the legitimate and malicious versions differ by who signed the DLL and nothing else. We allowlist by signer plus DC, never by filename.
@owen-mackay
23 Aug 2026
Signature status on image load is slipperier than people expect. On a freshly imaged host with no route to the revocation endpoint, Sysmon reports genuinely Microsoft-signed modules as unavailable, and you get a burst of matches on precisely the day a new build lands — which is also the day nobody wants to be paged. The false-positive list already names it. My ask is that the level stays at medium because of that, not in spite of it.

Unsigned DLL loaded into LSASS as a notification package

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it

2 threads