
Evasion EDR avanzata tramite spoofing della telemetria dell'IA e sandboxing WASM. Il Progetto Onyx è una pipeline Red Team PoC progettata per dimostrare tecniche di evasione avanzate contro i moderni sistemi EDR. Si distacca dall'offuscamento tradizionale basato su firme per orientarsi verso il mimetismo comportamentale e uno stretto keying ambientale.

Evasione EDR avanzata tramite spoofing della telemetria AI e sandboxing WASM. Project Onyx è una pipeline Red Team PoC progettata per dimostrare tecniche di evasione avanzate contro i moderni sistemi EDR. Si allontana dall'offuscamento tradizionale basato su firme per puntare su camuffamento comportamentale e keying ambientale rigoroso.
Questo progetto è una ricerca red team proof-of-concept, che studia una pipeline di esecuzione multistrato non convenzionale. L'architettura combina cinque tecniche distinte: camuffamento della telemetria AI, keying ambientale legato all'hardware, steganografia dei pesi ONNX, sandboxing WebAssembly in memoria e C2 Dead-Drop tramite aggiornamenti del modello in downlink --> in un'unica catena di consegna funzionante.
Project Onyx non sostiene di essere un bypass funzionante dei sistemi EDR in produzione. È uno schizzo architettonico: ogni componente è implementato e funzionante come parte della catena, ma ogni livello richiederebbe una ricerca dedicata per diventare significativo contro le difese reali. Project Onyx va inteso come un punto di partenza strutturato per questo tipo di esplorazione. Il payload runtime è volutamente limitato a un beacon heartbeat, consentendo di esaminare l'intera pipeline senza includere comportamenti distruttivi o post-exploitation.
onnxruntime di Microsoft. Questo rende l'artefatto ONNX una parte attiva della pipeline, non un file decorativo come il precedente piccolo MLP.MachineGuid del target, del Volume Serial Number e del SID dell'utente corrente.wasm3. L'applicazione host C++ agisce solo come loader e ponte API, esponendo funzioni host sicure alla sandbox WASM.float32. L'host estrae questo vault dei pesi dai byte del modello incorporato, lo autentica e solo allora recupera il materiale della chiave demo.heartbeat_ack e set_status, dimostrando la validità del canale senza abilitare l'esecuzione arbitraria di comandi.
Consulta docs/architecture.md per lo schizzo tecnico completo end-to-end. (Lo consiglio per una migliore comprensione).
e anche l'intero processo: i miei errori, i concetti e le idee che ho considerato lungo il percorso, e i compromessi architetturali che ho affrontato durante la costruzione di Project Onyx --> Medium
Questo progetto è creato esclusivamente a scopo educativo, ricerca sulla sicurezza e operazioni Red Team autorizzate.
Le tecniche dimostrate in questo repository (Project Onyx) hanno lo scopo di aiutare i professionisti della sicurezza a comprendere i metodi di evasione avanzati e a migliorare le difese degli endpoint (EDR/XDR).
Non usare questo software su alcun sistema o rete di cui non sei proprietario o per cui non hai un'autorizzazione esplicita e scritta a testare.
L'autore di questo progetto (X-3306) non si assume alcuna responsabilità e non è responsabile di qualsiasi uso improprio, danno o attività illegale causata dall'uso di questo software. Scaricando, compilando o usando questo codice, accetti di assumerti la piena responsabilità delle tue azioni.
DiagnosticsTool.cpp - Host Windows C++ e integrazione Wasm3/ONNX.DiagnosticsTool.rc / resource.h - binding delle risorse per gli asset generati.build.py - helper per fingerprinting, generazione dell'esca ONNX, embedding del weight vault, compatibilità del metadata vault, C2 Dead-Drop tramite aggiornamenti del modello in downlink e crittografia WASM.wasm_license_module/ - sorgente Rust per il modulo heartbeat WebAssembly.wasm3/source/ - sorgente Wasm3 venduta minima richiesta dalla build CMake.assets/README2.md - formati degli asset generati.docs/architecture.md - note complete sulla catena runtime e sull'architettura.Installa questi su Windows prima di compilare:
Dipendenze Python:
py -m pip install onnx numpy cryptography
Target Rust:
rustup target add wasm32-unknown-unknown
Il file CMake si aspetta un albero sorgente/build di ONNX Runtime in ./onnxruntime e collega le librerie statiche dei componenti da:
onnxruntime/build/Windows/Release/Releaseonnxruntime/build/Windows/Release/vcpkg_installed/x64-windows-static-md/libDa una Developer PowerShell per VS 2022, compila ONNX Runtime in questo modo:
git clone --recursive https://github.com/microsoft/onnxruntime.git onnxruntime
.\onnxruntime\build.bat --config Release --parallel --compile_no_warning_as_error --skip_tests --build_shared_lib --use_vcpkg --cmake_extra_defines VCPKG_TARGET_TRIPLET=x64-windows-static-md onnxruntime_BUILD_UNIT_TESTS=OFF
La onnxruntime.dll generata non viene distribuita con Project Onyx. Project Onyx collega i file .lib statici dei componenti e l'eseguibile finale non dovrebbe elencare onnxruntime.dll in dumpbin /DEPENDENTS.
Ottieni l'hash fingerprint per il dispositivo Windows corrente:
python build.py fingerprint --show-components
Usa la seconda riga stampata come valore --trigger.
Compila il modulo Rust WebAssembly:
cargo build --manifest-path wasm_license_module/Cargo.toml --target wasm32-unknown-unknown --release
Genera assets/model.onnx e assets/license_module.wasm.aes:
python build.py build `
--trigger "<64-char lowercase fingerprint hash>" `
--secret "<exactly-32-demo-key-chars>" `
--model-output assets/model.onnx `
--wasm-input wasm_license_module/target/wasm32-unknown-unknown/release/wasm_license_module.wasm `
--wasm-output assets/license_module.wasm.aes
Verifica i vault ONNX:
python build.py verify --trigger "<64-char lowercase fingerprint hash>" --model assets/model.onnx
Il comando di verifica controlla sia il vault dei metadati legacy sia il vault nascosto dei pesi ONNX. Entrambi devono sbloccare lo stesso materiale della chiave demo di 32 caratteri.
Il carrier predefinito è SqueezeNet 1.0 opset 12:
onnxmodelzoo/squeezenet1.0-12assets/base/squeezenet1.0-12.onnxdata_0, float[1, 3, 224, 224]softmaxout_1, float[1, 1000, 1, 1]Scarica o verifica il modello base incluso:
python build.py fetch-model
build.py build copia questo modello reale, aggiunge i metadati di Project Onyx, incorpora il vault dei pesi ONNX autenticato negli LSB dell'inizializzatore float32 e scrive il modello di riferimento finale in assets/model.onnx.
Il downlink aggiuntivo è un'estensione di ricerca per verificare se un normale aggiornamento del modello ONNX può trasportare un segnale di controllo minuscolo e autenticato come semplice PoC. È volutamente limitato a due direttive sicure:
heartbeat_ack - cambia lo stato heartbeat runtime in heartbeat_ack.set_status - cambia lo stato heartbeat runtime in una stringa sicura scelta dall'operatore, ad esempio lab_downlink_ack.Crea un modello di aggiornamento per il lab:
python build.py downlink-build `
--trigger "<64-char lowercase fingerprint hash>" `
--reference-model assets/model.onnx `
--output assets/downlink_update.onnx `
--command set_status `
--status lab_C2_test `
--expires-unix 4102444800 `
--cover-seed 2026 `
--cover-fraction 0.08 `
--cover-noise-scale 0.00004
Verificalo prima dell'uso:
python build.py downlink-verify `
--trigger "<64-char lowercase fingerprint hash>" `
--reference-model assets/model.onnx `
--model assets/downlink_update.onnx
Puntalo a un artefatto di modello HTTPS grezzo, ad esempio un asset di release pubblico:
$env:PROJECT_ONYX_DOWNLINK_MODEL_URL = "https://huggingface.co/<profile>/<repo>/resolve/main/downlink_update.onnx"
.\build\Release\ProjectOnyx.exe
Oppure usa il webhook Slack/Teams:
Project Onyx non incorpora un URL webhook reale. Per esecuzioni di laboratorio autorizzate, imposta:
La variabile deve essere visibile al processo che avvia ProjectOnyx.exe. Se fai doppio clic sull'eseguibile, impostala prima come variabile d'ambiente utente o di sistema, poi apri un nuovo terminale o riavvia Esplora file ed esegui l'host nativo con un modello di aggiornamento locale:
$env:PROJECT_ONYX_DOWNLINK_MODEL_PATH = "$($PWD.Path)\assets\downlink_update.onnx"; $env:PROJECT_ONYX_SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/..."; .\build\Release\ProjectOnyx.exe
(Puoi usare anche Teams)
Il runtime esegue un solo fetch/lettura all'avvio. Non esegue polling, non persiste, non esegue codice scaricato né elabora comandi arbitrari. Gli aggiornamenti del modello non validi, scaduti, non correlati o non autenticati vengono ignorati.
Parametri di verifica runtime:
$env:PROJECT_ONYX_ONNX_TELEMETRY_PASSES = "24"
$env:PROJECT_ONYX_REQUIRE_ONNX_TELEMETRY = "1"
$env:PROJECT_ONYX_LAB_OUTPUT_PATH = "$($PWD.Path)\assets\lab_heartbeat.json"
PROJECT_ONYX_ONNX_TELEMETRY_PASSES controlla quante inferenze reali di ONNX Runtime vengono eseguite prima che il percorso di sblocco del vault prosegua. PROJECT_ONYX_REQUIRE_ONNX_TELEMETRY=1 trasforma i guasti della telemetria in guasti critici, il che è utile per validare che la fase ONNX non venga saltata. PROJECT_ONYX_LAB_OUTPUT_PATH scrive il JSON heartbeat finale in un file locale per la verifica in laboratorio senza richiedere un webhook.
Questo repository include un modello di riferimento SqueezeNet reale perché è abbastanza piccolo per GitHub pur essendo una rete neurale addestrata legittima. Per un artefatto di ricerca più solido, crea un modello aggiornato tramite un vero fine-tuning o un altro normale processo di manutenzione del modello. L'embedder del downlink può quindi limitare le modifiche ai bit ai pesi che sono già cambiati rispetto al modello di riferimento. Questa è la versione pratica dell'idea "nascondersi nel rumore del fine-tuning", link al side-project completo: https://github.com/X-3306/ONNXStego
Per una rapida validazione in laboratorio, downlink-build può sintetizzare un aggiornamento cover simile a un fine-tuning casuale con seed a partire dal modello di riferimento. Questo dimostra i meccanismi end-to-end e fornisce pesi candidati naturali per il record LSB, MA non sostituisce una valutazione empirica su un compito, un dataset e una procedura di fine-tuning reali.
Configura e compila l'eseguibile release:
cmake -S . -B build -G "Visual Studio 17 2022" -A x64
cmake --build build --config Release
L'eseguibile finale è:
build\Release\ProjectOnyx.exe
Controllo opzionale delle dipendenze:
& "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64\dumpbin.exe" /DEPENDENTS build\Release\ProjectOnyx.exe
Atteso: nessuna dipendenza da onnxruntime.dll.
La demo non include persistenza, escalation dei privilegi, accesso alle credenziali, movimento laterale, esecuzione arbitraria di comandi, comportamenti distruttivi o token webhook privati inclusi. Il modulo WebAssembly è limitato alla formattazione e alla restituzione di un JSON heartbeat come semplice PoC. Il downlink aggiuntivo di aggiornamento del modello può solo modificare quello stato heartbeat tramite la whitelist heartbeat_ack / set_status. Se hai idee interessanti per questo progetto, non esitare a contattare: [email protected]