grisuno/cve-2022-22077CVE-2022-22077 é uma vulnerabilidade de alta gravidade (pontuação CVSS 7.8) que afeta o driver RTCore64.sys distribuído com o MSI Center.
Este documento fornece uma visão geral abrangente do framework de exploração CVE-2022-22077, um sofisticado kit de ataque BYOVD (Bring Your Own Vulnerable Driver) que tem como alvo a vulnerabilidade do driver RTCore64.sys. Este framework demonstra técnicas avançadas de exploração do kernel do Windows para fins educacionais e de pesquisa em segurança.
O material abordado inclui a base técnica da vulnerabilidade, a arquitetura do framework e a integração com o kit de ferramentas mais amplo LazyOwn RedTeam. Para análise detalhada da vulnerabilidade, consulte Análise de Vulnerabilidade. Para detalhes específicos de implementação de componentes individuais, consulte Framework de Exploração.
CVE-2022-22077 é uma vulnerabilidade de alta gravidade (pontuação CVSS 7.8) que afeta o driver RTCore64.sys distribuído com os aplicativos MSI Center e Dragon Center. A vulnerabilidade decorre de interfaces IOCTL expostas que permitem que usuários não privilegiados realizem leituras e gravações arbitrárias de memória física, contornando efetivamente todos os mecanismos de segurança do kernel do Windows.
O framework implementa o acesso à memória do kernel através de uma abordagem estruturada usando as vulnerabilidades do driver RTCore64.sys:
Por: grisun0, Arquiteto Chefe do Caos do Kernel & Sussurrador de Drivers em Tempo Parcial - LazyOwn RedTeam
Leitura de 7 min · Publicado às 3:33 AM porque “HVCI? Nunca a conheci.”
“A melhor maneira de possuir um sistema é pedir permissão ao seu próprio driver — educadamente, com IOCTLs.” — grisun0, provavelmente enquanto fazia engenharia reversa do MSI Afterburner de cueca
Vamos pular a parte onde finjo que isso é normal.
Se você está lendo isso, você é:
Bem-vindo ao LazyOwn RedTeam™, onde não contornamos a segurança — nós a convidamos para jantar e depois roubamos sua carteira.
Hoje, apresento a vocês RTCore64.sys — não um driver, não uma ferramenta, mas um exploit de kernel totalmente operacional disfarçado de utilitário para overclock da sua RTX 3090.
E sim — há um truque.
Spoiler: Ainda usa cmd.exe. Spoiler maior: Agora também usa beacon.exe. Spoiler ainda maior: Ambos estão rodando com privilégios NT AUTHORITY\SYSTEM, graças a um driver que achou que “acesso arbitrário à memória do kernel” era um recurso de qualidade de vida.
🕳️ O Que é RTCore64.sys? (Ou: “Como Transformar o MSI Afterburner em um Backdoor Ring 0”) Imagine instalar um driver para ajustar a voltagem da sua GPU… e acidentalmente se dar acesso total de leitura/gravação à memória do kernel.
Isto é CVE-2022–22077 — uma vulnerabilidade tão lindamente imprudente que faz o capcom.sys parecer uma bibliotecária tímida.
Enquanto capcom.sys pedia educadamente para executar seu callback, RTCore64.sys simplesmente entrega as chaves do reino — sem fazer perguntas.
“Aqui está um IOCTL. Escreva qualquer endereço. Leia qualquer valor. Divirta-se.” — MSI, provavelmente
E porque somos profissionais, não usamos DeviceIoControl aleatoriamente. Roubamos tokens SYSTEM, corrigimos estruturas EPROCESS e geramos shells SYSTEM — tudo antes de sua GPU atingir 70°C.
Deixe-me guiá-lo pelos cinco atos deste assalto digital:
Errado.
Enterrado lá dentro está RTCore64.sys — um driver assinado e vulnerável que expõe IOCTLs como:
0x80002048 → Ler memória do kernel 0x8000204c → Escrever memória do kernel Sem validação. Sem verificações de sanidade. Apenas poder puro e sem filtro.
“Por que isolar quando se pode kernel?” — Equipe de Engenharia da MSI, 2019
Basta:
sc create RTCore64 binPath=C:\Windows\Temp\RTCore64.sys type=kernel
sc start RTCore64
Boom. Acesso ao kernel desbloqueado.
Pré-requisito: SeLoadDriverPrivilege (que você já tem, porque você é bom nisso). Bônus: HVCI desabilitado (porque quem precisa de virtualização quando se tem estilo?).
CreateFileW(L"\\.\RTCore64", ...) → Pegue o bilhete dourado. EnumDeviceDrivers() → Encontre a base do ntoskrnl.exe. Analise PsInitialSystemProcess do disco → Obtenha o offset. Leia o EPROCESS do SYSTEM → Roube seu token. Escreva o token no seu próprio processo → Parabéns, você é Deus. CreateProcessW(L"beacon.exe", ...) → Inicie seu payload como SYSTEM. Sem shellcode. Sem cadeias ROP. Apenas pura e simples manipulação de objetos do kernel.
del C:\Windows\Temp\RTCore64.sys
sc delete RTCore64
Poof. Sumiu. Como um fantasma que fez overclock na sua RAM e desapareceu.
tasklist /m mimilib.dll
eventcreate /t INFORMATION /id 1 /l APPLICATION /d “sekurlsa::logonpasswords”
type C:\Windows\System32\mimilsa.log
→ Hashes de Admin de Domínio? Conferido. → Senhas em texto plano? Conferido. → Golden Tickets? Já estão chegando.
RTCore64.sys não é um lobo solitário. É um nó no LazyOwn RedTeam Framework — um ecossistema modular, extensível e ligeiramente desequilibrado de ferramentas ofensivas.
Imagine isto:
Gere shellcode com ShadowLink. Ofusque-o com LazyAddons. Entregue-o via roubo de token do RTCore64.sys. Execute-o como SYSTEM via CreateProcessW. Tudo orquestrado a partir de um C2 que parece um download do Steam. E a melhor parte? É tudo open-source. Porque transparência é a melhor opsec.
👉 Veja em ação (mentalmente, porque não estou filmando isso às 4 AM) brincadeira, pegue a pipoca e assista:
https://www.youtube.com/shorts/V2tqH53LRIw
Sim. Isso é um beacon.exe do Windows:
Gerado via roubo de token do RTCore64.sys Rodando como NT AUTHORITY\SYSTEM Relatando de volta ao seu C2 Tudo enquanto o Gerenciador de Tarefas diz “Parece normal para mim” E nem está rodando como admin. É simplesmente bom assim.
Não sou apenas um red teamer. Sou um red teamer responsável. Então aqui vai inteligência gratuita:
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
}
Procure por:
RTCore64.sys carregado fora de C:\Program Files (x86)\MSI Afterburner
Chamadas DeviceIoControl com 0x80002048 ou 0x8000204c
Mudanças de token de processo de baixo privilégio para SYSTEM
sc create ou sc start direcionados a RTCore64
PsInitialSystemProcess sendo lido da memória do kernel
Se você vir essa combinação?
Você foi RTCore’ado.
Esta ferramenta é disponibilizada apenas para propósitos educacionais e red teaming ético.
Não a use em sistemas que você não possui ou para os quais não tem permissão explícita para testar.
O uso indevido pode resultar em:
Ser demitido Ser processado Sua GPU desenvolver um complexo de divindade A Microsoft revogar a assinatura do seu driver (novamente) Sua mãe perguntar por que você está “hackeando o governo” de novo Não assumo nenhuma responsabilidade. Você está por conta própria, cowboy.
Ferramentas como RTCore64.sys não existem para quebrar sistemas — mas para revelar sua fragilidade.
Para treinar defensores. Para testar a lógica de detecção. Para tornar seu PC gamer o dispositivo mais perigoso da rede.
Então vá em frente. Aprenda. Teste. Quebre coisas (eticamente).
E lembre-se:
A melhor segurança é aquela que faz você questionar se sua placa de vídeo está conspirando contra você.
🔐 grisun0, assinando — de um depurador de kernel, provavelmente dentro da VRAM da sua GPU.
BYOVD Token Impersonation RTCore64.sys Kernel Exploitation Red Teaming LazyOwn
P.S. Se sua GPU começar a fazer overclock sozinha às 3 AM… de nada. 🚀
🔗 CVE-2022-22077 no NVD
🔗 https://www.loldrivers.io/drivers/e32bc3da-4db1-4858-a62c-6fbe4db6afbd/
🔗 https://github.com/grisuno/beacon
🔗 https://github.com/grisuno/LazyOwn/
