Gaining Threat-Intelligence the REALLY dodgy way
tl;dr
I forked and used hfiref0x’s awesome Kernel Driver Utility project to subscribe to the Microsft-Threat-Intelligence feed without using a signed binary or test machine.
Back to ETW-TI
Despite spending most of my time away from Windows these days, I was recently motivated to check back in with ETW, especially after the exploit used by SealighterTI was patched.
To refresh your memory on the systems and acronyms covered in this blog series so far (or skip to the new content):
Event Tracing for Windows (ETW)
ETW is a system on Microsoft Windows that provides tracing and event logs for a variety of kernel- and user-mode systems, both from Microsoft and other developers. Grouped into ‘Providers’, these events can provide a wealth of information for anyone looking to understand what is happening on a system, from Security products looking to detect malicious activity to bug hunters looking for vulnerabilities.
KrabsETW and Sealighter
KrabsETW is a C++ and .NET library that makes it very easy to subscribe to and receive ETW events.
Sealighter is a tool I built on top of Krabs to provide a basic commandline interface into ETW, making it easy to explore ETW events and data.
Protected Processes, PPL, and Early Launch Anti-Malware
Starting with Windows 8, Microsoft started developing new ways to provide extra protection to critical and sensitive information, such as user credentials or Anti-Malware processes.
One of these mechanisms is called Protected Proceses, and its sibling ‘Protected Process - Light’, or PPL. These are user-mode programs that have extra protections and security to prevent tampering but are also allowed access to data that typical programs cannot.
They require (among other things) that the program binary and libraries are checked and signed by Microsoft, which will then mark the binaries with a special entitlement indicating they can be run as a protected process.
One of these entitlements is called ‘Early Launch Anti-Malware’ or ELAM. Designed for security products, it allows the programs to both protect themselves from attackers, and gain special access to the system, such as the ability to scan Kernel activity early in the machine’s boot process. ELAM user-mode programs have to be loaded alongside a similarly checked-and-signed Kernel Driver, and there is a vetting process in place before a person or company can create ELAM programs.
Protected processes with the ELAM entitlement are sometimes called ‘PPL-AntiMalware’.
Microsft-Security-Threat-Intelligence
Microsft-Security-Threat-Intelligence is the name of a special ETW Provider, that can only be read by PPL-AntiMalware processes.
It contains lots of information that is very interesting to security software, such as suspicious memory allocations that could be evidence of process injection or Kernel exploitation.
Previous attempts
Test-Signing Mode
As mentioned above, to run a PPL process and subscribe to Microsft-Security-Threat-Intelligence the legitimate way on a normal Windows machine, you need a driver checked and signed by Microsoft with the ELAM entitlement.
If you put the Machine into ‘Test Signing’ or ‘Debug’ mode, while the program is still required to be signed and accompanied by an ELAM driver, it does not need to be signed by Microsoft.
I covered the steps to collect data from the Threat-Intelligence Provider on debug machine in my blog Experimenting with Protected Processes and Threat-Intelligence
.
Exploitation
Sometimes an exploit is discovered allowing you to inject code into an existing PPL process.
Although strong security mechanisms typically prevent this, back in 2018 Alex Ionescu and James Forshaw presented a series of talks, and blogs, covering many ways you could trick Windows into illegitimately running arbitrary code at the PPL level.
One of their techniques was worked up by Clément Labro into PPLDump, which would trick certain PPL Programs into loading an unsigned driver.
In my blog Gaining Threat-Intelligence the dodgy way, I built off Labro’s code to create SealighterTI, which uses the same exploit to subscribe to the Threat-Intelligence feed and send the results to the Event Log to be read and analysed.
Earlier this year, Microsoft patched the exploit used by PPLDump and SealighterTI, so these no longer work on up-to-date systems.
Even Dodgier Method - Vulnerable Drivers
Recently there has been growing public interest and research into utilising old drivers with known vulnerabilities for attack purposes.
As these old drivers are legitimetly signed by Microsoft, they can be used to exploit the system and gain Kernel-level privileges on up-to-date systems, and can circumvent a lot of Windows security mechanisms such as Secure Boot.
Microsoft can revoke the certificate of the drivers to prevent them from loading, and both Microsoft and 3rd-party security vendors provide ways to block these drivers based on file hash or certificate, but this is often a difficult cat-and-mouse game, as driver developers might not be forthcoming with details about exactly what versions of their driver are vulnerable, and what file hashes and signatures to block. And there is a lot of drivers out there to monitor and write signatures for.
For defensive purposes, the best protection is to know what drivers are normally installed on a system (to spot anomalies), and to closely monitor who, when, and how new drivers are installed, as installing new drivers does require Administrator privileges and should not be a common administrator task.
But for research purposes, vulnerable drivers provide an excellent way to explore Windows from one of the highest privilege levels, without altering system behaviour by putting it into a non-production debug state.
Enter the Kernel Driver Utility
The Kernel Driver Utility (KDU) from hfiref0x is an excellent project to explore the possibilities of vulnerable drivers.
Hfiref0x has collected a range of known vulnerable drivers (30 at the time of this blog), and abstracted exploiting each driver into a common interface to be able to read and write arbitrary kernel memory from user-land.
It also comes with several shellcode-based Kernel Driver loaders, making it trivial to write your own unsigned driver (perhaps first testing it normally on a debug system), and deploy it to a fully patched and protected system.
KDU and Sealighter
For interacting with PPL processes, KDU originally could only strip protections from processes, a not-uncommon tactic to be able to dump PPL memory or kill the process.
For Sealighter and The Threat-Intelligence Provider, I added a new feature to KDU to enable it to launch new processes as PPL-AntiMalware.
To achieve this, KDU first creates the process suspended usinh CREATE_SUSPENDED, so that while the process object in the kernel is created, the program hasn’t started to run. Then KDU uses a vulnerable driver to edit kernel memory, altering the process object in memory to change its protection type and signer to be PsProtectedTypeProtectedLight and PsProtectedSignerAntimalware, i.e. PPL-AntiMalware.
With this new feature, it was easy to then use KDU to run Sealighter and get Threat-Intelligence events. I simply created this Sealighter config:
{
"session_properties": {
"session_name": "Sealighter-Trace",
"output_format": "stdout"
},
"user_traces": [
{
"trace_name": "TI-Trace",
"provider_name": "Microsoft-Windows-Threat-Intelligence"
}
]
}
Then I built and ran KDU like this:
kdu.exe -pse "C:\path\to\Sealighter.exe C:\path\to\config.json"
And just like that, we get Threat-Intelligence events from a fully patched, non-debug Windows environment:
As you can see from the picture, the machine is running the latest Windows 22H2, Secure Boot is enables, and Driver signing using WHQL is enforced. Despite all that, KDU was able to load an old version of the legitimate MSI Afterburner RTCore driver, which is vulnerable to the exploit CVE-2019-16098 . It used this driver and the exploit to edit the EPROCESS->PS_PROTECTION object in the kernel’s memory to set the protection level of the process to be PPL-AntiMalware.
Once KDU does it’s job, the Sealighter Process is un-suspended, and it can now subscribe to and log events from Microsoft-Windows-Threat-Intelligence.
Conclusion
This blog doesn’t cover anything particularly new but does demonstrate yet another way to explore PPL Processes and the Threat-Intelligence ETW Provider. Vulnerable drivers will always be a security problem, but for both defensive and offensive research they also provide an excellent resource to learn more about Windows.
My additions to KDU are now merged into the main branch, so you can explore creating PPL Processes yourself by cloning the latest version from GitHub
Thanks go to hfiref0x for KDU, to lean and explore some more, I recommend you check out: