Complete Module Catalog

This document provides a comprehensive catalog of all 1190+ modules in IndustrialXPL-Forge, organized by category. Use this as the definitive reference for understanding what modules exist and how to use them.

Introduction

IndustrialXPL-Forge (IXF) modules are Python classes that implement the BaseExploit interface. Each module declares:

• __info__ dictionary with metadata (name, CVE, CVSS, impact level, MITRE techniques)
• run() method — executes the exploit (simulate or live)
• check() method — read-only vulnerability check (optional but recommended)

Modules are organized in a hierarchical path structure under industrialxpl/modules/:

modules/
├── cve/          — CVE-specific exploits (150+ vendors, 486 modules)
├── exploits/     — Protocol exploits and generic exploits (159 modules)
├── creds/        — Default credential testers (34 modules)
├── scanners/     — ICS device scanners (31 modules)
├── assessment/   — Compliance and assessment (18 modules)
└── generic/      — Generic utility modules (12 modules)

How to Search — 10 Examples

# By vendor name
ixf search siemens

# By CVE ID
ixf search CVE-2021-22681

# By protocol
ixf search modbus

# By impact level
ixf search CRITICAL

# By module category
ixf search default_creds

# By exploit type
ixf search dos

# By MITRE technique
ixf search T0836

# By product name
ixf search controllogix

# By technology keyword
ixf search firmware

# By year
ixf search 2024

CVE Modules — All 150+ Vendors

Vendor Summary Table

Protocol Exploit Modules — All 50 Protocols with Module Paths

Scanner Modules — All 31 Scanners

Credential Modules — All 34 Modules

Assessment Modules — All 18

(See Assessment & Compliance for full details)

Malware TTP Modules — All 26

Native Artifacts

IXF ships with these native source files compiled by the PolyExploit Runner:

NSE Scripts — All 8

(See Nmap NSE Scripts for full reference)

Module Statistics

Total modules: 1193
─────────────────────────────────────────────────────────
Category          Count    Percentage
─────────────────────────────────────────────────────────
cve               486      49.8%
exploits          159      16.3%
creds              34       3.5%  (note: some duplicates per vendor)
scanners           31       3.2%
assessment         18       1.8%
generic            12       1.2%
malware_ttps       26       2.7%
others/misc       210      21.5%
─────────────────────────────────────────────────────────
Total            1193      100%

By Impact Level:
CATASTROPHIC      22       2.3%
CRITICAL         128      13.1%
HIGH             312      32.0%
MEDIUM           218      22.3%
LOW               98      10.0%
READ              86       8.8%
INFO              112      11.5%

By MITRE Coverage:
Techniques mapped: 96/103 (93%)
Tactics covered:   12/12 (100%)

MITRE ATT&CK Coverage per Module Category

Extended CVE Coverage by Vendor — Secondary Vendors

Phoenix Contact (6 modules)

Yokogawa (5 modules)

Fanuc (2 modules)

Mitsubishi Electric (3 modules)

LS Electric (1 module)

Delta Electronics — Detailed Breakdown (11 modules)

WAGO (2 modules)

Endress+Hauser (2 modules)

Full Malware Module Reference

Detailed Malware TTP Analysis

Each malware module simulates the specific attack techniques used by real ICS malware, allowing defenders to test their detection and response capabilities.

STUXNET Modules (2)

CRASHOVERRIDE / INDUSTROYER Modules (4)

TRITON / TRISIS Modules (2)

INCONTROLLER / PIPEDREAM Modules (5)

Complete Module Usage Examples

Loading any module from the catalog

# Protocol exploit example
ixf > use exploits/protocols/dnp3/dnp3_direct_operate
ixf > set target 10.0.0.101
ixf > set outstation_addr 10
ixf > set trip_close LATCH_ON
ixf > run

# Scanner example
ixf > use scanners/ics/bacnet_scanner
ixf > set target 192.168.100.0/24
ixf > set threads 10
ixf > run

# Malware TTP example
ixf > use malware/industroyer/industroyer_iec104_exec
ixf > show info
ixf > set target 10.0.0.20
ixf > run

Batch module execution

