For security researchers studying unconventional side-channel attacks, acoustic keylogging is something of a Hello World: a foundational problem that’s been tackled many times. A recent paper authored by researchers across three Japanese universities cites six previous studies on the topic that date as far back as 2004. While earlier experiments showed theoretical promise, they came with real-world caveats so severe that it made them all but impractical for actual espionage. The authors of this latest study, however, claim to have overcome most of those limitations. Today, we look at how they pulled it off, and assess whether their method holds up in real-world scenarios.

What makes this new approach different?

Previous acoustic keylogging techniques were fundamentally flawed. Best-case scenarios required prior training on the target’s specific keyboard model. Worst-case scenarios required a complex microphone array to isolate the subtle acoustic differences between keystrokes. Crucially, almost all prior models failed outside silent environments, which rendered the attack vector virtually useless.

The Japanese research team demonstrated reliable keystroke interception even if the target was sitting nearby in a public space, sound was being recorded in an online meeting, or the researchers were using a contact microphone to eavesdrop through a wall. All this with strong model accuracy and a minimal training dataset. Their process needs a sample of just 150 to 200 keystrokes to reach a 99% accuracy rate for subsequent typing.

How to crack 200 keystrokes in under 50 iterations

To understand how the researchers achieved such high accuracy and adaptability, we have to look at their audio processing pipeline. Their analysis begins by automatically segmenting a raw recording into discrete keystrokes. This data is then passed through a specialized algorithm that simplifies the subsequent audio analysis. Next, the system clusters together acoustically similar signals. The assumption is that the members of one cluster map to the exact same key. One particularly intriguing takeaway was isolating the spacebar sound from all the rest. Because the spacebar produces a distinctly unique sound profile compared to other keys, identifying it provides reliable word boundaries. This streamlines the next phase: feeding the preprocessed acoustic data into specialized language models for inference.

Yes, the method relies on not one but two language models. The first model performs multiple passes over the audio stream to map acoustic signatures to potential keyboard characters. During each pass, the model leverages dictionaries to hypothesize character mapping, and check whether the resulting text aligns with standard words. The second model handles the final refinement pass: it ingests thoroughly pre-processed data rather than raw inputs. The method doesn’t stop there: unrecognized keystrokes undergo manual analysis, with analysts injecting educated guesses before re-running the recognition pipeline once again. The goal of looping through these multiple iterations is to achieve complete recognition across the keyboard from an ultra-compact dataset of ideally no more than 200 captured keystrokes. This marks a major shift from legacy methods, which relied on massive training datasets.

Research results

To validate their theoretical model, the researchers created an experimental testing setup:

The team tested four distinct laptop models, each producing unique acoustic keyboard signatures. Participants typed 2400 characters per experiment, with analysts extracting audio samples ranging from 50 to 400 keystrokes. Across all devices, the system reliably reconstructed typed text from a baseline sample of just 150 keystrokes or more. Recognition accuracy exceeded 80% at 150 keystrokes, and approached 100% once the sample reached 200 keystrokes.

The researchers achieved nearly identical results in field-like conditions with the microphone placed three meters away from the target device. Going a step further, the team successfully tested an even higher-friction scenario: using a specialized contact microphone to eavesdrop through a physical wall.

Under these conditions, accuracy dipped slightly for certain laptop models. Dell and Lenovo devices yielded roughly 80% accuracy over a 200-keystroke sample, while Apple and HP ones maintained nearly 100% recognition rates.

Remote interception during videoconferencing presented an additional variable: results depended on both the target laptop model and the specific web conferencing software used. Even so, most test scenarios yielded reliable character recognition, though a few edge cases required expanding the sample size from 200 to at least 250 keystrokes.

Reasonable critique

Despite these impressive results, the technique has clear limitations. First, all experiments were conducted strictly on lowercase English text. The target dataset was capped at just 29 characters: the standard alphabet, spacebar, period, and comma — even number keys were excluded. As a result, capturing randomized character strings like complex passwords remains a major hurdle. Yet these are precisely the targets threat actors care about most.

However, the Japanese research team didn’t ignore passwords. While recognition accuracy was predictably low, the authors proposed assessing success through a more realistic lens. For starters, attackers can almost always capture audio of other typing activity alongside password entry. This provides a stream of natural language with minimal special characters. Factoring this broader acoustic context into the password analysis significantly improves the odds of a successful guess.

Next, the researchers rightly noted that even a list of several candidate passwords increases the chances of compromising a target account. As shown in the graph above, when ample data (426 keystrokes) is captured, a short five-character password can be successfully cracked within 100 attempts with a 90% success rate. Naturally, longer passwords proved far more resistant to eavesdropping.

Despite its limitations, this study represents a major breakthrough in acoustic side-channel attacks. It demonstrates a highly practical threat scenario: an attacker captures a brief audio recording of typing activity, then uses iterative analysis and targeted manual adjustments to process and refine the data offsite.

While eavesdropping in a noisy restaurant or through a wall is likely difficult to scale, capturing keystrokes during virtual meetings for offline decoding represents a realistic attack scenario. Ultimately, this research offers a compelling proof-of-concept: modern algorithms can drastically improve the accuracy of acoustic reconnaissance.

The news coverage surrounding the breach of the AI platform Hugging Face by OpenAI’s autonomous agents reads like a scene straight out of a Terminator movie (apparently, a prequel). Yet for enterprise security teams — even those that don’t develop or deploy artificial intelligence — the detailed incident report published by Hugging Face provides a critical operational roadmap. The incident needs to be evaluated on the basis of a single, fundamental question: “Which organizational security flaws, missing controls, configurations, or technologies allowed this attack to succeed?”

What happened?

During cyber-capability testing of OpenAI’s advanced AI models against the ExploitGym benchmark, an agent found a way to break out of its confinement, reached the internet, and breached the infrastructure of several companies — one of them being Hugging Face. The model reasoned that it could find solutions to the benchmark challenges on these external systems. Dozens of articles have since covered these incidents in detail, so no need to go over that here. What truly matters is what transpired within Hugging Face’s systems between July 9 and 13 while the AI agent operated unchecked inside. The Hugging Face incident report includes an interactive attack timeline, so we’ll just list the key stages. A malicious configuration in a dataset uploaded by the agent allowed it to exfiltrate credentials for a worker pod, and execute code within it. The agent then exploited cloud environment metadata and escaped the privileged pod to obtain root-level access on the host. It retrieved a substantial number of secrets from storage and used a stolen VPN key and shared cluster administrator credentials to pivot deeper into the internal network and source code repository before the Hugging Face security team blocked its access.

How significant is the fact that this was next-generation AI?

Regardless of the specific area of ​​activity of a company, tomorrow it may become a target of human attackers, fully autonomous systems, or AI agents manually controlled by human hackers.

Many AI practitioners have rushed to dismiss this incident based on assumptions that OpenAI will never allow its tech to get into serious hacking. However, security researchers have argued for months that even currently available open-source models can be used to launch both offensive research and real-world attacks. Human oversight, while still a requirement, can be minimal. Even mid-tier models can easily iterate through a dozen vulnerabilities, inventory a compromised infrastructure, and quickly figure out how to expand their reach across a network. Defenders must analyze incidents like this in detail, map the key findings to their own environments, and adapt security controls to counter both stealthy human actors and rapid, noisy AI agents.

Three distinguishing features of AI-powered attacks

The techniques detailed in the Hugging Face report are not novel — the agent didn’t invent anything new. However, three factors regarding the attack’s speed and scale fundamentally shift the economics for both attackers and defenders:

• Trial and error becomes significantly cheaper. Where a human hacker might test five attack vectors, an agent can iterate through five hundred. Scenarios that security teams previously dismissed as “theoretically possible, but impractical and unlikely” and placed them on the backlog can now become active threats.
• Attack execution and incident response windows shrink. High-speed attacks are not unheard of, while some ransomware operators achieve compromise within hours even without AI. However, this accelerated pace will likely become the new baseline in cybersecurity, as demonstrated by the agent obtaining admin privileges at Hugging Face within 13 hours.
• Numerous alerts and log entries generated by the agent’s trial-and-error attempts can both help and hinder attackers as well as defenders. This noise can serve both as an indicator for threat detection, and as camouflage to hide meaningful actions. It also acts as a natural bottleneck for incident response when the workflows are fully manual.

How to protect corporate infrastructure

Don’t ignore alerts from triggered defensive controls. This classic mistake — often highlighted by our incident response experts — was made at Hugging Face as well. Malware execution, port scanning, WAF triggers, requests to non-allowlisted resources, and failed authentication attempts are likely some of the event types that are blocked automatically. However, all these events are often categorized by SIEM systems as purely informational and routinely ignored. In the Hugging Face incident, numerous server-side request forgery (SSRF) attack attempts were successfully blocked over several days, yet no one batted an eyelash. Much like persistent human adversaries, the AI agent continuously retried until it succeeded. To detect such attacks, establish clear rules and triage workflows for defensive alert telemetry to ensure that priority automatically escalates when event volume spikes.

Investigate rapidly escalating error counts. Legitimate operations rarely generate hundreds of authentication failures within 10 minutes across four distinct systems. Analyze historical baselines, and generate medium or high-severity alerts depending on the deviation from normal error rates. As part of automated response protocols, you can temporarily block the user or system that is generating the anomalous activity, or enforce rate-limiting on them.

Configure escalation paths and conduct security team drills. Hugging Face’s correlation engine successfully detected the attack, yet it failed to grab the human operators’ attention. During security drills, organization must evaluate how quickly key personnel respond to critical incidents — even when these happen during off-hours such as at night on weekends.

Isolate services — internal ones included — that process untrusted input by design. The primary vulnerability at the start of the attack was a node configured to process machine learning datasets, which are widely known for potentially containing executable code. This node, capable of executing untrusted code, operated without a sandbox or adequate isolation controls. The risk extends beyond machine learning — to document conversion engines, image processing pipelines, user file upload handlers, and any other server-side processes that perform deserialization or template rendering. Any server-side execution of this nature must run under maximum feasible isolation, restricted from accessing external or internal network hosts beyond an absolute minimum, and ideally enclosed within a sandbox.

