Security teams have spent years teaching employees how to identify suspicious software, avoid malicious links, and question unfamiliar websites. Two campaigns observed in 2026 suggest that the next challenge may be very different. Attackers no longer need users to trust them directly. They only need users to trust the brands they are impersonating.

Threat campaigns tracked as Google Chrome AI (W17) and InstallFix / Claude Code (W20) are technically distinct. One stems from legitimate browser behavior that introduces unexpected security and operational challenges. The other uses sponsored search results and counterfeit documentation pages to compromise developers. Yet both campaigns rely on the same underlying principle: trust in AI tools has become an attack surface.

The rapid adoption of AI across enterprise environments has outpaced the policies governing how these tools are installed, configured, and monitored. As a result, organizations are increasingly exposed to risks that traditional security controls were not designed to address.

Log360's internal breach and attack simulation (BAS) team has developed and tested detection rules for both campaigns. This article examines the technical details of each campaign, the strategic connection between them, and the steps security teams should consider taking to mitigate similar threats.

W17 – Google Chrome AI: When trusted software behaves like persistence   

Most threat campaigns involve attackers introducing malicious code or exploiting vulnerabilities to gain access to systems. W17 is different. It highlights how legitimate software behavior can unintentionally create conditions that resemble attacker persistence techniques.

Beginning in early 2026, Google Chrome started downloading Gemini Nano—Google's on-device language model—to endpoints where the feature was enabled. The model, which is approximately 4GB in size, is stored in the following location:

%LOCALAPPDATA%\Google\Chrome\User Data\OptGuideOnDeviceModel\weights.bin

For many organizations, the immediate concern is operational rather than security-related. A large-scale rollout of a 4GB model across thousands of endpoints can create significant bandwidth and storage challenges, particularly when organizations are unaware that the download is occurring. In some jurisdictions, the behavior may also raise questions around endpoint storage consent and software governance requirements.

The more interesting challenge appears during remediation.

Deleting the weights.bin file alone does not prevent the model from returning. Chrome treats the missing file as a condition requiring remediation and restores it during subsequent browser launches unless the underlying policy configuration is changed first. From a defender's perspective, this behavior resembles persistence patterns commonly observed in malware, where a trusted process restores an artifact that an administrator intentionally removed.

A secondary concern is configuration management. Chrome's on-device AI capabilities are governed by settings such as optimization-guide-on-device-model in the Local State file and the GenAILocalFoundationalModelSettings registry value under:

HKLM\SOFTWARE\Policies\Google\Chrome

When these settings are absent or misconfigured, organizations may inadvertently enable AI capabilities that have not been formally approved or governed. Security teams often monitor executables and browser extensions, but many do not monitor browser policy changes with the same level of scrutiny.

From a MITRE ATT&CK® perspective, the behaviors observed map primarily to T1105 (Ingress Tool Transfer) and T1112 (Modify Registry). The lesson here is not that Chrome is acting maliciously. Rather, it is that legitimate software can create behaviors that resemble attacker tradecraft and therefore deserve the same level of visibility and governance.

Log360 detection – W17   

Log360 has deployed five detection rules covering the lifecycle of the Chrome AI deployment, including:

• Creation of the Gemini Nano model file

• Large downloads from Google's AI infrastructure

• Missing or misconfigured policy settings

• Re-download of the model after deletion

• Anomalous modification of AI-related configuration settings

The most operationally significant detection correlates the deletion of weights.bin with its subsequent re-creation on the same host. This sequence provides strong evidence that remediation efforts are being reversed by the browser itself.

Another useful early indicator monitors network activity to Google's AI content delivery infrastructure before the model reaches disk, giving security teams an opportunity to identify the activity earlier in the process.

Note: Coverage statistics referenced in this article are based on internal BAS testing against default detection content from selected SIEM platforms as of May 2026.

Remediation guidance   

Organizations should deploy the GenAILocalFoundationalModelSettings policy before attempting to remove the downloaded model files. Without the policy in place, deleting the files alone may simply result in the model being restored during subsequent browser launches.

Security teams should also consider monitoring browser policy changes, reviewing whether on-device AI capabilities align with enterprise policy, and ensuring that endpoint telemetry such as Sysmon and Windows Security logs are enabled to support investigation.

W20 – InstallFix / Claude Code: Weaponizing developer workflow conventions   

While W17 focuses on browser behavior, W20 targets a very different layer of the enterprise environment: developer workflows.

The campaign, publicly documented by Trend Micro in May 2026, exploits a habit that has become second nature to many developers: copying installation commands directly from documentation pages and executing them without examining every detail.

Attackers purchased sponsored search advertisements targeting queries such as "Claude Code install." Users who clicked these advertisements were directed to pages that closely resembled Anthropic's legitimate documentation, complete with familiar branding, navigation, and installation instructions. The only meaningful difference was the installation command itself, which retrieved code from attacker-controlled infrastructure.