# Run a list of modules non-interactively
for module in \
  "use scanners/ics/modbus_scanner set target 192.168.1.0/24 run" \
  "use scanners/ics/s7_comm_scanner set target 192.168.1.50 run" \
  "use scanners/ics/enip_scanner set target 192.168.1.0/24 run"; do
  ixf $module
done

Using search to find modules by technique

ixf > search T0836
[*] Search results for: T0836
    use exploits/protocols/modbus/modbus_write_register
    use exploits/protocols/modbus/modbus_unauthorized_coil_set
    use exploits/protocols/s7comm/s7_write_memory
    use exploits/protocols/dnp3/dnp3_analog_output
    use exploits/protocols/iec104/iec104_command_injection
    use assessment/mitre_ics/t0836_modify_parameter
    use malware/stuxnet/stuxnet_s7_rootkit
    ... (18 results)

Finding all CRITICAL modules

ixf > search CRITICAL
[*] Filtering by severity: CRITICAL (241 modules)
    use cve/schneider/cve_2018_7789_modicon_auth_bypass   CVSS 9.8
    use cve/rockwell/cve_2022_1161_controllogix_firmware  CVSS 9.8
    use cve/siemens/cve_2021_22681_s7_1200_hardcoded_key  CVSS 9.8
    ... (238 more CRITICAL modules)

Module Development Quick Reference

Adding a new CVE module

# File: industrialxpl/modules/cve/newvendor/cve_2024_XXXXX_product_vuln.py

from industrialxpl.core.exploit.base import BaseExploit
from industrialxpl.core.exploit.options import OptString, OptInt, OptBool

__info__ = {
    "name": "CVE-2024-XXXXX NewVendor Product Vulnerability",
    "description": "Description of the vulnerability and impact",
    "authors": ("Andre Henrique (mrhenrike)",),
    "impact": "CRITICAL",
    "exploit_type": "Remote Code Execution",
    "cve": "CVE-2024-XXXXX",
    "cvss": 9.8,
    "mitre_techniques": ["T0855", "T0866"],
    "mitre_tactics": ["Execution"],
    "references": ["https://nvd.nist.gov/vuln/detail/CVE-2024-XXXXX"],
    "tags": ["newvendor", "rce", "critical"],
}

class Module(BaseExploit):
    def setup(self):
        self.add_option(OptString("target", required=True, description="Target IP"))
        self.add_option(OptInt("port", default=443, description="HTTPS port"))
        self.add_option(OptBool("simulate", default=True))
        self.add_option(OptBool("destructive", default=False))

    def run(self):
        target = self.get_option("target")
        if self.get_option("simulate"):
            self.print_simulate_header()
            print(f"  Step 1: Connect to https://{target}:{self.get_option('port')}")
            print(f"  Step 2: Send malformed request to /vulnerable/endpoint")
            print(f"  Step 3: Trigger RCE via [mechanism]")
            self.print_mitre()
        else:
            # live execution code
            pass

Adding a new scanner module

# File: industrialxpl/modules/scanners/ics/newprotocol_detect.py

from industrialxpl.core.exploit.base import BaseScanner
from industrialxpl.core.exploit.options import OptString, OptInt

__info__ = {
    "name": "NewProtocol Device Detect",
    "description": "Detect NewProtocol-speaking devices on the network",
    "authors": ("Andre Henrique (mrhenrike)",),
    "impact": "LOW",
    "exploit_type": "Service Detection",
    "cve": "N/A",
    "mitre_techniques": ["T0888"],
    "tags": ["scanner", "newprotocol", "discovery"],
}

class Module(BaseScanner):
    def setup(self):
        self.add_option(OptString("target", required=True))
        self.add_option(OptInt("port", default=9999))

    def run(self):
        target = self.get_option("target")
        port = self.get_option("port")
        # Detection logic
        pass

Quick Reference: Searching the Catalog

Search patterns

Module info shortcuts

# View all options for loaded module
ixf (module) > show options

# View full metadata
ixf (module) > show info

# View MITRE mapping only
ixf (module) > show mitre

# View references and CVE details
ixf (module) > show refs

# Check connectivity without running exploit
ixf (module) > check

Complete CVE ID Cross-Reference (Selected Highlights)

Module Index Verification

