A shim is a small compatibility layer that intercepts calls between a program and the operating system or another library. Attackers abuse shims to hide malicious behaviour, bypass checks, or alter execution, so defenders should monitor unsigned or unexpected shims, persistence points, and processes loading compatibility layers without a clear business need.
How a shim sits between a program and the operating system
A shim is a thin compatibility layer that intercepts calls and redirects them to the expected API, library, or operating system interface. In practice, it lets older software run on newer systems, smooths over missing functions, or adapts one calling convention to another without changing the application itself.
The important detail is that a shim is not the business logic of the program. It is an insertion point. That makes it useful for compatibility, but it also makes it attractive for tampering because control passes through it before the original function completes.
A shim is often easiest to understand as a wrapper with a purpose: preserve expected behaviour while translating, forwarding, or adjusting calls. On Windows, for example, compatibility shims can sit alongside application launch or library loading; on other platforms, similar mediation can happen through preload tricks, runtime hooks, or replacement libraries.
Why shims are attractive to attackers
Because shims can observe, change, delay, or suppress a call, they can be abused to hide malicious behaviour, bypass checks, or alter execution flow. A malicious shim can make a process appear normal while quietly redirecting what it actually does, which is why unsigned or unexpected shims deserve scrutiny.
Compatibility layers also create persistence opportunities. If a shim is loaded automatically by a trusted application path, an attacker may gain repeated execution without needing to modify the main binary. That is especially concerning when the shim is installed through a normal software management path or placed where loading behaviour is rarely reviewed.
For defenders, the practical question is not whether shims exist, but whether the shim is expected for that workload, signed by a trusted source, and tied to a documented compatibility need. A shim with no clear business purpose is a red flag even if the parent process looks familiar.
What defenders should check when a shim appears
Focus on the loading path, the parent process, and the reason the compatibility layer exists at all. If a process is loading a shim, compatibility layer, or injected library outside a known deployment pattern, treat it as a deviation worth validating rather than as harmless noise.
Review whether the shim is unsigned, newly introduced, or associated with unusual persistence locations. Also check whether the shim is changing process lineage, intercepting security checks, or masking file, registry, or network activity that would otherwise be visible in telemetry.
When compatibility is legitimate, the shim should usually be explainable through a vendor package, application compatibility record, or an approved workaround. If you cannot tie it back to one of those, assume the loading event needs closer inspection before it is trusted.
Risk and Threat Considerations
Shims create a trusted interception point, so the security risk is less about the compatibility feature itself and more about what happens when an attacker gains control of that interception path. Once a shim is abused, it can distort what the application thinks it is calling and what defenders think they are seeing.
Failure mechanism: A malicious or unexpected shim is loaded through a trusted execution path, then alters function calls, suppresses checks, or provides a persistence mechanism that survives normal application use.
Impact: The result can be hidden execution, weakened validation, covert persistence, and reduced visibility for monitoring and incident response, especially when the shim is loaded by a high-value or frequently used process.
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 | T1574 — Hijack Execution Flow | Shims alter execution flow and can be abused for persistence or evasion. |
| Recommendation — Map suspicious shim loading to hijack-execution-flow detections and hunt for unexpected library interception. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Unexpected shims are a common malware persistence and concealment mechanism. |
| Recommendation — Scan for unauthorized shims and block unknown compatibility layers in endpoint defenses. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Shim abuse changes trusted execution paths and can undermine integrity controls. |
| CM-7 — Least Functionality | Legitimate shims should be limited to documented business need and approved software paths. | |
| Recommendation — Validate trusted code paths and flag unapproved compatibility layers that alter program behaviour. Restrict compatibility layers to approved use cases and remove unnecessary shim mechanisms. | ||
Practitioner Guidance
What to verify: Confirm that each shim has a documented compatibility reason, a known owner, and an expected loading location. If you cannot explain why the shim exists, treat the finding as suspicious until proven otherwise.
Decision rule: If the shim is unsigned, newly introduced, or associated with a sensitive process, prioritise containment and validation of the loading path before assuming the main binary is clean. If the compatibility need is real, preserve the evidence and move to controlled remediation rather than immediate removal.
What good looks like: Expected shims are rare, documented, and tied to named applications or vendor workarounds. Unexpected shims are visible in monitoring, mapped to an owner, and investigated quickly enough that they do not become a durable persistence method.
Practitioner takeaway: Treat shims as a control point, not just a compatibility convenience, because the same interception mechanism that preserves legacy behaviour can also conceal or enable abuse.