How do you detect accessibility feature backdoors such as sticky keys on Windows?

You detect accessibility feature backdoors on Windows by monitoring for changes to system binaries and registry settings associated with logon-time accessibility tools. Alert when those files are replaced, renamed, or modified, especially outside approved maintenance. Also watch for unauthorised changes near the login screen, because attackers use these features to gain command access before sign-in.

How Windows accessibility backdoors are typically hidden

On Windows, these backdoors usually work by swapping in a different executable or altering the launch path for a logon-time accessibility tool. The important thing to understand is that the attacker is not inventing a new feature, they are hijacking one that the operating system already trusts early in the sign-in flow.

That makes file integrity and path integrity the first things to watch. If a binary associated with accessibility features suddenly changes hash, timestamp, signer, location, or name, treat it as suspicious unless there is a clear maintenance explanation.

The same logic applies to registry-backed launch points. If you already monitor persistence mechanisms broadly, the same family of checks applies to accessibility abuse, which is why the Persistence Techniques Guide is the right place to anchor this detection pattern.

What to monitor on the host and at logon

Focus on the files, registry values, and process launches that change what runs at the login screen. The relevant signal is not simply that a file exists, but that a trusted system component is being replaced, redirected, or overwritten in a way that gives a pre-authentication command surface.

Monitor for modifications to the underlying binaries, their parent directories, and the registry locations that control accessibility launch behavior. Alerts are most useful when they are tied to a known-good baseline, because Windows administrators may legitimately enable accessibility tools during support or testing.

Process and file telemetry help here as well. A replacement, rename, or permission change on an executable near the sign-in flow is a stronger signal than a simple logon event, because the attack depends on persistence at a trusted execution point rather than on user interaction after sign-in.

Accessibility abuse matters because it creates command execution before the user authenticates. That means the attacker can gain a shell or elevate control from the login screen, where standard endpoint controls may be weaker and user-session monitoring has not yet started.

The technique also tends to blend into normal Windows behaviour. An attacker can preserve the outward appearance of an accessibility function while replacing the underlying executable, so defenders who only look for new startup items or new services may miss it.

For a broader view of how accessibility abuse fits into attacker persistence and other logon-time techniques, see the MITRE D3FEND Guide and its focus on file integrity, logon-session artefacts, and service or binary verification.

Risk and Threat Considerations

Accessibility feature backdoors are high-value because they turn a convenience feature into a pre-authentication foothold. Once the launch path is altered, an attacker can preserve access across reboots and interact with the system before any normal user logon controls are in place.

Failure mechanism: The attacker replaces or redirects a trusted accessibility binary or its registry-backed launch point, then waits for the next sign-in event to trigger command execution.

Impact: This can lead to interactive local access, credential theft opportunities, persistence across restart, and further privilege escalation if the host is not rebuilt promptly.

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 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	T1546 — Event Triggered Execution	Accessibility backdoors abuse a trusted launch path at logon.
Recommendation — Hunt for event-triggered execution that redirects trusted logon-time binaries.
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	File and binary replacement at logon is an integrity problem.
	CM-3 — Configuration Change Control	Registry and launch-path edits need controlled change management.
Recommendation — Verify system binaries and alert on unauthorized integrity changes. Require approved change records for accessibility-related registry or path changes.
CIS Controls v8	CIS-2 — Inventory and Control of Software Assets	Detection depends on knowing which trusted binaries should exist.
	CIS-8 — Audit Log Management	Host telemetry and alerting are needed to spot unauthorized replacement.
Recommendation — Maintain software baselines for logon-time accessibility executables. Centralize and review alerts for unauthorized file and registry changes.

Practitioner Guidance

What to verify: Confirm the expected file paths, hashes, and signatures for every logon-time accessibility binary in your estate. If the file is present but the path, owner, or signer no longer match baseline, treat it as a compromise indicator rather than a cosmetic change.

Escalation / exception: If the change occurred outside a controlled maintenance window or on a host with no documented accessibility support need, escalate immediately and preserve the current state for investigation before remediation.

What good looks like: You can explain every modification to the accessibility launch chain, tie it to an approved change, and prove that no unauthorized binary or registry substitution can take effect at the login screen.

Practitioner takeaway: The key judgement is to treat pre-authentication launch points as privileged trust boundaries, not ordinary desktop configuration, because tampering there can bypass the normal user-session security model.