After installation, verify the full module index is intact:

# Quick count
python -c "
from industrialxpl.core.exploit.utils import index_modules
mods = index_modules()
print(f'Total: {len(mods)} modules')

# Count by category
from collections import Counter
cats = Counter(m.split('/')[0] for m in mods)
for cat, count in sorted(cats.items(), key=lambda x: -x[1]):
    print(f'  {cat:30s} {count:4d}')
"

Expected output:

Total: 1193 modules
  cve                              814
  exploits                         102
  scanners                          31
  creds                             34
  assessment                        18
  malware                           26
  nse                                8  (NSE wrappers)

If the count differs, reinstall:

pip install --force-reinstall industrialxpl-forge
python tools/env_doctor.py

Vendor CVE Module Details — Additional Vendors

Prosoft Technology (2 modules)

Red Lion Controls (1 module)

Opto22 (1 module)

Schweitzer Engineering (SEL) — 4 modules

Landis+Gyr (2 modules)

WEG Brazil (2 modules)

Elipse Software Brazil (2 modules)

Cisco Industrial (3 modules)

Protocol Exploit Modules — Remaining Catalog

Additional Modbus Variants

Additional DNP3 Variants

Additional OPC UA Variants

Additional IEC 61850 Variants

Credential Module Details — Full Credential Lists

creds/generic/http_default — Credentials Tested

creds/generic/snmp_community — Community Strings Tested

Using IXF Modules for Compliance Evidence

Generating Evidence for IEC 62443 Audits

IXF simulate-mode outputs serve as documented evidence that specific attack vectors were tested:

# Run all relevant tests in simulate mode and generate evidence report
ixf assess iec62443/zone_conduit_audit
ixf use exploits/protocols/modbus/modbus_unauthorized_coil_set
ixf set target 192.168.1.100
ixf run    # simulate output documents the attack would succeed without controls
ixf report json    # report contains simulate output as evidence

The JSON report can be attached to IEC 62443 assessment artifacts as evidence that:

• Specific attack vectors were tested
• Controls were (or were not) effective
• MITRE technique coverage was assessed

Generating Evidence for NIST 800-82 Audits

# Run full NIST checklist and export
ixf assess nist_sp800_82/control_checklist
ixf assess network/ics_firewall_audit
ixf report markdown    # human-readable for audit documentation

Generating a Penetration Test Report

# Full pentest workflow with report
ixf mitre-scan 192.168.1.0/24          # Phase 1: discovery
ixf assess risk/ics_risk_scorer         # Phase 2: risk scoring
ixf assess iec62443/zone_conduit_audit  # Phase 3: compliance
ixf report html                         # Generate HTML pentest report
ixf report json                         # Machine-readable output for ticketing
ixf report navigator                    # MITRE Navigator layer for visualization

Frequently Asked Questions — Module Catalog

How many modules target Modbus-based systems?

Over 200 modules interact with Modbus in some way: the 10 Modbus-specific protocol exploit modules, the 2 Modbus scanners, the 34 credential modules (many use HTTP to manage Modbus-accessible devices), and numerous CVE modules targeting devices that use Modbus TCP (Schneider Modicon, Rockwell, generic RTUs).

Can I run all CVE modules against a single target?

Yes, using a custom loop or the mitre-scan command which chains multiple modules:

ixf mitre-scan 192.168.1.100    # runs all technique-mapped modules
ixf ttp T0866 192.168.1.100     # runs all modules for T0866 (Exploitation of Remote Services)

For individual vendor sweeps:

ixf search siemens | grep "use " | while read cmd; do ixf $cmd set target 192.168.1.50 run; done

Are modules safe to run on production systems?

In simulate mode (default): yes, all modules print what they would do without sending packets.

In live mode (set simulate false): use only on authorized test systems. The check command sends a read-only connectivity probe and is generally safe on production.

How often is the module database updated?

New modules are added with each release. Subscribe to GitHub releases for notifications: https://github.com/mrhenrike/IndustrialXPL-Forge/releases

How do I report a missing CVE or vendor?

Open an issue: https://github.com/mrhenrike/IndustrialXPL-Forge/issues with the CVE ID, affected product, and CVSS score.

