We use many technologies to detect email spam. They analyze every part of a message: headers, text, images, and links. But the first thing our email products focus on is the “From” field. If the address contains a domain that’s already on our denylist, it’s an easy call. But spammers know the drill, so they register domains in industrial quantities to make emails, even from a single campaign, arrive from completely different addresses. Clearly, they don’t do that by hand. The process has long been automated, and attackers’ algorithms can register huge numbers of domains in a matter of minutes. But every domain needs a name. Coming up with a unique one for each isn’t feasible. So spammers use domain generation algorithms (DGAs), which create similar names with minor variations, based on date and time, pseudo-random numbers, and so on.

In fact, to block mailings such as these, you don’t need every address on your denylist. We’re good at automating processes, too. For some time now, our email solutions have included a technology that detects domains generated by DGAs, and shuts down entire batch with a single rule. Let me explain how this technology works.

How we detect and block generated domain names in bulk

As soon as any of our technologies flags an email as spam, its address becomes subject to further examination. If it meets a number of criteria, its domain is added to our database of domains we consider “bad”. We built a cascade of classifiers that compares these domains by similarity, groups them into clusters, and creates a short but comprehensive rule that blocks the entire cluster. Our email protection solutions receive this rule with an update. From then on, they block all emails sent from addresses on any domain that matches it — even if those domains have never been used in spam campaigns yet.

Here’s a real-world example. Let’s say the classifier flags several lookalike domains in a collection of “bad” ones it has gathered:

• sxkjcc.asia
• sxkjcd.asia
• sxkjcy.asia

Then, one rule is enough to catch them all: @sxkjc[a-z0-9]\.asia\b

How to protect your company from spam

According to our analysis, 44.9% of emails sent last year were spam. Unwanted, unsolicited emails distract employees, waste working time, and clog inboxes. In some cases, they also contain scam, phishing, or malware content. To protect business customers from this deluge of threats, our solutions for corporate email security have anti-spam technologies that we constantly improve. This includes the technology described above for blocking domains generated by DGAs.

Two critical vulnerabilities have been discovered in the popular PHP programming language. The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, allow attackers to remotely execute code on a server running PHP without authentication. The language’s development team has released updates for all supported branches, but the first attempts to exploit the vulnerabilities were observed even before the patches were published. The exploit has been named PHP2Shell.

The architectures of popular marketplaces, e-commerce platforms, and learning management systems (LMS) are written in PHP. In addition, PHP is used in various content management systems (CMS) such as WordPress, Drupal, Joomla, and so on, which power most websites on the internet.

In this blogpost, we discuss CVE-2026-109618 and CVE-2026-109619 in detail, and explain how companies can protect their infrastructure. Read the Securelist expert blog to learn how events surrounding these vulnerabilities unfolded before the patch was released.

Vulnerable PHP versions

According to PHP web site, versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12 are vulnerable to CVE-2026-109618 and CVE-2026-109619. There are no official fixes for older branches. According to unofficial reports, the vulnerabilities also affect PHP versions starting with 5.4.0.

What makes CVE-2026-109618 and CVE-2026-109619 dangerous

Both vulnerabilities received a score of 9.2 on the CVSS v4.0 scale. They arise because, after a request is interrupted (for example, due to a memory shortage), PHP leaves invalid data in the memory buffer, and subsequently accesses it, allowing code to be executed on the server. One of the confirmed attack chains via CVE-2026-109619 exploits the `session.upload_progress` mechanism (which tracks file upload progress), which is enabled by default in PHP.

By exploiting these vulnerabilities, attackers can remotely execute code on the server with web server process privileges without authentication.

According to PHP developers, all installations of unpatched versions that process web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The greatest risk lies with mod_php: researchers demonstrated an exploit for it in which an unauthenticated request triggers the attack even before the application code is executed.

What businesses should do

We’ve compiled key recommendations from the PHP developers and experts at Kaspersky.

• Update PHP to versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Start with systems accessible from the internet. The source code is available on the PHP website. If PHP is installed from distribution packages or provided by your hosting provider, check for updated packages: Linux distributions and LTS vendors received patches in advance. If the server is managed by a hosting provider, ask them to apply the update.
• Versions 8.1 and older no longer receive updates from the PHP project. Check with your distribution vendor or LTS support provider to see if backported fixes are available, or switch to a supported branch. For PHP 7.4, 8.0, and 8.1, the developers have prepared minimal source code backports for manual compilation. These can also be found on the PHP website.
• Restart PHP-FPM or the web server so that the processes load the new code, and verify the version using the `php -v` command. If PHP was installed from distribution packages, check the package changelog: the version number may remain the same.
• Check the logs from October 20. A warning sign is when the web server process is performing actions it shouldn’t (running command shells, curl, wget, and the like). Kaspersky solutions help detect malicious activity in a timely manner. Attempts to exploit the described RCE vulnerabilities on Linux and Windows machines can be detected using Kaspersky NEXT EDR Expert, while exploitation of PHP2Shell in network traffic is detected by Kaspersky Anti Targeted Attack (KATA) with the NDR module.

