Back to Intelligence

Ecava IntegraXor IGX 16.0.701.10 Remote Code Execution: Defending SCADA/HMI Systems Against a Public PoC

SA
Security Arsenal Team
October 2, 2026
12 min read

A public exploit targeting Ecava IntegraXor (IGX) version 16.0.701.10 has been published on Exploit-DB (entry 52688), detailing a critical remote code execution (RCE) flaw in this widely deployed SCADA/HMI platform. IntegraXor is a web-based HMI/SCADA server used in manufacturing, water treatment, building automation, energy, and other operational technology (OT) environments — precisely the environments where the blast radius of code execution extends beyond IT inconvenience into physical process disruption.

When a working proof-of-concept lands on Exploit-DB, the exploitation clock starts immediately. Copycat attackers, botnet operators, and initial access brokers actively monitor these feeds and operationalize public exploits against internet-exposed instances within hours to days. If your organization — or any of your managed clients — runs IntegraXor IGX 16.0.701.10 anywhere reachable from a business network (or worse, the internet), treat this as an urgent remediation event, not a routine patching ticket.

This post breaks down the exposure from a defender's perspective: what the vulnerable component looks like in your environment, how exploitation manifests in telemetry, and concrete detection content you can deploy today in Sigma, Microsoft Sentinel/Defender, and Velociraptor.

Technical Analysis

