Detect Modify Authentication Process in Sumo Logic CSE

Triage

1. Identify the specific modification type from the DetectionType field — Password Filter DLL registration and SSP injection are highest priority as they enable passive credential interception from every authentication event on the system
2. Extract the DLL name from RegistryValueData or the image load path and check if it exists on disk: Get-Item 'C:\Windows\System32\<dll_name>.dll' | Select-Object Name, CreationTime, LastWriteTime, @{n='Hash';e={(Get-FileHash $_.FullName).Hash}}
3. Verify the DLL's digital signature: Get-AuthenticodeSignature 'C:\Windows\System32\<dll_name>.dll' — an unsigned or invalidly signed DLL in this location is a critical indicator of malicious modification
4. Check who made the registry change and from what process — legitimate MFA software installations should come from msiexec.exe with a corresponding software installation event; any change from cmd.exe, powershell.exe, or reg.exe is highly suspicious
5. Determine if the affected system is a domain controller — run: (Get-ADDomainController -Identity $env:COMPUTERNAME -ErrorAction SilentlyContinue) — any authentication modification on a DC affects the entire domain and should trigger immediate escalation
6. Check the DLL's first appearance on disk versus the registry modification timestamp: if the DLL was created seconds before the registry change, this strongly suggests deliberate installation rather than a legitimate software update
7. Query for the DLL being loaded by lsass.exe since the registry change: DeviceImageLoadEvents | where InitiatingProcessFileName =~ 'lsass.exe' and FileName =~ '<dll_name>.dll' — if loaded, credential capture may already be in progress

Containment

1. If password filter DLL confirmed malicious: immediately remove the DLL name from HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages using: reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "Notification Packages" /t REG_MULTI_SZ /d "rassfm\0scecli" /f — then reboot to unload the DLL from lsass.exe
2. Force an immediate password reset for ALL privileged accounts on the affected system, especially domain admins — if the filter was active, their passwords are compromised; reset using: Set-ADAccountPassword -Identity <username> -Reset -NewPassword (Read-Host -AsSecureString)
3. Isolate the affected system from the network using EDR isolation or emergency ACL change while preserving forensic evidence — this prevents exfiltration of any already-captured credentials
4. If skeleton key attack suspected (any domain account accepts a single master password): initiate emergency krbtgt account double-reset to invalidate all existing Kerberos tickets: Reset-ADAccountPassword -Identity krbtgt, wait 10+ hours for replication, then reset again
5. Enable LSA Protection (RunAsPPL) if not already active to prevent future DLL injection into lsass.exe: reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1 /f — note: requires DLLs to be signed by Microsoft
6. Delete the malicious DLL from disk after capturing a forensic copy: Copy-Item 'C:\Windows\System32\<dll_name>.dll' -Destination '\\<forensics_share>\evidence\' ; Remove-Item 'C:\Windows\System32\<dll_name>.dll'

Evidence Collection

1. Export the affected LSA registry keys before any remediation: reg export 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' C:\temp\lsa_export.reg
2. Capture the malicious DLL for malware analysis — compute SHA256 hash and submit to VirusTotal: (Get-FileHash 'C:\Windows\System32\<dll_name>.dll' -Algorithm SHA256).Hash
3. Collect Windows Security Event IDs 4610 (authentication package loaded by LSA) and 4614 (notification package loaded by SAM) from the system boot prior to detection — these confirm when the DLL was first loaded
4. Collect Sysmon Event ID 7 (Image Load) logs filtered to InitiatingProcessName=lsass.exe for the 30 days prior to detection to establish when the unauthorized DLL first appeared in lsass.exe's module list
5. Collect Sysmon Event ID 13 (Registry Value Set) logs for the full LSA key path to trace the exact time and process that made the modification
6. Export LSASS memory for forensic analysis using a legitimate method: procdump64.exe -ma lsass.exe lsass.dmp — submit to forensics team for analysis of in-memory credential state
7. Collect MFT (Master File Table) entry for the malicious DLL to recover original creation timestamp and any file name changes: fsutil usn readjournal C: | findstr /i '<dll_name>'
8. If PAM modification suspected on Linux: diff /etc/pam.d/ against known-good backup, collect /var/log/auth.log and /var/log/secure for authentication events showing unexpected successful logins

Escalation Criteria

• !Modification detected on a domain controller — any DLL registered in the LSA authentication chain on a DC affects every domain authentication and requires immediate IR engagement
• !Malicious DLL has already been loaded by lsass.exe and survived a reboot (confirmed by Security Event ID 4614 at startup) — credentials may have been exfiltrating since the last system boot
• !DLL is unsigned or signed by an unknown/expired certificate — legitimate Windows authentication DLLs are always Microsoft-signed
• !Evidence of skeleton key attack: multiple domain accounts authenticating successfully with a single common password across different user sessions, or any domain account authenticating without a valid Kerberos ticket
• !Password filter DLL detected alongside outbound network connections from lsass.exe or a companion process — indicates active exfiltration of harvested plaintext passwords
• !Same DLL name registered across multiple systems simultaneously — indicates automated lateral movement or a domain GPO being abused to deploy the malicious package at scale