If an immediate update is not possible

Only the immediate installation of patches will fully resolve the issue, but if that isn’t possible, it’s recommended to implement temporary measures. PHP developers provide step-by-step instructions for each vulnerability.

Microsoft’s October Patch Tuesday update stands out for two reasons. First, the total number of patches has reached four digits for the first time. Second, to help companies better understand the details of the vulnerabilities, Microsoft has decided to group them into risk cohorts. A cohort brings together vulnerabilities that are exploited under the same conditions and affect the same systems. They replace neither the severity rating, nor the individual bulletins for each CVE. While they’re unlikely to be suitable for comprehensive patch prioritization, they will help quickly assess which part of an infrastructure is currently most at risk.

Statistics corner

Of the 1,414 vulnerabilities addressed in the October Patch Tuesday release, 1,102 directly affect the Windows operating system, 134 — Microsoft Office, 36 — SharePoint Server, 22 — SQL Server, and seven — Exchange Server. The vast majority — 677 — lead to privilege escalation, 317 to remote code execution, 40 to security bypass, and 73 to denial of service (DoS).

There are 86 critical vulnerabilities on the list, of which 68 lead to RCE, 14 to privilege escalation, three to spoofing, and one to data leakage. In addition, two vulnerabilities were disclosed before being patched, and one is being exploited in real-world attacks.

CVE-2026-96951 — vulnerability in Windows Shell

The only zero-day vulnerability patched in the October update that attackers are already exploiting in real-world attacks is CVE-2026-96951 in Windows Shell (CVSS severity score: 8.8). Details on how it’s being exploited aren’t yet known; however, according to Microsoft’s description, it involves command injection that allows bypassing a security feature when accessing the system over a network. Microsoft credits experts at both Fujitsu and Anthropic for discovering the vulnerability, so it was likely found using neural networks.

CVE-2026-108398 and CVE-2026-92707: vulnerabilities disclosed before patches were released

Information about these two vulnerabilities was made public before the October update was released. In theory, this could mean that attackers attempted to exploit them ahead of time. These are:

• CVE-2026-108398 — a vulnerability in the .NET Framework that allows bypassing WDAC protection;
• CVE-2026-92707 — a vulnerability in the third-party MessagePack-CSharp serialization component, leading to a denial of service (DoS).

However, according to the security bulletins, neither has been observed in actual attacks yet.

What else to pay attention to

Several vulnerabilities patched by the latest update combine potentially serious consequences with relatively simple exploitation. Particular attention should be paid to three flaws that could potentially lead to arbitrary code execution:

• CVE-2026-65674 (in SQL Server);
• CVE-2026-70571 (in Exchange Server);
• CVE-2026-70229 (in AD Domain Services).

What else should be patched?

Microsoft isn’t the only company that releases regular update packages for newly discovered vulnerabilities.

In its October update, Adobe fixed 174 defects in its products, including critical vulnerabilities (CVSS 10) in ColdFusion and Commerce/Magento. These systems are typically accessible from an external network, making them particularly attractive to attackers.

SAP’s October security bulletin lists 20 vulnerabilities, including CVE-2026-89111 — an SSRF vulnerability in the Cloud SDK for Python. This vulnerability, rated CVSS 10, allows attackers to steal OAuth tokens.

How to keep your company safe?

Recently, thanks to neural networks, the number of vulnerabilities detected and patched has been regularly breaking records. To avoid getting overwhelmed by the flood of patches, we recommend using an automated platform for tracking and assessing vulnerabilities . It helps not only identify and fix vulnerabilities, it also prioritizes them based on actual risks and automates the remediation process.

When it comes to protecting voice calls, security professionals typically focus on the security of the data carrying the audio — above all on encryption. Sooner or later though, the voice data stops being a stream of bits and becomes an analog signal that goes straight to the speakers. You might think that if someone is using headphones, nobody can listen in. But headphones are electronic devices, and their components have physical characteristics that can give away closely guarded secrets without any cyberattack at all. In a recent paper, researchers from two Hong Kong universities came up with InjectEave — an attack that exploits these properties to intercept the already-decoded analog audio signal.

How the InjectEave attack works

The electronic components in headphones convert data into analog form and amplify the signal to drive the speakers. This process generates weak electromagnetic emissions. Capturing those emissions and extracting information from them is a field unto itself, with many experts working in it. The main issue those experts face lies in the fact that stray emissions from headphones are too faint to intercept and analyze in practice.

The authors of InjectEave propose adding a radio transmitter that beams a signal at a specific frequency toward the target device. Those weak emissions from the headphones’ analog components modulate the transmitter’s signal. The altered signal can be intercepted from several meters away — provided the receiving antenna is sensitive enough. The attacker then analyzes the changes in the signal to reconstruct the original audio.

Technical details of the InjectEave attack

