OpenPLC ScadaBR Cross-site Scripting Vulnerability(Update on Active Exploitation)

Targeted Sectors

·         Industrial Control Systems (ICS)

·         Academia

·         Engineering

·         Local government

·         Manufacturing

·         Technology

·         Transportation

·         Utilities sectors

with a focus on systems running vulnerable versions of OpenPLC ScadaBR.

Countries

·         Israel

·         Egypt

BLUF

A known, old cross-site scripting vulnerability in OpenPLC ScadaBR is being actively exploited by hacktivists (TwoNet) to deface HMI login pages and disable logging features.

Date of First Reported Activity

·         The original vulnerability is from 2021

o   New active exploitation evidence led to a CISA KEV listing on November 28, 2025.

Date of Last Reported Activity Update

·         December 2, 2025

CVE-2021-26829

CVSS 3.1 Base Score

·         (5.4) /AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N.

Nessus ID

·         Not publicly listed

Patching/Mitigation Data

·         Affected versions: ScadaBR versions 0.9.1 (Linux) and 1.12.4 (Windows) and earlier.

Mitigation involves applying vendor instructions or discontinuing use. The vulnerability is an open-source issue, the fix is on GitHub.

·         hxxps://github.com/SCADA-LTS/Scada-LTS/pull/3211

 

APT Names: Not attributed to APTs. The activity is linked to a hacktivist group.

Associated Criminal Organization Names: TwoNet (hacktivist group, possibly linked to CyberTroops and OverFlame).

IOCs: Attackers modified system_settings.shtm to display a pop-up message "Hacked by Barlati," and altered settings to disable logs and alarms.

TTPs: T1059.004 (Command and Scripting Interpreter: JavaScript), T1021.001 (Remote Services: RDP), T1595.002 (Active Scanning: Vulnerability Scanning). Attackers focused exclusively on the web application layer.

Malware Names: None specified, the attack involves XSS and configuration changes.

Suggested rules / hunts

These are indicator rules, they are likely to be noisy

Suricata Rule

This Suricata rule looks for suspicious characters commonly used in XSS attacks (like <script> tags or JavaScript event handlers) in the HTTP URI or body when a request is made to the vulnerable ScadaBR component.

 

alert http any any -> $HOME_NET any (msg:"CVE-2021-26829 OpenPLC ScadaBR XSS Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/system_settings.shtm"; nocase; http.body; pcre:"/<(script|alert|prompt|confirm|onload|onerror|onmouseover)[^>]*?>/Ui"; reference:cve,CVE-2021-26829; classtype:attempted-user; sid:12345678; rev:1;)

Notes

·         $HOME_NET should be defined in your Suricata configuration to match your network range.

·         The pcre (Perl Compatible Regular Expression) looks for common XSS payloads in the request body, where the vulnerable parameter is likely located.

·         The sid (signature ID) 12345678 is an example and should be replaced with a unique ID within your environment.

Splunk Hunt Query

This Splunk query searches web server logs (assuming you are ingesting logs from the ScadaBR server or a proxy/IDS) for HTTP POST requests to the vulnerable page containing potential XSS payloads.

 

index=* sourcetype=(access_log OR suricata_eve_ids_attack OR pan_logs OR whatever_your_web_logs_are) (uri_path="/system_settings.shtm" OR uri="/system_settings.shtm") (method="POST") AND (eval(match(_raw, "(?i)<(script|alert|prompt|confirm|onload|onerror|onmouseover)[^>]*?>")))

| table _time, src_ip, dest_ip, uri, http_user_agent, _raw

| sort -_time

Notes:

Adjust index and sourcetype fields to match your environment's log sources.

The eval(match... part looks for the same XSS patterns as the Suricata rule.

This query helps identify the source IP and the exact request that triggered the potential exploitation attempt.

SentinelOne Hunt / Rules

 

Threat Hunting Query (Deep Visibility):

Use the Deep Visibility feature within the SentinelOne console to search for suspicious processes or network connections originating from the ScadaBR server, which might indicate successful exploitation.

sql

·         Search for suspicious process creation or network activity on the ScadaBR host

o   Example focuses on common post-exploitation tools (curl, wget, powershell web requests)

Replace 'ScadaBR_Hostname' with the actual hostname or IP of the affected server

 

EndpointName = 'ScadaBR_Hostname' AND EventType = 'Process Creation' AND (

  ProcessImagePath Contains 'curl.exe' OR

  ProcessImagePath Contains 'wget.exe' OR

  ProcessImagePath Contains 'powershell.exe' AND ProcessCommandLine Contains Anycase ('Invoke-WebRequest', 'Net.WebClient')

)

 

o   Custom Detection Rule (SentinelOne Management Console):

You can create a custom detection rule to flag specific command lines that indicate a potential web-based download or further compromise after the initial XSS is triggered (e.g., if an attacker uses the XSS to force the server or a client to fetch a secondary payload).

Navigate to Detections -> Library -> Custom Rules.

o   Create a rule based on the endpoint query above. This will generate an alert if those specific commands are run on the monitored endpoint

Delivery Method

o   Exploitation of a web application cross-site scripting vulnerability via crafted input to the system_settings.shtm parameter.

Email Samples

Not an email-based campaign.

References

NVD

·         hxxps://nvd.nist.gov/vuln/detail/CVE-2021-26829

GitHub

·         hxxps://github.com/SCADA-LTS/Scada-LTS/pull/3211

CISA KEV List

·         hxxps://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-26829

Previous
Previous

Windows LNK Flaw Campaign (CVE-2025-9491)

Next
Next

Iran-Linked Hackers Deploy New MuddyViper Backdoor