Restrict egress. Most organizational servers don’t require unrestricted connectivity to arbitrary external hosts. If implementing strict default-deny egress policies presents technical challenges, consider a streamlined approach: enforce DNS traffic resolution exclusively through your enterprise DNS server, and configure it to block known public services that are commonly abused as command-and-control infrastructure or exfiltration channels such as Pastebin or OneDrive. Similar outbound restrictions can also be enforced via an NGFW.

Avoid issuing large batches of secrets, or storing them as a single object. Even with secret managers in place, an attacker can gain broad access if a compromised account holds excessive permissions. In the Hugging Face breach, a single Kubernetes Secret object contained 136 keys. The fewer secrets issued, the lower the impact of a compromise — and the easier key-rotation becomes.

Avoid long-lived secrets and don’t store them in environment variables that are inherited by all child processes.

Isolate applications from metadata servers. Most cloud environments run services — such as the EC2 Instance Metadata Service — that issue credentials and system details upon request. Isolating these from arbitrary applications — via firewall rules or by enforcing IMDSv2 — eliminates the most direct path from a single application compromise to a full account takeover.

Audit server and application identities. Service accounts with broad access, OAuth tokens, cross-environment keys, and other artifacts granting excessive privileges are most frequently found in server and app identities rather than human user accounts.

Track usage of credentials at anomalous entry points. In the Hugging Face attack, credentials assigned to an internal host were leveraged from an external one. Detection rules that flag these anomalies are straightforward to implement and deliver high-fidelity, low-noise signals of an attack that’s already progressed beyond its initial stages.

Use short-lived, single-use keys when provisioning new devices and services. During the incident, a single key was used to register 181 separate devices without triggering a single alert.

Sooner or later, every company faces the need to upgrade its infrastructure — whether to accommodate expansion, optimize processes, or keep up with the latest trends in IT. When such a decision is made, company management typically thinks first and foremost about broad changes at the platform level — assuming that applications can simply be reinstalled and everything will work as before. And to a certain extent, that’s actually true. In an era when corporate security could be ensured solely by antivirus software on workstations, that would have worked; however, modern cyberthreats require protection at a fundamentally different level.

In this post, we explore why platform migration should be discussed with the security team as well, and why simply “installing a program” isn’t enough to ensure modern-day protection.

Security is no longer just a single program

In the past, securing endpoints was enough to prevent most attacks. In today’s environment, endpoint protection is just one layer of cybersecurity. A modern extended detection and response (XDR) solution isn’t a single application installed on a computer; it’s a set of components that work in conjunction. They provide protection for workstations and servers, event logging and storing, infrastructure-level threat detection mechanisms, investigation tools, automated response, reporting, and asset management. Each component serves a specific purpose and places different demands on the hardware and platform.

For the event storage system, disk speed is the most critical factor. In a large company, the security system generates millions of records per day, and all of them must be written quickly and then retrieved just as quickly when needed. The bottleneck here usually isn’t processor capabilities, but rather how fast the system can read and write data.

Threat detection requires computing power. The system compares events in real time and determines what can be a sign of an attack, and what is normal operational activity.

Response time is critical for investigation tools. When an analyst investigates an incident and pieces together what happened, they work in real time, and every second of waiting adds to the overall response time to the attack.

What does this mean? When a company switches platforms, it’s not enough to simply verify that the company’s existing cybersecurity solutions support the new architecture. The answer “yes, it’s supported” is too vague. It’s essential to clearly understand exactly which parts of the cybersecurity architecture are supported — starting from which version, and what is still under development.

What to ask before it’s too late

To avoid unexpected complications during implementation and operation, we recommend asking the right questions in advance — during the planning phase. Here are those questions:

Which specific components have been tested on the new platform?

The question shouldn’t be phrased as “Is the platform supported?”; the compatibility of each part of the system should be verified. Different components of a modern information-security solution operate under different rules, which is why their compatibility is tested separately. A one-word “yes” answer should raise a red flag: a reputable vendor will always provide a detailed response — including a list of components and any caveats (where applicable).

Will there be sufficient resources to handle the company’s workload?

“It will run” and “it will handle needed data volume” are two fundamentally different statements. The former is verified in a lab on a test bench; the latter depends on how many events specific infrastructure generates per day, and how long the company is required to retain them under regulatory or internal policies. It makes sense to ask the vendor for recommendations on calculating resources based on specific data volumes rather than relying on general minimum resource requirements when planning.

Is the security solution up to date?

It’s always important to clearly understand which version of the cybersecurity solution supports the new platform. It’s not uncommon for different parts of the infrastructure to be protected by different builds of the same solution. Sometimes this is because new features didn’t seem particularly critical; other times it’s because the IT security team was waiting for a convenient time to update so as not to disrupt business processes. If the security team won’t verify right away that all builds already support the new platform, the IT department may suddenly find itself having to make urgent changes to the migration schedule because updating the security solutions will require its own maintenance window and approvals. It’s better to find this out at the start of the project rather than deep into the process.

Are there any licensing restrictions?

Sometimes the availability of certain features depends not only on the product version but also on the specific licenses the company has purchased. It’s more cost-effective to clarify this during the design phase.

None of these questions require in-depth technical knowledge; a project manager can easily ask them. But when asked at the right time, they eliminate most of the unpleasant surprises that usually surface during the implementation of a new platform.

How do we help?

We’re constantly expanding the list of platforms supported by our solutions, and strive to describe their compatibility in as much detail as possible — like versions, component composition, and honest disclaimers where applicable. For example, the latest versions of Kaspersky NEXT XDR Expert and Kaspersky NEXT EDR Expert now support the Nutanix 7.3 hypervisor.

For companies planning to build their infrastructure on this platform (or migrate over to it) this means one thing: the compatibility issue goes from being a roadblock to being resolved. There’s no need to postpone securing the infrastructure until the migration is complete, or to deploy cybersecurity solutions in an untested configuration — cybersecurity is now integrated into the migration project on a par with other systems.

The full technical requirements for our security solutions are always available in the documentation; it’s always worth reviewing them before deployment schedules are finalized.

Leveraging legitimate software is one of cybercriminals’ tactics of choice, with remote management tools ranking among their top tools. A recent example involves the remote administration utility ScreenConnect. It’s designed for IT support teams to troubleshoot systems and configure software seamlessly in the background. However, when weaponized by threat actors, ScreenConnect becomes a versatile attack vehicle used to harvest data, deploy malware, and move laterally across corporate networks.

During a recent incident detected by Kaspersky Managed Detection and Response, our experts identified an attempt to use ScreenConnect in an attack. This allowed a detailed study of how attackers used this application in a large-scale malware distribution campaign. The following breakdown illustrates the mechanics of ScreenConnect-assisted attacks, and outlines key strategies to defend your organization against them.

How ScreenConnect reaches target computers

In the campaign analyzed by our experts, the attackers bundled ScreenConnect with legitimate free business software. They established a network of phishing websites to spoof popular tools, including OBS Studio, DS4Windows, DNS Jumper, Glary Utilities, Bandizip, Process Hacker, and others.

These rogue websites featured high-quality designs that could be taken for the official pages, making them highly convincing to unsuspecting users. Once the victim clicks the download button for the software, an archive is downloaded to their computer that contains additional files alongside the requested application:

• A legitimately signed Microsoft executable (exe), renamed to match the expected application installer (for example, OBS-Studio-Installer.exe)
• A malicious library named res.1033.dll
• An Assets directory containing installers for both ScreenConnect and the intended application

Launching the renamed file disguised as the app installer triggers DLL sideloading of a malicious library. This library silently runs the ScreenConnect installation without restarting the system, while using the standard Windows installer to set up the software the user originally tried to install.

The attackers used search engine optimization techniques to drive traffic to their fake websites. As a result, these malicious pages appeared at the top of search results for certain free software utilities on major search engines.

Our experts discovered over 90 domain names translated into more than 10 different languages. While most of these websites targeted English, Russian, and Chinese speakers, several domains catered to German, French, Spanish, Arabic, and other regional audiences.

A detailed analysis of the IP addresses and associated spoofed domains is available in our technical research article on Securelist, along with full indicators of compromise.

Why the attackers exploited ScreenConnect

In this campaign, attackers leveraged ScreenConnect to generate and execute malicious scripts on victim machines. These scripts served several key functions: they created exclusions for specific drives, directories, and processes within Windows Defender, disabled the User Account Control (UAC) security mechanism, and delivered and deployed AsyncRAT – a remote access Trojan.

To maintain persistence, the scripts configured a Windows scheduled task to run the malicious code at preset intervals. AsyncRAT then established a connection with the attackers’ command-and-control server to receive further instructions.

The primary objective of this campaign appears to be gaining unauthorized access to enterprise systems, likely to then resell it on cybercrime marketplaces.

How to secure corporate infrastructure

Although ScreenConnect in and of itself is a legitimate tool, its presence poses a security risk to corporate environments. Consequently, Kaspersky security solutions detect this application as not-a-virus:HEUR:RemoteAdmin.MSIL.ConnectWise.gen.

Security teams should implement the following controls:

• Enforce strict application control policies, including software allowlisting and restrictions on MSI package installations from unverified sources
• Monitor for newly installed remote management utilities and scheduled tasks
• Filter outbound network traffic from workstations to unknown IP addresses and domains

As noted previously, this campaign was originally detected through the Kaspersky Managed Detection and Response service, which can be employed to protect against such threats.

Cybersecurity news increasingly focuses on attackers using AI for reconnaissance, vulnerability hunting, and writing scripts or malware. Against this backdrop, a less conventional category of attacks remains largely overlooked: threat actors leveraging AI tools that are already deployed within the target infrastructure.

