LSA Packages

Windows Security Support Provider (SSP) DLLs are loaded into the Local Security Authority (LSA) process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs. An adversary may modify the Registry keys where this configuration is stored to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called. You can learn more about the LSA SSP adversary tactic at https://attack.mitre.org/wiki/Technique/T1101 and the related LSA Authentication Package and Notification Packages tactics at https://attack.mitre.org/wiki/Technique/T1131.

Veramine's detection engine highlights additions or modifications to the following registry keys related to these adversary tactics:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages

Here is an example detection of this type:

Each SSP is loaded as a DLL by lsass.exe. The Veramine detection engine also alerts on untrusted binaries being loaded by lsass.exe, whether via the Security Package mechanism or otherwise. Here is an example of lsass.exe loading a new DLL for the first time for this particular customer:

The mimilib.dll in this particular case was loaded after being added to the list of Security Packages. Clicking the "Binary Details" link embedded in the detection reveals that the binary is unsigned, flagged as malicious by 37 different anti-malware products, and loaded by only a single host:

The two buttons on this page allow for easy access to download a copy of the binary for further analysis or to take action such as blocking this binary from being loaded by any process on any machine across the network.