Module Catalog Summary

Module Update Cadence

New modules are added to IXF on a rolling basis:

Tracking New Modules

# Check IXF changelog for new modules
pip show industrialxpl-forge
# Check PyPI for latest version
pip index versions industrialxpl-forge
# Upgrade to latest
pip install --upgrade industrialxpl-forge
# Check what changed
python -c "
import industrialxpl
print(industrialxpl.__version__)
from industrialxpl.core.exploit.utils import index_modules
m = index_modules()
print(f'Modules in installed version: {len(m)}')
"

Module Security Policy

All modules in the IXF catalog comply with the following policies:

1. No real credentials — modules never contain actual passwords, API keys, or authentication tokens. Test credentials are from public vendor documentation or public CVE disclosures.

2. Simulate-first — every module MUST have a working simulate=True path before live execution is available. A module that only executes live will not be accepted.

3. Impact accuracy — impact levels must accurately reflect the real-world consequence. Understating impact (e.g., marking CATASTROPHIC as HIGH) is never acceptable.

4. Attribution — malware TTP modules correctly attribute the original threat actor and include references to public reporting.

5. No 0-day — IXF only covers publicly disclosed vulnerabilities with CVE identifiers or well-documented TTPs. No unpublished research or live 0-day exploitation.

6. Physical impact documentation — every CVE module must explicitly state the physical consequence in the simulation output.