AI agents designed for coding, as well as command-line tools — such as Claude Code CLI, Gemini CLI, Codex CLI, Amazon Q CLI, and the like — are particularly attractive targets. These agents can read and modify files, execute shell commands, install packages, and connect to external services. Developers frequently allow them to run in autonomous mode to avoid manually confirming every action. For an attacker, such an agent becomes a ready-made multitool that has the right privileges, access to critical data, and security clearances from the get-go. That said, other types of AI agents, such as automated financial workflow assistants, are equally vulnerable to exploitation.

Why trusted agents pose a threat

An AI agent differs from standard software in its broad access privileges, the wide array of ways it can be prompted to execute actions, and the difficulty of detecting its anomalous behavior. Enterprise security controls (EPP, EDR, XDR, SIEM) scan for malicious files, known command patterns, and suspicious action sequences. Even if a specific strain of malware hasn’t been seen before, its behavior often gives it away: bulk searches for documents, spawning PowerShell processes, accessing credential stores, or exfiltrating data to an external server from an unknown application will trigger a deluge of alerts in the SOC.

It’s much harder to apply that same detection logic to a legitimate, pre-installed AI agent. By design, these tools are capable of executing an extremely broad range of operations. Running scripts, reading configuration files (including secrets), moving documents, and installing dependencies can all be a part of their normal operation — especially on a developer’s machine.

When an attacker attempts to exploit this kind of AI system, they use natural language to convey their instructions to the agent. A request to hunt for passwords, API keys, or cryptocurrency wallets can be framed in thousands of ways, expressed in a variety of languages, or phrased indirectly. Furthermore, a malicious command can be hidden in any data stream the agent reads — including text fields in documents, file names, or even error logs, as shown in one of the examples below.

Integration between agents and third-party software further expands the attack surface. Agents are frequently connected to email, instant messaging apps, task management systems, knowledge bases, and MCP servers. As a result, a malicious instruction can originate from virtually any source whose data the agent processes automatically.

Below are several examples of attacks where threat actors leveraged AI agents to achieve their goals.

The Nx attack: a coding agent hunting for passwords

The most prominent and widespread example is the compromise of Nx npm packages in August 2025, dubbed s1ngularity. Attackers exploited a vulnerable GitHub Actions workflow, stole a package-publishing token, and released trojanized versions of several @nx packages that harvested developer secrets.

The malicious post-install script checked whether Claude Code, Gemini CLI, or Amazon Q CLI were installed on the victim’s machine. If any of these were detected, the agent was issued an instruction to scan for cryptocurrency wallets, ENV files, API keys, and other sensitive data. The agents were executed with auto-approval flags enabled, such as --dangerously-skip-permissions, --yolo, and --trust-all-tools.

The search results were then exfiltrated to public GitHub repositories created by the attackers. Over several waves of the attack, thousands of secrets belonging to hundreds of organizations were exposed.

Instead of developing a complex, custom harvesting tool, the attackers repurposed the victim’s own legitimate agent. It already could navigate the file system, understand file context, and identify high-value target data. However, post-incident analysis by security experts revealed drawbacks to this approach: the AI occasionally refused to carry out unethical tasks. Furthermore, the malware authors had to adjust their code so that it “waited” for the AI agent, which could take a considerable amount of time to process the task while generating significant intermediate output.

Communication via… error logs

The AgentJacking study was not a malicious attack, but it differed from one only in intent: its authors had no interest in stealing secrets. After developing the attack technique, the researchers tested it on a global scale and received callback responses from AI agents belonging to more than a hundred real-world companies — some of them major enterprises.

The attack targeted Sentry, a widely used telemetry service. Websites and mobile applications automatically transmit error reports to Sentry so developers can monitor issues without requiring active user reporting. These reports are accepted without authentication because errors often occur for anonymous visitors that the site or application knows nothing about.

The researchers configured their own MCP server within Sentry, allowing AI agents to analyze reports automatically. Next, they submitted a fake error message containing a data block formatted to match Sentry’s MCP server data structure. Embedded inside was an indirect prompt injection — an instruction to run “additional diagnostics” via a command like: npx @controlled-validation-package --diagnose.

If error handling were delegated to an agent, it could take the instruction as legitimate and execute a command resulting in the automatic installation of a third-party package. In this experiment, the package merely contacted the researchers’ command-and-control server without exfiltrating any sensitive data. A genuine malicious package, however, could steal credentials, tamper with code, or establish persistence in the system. Identifying targets for such an attack is equally straightforward: an organization’s use of Sentry is easily detectable by analyzing website code or checking the strings in mobile application binaries.

Notably, according to the study’s authors, Sentry acknowledged the issue but stopped short of implementing comprehensive fixes, opting instead to block only the specific variant of the malicious query routed through the MCP. Screenshots included in the study reveal that a Sentry employee described the system as “technically not defensible” against the attack.

Stealing financial data via MCP

Abusing unsecured MCP servers — as seen in the Sentry case — is just one way to attack this protocol. Introduced just a year ago, and already dubbed “USB for AI agents”, the Model Context Protocol standard was adopted rapidly without robust built-in security controls. As a result, attacks targeting MCP are bound to proliferate — a trend Microsoft recently warned about.

Threats can lie hidden even within the description of an MCP tool before the agent ever uses it. Agents parse tool descriptions to determine when to call the tool and what data to supply. If an MCP server provider stealthily alters a description — adding an instruction that demands collection of additional data — the agent may execute it as part of its standard workflow.

Microsoft highlights a scenario involving a financial agent that verifies vendor banking details via an external MCP service. Following a malicious update to the tool’s description, the agent begins appending unpaid-invoice data to its responses. The user sees a normal response, while confidential financial data is quietly exfiltrated to the server owner. Individually, each operation appears authorized: the agent operates under the employee’s permissions, queries an approved service, and uses a standard interface. Yet a data breach still occurs.

It remains unclear from Microsoft’s ambiguous phrasing whether this example is purely hypothetical or based on an investigation into a live incident. However, the fact that the post originated from Microsoft Incident Response points to the latter.

Prompt injections have already gone mainstream

In 2026, Unit 42 researchers identified widespread attempts to covertly embed instructions designed for AI systems across numerous public websites. Many of these instructions aim to force models to reveal system prompts, approve sites and posts during ad placement reviews, or boost phishing pages through SEO manipulation.

Similarly, an analysis of Common Crawl data by Google recorded a surge in such material: between November 2025 and February 2026, the share of malicious injections increased by 32%.

That said, confirmed cases of successful compromise using these techniques remain scarce. The presence of an injection on a webpage does not guarantee that an agent ever actually executed the command. Nevertheless, threat actors have clearly begun optimizing web content for an era when it will be read not just — and perhaps not primarily — by humans.

How to defend against agent-based attacks

The key takeaway for cybersecurity teams and all AI users alike is simple: an AI agent should never be considered trusted merely because it has been officially approved for enterprise use.

Organizations must:

• Maintain an inventory of agents, MCP servers, and the various tools available for them. Use allowlists to restrict agent tools, and package installations to components explicitly vetted and approved by information security. Allowlists must specify exact package versions.
• Monitor version changes to MCP tools and other dependencies. Re-evaluate updates before adding them to the approved inventory.
• Apply the principle of least privilege. Grant agents only the specific permissions needed for a given task, and only for the duration of that task.
• Enforce human-in-the-loop approval for package installations, script executions, file sends, and other high-risk actions.
• Run agents in isolated environments with limited access to developer workstations.
• Disable dangerous auto-approval modes.
• Restrict outbound network connections, and permit data transmission only for approved services.
• Store secrets in centralized, secure vaults, using short-lived tokens and rotating them regularly.
• Forward prompt logs, tool calls, shell commands, and agent network traffic into SIEM and XDR systems. For these tools to be effective, they require deep operational context regarding agent activity alongside specialized rule sets tailored to AI data processing pipelines.

Cybercriminals are increasingly moving away from complex malware, relying instead on social engineering that exploits a common user habit: mindlessly clicking through endless digital rituals like CAPTCHAs, cookie consents, and authentication prompts. This habit is often targeted by various kinds of the ClickFix technique, which threat actors have been actively using lately. Researchers recently discovered a new variant of this technique, which they dubbed ConsentFix. It allows attackers to gain unauthorized access to Microsoft 365 accounts via OAuth — a highly popular vector right now — thereby completely bypassing the need to steal passwords. For organizations, these attacks present a severe risk of compromised corporate email, exposed documents, and breached cloud resources.

How ConsentFix works

Social engineering lies at the core of all ClickFix variations. Attackers prompt the user to follow a seemingly harmless set of instructions, which actually lead to the compromise of their device or account. In the case of ConsentFix, these instructions are designed to trick the user into granting the attacker access to their Microsoft 365 account.

The attack begins by making the user believe they must authenticate with their Microsoft account to access a specific page or document. To do this, cybercriminals usually send an email containing a link to a website typically imitating a popular file-sharing service. Attempting to access a specific document on this site prompts the user for verification, which can be obtained by following this sequence of actions:

1. Clicking Verify with Microsoft.
2. Signing in to the work account, at which point the attackers warn that multi-factor authentication (MFA) may be required.
3. After being redirected to a new page, waiting until “localauth” appears in the address bar.
4. Dragging the information icon ⓘ from the browser’s address bar into a drop zone on the page.

In practice, following these instructions causes the user to drag an URL containing a session OAuth token directly onto the attacker’s page. This token is exactly what grants the attackers access to the victim’s email and other Microsoft 365 services.

The potential fallout of a Microsoft 365 session compromise

At first glance, it might seem like attackers only gain access to a mailbox. In reality, the consequences can be significantly more severe. The attacker’s specific capabilities depend on the organization’s Microsoft 365 license, the services deployed, and the privilege level of the compromised account.

Even basic corporate Microsoft 365 subscriptions typically grant access to Outlook, Teams, OneDrive, and SharePoint, while more advanced tiers may include additional services and administrative tools.

