This article describes a quick way to find easy exploitable process killer drivers. There are many ways to identify and exploit process killer drivers. This article is not exhaustive and presents only one (easy) method. Lately, the use of the BYOVD technique to kill AV and EDR agents seems trending. The ZeroMemoryEx Blackout project, the Terminator tool sold (for 3000$) by spyboy are some recent examples. Using vulnerable drivers to kill AV and EDR is not brand new, it’s been used by APTs, Red Teamers, and ransomware gangs for quite some time.

One day, I was trying to bypass an EDR and I noticed something interesting. The EDR I was trying to bypass wasn’t hooking the DLL in their code with jmp instruction like other EDRs in user-land. In this case, it was hooking directly the Import Address Table. This technique makes the usual move like live-patching, or erasing the loaded DLL with one freshly loaded from disk useless. I had to unhook the Import Address Table of my process.

The analysis on this post was made from a Windows 10 x64 bits. If you are trying to compare the content of this post on a lower Windows version you will be disappointed since changes were made in Windows 10. In my last post dedicated to the different ways to retrieve Syscall ID, I explained quickly how direct syscalls were performed in User Mode and remained vague about how it was processed in Kernel Mode.

This post is not an extensive presentation of Hell’s Gate1, Halo’s Gate, FreshyCalls2 or Syswhispers23. You can find detailed explaination on these techniques on their Github repo, various articles and the amazing Sektor7 Windows Evasion Course4. So whats the point of this article then ? Well, I find the various techniques used to dynamically retrieve syscall identifiers very interesting and I wanted to present the difference between them. Soooo let’s begin shall we ?

A long time ago, in a galaxy far far away, I was having fun reversing NotPetya. Files dropped by NotPetya During the dynamical analysis, I identified some files dropped on the disk by the sample. Files dropped in the disk An executed file using named pipe One of them caught my eye: it is executed by the sample with a named pipe argument. A binary executed with named pipe argument

We are going to learn how to steal the passphrase of a drive encrypted with default setup on a Debian distribution. How? Through physical intrusion! The general idea is simple. By default, disk encryption on Debian (and many other distributions) doesn’t encrypt the \boot directory. Even if full disk encyprtion is available via Grub2… To perform this attack, we are going to use a Live USB on the target machine. Using the live USB, we are going to modify the script asking the passphrase (located in /boot) to make it write, in a text file, the passphrase typed by the victim.