Defeating RunAsPPL: Utilizing Vulnerable Drivers to Read Lsass with Mimikatz
As operating systems continue to grow and improve themselves security-wise, we find ourselves requiring to defeat more and more of the controls and restrictions during penetration tests. One of such restrictions on Windows is Local Security Authority Protection. This feature arrived with Windows 8.1 and restricts access to LSA, which keeps important information such as used credentials (even if you have NT Authority System privileges). For lateral movement, we have many other methods but getting clear text passwords or NTLM hashes directly from a compromised system usually helps us proceed much faster towards our target during a red team exercise.
One of the tools that can extract clear text or hashed credential information from lsass process is the well known tool, mimikatz. However, when the “RunAsPPL” setting is enabled in the registry on a current Windows system, mimikatz fails to gather clear text or hashed credentials from the memory. What comes to the rescue is another module, that is developed by infamous Benjamin Delpy himself, called mimidrv . This module is a driver file called mimidrv.sys and by loading mimidrv as a driver it becomes possible to do operations to bypass or remove some further controls such as the lsass protection. We are not going to get into detail but Matt Hand has published a great article on the mimidrv functionality and technical details (You can read it here).
What is so special about mimidrv.sys and why would we want code execution as a driver ?
In a nutshell, even if we have administrator or system level privileges we may still want to escalate from the user space to kernel space. Windows drivers are allowed to run in the kernel space but the users are not. Code execution as a driver allows us to bypass or deactivate some of the Windows security mechanisms (such as LSA protection), also from the kernel space it is possible to have a more direct hardware access which in turn could allow us to modify the firmware of some components or the device itself (LoJax malware campaign is an example where a legitimate kernel driver “RwDrv.sys” is used to install persistent rootkit to the UEFI so that it can survive even a complete reinstallation of the operating system. You can read this article for further information.).
Kernel runspace (Ring 0) is a realm where almost everything is possible in a windows operating system.
So, can we say “Problem solved! lets use mimidrv module and gather all the credentials!” ?
Well, Yes and No.
If you are in the middle of a red team engagement and try to bring the same mimidrv.sys file that has been around since 2013 to the target environment, there will be alerts. The hash and composition of the file is known for the last 7 years. Even the least competent AV will probably detect it.
So what do you do now; can you modify the mimidrv source code and obfuscate the file for AV evasion for a quick win ?
Again it’s not that simple. Because on current Windows Operating Systems the drivers need to be signed and in order to successfully load a driver, there are strict rules on the kind of signatures that are acceptable. Microsoft currently requires for any new driver to be first signed with a trusted Extended Validation Code Signing Certificate, and then the driver needs to be submitted to the WHQL portal to be WHQL certified. Only then the drivers are allowed to load in Windows 10. However, there is an exception for older drivers that are signed prior the date: 29.07.2015. These drivers do not need to be signed again or submitted to WHQL portal, and for backward compatibility reasons Windows continues to accept these drivers.
This backward compatibility case can be seen in the below screen recording where the mimidrv.sys file signed by Benjamin Delpy from 7 years ago is still allowed to load as a driver.
In the screen recording below, the user has administrator privileges and tries to load an unsigned mimidrv driver. It can be seen that as the user tries to load the custom mimidrv.sys driver using mimikatz !+ command, the process fails.
There are 2 main ways to attack this problem:
1- Build your own driver, get it signed and Microsoft WHQL certified:
This option is also suggested by Vincent Le Toux. You will need to get an EV code signing certificate and you need to send your own custom driver (that may have some funny intentions) to Microsoft for quality control. Currently, there are not many people who disclose that they are sending such drivers for WHQL signing but it is not hard to imagine Microsoft trying to impose stricter controls on the certification process if this method attracts more attention. Also an EV certificate is a bit costly.
2- Exploit a vulnerable driver that is running as kernel driver on the system:
Another option would be to exploit a vulnerable driver that is already running on the system to escalate privileges. But what if there are no vulnerable drivers running on the system ?
Well, then, there actually is one more option: BYOvD, meaning Bring Your Own Vulnerable Driver. With this method, you upload a regular driver for any device or vendor that has code execution vulnerability to the target system. The perfectly normal product driver (that is also a little exploitable), lets say for a keyboard or a hard drive, would already be signed in the past before its release so that it could function. That driver would still be acceptable by Windows OS today. Thus, what we can do is to bring a vulnerable driver that we know how to exploit, load the vulnerable driver to our target system, and as this driver has rights to run in Ring 0 we will have the same rights after exploiting the driver. After getting the kernel level code execution rights, it is possible to act the same way as the mimidrv driver, bypass the protection and access LSA.
There are multiple POC programs on Github for exploitation of the vulnerable Gigabyte driver. We are going to use the proof of concept called gdrv-loader by Alexander Bruun to load our custom created mimidrv.sys. In this POC, the program first acquires Kernel level code execution right by exploiting the vulnerable Gigabyte driver and then uses the higher privilege to momentarily disable the Driver Signature Enforcement (DSE), load the given driver and enable DSE back again. After exploiting the Gigabyte driver, we can also directly remove process protection of a desired process(similar to what DanSpecial does). We could have also completely renamed the mimidrv file and its service to something else or further modified the mimikatz & mimidrv code for evasion. We could even load a custom driver of our own that would provide the similar functionality. Here, we are just using a freshly built and unsigned mimidrv for demonstration purposes.
OPSEC Note: Do not run untrusted/unverified code/binary in a live environment, review source codes, rebuild and test in controlled environments.
As we already have Administrator privileges, we can easily load the vulnerable (but signed and valid) Gigabyte driver to the target system. In the above example, we disable DSE and load our unsigned mimidrv driver with the help of kernel level code execution rights. mimidrv has a function that allows us to make any process protected. Thus, it is possible to protect the mimikatz.exe process using command !processProtect /process:mimikatz.exe . After this invocation it is possible to read lsass memory again.
Beware (Here be Dragons!)
It is harder for the operating system to tolerate or recover from errors that occur on the kernel level thus I would like to emphasize that loading rogue drivers to a windows system is a risky action and may very well cause system instability and/or crash (aka BSOD). Testing such actions multiple times on controlled environments and taking all necessary precautions before running on live systems are strongly advised both for OPSEC and safety reasons.
Further Research on vulnerable Drivers
There is research by the Eclypsium team (presented at Defcon 27) on finding unreported but possibly vulnerable drivers, it is very much possible to apply their methods and search for such previously unknown drivers, write custom exploits for them and use in your engagements for better evasion. You can read about their research here.
Note: It is unlawful to access computer systems without explicit consent. Author assumes no liability; always have permission and take necessary precautions before any invasive activity.