Even compromised corporate email alone is a major breach. The attacker not only gains access to email archives that may contain confidential business intelligence, but also can send phishing messages or launch internal BEC attacks on behalf of the user.

Beyond email, attackers are highly likely to gain access to the victim’s Microsoft Teams account, providing them with even deeper insights and broader leverage for various scams. Access to OneDrive and SharePoint is equally dangerous: it allows attackers to exfiltrate corporate documents, upload malware into cloud storage, tamper with existing files, and more. Ultimately, this creates a launchpad for moving laterally within the corporate infrastructure.

Publicly available attack blueprints

According to a Bleeping Computer article, the mechanics of ConsentFix are no secret. Attackers share detailed implementation guides on cybercrime forums, offering not only ready-to-use code but also video tutorials demonstrating how to deploy the attack. They also actively trade tips on how they harvest intelligence on organizations and their employees via LinkedIn and other OSINT channels to craft highly convincing phishing messages.

Collectively, this significantly lowers the barrier to entry for novice cybercriminals. As these guides and turnkey tools continue to proliferate, ConsentFix attacks will likely become increasingly common. Consequently, organizations should immediately factor this technique into both their defense strategies and employee awareness training programs.

How to secure your corporate infrastructure

The emergence of this new ClickFix variation demonstrates that simply blocking a specific keyboard shortcut or an isolated risky action on employee devices is not enough. Clearly, attackers quickly adapt to these measures. Therefore, to protect an organization from these types of attacks, we recommend the following:

• Be sure to deploy a robust security solution at the mail gateway level — this minimizes the likelihood of attackers successfully luring your employees to a page hosting the ConsentFix mechanism.
• Conduct regular cybersecurity awareness training for employees to keep them ahead of the latest social engineering tactics. Our training platform, Kaspersky Automated Security Awareness Platform, can assist with this initiative.

When targeting an organization to steal information, maintaining a low profile is critical for attackers. They typically aim for long-term persistence, which requires avoiding security alerts while preserving access in case they’re detected and the organization initiates incident response or routine password resets. Malware such as infostealers or ostensibly legitimate remote monitoring and management (RMM) tools fail the first requirement: their use triggers EDR and generates suspicious events in SIEM consoles. Relying on stolen credentials conflicts with the second requirement: the moment the security team suspects a compromise, passwords can be changed immediately — terminating access. If attackers attempt to steal browser cookies instead of passwords, they face a different challenge: many online services now correlate device characteristics with the expected session cookie and block access if the cookie is used on an unrecognized device. Furthermore, cookie theft protection mechanisms implemented in Chromium-based browsers (such as Chrome, Edge, and Opera) this year have made this approach significantly more difficult.

To address this persistence challenge, the ToddyCat APT — whose main game is spying — developed a novel technique. Kaspersky experts discovered this method during an incident investigation and named it Shadow Token via Remote Debug (STRD). This technique allows the attackers to establish reliable, persistent access to a victim’s mailbox and other resources in Google Workspace. With minor adjustments, the same approach could potentially be adapted to target other services that grant third-party application access via OAuth 2.0 authentication.

How an STRD attack works

First, the attackers must compromise the victim’s system with malware. In past campaigns, ToddyCat gained initial access to organizations by exploiting known vulnerabilities in server software and distributing malicious loaders via messaging apps. The specific employee targeted by the attackers might not notice the intrusion at all. This can occur, for example, if the adversary first obtains privileged administrative credentials and uses them to deploy the malware onto targeted machines remotely. Crucially, the deployment and execution of this malware mustn’t trigger immediate security alerts.

Once active, the malware executes an STRD attack, connecting the attackers’ remote service to the victim’s mailbox using the OAuth 2.0 protocol. This process requires no user interaction and shows no visible activity on the screen. To the cloud environment (Google Workspace, in the case at hand), the activity appears as if the user has legitimately authorized a third-party app for email access or data backup.

After that, the malware can terminate its operations and even delete itself from the system. The adversary retains direct access to the mailbox using the acquired OAuth token — and they need no connection to the victim’s endpoint or to the corporate network for that. Depending on the organization’s Google Workspace configuration, this access can persist for an extended period and survive subsequent password resets.

The core concept of Shadow Token via Remote Debug

At the heart of this attack is a connection to Google Workspace services via OAuth 2.0. This is a legitimate workflow used whenever a third-party application requests access to calendar data, emails, or Google Drive files. For example, to display calendar meetings in Zoom and automatically generate conference links, a user must authorize Zoom to access Google services. Similarly, configuring a third-party email client or calendar app requires granting permission. During this authorization process, the service requesting access opens a new browser window. In this window, Google Workspace first prompts the user to select the appropriate account. Once the account is chosen, the subsequent screen displays the specific permissions requested by the third-party app, allowing the user to either approve or deny access. For this scenario to proceed seamlessly, the user must already be authenticated to Google services in their browser — which is typically the case in organizations using Google Workspace. If the user isn’t authenticated, additional steps for entering credentials and completing multi-factor authentication are introduced into the sequence.

The ToddyCat hackers developed a malicious tool called Umbrij to facilitate a two-step covert authorization process when the user is already authenticated in Google. First, the malware identifies the browsers installed on the system, and locates the specific folder storing the user’s active profile for each. The attackers target Chrome and Edge, as these are the browsers most likely serving as the primary ones within the organization.

Next, Umbrij copies the entire user profile folder to a different directory on the machine. It then launches an instance of the browser, specifying the path to the duplicated profile via the command line. Because this duplicate profile contains the user’s session cookies, websites with saved credentials won’t prompt for re-authentication. Furthermore, since this occurs on the exact same computer where the primary browser is running, online services detect no anomalies. The browsing history for this newly launched instance is isolated within the new folder, keeping it hidden from the user’s main account activity.

Crucially, the browser is launched in a dedicated debugging mode typically reserved for web development. The browser window and user interface don’t appear on the screen at all (headless mode). Instead, the browser can be controlled through a debugging port using the DevTools protocol, allowing the malware to issue commands and read the state of the screen. To orchestrate these actions, Umbrij leverages Puppeteer, a legitimate automation library.

After verifying that the debugging browser instance has launched successfully, Umbrij opens a legitimate Google Workspace OAuth screen within it. The request sent to Google is engineered to bypass additional security checks while requesting maximum access privileges. For the application ID — the identity supposedly requesting these extensive permissions — the malware impersonates one of two legitimate tools: Google Workspace Migration for Microsoft Outlook (GWMMO), or Google Workspace Sync for Microsoft Outlook (GWSMO).

When Google opens the window within the headless browser, Umbrij uses debugging tools to programmatically click on the corporate account name and the confirmation buttons. As a result, Google generates an authorization code for the app. Umbrij extracts and saves this code, subsequently forwarding it to the attackers’ command-and-control server. Finally, operating entirely within their own infrastructure rather than on the victim’s computer, the attackers exchange this authorization code for an OAuth access token. This single token is all they need to maintain long-term unrestricted access to the mailbox.

How to protect against OAuth token theft

If a Google Workspace account is compromised, incident response measures must include the following steps after collecting the necessary logs and other forensic data for investigation:

• Resetting the affected user’s password
• Terminating all active web sessions for the user
• Revoking OAuth tokens and third-party app permissions
• Reviewing and removing access granted through legacy App Passwords

In addition, security and IT teams must systematically audit issued OAuth permissions, revoke unjustifiable access rights, and restrict capabilities that allow excessive or unauthorized permission grants. We covered this topic in detail in our article on blocking unwanted AI assistants.

How to prevent exploitation of Shadow Token via Remote Debug

While Kaspersky users are protected against the Umbrij tool, security teams should proactively implement policies that prevent standard users from launching browsers in debugging mode. This functionality is intended exclusively for website and web app developers. This restriction can be enforced through the DeveloperToolsAvailability group policy (available for both Chrome and Edge).

Additionally, configure monitoring within your SIEM/XDR to track the launch of browser instances with an active debugging port. This event serves as a strong indicator of this specific attack technique.

The concept of a completely autonomous security operations center (SOC) — where data collection, analysis of suspicious events, investigations, and incident response happen without human intervention — is extremely compelling. This is especially true for organizations grappling with a chronic shortage of cybersecurity talent and a threat landscape that’s growing faster and more sophisticated by the day. Organizations everywhere would welcome an approach where automation helps relieve analyst workloads, shortens alert triage times, and finally eliminates the backlog of unaddressed alerts — which, by some estimates, accounts for 67% of all security events in the average corporate SOC.

While many vendors are already pitching solutions in this space, real-world implementation remains highly problematic. Practitioners report tangible success when using these tools for alert enrichment and filtering out low-priority noise or false positives. However, when it comes to autonomous decision-making and response, very few organizations have managed to achieve a meaningful return on investment.

Foundational roadblocks of an autonomous SOC: looking beyond AI

While leveraging AI for data analysis and decision-making sounds like a logical and relatively easy-to-implement idea, actually putting it into practice exposes and amplifies the exact same challenges organizations faced with SIEM, XDR, and SOAR platforms:

Source data quality. Issues with coverage, enrichment quality, tagging and normalization, which detection engineering teams in every SOC battle daily, become even more acute when AI is introduced. AI agents are more sensitive to data gaps than human analysts, so incomplete data can magnify the resulting errors.

Data consolidation and tool integration. The very problem SIEM was once invented to solve remains a headache for most organizations today. Interestingly, marketing for AI-driven SOCs often claims that “the SIEM is dead” because “agents can just query the EDR directly for telemetry”. In reality, however, even in a best-case scenario, this just means the SIEM disappears as a user interface while its core functions remain embedded within the data fabric of the agentic SOC.

Analysts’ trust. Even when AI is restricted to preliminary data gathering and recommendations, human analysts frequently don’t trust the output, leading them to waste time re-collecting and re-analyzing the same data. Practitioners frequently point to several flaws in current AI SOC implementations: poor handling of gray-area verdicts (when an alert is suspicious but not definitively malicious), lack of safe escalation workflows, and systems that fail to learn when a human analyst corrects their mistakes.

