All Windows researchers know about RPC and ALPC, and the attack surface provided through the kernel's system call layer. As they know about shared memory, the object manager, the registry, and countless other more 'creative' kernel mechanisms which allow cross-process data sharing and communication, such as raw ETW or atom tables.
But since Windows 8, the kernel has implemented a new facility, accessible from all application layers, which has grown in complexity and use to cover major Windows technologies, without anyone going into its implementation details: the Windows Notification Facility (WNF).
Originally intended to support "Toast" notifications and Windows Push Notifications, WNF has grown today into a generalized framework for internal system communication, coordination, synchronization, and notification of various user and system events, across the kernel/user boundary (and between user applications). Launching a process causes a WNF notification. Making a phone call causes a notification. Your GPS location changing causes a notification. Lack of input for N minutes causes a notification. Installing a start menu tile causes a notification. Such examples only scratch the surface -- there are over a thousand different notification IDs which dozens of 'publishers' will issue, to be consumed by countless 'consumers', including multiple kernel drivers.
WNF isn't only an incredible way to gather information on the user and application's behaviors on the system. WNF registrations can be made to 'persist' across system reboots, and interesting persistence can be achieved through this obscure mechanism, especially given the User/Kernel boundary crossing. And each WNF registration is fully securable by the standard Windows security descriptor model -- and like standard securable entities, not all descriptors are configured in their most optimal way.
Notifications, by the way, are not merely 'signaled events' indicating something has happened. Each notification can contain a payload of up to 4KB of data, and consumers will often parse that data (sometimes incorrectly/too-trustingly) as part of receiving the signal. This means that outside of a useful way of snooping/faking behaviors by messing with what consumers 'trust' from their producers, payload data itself can be manipulated/fuzzed to cause parsing bugs (including in kernel consumers). Furthermore, once posted, payload data persists, such that a malicious reader could obtain interesting data from someone else's notification (including sometimes, uninitialized buffers containing pointers and other private heap data). Such payload data can even persist across reboots for permanent WNF notifications.
On top of all of these interesting uses cases, all of Windows' 'hidden' features that are A/B tested in preview builds (aka the 'velocity flags') are also implemented behind WNF. A 4KB WNF blob is used to encode which A/B testable velocity flags are enabled for a particular install, and playing with WNF can unlock new Windows behaviors (or disable them) months ahead of official release.
WNF is *not* merely a layer built upon ETW, or ALPC, or any other kernel mechanism you're likely to be familiar with -- it's a completely internal mechanism not exposed through the object manager or any other existing API, available only through a set of undocumented NT system calls (and even more undocumented Kernel32/NTDLL library wrappers). Your Next Gen EDR tools, ETW Sysmon logging tools, super Windows Defender All The Guard ATP Edition tools, and forensic debugger tools have no visibility into it, and attackers might be using it behind your back. As part of this talk, three initial WNF exploitation, fuzzing, and forensic tools will be released to tip the scales for the blue team, after 6 years of kernel obscurity.
Alex Ionescu is the Vice President of EDR Strategy at CrowdStrike, Inc., where he started as its Chief Architect almost six years ago. Alex is a world-class security architect and consultant expert in low-level system software, kernel development, security training, and reverse engineering. He is coauthor of the last three editions of the Windows Internals series, along with Mark Russinovich and David Solomon. His work has led to the fixing of many critical kernel vulnerabilities, as well as over a few dozen non-security bugs. Previously, Alex was the lead kernel developer for ReactOS, an open source Windows clone written from scratch, for which he wrote most of the Windows NT- based subsystems. During his studies in Computer Science, Alex worked at Apple on the iOS kernel, boot loader, and drivers on the original core platform team behind the iPhone, iPad and AppleTV. Alex is also the founder of Winsider Seminars & Solutions Inc., a company that specializes in low- level system software, reverse engineering and security trainings for various institutions.
Gabrielle Viala is a security engineer at Quarkslab focused on Windows Internals. After working as a pentester for several years, she shifted in reverse engineering, where she found a great topic of interest - the Windows kernel. She is part of the BlackHoodie from the very first edition and belong to the organization crew. She also contributes as a speaker and trainer during not just Blackhoodie but also other security related events. She is still far from being an expert, still she works hard to show the newcomers that playing with the kernel might actually be pretty fun.