Shimming Attack vs Refactoring Attack – Security+ Driver Manipulation

Shimming and refactoring are tactics that attackers might use to tamper with device drivers. Crafting an attack on a device driver is a rather specialized method for infiltrating a system which demands a significant amount of expertise. However, if such an attack is successful it can lead to substantial harm.

This is because drivers are highly trusted by the operating system. Consequently, compromising a driver can be challenging to detect and can provide the attacker with a wealth of information. To break things down, let’s first explore what drivers are, understand how our operating systems defend against these types of attacks, and then get into the workings of shimming and refactoring.


Drivers serve as the guiding instructions that enable a system’s hardware components to work with the operating system. These hardware components establish connections with one another through the motherboard, yet their potential remains untapped without the presence of instructions. Drivers allow the operating system to use the full potential of all components linked to the motherboard by ensuring their compatibility.

When you purchase a computer with an operating system already installed, the manufacturers have taken care of configuring all the hardware and ensuring compatibility. However, if you’ve ever built a computer or installed an obscure Linux operating system you’ve probably encountered driver issues.

But drivers do more than just instruct hardware; They also play a crucial role in keeping your components secure. Graphics cards, printers, Wi-Fi chips, and other components receive updates throughout their lifetimes. These updates serve to fix bugs, enhance technology, and protect your hardware from known vulnerabilities.

Depending on your OS and settings, driver updates happen when you update your system.

Anti-Malware and Anti-Virus

Modern anti-malware and anti-virus software do a great job at protecting our systems against known vulnerabilities.

Malware and virus detection often relies on a combination of methods, including signature-based detection, to identify activities like driver manipulation. Signature-based detection is like a digital fingerprinting system for malware. Antivirus software maintains a database of known malware signatures, which are unique patterns or characteristics found in malicious code. When the antivirus scans your computer, it compares the files and activities it finds to these signatures. If it detects a match between the scanned code and a known malware signature, it raises an alarm and takes appropriate action.

However, signature-based detection has limitations. It can only detect malware for which it has known signatures. New or previously unknown threats, often referred to as zero-day threats, can slip through undetected. To address this, modern antivirus solutions also employ behavior-based and heuristics-based detection methods. These techniques look at how a program behaves or its characteristics to determine if it’s potentially malicious, even if it doesn’t match a known signature.

Although it is possible that at anti-malware or anti-virus scan can detect a zero-day driver manipulation attack, it is highly unlikely. Hackers are coming up with new ways to evade these scans every-day, so let’s explore what shimming and refactoring attacks are.

Shimming Attack

A driver shimming attack involves the misuse of a helpful tool known as a shim within an operating system like Windows. Driver shims are intended to make older drivers work smoothly with newer software. They bridge the gap between older and newer components.

Just as with the conventional shim, a shimming attack uses a layer in between the driver and the operating system to target.

A shim is a relatively small piece of additional code that is used to provide compatibility between an application or software component and a driver or operating system. Users may need a shim when they want to run older applications or hardware on a more modern operating system. This is because as operating systems evolve, they may drop support for certain older drivers or functionalities. Instead of rewriting the entire driver, which can be a complex and time-consuming process, shims are introduced to intercept calls between the application and the driver and make adjustments to ensure compatibility.

However, attackers can insert their own harmful code in place of a legitimate shim.

When an application tries to use an older driver, the operating system directs the call to the malicious shim instead. This substitution can lead to various security risks, or even complete system compromise. Driver shimming attacks can be challenging to detect because they operate at a low level within the system, making them less visible to typical security defenses.

Refactoring Attack

A driver refactoring attack represents a distinct threat that stands in contrast to the previously discussed driver shimming attack. While driver shimming focuses on making external adjustments to achieve compatibility, a refactoring attack targets the core code of the drivers themselves. Programmers often use refactoring as a legitimate practice to enhance code quality without changing the program’s behavior. However, when employed maliciously, refactoring can lead to the creation of hidden backdoors or critical vulnerabilities within the driver code.

A refactoring attack involves making alterations to the actual code of the drivers.

This can include changing the structure, logic, or functionality of the code in a way that benefits the attacker. If the attack involves a brand-new exploit, then traditional security software may struggle to detect them until updates or patches are available.

The main objective behind such attacks is to introduce vulnerabilities that could be exploited later for unauthorized access, data breaches, or control over the affected system. Unlike shimming attacks that focus on intercepting calls, refactoring attacks tamper with the driver’s underlying code.

Real World Driver Exploit

Driver manipulation has been a persistent challenge for operating systems. Microsoft has grappled with this issue for years balancing between security and the needs of its diverse user base, some of whom rely on older software.

The heart of the problem lies in a Windows policy loophole that allows malicious actors to exploit the signing and loading of kernel-mode drivers. This loophole grants attackers the highest possible privilege level, as it provides access to the kernel. This represents a significant threat, as kernel-level access can allow for total system compromise.

Hackers leveraged open-source tools like HookSignTool and FuckCertVerifyTimeValidity to manipulate drivers signed prior to July 29, 2015. These tools enabled them to craft and sign new drivers using certificates from older ones, effectively infiltrating and executing malicious code on systems.

The underlying policy designed to ensure compatibility with older software by allowing the loading of older drivers in Windows 10 and Windows 11, has inadvertently created a security vulnerability. While Microsoft has responded by blocking the malicious drivers and the associated developer accounts, the issue of driver manipulation persists.

Security researchers argue that the current practice of blocking malicious drivers falls short of an ideal solution, as it allows hackers to exploit these vulnerabilities for extended periods.


Driver manipulation attacks can inflict significant harm on a system yet executing them is a very challenging task. These attacks demand a great understanding of programming and familiarity with low-level operating system intricacies. Their success hinges on the attack’s level of sophistication and whether similar exploits have been previously attempted. Notably, a zero-day attack, is likely to evade detection by standard antivirus or anti-malware scans.

If you are studying for your Security+ exam, good luck I hope this helped.