Context deficit. SOCs and security teams in general naturally rely on scantily documented information, such as business context and tribal knowledge, to accurately assess alerts and incidents. It’s very difficult to populate an AI system with that knowledge in a systematic way.

AI-specific issues critical for a SOC

Beyond traditional operational hurdles, fully autonomous SOCs face inherent flaws deeply rooted in the fundamental architecture of language models and AI agents.

Hallucinations and prompt injections. In a SOC environment, a single manipulated log field can easily become a viable exploit vector aimed directly at the agent. In a semi-autonomous setup, an AI hallucination is just a frustrating distraction that erodes analyst trust. In a fully autonomous SOC, however, a hallucination can trigger instantaneous, harmful actions across hundreds or thousands of endpoints simultaneously. A prime example of this risk is the widely cited incident at a Fortune 50 company, where an AI agent went rogue and rewrote access policies on its own.

Need for control. To combat hallucinations and over-automation, organizations typically rely on a human-in-the-loop (HITL) model to approve an agent’s actions. While this improves safety, it completely defeats the primary selling point of agentic AI: response times.

Compliance, audits, and accountability. The inherently stochastic nature of LLM outputs makes logging problematic. They often lack reproducibility and explanations. Consequently, an autonomous SOC will likely struggle to pass regulatory compliance audits. Simply put, current compliance frameworks were never designed to handle the unpredictable behavior of multiple interacting AI agents.

Strategies to overcome the challenges of an autonomous SOC

Specialized frameworks are emerging to address these built-in flaws of AI agents and language models. For the most part, these solutions focus on enforcing formal boundaries around AI privileges, and validating its actions.

Rigorous context engineering. Assuming source data is correct and properly enriched, the number of hallucinations can be minimized, and agent decision quality significantly improved by feeding the language model structured layers of context — such as alerts, user accounts, asset data, and enrichment data.

Narrowing the scope of work. AI agents are less likely to go off the rails when confined to highly repetitive, narrow tasks. For example, an “agent for collecting additional host data” is going to be more effective than an “autonomous threat hunter”.

Neurosymbolic validations and guardrails for agent actions. An Agent-Lock pipeline cleans untrusted log fields, and verifies proposed actions against existing CMDB/IAM policies. This approach enforces key rules, such as making it impossible for the AI to disable telemetry, while managing “autonomy budgets”.

Tiered autonomy over all-or-nothing automation. The Trusted Autonomy framework maps out progressive levels of AI independence based on human-in-the-loop roles and trust thresholds across monitoring, detection, and response. Low-risk operations like data enrichment and alert deduplication run fully automated, while high-blast-radius actions require mandatory human approval.

Governance-first architecture. The LanG platform, which utilizes a hierarchical approach: Governance → MCP → Agentic AI → Security, is one example. It enforces two mandatory human analyst check-ins, fully aligning the workflow with NIST SP 800-61 guidelines. The trade-off, however, is that this framework significantly scales back the solution’s autonomy.

Deterministic execution for high-risk actions. Triage and investigation are handled by a probabilistic AI model, but high-impact actions — like deciding to isolate a host or terminate a session — are based on deterministic code. This approach allows the system to satisfy the strict requirements of SOC 2 and other major regulatory frameworks.

Stateful admission control. For example, the recently proposed ACP protocol monitors behavioral patterns across agent execution logs. This makes it possible to catch rogue agents that are executing a series of individually harmless requests that add up to a coordinated attack.

Key takeaways and pitfalls

We can already confidently state that an autonomous SOC is highly unlikely to bring any improvements for organizations burdened by significant technical and operational debt in areas like data collection and enrichment or standardized incident response workflows. No layer of AI infrastructure will function without that baseline foundation firmly in place.

It’s also clear that, while AI streamlines analyst workflows, it doesn’t completely replace them. This is why Gartner’s prediction that there will never be an autonomous SOC still rings true in 2026. Deploying autonomous agents into the SOC shifts the center of gravity to complex investigations, but most importantly, to complex engineering. Teams will simply trade fine-tuning detection rules for managing AI agent playbooks, data pipelines, and decision-handling workflows.

For mature SOCs, the core hypothesis for the next one to two years is this: an autonomous SOC should be viewed as a direction rather than a destination. AI is already delivering tangible value today — specifically in correlation, enrichment, draft detection rules, and attack reconstruction — provided that each capability has proper security guardrails. These include a well-balanced human-in-the-loop review process for any action that impacts production environments. Security teams investing now in a structured, verifiable approach — one that actively anticipates emerging regulations — will be able to gradually integrate new agentic features into their SOC pipelines. Conversely, organizations that skip this layer will almost certainly run into roadblocks, likely forcing them to rebuild their systems and processes from the ground up.

Scientists at Graz University of Technology in Austria recently published a paper detailing a new method for tracking users’ activity through their web browsers. The most fascinating thing about this new technique — which they’ve named FROST — is that it relies on a computer’s solid-state drive (SSD) to do the spying. Without getting bogged down in technical details, here’s how the attack works: a hacker lures a victim to a specially crafted website; as long as the site is kept open, the attacker can track exactly what apps the user is launching, and what other web pages they’re visiting.

So, how do they pull this off? The first instinct is naturally to blame the browser. But in modern web browsers, every website runs in an isolated sandbox and is generally locked out from touching other tabs — let alone the computer’s actual hardware. While hackers do find loopholes in these defenses from time to time, that’s not what’s happening here. The FROST attack doesn’t need to break the browser; it works perfectly even with all standard security measures in place. Instead, it hijacks a completely legitimate browser feature called the origin private file system (OPFS), which gives websites their own virtual storage space to store data. However, while this storage is digitally isolated, the data is still physically written to the exact same SSD that every other app and website opened on the computer is using. The researchers discovered that if a malicious page constantly bombards the SSD with data requests, the microscopic delays in data access can help map out what else is running on the PC. Before we dive into the details of how they manage this, let’s take a quick look at the theory behind the attack.

A quick primer on side-channel attacks

The term “side-channel” refers to a method of spying on a computer — or even a single microchip — indirectly. Instead of intercepting the data itself, an attacker might analyze fluctuations in power consumption, monitor the temperature of specific components, or listen in on electromagnetic radiation, among other things. In theory, this means that someone could eavesdrop on a conversation in a room just by using a computer mouse, since the optical sensor can pick up sound vibrations. Similarly, watching a CPU’s clock speed fluctuate could allow a hacker to steal an encryption key. Even a simple LED light on a badge reader can leak enough data about the device’s inner workings for an attacker to clone a smart card.

The beauty of these indirect data leaks — at least from a hacker’s perspective — is that they’re not easy to spot. Device manufacturers rarely account for them when building security systems. The downside, however, is just as obvious: extracting information through a mechanism that was never meant for data transmission is often complex, slow, and laborious. The Austrian researchers focused on a specific subtype known as a contention side-channel attack. This is where a leak occurs because multiple processes are competing for the same resource. In this case, that contested resource is the storage drive’s bandwidth.

Inside the FROST attack

This specific side channel has actually been studied before, including in a 2025 research paper. Back then, however, the setup was rather straightforward: the researchers ran one program on a computer to act as the data source, while a second program running on the same machine tried to intercept that data. While that’s fine for a theoretical academic study, the attack model wasn’t exactly groundbreaking. After all, if a hacker can already run any program they wish, they don’t need to rely on complex side channels — they have plenty of direct ways to steal the data.

Still, last year’s study wasn’t a complete waste of time. It proved that the resolution obtained from monitoring an SSD is quite high, the data leak is real, and the captured information can actually be useful. The FROST attack is essentially a logical continuation of the same idea.

Here’s how it works in practice. Let’s say there’s a fairly large file on an SSD packed with random data. A specific process reads this data at regular intervals and clocks how fast it gets a response. This speed fluctuates depending on how busy the drive is with other tasks. These access delays are the telltale signs of the drive’s activity. The Austrian researchers demonstrated that plotting these delays over time can help pinpoint with reasonable accuracy what other task is running on the computer at that very moment.

The researchers mapped out latency graphs, like the ones shown above, for a wide variety of websites and locally running apps. What they found were distinct patterns — or digital fingerprints — generated every single time a specific site loads, or an app launches. Capturing these split-second launch or load windows requires monitoring the SSD continuously over a long period of time. However, these patterns proved to be remarkably consistent across different systems; the authors successfully tested their method on both a Linux desktop and an Apple Mac Mini. From there, the next step sounds simple enough: take a catalog of known fingerprints, measure real-world SSD delays, match the two up, and you know exactly what apps the user is opening, and what sites they’re visiting. But how to actually pull off this kind of surveillance under the radar, without planting malware on the victim’s computer?

And that’s where a relatively new browser feature called the origin private file system (OPFS) comes into play. A hypothetical attacker doesn’t have to trick the user into downloading a shady Trojan. All they need do is have the victim visit a specially crafted webpage, and that page will leverage OPFS to quietly track the SSD’s activity. The clever acronym brings all these moving parts together: FROST stands for Fingerprinting Remotely using OPFS-based SSD Timing. Here’s the step-by-step breakdown of how the entire attack plays out:

Method limitations

Like any side-channel attack, FROST isn’t exactly built for speed. It’s a slow, methodical process. To figure out just how slow, the researchers built a dedicated testbed to measure it.

The team ran a program on a computer to transmit data indirectly. Think of it as a digital spy broadcasting a secret message by changing how it interacts with the hard drive. For instance, a 1 in the binary message code could mean the program is actively using the SSD, while a 0 means it’s sitting idle. At the same time, they set up a receiver inside the web browser that accessed the storage drive via OPFS. Because both the browser receiver and the transmitter program were competing for the SSD’s bandwidth, the browser experienced tiny speed delays whenever the transmitter was actively sending data.