The main obstacle to intercepting electromagnetic emissions directly — without an external transmitter — is the relatively low signal frequency. For example, the audio amplifier in headphones operates at frequencies from 20Hz to 20kHz. By contrast, electromagnetic emissions are easiest to intercept at frequencies measured in megahertz. The researchers were able to find a transmitter frequency that would also “amplify” the low-frequency signal of interest.

The researchers ran a series of experiments. They used antennas to transmit the “amplifying” signal and receive the result, and a spectrum analyzer to capture and process the data. The authors have posted the raw recordings of the intercepted signals on a dedicated microsite, so anyone can check how well the attack works. In most cases, getting a usable result didn’t even require complex processing or recognition. Conversations picked up from wireless headphones are clearly intelligible despite the elevated noise level.

In total, the authors tested three models of wireless headphones and two models of basic wired headsets. The effective eavesdropping distance varied from one to six meters depending on the model. With a wired telephone, they were able to demonstrate two-way interception. They could hear not only the sound from the speakers but also the potential victim’s speech, which the headset’s built-in microphone and analog-to-digital converter had captured.

Advantages and limitations of the method

Any attack that requires getting very close to the target is challenging by definition. The need to tune the frequency of the “amplifying” radio signal for each specific device makes the attack even harder. In their experiments, the researchers had to use frequencies from one to eight megahertz.

Despite these caveats, the main achievement of this attack is its being able to target the quirks of the analog components in an electronic device. These components inherently produce stray emissions, and there’s almost no way to reduce them.

Similar surveillance methods that intercept a digital signal can be stopped by adding a layer of encryption. When it comes to the analog side of a device, protecting the signal itself is much harder. This research is another reminder of how complex and unpredictable even very simple, familiar devices can be. Sometimes even the strongest protection for digital data is powerless once that information is converted to analog form.

The post The Enterprise Threat Intelligence Report: 2026 appeared first on Flashpoint.

Many businesses still fear ransomware attacks. But is this threat still as relevant today? A few years ago, at the peak of ransomware’s popularity, the term “ransomware” was practically synonymous with malicious encryption of data. But in reality blocking access to information had long been little more than a symbolic gesture. In a May Securelist post on shifts in the ransomware threat landscape, our experts noted that in 2026, attackers are encrypting company data for ransom less and less frequently. Here’s a striking example: while investigating an incident, Kaspersky’s Global Emergency Response Team (GERT) uncovered the PAYLOAD extortion campaign, whose operators didn’t even bother using ransomware. They took a different route instead.

In this campaign, instead of using ransomware, the attackers seized control of the Active Directory environment, and created a malicious group policy object (GPO). They used it to deploy a ransom note, change wallpapers, and lock screens on workstations, and set up a banner to display at system login. Naturally, they also disabled local administrator accounts while they were at it. This move let the attackers demonstrate their presence in the compromised infrastructure and prove they’d accessed confidential information — just as effectively as encryption would have. Detailed information about this incident, along with indicators of compromise, can be found in the same Securelist post. What interests us more, though, is the trend of abandoning encryption.

Why data encryption has lost relevance

Let’s start with the fact that in a large company with thousands of infected computers, decrypting data is an extremely effort-intensive process. Restoring data from backups, which has become common practice largely thanks to mass ransomware attacks, is far easier than waiting for criminals to hand over a key, hoping it’s genuine, and trusting that the ransomware itself didn’t have bugs that made the data unrecoverable. As a result, cybercriminals found it harder and harder over time to actually collect a ransom for the decryption key.

Attackers tried to adapt to this shift. Alongside encryption, they increasingly began stealing confidential data and threatening to publish it. Publishing confidential information puts a company’s reputation, its security, and the safety of its business partners at risk. This is especially true if the data includes people’s personal information: more than 140 countries around the world have data protection laws, so a leak puts an organization at a fairly high risk of a hefty fine. Sometimes that’s far scarier than simply losing data, and no backup can help with that.

Data exfiltration has another advantage from the attackers’ perspective: it’s usually much harder to detect than malware activity. File encryption, for instance, triggers a spike in disk activity that endpoint protection tools pick up fairly quickly. By contrast, data exfiltration is easy to disguise as normal traffic. This is precisely what the ShinyHunters group exploits, building its attacks around the standard OAuth mechanism. On top of that, attackers can steal data much quicker if they don’t bother with encryption, which also makes it harder to catch the threat in time.

As a result, encryption has become a kind of calling card — proof that the attackers had access to the data. So cybercriminals finally decided to drop this optional step altogether.

What businesses should do

Standard cyberhygiene practices can help protect against a wide range of extortion schemes — regardless of whether or not they involve encryption:

• Run regular, automatic backups. By storing backups on two types of media — physical and cloud — a business need not fear serious disruption to its operations. After all, the downtime required to restore from backups is nothing compared with the consequences of losing all of its data.
• Install patches and updates promptly. For attackers, vulnerabilities remain one of the main entry points into infrastructure. To reduce the risk, we recommend setting up automated update management for operating systems, software, and drivers. It’s also important to scan systems regularly for security gaps, and triage the found vulnerabilities with a focus on critical flaws. Specialized vulnerability management solutions can help with this.
• Strengthen endpoint protection. Set up multi-factor authentication for every system in an infrastructure, and deploy a reliable workstation and server security solution. A SIEM or EDR solution can help security specialists gain full visibility into events, and respond to incidents quickly.
• Monitor external perimeter. Regularly check the company’s infrastructure (servers, databases, clouds, and legacy subdomains) for open ports and services exposed to the internet.
• Adhere to the principle of least privilege. This means giving users, systems, and processes only the access privileges they need to do their jobs. Revoke unused privileges, and fully disable access for former employees.
• Invest in staff training. Attackers still exploit the human element to break into a company’s infrastructure. Raising threat awareness among employees can keep them from falling victim to phishing.

We recently published a post on “tokenomics” and “denial of wallet” attacks — a new type of DDoS attack aimed at overspending AI tokens. But before security specialists begin protecting their colleagues’ AI processes from this new threat, they should remember that the work of the information security department itself can become a target for such an attack. Since security teams are now actively testing and implementing various types of AI-based automation, the threat of external interference aimed at paralyzing the defense system directly affects their own processes and technologies.

Elastic has estimated that, depending on the “agent-based SOC” architecture, triaging a single alert from a host can cost $0.69 for an ensemble of highly specialized agents or $3.42 for a general-purpose agent with 14 different skills.

However, these averages mask a huge range of variation. At any given moment, the basic processing of a simple alert (say, a thousand tokens) can turn into a cascading investigation involving processing millions of log entries, API calls, and other related data — which amounts to millions of tokens in a matter of minutes.

Elastic itself acknowledges that it uses the Claude Sonnet 4.6 model in its SOC. This immediately raises the question: what happens when the budget is exhausted or the model’s security filters are triggered? In the worst-case scenario, the following occurs: the AI SOC launches an “orchestra of agents” to investigate suspicious events that resembles lateral movement in the infrastructure. The agent calls the Anthropic API, but the department’s monthly budget has been exhausted, and the API returns errors. The investigation grinds to a halt, and people find out about it half a day later. Moreover, if the constantly changing “security filters” of a major AI provider flag the SOC’s requests as malicious, the same effect is possible even without the budget being exhausted — as demonstrated by Hugging Face’s experience investigating the breach of their infrastructure by OpenAI.

Of course, an attacker has a vested interest in such an outcome. They can directly influence the defenders’ costs by injecting malicious prompts into the data available to them (DNS TXT records, HTTP headers, code comments, filenames, and so on), counting on the fact that these prompts will be processed by information security systems. For example, in the GhostJacking attack case, WAF logs serve as the vector for prompt injection, and in academic study, another method was proposed: researchers managed to attack the LLM security guardrails themselves, causing their requests to increase latency by 148 and the number of tokens consumed by 63. In other words, the system theoretically continues to function correctly, but the latency in processing alerts and the associated costs increase significantly.

Dangerous silent failure

In agent-based scenarios, budget exhaustion doesn’t always manifest as an explicit error with a “request limit exceeded” message and an immediate alert to the responsible parties. Under certain configurations, “guerrilla” scenarios can arise: a request to the model times out, the system automatically switches to a cheaper model, and as a result the quality of its outputs drops, and subagents and periodic tasks stop running. Meanwhile, the security team may continue to believe for hours on end that everything is working as before.

How to control AI costs in cybersecurity

The task of managing expenses, of course, isn’t simply a matter of “preventing overspending”. The industry has already fallen into this trap when implementing SIEM: when companies had to pay based on the volume of telemetry collected, they began to selectively — and not always effectively — limit log collection. As a result, they ended up with detection blind spots. The same situation could arise with tokens — but faster and on a larger scale. A poorly designed cost-cutting policy could compromise the depth of investigations and the quality of responses. And in the absence of such a policy, the decision to cut something will be made not by the architect or the CISO during the system design phase, but by the analyst on duty at 3am. Or it may be an automatic limiter set by the system vendor.

A few simple principles can help avoid predictable cost overruns, and better manage situations that are truly unpredictable.

Don’t feed the AI model anything that can be verified with a standard query. Everything that’s repetitive and known in advance should be handled the old-fashioned way — with rules and data queries. These can be developed using AI, but they must operate deterministically. The model should only be used where an assessment of an ambiguous situation is truly needed.

Use strict limits and aggressively alert users when they are exceeded. Limits should be combined: a limit per task, a daily limit, and so on. Alerts about limit exceedances must immediately reach both on-duty analysts and those responsible for the system as a whole.

Decide in advance what happens when a limit is reached. Whether to stop and save money — while losing some control — or to continue and pay, is a decision that must be made before an incident occurs.

Limit agents’ permissions and the set of tools available to them. The fewer actions the system has access to, the more effectively it works on a narrow task, the fewer opportunities it has to inflate costs, and the less likely it is to be “exploited” by an outsider.

Strictly scan external, untrusted data. Incoming requests, inquiries, messages, and comments, as well as various technical fields capable of containing arbitrary text (DNS records, HTTP headers, file names) can not only lead to prompt injection, but also deliberately inflate the workload. Limit their size, and monitor the load they generate.