7. MITRE accuracy — MITRE ATT&CK for ICS technique mappings must match official ICS ATT&CK matrix definitions (https://attack.mitre.org/matrices/ics/).

Module Changelog

Track major module additions by version:

Getting Help Finding Modules

ixf > help
ixf > stats
ixf > vendors
ixf > protocols
ixf > mitre-list
ixf > search <any keyword>

For module development, see 09-module-development.md. For the assessment workflow, see 12-assessment-compliance.md. For NSE scripts, see 14-nse-scripts.md.

Complete Scanner Module Reference

Scanner Module Options

All scanner modules share a common base set of options. Here is the full options reference using modbus_scanner as a representative example:

ixf > use scanners/ics/modbus_scanner
ixf (Modbus TCP Scanner) > show options

  Options — Modbus TCP Scanner (CIDR Range)
  ═══════════════════════════════════════════════════════════════════════════
  +──────────────────+──────────+──────────+────────────────────────────────────────────────+
  | Option           | Value    | Required | Description                                    |
  +──────────────────+──────────+──────────+────────────────────────────────────────────────+
  | target           |          | yes      | Target IP, hostname, or CIDR range             |
  | port             | 502      | no       | Modbus TCP port (default: 502)                 |
  | unit_id_start    | 1        | no       | Starting unit ID for sweep (1-247)             |
  | unit_id_end      | 10       | no       | Ending unit ID for sweep                       |
  | timeout          | 3        | no       | Per-host connection timeout in seconds         |
  | threads          | 10       | no       | Parallel threads for CIDR scan                |
  | simulate         | True     | no       | Simulate mode (no packets sent)                |
  | output_format    | table    | no       | Output format: table / json / csv              |
  +──────────────────+──────────+──────────+────────────────────────────────────────────────+

ixf (Modbus TCP Scanner) > set target 192.168.1.0/24
[*] target => 192.168.1.0/24

ixf (Modbus TCP Scanner) > set threads 20
[*] threads => 20

ixf (Modbus TCP Scanner) > run

  [SIMULATE MODE — no packets sent]
  Module:  Modbus TCP Scanner — CIDR Range
  Target:  192.168.1.0/24  Threads: 20

  Step 1: Resolve 192.168.1.0/24 to 254 host addresses (192.168.1.1–192.168.1.254)
  Step 2: Spawn 20 threads; each tests up to 13 hosts
  Step 3: Per host: TCP SYN to port 502, timeout 3s
  Step 4: For responsive hosts: send Modbus FC4 (Read Input Registers) probe
  Step 5: Verify MBAP Transaction ID echo in response
  Step 6: For confirmed Modbus devices: sweep unit IDs 1-10
  Step 7: Report all Modbus devices with responding unit IDs

  [i] Live output (example):
      192.168.1.50   port 502  OPEN  Unit 1: Input Register[0]=0x0064  DETECTED
      192.168.1.100  port 502  OPEN  Unit 1: Input Register[0]=0x0032  DETECTED
      192.168.1.100  port 502  OPEN  Unit 2: Input Register[0]=0x0000  DETECTED
      192.168.1.155  port 502  OPEN  Unit 1: no response (non-Modbus service)
  [i] MITRE ATT&CK for ICS: T0888 (Remote System Information Discovery)

Scanner Output Formats

# Table (default) — human readable
ixf use scanners/ics/modbus_scanner set target 192.168.1.0/24 run

# JSON — for parsing and integration
ixf use scanners/ics/modbus_scanner set target 192.168.1.0/24 set output_format json run > scan.json

# CSV — for spreadsheet import
ixf use scanners/ics/modbus_scanner set target 192.168.1.0/24 set output_format csv run > scan.csv

Complete Protocol Exploit Module Reference

Module Severity and MITRE Mapping

Credential Module — Detailed Coverage

Vendor-Specific Credential Database

The IXF credential database contains 34 modules covering the most common default credential exposures in OT environments. Each module tests credentials specific to the vendor's implementation.

Siemens HMI Web Server Default Credentials

ixf > use creds/siemens/siemens_web_hmi_default
ixf > set target 192.168.1.50
ixf > set port 80
ixf > run

  [SIMULATE MODE — no packets sent]
  Module: Siemens SIMATIC HMI Web Server Default Credentials
  Target: http://192.168.1.50:80

  Credential pairs that would be tested:

  Path: /api/jsonrpc (Siemens WinCC Web Navigator)
  +──────────────────────────────────────+────────────────────+
  | Username                             | Password           |
  +──────────────────────────────────────+────────────────────+
  | admin                                | admin              |
  | admin                                | siemens            |
  | service                              | service            |
  | User                                 | (blank)            |
  | Administrator                        | (blank)            |
  | Siemens                              | Siemens            |
  +──────────────────────────────────────+────────────────────+

  [i] HMI web server found on Siemens TP1500, TP700, KP900, SMART panels
  [i] MITRE: T0812 (Default Credentials)

Rockwell FactoryTalk Default Credentials

ixf > use creds/rockwell/factorytalk_default
ixf > set target 192.168.1.110
ixf > run

  [SIMULATE MODE — no packets sent]
  Module: Rockwell FactoryTalk View Default Credentials
  Target: https://192.168.1.110:443

  Credential pairs tested:
  +──────────────────────────────+────────────────────────+──────────────────────+
  | Username                     | Password               | Notes                |
  +──────────────────────────────+────────────────────────+──────────────────────+
  | admin                        | admin                  | Factory default      |
  | ftvse                        | ftvse                  | FTV Site Edition     |
  | Administrator                | (blank)                | Windows admin        |
  | Rockwell                     | (blank)                | Vendor default       |
  | guest                        | (blank)                | Guest account        |
  +──────────────────────────────+────────────────────────+──────────────────────+

Ignition SCADA Default Credentials

ixf > use creds/inductive/ignition_default
ixf > set target 192.168.1.30
ixf > set port 8088
ixf > run

  [SIMULATE MODE — no packets sent]
  Module: Inductive Automation Ignition Gateway Default Credentials
  Target: http://192.168.1.30:8088

  Login endpoint: POST /data/login/default?designMode=0
  +──────────────────────────────+────────────────────────+──────────────────────────────+
  | Username                     | Password               | Notes                        |
  +──────────────────────────────+────────────────────────+──────────────────────────────+
  | admin                        | password               | Ignition factory default     |
  | admin                        | admin                  | Common weak                  |
  | admin                        | ignition               | Product name                 |
  | admin                        | 12345678               | Common numeric               |
  | user                         | user                   | Operator role                |
  +──────────────────────────────+────────────────────────+──────────────────────────────+

  Success detection: HTTP 200 + JSON {"auth_required": false, "user": "admin"}
  [i] Ignition admin access = full SCADA project read/write, OPC UA client, tag database
  [i] MITRE: T0812, T0819, T0866

Module Tagging System

Every module has a tags field in __info__ for faceted search. Common tags used in the IXF catalog:

Searching by tag in IXF

ixf > search sis
[*] Search results for: sis
    use cve/schneider/cve_2021_22763_modicon_cred_bypass  (sis, safety)
    use malware/triton/triton_sic_rewrite                 (sis, safety, critical)
    use malware/triton/triton_safe_state_bypass           (sis, safety, sil)
    use assessment/mitre_ics/t0829_loss_of_protection     (sis, safety)
    ... (8 results)

ixf > search nuclear
[*] Search results for: nuclear
    use cve/westinghouse/cve_2021_33023_common_q_dos     (nuclear)
    use cve/framatome/cve_2022_48192_teleperm_auth       (nuclear)
    ... (3 results)

Module Categories — Detailed Breakdown

CVE Module Sub-categories

CVE modules are organized by the vulnerability type they exploit:

Protocol Exploit Sub-categories

Scanner Sub-categories

IXF Module Naming Convention

All modules follow a consistent naming scheme:

cve/<vendor>/<cve_id>_<product_short>_<vuln_type>.py
exploits/protocols/<protocol>/<protocol>_<action>.py
scanners/ics/<protocol>_<scan_type>.py
creds/<vendor>/<product>_default.py
assessment/<standard>/<check_name>.py
malware/<malware_name>/<component>.py
nse/<script_name>.py

Examples

cve/siemens/cve_2021_22681_s7_1200_hardcoded_key.py
  └─ vendor: siemens
  └─ cve: CVE-2021-22681
  └─ product: s7_1200
  └─ vuln: hardcoded_key

exploits/protocols/modbus/modbus_unauthorized_coil_set.py
  └─ protocol: modbus
  └─ action: unauthorized_coil_set

scanners/ics/s7_comm_scanner.py
  └─ protocol: s7_comm
  └─ scan type: scanner

creds/tridium/niagara_default.py
  └─ vendor: tridium
  └─ product: niagara
  └─ type: default credentials

assessment/iec62443/zone_conduit_audit.py
  └─ standard: iec62443
  └─ check: zone_conduit_audit

malware/industroyer/industroyer2_iec104.py
  └─ malware family: industroyer
  └─ component: industroyer2_iec104

Integration with Third-Party Security Tools

Exporting IXF Results to SIEM

# Export JSON report to file
ixf report json

# Parse findings and send to Splunk HTTP Event Collector
python -c "
import json, requests
with open('./ixf-report-2026-06-01.json') as f:
    report = json.load(f)

for finding in report['findings']:
    event = {
        'sourcetype': 'ixf:finding',
        'event': finding
    }
    requests.post(
        'https://splunk.corp.example.com:8088/services/collector',
        headers={'Authorization': 'Splunk <token>'},
        json=event
    )
"

Integrating with Nozomi Networks / Claroty

IXF simulate-mode output can be used to validate that Claroty/Nozomi/Dragos OT NDR solutions detect the attack patterns:

# 1. Enable NDR detection mode (passive)
# 2. Run IXF in LIVE mode (set simulate false) against test PLC
# 3. Verify NDR alerts were generated
ixf use exploits/protocols/modbus/modbus_unauthorized_coil_set
ixf set target 192.168.1.100     # test PLC only
ixf set simulate false
ixf set destructive true
ixf run    # triggers real Modbus write — NDR should alert

Using IXF in CI/CD for OT Security Regression Testing

# .github/workflows/ot-security-test.yml
name: OT Security Regression Test
on:
  schedule:
    - cron: '0 2 * * 1'  # Weekly, Monday 2am

jobs:
  ot-assessment:
    runs-on: ubuntu-latest
    steps:
      - name: Install IXF
        run: 
        $extras = $args[0].Groups[1].Value
        "pip install industrialxpl-forge$extras"
    

      - name: Run compliance assessment
        run: |
          ixf assess iec62443/zone_conduit_audit
          ixf assess nist_sp800_82/control_checklist
          ixf assess network/ics_firewall_audit
          ixf report json

      - name: Upload report
        uses: actions/upload-artifact@v3
        with:
          name: ot-security-report
          path: ixf-report-*.json

Previous: Assessment & Compliance | Next: NSE Scripts