Как в 2025 доверие обернулось угрозой: анализ атак на цепочки поставок

Современная разработка держится на зависимостях, автоматизации и внешних сервисах, которым принято доверять по умолчанию. Именно такое доверие всё чаще становится входом для атак: без взлома периметра и без эксплуатации «классических» уязвимостей.

 

 

 

 

 

 

1. Введение
2. Атаки на цепочку поставок и меры противодействия
   
   1. 2.1. Получение доступа к данным «Ростелекома»
   2. 2.2. Масштабная атака на экосистему npm
   3. 2.3. Атака на цепочку поставок ПО «GhostAction»
   4. 2.4. Нарушение работы предприятий Jaguar Land Rover (JLR)
   5. 2.5. Поражение репозиториев разработчиков и CI / CD-инфраструктуры
   6. 2.6. Пакет NPM был уличён в краже сообщений из мессенджера
3. Последствия атак на цепочку поставок
4. Защита от атак на цепочки поставок
5. Выводы

Введение

Проще взломать небольшого поставщика с низким уровнем защиты, чем атаковать крупную корпорацию напрямую. На этом принципе и основан смещающийся в последние годы подход злоумышленников: компрометация одного звена цепочки поставок открывает доступ к широкому кругу крупных клиентов, получающих обновления и компоненты по доверенным каналам. Статистика за 2025 год подтверждает эту тенденцию: атаки на цепочки поставок (Supply Chain Attacks), компаний выросли на 110 %.

Эта тема уже неоднократно и достаточно детально рассматривалась в наших публикациях. Мы говорили не только о компрометации программного обеспечения (ПО), но и о рисках, связанных с аппаратными компонентами, облачными сервисами, подрядчиками и сервис-провайдерами, а также о злоупотреблении доверительными и делегированными полномочиями. Обсуждение велось в аналитических материалах и в формате экспертных дискуссий с участием практиков рынка, где рассматривались реальные сценарии компрометации и их последствия для downstream-организаций (компаний, работающих на финальных этапах производственной цепочки).

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

В совокупности эти материалы позволили сформировать целостное представление о цепочках поставок как о распределённой поверхности атаки, где ключевую роль играют не отдельные технологии, а связи между участниками экосистемы, процессы и принятые модели доверия.

Атаки на цепочку поставок и меры противодействия

Чтобы оценить реальные масштабы угрозы, важно опираться не на общие рассуждения, а на конкретные инциденты, в которых уязвимость поставщика привела к компрометации его клиентов. Рассмотрим ряд показательных кейсов, позволяющих проследить, какие элементы цепочки поставок становились точкой входа для атаки в 2025 году и какие меры на практике оказались эффективными для ограничения ущерба или прекращения нападения.

Получение доступа к данным «Ростелекома»

Группировка хактивистов Silent Crow объявила о получении доступа к данным двух интернет-ресурсов «Ростелекома»: company.rt.ru и zakupki.rostelecom.ru. Взлом затронул формы обратной связи, через которые злоумышленники получили базы данных с адресами электронной почты (154 000) и телефонами (101 000) пользователей. В самой компании заявили, что причиной утечки стал подрядчик, обслуживавший атакованные интернет-ресурсы.

В рамках атаки были задействованы техники:

• компрометация инфраструктуры стороннего подрядчика;
• эксплуатация уязвимых элементов веб‑приложений;
• злоупотребление доверительными отношениями между заказчиком и поставщиком услуг;
• несанкционированный доступ к данным через легитимные каналы обслуживания интернет‑ресурсов.

«Ростелеком» сообщил, что утечки данных не произошло: ресурсы company.rt.ru и zakupki.rostelecom.ru не предназначены для обслуживания физических лиц, и на них отсутствуют персональные данные. Пользователям было рекомендовано сбросить пароли и включить двухфакторную идентификацию там, где это возможно.

Масштабная атака на экосистему npm

В экосистеме JavaScript в сентябре 2025 был зафиксирован крупный инцидент, объектом которого был Node Package Manager (npm) и ряд широко используемых JavaScript‑пакетов, входящих в цепочки поставок программного обеспечения.

В рамках атаки были задействованы следующие техники модификации ПО и использования учётных данных поставщика. Злоумышленники получили доступ к учётным данным мейнтейнера (разработчика) npm‑пакетов Джоша Джунона (известного как qix) через фишинговую кампанию. Письмо пришло с поддельного домена npmjs.help и выглядело как официальное уведомление о необходимости обновить двухфакторную аутентификацию.

 

Рисунок 1. Фишинговое письмо с поддельного домена npmjs.help

 

В результате инцидента были скомпрометированы порядка 150 программных пакетов, включая компоненты, связанные с экосистемой CrowdStrike. Часть затронутых библиотек, имеющих миллионы загрузок в неделю, содержала вредоносный код, предназначенный для хищения токенов и ключей аутентификации. Его особенность — способность распространяться автоматически, заражая другие доступные пакеты.

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

