A fake Claude Code installation page promoted through sponsored search results delivered an undocumented credential stealer by mimicking a familiar developer workflow, according to new research from Ontinue.
Victims looking for Claude Code installation instructions were directed to a lookalike documentation page and told to run a one-line PowerShell command. To developers accustomed to command-line installers, the instruction may not have looked unusual. The campaign did not exploit Claude Code itself; it exploited the trust developers place in documentation pages and copied installation commands.
Ontinue found that the installer file appeared benign. A direct request to the site’s /install.ps1 URL returned what looked like a legitimate Claude Code installation script. But the command shown on the webpage was different. According to the researchers, the malicious PowerShell instruction was embedded in the page’s HTML rather than in the installer file. That meant automated scanners — or security researchers reviewing only the installer URL — could see a harmless script while victims copying the on-page command executed malware.
A Staged Infection Chain
Once executed, the PowerShell command pulled additional content from attacker-controlled infrastructure and launched a staged infection chain. Ontinue said the loader used obfuscated PowerShell to collect system identifiers, identify Chromium-based browsers, and coordinate the theft of stored secrets.
The campaign’s structure was important because suspicious behavior was divided across components. PowerShell handled the visible, noisier parts of the operation, including browser enumeration, data collection, archive creation, exfiltration, and persistence. A separate native helper performed the narrower task of recovering encryption material from Chromium’s App-Bound Encryption system.
That split helped the malware evade some detection approaches that look for a single binary carrying out obviously malicious actions.
Ontinue also found a geographic check in the PowerShell stage that excluded systems in CIS countries and Iran, a detail that may point to attacker operational preferences, though it is not enough on its own for attribution.
The Real Objective: Browser Secrets
The goal wasn’t sabotage or ransomware. It was browser data.
According to Ontinue, the malware targeted Chromium-family browsers and attempted to decrypt cookies, saved passwords, and payment methods. The PowerShell stage then packaged the stolen data into an in-memory archive and exfiltrated it to the attacker-controlled infrastructure.
The risk of this campaign doesn’t end with the compromised workstation. Stolen browser sessions and credentials can give attackers access to cloud dashboards, code repositories, developer tools, and administrative consoles, depending on what the compromised user had saved or authenticated in the browser.
“Developers hold the keys to an organization's most sensitive assets — intellectual property, cloud infrastructure, CI/CD pipelines,” said Vineeta Sangaraju, AI Research Engineer at Black Duck. “One compromised developer workstation does not stay contained.”
The Technical Twist: Abusing Browser Encryption
Swapping a legitimate installer for a malicious command is a familiar tactic. The more important finding was how the payload worked around protections designed to make browser credential theft harder.
Google introduced App-Bound Encryption in Chrome to raise the bar against stealers that simply copy local browser databases. Ontinue noted that ABE was not designed to protect against code already running as the user. The malware took advantage of that limitation by using a small native helper inside a Chromium-family browser process to recover encryption material needed to decrypt protected browser data.
The helper itself was intentionally limited. Ontinue said it had no persistence, file I/O, networking, or secondary stage. Its job was to recover the browser’s protected encryption key from inside the browser’s own security context, while PowerShell handled the rest of the operation.
For defenders, Ontinue’s findings suggest the architecture matters as much as the payload. The technique drew from earlier public research on Chrome App-Bound Encryption bypasses, but Ontinue said the orchestration model was distinct: a small, single-purpose helper paired with a larger PowerShell operation.
Why Detection Is Harder
Ontinue said two standard API-chain rule sets it evaluated against the native helper returned no matches. That does not mean the campaign was undetectable. It means defenders looking only at the helper binary may miss the larger operation.
The malicious behavior appeared across multiple layers, including the PowerShell pipeline, browser process injection, named-pipe communication, COM calls to the browser elevation service, browser database access, exfiltration, and scheduled-task persistence.
The campaign also showed signs of active maintenance. Ontinue said the helper included support for Chrome 144’s IElevator2 interface, released earlier this year, along with fallback logic for older interfaces. The report also identified an Edge IElevator2 identifier transcription error that could give defenders a useful detection signal.
Defensive Steps
The defensive lesson is not simply to block developers from installing tools. Developers often need the freedom to test and adopt software. The challenge is to reduce the chance that a search result or lookalike page becomes the source of an installation command.
Security teams should prioritize visibility into PowerShell activity, including script block logging and monitoring for obfuscated scripts. Ontinue recommended enforcing PowerShell Constrained Language Mode where possible, enabling Microsoft Attack Surface Reduction rules that block potentially obfuscated scripts, verifying that AMSI is enabled, and monitoring for tampering.
The report also recommended blocking newly registered domains through web content filtering and requiring phishing-resistant MFA for developer and administrator accounts.
Sangaraju said organizations should consider creating verified, internally shared installation commands for commonly used developer tools so staff are not searching externally for them. “The solution is not blunt-force blocking or adding another firewall rule,” she said. “Security teams should revisit detection strategies that account for trusted, native system components being abused.”
