BH18: Kernel Mode Threats and Practical Defenses

Joe Desimone, Gabriel Landau (Endgame)

Looking at kernel attacks, as it is a method to take over the entire machine and evade all security technology. Historically, Microsoft was vulnerable to malware - not prepared for those types of attacks, but they have made improvements over the year with things like PatchGuard and Driver Signature Enforcement. PatchGuard isn't perfect, attacks get through, but MS is constantly updating so the attacks don't work for long.

Both of these technologies are focused on 64-bit kernels, which is the growing norm today.

Attackers are now using bootkits, so Microsoft and Intel have come up with technology to counter (Secure Boot, Trusted Boot, Itnel Boot Guard, and Intel BIOS Guard).

All of those protections have changed the landscape. We don't see millions of kernel based botnets out there anymore.  But now people are signing their malware to look more legitimate and trick people to install.

DUQU 2.0 was a nation state attack, main payload used 0day in win32k.sys for kernel execution (CVE-2015-2360), it was spoofing process information to route maliious traffic on the internal network.

With the introduction of virtualization based security has also made the system more secure against things like Uroburos, Duqu2, DoublePUlsar.

The MS kernel has been greatly evolving over the last 10  years to greatly improved their mitigations. But, the problem is the adoption rate. There are still a lot of systems running Windows 7, which does not benefit from these new protections.

The speakers are on their orgs red team, so they are always looking for new ways to attack the system. They want to avoid detection and signature checks - their blue team is on the lookout for user mdoe priv escalation, so they wanted to be in the kernel. Looked at sample code from Winsock Kernel, found it was very effective (no beacons).

Did find a good attack, which means they needed to improve their own security.

Modification of kernel memory can significantly compromise the integrity of the system, so this is a major area of concern.

Need chip manufacturer to ship hardware with ROP detection enabled, otherwise this will always be a vector of attack. They did this by creating a surrogate thread, put it to sleep and though foudn the location of the stack and take advantage of it. (more details in the deck, the slides move pretty fast), but the interesting thing here is how much they can do by reusing existing code.

To project yourself, you should very carefully monitor driver load events. Look for low prevalence drivers and known-exploited drivers.  You need hypervisor protection policies, using white lists (which are hard to maintain) and leverage kernel drivers to WHQL. They have made a new tool to also  help to reduce the attack surface, available on their website today.

They wrote some code to generically detect function pointer hooks, locate the function pointers by walking relocation tables and leverage Endgame Marta.  They consider it a hit if it originally pointed to +X section in on-disk copy of driver, does not pont to a loaded driver in memory and points to executable memory.
 
ROP generates a lot of mispredictions, so need to protect this area as well (they could attack by scanning drivers to identify call/return sites, configure LBR to record CPLO near returns, etc)

The talk had lots of cool demos - can't really capture it here.

Windows platform security has gotten much better, but tehre are still kernel threats. You need to be using at least Windows 10 with SecureBoot and HVCI. at a minimum to protect yourself. Requite EV/WHQL within your organization