This bizarre setup managed to transmit data at 661 bits per second, with nearly 90% accuracy on a Linux desktop with an AMD processor. On an Apple Mac Mini running macOS, the transfer rate hit 719 bits per second, also hovering around 90% accuracy. While these numbers are slightly lower than those in last year’s study — which relied on apps installed directly on the computer — the gap isn’t actually that huge.

That said, the real threat of the FROST attack isn’t raw data transmission; it’s tracking what the user does. Even if a hacker has a database of digital fingerprints for specific apps and websites, the information leaked through a malicious site using OPFS is too noisy. After all, a computer is constantly reading and writing data from/to the SSD in the background. To slice through that digital noise, the researchers turned to a tool that’s becoming standard practice in modern cyberattacks: a neural network. AI trained on known SSD fingerprints could confidently pick out user activity even from a chaotic mess of background data. The final results are eye-opening. On the Apple Mac Mini, the AI accurately identified which website the user opened 89% of the time, and nailed local app launches with 96% accuracy. Crucially, it could even detect what websites were opened in a completely different browser than the one running in the malicious tab. It sounds like a total home run for hackers — except for a massive list of real-world catches.

Is the FROST attack a real-world threat?

Simply knowing which apps are opened or what websites are visited doesn’t give an attacker much leverage. This kind of data is usually useful to advertisers looking to build a user’s digital profile without their permission; however, rolling out this tracking method on a massive scale is hardly realistic. The roadblock comes down to the fundamental way computers handle data: the system regularly dumps frequently accessed data into its RAM. Because the entire FROST attack relies on measuring the relatively slow bandwidth of the physical SSD, the data in RAM is effectively invisible to this method. To bypass this hurdle, the malicious webpage would have to force the OPFS to create a massive file — well over a gigabyte in size. Needless to say, a website that hogs hard drive resources in such an aggressive way would immediately raise red flags. EDR or XDR solutions will most likely flag it as anomalous activity.

Ultimately, this means the FROST attack — like most side-channel spying methods — is only practical for highly targeted operations. But that brings us right back to square one: knowing what apps someone opens or what web pages they browse is a pretty measly reward for the massive effort required to pull off such a sophisticated stunt.

Even so, FROST is light-years ahead of most academic side-channel attacks when it comes to real-world practicality. It doesn’t require preinstalled malware, and the victim doesn’t have to do anything more than open a malicious page. If nothing else, this research is a stark reminder of just how complex modern computers are, and how many unexpected blind spots can lead to data leaks. When building ultra-secure systems for highly classified data, one absolutely has to consider hardware peculiarities. If the prize is big enough, a determined attacker will gladly invest the time to build a hyper-specific complex attack. Research like this serves as proof that, in the world of cybersecurity, that scenario isn’t impossible.

Unchecked AI in the workplace quickly becomes a massive loophole for data leaks and security breaches. All too often, employees drop sensitive company data into public chatbots, or install rogue AI assistants on their own — in the process handing over way too much access. In a previous post, we broke down the different types of risky AI systems, and later shared some tips on how to turn off the built-in AI features on major tech platforms. Today let’s take a look at practical ways to block or restrict the unauthorized “helpers” employees might be using — from ChatGPT and Grammarly, to meeting bots like Fireflies and Read AI.

How to detect and restrict ChatGPT

ChatGPT is the biggest culprit when it comes to unauthorized AI use worldwide. A quick word of warning, though: an outright ban only sends users hunting for sketchy third-party sites or messaging app chatbots that hook into the same service. That’s why it’s always a good idea to offer an approved alternative before pulling the plug.

Detecting it: keep an eye on the NGFW or web filter for traffic heading to chat.openai.com, chatgpt.com, oaistatic.com, oaiusercontent.com, or cdn.oaistatic.com. It’s also smart to use EDR/EPP tools to scan browser histories, installed apps, and browser extensions across corporate devices.

Locking it down: use the firewall or web filter to block the entire AI Services category, and set up DNS to reroute traffic away from those OpenAI domains. Browser policies can also be used to ban ChatGPT-powered extensions. Better yet, block all extensions not on a pre-approved allowlist. Finally, use application controls and EPP solutions to stop users from installing the official desktop app (ChatGPT.exe or com.openai.chat).

How to detect and restrict Claude and Claude Code

Detecting it: use the NGFW or web filter to track traffic going to claude.ai, anthropic.com, *.anthropic.com, and api.anthropic.com. EDR/EPP or application control tools can also be used to scan employee computers for the desktop app (claude.exe).

Locking it down: drop a blanket block on the AI Services category through the NGFW or web filter, and tweak DNS settings to reroute traffic away from the aforementioned Anthropic domains. Next, use browser policies to shut down Claude-powered extensions. Finally, use application controls and the EPP platform to prevent users from installing the desktop app.

How to detect and restrict Perplexity AI

Detecting it: keep tabs on the NGFW or web filter to flag any traffic heading to *.perplexity.ai or pplx.ai.

Locking it down: just like the others, add the AI Services category to the NGFW or web filter blocklist, and use DNS routing to redirect traffic away from those domains.

Configure the browser to block third-party extensions from being installed. If Firefox is used in the organization, be aware that recent versions come with Perplexity built in. Luckily, these AI features can be turned-off company-wide using enterprise policies — specifically, by setting SidebarChatbot = blocked. The full list of tweaks can be found in the Firefox documentation.

How to detect and restrict DeepSeek

Detecting it: keep an eye on the NGFW or web filter for traffic hitting deepseek.com, chat.deepseek.com, api.deepseek.com, or platform.deepseek.com. For better precision, analyze the SNI (server name identification) in TLS connection requests. For mobile devices, look out for the official app (com.deepseek.chat).

Locking it down: blocklist the AI Services category on the NGFW or web filter, and reroute traffic to DeepSeek’s domains via DNS settings. Use browser policies to block third-party extensions, and lean on MDM/EMM tools to restrict the mobile app.

How to detect and restrict Mistral, xAI Grok, and Character.ai

The playbook for these tools is exactly the same as DeepSeek, so here’s the quick list of domains to watch for and block: chat.mistral.ai, mistral.ai, console.mistral.ai, grok.com, x.ai, api.x.ai, character.ai, beta.character.ai, and c.ai.

A quick word of warning on Grok: because Grok is baked into X, blocking this specific AI access point means blocking the entire social media platform.

How to detect and restrict Slack AI

Detecting it: in the Slack workspace admin dashboard, look under Analytics → Slack AI usage. If an enterprise plan is used, the detailed Slack logs can be searched for any events starting with the ai_ prefix.

Blocking it with policies: in the organization’s Slack settings, click through the Workspace settings → Roles & permissions → Feature access, and change the permission to “no one”. Slack has a step-by-step guide in their help center.

Locking it down: shutting this down at the network level is tricky; it can be pulled off with a finely tuned CASB solution in place. Also, don’t forget the importance of blocking rogue integrations and keeping external AI services from tapping into Slack data in the first place. We covered how to lock this down using OAuth controls in a previous post.

How to detect and restrict Zoom AI Companion

Detecting it: if a corporate Zoom subscription is in use, just head to Admin Center → Reports → AI Companion usage. Detecting Zoom’s AI when employees join external meetings or use free accounts is a lot tougher, but email filters can be set up to flag incoming AI-generated meeting notes by scanning for subject lines or text containing “Meeting summary” or “Meeting assets”.

Blocking it with policies: for the company’s own Zoom subscription, go to the Admin Portal → Account Management → Account Settings → Meeting → AI Companion and toggle it OFF for everyone.

Locking it down: unfortunately, AI Companion is baked into Zoom’s DNA, so the only real option is blocking Zoom altogether.

How to detect and restrict Grammarly

What looks like an innocent spellchecker is actually one of the biggest culprits for workplace data leaks.

Detecting it: check the NGFW or web filter logs for traffic hitting grammarly.com, *.grammarly.com, and gnar.grammarly.com. EDR and MDM/EMM tools can also be used to hunt down the standalone desktop apps (Grammarly Desktop.exe and the macOS version), as well as the Grammarly browser extension.

Locking it down: use firewalls to block those domains at the network level, and EPP to stop employees from installing the desktop app, browser extensions, or the Grammarly add-ins for Microsoft Word and Excel.

How to detect and restrict meeting assistants: Fireflies, Read.ai, Tactiq, Fathom, and Granola

This massive category of third-party SaaS tools records and analyzes meetings — creating a massive risk for data leaks. The trickiest part? Outside clients or vendors can bring these bots into a meeting just as easily as employees can.

Detecting them: run an audit on calendar invites, and look for bot participants using email domains like @fireflies.ai, @read.ai, @tactiq.io, @fathom.video, or @granola.ai. Zoom, Teams, or Google Meet logs can also be used to review external participants who joined past calls.

Locking them down: since it’s impossible to control what outsiders do, blocking these bots comes down to tightening meeting rules. The best moves are: blocking users from granting OAuth permissions for bots to join calls, restricting employees from inviting unapproved external participants, or locking down meeting recording access for external users. That last option is usually the least painful way to keep bots out without disrupting business.

How to detect and restrict AI code editors: Cursor, Windsurf, and the like

Detecting them: use EDR/EPP tools to scan for executables like cursor.exe or windsurf.exe. It’s also worth monitoring network traffic heading to cursor.com and windsurf.com, as well as traffic hitting various AI model API providers. Keep in mind that there’s a pretty extensive list of API hosts to monitor here, since these editors aren’t tied to just one specific AI vendor.

Blocking them with policies: these apps can be prevented from being installed by setting up filters based on the developer’s digital signature certificate. Alternatively, a strict application allowlist can be employed where only pre-approved software is allowed to run.

Locking them down: rely on the EPP/EDR platform to actively detect and block these applications from running.

How to detect and restrict local AI tools: Ollama, LM Studio, and GPT4All

On one hand, this category carries fewer data leak risks because the AI models run completely locally on the user’s machine. On the other hand, it opens up a whole new can of worms: these apps themselves aren’t always highly secure, and can become targets for cyberattacks. Plus, it still means that employees can misuse models or process data in unauthorized ways.

