
CVE-2022-22077 ist eine Schwachstelle mit hohem Schweregrad (CVSS-Score 7.8), die den RTCore64.sys-Treiber betrifft, der mit MSI Center vertrieben wird.
Dieses Dokument bietet einen umfassenden Überblick über das CVE‑2022‑22077 Exploit‑Framework, ein anspruchsvolles BYOVD (Bring Your Own Vulnerable Driver) Angriffstoolkit, das die Schwachstelle im RTCore64.sys‑Treiber ausnutzt. Das Framework demonstriert fortgeschrittene Windows‑Kernel‑Exploitationstechniken zu Bildungs‑ und Sicherheitsforschungszwecken.
Der behandelte Stoff umfasst die technischen Grundlagen der Schwachstelle, die Architektur des Frameworks sowie die Integration in das breitere LazyOwn RedTeam‑Toolkit. Eine detaillierte Schwachstellenanalyse finden Sie unter Vulnerability Analysis. Spezifische Implementierungsdetails einzelner Komponenten sind im Abschnitt Exploitation Framework beschrieben.
CVE‑2022‑22077 ist eine Schwachstelle mit hohem Schweregrad (CVSS‑Score 7.8), die den mit MSI Center und Dragon Center ausgelieferten Treiber RTCore64.sys betrifft. Die Schwachstelle resultiert aus offengelegten IOCTL‑Schnittstellen, die es unprivilegierten Benutzern ermöglichen, beliebige physische Speicherbereiche zu lesen und zu schreiben – und damit alle Windows‑Kernel‑Sicherheitsmechanismen effektiv zu umgehen.
Das Framework implementiert Kernel‑Speicherzugriff über einen strukturierten Ansatz unter Ausnutzung der Schwachstellen im RTCore64.sys‑Treiber:
Von: grisun0, Chefarchitekt des Kernel‑Chaos & Teilzeit‑Treiberflüsterer – LazyOwn RedTeam
7 min Lesezeit · Veröffentlicht um 3:33 Uhr, weil „HVCI? Nie getroffen.“
„Der beste Weg, ein System zu übernehmen, ist, seinen eigenen Treiber um Erlaubnis zu bitten – höflich, mit IOCTLs.“ — grisun0, wahrscheinlich während des Reverse‑Engineerings von MSI Afterburner in Unterwäsche
Überspringen wir den Teil, in dem ich so tue, als wäre das normal.
Wenn Sie dies lesen, sind Sie entweder:
Willkommen bei LazyOwn RedTeam™, wo wir Sicherheit nicht umgehen – wir laden sie zum Abendessen ein und klauen dann ihr Portemonnaie.
Heute stelle ich Ihnen RTCore64.sys vor – kein Treiber, kein Tool, sondern ein voll funktionsfähiger Kernel‑Exploit, getarnt als Dienstprogramm zum Übertakten Ihrer RTX 3090.
Und ja – es gibt eine Wendung.
Spoiler: Es verwendet immer noch cmd.exe. Größerer Spoiler: Jetzt verwendet es auch beacon.exe. Noch größerer Spoiler: Beide laufen jetzt mit NT AUTHORITY\SYSTEM‑Rechten, dank eines Treibers, der dachte, „beliebiger Kernel‑Speicherzugriff“ sei ein Komfortmerkmal.
🕳️ Was ist RTCore64.sys? (Oder: „Wie man MSI Afterburner in eine Ring‑0‑Hintertür verwandelt“) Stellen Sie sich vor, Sie installieren einen Treiber, um Ihre GPU‑Spannung zu optimieren ... und geben sich dabei versehentlich vollen Lese‑/Schreibzugriff auf den Kernel‑Speicher.
Das ist CVE‑2022‑22077 – eine Schwachstelle, die so wunderbar rücksichtslos ist, dass capcom.sys im Vergleich wie eine schüchterne Bibliothekarin wirkt.
Während capcom.sys brav um Ausführung Ihres Callbacks bat, übergibt RTCore64.sys Ihnen einfach die Schlüssel zum Königreich – ohne Nachfragen.
„Hier ist ein IOCTL. Schreib jede Adresse. Lies jeden Wert. Leg los.“ — MSI, wahrscheinlich
Und weil wir Profis sind, machen wir nicht einfach wahllos DeviceIoControl‑Aufrufe. Wir stehlen SYSTEM‑Tokens, patchen EPROCESS‑Strukturen und spawnen SYSTEM‑Shells – alles bevor Ihre GPU 70°C erreicht.
Lassen Sie mich Sie durch die fünf Akte dieses digitalen Raubzugs führen:
Falsch.
Darin versteckt ist RTCore64.sys – ein signierter, anfälliger Treiber, der IOCTLs wie folgende bereitstellt:
0x80002048 → Kernel‑Speicher lesen 0x8000204c → Kernel‑Speicher schreiben Keine Validierung. Keine Plausibilitätsprüfungen. Nur rohe, ungefilterte Macht.
„Warum Sandbox, wenn man Kernel kann?“ — MSI Engineering Team, 2019
Einfach:
sc create RTCore64 binPath=C:\Windows\Temp\RTCore64.sys type=kernel
sc start RTCore64
Bumm. Kernel‑Zugriff freigeschaltet.
Voraussetzung: SeLoadDriverPrivilege (das Sie bereits haben, weil Sie so gut sind). Bonus: HVCI deaktiviert (denn wer braucht Virtualisierung, wenn man Stil hat?).
CreateFileW(L"\\.\RTCore64", ...) → Holen Sie sich das goldene Ticket. EnumDeviceDrivers() → Finden Sie die ntoskrnl.exe‑Basis. Parsen von PsInitialSystemProcess von der Festplatte → Offset ermitteln. EPROCESS von SYSTEM lesen → Token stehlen. Token in den eigenen Prozess schreiben → Herzlichen Glückwunsch, Sie sind Gott. CreateProcessW(L"beacon.exe", ...) → Starten Sie Ihr Payload als SYSTEM. Kein Shellcode. Keine ROP‑Chains. Nur pure, unverfälschte Kernel‑Objektmanipulation.
del C:\Windows\Temp\RTCore64.sys
sc delete RTCore64
Puff. Weg. Wie ein Geist, der Ihren RAM übertaktet hat und verschwand.
tasklist /m mimilib.dll
eventcreate /t INFORMATION /id 1 /l APPLICATION /d “sekurlsa::logonpasswords”
type C:\Windows\System32\mimilsa.log
→ Domain‑Admin‑Hashes? Check. → Klartextpasswörter? Check. → Golden Tickets? Kommen sofort.
RTCore64.sys ist kein Einzelgänger. Es ist ein Knoten im LazyOwn RedTeam Framework – einem modularen, erweiterbaren und leicht durchgeknallten Ökosystem offensiver Tools.
Stellen Sie sich das vor:
Generieren Sie Shellcode mit ShadowLink. Verschleiern Sie ihn mit LazyAddons. Liefern Sie ihn per RTCore64.sys‑Token‑Diebstahl. Führen Sie ihn als SYSTEM via CreateProcessW aus. Alles orchestriert von einer C2, die wie ein Steam‑Download aussieht. Und das Beste daran? Es ist alles Open‑Source. Denn Transparenz ist die beste OpSec.
👉 Sehen Sie es in Aktion (mental, weil ich das nicht um 4 Uhr morgens filme – nur Spaß, holen Sie sich Popcorn und schauen Sie zu):
https://www.youtube.com/shorts/V2tqH53LRIw
Ja. Das ist ein Windows‑beacon.exe:
Gespawnt via RTCore64.sys‑Token‑Diebstahl Läuft als NT AUTHORITY\SYSTEM Meldet sich zurück zu Ihrer C2 Während der Task-Manager sagt: „Sieht normal aus“ Und es läuft nicht einmal als Administrator. Es ist einfach so gut.
Ich bin nicht nur ein Red Teamer. Ich bin ein verantwortungsvoller Red Teamer. Hier ist kostenloser Geheimdienst:
yara
rule RTCore64_Based_Kernel_Exploit {
meta:
author = “LazyOwn BlueTeam”
description = “Detects RTCore64.sys exploitation via known IOCTLs and patterns”
license = “GPLv3”
strings:
$driver_name = “RTCore64.sys” ascii wide
$ioctl_read = { 80 00 20 48 } // 0x80002048
$ioctl_write = { 80 00 20 4C } // 0x8000204c
$create_device = “CreateFileW” ascii
$device_path = “\\.\RTCore64” ascii wide
$token_steal = “PsInitialSystemProcess” ascii
condition:
all of them
}
Achten Sie auf:
RTCore64.sys geladen außerhalb von C:\Program Files (x86)\MSI Afterburner
DeviceIoControl‑Aufrufe mit 0x80002048 oder 0x8000204c
Prozesstoken‑Wechsel von niedrigen Privilegien zu SYSTEM
sc create oder sc start auf RTCore64
PsInitialSystemProcess wird aus dem Kernel‑Speicher gelesen
Wenn Sie diese Kombination sehen?
Sie wurden gerTCored.
Dieses Tool wird nur für Bildungs‑ und ethische Red‑Teaming‑Zwecke veröffentlicht.
Verwenden Sie es nicht auf Systemen, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Erlaubnis zum Testen haben.
Missbrauch kann zu Folgendem führen:
Kündigung Verklagt werden Ihre GPU entwickelt einen Größenwahn Microsoft widerruft die Signatur Ihres Treibers (schon wieder) Ihre Mutter fragt, warum Sie schon wieder „die Regierung hacken“ Ich übernehme keine Haftung. Sie sind auf sich allein gestellt, Cowboy.
Tools wie RTCore64.sys existieren nicht, um Systeme zu zerstören – sondern um ihre Zerbrechlichkeit aufzuzeigen.
Um Verteidiger zu trainieren. Um Erkennungslogik zu testen. Um Ihren Gaming‑PC zum gefährlichsten Gerät im Netzwerk zu machen.
Also geht hinaus. Lernt. Testet. Zerstört Dinge (ethisch).
Und denkt daran:
Die beste Sicherheit ist die, bei der Sie sich fragen, ob Ihre Grafikkarte etwas gegen Sie plant.
🔐 grisun0, meldet sich ab – aus einem Kernel‑Debugger, wahrscheinlich im VRAM Ihrer GPU.
BYOVD Token‑Imitation RTCore64.sys Kernel‑Exploitation Red Teaming LazyOwn
P.S. Wenn Ihre GPU um 3 Uhr morgens anfängt, sich selbst zu übertakten … gern geschehen. 🚀
🔗 CVE‑2022‑22077 bei NVD
🔗 https://www.loldrivers.io/drivers/e32bc3da-4db1-4858-a62c-6fbe4db6afbd/
🔗 https://github.com/grisuno/beacon