To avoid service outages from external providers and maintain full control over your organization’s data, evaluate the possibility of using local models deployed on-premises at least for information security needs. While these models may not be state-of-the-art, their narrow specialization and fine-tuning with company data will deliver decent performance without unexpected failures.

In a more complex architecture, the use of LLMs can be divided into several levels. The first line of defense (routing, noise filtering, data enrichment) is handled by compact on-premise models. This significantly reduces budget volatility. The second level consists of a large local model that handles the substantive work: linking events, testing hypotheses, and piecing together the picture of an incident. It’s also not billed per request, but its throughput is limited; therefore, instead of budget overruns, overloads and event queues may occur. Only isolated, truly difficult cases are forwarded to advanced cloud-based models — preferably with the explicit approval of a human analyst. In this scheme, variable costs remain, but they’re limited to a small number of cases, and each one represents a conscious choice rather than a side effect of a script running overnight.

Essentially, all of this replicates the classic multi-tiered SOC model — where the first line filters, and the third line investigates — only the roles are played by models rather than people.

A critical vulnerability has been discovered in the popular WordPress content management system that allows attackers to execute arbitrary code on the web server. The vulnerability has been assigned the number CVE-2026-87902. The good news is that on September 22, WordPress released an update that patches it. The bad news is that the first attempts to exploit CVE-2026-87902 were detected just a few hours after the patch was released. Therefore, all companies whose corporate websites or blogs run on this platform are advised to update immediately.

WordPress versions affected by CVE-2026-87902

According to data published by WordPress on GitHub, all versions of the CMS from 4.7.0 through 7.1.1 are vulnerable. The company has released updates for all supported branches of the system; a complete table listing the patched version numbers can be found on the company’s GitHub page. The latest version of WordPress should be updated to version 7.1.2 (or newer).

What’s the nature of the CVE-2026-87902 vulnerability, and why is it so dangerous?

Under normal circumstances, WordPress loads PHP template files only from a specific folder within the active theme. However, due to the CVE-2026-87902 vulnerability, an attacker can craft a request to WordPress in such a way that an arbitrary PHP file is included — without requiring any authorization. Yes, the file must already be uploaded to the targeted server in some way, but that’s not really a problem for an attacker.

It sounds like a path traversal vulnerability, but in most publications, CVE-2026-87902 is classified as an RCE (Remote Code Execution) vulnerability because, under certain WordPress and PHP server configurations, the attack can lead to the execution of arbitrary code.

How to stay safe

The only way to secure a corporate WordPress site is to install the latest version. The researcher who discovered the vulnerability also offers several tips for hardening CMS security, but emphasizes that these are meant to complement the patch, not replace it.

The Hacker News lists several PHP filenames and IP addresses used in the attack via CVE-2026-87902. These can serve as indicators that a WordPress instance has been compromised.

Given that only a few hours pass between the publication of information about a vulnerability’s existence and the start of attacks exploiting it, it’s crucial for companies to have a properly configured, centralized vulnerability management system. To achieve this, they should have a specialized solution capable of identifying and resolving vulnerabilities, prioritizing them based on actual risks, and automating remediation processes. Our vulnerability management module for Kaspersky Next Optimum can help with this task.

Not long ago, many companies began actively implementing AI agents in a wide variety of workflows. Very quickly, the cost of using them became a pressing issue for companies. Moreover, it’s an issue that concerns more than just finance department — in addition to budgetary concerns, issues of reliability, operational stability, and even information security have emerged. This is because the cost of automating one and the same process varies significantly from one deployment to the next, is unpredictable, and could be subject to external influences.

Furthermore, for a malicious actor attacking an organization, any process automated using AI and vulnerable to external influence is, in essence, a convenient target for a “new type of DDoS attack”. Application-error reports, product reviews, or technical support requests can (just like any other external data that a company processes via AI) serve as a tool in an attack aimed at increasing consumption of tokens (word fragments that serve as the basic unit of input and output of an LLM).

A year of explosive growth… in bills

In 2026, large companies significantly overspent on their AI system budgets for the first time. Uber had spent its entire annual budget by April, while an unnamed company failed to set spending limits for Claude and spent $500 million in a single month. Although AI providers regularly announce lower prices and more efficient models, the shift from chatbots to agentic systems that operate continuously and autonomously increases token consumption by hundreds or thousands of times.  At the same time, the “fixed subscription for $20 or $100” model for companies is becoming a thing of the past; all major providers are transitioning business clients to pay-as-you-go billing.

As a result, companies are facing a problem all too familiar to cloud hosting and cellular communications industries. In the absence of specialized cost accounting and management systems, an organization only learns how much a particular process or project will cost after it’s completed. In the telecom and cloud sectors, this problem was eventually solved through the development of sophisticated billing systems, and their clients have even adopted the specialized term FinOps. For AI, this process is still in its infancy. Moreover, solving the problem will be complicated by the probabilistic nature of generative AI.

Unpredictable token consumption

