deathshotxd/0xcr0sscrushPesquisa Windows BYOVD sobre DCRCVDrv.sys e Alinubx.sys, engenharia reversa de suas primitivas de kernel, superfícies IOCTL e oportunidades de detecção.
Dois drivers assinados. Uma primitiva de kernel perigosa. 0xCr0ssCrush é um projeto de pesquisa de BYOVD para Windows que abrange os drivers DCRCVDrv.sys e Alinubx.sys abusados pelo loader de malware-como-serviço Cruciferra: suas interfaces, suas primitivas de kernel, sua proveniência e como detectar e defender contra seu abuso.
Um harness de pesquisa e pacote de análise para dois drivers assinados vulneráveis:
O repositório reproduz a própria tática de redundância dos operadores: se um driver for recusado pelo host, o harness recorre ao outro.
Ambos os drivers foram documentados pela Threat Response Unit da eSentire em agosto de 2026 como componentes do loader de malware-como-serviço Cruciferra, que encerra processos de AV/EDR antes da entrega do payload. Estas não são primitivas hipotéticas - são abusadas em campo, são assinadas, e nenhum dos arquivos estava presente na blocklist de drivers vulneráveis aplicada pela Microsoft no momento desta pesquisa.
Execução em laboratório controlado: seleção de driver, validação de hash, resolução de alvo e o caminho do IOCTL de encerramento em um host de laboratório Windows 11. Consulte docs/reproduction.md para o procedimento exato.
O 0xCr0ssCrush não reivindica a descoberta dos drivers vulneráveis subjacentes. Sua contribuição é uma implementação de pesquisa comparativa reproduzível que abrange dois drivers Windows assinados recentemente abusados, suas interfaces expostas, primitivas de kernel, proveniência, comportamento ambiental e oportunidades de detecção defensiva.
Nenhuma implementação publicamente indexada que corresponda a ambas as interfaces de driver foi identificada durante nossa pesquisa.
O suporte independente para as descobertas:
Matriz completa e superfície de IOCTL em docs/ioctl-reference.md.
Driver assinado da MOCOMSYS (DCRC) que carrega strings de callout WFP e um
monitor de processos filhos. O dispositivo exposto \\.\DCRCVDRV_U aceita um
IOCTL de encerramento a partir do modo usuário. Análise:
\\.\DCRCVDRV_U0x2205C0Detalhes em docs/dcrcv-analysis.md.
Driver assinado da CnCrypt com strings de callout WFP/ALE. O dispositivo
exposto \\.\Alinubx aceita um IOCTL de encerramento que recebe um PID e um
status de saída.
\\.\Alinubx0x222024{ pid: DWORD, exit_status: DWORD }Detalhes em docs/alinubx-analysis.md.
Ambos os drivers expõem a mesma família de primitivas:
primitive_family: PROCESS_CONTROL
primitive: PROCESS_TERMINATION
A classificação legível por máquina está em metadata/drivers.json para que drivers adicionais possam ser adicionados sem reestruturar o repositório.
A análise completa de despacho (incluindo a superfície adicional observada do DCRCVDrv.sys) está em docs/ioctl-reference.md.
Cada afirmação no writeup carrega um rótulo de evidência:
[CONFIRMED] directly established from code/disassembly
[CORROBORATED] observed here and independently supported
[INFERRED] likely but not fully proven
[UNRESOLVED] current evidence insufficient
Trechos de disassembly anotados (captura de imports, despacho de IOCTL, helper de encerramento, strings) estão incluídos em analysis/ para que a análise possa ser refeita.
Compile, e nunca carregue um driver sem validação de hash - o próprio harness impõe isso:
cargo build --release --target x86_64-pc-windows-gnu
crosscrush.exe -d -n "notepad.exe" # dry run, no IOCTLs
crosscrush.exe -n "notepad.exe" -k dcrc # single driver
Procedimento passo a passo e higiene de laboratório em docs/reproduction.md.
IOCTL aceito e processo encerrado são duas observações distintas; o guia de reprodução deixa isso explícito.
Sigma, YARA e orientações de telemetria:
detection/
|-- sigma/driver_load_win_cruciferra_byovd.yml
|-- yara/cruciferra_drivers.yar
+-- telemetry/README.md
Estratégia de detecção em docs/detection.md.
O estado observado é registrado por build em lab/test-matrix e marcado como Verified / Not tested / Blocked / Unknown. Atualmente verificado no Windows 11 24H2 (build 26100) com HVCI desabilitado. Nenhuma alegação de compatibilidade irrestrita é feita.
Específico do snapshot e reproduzível: docs/blocklist-status.md.
Proveniência específica por hash para cada amostra no repositório:
metadata/
|-- drivers.json # driver registry
+-- samples.json # sample registry (acquisition, verification)
Validado em relação à documentação por scripts/validate_metadata.py. Detalhes em docs/driver-provenance.md.
|-- README.md / WRITEUP.md / THREAT_MODEL.md / RESEARCH_NOTES.md
|-- CHANGELOG.md / SECURITY.md / LICENSE
|-- docs/ analysis, IOCTL reference, provenance, detection
|-- src/ research harness
|-- analysis/ annotated disassembly artifacts
|-- detection/ sigma / yara / telemetry
|-- lab/ test matrix and manifests
|-- metadata/ machine-readable driver and sample registry
|-- scripts/ metadata validation
+-- .github/ CI and release workflows
Este projeto existe para pesquisa e defesa. Carregue estes drivers apenas em sistemas que você possui ou está autorizado a testar; carregá-los em outros lugares é ilegal na maioria das jurisdições. Consulte SECURITY.md e THREAT_MODEL.md.