Unlike traditional ClickFix campaigns, there is no fabricated browser error, fake CAPTCHA, or deceptive warning designed to convince the user to act. The victim's own intention to install legitimate software becomes the social engineering mechanism.

The infection chain that follows is technically sophisticated:

1. mshta.exe

2. cmd.exe (/v:on)

3. SysWOW64 powershell.exe (-EncodedCommand)

4. C2 callback

The payload retrieves a ZIP/HTA polyglot file, reconstructs PowerShell commands using delayed variable expansion, launches 32-bit PowerShell to evade some AMSI implementations, performs victim fingerprinting, disables SSL certificate validation, patches AMSI in memory, and finally communicates with victim-specific command-and-control infrastructure.

The final payload has been linked to RedLine stealer activity targeting browser credentials, session tokens, and cryptocurrency wallets. The campaign has been observed across multiple regions and has affected organizations in government, education, and technology sectors.

From a detection standpoint, the process lineage itself becomes the behavioral signature of the attack.

MITRE ATT&CK coverage spans several techniques, including:

• T1218.005 – System Binary Proxy Execution: Mshta

• T1059.005 – Visual Basic

• T1059.003 – Windows Command Shell

• T1059.001 – PowerShell

• T1562.001 – Impair Defenses

• T1071.001 – Web Protocols

Log360 detection – W20   

Log360's BAS team has deployed four detections covering:

• Remote payload retrieval through mshta.exe

• Delayed command expansion through cmd.exe

• Encoded PowerShell execution and AMSI bypass activity

• Communication with known malicious infrastructure

Two correlation chains are particularly useful for SOC teams. The first correlates the complete process chain and should trigger immediate host isolation, credential review, and incident response engagement. The second correlates the initial payload retrieval with command-and-control communication and may provide sufficient evidence of compromise even when intermediate stages are missed.

Note: Coverage statistics referenced in this article are based on internal BAS testing against default detection content from selected SIEM platforms as of May 2026.

Remediation guidance   

Organizations should consider restricting mshta.exe network access and preventing it from spawning child processes where operationally feasible. Developer workflows also deserve closer scrutiny. Security teams should establish guidance around where installation commands may be sourced from and ensure that PowerShell and process creation logging is enabled to support detection and investigation.

The trust exploitation primitive   

At first glance, W17 and W20 appear to be entirely different campaigns. One stems from legitimate browser behavior and the other from malvertising. One operates silently in the background, while the other relies on explicit user action. One broadly affects enterprise endpoints and the other specifically targets developers.

What connects them is trust.

W17 exploits the trust that users and administrators place in their browser and the assumption that trusted software behaves only in ways that align with administrative expectations. W20 exploits the trust that developers place in familiar documentation and long-established installation workflows.

Neither campaign succeeds because users are careless. They succeed because the trust being exploited is legitimate and has been built over years of interacting with widely adopted software brands and familiar workflows.

This is the broader lesson for security teams. AI adoption is accelerating across browsers, IDEs, developer tooling, and enterprise applications, but governance around these technologies is still maturing. As a result, every widely adopted AI product with strong brand recognition and established workflows becomes a potential impersonation target.

The delivery mechanism may change from campaign to campaign. Today it may be a browser download or a sponsored search result. Tomorrow it may be an IDE plugin, a GitHub Action, or an AI agent marketplace. The underlying exploit, however, remains the same: attackers are increasingly targeting the trust that users extend to AI tools.

What security teams should do now   

For W17, organizations should deploy Chrome AI policies before attempting to remove downloaded model files, monitor browser policy changes, track large AI model downloads, and ensure that the required endpoint telemetry is enabled.

For W20, organizations should consider restricting mshta.exe network access, preventing it from spawning child processes, enabling PowerShell Script Block Logging, and establishing guidance around developer software installation practices.

More broadly, both campaigns expose a governance gap rather than a purely technical problem. Most organizations have mature policies around software installation, browser extensions, and endpoint security controls. Far fewer have established policies governing AI tools, including which tools are approved, how they may be installed, what configurations are permitted, and what telemetry should be collected.

Addressing those questions may ultimately prove more effective than any individual detection rule.

Detection is available now in Log360 

Log360's detection content for W17 and W20 has been lab-validated and is available now. Organizations should verify that the required endpoint and audit telemetry is enabled before relying on these detections.

The larger takeaway from these campaigns is not that AI tools are inherently risky. It is that trust itself is becoming an increasingly valuable target for attackers. Security teams spent years teaching users not to trust unknown software and suspicious websites. The next challenge will be recognizing that even familiar and legitimate AI brands can be used as vehicles for abuse.

In the AI era, attackers do not need users to trust them. They only need users to trust the brands they imitate.