To understand why costs rise so quickly and are so difficult to predict and control, we need to recall how a language model works and what turns it into an AI agent. The model is stateless; in other words, it does not retain any information between interactions. Every time the agent takes the next step, the entire history of work on a specific task (the context) must be resent to the model: the initial prompt, previous reasoning, the contents of the files it has read, and the responses from all tools. With each step, this “recap” grows longer — especially if the task involves iterative loops. If a step fails, or the response is unclear, or a tool returns an error, the agent simply tries again — further inflating the size of the context. And if the task is performed not by a single but by several agents, which divide the work among themselves and exchange results, this volume is multiplied by their number. As a result, token consumption does not increase gradually but in spurts, and it’s nearly impossible to predict it at the start of the task.

When running two different sessions of an AI agent interaction to solve exactly the same task (two tech-support tickets, two analytics tasks, and so on), the number of tokens spent on them can vary — the difference can be as much as 30 (!) times. This depends on how many steps, errors, and retries are required to solve the task. Increased resource consumption doesn’t necessarily depend on the complexity of the task. There are well-known cases where AI got stuck in a “thought loop” and wasted an absurd amount of resources on trivial tasks.

Three generations of AI in enterprise systems consume resources in completely different ways:

• Classical machine learning (ML). This typically works with well-structured data and isn’t overly computationally intensive. Resource consumption is predictable and low. This is a fixed budget item;
• A chatbot or other LLM-based AI assistant. It consumes tokens, but the pace is set by a human: an employee manually launches a task, then evaluates the result, and pauses. Cost increases roughly in proportion to the number of active users, and can be approximately estimated based on the number of licenses;
• An autonomous AI agent. A person sets a goal and steps away, and the system then decides on its own what to do and how many steps are needed. The meter keeps ticking until the task is considered complete, and there’s no predictable cost ceiling.

Tokenomics in attacks: denial of wallet as the new DDoS

Since LLM calls are significantly more expensive than typical standard software calls, automating routine corporate tasks comes at an unusually high cost. For example, Gartner estimates that resolving a single customer support request using an LLM costs approximately $3. It’s easy to imagine how attackers could bombard a company with thousands of long, sophisticated requests generated by an inexpensive LLM, causing significant financial damage. Since the process is automated, anomalies may not be detected right away.

If an attacker knows which agent system and which LLM are used in a business process, they can carry out a more precise attack and cause significantly greater damage. The authors of the GitInject study estimated that an attacker capable of creating GitHub issues within an organization that uses AI agents for error analysis with single attack (before GitHub’s defense mechanisms kick in) can cause up to $111 in damage and burn through 400 minutes of GitHub Actions from the victim’s account. Naturally, such an attack can be repeated multiple times — at no cost to the attacker.

The most dangerous risk — though difficult to quantify in monetary terms — comes from attacks that provoke LLMs into excessive reasoning. In the paper OverThink, the authors demonstrated how a harmlessly worded task, when fed into a language model, ultimately yields a correct result but, in the process , consumes 46 (!) times more tokens than it should. Moreover, all tasks tested by the researchers successfully passed existing security filters.

In the new version of the OWASP Top Risks for Language Models guide, this issue has risen to a record-high priority: unbounded token consumption is now designated as LLM06:2026, and among its variations, the “denial of wallet” attack — which depletes the victim’s budget for LLMs — is explicitly highlighted.

How to Avoid Becoming a Victim of the “New DDoS”

First and foremost, you should abandon the principle of “using AI just for the sake of using AI”. It doesn’t make sense to entrust autonomous agents with every task. It’s wise to periodically conduct a cost-benefit analysis of using artificial intelligence.

In addition, you should limit the permissions and set of tools available to an autonomous AI agent. The fewer actions the system has access to, the more effectively it works on a narrow task, the fewer opportunities it has to inflate costs, and the less likely it is that someone will be able to “manipulate” it into unnecessary token spending.

We also recommend setting strict limits on token consumption, and configuring a notification system to alert humans when these limits are exceeded. It makes sense to implement multiple limits in parallel: a limit per task, a daily limit, and so on. Alerts regarding limit exceedances must be immediately forwarded to the specialist responsible for the system so that they can make an informed decision — whether to continue or halt the process.

Strictly verify external, untrusted data. Any information processed by AI that comes from external sources — whether it’s requests, inquiries, messages, or comments, or various technical fields capable of containing arbitrary text (DNS records, HTTP headers, filenames) — can not only lead to prompt injection, but also deliberately inflate the workload. It will be wise to limit their size and monitor the load they generate.

Calculate the unit cost of work and compare the vendor’s invoices with your own data. The cost per analysis, per request, or per check is the only way to understand what you’re paying for and to spot errors in the invoices.

How can an industrial server be compromised through its GPU without leaving a trace? Such a complex, largely theoretical attack would typically leverage hardware vulnerabilities. This isn’t even about design flaws in the hardware itself, but about quirks in how it operates — sometimes at the physical level. A recent paper by Canadian researchers at the University of Toronto describes GPUThor — a new and more effective Rowhammer attack that exploits precisely this kind of hardware behavior in video memory.

