DET0542: Registry and LSASS Monitoring for Security Support Provider Abuse
DET0542 matters because abuse of Windows Security Support Providers can turn a persistence mechanism into direct identity risk: DLLs loaded by the Local Se...
Analyst context for executives and security teams
DET0542 matters because abuse of Windows Security Support Providers can turn a persistence mechanism into direct identity risk: DLLs loaded by the Local Security Authority can run at system start and may access sensitive credential material. For leaders, the practical question is whether the organization can prove it watches the relevant LSA registry configuration and LSASS/LSA loading behavior well enough to support fast containment decisions.
Executive priority
Prioritize this as an identity and Windows resilience control validation, not just a malware alert. The related ATT&CK technique is tied to persistence and privilege escalation, so coverage helps answer audit and incident-response questions such as: who can change LSA security package configuration, are those changes logged, can the SOC distinguish approved security software from suspicious additions, and can IR rapidly identify affected hosts if credentials may be exposed.
Technical view
Validate coverage for the related Windows technique T1547.005, Security Support Provider. ATT&CK states SSP DLLs are loaded into the Local Security Authority process at system start and that SSP configuration is stored in Registry locations including HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages. SOC teams should confirm monitoring for changes to that configuration and for LSASS/LSA loading behavior that aligns with unexpected SSP additions. Because the detection-strategy object has no official detection text or platform field, implementation should be grounded in local Windows telemetry and baselining of legitimate SSP/security-package activity.
Likely telemetry
- Windows Registry modification events for LSA Security Packages configuration
- Endpoint telemetry showing LSASS/Local Security Authority module or DLL load activity
- Host boot/startup timing context for newly loaded security packages
- Process and file metadata for DLLs associated with LSA/SSP loading
- Change-management or allowlist records for approved authentication/security software changes
Detection direction
- Alert on unauthorized or unexpected changes to LSA Security Packages registry configuration, with tuning for legitimate operating system, authentication, and security product changes.
- Correlate registry changes with subsequent LSASS/LSA DLL loading after startup to reduce noise and strengthen incident confidence.
- Baseline approved SSP-related entries per Windows build and managed security tooling; treat deviations as high-value triage candidates because of the related persistence and privilege-escalation tactics.
- Validate that endpoint logging survives reboot/startup scenarios, since the related behavior is loaded when the system boots.
- Document blind spots where registry auditing, endpoint module-load telemetry, or LSASS visibility is absent or restricted.
Mitigation priorities
- Restrict and monitor administrative ability to modify LSA-related registry configuration.
- Maintain a documented baseline of approved SSP/security package entries and the business owner for each.
- Ensure endpoint detection and response or native Windows logging captures registry changes and relevant LSASS/LSA load evidence.
- Integrate detections with incident-response playbooks for credential-risk assessment, host isolation decisions, and credential rotation decisions when warranted by local evidence.
- Use change-management evidence to distinguish approved authentication/security software updates from unplanned persistence changes.
Analyst notes and limits
This take is based on DET0542’s name, external reference, and its relationship to ATT&CK technique T1547.005 Security Support Provider. The relationship provides the key decision context: Windows SSP DLLs load into LSA at system start, can access sensitive credential material, and are associated with persistence and privilege escalation. Local baselines are essential because legitimate Windows and security software may use related mechanisms.
The supplied detection-strategy object has no official description, no official detection text, and no explicit platform or tactic fields. Windows, persistence, privilege escalation, LSA/LSASS, and registry context are derived from the supplied relationship to T1547.005. This summary does not assert active exploitation, attribution, or existing detection coverage.
Registry and LSASS Monitoring for Security Support Provider Abuse
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.005 | Security Support Provider Sub-technique | This object detects Security Support Provider. |
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 | 5e99606fc092… |
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 DET0542Open 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.