Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Project-Onyx — 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. | Kitploit
Strumenti/GitHubGitHub/x-3306/project-onyx
Reverse EngineeringShellcodeSteganografiaCrittografiaCommand and ControlApprendimento e FormazioneRed TeamingSviluppo PayloadSicurezza dell'IA
GitHubx-3306/project-onyx

Project-Onyx

Vedi Repository
115161 mese faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →

Informazioni

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.

Condividi

Banner

Project Onyx

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.

Concetti chiave / AGGIORNAMENTO = Project Onyx v2

  1. AI Decoy (camuffamento comportamentale): Ora Project Onyx incorpora un legittimo modello ONNX di classificazione delle immagini SqueezeNet 1.0 proveniente dal mirror ONNX Model Zoo di Hugging Face. Prima che il modulo heartbeat WebAssembly venga eseguito, l'host esegue ripetuti carichi di lavoro reali di inferenza tensoriale usando onnxruntime di Microsoft. Questo rende l'artefatto ONNX una parte attiva della pipeline, non un file decorativo come il precedente piccolo MLP.
  2. Environmental Keying: Alza notevolmente l'asticella per l'analisi in sandbox e il reverse engineering senza accesso alla macchina target esatta. Le chiavi di decrittazione sono derivate dinamicamente dall'hash SHA-256 del MachineGuid del target, del Volume Serial Number e del SID dell'utente corrente.
  3. Sandboxing WASM: Il payload vero e proprio è compilato in WebAssembly (WASM) ed eseguito interamente in memoria usando l'interprete wasm3. L'applicazione host C++ agisce solo come loader e ponte API, esponendo funzioni host sicure alla sandbox WASM.
  4. ONNX Weight Vault: Il materiale delle chiavi AES-256 necessario per decrittare il modulo heartbeat WebAssembly è incorporato nei bit meno significativi della mantissa dei pesi ONNX float32. L'host estrae questo vault dei pesi dai byte del modello incorporato, lo autentica e solo allora recupera il materiale della chiave demo.
  5. Metadata Vault Fallback: Il vault dei metadati autenticato originale rimane per compatibilità e verifica in fase di build. I nuovi asset preferiscono il vault dei pesi, mentre il vault dei metadati documenta lo stesso materiale protetto in una forma più ispezionabile.
  6. C2 Dead-Drop tramite aggiornamenti del modello in downlink: La pipeline dimostra un canale di comunicazione nascosto che usa gli aggiornamenti dei modelli ONNX. Un operatore può incorporare una direttiva autenticata negli LSB dei pesi che sono cambiati naturalmente durante il fine-tuning. Queste modifiche vengono identificate tramite analisi delta tra il modello aggiornato e il modello di riferimento (base). Per mantenere un ambito PoC sicuro, il runtime accetta strettamente solo le direttive heartbeat_ack e set_status, dimostrando la validità del canale senza abilitare l'esecuzione arbitraria di comandi.

Project Onyx Chain

Altamente raccomandato

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

Disclaimer legale

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.

Struttura del repository

  • 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.

Prerequisiti

Installa questi su Windows prima di compilare:

  • Visual Studio 2022 con sviluppo per desktop in C++.
  • CMake 3.25 o successivo.
  • Python 3.10 o successivo.
  • Rustup e Cargo.
  • Git.

Dipendenze Python:

root@kitploit:~
py -m pip install onnx numpy cryptography

Target Rust:

root@kitploit:~
rustup target add wasm32-unknown-unknown

Build statica di ONNX Runtime

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/Release
  • onnxruntime/build/Windows/Release/vcpkg_installed/x64-windows-static-md/lib

Da una Developer PowerShell per VS 2022, compila ONNX Runtime in questo modo:

root@kitploit:~
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.

Genera gli asset

Ottieni l'hash fingerprint per il dispositivo Windows corrente:

root@kitploit:~
python build.py fingerprint --show-components

Usa la seconda riga stampata come valore --trigger.

Compila il modulo Rust WebAssembly:

root@kitploit:~
cargo build --manifest-path wasm_license_module/Cargo.toml --target wasm32-unknown-unknown --release

Genera assets/model.onnx e assets/license_module.wasm.aes:

root@kitploit:~
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:

root@kitploit:~
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.

Modello ONNX reale

Il carrier predefinito è SqueezeNet 1.0 opset 12:

  • sorgente: onnxmodelzoo/squeezenet1.0-12
  • file: assets/base/squeezenet1.0-12.onnx
  • licenza: Apache-2.0 sulla scheda del modello Hugging Face
  • input: data_0, float[1, 3, 224, 224]
  • output: softmaxout_1, float[1, 1000, 1, 1]
  • dimensione: circa 4,95 MB
  • pesi float32: circa 1,23 milioni

Scarica o verifica il modello base incluso:

root@kitploit:~
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.

C2 Dead-Drop solo heartbeat tramite downlink di aggiornamento del modello

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:

root@kitploit:~
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:

root@kitploit:~
python build.py downlink-verify `
  --trigger "<64-char lowercase fingerprint hash>" `
  --reference-model assets/model.onnx `
  --model assets/downlink_update.onnx

Configurazione Webhook e modello

Puntalo a un artefatto di modello HTTPS grezzo, ad esempio un asset di release pubblico:

root@kitploit:~
$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:

root@kitploit:~
$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:

root@kitploit:~
$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"

IMPORTANTE, per favore leggi: Modello di riferimento, fine-tuning e delta naturali

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.

Build finale

Configura e compila l'eseguibile release:

root@kitploit:~
cmake -S . -B build -G "Visual Studio 17 2022" -A x64
cmake --build build --config Release

L'eseguibile finale è:

root@kitploit:~
build\Release\ProjectOnyx.exe

Controllo opzionale delle dipendenze:

root@kitploit:~
& "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.

Ambito

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]

Project Onyx Daily Trend Project Onyx Weekly Trend

Scarica lo strumento