Key Findings
- Our honeypot caught hacktivist activity targeting a decoy water treatment plant in Sept. 2025.
- A Russian-aligned group, TwoNet, claimed responsibility for the attack.
- The group logged into the human-machine interface (HMI) for: defacement, process disruption, manipulation, and evasion.
- We also discovered additional attacks targeting programmable logic controllers (PLCs) and the Modbus protocol linked to Russia and Iran.
Mitigation Recommendations
- Eliminate weak authentication
- Remove direct internet exposure
- Segment rigorously
- Harden admin interfaces
- Require authentication on all IoT/OT admin interfaces:
- Include web UIs and proprietary engineering ports
- Disable anonymous/default accounts and enforce strong, unique credentials
- Monitor with IoT/OT-aware, deep packet inspection (DPI)
- DPI should have protocol-aware detection (Modbus, S7, etc.) that creates alerts for: exploitation, password guessing, unauthorized writes, and changes in human machine interfaces (HMI).
- Watch for outbound and “dual use”
Part of the threat intelligence we provide to customers and the wider community comes from dedicated honeypots, decoy systems deliberately exposed to the internet to lure attackers and capture their tactics. Last year, one of our honeypots, designed as an AI-generated “healthcare clinic”, attracted cybercriminals who attempted to deploy ransomware.
This time, we observed something even more significant: an emerging pro-Russian hacktivist group targeted our “water treatment utility” honeypot and then falsely claimed responsibility for a real-world attack on their Telegram channel.
In the sections below, we analyze the attack, profile the group and its affiliations, and assess what this activity means for critical infrastructure organizations, particularly utilities. Just as importantly, we explain why honeypot intelligence is increasingly vital as hacktivists expand their focus to operational technology and industrial control systems (OT/ICS).
The Claimed Attack: TwoNet Defaces an HMI and Interferes with the Process
TwoNet’s attack against our honeypot occurred in September, shortly after the group launched its Telegram channel. The figure below summarizes the incident timeline.
The intrusion began at 08:22 AM from IP address 45.157.234[.]199 registered to AS58212 (dataforest GmbH), a German hosting provider. We found no prior malicious activity tied to this address and little history of abuse linked to that provider. Throughout the attack, the adversary’s user-agent was set to:
Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0
This suggests the attackers used Firefox on Linux, though user-agents can easily be spoofed.
The attacker initially logged into the HMI using default credentials (admin/admin). Their first step was to attempt database enumeration with the following SQL queries submitted through the sql.shtm page:
SELECT t.tablename, c.columnname, con.constraintname
FROM sys.systables t
JOIN sys.sysconstraints con ON t.tableid = con.tableid
JOIN sys.syskeys k ON con.constraintid = k.constraintid
JOIN sys.syscolumns c ON k.referenceid = c.referenceid AND k.columnid = c.columnnumber
WHERE con.type = 'P'
ORDER BY t.tablename
SELECT t.TABLENAME, i.INDEXNAME, i."UNIQUE"
FROM sys.systables t
JOIN sys.sysindexes i ON t.TABLEID = i.TABLEID
ORDER BY t.TABLENAME, i.INDEXNAME
These initial queries failed on the target system. The attackers then retried with a second set of queries, which succeeded in extracting schema information:
SELECT t.TABLENAME, c.COLUMNNAME, c.COLUMNNUMBER, c.COLUMNDATATYPE, c.COLUMNDEFAULT, c.AUTOINCREMENTVALUE, c.AUTOINCREMENTSTART, c.AUTOINCREMENTINC
FROM sys.systables t
JOIN sys.syscolumns c ON t.TABLEID = c.REFERENCEID
WHERE t.tabletype = 'T'
ORDER BY t.TABLENAME, c.COLUMNNUMBER
SELECT t.TABLENAME, con.CONSTRAINTNAME, con.TYPE
FROM sys.systables t
JOIN sys.sysconstraints con ON t.TABLEID = con.TABLEID
ORDER BY t.TABLENAME
We could not confirm whether these queries were generated by a tool or crafted manually, but evidence suggests they were entered directly through the HMI web interface.
The attacker next created a new user account named “BARLATI”. The first login with this account took place at 3:20 PM – about seven hours after the initial compromise. The last login occurred the following morning at 11:19 AM. During that window, the attacker carried out four defacement and disruption actions:
- Defacement: Exploited CVE-2021-26829 to change the HMI login page description to:
[<]script>alert("HACKED BY BARLATI, FUCK")</script>
triggering a pop-up alert with the expletive whenever the page was visited.
- Process Disruption: Deleted connected PLCs as data sources, disabling real-time updates.
- Manipulation: Changed PLC setpoints via the HMI.
- Evasion: Modified system settings to disable logs and alarms.
The attacker did not attempt privilege escalation or exploitation of the underlying host, focusing exclusively on the web application layer of the HMI.
Who Is TwoNet?
TwoNet is a recent entrant to the pro-Russian hacktivist ecosystem. According to Intel471, the group first appeared in January 2025 on a Telegram channel (t.me/TwoNetOfficial, banned on March 7) and initially focused on DDoS leveraging the MegaMedusa Machine malware.
Since September 14, TwoNet has used a new Telegram channel to claim activity, with a separate account rotating invite links to resist takedown. Messages on this channel indicate a pivot from pure DDoS to a broader mix of activity:
- OT/ICS targeting. Attempts against HMI/SCADA interfaces of critical infrastructure entities in “enemy countries” (see table below).
- Doxing/Intimidation. Publication of email addresses allegedly belonging to intelligence and police personnel, framed as supporting “neo-Nazi/pro-Ukrainian terrorists”. Posts attribute some of this content to “desinformador ruso” (“Russian Disinformer” in Spanish). This account has been linked in open discussions to a Spanish professor who was added to Europol’s most wanted fugitives list on September 12, 2025. Those claims remain unverified in our dataset and should be treated as allegations pending primary confirmation.
- Signal-boosting others. Frequent forwarding of posts from adjacent hacktivist brands to imply affiliation or court their attention. We analyze these relationships below.
- Commercial offerings:
- Ransomware-as-a-Service (RaaS) pitch. A new ransomware offered as RaaS for $830 plus 50% of each ransom to the operator. No technical details are provided; pricing is high relative to typical entry-level RaaS, suggesting low adoption potential (or a scam).
- Hack-for-hire. Persona @darkwariosoficial (also styled DarkWarios/Dark Warios in posts) claiming several attacks, advertises DDoS, camera compromise, and control panels as a service.
- Access brokerage. One post advertised access to “SCADA systems in Poland” (screenshot referenced below).
This pattern mirrors other groups that have shifted from “traditional” DDoS/defacement into OT/ICS operations (e.g., the Iranian-linked continuum from ICTUS team through CyberAv3ngers to APT IRAN, discussed in our 2025H1 Threat Review). Like those, TwoNet now mixes legacy web tactics with attention-grabbing claims around industrial systems. The table below lists some of the attacks claimed by TwoNet on their new Telegram channel.
| Date | Description |
|---|---|
| Sep 15 | Forwarded post from deleted “Cyber Forces” channel claiming access to European solar-plant control panels via a critical vulnerability”. Shared images depict WATTrouter (SOLAR Controls, CZ). We observe >50 such internet-exposed devices in Czechia, Slovakia, Poland and Finland (exposure ≠ compromise). |
| Sep 16 | Persona DarkWarios (“from the PalachPro and TwoNet teams”) claims >1,000 CCTV compromises and HVAC access at an Italian regional council. A file dump suggests internet-exposed cameras with trivial credentials (e.g., admin, 12345). The purported victim stated these cameras are not in government facilities and denied HVAC claims. |
| Sep 16 | Screenshots of the monitoring/control system for Moulin de L’Arnaude hydroelectric plant (France). Provenance of access not demonstrated. |
| Sep 17 | DDoS against the Ukrainian Center for Strategic Communication website. Screenshot includes the tag “Revenge” (related hacktivist brand analyzed below). |
| Sep 18 | Data from a French mobile operator data exfiltrated from an unsecured FTP server; advertised for $100. Level of sensitivity unverified |
| Sep 19 | Screenshots of a biomass boiler SCADA system in Czechia, with claims of altered parameters (fan speeds, auger cycling, ignition/overheat settings). Claimed by Dark Warios. |
| Sep 20 | Tampering with a smart home control panel in Poland (claimed by Dark Warios). |
| Sep 21 | Screenshots of a heating system control panel. |
According to a message posted in the affiliated group, CyberTroops’ chat, TwoNet announced it was ceasing operations on September 30th. As of this writing, TwoNet’s Telegram channels– and handles commonly associated with the group, including “BARLATI” and DarkWarios” – are no longer reachable. This underscores the ephemeral nature of the ecosystem where channels and groups are short-lived, while operators typically persist by rebranding, shifting alliances, joining other groups, learning new techniques, or targeting other organizations.
Go deeper: Watch our research team analyze this hacktivist attack caught in our honeypot:
Hacktivist Alliances: From Emerging Groups to Established Networks
A growing pattern in the hacktivist ecosystem is the formation of alliances – loose constellations of groups that share tools, intelligence, members, and targets. The best-known example is the Z-PENTEST alliance, which has publicly claimed attacks including activity against a dam in Norway.
TwoNet members have claimed affiliation with, and frequently forwarded messages from, other hacktivist brands. Some, like Revenge, primarily signal-boost others’ operations, and may lack the capability to run complex attacks themselves. Two groups are most relevant to TwoNet’s current posture: CyberTroops and OverFlame.
КиберVойска – CyberTroops
Origin & alliance. The current channel was created September 16, 2024; the group asserts it has operated since April 18, 2024. On January 30, 2025, it announced an alliance with TwoNet, and the two have since claimed joint DDoS attacks against Ukrainian, European and former-CIS targets, along with releasing database leaks from some incidents.
First OT/ICS claim. On October 31, 2024, CyberTroops posted video of a SCADA interface in Spain, “apparently a wind direction tracker/wind turbine controller or telecommunication controller”. They stated they did not alter operations “To avoid a man-made disaster”.
Recent OT/ICS focus: solar assets Claimed activity centers on solar monitoring/control panels:
| Date | Description |
|---|---|
| June 8 | Access to three German solar control panels via a vulnerability. Claimed no configuration tampering |
| Jun 13 | Access to an Italian solar control interface; mentions additional panels in Czechia. |
| Sep 11 | Access to four German solar control interfaces |
CyberTroops also shows ties to OverFlame, demonstrated by joint claims against pro-Ukrainian targets and frequent forwards of OverFlame content.
I changed the format of this whole section so it matches the preceding one more.
OverFlame
Channel history. Current channel created January 7, 2025, posts imply prior activity under earlier handles.
Activity types.
- DDoS against the government/research sites in Ukraine, Lithuania, Spain, Italy.
- SCADA claims in pro-Ukrainian countries; in at least one case, they alleged damaging valves at a French hydroelectric facility.
Handling of data. Selected leaks claimed from operations have been relayed to Russian authorities, suggesting possible coordination or signaling.
Network & affiliations. OverFlame sits amid a dense constellation of brands and alliances, including Z-PENTEST, DarkStormTeam, Moroccan Dragons, Golden Falcon Team, Mr. Hamza, Red Wolf Cyber Team, DEATH SLASH CYBER SECURITY, ROOTSKAD TEAM, Bandar Internasional Indonesia, Perun Swaroga and Sector16. Not all activity is Russia-Ukraine focused; for instance, DarkStormTeam, Moroccan Dragons and Mr. Hamza are pro-Palestinian.
Based on volume of claims, cross-posting and observed communication, OverFlame, likely functions as a hub, with TwoNet presenting as one of several satellites within its orbit.
Other Attacks We Caught in Our Honeypots
While it is unusual for a named group to claim a honeypot hit, the same system that caught TwoNet routinely logs other unclaimed activity.
Many of those originate from European IP addresses – as in the case of TwoNet – and include relatively disconnected activities such as:
Opportunistic European-origin hits (examples)
| Source IP | ASN/Provider (Country) | Action observed |
|---|---|---|
87.150.146[.]207 | AS3320 – Deutsche Telekom AG (DE) | Connected to the PLC’s web server and switched it to STOP mode |
95.90.199[.]75 | AS3209 – Vodafone GmbH (DE) | Scanned the PLC with a specific, unique sequence of Modbus requests. |
212.83.190[.]55 | AS12876 – Scaleway S.A.S (FR) | Subscribed to the PLC’s Mode-Transition using username USER1 and queried component identification. |
Some activity resembles the TwoNet incident, even if unclaimed, while other cases are more complex and originate elsewhere. Below are two related incidents.
Russian-linked IP addresses exploiting the HMI
Between March 1 – 3, we observed two source IP addresses targeting the honeypot:
45.14.247[.]8777.91.122[.]234
Both are registered PQ Hosting Plus SRL (Moldova). Open-source reporting has linked PQ Hosting to Stark Industries Solutions, an EU-sanctioned bulletproof hosting provider described by Brian Krebs as a “frequent source of massive DDoS attacks, Russian-language proxy and VPN services, malware tied to Russia-backed hacking groups, and fake news.”
Sequence of activity
45.14.247[.]81– March 1
Logged into the HMI with default credentials, then exploited CVE-2021-26828 (arbitrary file inclusion in view_edit.shtm) to upload a Java-based webshell. The attacker’s user-agent (python-requests/2.25.1) indicates scripted exploitation, and payload analysis suggests a likely publicly available PoC. Post-upload actions were limited to basic host enumeration (listing files/processes). No HMI browsing or additional steps observed.
77.91.122[.]234– March 1 (within one minute of web shell upload)
Focused on the HMI itself. Spent >4 hours altering settings and alarm configurations. Subsequent logins from the same IP occurred on March 2, 3, 15 and April 6, ranging from extended exploration of the HMI to brief sessions – likely persistence checks.
We observed no preceding port scans, brute-force attempts, or broad enumeration prior to the initial logins, suggesting prior knowledge of the target system. The absence of consistent post-exploitation activity (e.g. ransomware deployment or process manipulation) suggests either that the operators recognized the environment as a honeypot and disengaged,or that the attackers lacked sufficient expertise or motivation to pursue with the attack.
We assess with moderate confidence that the actions from these two IPs were coordinated, evidenced by tight sequencing and complementary roles (initial access and web shell placement followed by extended HMI-level tampering). The exploitation path (default credentials → CVE-2021-26828 → web shell) and subsequent HMI-only activity are consistent with low-to-moderate capability operators leveraging publicly available tooling.
Scanning and Tampering from Iran: Modbus, S7 and HTTP
Between February 21 and 25, we observed coordinated scanning and tampering against PLC honeypots using Metasploit Modbus modules plus additional scripts.
Quick Modbus primer (for context):
- Function code – purpose of the message.
- Transaction ID– syncs request/response pairs.
- Unit ID – addresses a specific device behind a gateway.
- Data model – reads/writes to memory locations called coils (1-bit) and registers (16-bit).
The interconnected attacks originated from four source IPs in Iran. Three registered to AS58224 (Iran Telecommunication Company PJS) and one to AS197207 (Mobile Communication Company of Iran PLC). As with TwoNet’s infrastructure, these IPs show no relevant prior abuse in our records.
Sequence of activity (by source)
2.181.103[.]232– Feb 21
Initial Modbus reconnaissance against a PLC:- Read Input Registers (Function 4, Transaction ID 8448)
- Read Device Identification (Function 43, Transaction ID 17506)
- Read Multiple Holding Registers (Function 3, Transaction ID 0)
92.43.161[.]74– Feb 23
Mirrored the initial sequence then:- Probed Unit IDs 1 to 254 over ~7 minutes (likely Metasploit modbus_findunitid; defaults align with Transaction ID 8448 and Modbus Function Code 4).
- After ~6 minutes; three Function Code 3 reads for 100 holding registers at Unit ID 1 with Transaction ID 0, starting at addresses 1, 10, 100.
- Two minutes later: another input register scan (Transaction ID 0, Unit ID 1, 100 registers at 100, 10, 200).
- Wrote 0xFF00 to coil ref 200 (~ 90 seconds later).
80.210.133[.]38– Feb 23 (≈2 hours later)- Wrote 0x0000 to coil address 1.
- After 5 minutes, resumed modbus_findunitid input register scan up to Unit ID 104.
- 30 seconds later: Device Identification (Function Code 43) for Unit ID 255 with Transaction ID 17506, consistent with Metasploit modbus_banner_grabbing. A similar request followed one minute later.
- Cross-protocol activity over ~1 hour:
- 19:32 – holding register scans, (addresses 1, 10, 100).
- 19:35 – modbus_findunitid until Unit ID 18.
- 19:38 – write 0xFF00 to coil address 1.
- 19:42-20:29 – interacted with the webserver (port 80).
- 20:33 – switched to S7comm to request PLC CPU type and running mode.
- 20:33 – sent two S7comm-plus packets: opened a v1 session, then v2 attempting to set multiple variables.
- 20:37 & 20:38 –two further S7comm attempts.
5.106.148[.]199– Feb 25- Ran another modbus_findunitid scan to Unit ID 32.
- After ~2 minutes: final write coil function, turning on coil address 1.
Assessment
- Likely manual operation. Gaps between actions, IP rotation, tool switching and parameter variation are inconsistent with a single automated scanner.
- Commodity tooling. Metasploit modules featured prominently
- Multi-protocol familiarity. Use of Modbus, HTTP/web, S7comm/S7comm-plus indicates basic OT fluency and an intent to map connected assets.
- Potential impact (if real targets). STOP commands, coil/register writes, and parameter changes can halt processes or change outputs on improperly secured systems
These patterns are representative of targeted actions we frequently observe – and are plausible against any internet-exposed utility-owned OT/ICS.
Conclusion
Since 2022, we’ve tracked the rise of hacktivist attacks against critical infrastructure. This is the first time a group has publicly claimed an attack that we can confirm occurred on one of our honeypots. Taken together with activity from affiliated groups, several lessons stand out:
- Treat claims cautiously, monitor relentlessly. Hacktivist channels blend genuine incidents with exaggeration. Monitoring still yields value: intent, tooling, target selection, and emerging alliances.
- OT/ICS pivots come with “false starts”. As with the early CyberAv3ngers playbook, groups moving from DDoS/defacement to OT/ICS often misread targets, trip over honeypots, or over-claim. That doesn’t make them harmless; it shows where they are headed.
- Alliances accelerate capability. Alliances (e.g., OverFlame, Z-PENTEST) share targets, TTPs, infrastructure, and sometimes personnel, giving nascent crews like TwoNet a shortcut to scale.
- Utilities, especially in the water and power sectors remain key targets. Water and power draw outsized attention. Our water-utility honeypot and affiliates’ solar claims mirror broader exposure in utility environments where security budgets, awareness, or accountability lag.
- Not all activity is The deeper, manual scans and tampering we observe (e.g., the Iran-sourced case) rarely make it to Telegram. OT/ICS devices are also probed by criminals and state-sponsored actors, another reason not to dismiss these signals.
- Brands are ephemeral, but threat actors remain. Short-lived groups rebrand and swap affiliations, carrying tactics and access forward. It is critical to track people, infrastructure and alliances, not just names, to keep pace with this ecosystem.
Recommended Mitigations
- Eliminate weak authentication. Remove default/easily guessable credentials on OT/ICS and IoT devices; enforce strong unique passwords and, where supported, MFA.
- Remove direct internet exposure. Do not expose IoT/OT/ICS devices to the public internet, follow CISA’s guidance on providing remote access for industrial control systems.
- Segment rigorously. Separate IT, IoT and OT networks, limiting network connections to only specifically allowed management and engineering workstations or among unmanaged devices that need to communicate.
- Harden admin interfaces. Place administrative interfaces (such as web UIs and engineering ports) behind IP-based access control lists, restrict by VPN-protected management VLAN, disable unused services.
- Require authentication on all IoT/OT admin interfaces (web UIs and proprietary engineering ports); disable anonymous/default accounts and enforce strong, unique credentials.
- Monitor with IoT/OT-aware, DPI. Use protocol-aware detection (Modbus, S7, etc.) to alert on exploitation, password guessing, unauthorized writes, and HMI changes.
- Watch outbound and “dual use”. Monitor for devices abused in distributed attacks (e.g., cameras, routers) and for unusual traffic from OT segments.
| Forescout Recommendation | NIST SP 800-82 r3 (section/control) | IEC 62443-3-3 mapping | MITRE ATT&CK for ICS techniques limited by this control |
|---|---|---|---|
| Enforce auth on all OT/IoT admin interfaces; remove defaults; use MFA where feasible | Access controls & ACL/RBAC guidance (Sec. 6.2.1.*); OT Overlay AC family (F.7.1); AC-17(10) “authenticate remote commands” | FR 1 Identification & Authentication Control (IAC): SR 1.1 human user I&A; SR 1.2 software/device I&A; (often SR 1.7 password policy) | T0859 Valid Accounts; reduces abuse of T0822 External Remote Services/T0886 Remote Services |
| Remove direct Internet exposure; broker remote access via VPN/jump host + MFA; restrict by ACLs | Defense-in-depth & segmentation model/DMZ (Sec. 5); Network Segmentation & Isolation (Sec. 6.2.1.3); Remote Access AC-17 + enhancements | FR 5 Restricted Data Flow: SR 5.1 network segmentation/zones & conduits | T0883 Internet Accessible Device, T0822 External Remote Services, T0886 Remote Services, T0866 Exploitation of Remote Services |
| Segment OT from IT; allow-list only required flows; deny-all at boundaries; use OT-aware firewalls/diodes | Network segmentation & DMZ (Sec. 5); Sec. 6.2.1.3 (segmentation/isolation); Appendix E.1 (firewalls, DPI, diodes) | FR 5 Restricted Data Flow: SR 5.1 (and related SRs for conduits) | Constrains lateral movement and command paths used in T0855 Unauthorized Command Message, T0803 Block Command Message |
| Put admin ports/UIs behind IP-based ACLs; management VLAN/jump servers only | Access control & ACL implementation notes (Sec. 6.2.1.1); “managed access control points” AC-17(3) | FR 2 Use Control: SR 2.1Authorization Enforcement (least privilege/SoD) | Limits write paths for T0836 Modify Parameter, T0821 Modify Controller Tasking, T0889 Modify Program |
| Harden HMI/SCADA web apps; input validation; disable unused modules; patch known vulns | General OT hardening + compensating controls; remote-access risk notes (Sec. E.1/E.2; Sec. 3.3.1–3.3.6) | FR 3 System Integrity; FR 4Data Confidentiality (where TLS needed) | Reduces T0832 Manipulation of View, T0878 Alarm Suppression, T0855 Unauthorized Command Message (when web HMI is the gateway) |
| Add auth to engineering protocols/workstations; restrict “write”/prog ops to engineers only | AC family + “authenticate remote commands” AC-17(10); PR.AC-7 (user/device auth) | FR 2 Use Control: SR 2.1; FR 1 IAC (SR 1.1/1.2) | T0821 Modify Controller Tasking, T0889 Modify Program, T0843 Program Download |
| OT-aware monitoring/DPI for Modbus/S7; alert on unauthorized writes, alarm changes, mode flips | Appendix E.1/E.2 (DPI firewalls; network monitoring/SIEM); compensating control with DPI (Sec. 3.3, p. 53) | FR 6 Timely Response to Events: SR 6.1 audit log access; SR 6.2 continuous monitoring | Detects T0836 Modify Parameter, T0878 Alarm Suppression, T0821 Modify Controller Tasking, T0831 Manipulation of Control |
| Watch for outbound abuse (bots/DoS) from OT/IoT; rate-limit/egress filter | Network monitoring & segmentation notes (Sec. 6.2.1.3; App. E.1/E.2) | FR 7 Resource Availability (DoS protections) | Curtails T0814 Denial of Service, T0816 Device Restart/Shutdown, T0813 Denial of Control |
IoCs
45.157.234[.]19987.150.146[.]20795.90.199[.]75212.83.190[.]552.181.103[.]23292.43.161[.]7480.210.133[.]385.106.148[.]19945.14.247[.]8777.91.122[.]234