1) Note the Windows binary in ACPI memory. This is a lovely "Windows Platform Binary Table" (WPBT) rootkit that most OEM vendors now shove in your systems.
2) Most OS developers assume they have the standard 5 UEFI runtime DXEs mapped (PcRtc, MonotonicCounterRuntime, ResetSystemRuntime, VariableSmmRuntime, CapsuleRuntime) because that's what Windows captures in the HAL.
There's a lot more in there, including SPI, PCH, and SMM DXEs.
3) The UEFI Memory Map is "supposed" to mark EFI Boot Services memory as recoverable by the OS, and wipe it before transferring control to the UEFI Runtime environment (during ExitBootServices). The chunk of interestingly duplicated EFI Boot Services modules are not "normal".
4) The random EFI Boot Services module in the middle of the UEFI Reserved Range is even more unexpected.
5) Don't forget the INTEL ACPI DEBUG buffers, the FBPT, the SMM Communications Buffer and Region Table, the BGRT, the TCG2 Final Events Table, the IGD OpRegion, and more.
6) Remember folks, not a single piece of this shows up in any kind of memory dump you take, including even in a Windows "full" kernel dump, because this "isn't memory". I believe some tools are insane enough to have an "MMIO Dump" mode where you might catch this (or just crash).
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I was repeatedly targeted by the threat actor from December 4th until January 24th. I never received any LPE. It surprised me so many people did, given the context. I’d like to offer some non-technical advice on how you can avoid becoming a victim of this specific type of attack:
First, the lure was the ask of advice on weaponizing a DirectX Kernel 0day exploit.
Unless you know a researcher, it seems like a dubious choice to advise in the exploitation of an 0day. You never know what they’re going to be doing with it.
Secondly, given that nobody knew this researcher, I was shocked some people showed willingness to help.
Consider: how do you value your time and what was the intent of this 0day?
If you’re in the business of exploitation, giving an unknown actor free 0day help seems dangerous.
1/ Of all the weird stuff I have ever seen Win32k.sys do, and trust me, I've seen a lot, I have to say this takes the icing on the cake. This is now all over it. Is there a new dev team that does't understand how (why?) the code base works? Is someone desperately hunting a bug?
2/ I am a huge fan of assertions -- use them all over the place. But _runtime_ assertions, with textual strings which send a live crash/telemetry back to the developer? They also happens to basically provide a guided map to where the bugs are. I love seeing words like "should".
3/ Well, I guess this is what happens when you no longer really ever build/use checked builds (apart from some teams) which had ASSERT_MSG providing similar behavior, and don't make them avaialble for customers anymore. Now you have them in retail builds causing live dumps.