Rowhammer and graphics cards

GPUThor builds on the idea behind the original attack on RAM, first proposed in 2014 in the Rowhammer research. Rowhammer and every attack in its class rest on a simple fact: memory cells aren’t fully isolated from one another. Repeatedly accessing (hammering) the same row of cells can, under certain conditions, corrupt data (that is, flip bits) in neighboring rows. Once that effect is confirmed as possible, all that’s left is finding a way to weaponize it — for example, by triggering a denial of service or even executing arbitrary code.

So what do servers and graphics accelerators have to do with any of this? As artificial intelligence technologies have taken off, so has demand for hardware that can run large numbers of parallel, similar computations. And the accelerators built into gaming graphics cards are a natural fit for this kind of workload. This makes cloud providers that rent out graphics accelerators to all comers an attractive target for Rowhammer attacks. The hypothetical scenario runs like this: an attacker buys access to a graphics chip, and uses it to try to compromise the provider’s entire infrastructure. This is exactly why attacks on video memory remain a topic of special interest to researchers.

How the GPUThor attack works

In the spring of this year, three new papers were published — each demonstrating a different attack on Nvidia accelerators equipped with GDDR6 memory. All three delivered fairly modest results: the most damage was done when the target was a consumer-grade graphics card, while attacks on an industrial accelerator like the Nvidia A6000 proved to be far less effective. On top of that, none of the attacks worked with ECC (error correction code) memory protection enabled.

GPUThor also looks at the possibility of attacking Nvidia’s older Ampere accelerators with GDDR6 memory: the researchers studied the A4000, A4500, A5000, and A6000 models. But the effectiveness of the new method — measured by the number of cells whose data was forcibly altered — is significantly higher. The researchers also argue that, in theory, the technique could be applied to newer accelerators as well.

;

How were these results achieved? The standard defense mechanism against Rowhammer attacks is called Target Row Refresh (TRR), which the Canadian researchers took a closer look at. It turns out that if TRR detects repeated access attempts, it forces a refresh of neighboring cells — making data corruption difficult or impossible. Attackers typically try to defeat TRR by accessing cells at random — confusing the defense system and reducing its effectiveness. The researchers discovered that on Nvidia Ampere cards, TRR only triggers once every 72 memory-cell refresh cycles. Armed with this finding, they applied an uneven access pattern — hammering the target cells far more aggressively than before. The result: measured against the original GDDR attack known as GPUHammer as a baseline, GPUThor turns out to be around 7 000 to 23 000 times more effective.

Results and outlook

Combining this more aggressive attack pattern with other refinements produced 72 000 to 377 000 bit flips per gigabyte. Earlier Rowhammer variants managed a few hundred at best. This let the researchers achieve double and even triple-bit errors. ECC easily corrects a single-bit error, but not a double-bit one.

The new method also demonstrates the real-world damage a Rowhammer attack could cause: repeated access to video memory using GPUThor triggers a denial of service. The accelerator first reboots, losing data in the process, then flags itself to the administrator as needing replacement.

Despite these impressive research results, GPUThor attacks aren’t successful. For one, the researchers weren’t able to demonstrate arbitrary code execution as a result of the data corruption — though they claim this is possible even with ECC enabled. For another, an attack thousands of times more effective hints at the theoretical possibility of compromising newer accelerators too, but this also remains unproven for now.

Even so, the Canadian researchers have shown that Rowhammer attacks on graphics accelerators still have untapped potential. It wouldn’t be surprising if future research demonstrated similar attacks against far more advanced devices previously considered highly resistant to them.

Threat actors are constantly developing new attack schemes — from OAuth token theft to attacks on AI agents — but the classics never quite leave their playbook. On any given day, an employee may receive malware attached directly to an email, or lying in wait behind a link embedded in an email. Making these attacks succeed still requires a degree of creativity, and in recent years attackers have increasingly adopted exotic file formats. Users don’t perceive these formats as dangerous; more importantly, many EDR and email security solutions skip scanning them entirely. Yet they’ve proven highly effective for deploying malware or harvesting credentials.

Below are the file types that may be blind spots in your organization’s detection strategy — despite being observed as used in real-world attacks.

Disk images

This is the broadest and most dangerous attachment category. A disk image can contain a fully prepared, correctly structured set of files tailored to a wide range of attack scenarios. It mounts as a separate volume (standalone virtual disk), and when doing so often uses tools built into the operating system. The victim doesn’t need to extract anything or create suspicious folders on disk.

The most versatile format is ISO, which dates back to the heyday of multimedia CDs. ISO images mount natively on every major OS without additional utilities, whether through simple tools like File Explorer or via the command line interface. This is precisely why threat actors have no hesitation in sending ISO files as email attachments.

Somewhat less common are IMG containers, which also mount without additional tooling on macOS or Linux, but require installing a small, free utility such as OSFMount on Windows, or using WSL2 (Windows Subsystem for Linux), which is built into recent Windows versions. A file with identical content may also carry a DD extension.

