While tracking the activities of 4BID we uncovered a new string of campaigns that appear to be the work of several interconnected actors. While politically motivated groups generally limit their scope to specific nations – for 4BID and its peers, primarily Russian and occasionally Belarusian organizations – our latest findings reveal a shift. The actual geographic footprint of these attacks became broader than expected, striking companies across Kazakhstan, the UAE, Syria, and Egypt.
What triggered our investigation was spotting a cluster of indicators of compromise within a breached Russian organization’s infrastructure. We used these footprints to successfully track down other environments hit by the same threat actors and piece together the bigger picture.
This article dives into the software deployed throughout these hacktivist campaigns:
These include both updated versions of known threat-actor tools and previously unseen software.
Within the initial organization’s infrastructure, we found numerous activity indicators linked to several interconnected hacktivist groups – which ultimately set the direction for our follow-up analysis. We can attribute the following findings to hacktivist activity with a medium level of confidence:
Analysis of the compromised environments revealed that the attackers gained initial access in most cases by exploiting the ProxyShell vulnerability in Microsoft Exchange, which allows for full server compromise.
Once inside, the attackers deployed the fd.aspx web shell – a modular ASP.NET file designed for remote control, file transfers, and system reconnaissance. Communication with the web shell relied on a basic security check: if the key parameter in an incoming request failed to match the AUTH_KEY constant, fd.aspx simply returned “Access Denied”.
Access key verification
If the verification was successful, the command contained in the request’s scriptText parameter was passed directly to PowerShell, and the output returned to the operator in the body of the HTTP response. In environments where PowerShell execution was restricted, the web shell swapped it out for cmd.exe. The CreateNoWindow: true and UseShellExecute: false flags were used to keep the command execution hidden from the user.
Beyond running commands, the web shell features bidirectional Base64-encoded file transfers. This allows any binary data – like executables, archives, or certificates – to be passed right inside the body of an HTTP request. The UploadFile function writes files to any directory the web server process can access, which makes it easy to drop additional shells or swap out legitimate files. The DownloadFile function exfiltrates any accessible file from the compromised system back to the attackers’ C2 server.
The web shell also includes a system reconnaissance feature that grabs the following data points:
Additionally, the reconnaissance feature uses the DriveInfo.GetDrives() function to enumerate running processes and map out connected drives – along with the amount of free space available on each. This file system reconnaissance is topped off with LastWriteTime metadata for each object, which helps the operator quickly spot recently modified files and get their bearings within the storage layout.
Alongside the web shells, we encountered a variety of scripts and C2 frameworks across all compromised infrastructures, which we break down below.
Once the attackers gained control over a target system, they moved on to the next phase: loading their required toolkit via custom scripts. Variations of these scripts were consistently found alongside fd.aspx on compromised hosts. Most of them interact with legitimate tools, which makes them look almost identical to routine administrative scripts at first glance. The only real giveaway is the code comments, written in Ukrainian. One such script is responsible for deploying AnyDesk on the compromised host.
The build quality of these scripts is worth discussing separately. Several of them show telltale signs of AI generation; inside some compromised systems, we found multiple iterations of the exact same script, a few of which were completely broken. AI-generated code typically fails to work out of the box and requires manual tweaking to run properly.
First, the script checks for admin privileges, as it cannot proceed without them. If that check passes, it looks for an active anydesk.exe process. If the process is missing, the script fetches and installs the application directly from the official website. Once AnyDesk is successfully installed, the script configures an unattended access password and pulls the unique AnyDesk ID. All the collected details are compiled into a report and exfiltrated to the attackers’ server at 185.221.153[.]121. Because we spotted simultaneous activity from multiple groups – 4BID, Hakerskii Kit, and C.A.S. – on the analyzed hosts, this IP address could potentially belong to any one of them.
Besides AnyDesk, the threat actors leverage other legitimate tools. One example is Microsoft Dev Tunnels, a Microsoft service that exposes a local server to the internet. It’s brought into the system by a separate script that, much like the one for AnyDesk, checks if the utility is already present before downloading it from the official site. In certain instances, the utility was fetched directly from the attackers’ server instead:
Once installed, the application runs, and the resulting connection details are saved to a file named login.txt. The contents of this file consist of standard instructions for using a provided code to authenticate on a Microsoft page through a web browser.
To sign in, use a web browser to open https://login.microsoft.com/device and enter the code [CODE].
As a final step, the script opens up the required ports and creates the tunnel, giving the attackers a back door into the compromised host.
Another script we uncovered handles the installation of Panorama9, a legitimate remote monitoring and management utility. Immediately after downloading that application, the attackers configure it via the registry to hide both its system tray icon and its installation folder. To camouflage the Panorama9 services, the attackers rename them to Windows Update Helper and Windows Update Helper Cache and swap out their descriptions, making the utility look almost identical to standard system components. Once the utility finishes its job, the script clears its tracks.
The attackers used a dedicated script to establish persistence on the system. When executed, it used the net user command to spin up a local user account and then hid it via the registry. The script added this new user to every available local group; if the machine was domain-joined, it also attempted to inject the user into all Active Directory groups.
At the same time, the script tweaked RDP settings: it set the minimum encryption level through the registry, added a firewall rule to allow port 3389, and ran the relevant services.
After it wrapped up its main tasks, the script wiped the event logs, command history, temporary files, and finally itself. Once the attackers got what they wanted out of the infected host, they triggered another script that removed the previously created user account, cleaned out the registry keys generated during the earlier phases, and then deleted itself as well.
The scripts described here are just the most telling examples out of dozens of samples we found. An analysis of the attackers’ toolkit reveals a clear trend: they aren’t just fine-tuning the solutions they’ve used in the past (specifically, the AnyDesk deployment script), but are actively broadening their arsenal with new tools like Panorama9, Dev Tunnels, and others.
As previously mentioned, the attackers leverage a broad spectrum of dual-use public software, such as all kinds of remote monitoring and management utilities. While they use the scripts discussed above to drop some of the utilities onto systems, we didn’t encounter scripts for others, so we can’t confirm whether any exist. We observed the following tools deployed across the campaigns in question:
To gain a foothold in the victim’s infrastructure, the attackers relied on several post-exploitation frameworks. Some of these are publicly available utilities, while others are custom-built.
Among the publicly available tools in the group’s arsenal are:
We also discovered a previously undocumented backdoor, dubbed BlackSalt, which contacts the C2 server to fetch commands and executes them via cmd.exe.
On several hosts, following the initial Microsoft Exchange server compromise, files named upd.exe, winhost.exe, update1.exe, update.exe, and akolo.exe were dropped alongside the previously mentioned fd.aspx files and scripts. All of them were located in the C:\Windows\System32\inetsrv\ directory and were configured as SFX archives with nearly identical payloads, which ran an install.bat script upon extraction.
Contents of the SFX archive
The install.bat script contents
The script copies the malicious components into the Windows folder and installs servicechecker.bat as a system service. To do this, it leverages the legitimate Windows Service Wrapper (WinSW) utility included in the archive under the filename backupsrv.exe. The archive also contains the WinSW configuration file, backupsrv.xml, which specifies exactly which script should be registered as a service. Once installed, servicechecker.bat is configured to run automatically on system boot.
The servicechecker.bat script, in turn, runs backupagnt.exe, a loader for the main malicious component housed in WindowsInternal.UpdateComponent.dll. This file was built with the help of the Donut utility and is encrypted with a simple single-byte XOR key (0x0F). Its primary job is to inject the Sliver code straight into the device’s memory.
The backupagnt.exe loader code
All Sliver instances uncovered during this investigation were configured to communicate with the C2 server at 185.221.153[.]121 over mTLS.
Inside a similar SFX archive located in the user directory $user\desktop\ under the filename demon.x64.exe, we found another post-exploitation framework: Havoc. This instance was configured to communicate with the C2 server at 77.72.85[.]62.
Mythic Apollo is a cross-platform post-exploitation agent used within the Mythic framework to manage compromised systems. It provides a persistent connection to the C2 server, executes operator commands, handles file uploads/downloads, runs arbitrary code, and supports expansion via plugins. We previously provided a detailed breakdown of the Mythic framework in our post, Hunting for Mythic in Network Traffic.
Here is an example of the Mythic Apollo configuration we encountered in these hacktivist attacks:
This specific sample of the .NET Mythic Apollo agent was compiled with an extensive suite of modules and supports multiple transport profiles that enable communication via HTTP, TCP, WebSocket, SMB, named pipes, and web shells. The C2 address 77.72.85[.]62 is hardcoded into its configuration.
AdaptixC2 is another post-exploitation framework in the attackers’ arsenal. This is a relatively new open-source project, which we broke down in our post, Adapt or pay:an analysis of the AdaptixC2 framework.
The agent samples discovered during our investigation into these hacktivist campaigns consist of a packed AdaptixC2 Beacon delivered via a custom x64 loader. Upon execution, the payload decrypts an embedded shellcode, allocates memory, and executes the malicious payload using the CreateThread WinAPI function. Packed inside the shellcode is the AdaptixC2 Beacon agent in DLL format, featuring a configuration encrypted using RC4.
According to the AdaptixC2 classification system, this agent falls under the BEACON_HTTP type. It is capable of executing commands, performing file operations, enumerating and killing processes, launching new programs, and exfiltrating data back to the C2. It also supports SOCKS port forwarding and BOF modules.
AdaptixC2 uses encryption to keep its configuration under wraps. The corresponding block contains the data size, the actual RC4-encrypted configuration, and a 16-byte key.
Example agent configuration
Example of agent requests pinging the C2 address, as flagged by Kaspersky solutions and displayed in Kaspersky Threat Lookup
During the investigation, we also came across target infrastructures running vulnerable versions of Microsoft Exchange where – much like the Sliver cases – SFX archives named WindowsServiceHelper.exe were discovered in the C:\Windows\System32\inetsrv\ directory. Once extracted, the archive executed an install.bat file.
SFX archive contents (09d0517a1f69feff8186655ae3b567e0)
The install.bat script contents
Similar to the other archives of this type, the script uses the WinSW utility to install the malicious components. In this specific case, however, the primary payload is a file named svc.exe, which turns out to be an obfuscated backdoor written in VBS. Much like the deployment scripts used for the remote management utilities, the code of this setup BAT script was clearly put together with AI tools and features comments in Ukrainian.
Main backdoor loop
The backdoor is essentially a textbook reverse shell. Its capabilities boil down to fetching commands from the C2 server at 45.150.109[.]2, executing them via cmd.exe, and piping the output back to the C2.
In their attacks, the threat actors deploy what are known as EDR killers: malicious tools designed to disable security software on the system. In the vast majority of cases, these utilities rely on the BYOVD technique.
On the hosts compromised during these hacktivist operations, we discovered samples named kil.exe and Killer.exe. These are modified versions of the public, Rust-based BYOVD project EDRKiller. The attackers streamlined the utility to act strictly as a client for the driver and expanded the hardcoded list of security processes to terminate. The sample targets the vulnerable Warsaw_PM driver, though it lacks the functionality to load the driver itself – the attackers drop it onto the system separately.
The general workflow plays out as follows:
The EDR killer continuously enumerates processes, repeatedly sending the IOCTL and terminating the target processes every single time they pop up.
Example of the process list storage inside the EDR killer
Both kil.exe and Killer.exe share the exact same list of processes targeted for termination:
MsMpEng.exe, SenseIR.exe, SenseNdr.exe, SenseCncProxy.exe, SenseSampleUploader.exe, NisSrv.exe, avp.exe, kavfs.exe, bdagent.exe, bdservicehost.exe, vsserv.exe, AvastSvc.exe, AvastUI.exe, aswidsagent.exe, avgsvc.exe, mfemms.exe, mfefire.exe, mfevtps.exe, dwengine.exe, dwservice.exe, elastic-agent.exe, elastic-endpoint.exe, Sysmon.exe, wazuh-agent.exe, ipban.exe
Another utility used to kill security software processes is ghostdriver.exe, an unmodified build of the open-source project GhostDriver. In this case, the attackers simply pulled a version straight from GitHub and didn’t modify any of its code.
Example of output from the GhostDriver utility
The tool operates through the following stages:
GhostDriver.sys is hardcoded inside the GhostDriver executable and is a binary driver known as RentDrv2 (BadRentdrv2).
It contains the CVE-2023-44976 vulnerability, which allows it to:
Upon execution, GhostDriver drops RentDrv2 to disk, loads it into the Windows kernel, and connects to it via the virtual device \\.\rentdrv2. The utility then issues command 0x22E010 to the driver, passing along the target process ID, and the driver terminates that process directly from kernel mode.
GhostDriver runs in a continuous loop. Every ~700 ms, it rescans for the target processes and sends out termination commands.
After the driver starts up, the utility attempts to delete the ghostdriver.sys file. To do this, it opens a file handle, uses the SetFileInformationByHandle WinAPI function to rename it to something like :GhostDriver, reopens the handle, and marks the file for deletion via FileDispositionInfo. Before wrapping up, it also tries to stop and remove the driver service, and delete the C:\rentdrv.log file where the driver writes its logs.
Example of the adversary command execution launching GhostDriver:
Current versions of Kaspersky products are resilient to these types of attacks: the utilities described in this post cannot terminate their processes.
Alongside the previously described Mythic Apollo samples (C2: 77.72.85.62), backupagnt.exe loaders, and Panorama9 deployment scripts, we discovered a new ransomware strain named ClearWater across several compromised infrastructures. Written in C++ and compiled with GCC (MinGW), the sample is a 64-bit Windows executable. It features zero obfuscation; in fact, the binary wasn’t stripped of its DWARF debug information. This makes analyzing the sample significantly easier and points to either sloppiness or a lack of technical expertise on the developers’ part.
Original function names preserved within the Trojan’s body
When executed, ClearWater logs its progress in a separate console window.
The console window displayed upon launching the Trojan
Like most ransomware strains, ClearWater is a Trojan designed to locate and encrypt the victim’s files. The Trojan executable contains a hardcoded RSA-2048 primary public key in PEM format.
For every file it processes, the ransomware generates a new 32-byte key and a 12-byte nonce – though only 8 of those 12 bytes are actually used – and encrypts the file’s contents via the ChaCha20 symmetric algorithm. The ChaCha key is then RSA-encrypted and appended to a specific data structure at the end of the file. To pull this off, the malware leverages cryptographic implementations from the open-source libsodium library.
Entrarstruct
{
uint8_t label[4]; //'M', 'Y', 'E', 'K' marker
uint32_t rsa_encr_size; //size of RSA-encrypted data
uint8_t rsa_encr_data[256]; //RSA-encrypted ChaCha key
};The Trojan processes all files except those with a .txt extension. This approach can easily break installed software, as it blindly encrypts both libraries and executables; however, it does explicitly skip the system directory during its search. Encrypted files are additionally appended with the .clear extension. The malware scans for targets on local drives as well as SMB network shares, which it maps out by using the net view command.
Within every directory it processes, the Trojan drops the attackers’ demands into a file named CLEARWATER_README.txt.
Ransom note:
Additionally, by modifying the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key, the malware sets up a persistence mechanism that automatically opens the ransom note with notepad.exe on startup.
ClearWater is distributed inside a self-extracting archive. The extraction script runs in silent mode (GUIMode=”2″), escalates privileges via a UAC prompt, drops the Trojan at C:\ProgramData\ClearWater_x64.exe, and kicks it off. Once the ransomware finishes running, the SFX archive cleans up after itself and wipes the original archive (SelfDelete=”1″).
Alongside this script and the Trojan executable, the archive includes a BMP image. The ransomware sets this image as both the desktop wallpaper (by tweaking the HKEY_USERS\<…>\Control Panel\Desktop\Wallpaper registry key and calling SystemParametersInfoA with the SPI_SETDESKWALLPAPER parameter) and the lock screen background (by modifying the LockScreenImagePath and LockScreenImageUrl values under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP).
Two variants of the desktop and lock screen image
To complicate system recovery after the attack, ClearWater performs several actions typical of ransomware:
ClearWater also features a kill_all_non_whitelisted_processes() function designed to terminate active tasks, though it doesn’t actually call it during execution. This function leverages PowerShell to look up and kill any process whose name isn’t included in a hardcoded allowlist within the Trojan’s body. It uses the following PowerShell code to do this:
Get-Process|Where-Object{$w -notcontains $_.Name.ToLower()}|Stop-Process -ForceThe exclusion list contains various essential system processes and breaks down as follows:
system, idle, smss, csrss, wininit, services, lsass, winlogon, svchost, explorer, dwm, shellexperiencehost, runtimebroker, trustedinstaller, tiworker, textinputhost, taskhostw, mousocoreworker, fontdrvhost, audiodg, sihost, spoolsv, taskeng, taskhost, searchui, securityhealthservice, startmenuexperiencehost, searchindexer, backgroundtaskhost, sppsvc, wmiprvse, wudfhost, vboxservice, vboxtray, vmtoolsd, vmwaretray, vboxguest, vmsrvc, vgauthservice, vmacthlp, qemud, qemu-ga, msdtc, searchprotocolhost, wlanext, dllhost, conhost, comppkgsrv, msmpeng, mssecflt, systemsettings, securityhealthsystray, nvtray, nvvsvc, ravbg64, igfxtray, igfxem, igfxcuiservice, igfxhk, igfxext
In a previously published report (link in Russian) on collaborations between several hacktivist groups, we highlighted a tool called Blackout Locker. In late January 2026, the 4BID group ran a series of attacks against organizations in Russia using an updated version of this malware. This section breaks down the new version of Blackout Locker and covers its key characteristics uncovered during our analysis.
The attackers use a dropper written in Rust to distribute Blackout Locker. Depending on the specific sample, the dropper first carries out a series of staging actions. It then writes the payload executable to …\Users\[USERNAME]\AppData\Local\Microsoft\[REDACTED].dat and swaps its extension to EXE by calling the Windows command prompt:
After that, it launches the renamed executable.
The primary tool deployed in the attacks in question is an updated version of Blackout Locker.
Our analysis revealed that the key difference in this new version is the addition of a screen locker component, which it drops and executes in tandem with the ransomware’s main background payload.
During the initial phase, the screen locker file is created under the following paths:
To launch the screen locker, several tasks are created:
The screen locker is also written to the following registry keys:
After this, two LNK files, SystemHelper.lnk and WindowsHelper.lnk, are created via PowerShell for subsequent execution:
As a result, a shortcut is created in the startup folder pointing to WindowsSystemHelper.exe located on the desktop. This ensures the screen locker appears every time the user logs in. Even if the victim enters the correct password into the locker window, it will keep popping back up; while the window itself closes after password entry, the corresponding task is never actually deleted.
During execution, Blackout Locker generates a file named README.txt, which the screen locker later references to pull the text displayed to the user. Some Blackout Locker samples drop a ransom note written in English:
On the lock screen, it may look like this:
Other samples deploy a ransom note in Russian:
If the program fails to read README.txt, it falls back to a hardcoded ransom message. If this fallback message is in Russian but the victim’s operating system lacks support for Cyrillic encodings, the loader’s on-screen output renders as garbled text.
The majority of the compromised infrastructures belong to Russian and Belarusian organizations, which aligns with the stated agenda of these hacker groups. However, for the first time, we identified victims in other countries with no relation to this agenda: Kazakhstan, the UAE, Syria, and Egypt. Within the network of a Kazakh aviation company, we detected multiple post-exploitation frameworks pointing to C2 servers at 77.72.85[.]62 and 185.221.153[.]121, traces of the Panorama9 and Tactical RMM platforms, and backupagnt.exe loaders. A similar footprint was observed in the infrastructure of an Egyptian hospital, though the familiar toolkit was augmented by the fd.aspx web shell. The remaining international victims exhibited a nearly identical combination of artifacts, with only minor variations.
While the primary targeting vector previously centered on Russia and Belarus, the threat actors now appear to be pivoting their attention toward the wider CIS region and the Middle East. This strategic shift correlates with a statement from a member of the 4BID group, who claimed that attacking Russia is no longer profitable.
The hacktivist groups discussed in this report are steadily expanding the geographical footprint of their campaigns, pushing beyond Russia and the wider CIS region. Alongside this expansion, we observe the growing use of ransomware and other tooling consistent with financially motivated operations, which may further influence their choice of victims.
This shift underscores the critical need for continuous threat landscape monitoring. To stay ahead of threat actors, organizations must look beyond the immediate risks facing their perimeter and proactively track emerging threats, including the tactics of groups targeting specific industry verticals or geographic regions.
Kaspersky solutions reliably detect the malicious activity in question at every stage of the malware lifecycle. This section outlines potential detection scenarios.
Publicly available dual-use software leaves numerous artifacts on targeted hosts, which helps Kaspersky Endpoint Detection and Response Expert trace the activity of these utilities.
For instance, network connections established with Panorama9 servers both during the initial software launch and throughout the tool’s operation trigger the panorama9_dns_activity rule. The Hunt Hub section of our TI Portal features detection rules for other event types and specific operating systems, searchable with the keyword panorama9. Similar rules exist for the other utilities described in this post: Tactical RMM, Nezha, and Dev tunnels.
GhostDriver.exe relies on an embedded vulnerable driver, which it drops onto the target host. The creation of these drivers is detected by the vuln_driver_created_by_unsigned_process rule family.
Ransomware is inherently quite noisy and so can be detected at various execution phases. The execution graph within Kaspersky Cloud Sandbox on our Threat Intelligence Portal visualizes the entire ClearWater execution chain, capturing key behaviors such as modifying the desktop wallpaper and deleting shadow copies.
ClearWater execution graph in Kaspersky Cloud Sandbox
Additionally, the Threat Lookup and Research Graph sections of Kaspersky Threat Intelligence Portal allow you to visualize and analyze the connections between the malicious domains and files used by the adversaries.
Visualization via Research Graph on Kaspersky Threat Intelligence Portal
Kaspersky Threat Lookup demonstrating the connection between malicious files and the attackers’ IP address
Monitoring network traffic is another highly effective method for detecting the malicious activity described here. Kaspersky Anti Targeted Attack (KATA) with the NDR module detects the network communications of all malware samples in question utilized throughout this campaign.
For instance, upon detecting HTTP network activity characteristic of the BlackSalt backdoor, the system triggers an alert for the Backdoor.BlackSalt.HTTP.C&C rule triggering.
Examples of using the Kaspersky Anti Targeted Attack (KATA) platform with the NDR module to detect other agents described here – along with their detailed technical analysis – are available in our dedicated reports on Adaptix and Mythic detection.
Network indicators
212.46.12[.]182
185.221.153[.]121
77.72.85[.]62
45.150.109[.]2
130.49.155[.]112
45.112.194[.]82
138.226.236[.]52
85.137.253[.]186
What Happened:
Analyst Comment:
This case is a sobering look at the technical debt hiding inside the UK’s Critical National Infrastructure (CNI). A dwell time of nearly two years is practically unheard of in modern ransomware operations, and the TTPs used by the adversary points to a total breakdown of their defences. Cl0p didn’t need sophisticated, state-sponsored techniques or zero-days to pull this one off, they just walked back in through an infection that went undetected.
The ICO’s findings also reveal the reality that many UK organisations still treat cybersecurity as a set-and-forget compliance check rather than routine efforts to mature and upgrade systems or proactive measures to hunt and detect threats lurking inside the network.
Defensive Takeaways:
Relevant Sources:
Relevant CTI Resources
The following intelligence brief was sent to all SentinelOne partners and customers today:
Recent U.S. and Israeli strikes against Iranian targets, followed by Iranian attacks on multiple regional locations, present a highly dynamic geopolitical situation with credible cyber threat implications. Iran has historically incorporated cyber operations into periods of regional escalation.
Given the rapid escalation of geopolitical tensions, we assess that Iranian state-aligned cyber activity is likely to intensify in the near-term based on a long track record of leveraging cyber operations for asymmetric retaliation, coercive signaling, and strategic messaging. Prior campaigns, including destructive wiper malware, infrastructure disruption, and influence operations masquerading as ‘hacktivism’, demonstrate both capability and intent to operate in the cyber domain alongside kinetic action.
This report outlines Iran’s historical cyber posture, relevant tactics and tradecraft, and our forward-looking assessment of potential cyber responses in the days and weeks following the airstrikes.
We assess with high confidence that organizations in Israel, the United States, and allied nations are likely to face direct or indirect targeting – particularly within government, critical infrastructure, defense, financial services, academic, and media sectors.
We recommend that all clients, especially those operating in, or supporting, U.S. and Israeli infrastructure, review their security posture and preparedness accordingly.
This assessment is current as of February 28, 2026 and reflects a rapidly evolving threat environment.
Iran presents a mature, well-resourced cyberthreat based on more than fifteen years of experience across a wide range of malicious cyber events.
Iran uses a diverse set of cyber tools to further state objectives, particularly preservation of the Iranian regime, including:
Iranian cyber actors previously aligned their operations with kinetic campaigns, often acting as a force multiplier for regional allies like Hamas or as a standalone tool of retaliation. The TTPs employed by Iranian hacktivists increasingly mirror those used by state-sponsored APTs, raising critical questions about capability sharing and formal command-and-control relationships within this environment.
Expect escalated targeting of Israeli defense, government, and intelligence networks using spearphishing, credential harvesting, and deployment of custom malware. Historically, groups such as APT34 (OilRig) and APT42 (TA453) leveraged legitimate access to move laterally and exfiltrate strategic intelligence. Additionally, U.S. military and government organizations will likely be targeted in similar campaigns.
Anticipated Targets:
Iran has a well-documented history of using destructive malware and DDoS attacks to disrupt the critical infrastructure of its adversaries. We assess a high likelihood of similar tactics being deployed against U.S. and Israeli sectors, particularly utilities and public-facing systems.
Key techniques include:
Anticipated Targets:
Iranian-aligned actors are likely to amplify disinformation campaigns to shape public perception, particularly around civilian impact, military failure, and geopolitical instability. These efforts often run concurrently with real-world escalations and aim to degrade public trust in institutions.
Anticipated Themes:
Iran has demonstrated readiness to expand attacks to Western infrastructure during periods of high tension. Recent examples include the exploitation of Unitronics PLCs at U.S. water treatment plants (late 2023), highlighting a shift toward ICS/OT targets. Such actions serve retaliatory and signaling purposes and are often designed to be low-impact yet high-visibility to maximize psychological effect.
Anticipated Targets:
SentinelOne research and detection teams have closely followed Iranian cyber actors for many years. We provide multiple layers of protection and are closely monitoring emerging threat intelligence to maximize coverage.
We extensively cover techniques known to be used by Iranian threat groups including:
These protections are not Iran-specific but known to be effective in detecting their operations.
We are monitoring the situation closely and can ship new detections quickly through Platform Rules updates or Live Security Updates.
For maximum protection, we recommend:
SentinelOne is proactively hunting for IOCs and TTPs associated with these groups. These threat hunts are being performed for all Wayfinder Threat Hunting customers. Any related hunt findings will be visible in the Wayfinder Threat Hunting dashboard.
This report is intended to support informed decision-making and proactive defensive measures amid a dynamic and escalating geopolitical conflict.
The cyber threat landscape associated with Iranian state-aligned actors is adaptive, and we assess that both targeting priorities and tactics may shift rapidly in response to real world developments, political statements, or perceived provocations.
We advise clients to treat this as a time-sensitive assessment and to revisit posture, incident response, and monitoring processes regularly.
For immediate questions or escalations, please contact your Client Success Lead or reach our Support teams directly at: https://www.sentinelone.com/global-services/get-support-now/
Customers should consider activating Platform Detection Library rules to improve coverage. The following rules are known to be effective against Iranian cyber operations:
MuddyWater
Credential Dumping
Tunneling & Remote Access
Collection & Exfiltration
PowerShell/Script Abuse
Defense Evasion, Impact, Discovery
On September 25, CISA issued a stark reminder that critical infrastructure remains a primary target for cyberattacks. Vulnerable systems in industrial sectors, including water utilities, continue to be exploited due to poor cyber hygiene practices. Using unsophisticated methods like brute-force attacks and leveraging default passwords, threat actors have repeatedly managed to compromise operational technology (OT) and industrial control systems (ICS).
Attacks on the industrial sector have been particularly costly. The 2024 IBM Cost of a Data Breach report found the average total cost of a data breach in the industrial sector was $5.56 million — an 18% increase for the industry compared to 2023. This represents the highest data breach cost increase of all industries surveyed in the report, rising by an average of $830,000 per breach over last year.
Ongoing vulnerabilities pose a serious threat to public safety and national security, especially as water systems and other critical infrastructure providers remain underprepared in the current threat landscape. Let’s take a closer look at the current state of critical infrastructure security, highlighting recent incidents, efforts to address vulnerabilities and the need for further collaboration between the government and private sectors.
The cybersecurity incident at the Arkansas City Water Treatment Facility on September 22 exemplifies the growing risks. While city officials emphasized that the water supply remained safe and no disruption to service occurred, the breach still forced the facility to switch to manual operations. The incident is currently under investigation, with local authorities and cybersecurity experts collaborating to resolve the issue and prevent further attacks. But the Arkansas City breach is not an isolated incident; it mirrors a larger trend of attacks on water systems.
CISA has issued multiple warnings regarding the susceptibility of water and wastewater systems to cyber threats. Intruders often exploit outdated and unsecured OT and ICS environments, where systems are exposed to the internet or still using default credentials. This means cyber criminals can gain access using relatively simple techniques, which raises concerns about the overall preparedness of critical infrastructure operators.
CISA’s September alert is not the first indication of the heightened threat to water and other critical infrastructure providers. Earlier in 2024, the agency warned that Russia-affiliated hacktivists were actively targeting ICS and OT environments in U.S. critical infrastructure facilities. Water systems, dams and sectors, such as energy and food, were particularly vulnerable to these attacks.
The situation worsened with the rise of the Cyber Army of Russia Reborn, a hacktivist group tied to Advanced Persistent Threat 44 (APT44), commonly known as Sandworm. The group has been quite busy exploiting weak cybersecurity postures of smaller water systems that lack adequate cyber defense resources.
According to Keith Lunden of Mandiant, “We expect these attacks to continue for the foreseeable future given the lack of dedicated cybersecurity personnel for many small- and mid-sized organizations operating OT.” Unfortunately, hacktivist groups have exploited these gaps with relative ease. And without rapid intervention, these attacks will likely continue.
Read the Threat Intelligence IndexAmidst the growing cyber threats, the U.S. Department of Homeland Security (DHS) has recognized the need for more support for state and local government cybersecurity. In fiscal year 2024, DHS announced the allocation of $280 million in grant funding for the State and Local Cybersecurity Grant Program (SLCGP). This funding aims to assist state, local, tribal and territorial governments in enhancing their cyber resilience. A special emphasis has been placed on protecting critical infrastructure systems like water utilities, energy grids and emergency services.
These grants will help organizations improve monitoring systems, patch vulnerabilities and implement critical cybersecurity measures such as multi-factor authentication and regular system audits. In states like Michigan, for example, government agencies are already working with local water utilities to provide cybersecurity training and support. The DHS funding could greatly expand these efforts, offering a much-needed boost to the security posture of critical infrastructure providers.
In 2019, the Cyberspace Solarium Commission (CSC) was established by the U.S. Congress to develop a national cyber defense strategy. Currently, approximately 80% of its recommendations have been implemented. However, a final push is needed to address critical gaps, particularly regarding private-sector collaboration and insurance reforms.
One major challenge is identifying the “minimum security burdens” for systemically important entities critical to national security. This would ensure that high-priority infrastructure providers, such as key transportation systems and water utilities, receive the necessary support to prevent catastrophic events.
The CSC also highlighted the need to develop an economic continuity plan for cyber events. This would be nothing less than an incident response and resilience plan to protect the U.S. economy in the face of a major cyberattack. The commission also emphasized the need for better information sharing between government agencies, private industries and international partners to protect critical infrastructure from evolving cyber threats.
During a recent panel discussion, Senator Angus King, co-chair of CSC 2.0, pointed to the difficulties of building trust between the government and private sectors. Private entities own and operate the majority of the nation’s critical infrastructure, but historical tensions make collaboration challenging. King noted that the situation mirrors early tensions that existed between state officials and CISA. Nonetheless, the collaboration between private industry and government is essential to address the growing threat to critical infrastructure.
The cybersecurity posture of U.S. critical infrastructure remains a concern. As seen in attacks like the Arkansas City Water Treatment Facility and other incidents targeting internet service providers, threat actors are increasingly focusing on essential services. These attacks are not limited to small municipalities. Larger-scale infrastructure providers, including ISPs and managed service providers, have also been targets.
The FBI recently disclosed that China-linked hackers compromised more than 260,000 network devices, underscoring the scale of the problem. Meanwhile, attacks attributed to the Chinese government have targeted ISPs and managed service providers through vulnerabilities in Versa Networks’ SD-WAN software, demonstrating the growing sophistication of these threats.
While the U.S. government is actively working to improve critical infrastructure cybersecurity, the attacks on water treatment systems and other essential services clearly reveal that more needs to be done. The DHS grant program and the recommendations of the Cyberspace Solarium Commission represent critical steps in this effort, but collaboration between government, private industry and international partners will be key to building a resilient defense against evolving threats.
The safety of critical infrastructure remains a pressing concern. Recent events should serve as a wake-up call for operators, policymakers and the public to take action before a cyberattack occurs that impacts human life and health. Undoubtedly, the threats are real — and any meaningful response requires a concerted effort.
The post Is the water safe? The state of critical infrastructure cybersecurity appeared first on Security Intelligence.
