Modify Authentication Process
Adversaries may modify authentication mechanisms and processes to access user credentials or enable otherwise unwarranted access to accounts. The authentication process is handled by mechanisms such as the Local Security Authentication Server (LSASS) process and the Security Accounts Manager (SAM) on Windows, pluggable authentication modules (PAM) on Unix-based systems, and authorization plugins on macOS systems. By modifying an authentication process, an adversary may authenticate to a service or system without using valid accounts, or may passively harvest credentials as users authenticate. Techniques include registering malicious password filter DLLs that receive plaintext passwords during every password change, injecting security support providers (SSPs) into LSASS to intercept credentials, installing skeleton keys to accept any password for domain accounts, modifying PAM stack configuration files to permit unauthorized access, and replacing legitimate authentication binaries with trojanized versions that exfiltrate credentials.
What is T1556 Modify Authentication Process?
Modify Authentication Process (T1556) maps to the Credential Access and Defense Evasion and Persistence tactics — the adversary is trying to steal account names and passwords in MITRE ATT&CK.
This page provides production-ready detection logic for Modify Authentication Process, covering the data sources and telemetry it touches: Registry: Registry Key Modification, Module: Module Load, Process: Process Creation, Microsoft Defender for Endpoint. The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Technique
- T1556 Modify Authentication Process
- Canonical reference
- https://attack.mitre.org/techniques/T1556/
// T1556: Modify Authentication Process
// Detects modifications to Windows LSA authentication registry keys used to register
// password filter DLLs, SSPs, auth packages, network providers, and GINA DLLs.
// These are the primary persistence paths for credential interception malware
// such as skeleton key (Secureworks), Ebury, Kessel, and SILENTTRINITY.
let LsaRegistryPaths = dynamic([
"CurrentControlSet\\Control\\Lsa\\Notification Packages",
"CurrentControlSet\\Control\\Lsa\\Security Packages",
"CurrentControlSet\\Control\\Lsa\\Authentication Packages",
"CurrentControlSet\\Control\\Lsa\\OSConfig\\Security Packages",
"CurrentControlSet\\Control\\NetworkProvider\\Order",
"CurrentVersion\\Winlogon\\GinaDLL",
"CurrentVersion\\Authentication\\Credential Providers"
]);
let TrustedModifiers = dynamic([
"TrustedInstaller.exe", "MsMpEng.exe", "msiexec.exe",
"wuauclt.exe", "WindowsUpdateAgent.exe", "svchost.exe"
]);
let LsaLoadEvents = DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName =~ "lsass.exe"
| where not(FileName in~ (
"ntdll.dll", "kernel32.dll", "kernelbase.dll", "msvcrt.dll",
"kerberos.dll", "msv1_0.dll", "wdigest.dll", "tspkg.dll",
"pku2u.dll", "cloudap.dll", "schannel.dll", "cryptdll.dll",
"samsrv.dll", "lsasrv.dll", "netlogon.dll", "ntlmshared.dll"
))
| extend DetectionSource = "LsassUnexpectedDllLoad"
| project Timestamp, DeviceName, AccountName = InitiatingProcessAccountName,
DetectionType = "Unexpected DLL Load by LSASS",
RegistryKey = "", RegistryValueName = "", RegistryValueData = "",
DllName = FileName, DllPath = FolderPath, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine;
let RegistryMods = DeviceRegistryEvents
| where Timestamp > ago(24h)
| where RegistryKey has_any (LsaRegistryPaths)
| where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
| where not(InitiatingProcessFileName has_any (TrustedModifiers))
| extend DetectionType = case(
RegistryKey has "Notification Packages", "Password Filter DLL Registration",
RegistryKey has "Security Packages" and not (RegistryKey has "OSConfig"), "Security Support Provider (SSP) Registration",
RegistryKey has "Authentication Packages", "Authentication Package Registration",
RegistryKey has "NetworkProvider", "Network Provider DLL Registration",
RegistryKey has "GinaDLL", "GINA DLL Modification",
RegistryKey has "Credential Providers", "Credential Provider Registration",
"LSA Authentication Configuration Modification"
)
| project Timestamp, DeviceName, AccountName, DetectionType,
RegistryKey, RegistryValueName, RegistryValueData,
DllName = "", DllPath = "", SHA256 = "",
InitiatingProcessFileName, InitiatingProcessCommandLine;
RegistryMods
| union LsaLoadEvents
| extend IsDomainController = DeviceName has_any ("DC", "PDC", "BDC", "RODC")
| sort by Timestamp desc Detects modifications to Windows LSA authentication configuration by monitoring two key signals: (1) registry writes to authentication-critical keys including LSA Notification Packages (password filters), Security Packages (SSPs), Authentication Packages, Network Provider Order, and GINA DLL paths, excluding known-good Windows system processes; and (2) unexpected DLL loads by the lsass.exe process from non-standard DLL names not part of the default Windows authentication package list. Together these cover the primary persistence mechanisms used by skeleton key malware, Ebury, Kessel, and SILENTTRINITY to intercept credentials. Domain controller detections are flagged separately given their elevated impact.
Data Sources
Required Tables
False Positives
- Legitimate MFA solutions (Duo Security, Okta Verify, RSA SecurID) that install custom credential provider DLLs during initial setup — filter by InitiatingProcessFileName = msiexec.exe and correlate with change management tickets
- Enterprise privileged access management tools (CyberArk, BeyondTrust, Centrify) that register authentication packages — build an allowlist of their specific DLL names
- Windows Defender Credential Guard enabling LSA protection, which modifies LSA configuration keys — these changes come from svchost.exe or TrustedInstaller
- Third-party VPN clients and smart card middleware that install network provider DLLs or credential providers as part of software installation
- Password manager enterprise editions (LastPass Enterprise, 1Password Business) installing Windows credential provider extensions
Sigma rule & cross-platform mapping
The detection logic for Modify Authentication Process (T1556) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1556
References (8)
- https://attack.mitre.org/techniques/T1556/
- https://clymb3r.wordpress.com/2013/09/15/intercepting-password-changes-with-function-hooking/
- https://xorrior.com/persistent-credential-theft/
- https://www.secureworks.com/research/skeleton-key-malware-analysis
- https://adsecurity.org/?p=2053
- https://technet.microsoft.com/en-us/library/dn487457.aspx
- https://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/
- https://github.com/SigmaHQ/sigma/blob/master/rules/windows/registry/registry_set/registry_set_lsa_packages.yml
Testing Methodology
Validate this detection against 4 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 1Register Benign Password Filter DLL in LSA Notification Packages
Expected signal: Sysmon Event ID 13: TargetObject=HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages, Details contains 'df00tech-test-filter', Image=powershell.exe. Windows Security Event ID 4657 if SACL is configured on the LSA key. DeviceRegistryEvents in MDE: RegistryKey contains 'Notification Packages', RegistryValueData contains new DLL name, InitiatingProcessFileName=powershell.exe.
- Test 2Register Fake Security Support Provider (SSP) in LSA Security Packages
Expected signal: Sysmon Event ID 13: TargetObject=HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages, Details appended with 'df00tech-test-ssp'. DeviceRegistryEvents: RegistryKey contains 'Security Packages', ActionType=RegistryValueSet. If system reboots, Security Event ID 4610 will fire listing the (missing) SSP DLL name — LSASS will generate an error in System event log.
- Test 3Modify PAM Configuration to Permit Authentication Bypass on Linux
Expected signal: Linux auditd: syscall=openat/write on path=/etc/pam.d/sshd with auid=<attacker_uid> if auditd watches are configured (-w /etc/pam.d/ -p wa -k pam_modification). Syslog: process writing to /etc/pam.d/sshd. File integrity monitoring (AIDE, Tripwire) will alert on hash change to /etc/pam.d/sshd. DeviceFileEvents (for Linux onboarded to MDE): FileModified on /etc/pam.d/sshd.
- Test 4Register Malicious Network Provider DLL via Registry
Expected signal: Sysmon Event ID 13: TargetObject=HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder, Image=powershell.exe, Details contains appended provider name. DeviceRegistryEvents: RegistryKey contains 'NetworkProvider\Order', RegistryValueName='ProviderOrder', ActionType=RegistryValueSet.
Response Playbook
Triage
- 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
- 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}}
- 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
- 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
- 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
- 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
- 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
- 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
- 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)
- 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
- 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
- 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
- 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
- Export the affected LSA registry keys before any remediation: reg export 'HKLM\SYSTEM\CurrentControlSet\Control\Lsa' C:\temp\lsa_export.reg
- 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
- 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
- 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
- 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
- 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
- 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>'
- 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
Investigation Guide
Forensic Artifacts
- >
Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages — multi-string value listing all registered password filter DLLs; default values are 'rassfm' and 'scecli' - >
Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages — lists loaded SSPs; defaults include kerberos, msv1_0, schannel, wdigest, tspkg, pku2u - >
Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages — lists auth packages loaded at startup; default is 'msv1_0' - >
Registry: HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder — comma-separated list of network providers; unexpected entries indicate T1556.008 - >
Event Log: Security — Event ID 4610 (Authentication Package Loaded by LSA) and 4614 (Notification Package Loaded by SAM) — fire at system startup with each registered package - >
Event Log: Security — Event ID 4657 (Registry Value Modified) — requires 'Audit Registry' policy enabled with SACL on LSA keys - >
File System: C:\Windows\System32\<dll_name>.dll — malicious password filter or SSP DLL; check creation time vs legitimate DLLs, verify Authenticode signature - >
File System: C:\Windows\System32\mimilsa.log or similar — Mimikatz SSP creates this output file when configured to log credentials - >
Linux: /etc/pam.d/ directory contents — check for unauthorized modules, especially 'sufficient' entries that bypass authentication or 'requisite' entries that could cause crashes - >
Linux: /var/log/auth.log or /var/log/secure — successful root logins without corresponding sudo or SSH key entries indicate backdoored PAM stack
Tuning Guidance
The highest-value tuning investment for this detection is building an allowlist of legitimate software that modifies LSA registry keys in your environment. Deploy the detection for one week in alert-only mode and collect all InitiatingProcessFileName and RegistryValueData values that trigger. For each unique DLL name registered, verify: (1) it was installed by a known software package, (2) the DLL has a valid Microsoft or known-vendor Authenticode signature, (3) the installation correlated with a change management ticket. Add verified combinations to an allowlist as InitiatingProcessFileName + RegistryValueData pairs — never allowlist a RegistryKey path alone. For the lsass.exe image load detection, build your baseline ExpectedLsassDlls list from 30 days of DeviceImageLoadEvents filtered to InitiatingProcessFileName = 'lsass.exe' in your environment before enabling alerting — enterprise security tools may legitimately load additional DLLs into lsass. Enable Windows Security Audit Policy for 'Audit Audit Policy Change' (Category: Policy Change) and configure a SACL on HKLM\SYSTEM\CurrentControlSet\Control\Lsa with auditing for 'Set Value' by Everyone — this provides Event ID 4657 as a second detection source independent of Sysmon. For Linux PAM detections (T1556.003), implement file integrity monitoring on /etc/pam.d/ using auditd watch rules: -w /etc/pam.d/ -p wa -k pam_modification.
Hunting Queries
Hunt for DLLs loaded by lsass.exe that are not in the expected Windows authentication module list. This catches password filter DLLs, malicious SSPs, and skeleton key components that have been injected into LSASS and have survived reboots. Run over 30 days to surface persistence that may have existed for extended periods before detection was enabled.
// Hunt for DLLs loaded by lsass.exe that are NOT in the expected Windows authentication DLL list
// Run over 30 days to catch persistence that survived multiple reboots
let ExpectedLsassDlls = dynamic([
"ntdll.dll", "kernel32.dll", "kernelbase.dll", "msvcrt.dll", "sechost.dll",
"rpcrt4.dll", "advapi32.dll", "lsasrv.dll", "samsrv.dll", "kerberos.dll",
"msv1_0.dll", "wdigest.dll", "tspkg.dll", "pku2u.dll", "cloudap.dll",
"schannel.dll", "cryptdll.dll", "netlogon.dll", "ntlmshared.dll",
"rassfm.dll", "scecli.dll"
]);
DeviceImageLoadEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "lsass.exe"
| where not(FileName in~ (ExpectedLsassDlls))
| where not(FolderPath startswith @"C:\Windows\System32\drivers\")
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), LoadCount=count(),
Devices=make_set(DeviceName), SHA256Values=make_set(SHA256) by FileName, FolderPath
| order by FirstSeen desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=7 Image="*\\lsass.exe"
NOT (ImageLoaded="*\\ntdll.dll" OR ImageLoaded="*\\kernel32.dll" OR ImageLoaded="*\\kerberos.dll"
OR ImageLoaded="*\\msv1_0.dll" OR ImageLoaded="*\\wdigest.dll" OR ImageLoaded="*\\tspkg.dll"
OR ImageLoaded="*\\lsasrv.dll" OR ImageLoaded="*\\samsrv.dll" OR ImageLoaded="*\\netlogon.dll"
OR ImageLoaded="*\\schannel.dll" OR ImageLoaded="*\\cloudap.dll" OR ImageLoaded="*\\pku2u.dll"
OR ImageLoaded="*\\rassfm.dll" OR ImageLoaded="*\\scecli.dll")
| stats count as LoadCount, dc(host) as DeviceCount, earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(host) as Devices by ImageLoaded, Hashes
| sort - FirstSeen Hunt across the entire environment for historical LSA registry modifications over 90 days to surface authentication backdoors that may have been installed long before detection tuning was applied. High change counts on a single device, or modifications appearing on multiple devices simultaneously, suggest automated deployment of credential harvesting tools.
// Hunt for registry modifications to LSA auth keys across the environment
// over the last 90 days to find stale authentication backdoors
DeviceRegistryEvents
| where Timestamp > ago(90d)
| where RegistryKey has_any (
"Control\\Lsa\\Notification Packages",
"Control\\Lsa\\Security Packages",
"Control\\Lsa\\Authentication Packages"
)
| where ActionType in ("RegistryValueSet", "RegistryKeyCreated")
| extend ModifiedBy = strcat(DeviceName, " \\ ", AccountName, " via ", InitiatingProcessFileName)
| summarize ChangeCount=count(), FirstChange=min(Timestamp), LastChange=max(Timestamp),
UniqueValues=make_set(RegistryValueData), ModifiedBy=make_set(ModifiedBy)
by RegistryKey, DeviceName
| where ChangeCount > 0
| order by LastChange desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=13 earliest=-90d
(TargetObject="*\\Control\\Lsa\\Notification Packages*"
OR TargetObject="*\\Control\\Lsa\\Security Packages*"
OR TargetObject="*\\Control\\Lsa\\Authentication Packages*")
| stats count as ChangeCount, earliest(_time) as FirstChange, latest(_time) as LastChange, values(Details) as RegisteredValues, values(Image) as ModifyingProcesses by host, TargetObject
| sort - LastChange Hunt for DLL files created or modified in System32 by non-Windows-Update processes that match DLL names registered in LSA authentication keys, or that appear on very few devices (suggesting targeted implantation). Password filter and SSP DLLs must exist in System32 to be loaded by lsass.exe — this cross-reference of file creation and registry registration events surfaces staged authentication backdoors before or after reboot.
// Hunt for newly created DLL files in System32 that match known password filter and SSP naming conventions
// Cross-references file creation events against LSA registry values to find staged-but-not-yet-loaded filters
let RegisteredPackages = DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has_any ("Notification Packages", "Security Packages", "Authentication Packages")
| where ActionType == "RegistryValueSet"
| extend PackageNames = split(RegistryValueData, "\0")
| mv-expand PackageName = PackageNames to typeof(string)
| where isnotempty(PackageName)
| distinct PackageName, DeviceName;
DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType in ("FileCreated", "FileModified")
| where FolderPath startswith @"C:\Windows\System32\"
| where FileName endswith ".dll"
| where not(InitiatingProcessFileName in~ ("TrustedInstaller.exe", "msiexec.exe", "wuauclt.exe"))
| join kind=inner RegisteredPackages
on $left.FileName == strcat($right.PackageName, ".dll"), $left.DeviceName == $right.DeviceName
| project Timestamp, DeviceName, FileName, FolderPath, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11 earliest=-30d
TargetFilename="C:\\Windows\\System32\\*.dll"
NOT (Image="*\\TrustedInstaller.exe" OR Image="*\\msiexec.exe" OR Image="*\\wuauclt.exe" OR Image="*\\MsMpEng.exe")
| stats count as FileEvents, dc(host) as Devices, earliest(_time) as FirstSeen, values(Image) as CreatedBy, values(Hashes) as Hashes by TargetFilename
| where Devices < 3
| sort - FirstSeen Atomic Red Team Tests
Modifies HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages to append a test DLL name. Password filter DLLs registered here receive the plaintext password in the PasswordFilter() callback during every successful password change on the system. This simulates the Ebury and Kessel malware technique of trojanizing ssh-add and registering credential interceptors. The DLL name added is 'df00tech-test-filter' — no actual DLL is created, so LSASS will log an error on reboot but the registry modification is detectable.
Command
powershell -Command "$current = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Notification Packages').'Notification Packages'; $new = $current + 'df00tech-test-filter'; Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Notification Packages' -Value $new -Type MultiString" Cleanup
powershell -Command "$current = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Notification Packages').'Notification Packages'; $cleaned = $current | Where-Object { $_ -ne 'df00tech-test-filter' }; Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Notification Packages' -Value $cleaned -Type MultiString" Expected Telemetry
Sysmon Event ID 13: TargetObject=HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages, Details contains 'df00tech-test-filter', Image=powershell.exe. Windows Security Event ID 4657 if SACL is configured on the LSA key. DeviceRegistryEvents in MDE: RegistryKey contains 'Notification Packages', RegistryValueData contains new DLL name, InitiatingProcessFileName=powershell.exe.
Expected Detection
KQL: RegistryMods branch fires with DetectionType='Password Filter DLL Registration', InitiatingProcessFileName='powershell.exe'. SPL: IsAuthRegistryMod=1, DetectionType='Password Filter DLL Registration', Severity='Critical'. Alert should fire within seconds of the registry write.
Appends a test entry to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages, which causes Windows to load the named DLL into lsass.exe at the next system boot. Malicious SSPs (as used by the Mimikatz mimilsa module and documented in the Secureworks skeleton key analysis) can log all authentication credentials passing through LSASS. This test modifies only the registry value — the DLL itself is not created — to safely trigger the detection without affecting system stability.
Command
powershell -Command "$current = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Security Packages').'Security Packages'; $new = $current + 'df00tech-test-ssp'; Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Security Packages' -Value $new -Type MultiString" Cleanup
powershell -Command "$current = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Security Packages').'Security Packages'; $cleaned = $current | Where-Object { $_ -ne 'df00tech-test-ssp' }; Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'Security Packages' -Value $cleaned -Type MultiString" Expected Telemetry
Sysmon Event ID 13: TargetObject=HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages, Details appended with 'df00tech-test-ssp'. DeviceRegistryEvents: RegistryKey contains 'Security Packages', ActionType=RegistryValueSet. If system reboots, Security Event ID 4610 will fire listing the (missing) SSP DLL name — LSASS will generate an error in System event log.
Expected Detection
KQL: RegistryMods branch fires with DetectionType='Security Support Provider (SSP) Registration'. SPL: DetectionType='SSP Registration', Severity='Critical'. This should generate a Critical severity alert as SSP injection provides persistent in-process credential access.
Appends 'auth sufficient pam_permit.so' to /etc/pam.d/sshd on Linux. The 'sufficient' control flag combined with pam_permit.so (which always returns success) means any user can authenticate without a password if this line is encountered before the standard pam_unix.so check. This is equivalent to a PAM-level authentication backdoor and simulates the technique used by Ebury malware on compromised Linux SSH servers. The pam_permit.so module is part of the default Linux-PAM package and is available on all major distributions.
Command
echo 'auth sufficient pam_permit.so' >> /etc/pam.d/sshd && echo '[+] PAM backdoor appended to /etc/pam.d/sshd' && grep -n 'pam_permit' /etc/pam.d/sshd Cleanup
sed -i '/pam_permit.so/d' /etc/pam.d/sshd && echo '[+] PAM backdoor removed from /etc/pam.d/sshd' Expected Telemetry
Linux auditd: syscall=openat/write on path=/etc/pam.d/sshd with auid=<attacker_uid> if auditd watches are configured (-w /etc/pam.d/ -p wa -k pam_modification). Syslog: process writing to /etc/pam.d/sshd. File integrity monitoring (AIDE, Tripwire) will alert on hash change to /etc/pam.d/sshd. DeviceFileEvents (for Linux onboarded to MDE): FileModified on /etc/pam.d/sshd.
Expected Detection
Linux SIEM: auditd key=pam_modification, syscall write on /etc/pam.d/sshd. File integrity monitoring alert on /etc/pam.d/ checksum mismatch. The auditd SPL query: index=linux_secure sourcetype=linux_audit key=pam_modification | table _time, host, auid, uid, exe, name.
Modifies HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder to append a test network provider name. Network provider DLLs (T1556.008) receive network authentication credentials in plaintext when users connect to network resources. This technique was used to harvest SMB/RDP credentials. The test appends 'df00tech-test-np' to the ProviderOrder string — no actual DLL is created. The NPAddConnection3() export in the malicious DLL would normally capture credentials during UNC path authentication.
Command
powershell -Command "$current = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order' -Name 'ProviderOrder').ProviderOrder; $new = $current + ',df00tech-test-np'; Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order' -Name 'ProviderOrder' -Value $new" Cleanup
powershell -Command "$current = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order' -Name 'ProviderOrder').ProviderOrder; $cleaned = ($current -split ',') | Where-Object { $_ -ne 'df00tech-test-np' }; $restored = $cleaned -join ','; Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order' -Name 'ProviderOrder' -Value $restored" Expected Telemetry
Sysmon Event ID 13: TargetObject=HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder, Image=powershell.exe, Details contains appended provider name. DeviceRegistryEvents: RegistryKey contains 'NetworkProvider\Order', RegistryValueName='ProviderOrder', ActionType=RegistryValueSet.
Expected Detection
KQL: RegistryMods branch fires with DetectionType='Network Provider DLL Registration', InitiatingProcessFileName='powershell.exe'. SPL: IsAuthRegistryMod=1, DetectionType='Network Provider DLL Registration'. Alert severity High.
Related Detections
Sub-techniques (9)
- T1556.001Domain Controller Authentication
- T1556.002Password Filter DLL
- T1556.003Pluggable Authentication Modules
- T1556.004Network Device Authentication
- T1556.005Reversible Encryption
- T1556.006Multi-Factor Authentication
- T1556.007Hybrid Identity
- T1556.008Network Provider DLL
- T1556.009Conditional Access Policies