IOCX

Deterministische, risikofreie IOC-Extraktion für moderne Security-Pipelines

_{Statische IOC-Extraktion aus einer PE-Datei mit der IOCX-CLI}

Offizielles IOCX-Projekt

Dies ist die originale IOCX-Engine für deterministische statische IOC-Extraktion und PE-Analyse. Jegliche anderen Repositorys, die den Namen „iocx“ verwenden, sind nicht mit diesem Projekt verbunden.

Offizielle Links:

• PyPI: https://pypi.org/project/iocx/
• Github: https://github.com/iocx-dev/iocx
• Website: https://iocx.dev/

Warum IOCX wichtig ist

Moderne Malware ist standardmäßig adversativ — fehlerhaft, ausweichend und darauf ausgelegt, naive Extraktoren zu brechen.

• Binär-unbewusste Tools scheitern an fehlerhaften PEs
• Sandboxes sind unsicher und in CI/CD unbrauchbar
• Reproduzierbarkeit ist für automatisierte Pipelines unerlässlich

IOCX wurde für Umgebungen entwickelt, in denen Korrektheit und Determinsmus wirklich zählen.

Die IOCX-Engine

IOCX ist die offizielle statische IOC-Extraktions-Engine — ein deterministisches, binär-bewusstes System, das für DFIR, SOC-Automatisierung, CI/CD-Sicherheit und groß angelegte Threat-Intelligence-Pipelines entwickelt wurde.

Im Gegensatz zu reinen Regex-Extraktoren oder sandbox-abhängigen Tools führt IOCX Folgendes durch:

• reine statische Analyse
• null Ausführungsrisiko
• stabile, deterministische Ausgabe
• adversativ getestete Heuristiken

Es ist eine Kernkomponente des MalX-Labs-Ökosystems für skalierbare, moderne Bedrohungsanalyse.

IOCX in 10 Sekunden ausprobieren

echo "http://malicious.example" | iocx -

Oder eine PE-Datei sicher scannen:

iocx suspicious.exe -a deep

Warum es IOCX gibt

Sicherheitsteams stehen vor drei anhaltenden Problemen:

1. Regex-Extraktoren brechen unter adversativen Eingaben
2. Sandboxing ist unsicher, langsam und für Automatisierung ungeeignet
3. Die meisten IOC-Tools sind inkonsistent, langsam oder erzeugen zwischen Läufen subtil unterschiedliche Ausgaben

IOCX löst dies mit einer deterministischen, rein statischen Engine, die für Automatisierung, Sicherheit und Skalierung entwickelt wurde.

Was IOCX Nicht ist

IOCX ist bewusst nicht:

• eine Sandbox
• ein Tool zur Verhaltensanalyse
• ein Emulator
• eine Anreicherungs-Engine

Es führt niemals nicht vertrauenswürdigen Code aus. Es führt niemals dynamische Analysen durch. Es ist bewusst rein statisch — für Sicherheit, Determinsmus und CI/CD-Kompatibilität.

Design-Philosophie

IOCX ist für die Realitäten moderner Malware entwickelt, nicht für die Annahmen von Legacy-Tools.

1. Determinsmus statt Mehrdeutigkeit

Stabile, reproduzierbare Ausgabe — keine Zufälligkeit, keine Volatilität.

2. Statisch statt dynamisch

Ausführung ist unsicher. Statische Analyse ist vorhersehbar, skalierbar und CI-freundlich.

3. Adversative-Erst-Engineering

Fehlerhafte PEs, korrupte RVAs, feindselige Strings — IOCX behandelt sie als normale Eingaben.

4. Schema-Stabilität als Vertrag

Nachgelagerte Systeme sollten bei Upgrades niemals brechen.

5. Leistung ohne Kompromisse

150–300 MB/s bei Rohtext. 6–15 MB/s bei typischen PEs. Vorhersehbar selbst unter Worst-Case-adversativer Last.

Diese Verpflichtungen stammen aus einer veröffentlichten Forschungsmethodik für die strukturelle PE-Analyse — deterministische Fixture-Konstruktion, Einzel-Anomalie-Disziplin und Windows-Loader-Verhalten als Korrektheits-Orakel. Siehe docs/methodology.md für die vollständige Methodik und paax.dev für die breitere adversative-PE-Taxonomie und kommerzielle Fixture-Suite.

Was IOCX anders macht

Kurz gesagt: IOCX ist für reale adversative Realität gebaut, nicht für idealisierte Eingaben.

Anwendungsfälle

CI/CD & DevSecOps

• Binärdateien vor der Veröffentlichung scannen
• Versehentliche URLs, IPs oder Secrets in Builds erkennen
• Sicherheits-Gates mit null Ausführungsrisiko durchsetzen

SOC & Incident Response

• Indikatoren aus Alerts oder Analysten-Zwischenablage-Text extrahieren
• Malware-Proben sicher ohne Ausführung untersuchen
• IOCs in strukturiertes JSON normalisieren

Threat Intelligence

