Как поддельная страница документации внедрилась в современный рабочий процесс разработчика

Представьте себе инженера-программиста среднего звена по имени Алекс. Сейчас 15:00 вторника, и Алекс хочет сэкономить двадцать минут на утомительной задаче по рефакторингу. Он слышал много хорошего о Claude Code — интерфейсе командной строки от Anthropic для агентного программирования. Быстрый поиск по запросу «install claude code» выдает спонсируемый результат, который выглядит неотличимым от официальной документации. Страница чистая, типографика идеально соответствует эстетике Anthropic, и на ней есть простая однострочная команда PowerShell, готовая к копированию и вставке в терминал.

Алекс, как и тысячи других разработчиков, находящихся под давлением сроков, доверяет рейтингу поисковой системы. Он копирует команду, вставляет ее в свою административную оболочку и нажимает Enter. Для Алекса установка, кажется, проходит нормально. Однако за кулисами его рабочая станция только что стала начальной точкой доступа для сложной кампании, предназначенной для кражи учетных данных из его браузера и проникновения в самое сердце инфраструктуры организации.

С точки зрения рисков, это не просто очередная фишинговая атака. Это высокоточный удар по привратникам цифрового королевства. Эта кампания, впервые подробно описанная 11 мая 2026 года Центром киберзащиты Ontinue, подчеркивает смещение фокуса злоумышленников. Нацеливаясь на инструменты, которые разработчики используют для сборки, атакующие фактически обходят парадную дверь и заходят прямо в серверную.

Иллюзия канонической документации

Гениальность этой кампании заключается в ее простоте. Злоумышленники не просто создали поддельный сайт; они создали зеркало. Страница-приманка имитировала макет легитимной документации Claude Code, но с критическим отклонением: команда установки, отображаемая в HTML, была изменена. В то время как подлинная команда Anthropic загружает данные из доверенного репозитория, вредоносная версия указывала на один из трех контролируемых оператором доменов, зарегистрированных в период всплеска активности в апреле 2026 года.

Когда я впервые изучил сетевой трафик, связанный с этой кампанией, я заметил хитрый прием, предназначенный для обхода автоматических сканеров URL. Если инструмент безопасности, такой как «песочница» или поисковый робот, запрашивал файл /install.ps1 напрямую, сервер возвращал дословную чистую копию подлинного установщика Claude Code. Вредоносная нагрузка доставлялась только при обнаружении специфических заголовков или поведения, характерного для браузера. Это цифровой эквивалент троянского коня, который открывает потайную дверь только после того, как благополучно окажется внутри городских стен.

Разделение атаки: нативный сплит в PowerShell

После выполнения терминал жертвы не просто устанавливает инструмент для программирования; он загружает PowerShell-загрузчик размером 600 КБ. Этот скрипт сильно обфусцирован — обычная тактика, но именно то, как он обрабатывает саму кражу, привлекло мое внимание. С проактивной точки зрения, большинство правил поведенческого обнаружения ищут подозрительную активность в рамках одного процесса. Если нативный бинарный файл начинает устанавливать сетевые соединения и читать базы данных браузера, срабатывают флажки тревоги.

Чтобы обойти это, злоумышленники использовали архитектуру с разделением функций. PowerShell-загрузчик выполняет основную работу по подготовке среды: он перечисляет браузеры семейства Chromium, такие как Chrome, Edge, Brave, Vivaldi, а также новые Arc или Perplexity Comet. Затем он рефлексивно внедряет крошечный нативный вспомогательный модуль размером 4608 байт в живой легитимный процесс браузера.

Этот помощник — мастер-класс по минимализму. Он не содержит импортов для работы с сетью, файлами или криптографией. При форензическом анализе в изоляции бинарный файл выглядит почти инертным. Его единственная цель — служить мостом, вызывая внутренние интерфейсы браузера для получения ключей шифрования. К тому времени, когда PowerShell-скрипт использует эти ключи для чтения баз данных SQLite, содержащих файлы cookie и пароли, «вредоносное» действие уже распределено по разным уровням операционной системы, что делает его почти невидимым для традиционных инструментов обнаружения и реагирования на конечных точках (EDR).

Обход цифрового сейфа: эксплойт IElevator2

Архитектурное ядро атаки нацелено на специфическую функцию безопасности в современных браузерах: App-Bound Encryption (шифрование с привязкой к приложению). Внедренная именно для предотвращения подобного рода краж, технология App-Bound Encryption привязывает конфиденциальные данные к идентификатору приложения, теоретически не позволяя стороннему скрипту просто захватить папку с cookie и запустить ее.

Однако злоумышленники, стоящие за этой кампанией, с хищным вниманием отслеживали изменения в Chromium. В течение 60 дней после выпуска Chrome 144 в январе 2026 года они уже адаптировали свой загрузчик для атаки на COM-интерфейс IElevator2. С точки зрения целостности данных, этот интерфейс предназначен для работы в качестве высокопривилегированной службы, позволяющей браузеру выполнять специфические задачи. Вредоносное ПО обманом заставляет эту службу выдать мастер-ключ, фактически обращая механизмы безопасности браузера против него самого.

