Common signs include unexplained changes to the Lsa Security Packages registry values, the appearance of suspicious DLLs in system directories, and new log files such as kiwissp.log or mimilsa.log. Security teams should also treat any unexpected loading of security packages by domain controllers as a strong warning signal, especially when paired with privileged access or recent admin activity.
How to recognize SSP-based credential dumping on a Windows domain
SSP-based credential dumping is usually less about a single indicator and more about a cluster of Windows credential-store tampering signs. The most useful clues are changes to security package configuration, unexpected DLLs placed where LSASS can load them, and artefacts that suggest a dumping tool already ran. On domain controllers, any new security package load deserves immediate scrutiny.
Because the technique abuses how Windows loads Security Support Providers, the first thing to verify is whether the system has been altered to load an extra package at logon or service start. That often means registry changes, dropped binaries, and follow-on log files that appear only after the malicious package is invoked.
What artefacts usually point to SSP tampering?
The most common visible sign is an unexplained change to the Lsa Security Packages registry values, especially when the added entry does not match your approved baseline. Security teams should also look for DLLs in system paths that are not consistent with normal patching or software deployment, because SSP loading depends on those libraries being reachable by the authentication subsystem.
Suspicious filenames and paths matter because SSP abuse is usually operationalised through a payload that must survive reboot and load quietly. When a system starts writing logs such as kiwissp.log or mimilsa.log, that is strong corroboration that a credential-dumping tool is active or has already been executed. OWASP Non-Human Identity Top 10 is useful here because it frames credential exposure, rotation failures and overprivilege as part of the same abuse path.
Domain controllers raise the stakes. A newly loaded security package on a controller is not a routine endpoint oddity, it can indicate that an attacker is trying to harvest reusable authentication material at the place where the highest-value identities are processed. That is why the event should be treated as suspicious even before you confirm exfiltration.
Why domain controller activity changes the severity
On a workstation, SSP tampering may still be serious, but on a domain controller the same behaviour can expose password hashes, service credentials or other material that enables broad lateral movement. The practical difference is blast radius: a compromised controller can turn a local credential theft into domain-wide access.
That is also why privilege context matters. If the suspicious registry change or DLL load appears shortly after admin activity, remote maintenance, or use of privileged tooling, the question becomes whether the change was authorised and logged. A valid administrative action still needs to match change records, because adversaries often hide behind expected maintenance windows. MITRE ATT&CK Enterprise Matrix is a good companion reference for mapping the behaviour to credential access and defence evasion patterns.
SSP abuse is also dangerous because it can persist invisibly. Once a malicious security package is registered, it may reload automatically and continue collecting credentials across reboots. That makes early detection far more valuable than post-incident discovery.
What to check first when you suspect SSP credential dumping
Start with the exact registry path, the loaded package list, and the file hashes of any newly introduced DLLs. Then compare the findings against your gold image, authorised software inventory, and recent change tickets. If the machine is a domain controller, treat any mismatch as a high-priority incident until proven otherwise.
Next, look for evidence of tool execution and post-compromise handling. New log files, odd timestamps, unsigned binaries in system directories, and unexpected service restarts are all useful clues, especially when they appear together. Baseline drift plus credential-store artefacts is much more meaningful than any one signal alone.
For deeper validation, compare the observed behaviour with known credential-access techniques and verify whether other authentication material was touched at the same time. RFC 6749: The OAuth 2.0 Authorization Framework is relevant as a broader reference point for machine-to-machine credential abuse, while OWASP Cheat Sheet Series provides implementation guidance on protecting credentials and reducing exposure.
Risk and Threat Considerations
SSP-based dumping is high risk because it targets the credential layer that Windows relies on for trust, persistence and domain access. The main threat is not just disclosure, but the attacker’s ability to reuse harvested material for privilege escalation, lateral movement and long-lived access.
Failure mechanism: An attacker or malicious tool modifies the Lsa Security Packages configuration, drops a loadable DLL, and causes the package to run inside the authentication process where credentials can be captured or derived.
Impact: The compromise can expose reusable domain credentials, enable stealthy persistence on domain controllers, and create a direct path to broader domain takeover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1003 — OS Credential Dumping | SSP dumping is a credential-dumping technique that targets Windows authentication material. |
| Recommendation — Map the activity to T1003 and hunt for credential access, persistence, and lateral movement indicators. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | SSP dumping exposes reusable authentication material and credential-like secrets. |
| NHI-05 — Overprivileged NHI | The impact grows when harvested credentials or service accounts carry excessive privilege. | |
| Recommendation — Treat unexpected SSP loads as secret-exposure events and rotate affected credentials immediately. Reduce privilege on exposed accounts and remove unnecessary domain-wide access paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential dumping directly implicates lifecycle control over authenticators and secrets. |
| SI-7 — Software, Firmware, and Information Integrity | Unexpected SSP DLLs and registry changes indicate integrity compromise in system loading. | |
| Recommendation — Enforce rotation, revocation, and protection controls for credentials tied to affected systems. Validate system integrity and investigate unauthorized binaries or configuration changes immediately. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential dumping becomes severe when exposed accounts remain active or overly privileged. |
| Recommendation — Review affected accounts, revoke risky access, and reset credentials with verified exposure. | ||
Practitioner Guidance
What to prioritise: Treat any unexpected SSP change on a domain controller as an incident-first event, not a hygiene task. Preserve the registry, the DLL, and the surrounding event timeline before remediation so you can prove whether the package was authorised.
What to verify: Confirm whether the package name, binary hash, file path, and timestamp match an approved deployment. If you cannot tie the change to a documented change window, assume credential exposure is possible until containment is complete.
Common mistake: Teams often remove the malicious file first and only then ask what it loaded, which destroys the evidence needed to determine whether hashes, tickets, or administrator accounts were already compromised.
Practitioner takeaway: The deciding factor is not just whether SSP files changed, but whether the change created a new credential collection path inside a trusted authentication process.
Related resources from NHI Mgmt Group
- What are the signs that credential harvesting from domain shares is happening in practice?
- What are the signs that an SSL certificate has not been installed or trusted correctly on a Windows-based password vault?
- What are the signs that a credential-based intrusion is escalating from login abuse to broader system compromise?
- What are the signs that credential-based access is being abused inside a cloud or document repository?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
