PAIT-ONNX-200: Embedded Malicious Binary Artifacts and Polyglots in ONNX Models

Overview

The ONNX (Open Neural Network Exchange) format is widely recognized as the industry standard for cross-platform model interoperability, utilized across Microsoft, Meta, AWS, and NVIDIA Triton inference servers. Built upon Google Protocol Buffers (Protobuf), ONNX is generally considered safer than Python pickle-based formats because it represents neural networks as static computational data graphs rather than executable code scripts.

However, the PAIT-ONNX-200 finding highlights a critical AI supply chain attack vector: Embedded Binary Artifacts and Polyglot Trojans. Threat actors take advantage of the flexible protobuf container structure and external tensor loading capabilities of ONNX to embed fully formed malicious executables (ELF, PE, Mach-O, shellcode), reconnaissance toolkits, or steganographic C2 configurations directly inside the model file.

Technical Mechanics: How Malware Is Concealed in ONNX Structures

An ONNX model consists of a ModelProto root message containing metadata, operator set imports, and a GraphProto detailing nodes, initializers, and tensor values. Adversaries abuse three primary techniques to embed hidden payloads:

1. Protobuf Extra Field Injection & Polyglot Packaging

Because Protocol Buffer parsers ignore unrecognized tag fields by design, an attacker can append or interleave an entire executable binary within the .onnx file without corrupting the mathematical graph. The file remains a 100% valid ONNX model that loads and evaluates predictions smoothly in ONNX Runtime, while simultaneously serving as a valid ELF/PE executable for downstream exploitation scripts.

ONNX File Structure with Polyglot Payload:
├── ONNX ModelProto Header (Valid Magic & Graph)
│   ├── Input Nodes (e.g., float32 [1, 3, 224, 224])
│   ├── Convolutional / Linear Weight Tensors
│   └── Output Nodes
├── Unrecognized Protobuf Extension Buffer:
│   └── [Embedded Payload: 0x7F 'E' 'L' 'F' ... Reverse Shell Binary]
└── Padding & CRC Checksums

2. Abuse of External Data Storage (external_data)

For large language models exceeding 2GB protobuf limits, ONNX supports offloading tensor weights to external binary files via the external_data dictionary. Attackers configure tensor definitions referencing system binaries or drop weaponized .bin files that match operating system library search paths.

3. Custom Operator Binary Hooks (CustomOp)

Attackers define custom runtime operators linked to compiled shared libraries (.so/.dll). When the inference server loads the graph via InferenceSession.register_custom_ops_library(), the shared library executes initialization constructors (__attribute__((constructor))) in root memory.

Key Risk Indicators Flagged Under PAIT-ONNX-200

Eresus Sentinel inspects the internal binary layout and protobuf stream, flagging PAIT-ONNX-200 upon identifying:

• High Shannon entropy clusters ($> 7.8$) in non-weight protobuf fields indicating compressed or encrypted executables.
• Magic byte signatures (\x7fELF, MZ\x90\x00, \xca\xfe\xba\xbe) embedded inside string metadata or trailing bytes.
• External data paths containing relative directory traversal or absolute filesystem targets.
• Unregistered custom operator shared library dependencies.

Threat Matrix & Attack Impact

Code-Level Detection & Sanitization (Python)

To verify the integrity of ONNX models before promotion to production registries, use the following validation script:

import onnx
import math

def scan_onnx_model_for_embedded_payloads(model_path: str):
    # 1. Parse ONNX graph strictly
    model = onnx.load(model_path)
    
    # 2. Check for suspicious magic bytes in raw bytes
    with open(model_path, 'rb') as f:
        raw_bytes = f.read()
        
    signatures = {
        b'\x7fELF': "Embedded Linux ELF Binary",
        b'MZ': "Embedded Windows PE Binary",
        b'\xfe\xed\xfa\xce': "Embedded Mach-O Binary (32-bit)",
        b'\xfe\xed\xfa\xcf': "Embedded Mach-O Binary (64-bit)",
        b'#!/bin/sh': "Embedded Shell Script",
        b'#!/bin/bash': "Embedded Bash Script"
    }
    
    for sig, desc in signatures.items():
        if sig in raw_bytes:
            raise SecurityError(f"PAIT-ONNX-200 Violation: Found {desc} inside {model_path}")
            
    # 3. Validate ONNX Graph Consistency
    onnx.checker.check_model(model)
    print(f"[OK] Model {model_path} is structurally clean.")

Remediation & Operational Hardening

1. Quarantine Flagged ONNX Files: Isolate the artifact and verify model provenance with the creator.
2. Re-export from Source: Never attempt manual file cleaning; re-export the model directly from trusted PyTorch/TensorFlow weights using an internal build pipeline.
3. Enforce Binary Whitelisting: Prevent Triton / ONNX Runtime services from loading unregistered CustomOp shared libraries.
4. Deploy Eresus Sentinel Static Intake: Scan all model files in CI/CD before registry upload.

Frequently Asked Questions

Can an ONNX file harm my computer if I don't execute it as a script?

If the ONNX model uses standard operators, loading it in a standard runtime will not trigger a polyglot binary automatically. However, if accompanying deployment scripts, container entrypoints, or custom operator loaders inspect the file, the hidden binary can be unpacked and executed.

Why do attackers choose ONNX over Pickle for backdoors?

Because security teams often believe "ONNX is safe from code execution" and skip deep artifact inspection, making it an ideal carrier for stealthy supply chain persistence.

Does onnx.checker.check_model() catch embedded binaries?

No. onnx.checker verifies protobuf field typing and graph schema validity; it completely ignores extra data blocks or embedded binary polyglots.