OpenAlt 2026

Windows kernel driver běží v Ring 0, tedy na stejné úrovni jako samotné jádro operačního systému. Když takový driver obsahuje zranitelnost, útočník přes ni obejde všechny bezpečnostní hranice, na kterých celý systém stojí.

V tomhle talku ukážu, jak jsem od nuly napsal funkční privilege escalation exploit pro reálný podepsaný Windows driver ktapi.sys, který neprivilegovaným procesům umožňuje libovolný přístup k fyzické paměti. Nezačínám ale exploitem. Nejdřív pořádně rozeberu, jak funguje Windows kernel: ochranné ringy, virtuální a fyzická paměť, překlad adres přes CR3 a čtyři úrovně tabulek stránek. Pak vysvětlím, jak fungují ovladače a proč je jejich podpis a běh v Ring 0 tak citlivý, a jak se na drivery obecně útočí. Teprve s tímhle kontextem má smysl jít do konkrétního případu.

ktapi.sys jsem analyzoval sám, protože žádná veřejná analýza neexistovala. Projdeme reverzní inženýrství ovladače v Ghidře, ruční průchod page tables, překlad virtuálních adres na fyzické, nalezení struktury EPROCESS a krádež SYSTEM tokenu pro eskalaci na NT AUTHORITY\SYSTEM. Skončím funkčním PoC a živou ukázkou.

Celý talk stavím tak, aby dával smysl i bez předchozí zkušenosti s kernel exploitací. Že nejde o akademický problém, ukazuje i to, že zranitelné podepsané ovladače tohohle typu reálně zneužívají ransomware skupiny k vypnutí ochran a eskalaci práv. Na konci se proto podíváme na obranu, konkrétně HVCI, WDAC a LOLDrivers blocklist, a na to, že ani plně aktualizovaný systém nemusí stačit.

Co si odnesete: jak reálně vypadá cesta od reverzního inženýrství podepsaného ovladače k funkčnímu SYSTEM exploitu, jak ransomware skupiny dokážou zneužít podobných chyb a ovládnou systém, proč je podpis ovladače sám o sobě slabá záruka, a jaké obrany proti téhle třídě útoků skutečně fungují.