deathshotxd/0xcr0sscrushWindows-BYOVD-Forschung zu DCRCVDrv.sys und Alinubx.sys, Reverse Engineering ihrer Kernel-Primitiven, IOCTL-Oberflächen und Erkennungsmöglichkeiten.
Zwei signierte Treiber. Ein gefährliches Kernel-Primitiv. 0xCr0ssCrush ist ein Windows-BYOVD-Forschungsprojekt, das die von dem Cruciferra-Malware-as-a-Service-Loader missbrauchten Treiber DCRCVDrv.sys und Alinubx.sys behandelt: ihre Schnittstellen, ihre Kernel-Primitive, ihre Herkunft und wie man ihren Missbrauch erkennt und sich dagegen verteidigt.
Ein Forschungsharness und Analysepaket für zwei verwundbare signierte Treiber:
Das Repository reproduziert die eigene Redundanztaktik der Operatoren: Wenn ein Treiber vom Host abgelehnt wird, weicht das Harness auf den anderen aus.
Beide Treiber wurden von eSentires Threat Response Unit im August 2026 als Komponenten des Cruciferra-Malware-as-a-Service- Loaders dokumentiert, der AV/EDR-Prozesse vor der Payload-Auslieferung beendet. Dies sind keine hypothetischen Primitive - sie werden in freier Wildbahn missbraucht, sie sind signiert, und keine der beiden Dateien war zum Zeitpunkt dieser Forschung in Microsofts erzwungener Blockliste für verwundbare Treiber enthalten.
Kontrollierter Laborlauf: Treiberauswahl, Hash-Validierung, Ziel- Auflösung und der Termination-IOCTL-Pfad auf einem Windows-11-Lab-Host. Die genaue Vorgehensweise ist in docs/reproduction.md beschrieben.
0xCr0ssCrush beansprucht nicht die Entdeckung der zugrunde liegenden verwundbaren Treiber. Sein Beitrag ist eine reproduzierbare vergleichende Forschungs- implementierung, die zwei kürzlich missbrauchte signierte Windows-Treiber, ihre exponierten Schnittstellen, Kernel-Primitive, Herkunft, Umgebungsverhalten und defensive Erkennungsmöglichkeiten abdeckt.
Während unserer Forschung wurde keine öffentlich indexierte Implementierung identifiziert, die beiden Treiberschnittstellen entspricht.
Die unabhängige Unterstützung für die Ergebnisse:
Vollständige Matrix und IOCTL-Oberfläche in docs/ioctl-reference.md.
Signierter Treiber von MOCOMSYS (DCRC) mit WFP-Callout-Strings und einem
Kindprozess-Monitor. Das exponierte Gerät \\.\DCRCVDRV_U akzeptiert einen
Termination-IOCTL aus dem User-Mode. Analyse:
\\.\DCRCVDRV_U0x2205C0Details in docs/dcrcv-analysis.md.
Signierter Treiber von CnCrypt mit WFP/ALE-Callout-Strings. Das exponierte
Gerät \\.\Alinubx akzeptiert einen Termination-IOCTL, der eine PID und einen
Exit-Status entgegennimmt.
\\.\Alinubx0x222024{ pid: DWORD, exit_status: DWORD }Details in docs/alinubx-analysis.md.
Beide Treiber exponieren dieselbe Primitiv-Familie:
primitive_family: PROCESS_CONTROL
primitive: PROCESS_TERMINATION
Die maschinenlesbare Klassifizierung befindet sich in metadata/drivers.json, sodass zusätzliche Treiber ohne Umstrukturierung des Repositories hinzugefügt werden können.
Vollständige Dispatch-Analyse (einschließlich der beobachteten zusätzlichen DCRCVDrv.sys-Oberfläche) in docs/ioctl-reference.md.
Jede Behauptung im Writeup trägt ein Evidenz-Label:
[CONFIRMED] direkt aus Code/Disassembly abgeleitet
[CORROBORATED] hier beobachtet und unabhängig gestützt
[INFERRED] wahrscheinlich, aber nicht vollständig bewiesen
[UNRESOLVED] aktuelle Evidenz unzureichend
Annotierte Disassembly-Auszüge (Import-Erfassung, IOCTL-Dispatch, Termination-Helper, Strings) sind unter analysis/ enthalten, sodass die Analyse nachvollzogen werden kann.
Bauen, dann niemals einen Treiber ohne Hash-Validierung laden - das Harness selbst erzwingt dies:
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
Schritt-für-Schritt-Vorgehen und Laborhygiene in docs/reproduction.md.
IOCTL akzeptiert und Prozess gestoppt sind zwei unterschiedliche Beobachtungen; der Reproduktionsleitfaden macht dies explizit.
Sigma-, YARA- und Telemetrie-Leitfaden:
detection/
|-- sigma/driver_load_win_cruciferra_byovd.yml
|-- yara/cruciferra_drivers.yar
+-- telemetry/README.md
Erkennungsstrategie in docs/detection.md.
Der beobachtete Zustand wird pro Build in lab/test-matrix festgehalten und als Verified / Not tested / Blocked / Unknown markiert. Derzeit verifiziert unter Windows 11 24H2 (Build 26100) mit deaktiviertem HVCI. Es werden keine pauschalen Kompatibilitätsaussagen getroffen.
Snapshot-spezifisch und reproduzierbar: docs/blocklist-status.md.
Hash-spezifische Herkunft für jedes Sample im Repository:
metadata/
|-- drivers.json # driver registry
+-- samples.json # sample registry (acquisition, verification)
Validiert gegen die Dokumentation durch scripts/validate_metadata.py. Details in 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
Dieses Projekt existiert für Forschung und Verteidigung. Lade diese Treiber nur auf Systemen, die dir gehören oder die du autorisiert testen darfst; das Laden an anderer Stelle ist in den meisten Rechtsordnungen illegal. Siehe SECURITY.md und THREAT_MODEL.md.