Detecting them: EDR/EPP tools are the best line of defense here. They should be used to flag known local AI files and processes like ollama.exe, ollama serve, lmstudio.exe, LM Studio.app, jan.exe, or gpt4all.exe. From a network perspective, it’s worth scanning for open ports on local devices — typically port 1234 for Ollama and LM Studio, or port 8080 for WebUIs (using an additional fingerprint check of the server response). Another massive red flag is the presence of large files (often several gigabytes) containing language model weights. Look out for extensions like .gguf, .bin, or sometimes .safetensors.

Locking them down: use EPP/EDR platforms or windows AppLocker to block these applications by name, or switch to an application allowlist.

How to detect and restrict autonomous agents: OpenClaw, NemoClaw, and NanoClaw

This is easily one of the most dangerous categories of AI tools out there. These agents mix high-level independence with access to untrusted data, making them a massive security headache.

Detecting them: use EPP/EDR tools to sniff out active processes like openclaw, nanoclaw, nemoclaw, or clawdbot. Also keep an eye out for devices running Node.js that suddenly start launching Bash or Python scripts. Another dead giveaway is the appearance of system folders like ~/openclaw, ~/nanoclaw, ~/.claw*, or ~/clawhub. At the network level, monitor connections to the AI model APIs we mentioned earlier, as well as traffic hitting servers like openclaw.ai, nanoclaw.dev, or clawhub.*.

Locking them down: the safest bet is to use strict application allowlisting (only allowing approved software to run), or to specifically ban the known agent apps listed above. On top of that, consider blocking non-developers from installing Node.js and Docker, neither of which they need on their computers anyway.

Lately, software developers have been baking AI features straight into everyday work tools, operating systems, and browsers. In some cases, they’re genuinely handy. However, their presence introduces specific risks, which means plenty of companies are hesitant to give employees access to these tools. In a previous post, we categorized these unwanted AI systems, looked at how to spot them at the network and endpoint levels, and covered the ultimate universal kill switch: managing OAuth access across major corporate platforms. In this deep dive, we’re getting tactical: breaking down how to disable or restrict the AI built into popular platforms.

A quick heads-up: major software vendors occasionally change the names of their AI settings and tweak how they function. If any of the options mentioned below are missing or aren’t working as expected, a quick web search for the setting’s name will usually point you to its new location or branding.

How to turn off Microsoft 365 Copilot

Detection: you can check actual Copilot usage in the logs by going to Microsoft 365 admin →  Copilot usage report.

Disabling via policies: in the Microsoft 365Admin Center, go to Settings →  Integrated Apps, find Copilot in the Available Apps list, and select Block. More granular configuration policies are available under Customization →  Policy Management. The Policies page here contains over two thousand entries, so you’ll want to filter them by the keyword “Copilot” (detailed guide). Given that Copilot is a paid add-on for Office, another way to block it — and save money by doing so — is to simply avoid assigning users SKUs that include Copilot.

We recommend separately blocking Copilot Chat, which is available in Teams, Edge, Outlook, and several other services. Yes, it’s not Copilot itself. And yes, it has to be blocked separately by following this guide.

Additional layer of protection: you can block the domains copilot.cloud.microsoft and m365.cloud.microsoft/chat at the web filter or NGFW level. However, Microsoft explicitly advises against this, warning that it could break other Microsoft 365 features.

How to turn off Windows Copilot

Beyond the Office version of Copilot, you also need to manage its consumer-facing cousin.

Detection: look through your NGFW or other network logs for traffic hitting copilot.microsoft.com, bing.com/chat, or edgeservices.bing.com.
Disabling via policies: in Windows Group Policy, navigate to Computer Config →  Admin Templates →  Windows Components →  Windows Copilot. In Microsoft 365 Group Policy, go to Admin center →  Block consumer Copilot for organizational accounts.

Additional layer of protection: block the Copilot.exe executable from running entirely.

How to turn off the Copilot sidebar in Edge

Detection: look through your NGFW or other network logs for traffic hitting copilot.microsoft.com, bing.com/chat, or edgeservices.bing.com.

Blocking: configure the following MS Edge Group Policies: HubsSidebarEnabled = false, EdgeShoppingAssistantEnabled = false, CopilotPageContext = Disabled (false), CopilotNewTabPageEnabled = false, Microsoft365CopilotChatIconEnabled = false, GenAILocalFoundationalModelSettings = 1 (note that disabling this unexpectedly requires a 1 instead of a 0).

Second layer of protection: block the domains copilot.cloud.microsoft and m365.cloud.microsoft/chat at the web filter or NGFW level. However, Microsoft explicitly advises against this, warning that it could break other features.

How to turn off the Gemini Assistant in Google Workspace

Detection: check the Workspace Admin Console (admin.google.com), Gemini usage report section.

Blocking via policies: in the Admin Console, navigate to Apps →  Additional Google services → > Gemini app, and set it to OFF. Then, go to Manage Workspace smart feature settings →  Smart features in Google Workspace, and set it to OFF.

Second layer of protection: block network traffic to the domains gemini.google.com, bard.google.com, and aistudio.google.com.

How to turn off Gemini in Google Chrome

Detection: check your Chrome Enterprise reports (Chrome management →  Reports), or look through network traffic logs for connections to the previously mentioned domains.

Blocking via policies: in your Chrome Enterprise policies, configure the following settings: GenAILocalFoundationalModelSettings = 0, HelpMeWriteSettings = 2 (disabled), TabOrganizerSettings = 2, CreateThemesSettings = 2, DevToolsGenAiSettings = 2.

Additional layer of protection: block network traffic to the domains gemini.google.com, bard.google.com, and aistudio.google.com. Additionally, block unauthorized Chrome/Chromium installations (those outside your policy management) with the help of host-based application control tools like EPP/EDR or AppLocker.

How to turn off Apple Intelligence

Detection: on your NGFW and web filters, traffic hitting apple-relay.apple.com and *.apple-cloudkit.com is a clear indicator that Apple Intelligence is active.

Blocking via policies: any managed Apple device allows you to disable individual AI features, though there isn’t a master switch you can flip to shut down “all AI”. In your MDM profile, you need to set the following keys to false (disabled): allowWritingTools, allowMailSummary, allowGenmoji, allowImagePlayground, allowImageWand, allowPersonalizedHandwritingResults, allowExternalIntelligenceIntegrations, allowExternalIntelligenceIntegrationsSignIn, allowNotesTranscription, and allowNotesTranscriptionSummary. Here is a brief configuration example:

<dict>
<key>PayloadType</key>
<string>com.apple.applicationaccess</string>
<key>allowWritingTools</key>
<false/>
<key>allowMailSummary</key>
<false/>
</dict>

Despite Apple’s shift toward declarative device management, these AI features still need to be managed through traditional MDM payload settings.

Second layer of protection: block network traffic to the hosts mentioned above — though the obvious downside for mobile devices is that this won’t work once they leave the corporate network.

The Future of Threat Defense Resides at the IP Layer

For years, network security operated on a relatively predictable premise: inspect traffic, identify malicious content, and block it. Because deep content inspection created a seemingly robust defense in depth, relatively static legacy approaches—like reliance on threat intelligence feeds—were allowed to simply persist in the background.

The weaponization of agentic AI and highly evasive techniques has fundamentally shattered that model. Attackers are no longer just iterating on old threats. They are launching attacks at staggering velocity, completely outpacing threat feeds, and employing evasion tactics that actively starve legacy prevention solutions of the content they rely on to inspect.

Our new research report from Unit 42, Attackers Are Evading Threat Prevention at the Internet Edge, reveals how adversaries are actively exploiting the contextual vacuum at the IP layer to bypass standard security controls. For security leaders, understanding this shift is no longer optional. As the nature of the threat fundamentally changes, our strategic approach to network security must definitively change with it.

The AI-Accelerated, Evasive Attack Lifecycle

To understand why legacy defenses are failing, we must look at how adversaries are accelerating and obfuscating every stage of the attack lifecycle. As these threats progress, the commonly used network indicators we have long relied upon are vanishing, collapsing traditional defenses and leaving defenders with little to act on.

Powered by frontier AI, adversaries now automate reconnaissance and exploitation at huge scale and speed, while using anonymizers to mask their intent. Once an intrusion is launched, orchestration shifts to highly evasive command and control (C2). Attackers hide communications using advanced encryption and AI-built malware-less techniques. They’re also bypassing traditional web and DNS inspection entirely by routing traffic directly to IP addresses—a tactic Unit 42 found in 23% of modern malware

Ultimately, the takeaway is clear: network threat prevention can no longer rely solely on detecting malicious payloads. As AI-driven attacks continue to minimize their footprint, security strategies must augment content inspection with real-time IP layer monitoring to left-shift threat detection and counter these rapid, machine-speed threats at the network foundation.

Existing Approaches Aren’t Working

Where content-based detection falls short, many security vendors and organizations still rely on IP threat intelligence feeds to pick up the slack in an attempt to filter out malicious connections on the network layer. However, after years of operating under this model, the results are in—the traditional feed is showing its age.

Attackers have long relied on proxies, anonymizers, residential routers and public cloud providers as a tactic to evade detection. However, agentic AI morphs this process, enabling rapid infrastructure rotation and stealth at an unprecedented scale. As this autonomous evasion accelerates, experienced network defenders continue to run into the well-known limitations of classic IP blocklists:

