InstallFix shows how cloned dev tools turn search into malware

At a glance

What this is: InstallFix is a browser-delivered social engineering campaign that clones developer tool install pages and swaps legitimate commands for malware-laden ones.

Why it matters: It matters because identity and access teams must treat copy-paste install flows, search-ad delivery, and browser-executed commands as part of NHI and endpoint risk, not just developer convenience.

By the numbers:

• 4 in 5 ClickFix lures we intercept are accessed from search engines.

👉 Read Push Security's analysis of the InstallFix campaign targeting Claude Code

Context

InstallFix is a social engineering pattern that abuses trust in software installation instructions. Attackers clone the pages for popular developer tools, then alter the command line instructions so a copied install command executes malware instead of legitimate code. The primary issue is not the tool itself, but the assumption that a trusted-looking domain and a familiar install pattern are enough to establish safety.

That assumption matters to identity governance because modern developer workflows often move secrets, tokens, and privileged access through the terminal before any traditional security control sees them. As AI tools become more widely used, the audience for these attack pages expands beyond experienced developers to users who may not recognise the risk of pasted shell commands. This is a browser-to-terminal attack path, not a classic phishing email problem.

Key questions

Q: How should security teams handle copy-paste install commands for developer tools?

A: They should treat copied install commands as executable code, not as documentation. Prefer signed packages, managed software distribution, or internal mirrors for common tools, and require review before any command that downloads remote content is run from a browser page. That reduces the chance that a cloned page can turn trusted install behaviour into malware execution.

Q: Why do search ads create extra risk for developer tool installs?

A: Search ads can place a malicious clone above the legitimate result and make the page feel normal before the user clicks. That matters because the user initiates the visit, which bypasses email security controls and gives the attacker a trusted browser session as the delivery channel. The real risk is not the ad alone, but the trust it inherits from the search process.

Q: What breaks when a terminal install page is cloned by attackers?

A: The trust model breaks. Users assume the page, the URL, and the command line instruction are aligned, but a clone can keep the visual context while swapping the command for malware delivery. Once that happens, the browser becomes a code execution gateway and any secrets already present on the endpoint become exposed to theft.

Q: What should teams do when infostealers target browser credentials?

A: They should assume browser cookies, saved passwords, and session tokens can be reused to reach cloud and developer systems. That means shortening token lifetimes, isolating privileged sessions, and reviewing where developers authenticate to critical tools. If stolen browser material can open NHI-adjacent access paths, credential hygiene has to include the browser.

Technical breakdown

Cloned install pages and malicious command substitution

InstallFix works by replicating the visual structure of a legitimate installation page, including branding, layout, and documentation navigation, while replacing the command text with attacker-controlled instructions. The user sees a trusted install flow and copies a command that looks normal, but the shell executes remote content from a malicious domain. The technique is effective because the security boundary is not the page alone, it is the exact command string being pasted into the terminal. In practice, the attack turns documentation trust into code execution trust.

Practical implication: inspect copied install commands as executable content, not as documentation text.

Malvertising as the entry point for browser-based compromise

The campaign uses sponsored search results to place the fake page above or alongside legitimate results, which means the user initiates the visit through normal search behaviour. That bypasses email gateways and other controls built around inbound message inspection. Because the browser renders the attack page just like a real one, the delivery channel becomes part of the attack chain rather than a separate precondition. Search visibility, ad abuse, and lookalike domains combine to make the lure feel routine instead of suspicious.

Practical implication: extend detection and awareness beyond email to browser sessions and search-ad delivery.

Staged payload execution and infostealer behaviour

The observed payload uses layered execution, including cmd.exe calling mshta.exe to retrieve remote content, with macOS variants using additional encoding and staging. The final malware, identified by Push as matching Amatera Stealer signatures, is designed to harvest browser passwords, cookies, session tokens, and system data. That matters because stolen session material can be reused to bypass normal authentication controls and move into NHI-adjacent access paths. The architecture is built for fast credential theft and operational persistence, not noisy exploitation.

Practical implication: treat terminal-delivered malware as a session-token and secret-exfiltration risk, not only an endpoint event.

Threat narrative

Attacker objective: The attacker wants to convert trusted install behaviour into credential theft that can support account takeover and broader access reuse.

1. Entry occurs when a user reaches a lookalike developer tool page through malicious search advertising and follows a cloned install flow.
2. Credential access happens after the pasted install command pulls staged content from attacker infrastructure and the malware harvests browser passwords, cookies, and session tokens.
3. Impact follows when stolen credentials and session material are reused to access accounts, systems, and downstream non-human identities with the victim's trust context.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install instructions have become an identity trust boundary. The old assumption was that a user could safely copy a command from a documentation page if the site looked legitimate. That assumption fails when the page itself is a clone and the command is the payload. Practitioners should treat install flows as a governed access path, not a convenience layer.

