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.