По моему опыту анализа загрузчиков уровня APT, такая гибкость встречается редко. Это указывает на оператора, который не просто является «скрипт-кидди», использующим утечки готовых наборов, а представляет собой команду разработчиков, целенаправленно работающую над преодолением дорожной карты безопасности Chromium. Интересно, что они оставили след собственной ошибки: опечатку в идентификаторе Edge IElevator2. Два ниббла были переставлены местами в поле Data3. Это приводит к сбою первоначального высокотехнологичного вызова, заставляя вредоносное ПО откатываться к более старому и «шумному» интерфейсу. Для защитника этот неправильно сформированный идентификатор — настоящий подарок, высоконадежная сигнатура обнаружения, которую можно использовать для поиска этого конкретного семейства во всей сети.

Разработчик как ценная точка перехода

Мы часто говорим о «человеческом факторе» в контексте административных помощников или финансовых отделов, но разработчики представляют собой уникальный и повсеместный риск. Как отметила Винита Сангараджу, инженер по исследованиям в области ИИ в Black Duck, скомпрометированная рабочая станция разработчика редко является конечной целью для атакующего. Это точка перехода.

Разработчики обычно имеют широкий доступ к критически важным активам. На их машинах хранятся сессионные cookie для GitHub, AWS и внутренних конвейеров CI/CD. У них есть SSH-ключи от рабочих серверов и API-токены, которые позволяют обходить многофакторную аутентификацию. Одна скомпрометированная рабочая станция не остается изолированной; она запускает каскад. Атака переходит в репозитории исходного кода, где злоумышленники могут внедрять бэкдоры в программное обеспечение для последующих пользователей — маневр, который мы видели в системных атаках на цепочки поставок, таких как SolarWinds.

Кроме того, вредоносное ПО включает список «региональных исключений». Если загрузчик обнаруживает, что хост находится в России, Иране или других странах СНГ, он завершает работу без каких-либо действий. Это характерный признак акторов, действующих из этих регионов и желающих избежать внимания местных правоохранительных органов, что добавляет геополитический контекст к техническому анализу.

Построение устойчивой защиты от атак на инструменты разработки

Итак, как нам защититься от атаки, которая выглядит как легитимная часть рабочего процесса разработчика? Если оставить в стороне патчи — поскольку это вредоносное ПО эксплуатирует валидные интерфейсы, а не неисправленные уязвимости — мы должны рассмотреть архитектурные меры контроля.

С проактивной точки зрения, наиболее эффективной контрмерой является принудительное использование режима ограниченного языка PowerShell (PowerShell Constrained Language Mode, CLM). Это ограничивает возможность скриптов вызывать сложные API-интерфейсы COM и Win32, необходимые для рефлексивной инъекции. В сочетании с надежным журналированием блоков скриптов это позволяет аналитикам SOC видеть «как» произошла атака, даже если «что» было обфусцировано.

Кроме того, нам необходимо относиться к рабочей станции разработчика как к среде с высоким уровнем доверия и высокого риска. Это означает:

1. Внедрение фильтрации веб-контента, которая блокирует недавно зарегистрированные домены (возрастом менее 30 дней), что нейтрализовало бы данную конкретную кампанию.
2. Переход от долгоживущих сессионных cookie к краткосрочным токенам, привязанным к оборудованию, для доступа к облачной инфраструктуре.
3. Обучение инженерных команд рискам установки методом «копировать-вставить» из неканонических источников, даже если они появляются в результатах поиска.

В конечном счете, безопасность — это игра в кошки-мышки, идущая со скоростью цикла выпуска Chrome. Эта кампания доказывает, что злоумышленники больше не ждут уязвимостей нулевого дня; они просто ждут, когда мы скопируем не ту строку кода.

Ключевые выводы для ИТ-директоров и руководителей служб безопасности

• Проверяйте источник: Убедитесь, что разработчики загружают инструменты CLI и пакеты только из официальных, проверенных репозиториев (например, прямые релизы GitHub или официальные реестры npm/pip), а не из сторонних зеркал документации.
• Мониторинг активности COM: Используйте инструменты EDR для мониторинга необычных процессов, вызывающих интерфейсы IElevator и IElevator2, обращая особое внимание на сигнатуру неправильно сформированного IID Edge.
• Охота за методами закрепления: Проводите аудит запланированных задач на предмет необычных интервалов опроса (например, раз в минуту), указывающих на внешние, не корпоративные C2-домены.
• Соблюдение принципа наименьших привилегий: Используйте Windows AppLocker или аналогичные технологии для предотвращения выполнения несанкционированных загрузчиков PowerShell в контексте с высокими привилегиями.

Источники:

• Ontinue Cyber Defense Center: Threat Intelligence Report (May 2026)
• Chromium Project: App-Bound Encryption Technical Documentation
• MITRE ATT&CK: T1059.001 (Command and Scripting Interpreter: PowerShell)
• NIST SP 800-207: Zero Trust Architecture

Отказ от ответственности: Данная статья предназначена исключительно для информационных и образовательных целей. Она не заменяет профессиональный аудит кибербезопасности, форензический анализ или услуги по реагированию на инциденты. Всегда консультируйтесь с квалифицированным специалистом по безопасности перед внесением значительных изменений в систему безопасности вашей организации.