Evidence of a Custom Security Support Provider (SSP) usually appears in authentication and system logs that record security package registration, loading or use during logon activity. Review the relevant host and directory authentication logs for unexpected SSP names, new package registration, or unusual credential-processing behaviour. Also compare changes against approved security software and hardening baselines.
Where evidence of a custom SSP appears
Look first in the host-side authentication trail, because a custom security support provider usually surfaces when the operating system records package registration, logon processing, or security package loading. That is where you are most likely to see an unexpected SSP name, a new package added to the authentication stack, or credential-handling behaviour that does not match the approved baseline.
The most useful records are the ones that tie authentication events to system change events. Pair logon activity with service, driver, and configuration changes so you can tell whether the SSP was introduced deliberately, loaded by a legitimate security product, or injected as part of a persistence or credential-access technique.
On Windows estates, that usually means comparing security event data with service-installation and system-startup telemetry. A custom SSP may not be obvious from a single event, but the combination of an unusual package name, a new binary path, and a corresponding authentication event is often enough to establish that the logon stack has been modified.
How to interpret the log pattern
An SSP is not just another library load. It is part of the authentication path, so any evidence should be treated as security-relevant even if the machine still appears to function normally. A benign security product may register an SSP for protection or auditing, but an attacker can also use the same mechanism to observe credentials, alter logon behaviour, or maintain access.
That makes change context essential. Review the event sequence around the first appearance of the package: who installed or updated software, whether the host was patched or hardened, and whether the package name matches an approved endpoint protection or identity product. If the name is unfamiliar, undocumented, or appears without a change record, treat it as suspicious until proven otherwise.
Directory-integrated environments deserve extra scrutiny because authentication components can be deployed broadly and silently. A custom SSP on one host may be an isolated software issue, but the same pattern across multiple systems can indicate a wider campaign affecting sign-in telemetry, local credential processing, or session establishment.
What to verify before you conclude it is malicious
Separate product-driven security telemetry from unauthorised modification. The practical test is whether the SSP name, file location, signing status, and registration path align with an approved security tool or a documented hardening standard. If they do not, the next question is not “does the system still work?” but “what authentication behaviour was changed and what could that process now observe?”
Where possible, correlate the event with system inventory, approved software lists, and configuration management records. A valid SSP should be explainable from those sources. If the log trail shows a package that does not belong to any sanctioned security or identity product, investigate the process lineage and the timing of the change before dismissing it as harmless.
For defenders who need a durable reference point, the logging patterns described in the Windows Event Log Guide help anchor authentication events, service changes, and log-clearing activity in one investigation workflow.
Risk and Threat Considerations
A custom SSP matters because it sits inside the authentication path, where it can influence or observe sensitive sign-in processing. If an attacker gains the ability to register or replace an SSP, they may be able to capture credentials, alter logon flow, or hide persistence inside a component that defenders do not inspect every day.
Failure mechanism: The security boundary fails when an unapproved package is registered as part of the logon stack and then trusted during authentication, allowing credential-processing behaviour to be changed without obvious user-visible symptoms.
Impact: The result can be credential exposure, stealthy persistence, and broader compromise of accounts that rely on the affected host or directory authentication path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1556 — Modify Authentication Process | Custom SSPs alter authentication processing and can enable credential capture or persistence. |
| Recommendation — Map unexpected SSP activity to T1556 and hunt for authentication-process modification indicators. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The answer depends on reviewing host and directory logs for package registration and logon anomalies. |
| Recommendation — Centralise and review authentication and system logs for unexpected package registration events. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Detecting SSP evidence depends on generating and retaining the right authentication and system records. |
| SI-4 — System Monitoring | Custom SSPs are identified through monitoring for unauthorized authentication-path changes. | |
| CM-5 — Access Restrictions for Change | Unauthorized SSP registration is a configuration-control failure that should be constrained. | |
| Recommendation — Enable audit generation for logon, service, and configuration-change events that expose SSP registration. Correlate authentication and configuration telemetry to detect unapproved SSP loading or registration. Restrict who can register or modify security packages on authentication hosts. | ||
Practitioner Guidance
What to verify: Confirm whether the SSP name, binary path, and registration event match an approved security product or a documented hardening baseline. If any one of those three is inconsistent, treat the host as requiring deeper review rather than assuming the package is benign.
What to prioritise: Focus on the first observed appearance of the package and the surrounding logon events, because that is usually where you can distinguish sanctioned deployment from suspicious modification. If the host also shows unusual authentication failures, service creation, or recent security configuration changes, escalate the investigation.
Practitioner takeaway: The key judgement is not whether the SSP is merely present, but whether it is explainable, approved, and consistent with the host’s authentication baseline.