Attackers use Application Shimming to attach compatibility shims that alter how an application starts or behaves, sometimes to load malicious code automatically. Because shim settings can persist, they support stealth and repeat execution. Defenders should audit unexpected shim entries, monitor persistence locations, and review application compatibility changes on sensitive systems.
How Application Shimming turns compatibility into persistence
application shimming abuses Windows compatibility features that were designed to fix legacy application behaviour. An attacker can register a shim so a target program launches with altered behaviour, including automatic loading of malicious code. That makes the technique useful for persistence, stealth, and re-execution without changing the main application binary.
The key security problem is that shim databases and related compatibility settings can look like ordinary administration or troubleshooting activity. On a busy endpoint, that lets the change survive casual review while still redirecting execution each time the application starts.
Where attackers place shims and why it is effective
Attackers usually target applications that start often, run with useful permissions, or are trusted by users and defenders. Once the shim entry is in place, the shim can influence process start-up, environment handling, compatibility checks, or DLL loading paths. That makes it a flexible way to trigger code without dropping an obviously named persistence service or scheduled task.
Because the mechanism is tied to application behaviour rather than a single obvious autorun location, it can blend into normal system noise. Persistence Techniques Guide is useful background here because Application Shimming sits alongside other execution-flow hijacking methods that defenders need to recognise as persistence, not just compatibility tuning.
Attackers also like shimming because it can be layered with other mechanisms. A shim may launch a loader, point to a staged payload, or modify how a trusted executable resolves dependencies. In practice, the real goal is not the shim itself, but durable code execution that survives ordinary user activity and some forms of remediation.
What defenders should look for when shims are used maliciously
Unexpected shim entries on sensitive systems are the most direct warning sign, especially when they appear for applications that should not need compatibility exceptions. Review changes to application compatibility databases, custom .sdb files, and any administrative tooling that can write to those locations. A shim that appears shortly before suspicious child processes, unusual DLL loads, or repeated execution of the same payload deserves escalation.
Forensic review should also check whether the shim was used to support first-stage execution, post-compromise persistence, or both. In many cases the shim is only one link in the chain, so analysts should correlate it with process creation, file writes, registry changes, and application deployment history rather than treating it as an isolated event.
Risk and Threat Considerations
Application Shimming is risky because it abuses a legitimate compatibility feature to create persistent code execution that can be hard to spot during routine maintenance. The same mechanism that helps older software run can also help an intruder remain present after the initial foothold is discovered.
Failure mechanism: An attacker plants or modifies a shim database so a trusted application starts with altered behaviour, then uses that start-up path to load malicious code or trigger a payload repeatedly.
Impact: The result can be stealthy persistence, repeated re-entry after reboot or relaunch, and a misleading administrative trail that slows containment and eradication.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1546.011 — Event Triggered Execution: Application Shimming | Directly covers the persistence technique asked about. |
| Recommendation — Map shim activity to T1546.011 and hunt for associated persistence and payload execution. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Shim abuse is exposed through change and execution logging on endpoints. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Shim entries are configuration drift that should be governed on managed systems. | |
| Recommendation — Centralise endpoint logs and alert on unexpected compatibility changes and start-up anomalies. Baseline approved compatibility settings and remove unapproved shim entries promptly. | ||
Practitioner Guidance
What to verify: Confirm which systems actually use application compatibility tooling before you treat a shim entry as benign. On high-value hosts, any new compatibility exception should be tied to a documented change request, owner, and business reason.
What to measure: Track the number of shim changes on sensitive endpoints, the age of compatibility exceptions, and whether those entries coincide with unusual process launches or DLL loads. A growing set of unmanaged exceptions usually signals control drift.
Decision rule: If a shim entry is not tied to a clearly justified compatibility requirement, treat it as suspicious persistence and investigate it alongside other autorun and start-up mechanisms. Do not wait for proof of malicious payload execution before reviewing the change.
Practitioner takeaway: The main defensive mistake is assuming a compatibility entry is low risk by default. In reality, Application Shimming should be treated as a persistence mechanism first and a maintenance feature second when it appears on sensitive systems.