Атака на цепочку поставок ПО «GhostAction»

В сентябре 2025 года исследователи из GitGuardian раскрыли масштабную кампанию «GhostAction», затронувшую 327 пользователей GitHub и 817 репозиториев. Злоумышленники внедрили вредоносные рабочие процессы, которые через HTTP-запросы POST к удалённой конечной точке похитили 3 325 секретов, включая токены PyPI, npm и DockerHub.

В рамках кампании применялась простая, но эффективная схема атаки. Злоумышленники распространяли вредоносные рабочие процессы, замаскированные под улучшения безопасности. Каждый workflow с названием «Добавить рабочий процесс безопасности GitHub Actions» содержал скрытый код для кражи данных, который срабатывал при отправке изменений или при ручном запуске.

 

Рисунок 2. Вредоносный файл рабочего процесса GitHub

 

Рабочие процессы были настроены на поиск и соответствие конкретным именам секретов, найденных в скомпрометированных репозиториях, что значительно повышало вероятность успешной эксфильтрации. Компрометация учётной записи разработчика позволяла злоумышленникам повышать привилегии и получать доступ к секретам CI / CD, открывая потенциальный путь к производственным средам.

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

• Провести аудит репозиториев на предмет наличия вредоносных рабочих процессов.
• Удалить все выявленные угрозы и нежелательные workflow‑файлы.
• Внедрить политики, блокирующие эксфильтрацию секретов из непроверенных workflow, чтобы предотвратить доступ к секретам из неавторизованных или непроверенных процессов.
• Активировать защиту веток (branch protection), требующую проверки pull request перед слиянием изменений, особенно для файлов workflow.

Хотя непосредственная угроза была нейтрализована благодаря действиям GitGuardian и сообщества специалистов по безопасности, инцидент стал тревожным сигналом для отрасли.

Нарушение работы предприятий Jaguar Land Rover (JLR)

В конце августа 2025 атака парализовала ИТ-системы JLR, что вынудило концерн остановить производство на всех трёх британских заводах. Простои длились около шести недель, задержался выпуск тысяч запланированных автомобилей. Убытки составили почти 2 млрд фунтов стерлингов. В октябре выпуск авто просел на 25 % в годовом сравнении.

Последствия атаки вышли далеко за пределы самого автопроизводителя. Более 70 % предприятий-подрядчиков сообщили о негативном влиянии инцидента на свою деятельность. Производственные процессы и цепочки поставок были тесно связаны с автоматизированными системами JLR, поэтому после отключения сетей остановка конвейеров у поставщиков стала неизбежной.

По результатам опросов, почти половина подрядчиков понесла существенные финансовые потери из-за отмены заказов и срыва графиков поставок. Около трети организаций были вынуждены временно сократить рабочую неделю либо отправить сотрудников в отпуска. Каждая седьмая компания прибегла к сокращению персонала. Отдельные малые предприятия прямо указывали на риск банкротства, поскольку остановка производственных линий JLR лишила их выручки на несколько недель вперёд.

JLR отказалась комментировать результаты исследования, но заявила, что постепенно возобновляет часть производства. Для расследования и ликвидации последствий автопроизводитель работает совместно с Национальным центром кибербезопасности (National Cyber Security Centre, NCSC).

Поражение репозиториев разработчиков и CI / CD-инфраструктуры

Исследователи Wiz Research и Wiz CIRT отслеживают активность Shai-Hulud 2.0 с 24 ноября и отмечают: несмотря на общее замедление, распространение вредоносного кода не прекращалось. Показательный всплеск был зафиксирован 1 декабря, когда за 12 часов появилось более 200 новых заражённых репозиториев. По оценкам аналитиков, кампания носит волнообразный характер. Наиболее часто вредонос обнаруживается в средах CI / CD, где основная доля инцидентов приходится на GitHub Actions. Значительно реже заражения фиксируются в Jenkins, GitLab CI и AWS CodeBuild.

 

Рисунок 3. CI / CD-платформы, в которых зафиксировано распространение Shai-Hulud 2.0

 

Shai-Hulud — самовоспроизводящийся червь экосистемы npm, получивший название по мотивам фильма «Дюна». После заражения системы червь осуществляет поиск раскрытых секретов, включая API-ключи и токены, с использованием инструмента TruffleHog. Обнаруженные данные публикуются в публичном репозитории GitHub, после чего вредонос пытается загрузить новые копии самого себя в npm, обеспечивая дальнейшее распространение и утечку данных.

К моменту анализа вредонос затронул более 30 000 репозиториев, при этом порядка 70 % из них содержали уникальные признаки конкретных заражённых сред. Отдельно отмечается компрометация более 500 GitHub-токенов и логинов, что обеспечивает злоумышленникам прямой доступ к учётным записям и формирует основу для последующих атак на связанные проекты и инфраструктуры.

