Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1547.002: Authentication Package

Adversaries may abuse authentication packages to execute DLLs when the system boots. Windows authentication package DLLs are loaded by the Local Security Authority (LSA) process at system start. They provide support for multiple logon processes and multiple security protocols to the operating system.[1]

Adversaries can use the autostart mechanism provided by LSA authentication packages for persistence by placing a reference to a binary in the Windows Registry location HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ with the key value of "Authentication Packages"=<target binary>. The binary will then be executed by the system when the authentication packages are loaded.

EnterpriseT1547.002Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Authentication Package persistence matters because it places adversary-controlled code in a Windows authentication path that loads during system start under the Local Security Authority context. For leaders, this is not just another autorun location: it touches logon infrastructure and privileged process trust, so a missed change can undermine incident containment, credential-protection assumptions, and evidence that privileged Windows hosts are hardened.

Executive priority

Prioritize this as a Windows privileged-persistence and privilege-escalation risk. Security leaders should ask whether changes to LSA authentication package configuration are monitored, whether LSASS-related DLL loads are visible to the SOC, and whether privileged process protections such as Windows RunAsPPL are enabled where appropriate. This is especially relevant for audit evidence around hardening, identity infrastructure readiness, and incident response scoping of systems where authentication components may have been modified.

Technical view

ATT&CK describes this as a Windows sub-technique of Boot or Logon Autostart Execution used for persistence and privilege escalation. The key defensive validation is whether the SOC can detect modification of HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ Authentication Packages and correlate it with DLL loading by LSASS at system start. Relationship context identifies DET0207, Detect LSA Authentication Package Persistence via Registry and LSASS DLL Load, and mitigation M1025, Privileged Process Integrity, including enabling RunAsPPL on Windows systems. Flame is listed as software using this technique, but that relationship should be used as historical technique context, not as evidence of current activity.

Likely telemetry

  • Windows Registry auditing or endpoint telemetry for HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ Authentication Packages changes
  • Process and module-load telemetry showing DLLs loaded by LSASS during boot or authentication initialization
  • Endpoint detection telemetry from Windows systems covering privileged process activity
  • Change-management or configuration-management records for approved LSA authentication package settings
  • Host inventory and hardening state for Windows systems, including whether additional LSA protection such as RunAsPPL is enabled

Detection direction

  • Validate alerting for new, unexpected, or modified values under the LSA Authentication Packages registry configuration.
  • Correlate registry modification events with subsequent LSASS DLL loads to reduce noise and support incident triage.
  • Baseline expected authentication packages on critical Windows systems so legitimate operating system or administrator-driven changes are distinguishable from suspicious persistence.
  • Tune carefully because authentication packages are a legitimate Windows mechanism; detection should emphasize unauthorized change, unusual binaries, and mismatch with approved configuration.
  • Confirm collection starts early enough and is retained long enough to support boot-time persistence investigations.

Mitigation priorities

  • Establish and document approved LSA authentication package configuration for managed Windows systems.
  • Restrict and monitor administrative paths that can modify HKLM LSA configuration.
  • Apply privileged process integrity controls where appropriate, including Windows RunAsPPL as referenced by the related mitigation.
  • Include LSA configuration checks in Windows hardening, compliance validation, and post-incident persistence reviews.
  • Use configuration management to detect drift and support rapid restoration to known-good authentication settings.
Analyst notes and limits

This object is a Windows-only ATT&CK sub-technique under T1547 Boot or Logon Autostart Execution. MITRE provides no official detection text for the technique, so detection guidance is derived from the official behavior description and the supplied DET0207 relationship. The revoked T1131 relationship indicates this content supersedes the older Authentication Package technique. External references include Microsoft authentication package documentation and Microsoft guidance for additional LSA protection.

The supplied ATT&CK fields do not provide procedure details beyond the Flame software relationship, do not prove current exploitation, and do not define a complete detection analytic. Local baselines, endpoint telemetry quality, registry auditing configuration, and approved authentication package usage are required to determine real coverage and risk.

Official MITRE ATT&CK definition

Authentication Package

Adversaries may abuse authentication packages to execute DLLs when the system boots. Windows authentication package DLLs are loaded by the Local Security Authority (LSA) process at system start. They provide support for multiple logon processes and multiple security protocols to the operating system.[1]

Adversaries can use the autostart mechanism provided by LSA authentication packages for persistence by placing a reference to a binary in the Windows Registry location HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ with the key value of "Authentication Packages"=<target binary>. The binary will then be executed by the system when the authentication packages are loaded.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1131 Authentication Package Authentication Package revoked by this object.
Enterprise T1547 Boot or Logon Autostart Execution This object subtechnique of Boot or Logon Autostart Execution.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0143: Flame

Flame is a sophisticated toolkit that has been used to collect information since at least 2010, largely targeting Middle East countries. [1]

Windows
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1025: Privileged Process Integrity Enterprise detects · Detection Strategy DET0207: Detect LSA Authentication Package Persistence via Registry and LSASS DLL Load Enterprise uses · Malware S0143: Flame Enterprise revoked by · Technique T1131: Authentication Package Enterprise subtechnique of · Technique T1547: Boot or Logon Autostart Execution Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1025: Privileged Process Integrity

Privileged Process Integrity focuses on defending highly privileged processes (e.g., system services, antivirus, or authentication processes) from tampering, injection, or compromise by adversaries. These processes often interact with critical components, making them prime targets for techniques like code injection, privilege escalation, and process manipulation. This mitigation can be implemented through the following measures:

Protected Process Mechanisms:

- Enable RunAsPPL on Windows systems to protect LSASS and other critical processes. - Use registry modifications to enforce protected process settings: `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL`

Anti-Injection and Memory Protection:

- Enable Control Flow Guard (CFG), DEP, and ASLR to protect against process memory tampering. - Deploy endpoint protection tools that actively block process injection attempts.

Code Signing Validation:

- Implement policies for Windows Defender Application Control (WDAC) or AppLocker to enforce execution of signed binaries. - Ensure critical processes are signed with valid certificates.

Access Controls:

- Use DACLs and MIC to limit which users and processes can interact with privileged processes. - Disable unnecessary debugging capabilities for high-privileged processes.

Kernel-Level Protections:

- Ensure Kernel Patch Protection (PatchGuard) is enabled on Windows systems. - Leverage SELinux or AppArmor on Linux to enforce kernel-level security policies.

*Tools for Implementation*

Protected Process Light (PPL):

- RunAsPPL (Windows) - Windows Defender Credential Guard

Code Integrity and Signing:

- Windows Defender Application Control (WDAC) - AppLocker - SELinux/AppArmor (Linux)

Memory Protection:

- Control Flow Guard (CFG), Data Execution Prevention (DEP), ASLR

Process Isolation/Sandboxing:

- Firejail (Linux Sandbox) - Windows Sandbox - QEMU/KVM-based isolation

Kernel Protection:

- PatchGuard (Windows Kernel Patch Protection) - SELinux (Mandatory Access Control for Linux) - AppArmor

Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
7d0c90ce0443bda8...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 7d0c90ce0443…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    MSDN Authentication Packages

    Microsoft. (n.d.). Authentication Packages. Retrieved March 1, 2017.

    Open source URL
  2. [2]
    Graeber 2014

    Graeber, M. (2014, October). Analysis of Malicious Security Support Provider DLLs. Retrieved March 1, 2017.

    Open source URL
  3. [3]
    Microsoft Configure LSA

    Microsoft. (2013, July 31). Configuring Additional LSA Protection. Retrieved June 24, 2015.

    Open source URL
  4. [4]
    mitre-attack T1547.002
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use