Kaspersky reported on June 8, 2026, that hacktivist-linked actors associated with 4BID and overlapping groups have expanded attacks beyond Russia and Belarus, using ransomware, web shells, remote management tools, and post-exploitation frameworks against organizations in Kazakhstan, the UAE, Syria, and Egypt. The finding matters because it describes a drift from cause-driven disruption toward opportunistic intrusion, where political branding and criminal tradecraft increasingly share the same operator console. For Windows administrators, the story is less about one new ransomware family than about a familiar stack of neglected Exchange servers, dual-use tools, and kernel-level security tampering being repackaged for wider use.
Hacktivism has always had a branding problem. The public face is ideological: flags, slogans, claimed enemies, and theatrical leak posts. The operational reality is often messier, especially when groups begin sharing infrastructure, scripts, malware, and access methods with peers whose incentives may not be identical.
That is the tension running through Kaspersky’s latest reporting on 4BID-linked activity. The researchers began from indicators found inside a compromised Russian organization, then used those traces to follow related intrusions into other environments. What emerged was not a tidy campaign against a single geopolitical adversary, but a cluster of overlapping operations spanning Russian and Belarusian targets as well as victims in Kazakhstan, the United Arab Emirates, Syria, and Egypt.
That geographical spread is the headline, but it is not the whole story. A hacktivist group moving into another region could be explained by politics, alliances, retaliation, or mistakes in targeting. The more important signal is the tooling: ransomware, remote monitoring utilities, EDR killers, web shells, and commodity C2 frameworks. That is not the toolkit of online protest. It is the toolkit of persistence, monetization, and operational reuse.
The report attributes some findings only with medium confidence, which is the right level of caution. The same infrastructure can be borrowed, stolen, resold, or deliberately planted to confuse attribution. But for defenders, perfect attribution is secondary. If the same scripts, C2 servers, and payload chains are appearing across unrelated geographies, the defensive lesson is already clear: the campaign has escaped the neat boundary implied by its public ideology.
ProxyShell is not a single bug so much as a chained path to compromise. In practical terms, it gave attackers a route from exposed Exchange services to remote code execution and web shell deployment. Years after disclosure, it remains useful because Exchange is hard to retire, hard to patch cleanly in some environments, and often treated as too critical to touch until an incident makes touching it unavoidable.
The attackers in this campaign used an ASP.NET web shell named fd.aspx after compromise. Its design is not exotic, but it is efficient. It checks an authentication key, accepts commands through a request parameter, runs them through PowerShell, falls back to cmd.exe where needed, and returns output over HTTP.
That simplicity is the point. A web shell on an Exchange server does not need to be elegant; it needs to survive long enough to let the operator map the host, move files, and stage the next tool. The shell’s Base64 file-transfer functions made it useful for both uploading additional payloads and pulling files back out of the environment.
The reconnaissance functions were similarly pragmatic. The shell collected OS version, hostname, domain, username, processor count, directories, .NET version, drives, free space, and file timestamps. In other words, it gave the attacker the same basic orientation a Windows admin wants when landing on an unfamiliar server — except the admin is not supposed to be there.
This is the defensive nightmare of living off trusted software. Security teams can block a known malware hash, but they cannot simply ban every remote administration platform without breaking real support workflows. The gray zone is where these operations thrive: a script installs a legitimate tool, configures it for unattended access, hides the tray icon, renames services to sound like Windows components, and then cleans up after itself.
The AnyDesk script described by Kaspersky followed the basic playbook. It checked for admin rights, looked for an existing process, downloaded the tool from the official source if needed, configured unattended access, collected the AnyDesk ID, and exfiltrated the resulting connection details. On a noisy endpoint, that can look uncomfortably close to helpdesk automation.
The Panorama9 deployment was more deceptive. The attackers reportedly modified registry settings to hide the tray icon and installation folder, then renamed services to “Windows Update Helper” and “Windows Update Helper Cache.” The names are almost insultingly bland, but blandness works. Windows fleets are full of helper services, update agents, telemetry components, and vendor utilities few administrators can identify at a glance.
Microsoft Dev Tunnels adds another twist. The service is meant to help developers expose local services securely through a cloud relay, typically without requiring inbound firewall rules. In attacker hands, that same design can become a convenient path around perimeter assumptions. A tunnel created from the inside out is a reminder that “we blocked inbound access” is not the same thing as “we prevented remote reachability.”
The scripts were not masterpieces. Some were broken. Some needed manual adjustment. But the attackers did not need pristine engineering; they needed enough automation to install tools, create users, modify RDP settings, open firewall ports, clear logs, and remove traces when finished.
That is where generative AI is changing the economics of intrusion. It does not need to produce novel exploits to matter. If it helps an operator generate ten variations of an AnyDesk installer, a persistence script, or a cleanup routine, it reduces the friction between initial access and operational control.
This also complicates defender intuition. Sloppy code used to imply a certain class of actor, but AI-generated scaffolding can make inexperienced operators look more capable in places and more careless in others. Comments may be oddly verbose. Error handling may be inconsistent. The same function may appear in slightly different forms across samples.
The result is a strange hybrid: amateurish code embedded in a professionalized intrusion chain. That is not reassuring. It means more actors can reach for techniques that used to require a stronger internal development bench.
Sliver’s appearance is unsurprising. It has become a favorite in both red-team and malicious contexts because it is powerful, cross-platform, and well documented. In the observed cases, Sliver payloads were packaged in self-extracting archives, installed through Windows Service Wrapper, and loaded through a chain involving batch scripts and a Donut-built component.
Havoc and Mythic Apollo fit the same pattern of modern intrusion tradecraft. These are frameworks built for operator control: persistence, tasking, file movement, command execution, and flexible transports. Mythic Apollo’s support for HTTP, TCP, WebSocket, SMB, named pipes, and web shells makes it especially adaptable in Windows networks where one path may be blocked but another remains available.
AdaptixC2’s presence is notable because it is newer and reflects how quickly open-source offensive tooling enters real campaigns. The samples described by Kaspersky used a custom x64 loader, decrypted embedded shellcode, and executed an AdaptixC2 Beacon with RC4-protected configuration. Capabilities included command execution, file operations, process control, data exfiltration, SOCKS forwarding, and BOF module support.
Then there is BlackSalt, the custom backdoor. Compared with the larger frameworks, it sounds almost primitive: fetch commands from a C2 server, execute them through cmd.exe, and return output. But simple implants have their place. They are easier to deploy, easier to understand, and sometimes less conspicuous than a full-featured framework.
The important point is not which framework is most sophisticated. It is that these actors appear comfortable mixing public frameworks, custom backdoors, self-extracting archives, service wrappers, and script-driven staging. That is a flexible intrusion model, and flexible models travel well.
ClearWater itself does not sound like an elite ransomware engineering project. Kaspersky describes it as a 64-bit Windows executable written in C++ and compiled with MinGW, with no obfuscation and DWARF debug information left intact. That is sloppy, but ransomware does not need to be beautiful to destroy a file server.
The encryption design follows the familiar hybrid model. The malware uses per-file symmetric encryption, then protects the symmetric key with an embedded RSA-2048 public key. It appends a marker structure to encrypted files and adds a .clear extension. The use of ChaCha20 and libsodium suggests the developers leaned on known cryptographic building blocks rather than inventing their own.
Operationally, ClearWater behaves like ransomware built to cause maximum practical pain. It scans local drives and SMB shares, drops ransom notes, modifies registry keys so the note opens on startup, changes desktop and lock screen imagery, deletes shadow copies, wipes backup catalogs, disables restore features, and tampers with startup recovery. That is the difference between “files were encrypted” and “the recovery path was attacked too.”
The malware also contains a function intended to kill non-whitelisted processes, though Kaspersky says it was not actually called during execution. That unused capability is a useful reminder that malware samples are snapshots, not final product brochures. A feature can be dormant in one build and active in the next.
Blackout Locker adds another layer to the ransomware story. Its updated version reportedly includes a screen locker component deployed alongside the background ransomware payload. That is old-school intimidation grafted onto modern extortion: encrypt the machine, lock the user’s view, create startup shortcuts and scheduled tasks, and make the system feel possessed even after a password is entered.
The technique is the now-familiar bring your own vulnerable driver model. Attackers abuse legitimately signed but vulnerable kernel drivers to perform actions that ordinary user-mode malware would struggle to accomplish. In this case, the modified EDRKiller samples targeted the vulnerable Warsaw_PM driver, while GhostDriver used an embedded RentDrv2 driver associated with CVE-2023-44976.
That matters because Windows security is increasingly a kernel contest. Endpoint agents can protect their user-mode processes, but a vulnerable driver running in the kernel can undercut those assumptions. Microsoft has pushed vulnerable-driver blocklists and related hardening mechanisms, yet the ecosystem remains full of old drivers, niche hardware utilities, and signed components with dangerous capabilities.
The process list targeted by the modified killers reads like a roll call of common defensive tooling: Microsoft Defender components, Kaspersky, Bitdefender, Avast, McAfee, Elastic, Sysmon, Wazuh, and others. The intent was not subtle. It was to blind the endpoint before payload execution, persistence, lateral movement, or ransomware detonation.
GhostDriver’s looped behavior is especially revealing. It rescans for target processes roughly every 700 milliseconds and sends termination commands through the vulnerable driver. This is not a one-shot attempt to stop an antivirus process. It is a suppression mechanism designed to fight the endpoint continuously while the operator proceeds.
For administrators, this shifts the mitigation conversation. It is not enough to ask whether Defender or EDR is deployed. The better questions are whether vulnerable-driver blocking is enforced, whether kernel driver loads are monitored, whether unexpected service creation is alerted, and whether tamper-protection events are treated as intrusion signals rather than product noise.
That does not automatically prove a clean strategic pivot by one group. Interconnected actors blur the picture. Access brokers, shared C2, borrowed scripts, common malware builders, and public frameworks can make separate operations look related. But from the defender’s side of the glass, the effect is the same: organizations outside the original ideological blast radius are now seeing the same intrusion patterns.
Kaspersky also notes that the shift correlates with a statement from a 4BID member claiming that attacking Russia was no longer profitable. That phrase, if accurately reported, is the quiet center of the article. Profitability is not a hacktivist metric. It is a criminal-market metric.
The moment actors begin discussing target selection in terms of return, the political story becomes harder to sustain as the sole explanation. Ideology may still determine branding, preferred enemies, or public messaging. But money changes the targeting logic. It pushes groups toward softer victims, richer victims, less defended victims, and geographies where attention is lower.
This is why the Middle East and wider CIS angle should worry defenders beyond those regions. Campaigns that expand once can expand again. If the same playbook works against an aviation company, a hospital, a factory, and a government-adjacent organization, there is little reason to assume it will politely stop at a border.
The attackers did not need a cinematic zero-day. They used an old Exchange chain, a web shell, PowerShell and cmd.exe, legitimate RMM tooling, service wrappers, scheduled tasks, registry changes, Dev Tunnels, and vulnerable drivers. That is a greatest-hits album of Windows enterprise tradecraft.
This is not an argument that Windows is uniquely doomed. It is an argument that Windows estates are sprawling, backwards-compatible, and full of business exceptions. Every exception becomes a place where dual-use tools can hide. Every unpatched server becomes a long-term foothold. Every “temporary” remote access workaround becomes an invitation to persistence.
The uncomfortable part for IT teams is that many of the attacker actions resemble administrative behavior. Installing AnyDesk can be legitimate. Creating a local account can be legitimate. Opening RDP can be legitimate. Creating a service with a helpful-sounding name can be legitimate. The detection problem is context: who did it, from where, on which host, after what parent process, and with what follow-on network activity.
That means defenders need less faith in tool names and more attention to chains of behavior. Panorama9 is not bad because it is Panorama9. It is suspicious when it appears unexpectedly on an Exchange server after web shell activity, hides its UI, renames services, and contacts infrastructure unrelated to the organization’s management plane.
Dual-use RMM leaves artifacts. Dev Tunnels leaves authentication and outbound domain traces. Panorama9, Tactical RMM, and Nezha create processes, services, scheduled activity, network connections, installation paths, and registry changes. These are huntable even if an organization does not use Kaspersky tooling.
The same is true of the ransomware behaviors. Wallpaper changes, lock screen modifications, shadow copy deletion, backup catalog tampering, restore disabling, mass file modification, and SMB share enumeration are noisy by design. The challenge is not that they are invisible. The challenge is catching them before the encryption job is complete.
C2 frameworks can also be hunted behaviorally. Sliver, Havoc, Mythic, and Adaptix differ in implementation, but they still produce patterns: suspicious service creation, self-extracting archive execution, memory injection, outbound beaconing, unusual child processes, and staged payload paths under directories that should not contain bespoke “update” binaries.
The fd.aspx web shell points defenders back to the edge. Exchange servers deserve file-integrity monitoring, especially under web-accessible directories. Unexpected ASPX files, PowerShell spawned by web worker processes, cmd.exe under IIS context, and outbound connections from mail infrastructure should all be treated as high-signal events.
Observed behavior says these actors can compromise Exchange, deploy web shells, stage multiple C2 frameworks, install legitimate RMM, establish persistence, disable security tools through vulnerable drivers, and deploy ransomware. That is enough to make them relevant to any organization that resembles their victims technically, even if it does not resemble them politically.
The campaign also reflects a broader convergence in the threat landscape. Hacktivists borrow from ransomware crews. Ransomware crews borrow from red teams. Red-team tools become commodity malware infrastructure. AI-generated scripts fill in operational gaps. Legitimate cloud and remote access services become covert channels.
This convergence makes labels less useful. “Hacktivist” once implied noisy disruption, website defacement, data leaks, and ideological spectacle. It can still mean those things. But in this case, the label sits beside ransomware, EDR killers, and post-exploitation frameworks — a combination that should push defenders to classify the risk by impact rather than declared motive.
The irony is that political branding may make some organizations underestimate the threat. A company outside Russia or Belarus might assume it is not in scope. A hospital in Egypt or aviation firm in Kazakhstan would now have reason to disagree.
The Politics Stayed on the Banner, but the Target List Moved
Hacktivism has always had a branding problem. The public face is ideological: flags, slogans, claimed enemies, and theatrical leak posts. The operational reality is often messier, especially when groups begin sharing infrastructure, scripts, malware, and access methods with peers whose incentives may not be identical.That is the tension running through Kaspersky’s latest reporting on 4BID-linked activity. The researchers began from indicators found inside a compromised Russian organization, then used those traces to follow related intrusions into other environments. What emerged was not a tidy campaign against a single geopolitical adversary, but a cluster of overlapping operations spanning Russian and Belarusian targets as well as victims in Kazakhstan, the United Arab Emirates, Syria, and Egypt.
That geographical spread is the headline, but it is not the whole story. A hacktivist group moving into another region could be explained by politics, alliances, retaliation, or mistakes in targeting. The more important signal is the tooling: ransomware, remote monitoring utilities, EDR killers, web shells, and commodity C2 frameworks. That is not the toolkit of online protest. It is the toolkit of persistence, monetization, and operational reuse.
The report attributes some findings only with medium confidence, which is the right level of caution. The same infrastructure can be borrowed, stolen, resold, or deliberately planted to confuse attribution. But for defenders, perfect attribution is secondary. If the same scripts, C2 servers, and payload chains are appearing across unrelated geographies, the defensive lesson is already clear: the campaign has escaped the neat boundary implied by its public ideology.
Exchange Remains the Door That Never Quite Closed
The initial-access story is depressingly familiar: vulnerable Microsoft Exchange servers, in many cases compromised through ProxyShell. That vulnerability chain is old by internet standards, but “old” does not mean irrelevant when it lives on internet-facing infrastructure with mail flow, privileged service accounts, and years of organizational inertia behind it.ProxyShell is not a single bug so much as a chained path to compromise. In practical terms, it gave attackers a route from exposed Exchange services to remote code execution and web shell deployment. Years after disclosure, it remains useful because Exchange is hard to retire, hard to patch cleanly in some environments, and often treated as too critical to touch until an incident makes touching it unavoidable.
The attackers in this campaign used an ASP.NET web shell named fd.aspx after compromise. Its design is not exotic, but it is efficient. It checks an authentication key, accepts commands through a request parameter, runs them through PowerShell, falls back to cmd.exe where needed, and returns output over HTTP.
That simplicity is the point. A web shell on an Exchange server does not need to be elegant; it needs to survive long enough to let the operator map the host, move files, and stage the next tool. The shell’s Base64 file-transfer functions made it useful for both uploading additional payloads and pulling files back out of the environment.
The reconnaissance functions were similarly pragmatic. The shell collected OS version, hostname, domain, username, processor count, directories, .NET version, drives, free space, and file timestamps. In other words, it gave the attacker the same basic orientation a Windows admin wants when landing on an unfamiliar server — except the admin is not supposed to be there.
The New Intrusion Kit Looks Like IT Work
One of the more telling parts of the campaign is not the custom malware, but the abuse of legitimate administration tools. AnyDesk, Panorama9, Tactical RMM, Nezha Monitoring, Advanced IP Scanner, and Microsoft Dev Tunnels all appeared in the broader activity set. None of those tools is inherently malicious. That is precisely why attackers like them.This is the defensive nightmare of living off trusted software. Security teams can block a known malware hash, but they cannot simply ban every remote administration platform without breaking real support workflows. The gray zone is where these operations thrive: a script installs a legitimate tool, configures it for unattended access, hides the tray icon, renames services to sound like Windows components, and then cleans up after itself.
The AnyDesk script described by Kaspersky followed the basic playbook. It checked for admin rights, looked for an existing process, downloaded the tool from the official source if needed, configured unattended access, collected the AnyDesk ID, and exfiltrated the resulting connection details. On a noisy endpoint, that can look uncomfortably close to helpdesk automation.
The Panorama9 deployment was more deceptive. The attackers reportedly modified registry settings to hide the tray icon and installation folder, then renamed services to “Windows Update Helper” and “Windows Update Helper Cache.” The names are almost insultingly bland, but blandness works. Windows fleets are full of helper services, update agents, telemetry components, and vendor utilities few administrators can identify at a glance.
Microsoft Dev Tunnels adds another twist. The service is meant to help developers expose local services securely through a cloud relay, typically without requiring inbound firewall rules. In attacker hands, that same design can become a convenient path around perimeter assumptions. A tunnel created from the inside out is a reminder that “we blocked inbound access” is not the same thing as “we prevented remote reachability.”
AI-Generated Scripts Lower the Floor, Not the Ceiling
Kaspersky’s researchers note that several scripts showed signs of AI generation, including Ukrainian-language comments and multiple broken iterations found in compromised environments. That detail should not be overplayed into a science-fiction story about autonomous attackers. It is more mundane and more important: AI-assisted scripting makes low-grade operational work faster, cheaper, and easier to iterate.The scripts were not masterpieces. Some were broken. Some needed manual adjustment. But the attackers did not need pristine engineering; they needed enough automation to install tools, create users, modify RDP settings, open firewall ports, clear logs, and remove traces when finished.
That is where generative AI is changing the economics of intrusion. It does not need to produce novel exploits to matter. If it helps an operator generate ten variations of an AnyDesk installer, a persistence script, or a cleanup routine, it reduces the friction between initial access and operational control.
This also complicates defender intuition. Sloppy code used to imply a certain class of actor, but AI-generated scaffolding can make inexperienced operators look more capable in places and more careless in others. Comments may be oddly verbose. Error handling may be inconsistent. The same function may appear in slightly different forms across samples.
The result is a strange hybrid: amateurish code embedded in a professionalized intrusion chain. That is not reassuring. It means more actors can reach for techniques that used to require a stronger internal development bench.
The C2 Menu Says This Was Not a One-Tool Operation
The campaign did not rely on a single command-and-control framework. Kaspersky observed Sliver, Havoc, Mythic Apollo, AdaptixC2, and a previously undocumented backdoor it calls BlackSalt. That variety matters because it suggests either multiple teams working in parallel, a shared toolkit culture, or operators willing to swap frameworks depending on access, detection pressure, and task.Sliver’s appearance is unsurprising. It has become a favorite in both red-team and malicious contexts because it is powerful, cross-platform, and well documented. In the observed cases, Sliver payloads were packaged in self-extracting archives, installed through Windows Service Wrapper, and loaded through a chain involving batch scripts and a Donut-built component.
Havoc and Mythic Apollo fit the same pattern of modern intrusion tradecraft. These are frameworks built for operator control: persistence, tasking, file movement, command execution, and flexible transports. Mythic Apollo’s support for HTTP, TCP, WebSocket, SMB, named pipes, and web shells makes it especially adaptable in Windows networks where one path may be blocked but another remains available.
AdaptixC2’s presence is notable because it is newer and reflects how quickly open-source offensive tooling enters real campaigns. The samples described by Kaspersky used a custom x64 loader, decrypted embedded shellcode, and executed an AdaptixC2 Beacon with RC4-protected configuration. Capabilities included command execution, file operations, process control, data exfiltration, SOCKS forwarding, and BOF module support.
Then there is BlackSalt, the custom backdoor. Compared with the larger frameworks, it sounds almost primitive: fetch commands from a C2 server, execute them through cmd.exe, and return output. But simple implants have their place. They are easier to deploy, easier to understand, and sometimes less conspicuous than a full-featured framework.
The important point is not which framework is most sophisticated. It is that these actors appear comfortable mixing public frameworks, custom backdoors, self-extracting archives, service wrappers, and script-driven staging. That is a flexible intrusion model, and flexible models travel well.
Ransomware Turns the Ideological Campaign Into a Business Problem
ClearWater ransomware is the pivot point in the story. Its presence across compromised infrastructures turns a politically framed operation into something with direct financial and operational consequences. Even if the initial motivation was ideological, the victim experiences downtime, data loss, recovery cost, and extortion pressure.ClearWater itself does not sound like an elite ransomware engineering project. Kaspersky describes it as a 64-bit Windows executable written in C++ and compiled with MinGW, with no obfuscation and DWARF debug information left intact. That is sloppy, but ransomware does not need to be beautiful to destroy a file server.
The encryption design follows the familiar hybrid model. The malware uses per-file symmetric encryption, then protects the symmetric key with an embedded RSA-2048 public key. It appends a marker structure to encrypted files and adds a .clear extension. The use of ChaCha20 and libsodium suggests the developers leaned on known cryptographic building blocks rather than inventing their own.
Operationally, ClearWater behaves like ransomware built to cause maximum practical pain. It scans local drives and SMB shares, drops ransom notes, modifies registry keys so the note opens on startup, changes desktop and lock screen imagery, deletes shadow copies, wipes backup catalogs, disables restore features, and tampers with startup recovery. That is the difference between “files were encrypted” and “the recovery path was attacked too.”
The malware also contains a function intended to kill non-whitelisted processes, though Kaspersky says it was not actually called during execution. That unused capability is a useful reminder that malware samples are snapshots, not final product brochures. A feature can be dormant in one build and active in the next.
Blackout Locker adds another layer to the ransomware story. Its updated version reportedly includes a screen locker component deployed alongside the background ransomware payload. That is old-school intimidation grafted onto modern extortion: encrypt the machine, lock the user’s view, create startup shortcuts and scheduled tasks, and make the system feel possessed even after a password is entered.
EDR Killers Are the Tell That Operators Expected Resistance
The campaign’s use of EDR killers is one of the clearest signs that these were not mere defacement crews wandering through exposed servers. Tools named kil.exe, Killer.exe, and ghostdriver.exe were found in compromised environments. Their job was to terminate security processes and keep terminating them when they reappeared.The technique is the now-familiar bring your own vulnerable driver model. Attackers abuse legitimately signed but vulnerable kernel drivers to perform actions that ordinary user-mode malware would struggle to accomplish. In this case, the modified EDRKiller samples targeted the vulnerable Warsaw_PM driver, while GhostDriver used an embedded RentDrv2 driver associated with CVE-2023-44976.
That matters because Windows security is increasingly a kernel contest. Endpoint agents can protect their user-mode processes, but a vulnerable driver running in the kernel can undercut those assumptions. Microsoft has pushed vulnerable-driver blocklists and related hardening mechanisms, yet the ecosystem remains full of old drivers, niche hardware utilities, and signed components with dangerous capabilities.
The process list targeted by the modified killers reads like a roll call of common defensive tooling: Microsoft Defender components, Kaspersky, Bitdefender, Avast, McAfee, Elastic, Sysmon, Wazuh, and others. The intent was not subtle. It was to blind the endpoint before payload execution, persistence, lateral movement, or ransomware detonation.
GhostDriver’s looped behavior is especially revealing. It rescans for target processes roughly every 700 milliseconds and sends termination commands through the vulnerable driver. This is not a one-shot attempt to stop an antivirus process. It is a suppression mechanism designed to fight the endpoint continuously while the operator proceeds.
For administrators, this shifts the mitigation conversation. It is not enough to ask whether Defender or EDR is deployed. The better questions are whether vulnerable-driver blocking is enforced, whether kernel driver loads are monitored, whether unexpected service creation is alerted, and whether tamper-protection events are treated as intrusion signals rather than product noise.
The International Victims Change the Risk Model
The expansion into Kazakhstan, the UAE, Syria, and Egypt is more than a map update. It changes how defenders should think about groups whose public identity appears regionally or politically bounded. A hospital in Egypt and an aviation company in Kazakhstan do not fit neatly into the original Russia-Belarus-centered frame, yet Kaspersky reports that the same familiar artifacts appeared there.That does not automatically prove a clean strategic pivot by one group. Interconnected actors blur the picture. Access brokers, shared C2, borrowed scripts, common malware builders, and public frameworks can make separate operations look related. But from the defender’s side of the glass, the effect is the same: organizations outside the original ideological blast radius are now seeing the same intrusion patterns.
Kaspersky also notes that the shift correlates with a statement from a 4BID member claiming that attacking Russia was no longer profitable. That phrase, if accurately reported, is the quiet center of the article. Profitability is not a hacktivist metric. It is a criminal-market metric.
The moment actors begin discussing target selection in terms of return, the political story becomes harder to sustain as the sole explanation. Ideology may still determine branding, preferred enemies, or public messaging. But money changes the targeting logic. It pushes groups toward softer victims, richer victims, less defended victims, and geographies where attention is lower.
This is why the Middle East and wider CIS angle should worry defenders beyond those regions. Campaigns that expand once can expand again. If the same playbook works against an aviation company, a hospital, a factory, and a government-adjacent organization, there is little reason to assume it will politely stop at a border.
Windows Admins Are Fighting the Afterlife of Old Decisions
The practical Windows lesson is brutally simple: old architectural decisions keep creating new incidents. Internet-facing Exchange, permissive remote administration, inconsistent RDP controls, unmanaged local administrator rights, weak monitoring of service creation, and under-enforced driver policies all show up in this story.The attackers did not need a cinematic zero-day. They used an old Exchange chain, a web shell, PowerShell and cmd.exe, legitimate RMM tooling, service wrappers, scheduled tasks, registry changes, Dev Tunnels, and vulnerable drivers. That is a greatest-hits album of Windows enterprise tradecraft.
This is not an argument that Windows is uniquely doomed. It is an argument that Windows estates are sprawling, backwards-compatible, and full of business exceptions. Every exception becomes a place where dual-use tools can hide. Every unpatched server becomes a long-term foothold. Every “temporary” remote access workaround becomes an invitation to persistence.
The uncomfortable part for IT teams is that many of the attacker actions resemble administrative behavior. Installing AnyDesk can be legitimate. Creating a local account can be legitimate. Opening RDP can be legitimate. Creating a service with a helpful-sounding name can be legitimate. The detection problem is context: who did it, from where, on which host, after what parent process, and with what follow-on network activity.
That means defenders need less faith in tool names and more attention to chains of behavior. Panorama9 is not bad because it is Panorama9. It is suspicious when it appears unexpectedly on an Exchange server after web shell activity, hides its UI, renames services, and contacts infrastructure unrelated to the organization’s management plane.
The Vendor Product Pitch Is Less Important Than the Detection Pattern
Kaspersky’s report naturally includes a section on how its products detect the activity. That is expected vendor positioning, and readers should treat it as such. But beneath the product references are detection ideas that apply across security stacks.Dual-use RMM leaves artifacts. Dev Tunnels leaves authentication and outbound domain traces. Panorama9, Tactical RMM, and Nezha create processes, services, scheduled activity, network connections, installation paths, and registry changes. These are huntable even if an organization does not use Kaspersky tooling.
The same is true of the ransomware behaviors. Wallpaper changes, lock screen modifications, shadow copy deletion, backup catalog tampering, restore disabling, mass file modification, and SMB share enumeration are noisy by design. The challenge is not that they are invisible. The challenge is catching them before the encryption job is complete.
C2 frameworks can also be hunted behaviorally. Sliver, Havoc, Mythic, and Adaptix differ in implementation, but they still produce patterns: suspicious service creation, self-extracting archive execution, memory injection, outbound beaconing, unusual child processes, and staged payload paths under directories that should not contain bespoke “update” binaries.
The fd.aspx web shell points defenders back to the edge. Exchange servers deserve file-integrity monitoring, especially under web-accessible directories. Unexpected ASPX files, PowerShell spawned by web worker processes, cmd.exe under IIS context, and outbound connections from mail infrastructure should all be treated as high-signal events.
The Real Boundary Is No Longer Ideology
The most tempting mistake is to categorize these actors by their Telegram posts, claimed causes, or preferred enemies. That may help with geopolitical analysis, but it is a weak guide for risk management. The stronger guide is capability and observed behavior.Observed behavior says these actors can compromise Exchange, deploy web shells, stage multiple C2 frameworks, install legitimate RMM, establish persistence, disable security tools through vulnerable drivers, and deploy ransomware. That is enough to make them relevant to any organization that resembles their victims technically, even if it does not resemble them politically.
The campaign also reflects a broader convergence in the threat landscape. Hacktivists borrow from ransomware crews. Ransomware crews borrow from red teams. Red-team tools become commodity malware infrastructure. AI-generated scripts fill in operational gaps. Legitimate cloud and remote access services become covert channels.
This convergence makes labels less useful. “Hacktivist” once implied noisy disruption, website defacement, data leaks, and ideological spectacle. It can still mean those things. But in this case, the label sits beside ransomware, EDR killers, and post-exploitation frameworks — a combination that should push defenders to classify the risk by impact rather than declared motive.
The irony is that political branding may make some organizations underestimate the threat. A company outside Russia or Belarus might assume it is not in scope. A hospital in Egypt or aviation firm in Kazakhstan would now have reason to disagree.
The Signal Inside 4BID’s Broader Footprint
The most concrete lesson from this campaign is that defenders should stop treating hacktivist scope as self-limiting. Once tooling becomes reusable and financial incentives enter the picture, the target set can widen quickly.- Organizations should treat old Exchange vulnerabilities as active operational risk, not historical cleanup work.
- Security teams should baseline approved remote management tools and investigate surprise installations of AnyDesk, Panorama9, Tactical RMM, Nezha Monitoring, and similar utilities.
- Administrators should monitor Dev Tunnels and other outbound tunneling services because perimeter firewalls do not help if access is brokered from inside the network.
- Endpoint teams should enforce vulnerable-driver protections and alert on suspicious kernel driver loads, especially when followed by security-process termination.
- Incident responders should treat unexpected RMM deployment, web shell activity, and shadow copy deletion as parts of one intrusion chain rather than isolated alerts.
- Executives should understand that political branding does not prevent an actor from behaving like a financially motivated ransomware crew.