How Project Onyx Works
Project Onyx is a proof-of-concept red team pipeline designed to explore advanced evasion techniques against modern Endpoint Detection and Response (EDR) systems. Unlike traditional approaches relying on signature-based obfuscation, it employs behavioral camouflage and strict environmental keying to evade detection. The project demonstrates a multi-layer execution pipeline combining five distinct techniques: AI telemetry camouflage, hardware-bound environment keying, ONNX weight steganography, in-memory WebAssembly sandboxing, and Dead-Drop Command and Control (C2) via downlink model updates. Each component is functional but requires further research to achieve meaningful evasion against real-world defenses.
The pipeline is structured as a chain where each layer builds upon the previous one. The runtime payload is intentionally limited to a heartbeat beacon, allowing the full pipeline to be examined without executing destructive or post-exploitation behavior. This design ensures the focus remains on architectural exploration rather than operational impact.
The project is not intended as a working bypass for production EDR systems but serves as a structured starting point for researchers to investigate and improve endpoint defenses.
- AI Decoy (Behavioral Camouflage): The project embeds a legitimate SqueezeNet 1.0 ONNX image-classification model sourced from Hugging Face’s ONNX Model Zoo. Before executing the WebAssembly heartbeat module, the host performs repeated real tensor inference workloads using Microsoft’s ONNX Runtime. This makes the ONNX artifact an active component of the pipeline, distinguishing it from previous approaches that used decorative files like tiny NLP models. The inference workloads generate legitimate AI telemetry, creating a plausible cover for malicious activity.
- Environmental Keying: This technique raises the bar for sandbox analysis and reverse engineering by dynamically deriving decryption keys from the target machine’s unique identifiers. Specifically, the keys are generated using the SHA-256 hash of the target’s MachineGuid, Volume Serial Number, and the current user’s Security Identifier (SID). This ensures the payload can only be decrypted and executed on the intended target machine, making it ineffective in generic sandbox environments.
- WASM Sandboxing: The actual payload is compiled to WebAssembly (WASM) and executed entirely in-memory using the wasm3 interpreter. The host C++ application acts solely as a loader and API bridge, exposing safe host functions to the WASM sandbox. This isolation limits the attack surface and reduces the risk of detection by EDR systems, which may monitor traditional execution environments more closely.
- ONNX Weight Vault: The AES-256 key material required to decrypt the WebAssembly heartbeat module is embedded into the least significant mantissa bits of the float32 ONNX weights. The host extracts this weight vault from the embedded model bytes, authenticates it, and recovers the demo key material only after successful extraction. This method leverages the model’s weights as a covert storage mechanism, making the key material difficult to detect without specialized analysis.
- Metadata Vault Fallback: While the ONNX weight vault is the primary method for storing key material, the project retains a legacy metadata vault for compatibility and build-time verification. This ensures backward compatibility while allowing new assets to prefer the weight vault. Both vaults document the same protected material, with the metadata vault providing a more inspectable form for debugging and verification purposes.
- Dead-Drop C2 via Downlink Model Updates: This technique demonstrates a covert communication channel using ONNX model updates. An operator can embed authenticated directives within the least significant bits of weights that have naturally changed during fine-tuning. These changes are identified via delta analysis between the updated model and the reference model. For the proof-of-concept, the runtime accepts only two safe directives: heartbeatack and setstatus, demonstrating the channel’s viability without enabling arbitrary command execution. This method allows for stealthy communication while maintaining a controlled scope.
The project’s architecture is documented in detail in the docs/architecture.md file, which provides a full end-to-end technical sketch. Additionally, a Medium article by the author outlines the development process, including conceptual ideas, architectural tradeoffs, and lessons learned during the project’s creation.
Use Cases
Project Onyx is primarily intended for educational purposes and authorized red team operations. Its design focuses on demonstrating advanced evasion techniques to help security professionals understand and improve endpoint defenses, particularly those implemented by EDR and Extended Detection and Response (XDR) systems.
Traditional signature-based defenses are increasingly ineffective against sophisticated adversaries, making behavioral camouflage and environmental keying critical areas of research. Project Onyx provides a framework for exploring these techniques in a controlled environment, allowing defenders to test and refine their detection capabilities.
While the project does not claim to bypass production EDR systems, it serves as a valuable tool for red team exercises. Security teams can use Project Onyx to simulate advanced attack scenarios, assess the effectiveness of their detection mechanisms, and identify areas for improvement. The pipeline’s modular design also makes it adaptable for further research, enabling developers to extend or modify individual components to test specific hypotheses.
The Dead-Drop C2 technique, in particular, offers insights into covert communication channels that could be exploited in real-world attacks. By embedding commands within seemingly innocuous model updates, adversaries could establish persistent, hard-to-detect communication channels. Understanding this method allows defenders to develop detection rules for unusual model behavior, such as unexpected weight changes or unauthorized model updates.
Key Features and Capabilities
Project Onyx integrates several advanced techniques to create a cohesive evasion pipeline.
- Multi-Layer Execution Pipeline: The project chains five distinct techniques into a single functional delivery chain. Each layer contributes to the overall evasion strategy, from AI telemetry generation to in-memory execution and covert communication. This layered approach increases the complexity of detection and analysis, as each component must be understood in the context of the others.
- AI Telemetry Camouflage: The use of a legitimate ONNX model for real tensor inference generates AI telemetry that mimics benign activity. This makes it difficult for EDR systems to distinguish malicious behavior from normal operations. The SqueezeNet 1.0 model, with its 4.95 MB size and 1.23 million float32 weights, provides a realistic cover for the payload’s execution.
- This technique significantly complicates reverse engineering and sandbox analysis, as the payload becomes useless without access to the exact target environment. The use of SHA-256 hashing for MachineGuid, Volume Serial Number, and SID adds an additional layer of security.
- In-Memory WASM Execution: The payload is compiled to WebAssembly and executed entirely in-memory using the wasm3 interpreter. This approach isolates the malicious code from the host system, reducing the risk of detection by EDR agents that monitor traditional execution environments. The C++ host application serves as a loader and API bridge, limiting the payload’s interaction with the system.
- Steganographic Key Storage: The AES-256 key material is embedded within the least significant bits of the ONNX model’s float32 weights. This method of steganography ensures that the key material is hidden within an otherwise legitimate file, making it resistant to simple static analysis. The host application extracts and authenticates the key material before proceeding with payload execution.
- Covert Command and Control: The Dead-Drop C2 technique demonstrates how ONNX model updates can carry authenticated directives. By embedding commands within the weights of updated models, adversaries can communicate with compromised systems without raising suspicion. The project limits this functionality to safe directives (heartbeatack and setstatus) to maintain a controlled proof-of-concept scope.
- DiagnosticsTool.cpp: This C++ file serves as the Windows host application, integrating ONNX Runtime and wasm3 for payload execution. It handles the loading of assets, environmental keying, and interaction with the WASM sandbox.
- DiagnosticsTool.rc / resource.h: These files contain resource bindings for generated assets, including the ONNX model and encrypted WASM module.
- build.py: A Python script that automates fingerprinting, ONNX bait generation, weight-vault embedding, metadata-vault compatibility, and Dead-Drop C2 model updates.
- The module is compiled to WASM and encrypted for secure execution within the sandbox.
- wasm3/source/: A minimal vendored source of the wasm3 interpreter, required for in-memory WASM execution.
- docs/architecture.md: Provides a detailed technical sketch of the full runtime chain and architectural notes, including tradeoffs and design decisions.
To build and run Project Onyx, developers must install several prerequisites on a Windows system:
- Visual Studio 2022 with Desktop development with C++ support.
- Python 3.10 or newer, with the following dependencies: onnx, numpy, and cryptography.
- Rustup and Cargo for compiling the WebAssembly module.
- Git for version control and repository management.
Additionally, the project requires a static build of ONNX Runtime, which must be generated from source. The CMake configuration expects the ONNX Runtime source tree at ./onnxruntime and links static component libraries from the build directory. The final executable should not include onnxruntime.dll as a dependency, as it relies on static linking.
The build process involves several steps to generate and verify assets:
- Fingerprinting: The build.py script generates a fingerprint hash for the current Windows device, which is used as a trigger value for environmental keying.
- WASM Module Compilation: The Rust WebAssembly module is built using Cargo, targeting the wasm32-unknown-unknown platform.
- Asset Generation: The build.py script generates the final ONNX model (assets/model.onnx) and encrypted WASM module (assets/licensemodule.wasm.aes). These assets incorporate the embedded key material and are ready for deployment.
- Verification: The verification command checks both the legacy metadata vault and the hidden ONNX weight vault to ensure they unlock the same 32-character demo key material.
The default ONNX model used in Project Onyx is SqueezeNet 1.0, sourced from Hugging Face’s ONNX Model Zoo. This model is selected for its balance of size (4.95 MB) and complexity (1.23 million float32 weights), making it suitable as a carrier for the steganographic payload.
For Dead-Drop C2 functionality, operators can create lab update models using the build.py script. These models embed authenticated directives within the weight updates, allowing for covert communication. The directives are limited to heartbeatack and setstatus to maintain safety within the proof-of-concept scope.
The project emphasizes legal and ethical considerations, stating that it is intended solely for educational purposes, security research, and authorized red team operations. Users are explicitly prohibited from deploying the software on systems they do not own or have explicit permission to test. The author disclaims liability for any misuse, damage, or illegal activities resulting from the use of the project.