• Feeds in großem Maßstab verarbeiten
• Unstrukturierte Berichte parsen
• Anreicherungs-Pipelines auf deterministischer Ausgabe aufbauen

Automatisierung & Skripting

• Logs oder Artefakte durch IOCX pipen
• Die Python-API für ETL- oder Batch-Workflows verwenden
• Mit benutzerdefinierten Detektoren erweitern

Leistungsprofile

1. Rohe IOC-Extraktion (Text, Logs, Puffer)

150–300 MB/s anhaltender Durchsatz Schneller Pfad — kein PE-Parsing.

2. Typische PE-Dateien (~39 KB)

• 0.0122 s (typisch)
• 0.0145 s (mit Heuristiken)
• 6–15 MB/s Durchsatz

3. Adversative dichte PE (1,5 MB)

• 0.192 s
• ~7,6 MB/s Durchsatz
• Löst TLS-Anomalien, strukturelle Anomalien, Anti-Debug-Muster aus

4. Vollständige Engine (Nicht-PE)

• 1 MB: 0.038 s

Versions-Highlights

Schnellstart

Installieren

pip install iocx

IOCs aus einer Datei extrahieren

iocx suspicious.exe

Aus Text extrahieren

echo "Visit http://bad.example.com" | iocx -

PE-Analyse aktivieren

iocx suspicious.exe -a

Python-API

from iocx.engine import Engine

engine = Engine()
results = engine.extract("suspicious.exe")
print(results)

Beispielausgabe

IOCX erzeugt strukturiertes, deterministisches JSON, das IOCs, PE-Metadaten, Section-Analyse, Heuristiken und Obfuskations-Indikatoren enthält.

Das folgende Beispiel ist eine gekürzte Ausgabe einer echten adversativen PE-Probe. Es zeigt die Form und Tiefe des Schemas, während die Größe für Dokumentationszwecke handhabbar bleibt.

{
    "file": "heuristic_rich.full.exe",
    "type": "PE",
    "iocs": {
        "urls": ["http://not-a-real-domain.test/payload"],
        "domains": ["example-malware.com"],
        "ips": ["192.0.2.123"],
        "hashes": [
            "abcd1234ef567890abcd1234ef567890",
            "1234567890",
            "3333333333333333"
        ],
        "filepaths": [
            "/usr/src/mingw-w64-11.0.1-3build1/mingw-w64-crt/crt/crtexe.c",
            "/usr/x86_64-w64-mingw32/include",
            "/usr/src/mingw-w64-11.0.1-3build1/mingw-w64-crt/crt/pseudo-reloc.c"
        ]
    },
    "metadata": {
        "file_type": "PE",
        "imports": ["KERNEL32.dll", "msvcrt.dll", "USER32.dll"],
        "sections": [
            ".text", ".data", ".rwx", ".rdata",
            "UPX0", ".pdata", ".xdata", ".tls"
        ],
        "resources": [],
        "resource_strings": [],
        "delayed_imports": [],
        "bound_imports": [],
        "exports": [],
        "signatures": [],
        "has_signature": false,
        "tls": {
            "start_address": 5368758272,
            "end_address": 5368758280,
            "callbacks": 5368754232
        },
        "header": {
            "entry_point": 5088,
            "image_base": 5368709120,
            "machine": "AMD64",
            "subsystem": "Windows GUI"
        },
        "optional_header": {
            "section_alignment": 4096,
            "file_alignment": 512,
            "size_of_image": 155648
        }
    },
    "analysis": {
        "sections": [
            { "name": ".text", "entropy": 5.92 },
            { "name": ".rwx", "entropy": 0 },
            { "name": "UPX0", "entropy": 0.34 },
            { "name": ".rdata", "entropy": 4.03 }
        ],
        "obfuscation": [
            {
                "value": "abnormal_section_layout_virtual_only",
                "category": "obfuscation_hint",
                "metadata": {
                    "section": ".bss",
                    "raw_size": 0,
                    "virtual_size": 384
                }
            }
        ],
        "extended": [
            {
                "value": "summary",
                "category": "pe_metadata",
                "metadata": {
                    "dll_count": 3,
                    "import_count": 45,
                    "resource_count": 0,
                    "has_tls": true,
                    "has_signature": false
                }
            }
        ],
        "heuristics": [
            {
                "value": "packer_suspected",
                "metadata": {
                    "reason": "packer_section_name",
                    "section": "UPX0"
                }
            },
            {
                "value": "anti_debug_heuristic",
                "metadata": {
                    "reason": "anti_debug_api_import",
                    "dll": "kernel32.dll",
                    "function": "CheckRemoteDebuggerPresent"
                }
            },
            {
                "value": "anti_debug_heuristic",
                "metadata": {
                    "reason": "timing_api_import",
                    "dll": "kernel32.dll",
                    "function": "GetTickCount"
                }
            },
            {
                "value": "pe_structure_anomaly",
                "metadata": {
                    "reason": "section_overlaps_headers",
                    "section": ".bss",
                    "raw_address": 0,
                    "size_of_headers": 1536
                }
            },
            {
                "value": "pe_structure_anomaly",
                "metadata": {
                    "reason": "data_directory_overlap",
                    "directory_a": "IMAGE_DIRECTORY_ENTRY_IMPORT",
                    "directory_b": "IMAGE_DIRECTORY_ENTRY_IAT"
                }
            }
        ]
    }
}