• Too slow to keep pace: Unit 42 found an average 20-day lag time before new threats hit popular feeds. Because agentic AI enables adversaries to autonomously rotate proxy IPs in hours, these lists are obsolete at the moment of delivery.
• Fundamentally incomplete: IP feeds are unable to see a massive portion of the modern attack surface. Unit 42 research indicates that 52% of malicious IPs used for direct-to-IP connections are completely absent from these lists.
• Unactionable on shared infrastructure: Even known threats are often impossible to block. The Unit 42 team reports that 37% of direct-to-IP traffic uses reputable CDNs and cloud providers. IP feeds cannot distinguish malicious connections from legitimate ones, making blocking too risky for business continuity.
• A management nightmare: Among the security teams that Unit 42 polled, 30% indicate resource-intensive vetting and false-positive triage as their top pain point. To avoid breaking legitimate traffic, feeds are frequently relegated to an alert-only mode, defeating the entire purpose of prevention.

If modern and agentic AI-enabled attacks can outrun traditional network payload-based detections, we need a new weapon in the network defender’s arsenal. We can no longer depend on yesterday’s IP feeds to secure such an extremely agile threat environment.

The Blueprint for Modernizing the Internet Edge

To outpace the impact of agentic AI and advanced evasion on network threat prevention, security leaders must redefine their defense strategy and shift-left to track the attacker infrastructure itself—monitoring the exact IP layer locations where adversaries build and control their campaigns. Deep content inspection remains essential, but securing the modern edge requires establishing the context and intent of a connection before a session is established.

To achieve this goal, organizations must move beyond the limitations of static defense and adopt a modern security blueprint:

• Proactive protection against attacker infrastructure: While high-quality threat feeds remain essential for SOC investigations and incident response, relying on them for frontline, real-time prevention creates major blind spots. Instead, security teams must use real-world, global telemetry to proactively identify and block connections to attacker-controlled hosts before requesting a URL or file.
• Zero trust principles applied to the network layer: An IP address without a negative reputation does not equal a safe connection. Continuous verification requires extending zero trust down to the network foundation. It validates the real-time behavior and intent of every single session to ensure attackers cannot hide in the contextual vacuum of the IP layer.  
• Reducing the attack surface with rich contextual attributes: Traditional IP blocking is like a blunt instrument that creates unacceptable false positives and alert fatigue. To modernize the edge, security teams need deep, attribute-based visibility across the entire Internet address space to reduce noise and replace legacy IP feeds entirely.  

By moving away from point-in-time assumptions and embracing real-time, inline protection, security leaders can reclaim the advantage at the network foundation.

To see how these evasion tactics operate in the wild, read the latest Unit 42 report, Attackers Are Evading Threat Prevention at the Internet Edge. You’ll find this report valuable in understanding the systemic gaps in legacy risk models and learning why continuous verification must be our new mandate.

The post How AI and Evasion Demand a Radical Shift in Network Threat Prevention appeared first on Palo Alto Networks Blog.

According to global research, the market share of highly automated, driverless vehicles is growing rapidly. Analysts estimate that the next 10 to 15 years will mark a major shift from pilot projects to the mass adoption of autonomous transport. The momentum is building worldwide: Europe has already rolled out over 35 autonomous vehicle pilots, while the U.S. and China log more than 450 000 and 250 000 commercial trips per week, respectively. However, the report notes several roadblocks slowing down this progress. One such hurdle is the uncertainty surrounding legal liability and regulation, including in the areas of safety and security. The allocation of responsibility among suppliers, manufacturers, enterprise clients, and end users remains a major point of discussion.

Each market stakeholder sees the issue of ensuring the safety of autonomous vehicles differently. For automakers, it means taking responsibility for how a vehicle behaves on the road and for vetting their suppliers. For the suppliers themselves, it means designing security mechanisms directly into their solution architecture from day one and guaranteeing their adequacy. For insurance companies, it means completely overhauling their risk models to account for not just accidents, but also potential software glitches and cyberattacks. Ultimately, everyone agrees on one fundamental point: security must be a foundational feature of the vehicle — not an optional add-on.

Ensuring vehicle security in the modern era

For years, discussions around automotive safety focused strictly on functional safety. In other words, the goal was to ensure that vehicle systems operated correctly, and that risks associated with potential failures were fully mitigated or reduced to an acceptable level. The ISO 26262 standard “Road vehicles — Functional safety” helps address this very challenge, and serves as the baseline for the automotive industry.

However, the modern connected vehicle is a complex cyberphysical system that stores and processes massive amounts of data, including sensitive information. And this leads to the emergence of new basic needs. To draw an analogy with two levels of Maslow’s hierarchy of needs, a modern vehicle must:

• Satisfy the need for “esteem” — meaning it must securely and reliably store user profile data, such as account credentials, biometric data, payment details, and more.
• Satisfy the user’s cognitive needs — meaning it must provide secure internet connectivity, transmit vehicle telemetry, and send reminders for scheduled or emergency maintenance.

All of this means equipping vehicles with a wide array of interfaces — telematics, Bluetooth, Wi-Fi, cellular connectivity, OTA updates, and V2X — which opens the door to remote attacks. Therefore, it becomes necessary to ensure not only the functional security, but also the information security of the vehicle. As a result, specialized industry standards that help address automotive cybersecurity challenges have emerged in most countries. The key international standards are ISO/SAE 21434 “Road vehicles — Cybersecurity engineering”, UNECE R155, and UNECE R156.

China’s regulations are evolving too. In 2024, the country published the national standard GB 44495-2024 “Technical Requirements for Vehicle Cybersecurity”, which went into effect on January 1, 2026. The document introduces mandatory cybersecurity requirements for vehicles, including communications protection, security event management, threat monitoring, and secure vehicle interaction with external infrastructure.

Understanding and applying these standards is becoming absolutely critical. Research shows that cybersecurity risks are escalating daily, and their impact on functional safety can sometimes trigger far more dangerous incidents than an internal system failure. What happens if an attacker gains access to a self-driving truck’s remote-control system, or manages to reflash a critical electronic control unit during an unauthorized diagnostic session?

One of the key components for mitigating these scenarios is a security gateway, which isolates the vehicle’s architecture into different domains based on criticality, while providing secure routing, filtering, and traffic control. Developing this type of software solution is precisely what our team focuses on as we build the Kaspersky Automotive Secure Gateway based on KasperskyOS.

Why Kaspersky Automotive Secure Gateway?

The primary purpose of Kaspersky Automotive Secure Gateway (KASG) is to secure the vehicle’s CAN domain, since the CAN bus is used to transmit a vast number of critical control commands. This impacts nearly 80% of the electronic control units inside the car, which handle engine management, braking, body electronics, and more. Because of this, we utilize the Safety-Aware Cybersecurity approach — a unified architecture that accounts for both functional safety and cybersecurity requirements.

For example, standard End-to-End Protection (E2E) mechanisms are typically used to mitigate risks associated with dropped, out-of-order, or corrupted CAN messages. However, these mechanisms were not originally designed to counter targeted cyberattacks. If an attacker manages to construct a malicious frame that conforms to the required E2E format, the system may accept it as valid.

This introduces a new factor: it’s critical not only to verify that a message was delivered without errors, but also to ensure that it was actually generated by a trusted electronic control unit (ECU), and was not altered in transit. This is particularly vital for transmitting control commands — such as those sent to the vehicle’s braking system — or for implementing keyless entry (NFC) systems.

To address that challenge, Secure Onboard Communication (SecOC) mechanisms are integrated into the vehicle’s architecture. They use cryptographic methods to verify message authenticity and integrity, protecting the system against message spoofing and replay attacks. KASG successfully implements these mechanisms, which, in addition to message verification, perform the crucial function of centralized key management. This allows encryption keys to be distributed and updated from a single point within the vehicle, reducing both the cost and the processing load on the ECUs involved in SecOC-backed data exchange.

Automotive IDS

However, in complex systems, it’s no longer enough to apply security mechanisms only to individual messages or separate network segments. It’s essential to provide vehicle-wide monitoring and control, tracking behavioral anomalies, unusual cross-domain interactions, and unauthorized tampering attempts. In the IT domain, this is known as an Intrusion Detection System (IDS). These systems have been successfully adopted by the automotive industry as well.

At the same time, it’s important to realize that for a modern vehicle, an IDS is not a single magic point of data collection and analysis; the vehicle requires a distributed monitoring system. Monitoring is carried out at various architectural levels: within domains, at the individual controller level, and at network boundaries.

The security gateway becomes a critical monitoring point because all cross-domain interaction passes through. Additionally, the gateway provides visibility into data exchange across different segments of the vehicle network. Its job is to detect deviations from normal behavior and generate security events.

When it comes to the CAN domain monitoring implemented in KASG, the IDS looks at the following criteria for traffic analysis:

• Alignment of CAN message parameters (CAN ID, DLC) with their descriptions in the DBC specification.
• Frequency and periodicity of CAN messages.
• Allowable ranges for CAN signals.

In practice, however, an important limitation becomes clear: even with an onboard IDS, more context is required to determine the exact characteristics of an attack. Furthermore, when operating highly automated vehicles — where fleet-wide monitoring is essential — such isolated analysis becomes inherently insufficient.

Connecting a vehicle to an SIEM

Multi-object monitoring, data correlation, and data analysis can be efficiently handled externally — specifically in SIEM (Security Information and Event Management) systems, which are traditionally used in corporate and industrial cybersecurity operations centers. Therefore, utilizing a SIEM system fleet-wide is a logical step that makes it possible to:

• Collect security events from multiple vehicles.
• Correlate events over time and across contexts.
• Detect advanced and distributed attacks.
• Provide incident auditing and investigation.
• Respond to individual incidents and manage cyber-risks fleet-wide.

When integrating with external SIEM systems, several critical tasks must be addressed: ensuring a secure connection, tuning the security event transmission process, and establishing baseline rules for event processing and correlation. We are actively working through all of these challenges using our own SIEM system — Kaspersky Unified Monitoring and Analysis Platform — as a blueprint.

There are still many issues ahead that need to be resolved. This article covered only a fraction of the approaches currently used in KASG to ensure vehicle safety and security. Yet even this small part demonstrates that automotive security cannot be achieved by solving a single problem or applying a single mechanism. Achieving it requires an approach that enables methodical architecture development — balancing diverse requirements for vehicle functionality, security, and reliability.

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.