Skip to content

Siemphony is in beta and still being built. How a rule earns its badge.

Siemphonybeta
Siemphony’s repertoire

Unsigned DLL loaded into LSASS as a notification package

Siemphony@siemphonymediumT1556.002unverifiedPlaybook · Persistence established
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 detection

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

title: Unsigned DLL loaded into LSASS as a notification packageid: 69af3cf4-b6ff-4ae3-a58a-04ff70dd05eastatus: experimentaldescription: |  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.references:  - https://attack.mitre.org/techniques/T1556/002  - https://attack.mitre.org/detectionstrategies/DET0472author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)date: 2026-08-17tags:  - attack.defense-evasion  - attack.persistence  - attack.credential-access  - attack.t1556.002logsource:  category: image_load  product: windowsdetection:  selection_lsass:    Image|endswith: '\lsass.exe'  filter_valid_signature:    SignatureStatus: 'Valid'  condition: selection_lsass and not filter_valid_signaturefalsepositives:  - "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."level: medium

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>

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Log in to react
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.

Log in to report a verdict.

Log in to join the discussion.

2 threads

  • @hana-kobayashi

    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

    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.