Architektur

iocx/
├── examples/
├── docs/
├── tests/
└── iocx
    ├── detectors/
    ├── parsers/
    ├── plugins/
    ├── cli/
    └── analysis/

Plugin-Ökosystem & Erweiterbarkeit

IOCX ist darauf ausgelegt, sicher und vorhersehbar erweitert zu werden. Plugins sind erstklassige Bürger, validiert durch dieselben deterministischen Snapshot-Tests wie die Kern-Engine.

Sie können Folgendes erstellen:

• benutzerdefinierte IOC-Detektoren
• benutzerdefinierte Regex-Regeln
• binär-bewusste Plugins
• interne Heuristiken
• pipeline-spezifische Extraktoren

Siehe:

• docs/specs/overlap-suppression.md
• docs/specs/plugin-authoring-guidelines.md

Ökosystem-Überblick

IOCX ist mehr als eine einzelne Binärdatei — es ist ein modulares Ökosystem:

• Kern-Engine — deterministische IOC-Extraktion + PE-Analyse
• Plugin-System — benutzerdefinierte Detektoren und Analysemodule
• Adversatives Korpus — fehlerhafte PEs, feindselige Strings, Fuzz-Proben
• Snapshot-Test-Framework — gewährleistet deterministische Ausgabe
• Leistungs-Benchmarks — in CI durchgesetzt
• Dokumentations-Suite — Spezifikationen, Verträge und Plugin-Anleitungen

Wer nutzt IOCX?

IOCX wird eingesetzt in:

• DFIR-Teams
• SOC-Automatisierungs-Pipelines
• CI/CD-Sicherheits-Gates
• Threat-Intelligence-Plattformen
• Malware-Forschungslaboren
• Sicherheits-Engineering-Teams

Überall dort, wo Indikatoren sicher, deterministisch und in großem Maßstab extrahiert werden müssen, passt IOCX.

Sicheres Testen (keine Malware erforderlich)

Alle Testproben sind:

• Synthetisch
• Harmlos
• Öffentlich sicher (EICAR, GTUBE)
• Entwickelt, um versehentliche Malware-Handhabung zu vermeiden

Leistungsgarantien

IOCX setzt strenge Leistungsschwellen in CI durch, um sicherzustellen:

• Keine Regex-Backtracking-Staus
• Keine pathologischen Verlangsamungen
• Stabile Leistung über Releases hinweg

Siehe:

• docs/performance.md

Projektidentität & Namensgebung

Der Name IOCX bezieht sich ausschließlich auf die offizielle Engine, die veröffentlicht wird auf:

• PyPI: https://pypi.org/project/iocx/
• GitHub: https://github.com/iocx-dev/iocx

Nicht erlaubt

• Repositorys mit dem Namen iocx
• Tools mit dem Namen „iocx“, die nicht Teil dieses Projekts sind
• Andeutung einer Zugehörigkeit ohne Erlaubnis

Erlaubt

• iocx-<plugin>
• iocx-extension-<name>
• iocx-detector-<feature>

Offizielle IOCX-Repositorys

• Kern-Engine: https://github.com/iocx-dev/iocx
• Plugins-Meta-Repo: https://github.com/iocx-dev/iocx-plugins
• Dokumentation: https://github.com/iocx-dev/iocx/tree/main/docs/specs
• PyPI-Paket: https://pypi.org/project/iocx/

Roadmap

Die IOCX-Entwicklung konzentriert sich auf Stabilität, Erweiterbarkeit und tiefere statische Analyseabdeckung. Die folgenden Punkte repräsentieren laufende Arbeits- und Forschungsbereiche.

• Erweiterte PE-Heuristiken (Delay-Load-Verhalten, strukturelle Anomalien, Relocation-Muster)
• Selektive Unterdrückungsregeln für OSINT-, DFIR- und Threat-Intelligence-Workflows
• ELF- und Mach-O-Metadaten-Extraktion
• Batch-Analysemodus für Multi-Artefakt-Workflows
• YARA-artige Ausgabemodi und Anreicherungs-Hooks
• Binär-agnostische statische Analyse
• Plattformübergreifendes Plugin-Ökosystem
• Sprachbindungen für Rust, Go und Node.js

Mitwirken

Wir begrüßen:

• Neue Detektoren
• Parser-Verbesserungen
• Dokumentations-Updates
• Synthetische adversative Proben

Siehe CONTRIBUTING.md für Richtlinien.

Sicherheit

Wenn Sie ein Sicherheitsproblem entdecken, öffnen Sie kein GitHub-Issue. Befolgen Sie die Anweisungen in SECURITY.md.

Lizenz

MPL-2.0-Lizenz — siehe LICENSE.