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
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:
Clicking Verify with Microsoft.
Signing in to the work account, at which point the attackers warn that multi-factor authentication (MFA) may be required.
After being redirected to a new page, waiting until “localauth” appears in the address bar.
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 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.
Login
