deathshotxd/0xcr0sscrushInvestigación de BYOVD en Windows sobre DCRCVDrv.sys y Alinubx.sys, ingeniería inversa de sus primitivas de kernel, superficies IOCTL y oportunidades de detección.
Dos controladores firmados. Una primitiva de kernel peligrosa. 0xCr0ssCrush es un proyecto de investigación BYOVD para Windows que abarca los controladores DCRCVDrv.sys y Alinubx.sys abusados por el cargador de malware-como-servicio Cruciferra: sus interfaces, sus primitivas de kernel, su procedencia y cómo detectar y defenderse de su abuso.
Un arnés de investigación y paquete de análisis para dos controladores firmados vulnerables:
El repositorio reproduce la propia táctica de redundancia de los operadores: si un controlador es rechazado por el host, el arnés recurre al otro.
Ambos controladores fueron documentados por el Threat Response Unit de eSentire en agosto de 2026 como componentes del cargador de malware-como-servicio Cruciferra, que termina procesos de AV/EDR antes de la entrega del payload. No son primitivas hipotéticas: se abusan en el mundo real, están firmadas y ninguno de los archivos estaba presente en la lista de bloqueo de controladores vulnerables aplicada por Microsoft en el momento de esta investigación.
Ejecución en laboratorio controlado: selección de controlador, validación de hash, resolución de objetivo y la ruta del IOCTL de terminación en un host de laboratorio con Windows 11. Consulte docs/reproduction.md para el procedimiento exacto.
0xCr0ssCrush no reclama el descubrimiento de los controladores vulnerables subyacentes. Su contribución es una implementación de investigación comparativa reproducible que abarca dos controladores firmados de Windows abusados recientemente, sus interfaces expuestas, primitivas de kernel, procedencia, comportamiento ambiental y oportunidades de detección defensiva.
No se identificó durante nuestra investigación ninguna implementación indexada públicamente que coincida con ambas interfaces de controlador.
El respaldo independiente de los hallazgos:
Matriz completa y superficie de IOCTL en docs/ioctl-reference.md.
Controlador firmado de MOCOMSYS (DCRC) que contiene cadenas de callout de WFP y un
monitor de procesos hijos. El dispositivo expuesto \\.\DCRCVDRV_U acepta un
IOCTL de terminación desde modo usuario. Análisis:
\\.\DCRCVDRV_U0x2205C0Detalles en docs/dcrcv-analysis.md.
Controlador firmado de CnCrypt con cadenas de callout de WFP/ALE. El dispositivo
expuesto \\.\Alinubx acepta un IOCTL de terminación que toma un PID y un
estado de salida.
\\.\Alinubx0x222024{ pid: DWORD, exit_status: DWORD }Detalles en docs/alinubx-analysis.md.
Ambos controladores exponen la misma familia de primitivas:
primitive_family: PROCESS_CONTROL
primitive: PROCESS_TERMINATION
La clasificación legible por máquina se encuentra en metadata/drivers.json para que se puedan añadir controladores adicionales sin reestructurar el repositorio.
El análisis completo del despacho (incluida la superficie adicional observada de DCRCVDrv.sys) está en docs/ioctl-reference.md.
Cada afirmación en el informe lleva una etiqueta de evidencia:
[CONFIRMED] directly established from code/disassembly
[CORROBORATED] observed here and independently supported
[INFERRED] likely but not fully proven
[UNRESOLVED] current evidence insufficient
Los extractos de desensamblado anotados (captura de importaciones, despacho de IOCTL, helper de terminación, cadenas) se incluyen en analysis/ para que el análisis pueda recorrerse de nuevo.
Compile y luego nunca cargue un controlador sin validación de hash: el propio arnés impone esto:
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
El procedimiento paso a paso y la higiene del laboratorio están en docs/reproduction.md.
IOCTL aceptado y proceso detenido son dos observaciones distintas; la guía de reproducción lo deja explícito.
Guía de Sigma, YARA y telemetría:
detection/
|-- sigma/driver_load_win_cruciferra_byovd.yml
|-- yara/cruciferra_drivers.yar
+-- telemetry/README.md
Estrategia de detección en docs/detection.md.
El estado observado se registra por compilación en lab/test-matrix y se marca como Verified / Not tested / Blocked / Unknown. Actualmente verificado en Windows 11 24H2 (compilación 26100) con HVCI deshabilitado. No se hacen afirmaciones de compatibilidad general.
Específico de la instantánea y reproducible: docs/blocklist-status.md.
Procedencia específica por hash para cada muestra en el repositorio:
metadata/
|-- drivers.json # driver registry
+-- samples.json # sample registry (acquisition, verification)
Validado contra la documentación por scripts/validate_metadata.py. Detalles en 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 proyecto existe para la investigación y la defensa. Cargue estos controladores solo en sistemas que posea o esté autorizado a probar; cargarlos en otros lugares es ilegal en la mayoría de las jurisdicciones. Consulte SECURITY.md y THREAT_MODEL.md.