Тем, кто успел загрузить заражённые пакеты, рекомендовано:

• откат к безопасным версиям пакетов, очистка кеша npm;
• аудит пайплайна CI / CD и компьютеров разработчиков на предмет несанкционированных изменений;
• анализ логов для идентификации подозрительных обращений к npm publish;
• замена ключей и токенов NPM, GitHub, AWS, GCP, Azure, которые были доступны в поражённой среде.

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

Пакет NPM был уличён в краже сообщений из мессенджера

Lotusbail — практически идеальная подделка. Авторы просто склонировали библиотеку, форк официального пакета @whiskeysockets/baileys (популярной библиотеки для работы с WhatsApp API), и аккуратно встроили в неё вредоносный код. Снаружи всё выглядело легитимно: приложения на базе lotusbail спокойно отправляли и получали сообщения.

Но за этой рабочей функциональностью скрывалась сложная вредоносная программа, которая ворует учётные данные WhatsApp (принадлежит запрещённой в России и признанной экстремистской организации Meta), перехватывает каждое сообщение, собирает контакты пользователей, устанавливает постоянный бэкдор и шифрует всё перед отправкой на сервер злоумышленника.

Перехватывались не только новые сообщения, но и исторические данные, доступные через API. В коде пакета был зашит жёстко заданный, зашифрованный AES код привязки (Advanced Encryption Standard, надёжный алгоритм симметричного блочного шифрования), который незаметно подключал устройство атакующего к аккаунту жертвы.

 

Рисунок 4. Зашифрованный с помощью алгоритма AES код, скрытый в пакете

 

Злоумышленник получал постоянный доступ к аккаунту, который сохранялся даже после удаления из проекта вредоносного пакета.

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

Последствия атак на цепочку поставок

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

На практике такие атаки редко сводятся не только к краже данных. Гораздо чаще они приводят к остановке сервисов и ключевых бизнес-процессов. Простой, массовые сбои и затянутое восстановление инфраструктуры становятся одними из самых тяжёлых последствий. Эти сбои нередко затрагивают не только одну компанию, но и её партнёров, что вызывает цепную реакцию в отрасли. Опрос Invenio IT показал, что 100 % организаций, пострадавших от кибератак, понесли прямые потери прибыли из-за простоев и в среднем сталкивались с 86 незапланированными отключениями в год.

Согласно статистике за 2025 год, восстановление после атак на цепочку поставок занимает значительное время: 72 % организаций тратят на возврат к нормальной работе более недели. В таких сферах, как производство и здравоохранение, сроки восстановления часто превышают 6 недель. При этом сам простой обходится очень дорого: более 90 % средних и крупных компаний теряют свыше 300 тысяч долларов США за каждый час недоступности своих систем.

Финансовый ущерб не ограничивается потерями от остановки работы. Существенные затраты возникают из-за расследования инцидента, восстановления инфраструктуры, юридических последствий и репутационного ущерба. Согласно исследованию Security Scorecard, устранение последствий инцидентов в цепочке поставок обходится в 17 раз дороже, чем устранение последствий внутренних нарушений.

Оценить реальный масштаб атак на цепочки поставок сложно. Большинство инцидентов не становится публичным из-за репутационных рисков и договорных обязательств. По этой причине даже компании, которые занимаются расследованием киберинцидентов и анализом деятельности хакерских групп, располагают лишь частью информации.

Защита от атак на цепочки поставок

В рамках прямого эфира AM Live эксперты уже разбирали ключевые подходы к контролю рисков в Supply Chain Attacks: от анализа зависимостей и перечней компонентов (Software Bill of Materials, SBOM) до внедрения практик DevSecOps (интеграции безопасности на каждом этапе жизненного цикла ПО) и аудита. Вопрос уменьшения рисков последствий и предотвращения атак рассматривается комплексно и охватывает несколько уровней.

На организационном уровне компании усиливают контроль над подрядчиками и поставщиками, внедряют прозрачные процессы разработки, обязательный аудит поставщиков и мониторинг активности в CI / CD‑средах. На технологическом уровне используются специализированные решения, включая прокси-сервисы для проверки компонентов открытого кода, инструменты управления уязвимостями, анализ исходного кода и интеграция SIEM / SOAR для оперативного обнаружения аномалий.

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

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

Выводы

Анализ показал, что доверие к сервисам, компонентам и подрядчикам может стать источником угроз для всей инфраструктуры. Перспектива понести ответственность за инциденты, инициированные через Supply Chain Attacks, радикально меняет подход к выбору поставщиков и подрядчиков.

Теперь ключевым критерием становится не только цена или скорость выполнения работ, но и способность исполнителя поддерживать надёжную киберзащиту. Компетентность и защищённость подрядчика превращаются в стратегическое преимущество. Прозрачные процессы разработки, своевременное устранение уязвимостей, управление доступами и мониторинг безопасности оказываются важнее любых скидок или ускоренных сроков.