DET0207: Detect LSA Authentication Package Persistence via Registry and LSASS DLL Load
This detection strategy matters because it is aimed at a Windows persistence path where changes to LSA authentication package configuration can cause code...
Analyst context for executives and security teams
This detection strategy matters because it is aimed at a Windows persistence path where changes to LSA authentication package configuration can cause code to load into LSASS at system start. For leaders, the practical issue is not just malware persistence; it is whether the organization can prove it monitors sensitive authentication infrastructure changes and can quickly distinguish approved security/identity software from unauthorized DLL loading in a highly privileged process.
Executive priority
Prioritize this as an identity and endpoint resilience control validation item. Because the related ATT&CK technique is associated with persistence and privilege escalation on Windows, security leaders should ask whether registry changes affecting LSA authentication packages are logged, whether LSASS module-load visibility exists, and whether incident responders have a tested process for triaging suspicious authentication package changes without disrupting business-critical logon services.
Technical view
The supplied object has no official detection text, but its name and relationship indicate a strategy focused on correlating LSA authentication package registry configuration with DLL loading by LSASS for T1547.002 Authentication Package. SOC and detection teams should validate coverage for Windows registry modifications to LSA authentication package configuration, LSASS DLL/module load events, related file creation or modification for referenced DLLs, and system restart timing. Triage should account for legitimate authentication, endpoint security, and identity components that may interact with LSA, so baselining and allowlisting require care.
Likely telemetry
- Windows registry auditing or EDR registry events for LSA authentication package configuration changes
- Process/module-load telemetry showing DLLs loaded by LSASS
- File creation, modification, and path metadata for DLLs referenced by LSA configuration
- Endpoint process context around tools or accounts making registry changes
- System boot or service-start timing that explains when LSASS loaded configured packages
Detection direction
- Validate that registry changes to LSA authentication package settings are collected with actor, host, timestamp, and before/after value context.
- Correlate suspicious registry entries with subsequent LSASS DLL/module-load evidence rather than relying on either signal alone.
- Baseline known-good authentication packages and security software to reduce false positives, but review new or rare DLL paths carefully.
- Pay attention to blind spots where LSASS module loading is not captured, registry auditing is disabled, or EDR policies suppress sensitive process telemetry.
- Use the related technique context—Windows persistence and privilege escalation—to prioritize alerts on domain controllers, administrative workstations, and other identity-critical systems when those assets are in scope locally.
Mitigation priorities
- Confirm logging coverage first: registry auditing, endpoint telemetry, and LSASS module-load visibility are the deciding evidence sources for this strategy.
- Restrict and monitor administrative access capable of changing LSA-related registry configuration.
- Maintain an approved inventory of authentication packages and related security/identity software so responders can separate expected components from unauthorized changes.
- Integrate detections with change-management evidence to identify unapproved modifications quickly.
- Prepare IR playbooks for validating suspicious LSA configuration changes, collecting affected DLLs for analysis, and restoring trusted configuration without causing authentication outages.
Analyst notes and limits
This take is derived from DET0207, its title, external reference, and its relationship to ATT&CK technique T1547.002 Authentication Package. The ATT&CK object itself does not provide official detection logic or platform metadata, so the Windows scope and persistence/privilege-escalation framing come from the related technique context supplied in the relationship.
No official description or detection text was provided for DET0207, and the detection strategy object lists no platforms or tactics. Local telemetry availability, approved authentication packages, and asset criticality must be validated before judging coverage or risk.
Detect LSA Authentication Package Persistence via Registry and LSASS DLL Load
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1547.002 | Authentication Package Sub-technique | This object detects Authentication Package. |
All related ATT&CK context
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 | 29c1d75d6126… |
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 DET0207Open 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.