Search advertising is now part of the attack surface for NHI and developer access. Attackers are not relying on email compromise when they can place the lure directly above legitimate documentation in search. That means visibility, ranking, and browser rendering all influence whether a user reaches a hostile command. Security programmes that stop at inbox controls miss the real entry point.

Browser session theft is a downstream NHI problem, not only an endpoint problem. Amatera and similar stealers target cookies, tokens, and saved passwords that can be reused against developer tools, cloud consoles, and service access paths. That creates a bridge from a user-level click to non-human identity compromise. The practical conclusion is that session material must be treated as identity infrastructure, not just cached browser data.

Ephemeral trust in install commands creates a new form of identity exposure debt. Each successful copy-paste event can create short-lived but high-value credential exposure before any review or rotation process starts. For NHI governance, that means the weakest link is not only secret storage, but the moment a user chooses to trust a command string. Teams should model that exposure window explicitly.

Malvertising-driven tool impersonation is becoming a repeatable pattern across the developer ecosystem. Claude Code, NotebookLM, Homebrew, and similar tools show that any widely searched install path can be cloned and weaponised. The field should stop treating these as isolated brand impersonations and start treating them as a category of command-line credential capture. Practitioners need controls that assume search result manipulation is normal, not exceptional.

From our research:

• 4 in 5 ClickFix lures we intercept are accessed from search engines, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations say they are confident in their secrets management capabilities.
• For a broader case library on how compromised identities are used in real incidents, see 52 NHI Breaches Analysis.

What this signals

InstallFix turns developer search behaviour into an access-control problem. Teams that manage cloud, build, and AI tool access need to assume the browser is now part of the identity perimeter, because the first trust decision often happens before any secret is entered. That makes command provenance, search-result integrity, and browser telemetry part of the governance stack, not optional hardening.

With 4 in 5 ClickFix lures arriving through search engines, the programme-level lesson is that traditional anti-phishing controls are too narrow for modern developer workflows. Security teams should combine browser detection with identity monitoring and search-risk review, then anchor their response in resources like the 52 NHI breaches Report and the Top 10 NHI Issues.

For practitioners

• Block direct execution of copied shell install commands where possible Route installation through reviewed package sources, signed artifacts, or managed software distribution so users are not pasting remote execution commands from arbitrary pages.
• Add browser-side detection for cloned install pages Monitor for lookalike domains, copy-to-clipboard command blocks, and search-ad referral patterns in the browser, because those signals often appear before endpoint malware runs.
• Treat session tokens and saved browser credentials as high-value identity material Harden cookie and token lifetimes, review where developer credentials are stored, and assume infostealers will target the browser before they target cloud control planes.
• Review developer search journeys for impersonation risk Test the search terms your teams actually use to install tools, then determine whether sponsored results, cloned docs, or redirect chains could place malicious commands above legitimate documentation.

Key takeaways

• InstallFix is a browser-to-terminal attack pattern that converts trust in documentation into malware execution.
• The evidence points to search advertising, cloned pages, and session theft as the practical weak points, not just the endpoint.
• Identity teams need to govern install flows, browser credentials, and search-driven entry points as part of the same risk surface.

Key terms

• InstallFix: A browser-delivered social engineering pattern where attackers clone a legitimate software installation page and replace the command instructions with malicious content. The attack succeeds by exploiting trust in documentation and the habit of pasting install commands directly into a terminal.
• Malvertising: The use of online ads to distribute malicious links or payloads. In this context it places cloned developer tool pages ahead of legitimate results, giving the attacker a trusted-looking entry point without needing an email campaign or direct social contact.
• Infostealer: Malware designed to quietly collect credentials, cookies, tokens, and other sensitive data from a device. Once it captures browser material, the attacker can often reuse that information to access developer tools, cloud services, and other identity-bound systems.
• Command Provenance: The trust relationship between a command and the source that supplied it. When provenance is weak, users may run remote code from a cloned page without noticing that the command points to attacker infrastructure instead of the legitimate software provider.

Deepen your knowledge

InstallFix and browser-delivered NHI risk are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with developer tooling, session theft, or copy-paste command exposure, it is worth exploring.

This post draws on content published by Push Security: Attackers are cloning developer tool install pages to deliver infostealer malware through malicious search ads. Read the original.