AN1495: Analytic 1495
Monitor registry modifications to `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages` or `...\OSConfig\Security Packages`, especially insertions of new DLL entries. Correlate this with subsequent DLL module loads into `lsass.exe`. Track unsigned or anomalous DLLs loading into LSASS using image load auditing. LSASS loads unsigned DLL due to AuditLevel=8 registry configuration or System reboot followed by DLL load into lsass.exe
Analyst context for executives and security teams
This analytic matters because changes to Windows LSA Security Packages can cause DLLs to load into LSASS, a highly sensitive authentication process. For leaders, the decision value is whether the organization can prove it monitors both the registry change and the later LSASS module load, because either event alone may be easy to miss or explain away during an incident.
Executive priority
Prioritize this as a Windows identity and incident-response visibility control. LSASS is central to authentication, so gaps here can weaken SOC triage, privileged-access investigations, and audit evidence around credential-related activity. Executives should ask whether teams collect registry modification and image-load telemetry on critical Windows systems, whether unsigned or unusual LSASS-loaded DLLs are reviewed, and whether responders can correlate a registry change with a reboot or later LSASS load.
Technical view
Validate monitoring for modifications to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and ...\OSConfig\Security Packages, especially insertion of new DLL entries. Correlate those registry changes with subsequent DLL module loads into lsass.exe. Detection engineering should focus on image load auditing for LSASS, unsigned DLLs, anomalous DLL paths or names, and the condition described in the source where LSASS loads an unsigned DLL due to AuditLevel=8 registry configuration or after a system reboot followed by DLL load into lsass.exe. Scope is Windows only; no ATT&CK tactic or relationship context was supplied.
Likely telemetry
- Windows registry modification events for LSA Security Packages and OSConfig Security Packages paths
- Process image-load or module-load telemetry for lsass.exe
- DLL signing status and file metadata for modules loaded by LSASS
- System reboot or startup timing to correlate registry persistence with later LSASS DLL loading
- Host inventory and baseline of expected LSASS-loaded security package DLLs
Detection direction
- Confirm that registry auditing covers the specified HKLM LSA paths and captures value additions or changes, not only key creation.
- Correlate registry modification time with lsass.exe DLL load events, including after reboot, because the load may occur later than the registry write.
- Tune for unsigned, newly observed, or non-baseline DLLs loaded into LSASS while accounting for legitimate security packages and enterprise authentication components.
- Review whether image-load auditing is enabled and retained on Windows systems where LSASS visibility is required; lack of module-load telemetry is a material blind spot.
- Use allowlisting or baselining carefully: legitimate LSASS modules may vary by Windows build and installed security software, so local validation is required.
Mitigation priorities
- Establish a known-good baseline for LSA Security Packages and LSASS-loaded DLLs on representative Windows builds.
- Restrict and monitor administrative write access to the relevant HKLM LSA registry locations.
- Enable and retain registry modification and LSASS image-load telemetry on systems where identity risk is material.
- Operationalize triage runbooks that review DLL signature, path, hash, owner, change time, and reboot correlation.
- Include this evidence in incident response and compliance readiness checks for Windows authentication infrastructure.
Analyst notes and limits
This is a detection analytic, not a technique description. The useful defensive pattern is correlation: registry configuration change plus later LSASS module load, with special attention to unsigned or anomalous DLLs. Because no relationships were supplied, this take does not infer a specific ATT&CK tactic, technique, actor, malware family, or campaign.
The official object provides a description but no separate detection field, no relationship context, and no mitigation text. Local environment baselines, Windows audit configuration, and approved security package inventory are required to determine what is suspicious versus expected.
Analytic 1495
Monitor registry modifications to `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages` or `...\OSConfig\Security Packages`, especially insertions of new DLL entries. Correlate this with subsequent DLL module loads into `lsass.exe`. Track unsigned or anomalous DLLs loading into LSASS using image load auditing. LSASS loads unsigned DLL due to AuditLevel=8 registry configuration or System reboot followed by DLL load into lsass.exe
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 196e1656ffa9… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1495Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.