deathshotxd/0xcr0sscrushRecherche Windows BYOVD sur DCRCVDrv.sys et Alinubx.sys, rétro-ingénierie de leurs primitives noyau, surfaces IOCTL et opportunités de détection.
Deux pilotes signés. Une primitive noyau dangereuse. 0xCr0ssCrush est un projet de recherche Windows BYOVD couvrant les pilotes DCRCVDrv.sys et Alinubx.sys abusés par le loader malware-as-a-service Cruciferra : leurs interfaces, leurs primitives noyau, leur provenance, et comment les détecter et se défendre contre leur abus.
Un harnais de recherche et un package d'analyse pour deux pilotes signés vulnérables :
Le dépôt reproduit la propre tactique de redondance des opérateurs : si un pilote est refusé par l'hôte, le harnais se rabat sur l'autre.
Les deux pilotes ont été documentés par le Threat Response Unit d'eSentire en août 2026 comme composants du loader malware-as-a-service Cruciferra, qui termine les processus AV/EDR avant la livraison de la charge utile. Ce ne sont pas des primitives hypothétiques - elles sont abusées en conditions réelles, elles sont signées, et aucun des deux fichiers n'était présent dans la blocklist de pilotes vulnérables appliquée par Microsoft au moment de cette recherche.
Exécution en laboratoire contrôlé : sélection du pilote, validation du hash, résolution de la cible, et le chemin IOCTL de terminaison sur un hôte de laboratoire Windows 11. Voir docs/reproduction.md pour la procédure exacte.
0xCr0ssCrush ne revendique pas la découverte des pilotes vulnérables sous-jacents. Sa contribution est une implémentation de recherche comparative reproductible couvrant deux pilotes Windows signés récemment abusés, leurs interfaces exposées, leurs primitives noyau, leur provenance, leur comportement environnemental et les opportunités de détection défensive.
Aucune implémentation indexée publiquement correspondant aux deux interfaces de pilotes n'a été identifiée durant notre recherche.
Le soutien indépendant des conclusions :
Matrice complète et surface IOCTL dans docs/ioctl-reference.md.
Pilote signé de MOCOMSYS (DCRC) portant des chaînes de callout WFP et un
moniteur de processus enfant. Le device exposé \\.\DCRCVDRV_U accepte un
IOCTL de terminaison depuis le mode utilisateur. Analyse :
\\.\DCRCVDRV_U0x2205C0Détails dans docs/dcrcv-analysis.md.
Pilote signé de CnCrypt avec des chaînes de callout WFP/ALE. Le device
exposé \\.\Alinubx accepte un IOCTL de terminaison prenant un PID et un
statut de sortie.
\\.\Alinubx0x222024{ pid: DWORD, exit_status: DWORD }Détails dans docs/alinubx-analysis.md.
Les deux pilotes exposent la même famille de primitives :
primitive_family: PROCESS_CONTROL
primitive: PROCESS_TERMINATION
La classification lisible par machine se trouve dans metadata/drivers.json afin que des pilotes supplémentaires puissent être ajoutés sans restructurer le dépôt.
L'analyse complète du dispatch (y compris la surface supplémentaire observée de DCRCVDrv.sys) se trouve dans docs/ioctl-reference.md.
Chaque affirmation de l'écrit porte une étiquette de preuve :
[CONFIRMED] directement établi à partir du code/désassemblage
[CORROBORATED] observé ici et soutenu indépendamment
[INFERRED] probable mais non entièrement prouvé
[UNRESOLVED] preuves actuelles insuffisantes
Des extraits de désassemblage annotés (capture d'imports, dispatch IOCTL, helper de terminaison, chaînes) sont inclus sous analysis/ afin que l'analyse puisse être re-parcourue.
Compiler, puis ne jamais charger un pilote sans validation du hash - le harnais lui-même l'impose :
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
Procédure pas à pas et hygiène de laboratoire dans docs/reproduction.md.
IOCTL accepté et processus arrêté sont deux observations distinctes ; le guide de reproduction rend cela explicite.
Sigma, YARA et conseils de télémétrie :
detection/
|-- sigma/driver_load_win_cruciferra_byovd.yml
|-- yara/cruciferra_drivers.yar
+-- telemetry/README.md
Stratégie de détection dans docs/detection.md.
L'état observé est enregistré par build dans lab/test-matrix et marqué comme Verified / Not tested / Blocked / Unknown. Actuellement vérifié sur Windows 11 24H2 (build 26100) avec HVCI désactivé. Aucune revendication de compatibilité générale n'est faite.
Spécifique au snapshot et reproductible : docs/blocklist-status.md.
Provenance spécifique au hash pour chaque échantillon du dépôt :
metadata/
|-- drivers.json # driver registry
+-- samples.json # sample registry (acquisition, verification)
Validé par rapport à la documentation par scripts/validate_metadata.py. Détails dans 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
Ce projet existe pour la recherche et la défense. Ne chargez ces pilotes que sur des systèmes que vous possédez ou êtes autorisé à tester ; les charger ailleurs est illégal dans la plupart des juridictions. Voir SECURITY.md et THREAT_MODEL.md.