Detect Authentication Package in Google Chronicle
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. 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.
MITRE ATT&CK
- Tactic
- Persistence Privilege Escalation
- Technique
- T1547 Boot or Logon Autostart Execution
- Sub-technique
- T1547.002 Authentication Package
- Canonical reference
- https://attack.mitre.org/techniques/T1547/002/
YARA-L Detection Query
rule t1547_002_authentication_package_persistence {
meta:
author = "Argus Detection Engineering"
description = "Detects modification of HKLM\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Authentication Packages registry value, indicating potential LSA authentication package persistence (T1547.002)"
mitre_attack_tactic = "Persistence"
mitre_attack_technique = "T1547.002"
severity = "HIGH"
confidence = "HIGH"
events:
$e.metadata.event_type = "REGISTRY_MODIFICATION"
$e.target.registry.registry_key = /(?i)\\Control\\Lsa/
$e.target.registry.registry_value_name = /(?i)Authentication Packages/
$host = $e.principal.hostname
condition:
$e
}Chronicle YARA-L 2.0 rule that detects writes to the LSA Authentication Packages registry value using UDM REGISTRY_MODIFICATION events, identifying potential adversary persistence via LSA DLL loading at boot.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate smart card or biometric authentication software registering custom LSA packages during enterprise deployment
- Microsoft-signed authentication extension packages being installed or updated via Windows Update or enterprise management tools
- Identity and access management (IAM) solutions that extend LSA functionality as a supported integration method
Other platforms for T1547.002
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Add Authentication Package via Registry
Expected signal: Sysmon Event ID 13: RegistryValueSet on HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages. MDE DeviceRegistryEvents with the modified multi-string value.
- Test 2Query Current Authentication Packages
Expected signal: Sysmon Event ID 1: Process creation for reg.exe with command line arguments querying the Lsa key. No registry modification events generated.
- Test 3Add Authentication Package via PowerShell
Expected signal: Sysmon Event ID 13: RegistryValueSet with Image=powershell.exe. PowerShell ScriptBlock Log Event ID 4104 with the full script content. Sysmon Event ID 1 for the PowerShell process creation.
References (5)
- https://attack.mitre.org/techniques/T1547/002/
- https://msdn.microsoft.com/library/windows/desktop/aa374733.aspx
- https://technet.microsoft.com/en-us/library/dn408187.aspx
- http://docplayer.net/20839173-Analysis-of-malicious-security-support-provider-dlls.html
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1547.002/T1547.002.md
Unlock Pro Content
Get the full detection package for T1547.002 including response playbook, investigation guide, and atomic red team tests.