Affected Product and Scope

  • Product: Ecava IntegraXor (IGX) — a web-based SCADA/HMI server for Windows
  • Affected version: 16.0.701.10 (per the published exploit; earlier builds in the 16.x line should be assumed vulnerable until confirmed otherwise by the vendor)
  • Component: The IGX web server / server runtime (IntegraXor.exe and its associated service processes), which by default listens on TCP port 7131 (the product's well-known default web port; custom deployments may vary)
  • Impact: Remote code execution with the privileges of the IGX service — frequently SYSTEM or a service account on the HMI/SCADA host, which in OT environments is often also the engineering workstation or OPC aggregation point

How the Attack Works (Defender's View)

The published exploit is a remote exploit against the IGX server component. From a blue-team perspective, the exploitation chain produces a consistent and highly detectable behavioral signature:

  1. Network ingress: An attacker connects to the IGX web service (default TCP 7131) and delivers a crafted request that triggers the code execution condition. Expect anomalous HTTP POST/GET patterns, unusually large request bodies, or requests from sources that have no business talking to an HMI.
  2. Process spawning: Successful exploitation almost universally results in the IGX server process (IntegraXor.exe) spawning child processes — cmd.exe, powershell.exe, wscript.exe, rundll32.exe, or attacker-dropped binaries in temp/public directories. A SCADA HMI server spawning a shell is never legitimate.
  3. Post-exploitation: File drops to world-writable paths (C:\Users\Public\, %TEMP%, the IGX web root), persistence via scheduled tasks or services, and outbound C2 connections from the IGX host — a machine that under normal operation talks to a small, fixed set of PLC/OPC endpoints and operator workstations.

Exploitation Status

  • Public PoC: Confirmed — published on Exploit-DB as exploit ID 52688. Public exploit code dramatically lowers the bar for exploitation and typically precedes opportunistic scanning.
  • Active exploitation: No confirmed in-the-wild campaign is attached to this advisory as of publication, but treat public PoC against internet-exposed ICS software as pre-exploitation — scan your exposure now.
  • CVE / KEV status: No CVE identifier is provided in the source material at this time, and no CISA KEV listing has been tied to this specific flaw as of writing. Do not wait for a CVE or KEV entry to act — ICS advisories routinely lag exploitation, and the PoC is public today.

Why This Matters in OT

IntegraXor deployments commonly sit at Level 2/3 of the Purdue model — supervising PLCs and RTUs. RCE on the HMI host gives an attacker a pivot point toward engineering workstations, historians, and ultimately the control layer. Even if your instance is not internet-facing, lateral movement from a compromised IT asset to an HMI over port 7131 is a realistic and well-trodden path in OT intrusions.

Detection & Response

The most reliable signal for exploitation of a server-side RCE in a product like IGX is the server process doing things a server should never do: spawning shells, scripting engines, or LOLBins. These rules are deliberately narrow — they will not fire on legitimate IGX operation.

YAML
---
title: Ecava IntegraXor IGX Server Spawning Shell or Scripting Process
description: Detects the IntegraXor SCADA/HMI server process spawning command shells, scripting engines, or LOLBins — a strong indicator of remote code execution against the IGX web service (public PoC, Exploit-DB 52688).
references:
  - https://www.exploit-db.com/exploits/52688
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
status: experimental
id: 3f9a2c71-4e8d-4b5a-9c1f-7d2e6a0b8143
tags:
  - attack.execution
  - attack.initial_access
  - attack.t1059
  - attack.t1190
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\IntegraXor.exe'
      - '\IGXServer.exe'
      - '\IGX.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\whoami.exe'
      - '\net.exe'
      - '\net1.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare — legitimate IGX maintenance scripts run interactively by engineers; validate against change windows
level: critical
---
title: File Drop in Ecava IntegraXor Web Root or Public Directories by IGX Process
description: Detects the IntegraXor server process writing executable or script files to web-accessible or world-writable directories, consistent with web shell deployment following RCE against the IGX service.
references:
  - https://www.exploit-db.com/exploits/52688
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
status: experimental
id: 8b1d4e62-9f3a-4c7b-a2e5-1c6d9f034782
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.t1105
logsource:
  category: file_event
  product: windows
detection:
  selection_source:
    Image|endswith:
      - '\IntegraXor.exe'
      - '\IGXServer.exe'
      - '\IGX.exe'
  selection_ext:
    TargetFilename|endswith:
      - '.exe'
      - '.dll'
      - '.bat'
      - '.ps1'
      - '.vbs'
      - '.js'
      - '.aspx'
      - '.asp'
      - '.php'
  selection_path:
    TargetFilename|contains:
      - '\Users\Public\'
      - '\Temp\'
      - '\Windows\Temp\'
      - '\ProgramData\'
      - 'IntegraXor'
  condition: selection_source and selection_ext and selection_path
falsepositives:
  - IGX self-update or installer activity — correlate with authorized patch/upgrade windows
level: high
---
title: Inbound Network Connection to IntegraXor Default Web Port from Non-OT Source
description: Detects inbound connections to the IntegraXor IGX default web service port (TCP 7131) originating outside expected operator/engineering segments, indicating scanning or exploitation attempts against the IGX server.
references:
  - https://www.exploit-db.com/exploits/52688
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
status: experimental
id: 5c2e7a19-6d4b-4f08-b3a1-2e8c5d709164
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 7131
    Initiated: 'true'
    Image|endswith:
      - '\IntegraXor.exe'
      - '\IGXServer.exe'
      - '\IGX.exe'
  condition: selection
falsepositives:
  - Legitimate operator HMI browser sessions — whitelist known operator workstation and engineering subnet IPs at the SIEM layer; any residual hits from outside those ranges are investigative leads
level: high

Microsoft Sentinel / Defender KQL

This hunt looks across process, network, and file telemetry for the exploitation signature. It assumes Defender for Endpoint on the HMI host (strongly recommended for modern HMI deployments where supported by the vendor) and/or Sysmon ingestion via the SecurityEvent/WindowsForwarding pipeline.

KQL — Microsoft Sentinel / Defender
// Hunt 1: IGX server spawning suspicious child processes (RCE indicator)
let IGXProcesses = dynamic(["IntegraXor.exe", "IGXServer.exe", "IGX.exe"]);
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "whoami.exe", "net.exe", "net1.exe", "nltest.exe", "ipconfig.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (IGXProcesses)
| where FileName in~ (SuspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, InitiatingProcessRemoteSessionIPV4Address, ReportId
| sort by TimeGenerated desc;

// Hunt 2: Inbound connections to IGX default port 7131 from unexpected sources
let AllowedSubnets = dynamic(["10.20.30."]); // TODO: replace with your operator/engineering subnets
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where LocalPort == 7131
| where InitiatingProcessFileName in~ (dynamic(["IntegraXor.exe", "IGXServer.exe", "IGX.exe"]))
| extend RemoteIPStr = tostring(RemoteIP)
| where not(RemoteIPStr has_any (AllowedSubnets)) and not(RemoteIPStr startswith "10.") and not(RemoteIPStr startswith "192.168.") and not(RemoteIPStr startswith "172.16.")
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName
| sort by ConnectionCount desc;

// Hunt 3: Executable/script drops attributable to the IGX process
DeviceFileEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ (dynamic(["IntegraXor.exe", "IGXServer.exe", "IGX.exe"]))
| where FileName endswith ".exe" or FileName endswith ".dll" or FileName endswith ".bat" or FileName endswith ".ps1" or FileName endswith ".vbs" or FileName endswith ".js" or FileName endswith ".aspx" or FileName endswith ".php"
| where FolderPath has_any ("\\Users\\Public\\", "\\Temp\\", "\\Windows\\Temp\\", "\\ProgramData\\", "IntegraXor")
| project TimeGenerated, DeviceName, FolderPath, FileName, SHA256, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by TimeGenerated desc;

For environments forwarding IGX host logs via Sysmon/CEF into Sentinel, adapt Hunt 1 against SecurityEvent (Event ID 4688) by filtering ParentProcessName on the IGX binaries. If you ingest network device logs (firewall/zone conduits) into CommonSecurityLog, query for DestinationPort == 7131 with sources outside your OT DMZ — that is often the earliest tripwire for scanning activity against exposed instances.

Velociraptor VQL

Deploy this artifact across suspected or confirmed IGX hosts to identify live exploitation artifacts: rogue child processes of the IGX server and executables in suspicious locations.

VQL — Velociraptor
-- Hunt: Ecava IntegraXor RCE post-exploitation indicators
-- Looks for child processes spawned by the IGX server and file drops in
-- world-writable / web-accessible locations (Exploit-DB 52688 context)

LET proc_hunt = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)cmd\.exe|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|bitsadmin|whoami|net(1)?\.exe'

LET resolved = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       (SELECT Name FROM pslist(pid=proc_hunt.Ppid)) AS ParentInfo
FROM proc_hunt

SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       ParentInfo[0].Name AS ParentName
FROM resolved
WHERE ParentName =~ '(?i)integraxor|igxserver|igx\.exe'

-- Companion file hunt (run separately if desired):
-- SELECT FullPath, Size, Mtime, Ctime FROM glob(globs='C:/Users/Public/**/*.exe')
-- UNION SELECT FullPath, Size, Mtime, Ctime FROM glob(globs='C:/Windows/Temp/*.exe')
-- ORDER BY Mtime DESC

Remediation

Act in this order. In OT environments, compensating controls frequently must precede patching because vendor-validated updates and maintenance windows lag disclosure.

  1. Inventory and isolate immediately. Identify every IntegraXor IGX instance and its version. Any instance on 16.0.701.10 (or unpatched 16.x) must be treated as exposed. Pull the HMI web interface off any internet-facing or general IT network segment today — block inbound TCP 7131 at the zone conduit/firewall from everything except explicitly authorized operator workstations and engineering subnets.

  2. Apply the vendor fix. Contact Ecava support (https://www.ecava.com / https://www.integraxor.com) for the patched build superseding 16.0.701.10. Do not assume the latest public download is fixed — request written confirmation of the fixed version number for this specific flaw, and follow Ecava's upgrade procedure in a test/staging environment first, per standard OT change management.

  3. Hunt before you patch. Patching erases the vulnerability, not the intrusion. Run the Sigma, KQL, and VQL content above across all IGX hosts before remediation. Review firewall logs for historical connections to TCP 7131 from unknown sources going back at least 30–90 days. If you find evidence of exploitation, pivot to IR: isolate the host, capture memory/disk, and assess lateral movement toward PLCs, historians, and engineering workstations.

  4. Harden the service. Run the IGX service under a least-privilege service account rather than SYSTEM where the vendor supports it. Enforce authentication on the web interface, disable any unused IGX web modules, and ensure TLS is configured for operator sessions.

  5. Architectural controls (persistent). HMI/SCADA web interfaces should never be directly internet-reachable. Enforce access through the OT DMZ with an industrial firewall, jump-host/remote-access gateway with MFA, and unidirectional or tightly ACL'd flows toward Level 2. Continuously monitor the conduit for port 7131 traffic anomalies.

The following PowerShell script helps you quickly assess exposure and apply a compensating firewall block on the HMI host while awaiting the vendor patch. Test in your maintenance window; coordinate with operations before restricting HMI access.

PowerShell
# Ecava IntegraXor IGX - Exposure Assessment and Compensating Controls
# Run elevated on the suspected IGX host. Review output before applying blocks.

$ErrorActionPreference = 'Continue'
$report = @()

# 1. Identify installed IntegraXor version
$igx = Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
        HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
        Where-Object { $_.DisplayName -match 'IntegraXor|IGX' } |
        Select-Object DisplayName, DisplayVersion, InstallLocation
if ($igx) {
    $report += "[FOUND] Installed: $($igx.DisplayName) - Version $($igx.DisplayVersion)"
    if ($igx.DisplayVersion -match '16\.0\.701\.10') {
        $report += "[VULNERABLE] Version 16.0.701.10 matches the publicly exploited build."
    }
} else {
    $report += "[INFO] No IntegraXor installation detected via registry uninstall keys."
}

# 2. Check whether the IGX web port is listening and which process owns it
$listeners = Get-NetTCPConnection -State Listen -LocalPort 7131 -ErrorAction SilentlyContinue
foreach ($l in $listeners) {
    $proc = Get-Process -Id $l.OwningProcess -ErrorAction SilentlyContinue
    $report += "[EXPOSED] TCP 7131 LISTENING - Process: $($proc.ProcessName) (PID $($l.OwningProcess)) Path: $($proc.Path)"
}

# 3. Compensating control: restrict TCP 7131 to authorized operator subnet only
#    EDIT $AllowedSubnet before running. Set $ApplyBlock = $true to enforce.
$ApplyBlock   = $false
$AllowedSubnet = '10.20.30.0/24'   # TODO: replace with your operator/engineering subnet

if ($ApplyBlock) {
    New-NetFirewallRule -DisplayName 'IGX-Block-7131-External' -Direction Inbound `
        -Protocol TCP -LocalPort 7131 -Action Block `
        -RemoteAddress Any -Profile Any -ErrorAction SilentlyContinue | Out-Null
    New-NetFirewallRule -DisplayName 'IGX-Allow-7131-Operators' -Direction Inbound `
        -Protocol TCP -LocalPort 7131 -Action Allow `
        -RemoteAddress $AllowedSubnet -Profile Any -ErrorAction SilentlyContinue | Out-Null
    $report += "[ACTION] Firewall rules applied: 7131 allowed only from $AllowedSubnet, blocked otherwise."
    $report += "[ACTION] Verify operator HMI access immediately after applying."
} else {
    $report += "[DRY-RUN] Set `$ApplyBlock = `$true and configure `$AllowedSubnet to enforce the compensating firewall rule."
}

# 4. Recent suspicious child processes of IGX (last 14 days, requires process auditing/Sysmon)
$events = Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-14) } -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match 'IntegraXor\.exe|IGXServer\.exe' -and $_.Message -match 'cmd\.exe|powershell\.exe|wscript\.exe|mshta\.exe|rundll32\.exe|certutil\.exe' } |
    Select-Object TimeCreated, Message -First 25
if ($events) {
    $report += "[ALERT] Suspicious IGX child process events found - escalate to IR:"
    $events | ForEach-Object { $report += ($_.TimeCreated.ToString() + ' :: ' + ($_.Message -split "`n")[0]) }
} else {
    $report += "[INFO] No suspicious IGX child-process events in Security log (or 4688 auditing not enabled)."
}

$report | ForEach-Object { Write-Output $_ }

Bottom Line

Public PoC against a SCADA/HMI web server is a five-alarm event for OT defenders, even without a CVE number or KEV listing attached yet. The detection content above is intentionally tight: an IGX server process spawning a shell, dropping executables, or accepting connections from outside your operator segments is a high-fidelity signal, not noise. Deploy it, hunt with it, and get TCP 7131 behind a fence while you wait on Ecava's patched build. In OT, the network boundary and the behavioral tripwire are your patch until the vendor's patch is validated.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.