The hardware are the components responsible for operating the machine in the first place, and thus it all boils down to them allowing things to function or not.
What you can do is what @Mr.X suggested - use a Virtual Machine. Virtual Machines will leverage built-in virtualisation support (technology embedded into your CPU). Intel implement their own virtualisation technology into their CPUs and AMD do the same by implementing theirs. Intel have Intel VT-x and AMD have AMD SVM (Secure Virtual Machine). If your hardware supports it then you can enable it from the BIOS. This is also referred to as the "hyper-visor", which explains why some security software have conflicts with Virtual Machine software on-occasion.
You shouldn't be worrying about hardware infections, or even firmware infections for that matter. A bigger concern for an average home user like ourselves would be accidentally making a mistake with a dodgy e-mail or download and becoming infected with a normal ransomware sample.
You're extremely unlikely to run into a UEFI-based bootkit, or the alike. These types of attacks are simply not prevalent in the wild, especially not aimed at home users. It would be out of the ordinary for even a business to be targeted with such an attack. You have to know what you are doing and have information regarding the environment for the target to even consider deploying an attack like this, which pretty much eliminates the home user potential. I can tell you right now that developing attacks like those will not just require your average "experience", especially for it to be successful and work as intended a majority of the time.
You need to remember that only kernel-mode code can access the firmware/hardware, which means a kernel-mode component will be required. This is one factor which eliminates the home user abuse potential, not to mention that you'd need a zero-day Windows vulnerability to bypass PatchGuard for 64-bit targets without an EV certificate now.
Afterwards, you need to remember that the author would need to understand how the Windows boot-loader works. They'll need to plan and take action with the plan in-order to get their code executing at boot first, and then allow Windows to start-up. This typically involves byte-patching of the Windows boot-loader in memory (e.g. for UEFI systems it'd be targeting an *.efi). All of this needs to be done without triggering any internal protection mechanisms in Windows, or making the system unstable in a way that it won't work properly after the deployment of the attack (stability will require extreme experience, as well as for the success rate to be in favour and not odds). This will differ between each OS version and potentially patch updates as well.
After that, you need to remember that if Windows has an update, depending on the circumstances it can cause that previously deployed attack to have problems and leave the system unstable. This would raise awareness and people would start to wonder why the system is having trouble, and in an endpoint environment this can lead to a proper investigation -> potentially exposing the attack which had previously been deployed.
Now I cannot say much about the deployment of an attack on hardware because I've not studied this reasonably to talk about it, but the only bootkit attack or any similar attack a Home user has any chance of encountering, or most businesses, would be evolving around the Master Boot Record. Cut off any potential for anything deeper than that in a realistic situation. You'll find Proof-Of-Concepts on GitHub but none of which are abused by malware in the wild, even years later from their disclosure date, and that is for the reason that most malware authors will not even know where to start with developing such an attack, let alone deploy it successfully without having their operation identified due to unstable/unreliable code - whether a "professional" or not.
A more realistic concern would be whether the hardware in your system had been altered with malicious intent by employees from your manufacturer on behalf of a government agency, since this has actually been done before (exposed by Kaspersky a few years ago). As opposed to worrying about whether you'll be hit with an attack which touches firmware/hardware.
Last edited by a moderator:
