Install Additional Authentication Packages
Last updated on:
In this page
Rule name | Rule type | Log sources | MITRE ATT&CK tags | Severity |
|---|---|---|---|---|
Install Additional Authentication Packages | Standard | Windows, Sysmon | Persistence: Modify authentication process (T1556) | Critical |
About the rule
Rule Type
Standard
Rule Description
Detects the installation of additional authentication packages in the Local Security Authority (LSA) registry keys. Adversaries may add malicious packages to the LSA to steal credentials or maintain persistence, as these packages are loaded during system boot.
Why this rule?
Adding malicious authentication packages allows attackers to intercept credentials during user logon, enabling credential theft at scale. This persistence technique runs with SYSTEM privileges and can capture plaintext passwords. Detection is vital as it indicates an advanced attack targeting your authentication infrastructure.
Severity
Trouble
Rule journey
Attack chain scenario
Execution → Persistence → Registry Modification (Lsa Authentication Packages) → Loading of malicious DLL into LSASS → Credential Harvesting.
Impact
Compromise of user credentials and establishment of high-level persistence that executes every time the system starts.
Rule Requirement
Prerequisites
Enable Registry auditing for the path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa.
Criteria
Action1:
actionname = "Registry Event" AND (OBJECTNAME contains "Control\Lsa" AND (OBJECTNAME contains "Authentication Packages" OR OBJECTVALUENAME contains "Authentication Packages"))
select Action1.HOSTNAME,Action1.MESSAGE,Action1.PROCESSNAME,Action1.OBJECTNAME,Action1.OBJECTVALUENAME,Action1.ACCESSES,Action1.USERNAME,Action1.DOMAIN,Action1.PREVVAL,Action1.CHANGES,Action1.INFORMATION
Detection
Execution Mode
realtime
Log Sources
Windows
MITRE ATT&CK
Persistence: Modify authentication process (T1556)
Future actions
Known False Positives
Installation of legitimate third-party authentication providers (e.g., biometrics, smart cards, or specialized VPN clients).
Next Steps
- Identification: Identify the specific package name added to the "Authentication Packages" value.
- Analysis: Verify the associated DLL on disk for valid digital signatures.
- Response: Revert the registry value to the default list (msv1_0) and remove the unauthorized package.
Mitigation
ID | Mitigation | Description |
|---|---|---|
Review authentication logs to ensure that mechanisms such as enforcement of MFA are functioning as intended. Periodically review the hybrid identity solution in use for any discrepancies. For example, review all Pass Through Authentication (PTA) agents in the Azure Management Portal to identify any unwanted or unapproved ones.[6] If ADFS is in use, review DLLs and executable files in the AD FS and Global Assembly Cache directories to ensure that they are signed by Microsoft. Note that in some cases binaries may be catalog-signed, which may cause the file to appear unsigned when viewing file properties.[7] Periodically review for new and unknown network provider DLLs within the Registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ | ||
Integrating multi-factor authentication (MFA) as part of organizational policy can greatly reduce the risk of an adversary gaining control of valid credentials that may be used for additional tactics such as initial access, lateral movement, and collecting information. MFA can also be used to restrict access to cloud resources and APIs. | ||
Ensure only valid password filters are registered. Filter DLLs must be present in Windows installation directory (C:\Windows\System32\ by default) of a domain controller and/or local computer with a corresponding entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages. Starting in Windows 11 22H2, the EnableMPRNotifications policy can be disabled through Group Policy or through a configuration service provider to prevent Winlogon from sending credentials to network providers.[8] | ||
Ensure that AllowReversiblePasswordEncryption property is set to disabled unless there are application requirements.[9] | ||
Audit domain and local accounts as well as their permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. [10][11] These audits should also include if default accounts have been enabled, or if new local accounts are created that have not be authorized. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers. [12] Limit access to the root account and prevent users from modifying protected components through proper privilege separation (ex SELinux, grsecurity, AppArmor, etc.) and limiting Privilege Escalation opportunities. Limit on-premises accounts with access to the hybrid identity solution in place. For example, limit Azure AD Global Administrator accounts to only those required, and ensure that these are dedicated cloud-only accounts rather than hybrid ones.[7] | ||
Enabled features, such as Protected Process Light (PPL), for LSA.[13] | ||
Restrict write access to the /Library/Security/SecurityAgentPlugins directory. | ||
Restrict Registry permissions to disallow the modification of sensitive Registry keys such as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order. | ||
Ensure that proper policies are implemented to dictate the the secure enrollment and deactivation of authentication mechanisms, such as MFA, for user accounts. |