Threat actors also make use of VHD, a virtual disk format native to Windows, which generally works on Linux machines as well (via qemu-nbd or guestmount). On macOS, an additional utility — again, qemu-nbd is a common choice — is required to mount it. Note that on unpatched Windows systems, the victim doesn’t need to take any further action after the disk mounts: CVE-2025-24993 — a vulnerability actively exploited in real-world attacks — triggers attacker code execution immediately upon mounting the image.

For completeness’ sake, VMDK, the disk image format used by VMware, is also worth detecting, though it’s largely ineffective in attacks on regular users since every popular OS requires additional software to mount it.

All of these image formats can be viewed and unpacked not only with specialized tools, but with standard archive utilities like 7-Zip or RAR. As a result, the odds that the user will fall for the bait are higher than one might hope.

In addition to not being a well-known potentially dangerous format, image files give attackers one further advantage: files extracted from disk images on Windows frequently lack the Mark of the Web flag, and therefore can be launched without triggering additional system warnings.

There’s one more reason why EPP/EDR solutions must scan virtual machines and disk images: these formats are also used during later stages of an attack. To mask active file-system activity from monitoring tools, ransomware gangs sometimes run the entire encryption process inside a virtual machine deployed on the victim’s computer. The RagnarLocker ransomware strain has used VirtualBox for this purpose, while the CRON#TRAP campaign relied on a QEMU environment.

MS Office files

No, this isn’t about macro-laced DOC files. Microsoft has grown weary enough of this classic attack vector that macros in downloaded documents are now blocked outright, and enabling them requires considerable effort from the user. But Office relies on dozens of file formats, and some of the less common ones still occasionally give attackers an edge.

Less familiar to both users and security solutions are OneNote files (.one). These are essentially simple notes, but they can carry embedded attachments, including not just images and links, but VBS/WSF/BAT scripts as well. Within the note, an attachment normally displays as an icon, but attackers overlay it with a picture showing a message with a “View” button.

Another Office format popular with attackers is the Excel add-in. These files use the .xll extension but are, in effect, full-fledged Windows dynamic-link libraries (DLLs), and therefore may have extensive functionality. Victims receive a malicious email with what looks like an invoice; the icon suggests that the file will open in Excel. Ignoring the security warning may result in an infostealer infection.

SVG “graphics”

The description of the SVG (Scalable Vector Graphics) format sounds entirely innocuous. Indeed, 99% of SVG files are logos and interface icons. But unlike PNG or JPG, SVG files are fundamentally XML documents, and beyond points, lines and fills they can contain JavaScript. In terms of malicious potential, SVG is not far behind a full web page. In real-world attacks, SVG files can redirect a user to a phishing page immediately upon opening, or render the phishing page directly by unpacking a Base64-encoded block into full HTML.

SVG files pose a distinct risk to corporate portals that accept user file uploads. If a portal’s Content Security Policy (CSP) isn’t sufficiently restrictive, and lets someone upload a malicious SVG file, the embedded JavaScript can steal cookies from the page, inject unauthorized content, and carry out similar attacks.

Polyglot files

Polyglot file formats are less exotic in and of themselves, but the files carry more than meets the eye. They’re called polyglots because attackers construct a file that can be validly interpreted in multiple ways: for example, it can be a valid ZIP archive and a valid executable at the same time. The purpose is purely to evade detection by security solutions and deceive the user. We’ve covered polyglots in detail in a separate blog post.

The clear standout in our roundup is a malicious campaign distributing the IcedID infostealer. Victims receive emails with a ZIP attachment, which unpacks into an ISO disk image. That further unpacks into a CHM file (the Windows Help format) that’s also correctly processed as an mshta (Microsoft HTML Application host) application, which then downloads the primary malware payload.

Defending against exotic files

These attacks rely on the assumption that security solutions either don’t scan unusual file formats, or scan them only superficially. Preventing the threat starts with not operating on that assumption with regard to your own infrastructure:

• Configure EDR, web, and email filters to scan all of the file formats described above.
• Process archives and disk images with the same rigor as you would apply to executables.
• Detonate potentially dangerous file types in a sandbox, and configure recursive unpacking of nested formats through to the end of the chain: ZIP → ISO → CHM.
• Where feasible, quarantine all file formats anomalous for email — disk images in particular.
• Build detection rules for anomalous usage patterns that involve exotic files. For example, unusually small disk images are rare and are therefore worth investigating.
• Review the technical documentation of your security solutions to confirm that complex formats are detected through deep structural parsing rather than magic-byte checks alone.
• Deploy behavioral detection capable of flagging anomalous execution patterns and legitimate utilities launched from unexpected contexts. The usual suspects here include mshta, git, wscript, hh, and rundll32.
• SVG files warrant a dedicated policy. Treat SVGs as active content at the email and web perimeter. On corporate portals, enforce a strict CSP, and serve user-uploaded files from a separate subdomain so that a malicious script embedded in an SVG can’t access the session on the main portal.

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.