Notable Exploits
The Case Studies index is organized by CVE: one vulnerability, dissected from root cause to patch. That axis answers "what was the bug". It does not answer "who keeps building working escalations out of these bugs, and how do they think about stringing primitives together".
This section is the second axis. It is organized by the exploit developer, and it is focused on the chain: not the single flaw, but the sequence of primitives that turns a standard-user foothold into SYSTEM, and which defenses that sequence walks past. A developer who ships fifteen exploits in six months is not fifteen unrelated bugs. There is a house style, a reused primitive vocabulary, and a way of composing them that repeats. That pattern is worth studying on its own, because it predicts the next exploit better than any single CVE does.
Why chain-first
KernelSight's thesis is that the individual vulnerability is rarely the interesting part. The interesting part is the composition: coerce a privileged component into acting, redirect where it acts, win or remove the timing, then convert the result into a SYSTEM token. The same five-stage shape recurs across wildly different bugs. A developer-centric view makes that shape visible, because you watch one author apply it to Defender, then to a cloud-filter driver, then to a third-party EDR, changing only the coercion and the redirect while the skeleton stays fixed.
Each profile therefore leads with the chain and treats the bugs as interchangeable parts within it.
How these relate to the kernel focus
Most escalations here reach SYSTEM by coercing a privileged user-mode service rather than by corrupting kernel memory directly. That still belongs in KernelSight for two reasons. First, SYSTEM is the trust level a kernel primitive is usually spent to reach, so these chains arrive at the same destination by a different road, and the what a kernel primitive buys you analysis applies to both. Second, several of the chains do route through kernel drivers: cldflt.sys (the Cloud Filter minifilter) and third-party display drivers appear as links in them, and those have their own case studies. Where a chain touches a driver in the corpus, the profile links to it.
Verdict basis
These profiles are graded cited: they are built from public vendor and press analysis (Huntress, Barracuda, Picus, ThreatLocker, LevelBlue, SecurityWeek, BleepingComputer, The Register), not from independent reversing of the exploit binaries. Where a claim rests only on the developer's own statements, it is marked as such. Nothing here is a repro attestation.
Profiles
| Developer | Focus | Signature | Profile |
|---|---|---|---|
| Nightmare-Eclipse | Security-product LPE (Defender, cldflt, third-party EDR) | Composition over novel bugs; coerce-redirect-race-load-bridge; re-wins narrowed patch windows | Read |
| Lazarus / FudModule | Admin-to-kernel, data-only DKOM rootkit | Kernel R/W from a Microsoft-signed driver ("beyond BYOVD"), spent only on kernel data to blind EDR | Read |
These two are deliberate opposites: a user-mode coercion chain versus a kernel-primitive chain. Read together, they bracket what "the way up" to and past SYSTEM actually means. More developers will be added as their bodies of work are dissected.