Driver Manipulation – CompTIA Security+ SY0-501 – 1.2

| November 5, 2017


Our device drivers have direct access to hardware and the operating system. In this video, you’ll learn how attackers can manipulate hardware drivers to gain access to your information.

<< Previous Video: Client Hijacking Attacks Next: Spoofing >>


The traditional anti-virus and anti-malware software that we use on our workstations is very good at identifying known vulnerabilities. It has a virus signature database. And if anything is going through your system and executing that matches that signature, it will stop it immediately before it infects your system.

This malware is still obviously able to get onto our systems. And that’s because the malware developers are finding new ways to infect our computers. We have to be on the lookout for the zero-day attacks and these new attack types so that we can prevent this malicious software from getting onto our computers.

One great place to put a piece of malicious software would be on the hardware drivers that we install in our operating systems. These drivers sit between the hardware and the operating system itself. They are effectively privileged code that’s running, very much trusted by the operating system. So this would be a great place to embed some malicious software.

Sometimes this happens accidentally. For example, in May 2016, HP shipped some audio drivers for the audio hardware. And of course, this allows you to enable and control the audio inside of your computer. Unfortunately, it also had the side effect of having a debugging feature that was able to capture keystrokes. Effectively, the audio drivers were able to spy on you as you were using your computer. This obviously is something to think about no matter whether it’s audio, there’s a video keyboard, mouse control. If somebody was able to monitor all of that hardware and capture that data, they would have a wealth of information to use against you.

Our operating systems also include shims. We often think of shims as a physical thing that sits between two objects. Maybe you’re shimming up a door jamb and making sure everything is perfectly straight. But it’s a middleman. There’s also software-based shims that are in our operating systems.

For example, in Windows, there is a shim built into the operating system that allows you to modify applications to run as if they are on different versions of Windows. That way, you’re able to take legacy pieces of software and run them on the latest versions of the operating systems. In Windows, this is called Compatibility Mode. Developers refer to this as the Application Compatibility Shim Cache.

If a malware author, then, could write their own shim to pretend as if it was a previous version of Windows, they may be able to get around a number of security requirements. For example, older versions of Windows didn’t have the user account control feature. And if you could pretend that the application was using an older version of Windows, you may be able to circumvent some of those newer security techniques. This actually happened in January of 2015. There was a vulnerability identified in the shim cache where someone could elevate the privilege just by taking advantage of this vulnerability.

Another technique that malware authors like to do is to change the way the malware looks every time it’s downloaded. This is metamorphic malware. It’s a technique called refactoring. And every time somebody downloads malware, it’s downloaded as a completely different executable. This means that, if you’re looking for something to be the same every time, for instance with an anti-virus signature, this now becomes much more difficult to identify.

The refactoring adds things like NOPs, which are No Operation methods. They put loops into the application. There’s code strings added that have nothing to do with the operation of the malware. They’re really just designed to make the malware look different.

This refactoring process is very intelligent. It takes the malware and reorders all the functions. It changes the actual flow of the application. The code is completely reorganized, and becomes very difficult for a signature-based identification method like anti-virus to be able to now identify this as something malicious.

This means that you should be using a layered approach. You should still use the anti-virus signatures that you have, but you should also consider adding on a blocking of known malicious URLs, or perhaps making sure that you have backups done more often so that, if you do need to restore from backup, you won’t lose too much of your data.

Category: CompTIA Security+ SY0-501

Comments are closed.

X