In our lastpost, we described the evolution of kernel mode threats. These remain a prominent mode of compromise for nation-state attackers, as they are difficult to detect and enable robust persistence. Despite advances in platform protections, kernel mode threats continue to evolve and have been employed in many high profile attacks, such as WannaCry and NotPetya. What can organizations do to protect against kernel mode threats? Fortunately, the state of the art in defense also has evolved to counter this impactful attack trend.
Our own offensive tradecraft research informs our approach to improving defenses from kernel threat vectors. We will first cover our own research which evolved from Red versus Blue exercises, as well as detail deeper analysis into evading current platform protections. With the state of the art in offensive tradecraft established, we will then discuss several approaches to defending against kernel mode threats. We will also introduce two open source tools to help defend against kernel mode threats. Some are fast wins, while others involve hunting and establishing real-time protections. And in all cases, we still highly recommend upgrading to the latest windows 10 and enable as many protections as feasible in your organization.
Offensive Tradecraft ResearchTo test and push the boundaries of our defenses, it is essential to comprehend the state of the art in offensive tradecraft. During an internal red vs blue, we first explored leveraging kernel mode malware to evade endpoint security products and the most commonly deployed kernel protections (such as Driver Signature Enforcement). Next, we investigated methods for evading the most advanced kernel protections such as Virtualization Based Security (VBS) and Hypervisor Code Integrity (HVCI).
Red vs. BlueEndgame periodically conducts internal Red vs Blue exercises to test our product and team’s skills. The Red Team is tasked with emulating adversaries of varying sophistication levels. This includes everything from very noisy commodity malware to mid and upper tier APTs. Typically, those of us on the Red Team try to stay stealthy with the latest user-mode in-memory techniques. However, our Blue Team is constantly upping their game and and became increasingly efficient at zeroing in our user mode injection techniques. We decided to pursue kernel-mode in memory techniques to raise the bar.
Turla Driver Loader (TDL) was a key piece of our kernel tradecraft. TDL is an open source implementation of the Turla/Uroburos driver loading technique. In a nutshell, it will load a vulnerable VirtualBox driver. From there, the VirtualBox driver is exploited to load and execute arbitrary kernel shellcode. TDL is built with shellcode that leverages a technique like "MemoryModule" in user mode to manually map an arbitrary driver and call its entry point. Using TDL helps the Red Team achieve two objects: evade driver signature enforcement and never write our driver to disk on the target machine.
We had some other high level design goals for the implant. First, we wanted to avoid any user mode components. A very typical design is to use a kernel mode component which injects into a user mode process for performing the primary "implant" functions. The kernel mode malware referenced in these two posts have some user mode components. Avoiding user mode is more time consuming for basic features, but we felt it would be worth it. Injecting anything into user mode would have a high chance of getting caught by our Blue Team. This required us to do our network command and control from kernel mode. We chose Winsock Kernel (WSK) as our networking choice because it is very well documented, has great sample code, and presents a relatively easy interface for doing network communications from the kernel.
To further confuse our Blue Team, we did not want a beacon style implant. Beaconing is by far the most popular technique for malware and we knew it was something they would be looking for on the range. Our initial port opening concept unfortunately could be detected easily. We settled on a more stealthy approach by re-using the DoublePulsar function pointer hook trick to hijack some existing kernel socket. However, we didn't want to leverage the same hook point, expecting it to now be monitored by PatchGuard. After digging around in various stock network enabled drivers we settled on the srvnet driver which opens port 445. Our driver egg hunts to locate and hook srvnet’s WskAccept function with our own accept function. This allows our implant to selectively hijack port 445 traffic.
Leveraging TDL meant that our kernel driver would never touch disk, however there was still a high risk that the loader itself could be caught. As a result, we wanted to ensure the loading process itself was as fileless as possible. This meant starting the chain with either PowerShell or javascript. We opted for JS due to generally less visibility for defenders. Instead of launching cscript/wscript itself, we used the squiblydoo technique to run a scriptlet from a regsvr32 process. For our actual Black Hat demo (below), we updated this to use SquiblyTwo and the winrm.vbs evasion technique .
From here, we used DotNetToJS to load/execute an arbitrary .NET executable from JavaScript. We could have exploited and loaded our driver from this .NET executable, but the code for doing this was already written in C. The easier option was to use a MemoryModule style .NET loader to then load and execute the native executable. The native executable (TDL) would then load the vulnerable VirtualBox driver, and exploit it to load and map our implant driver into memory. In this whole process, the only executable that truly touched disk in native form was the legitimate VirtualBox driver.
Demo 1: Fileless Kernel Mode Evading VBS/HVCIWhen we were accepted to present at Black Hat, we wanted to push the bounds of our offensive tradecraft. Currently, Microsoft's Virtualization Based Security (VBS) combined with Hypervisor Code Integrity (HVCI) will block any unsigned code from ever running in the kernel. This includes DoublePulsar and the implant we wrote for our RvB exercise.
We first identified a vulnerable driver because the VirtualBox driver from TDL won’t load while HVCI is enabled. There is virtually an unlimited supply of vulnerable drivers. We grabbed a known-vulnerable sample from Parvez Anwar 's site. Since we had the option to choose the vulnerability brought to the endpoint, we chose an easy to exploit write-*what-where vulnerability, as opposed to a more difficult one like a static one byte write. The latter would typically involve some p