После предыдущего разбора 13 взломов через подрядчиков я решил расширить материал. В первую статью вошли только истории, где поставщик, подрядчик или цепочка разработки действительно стали дорогой к системам заказчика. Критерий был строгий, поэтому за бортом остались Log4Shell, Snowflake, LastPass, Jaguar Land Rover, UNFI и ещё несколько громких случаев.
Они не стали от этого бесполезными. Просто отвечают на другие вопросы.
Эта статья шире: здесь 22 случая риска в цепочке поставок, а не 22 одинаковых «взлома через подрядчика». Где-то атакующий действительно прошёл через чужую учётную запись. Где-то отравил обновление. Где-то нашёл уязвимость в массовом продукте, не взламывая его разработчика. А иногда поставщика атаковали напрямую, но остановились уже его заказчики.
Разница не академическая. От неё зависит, что делать: отключать VPN, отзывать OAuth-токены, задерживать обновление, искать библиотеку в сборках или запускать резервный способ приёма заказов.
Карта 22 случаев
| № | Случай | Что произошло | Как его правильно классифицировать |
|---|---|---|---|
| 1 | SolarWinds Orion | вредонос попал в штатное обновление | компрометация поставщика ПО |
| 2 | Kaseya VSA | RMM развернул шифровальщик ниже по цепочке | атака через платформу MSP |
| 3 | NotPetya / M.E.Doc | заражённое обновление бухгалтерского ПО | компрометация канала обновлений |
| 4 | Codecov | подменённый CI-скрипт крал секреты | компрометация инструмента разработки |
| 5 | Log4Shell | уязвимость оказалась в массовой библиотеке | риск зависимости, не взлом Apache |
| 6 | 3CX DesktopApp | троянизирован официальный клиент | двойная атака на цепочку разработки |
| 7 | Okta / Sitel | взломана рабочая станция инженера поддержки | вход через подрядчика |
| 8 | MOVEit Transfer | массово использована SQL-инъекция | уязвимость продукта, не взлом Progress |
| 9 | Snowflake | украденные логины открыли клиентские хранилища | компрометация клиентских доступов, в том числе подрядчиков |
| 10 | LastPass | атакован компьютер инженера самого поставщика | взлом поставщика через стороннее ПО |
| 11 | Microsoft / SolarWinds | исходный код просмотрели после атаки на Orion | последствие случая № 1, а не новая кампания |
| 12 | Target / HVAC | украдены данные подрядчика по вентиляции | вход через подрядчика |
| 13 | Lifting Zmiy | контроллеры лифтов использовали как инфраструктуру атак | взлом инженерного оборудования, но не доказанный вход к его заказчику |
| 14 | Интегратор и маскировка под 1С | старый доступ подрядчика привёл к шифрованию | вход через интегратора; 1С была маскировкой |
| 15 | «Ростелеком» | вероятным источником утечки названа инфраструктура подрядчика | инцидент у подрядчика сайта |
| 16 | Salesloft Drift / Salesforce | похищены OAuth-токены интеграции | атака через SaaS-связь |
| 17 | Shai-Hulud | токены npm использовали для заражения следующих пакетов | самораспространяющаяся атака на зависимости |
| 18 | Red Hat Cloud Services npm | вредонос попал в 32 пакета | компрометация учётной записи разработчика |
| 19 | Trellix | открыт доступ к части репозиториев исходного кода | взлом поставщика; путь входа не раскрыт |
| 20 | Jaguar Land Rover | атака остановила производство и ударила по поставщикам | операционный риск цепочки; путь входа не раскрыт |
| 21 | Marks & Spencer | социальная инженерия началась со стороннего MSP | вход через подрядчика |
| 22 | UNFI | атака на дистрибьютора нарушила исполнение заказов | атака на узел цепочки, не через него |
Отравленные обновления и чужой код
1. SolarWinds Orion, 2020
Злоумышленники внедрили SUNBURST в сборки Orion, которые SolarWinds распространяла штатным способом. До 18 000 клиентов могли скачать уязвимую версию, но сама компания позднее оценила число клиентов, реально взломанных через SUNBURST, менее чем в сто. Это видно в отчётности SolarWinds для SEC.
Что проверять: подпись файла подтверждает, кто его выпустил, но не подтверждает, что среда сборки была чистой. Для системного ПО нужны задержка обновления, поведенческий контроль после установки и возможность быстро остановить распространение версии.
2. Kaseya VSA, 2021
REvil использовала уязвимости в локальных серверах VSA и через механизм удалённого управления развернула шифровальщик у клиентов MSP. Kaseya сообщала о менее чем 60 непосредственно затронутых клиентах и не более 1500 компаниях ниже по цепочке. Требование $70 млн было требованием преступников за универсальный дешифратор, а не выплаченным выкупом. Масштаб и механику описал Национальный центр контрразведки и безопасности США.
Что проверять: RMM надо считать критичным поставщиком независимо от суммы договора. Он умеет выполнить одну команду сразу на сотнях машин.
3. NotPetya через M.E.Doc, 2017
Вредонос распространялся через механизм обновления украинского бухгалтерского ПО M.E.Doc, а затем двигался внутри сетей с украденными учётными данными и штатными средствами Windows. Обращения к серверу обновлений зафиксировал CERT-EU. Общий ущерб правительство США оценивало более чем в $10 млрд.
Что проверять: обязательность продукта не делает его безопаснее. Она увеличивает радиус поражения, поэтому нужны сегментация и восстановление, которое не зависит от доверия к домену Windows.
4. Codecov Bash Uploader, 2021
С 31 января по 1 апреля злоумышленник подменял Bash Uploader. Скрипт забирал из CI переменные окружения и сведения о репозиториях. Период и способ атаки описали Codecov и CISA. Точного публичного списка всех пострадавших компаний нет.
Что проверять: команда curl ... | bash в CI — удалённое исполнение кода по подписке. Фиксируйте версию и хеш, а секреты выдавайте задаче на короткий срок.
5. Log4Shell, 2021
Log4Shell — не взлом через подрядчика и не компрометация проекта Apache. Это уязвимость удалённого выполнения кода в Log4j версий от 2.0-beta9 до 2.14.1. Она стала риском цепочки поставок потому, что библиотека лежала внутри огромного числа продуктов, а их владельцы часто не знали о зависимости. Техническую механику и границы версий зафиксировала CISA.
Что проверять: SBOM нужен не для красивого отчёта, а для ответа на вопрос «в каких наших сборках есть эта библиотека и какая именно версия».
6. 3CX DesktopApp, 2023
Официальный клиент 3CX был троянизирован и распространялся через штатные каналы. По данным Microsoft, атакующие сначала скомпрометировали американскую финтех-компанию, а затем через неё добрались до среды 3CX. Цифра 600 000 организаций описывает клиентскую базу, а не число доказанно заражённых компаний. Цепочку приводит Microsoft Digital Defense Report.
Что проверять: поставщик вашего продукта тоже покупает код, инструменты сборки и услуги. Для критичного ПО надо знать хотя бы его критические четвёртые стороны.
Поддержка, облака и идентификация
7. Okta через Sitel, 2022
Атакующий получил RDP-доступ к компьютеру инженера Sitel, обслуживавшего Okta. Сначала максимально возможный охват оценили в 366 клиентов, но после анализа журналов Okta сообщила, что затронуты два. Разбор Okta хорошо показывает разницу между «мог получить доступ» и «действительно получил данные».
Что проверять: поддержка провайдера идентификации должна работать с отдельного управляемого рабочего места, под персональной учётной записью и с записью административных действий.
8. MOVEit Transfer, 2023
Cl0p массово использовала SQL-инъекцию в MOVEit Transfer. Это был не взлом Progress как поставщика, а эксплуатация уязвимых установок его продукта. Progress прямо писала в отчётности для инвесторов, что не видит все локальные установки и потому не может сама назвать полный масштаб.
Что проверять: для файлового шлюза важны не цена лицензии и анкета вендора, а внешний периметр, срок хранения файлов, журнал скачиваний и возможность аварийно отключить веб-доступ.
9. Snowflake, 2024
В корпоративную среду Snowflake злоумышленники не проникали. Они входили в клиентские экземпляры по логинам, ранее украденным инфостилерами; MFA на затронутых учётных записях не было, некоторые пароли не менялись годами. Mandiant и Snowflake уведомили примерно 165 потенциально затронутых организаций. В нескольких расследованиях исходное заражение произошло на компьютерах подрядчиков, которые использовались ещё и для игр или пиратского ПО. Всё это описано в отчёте Mandiant.
Что проверять: SaaS не отменяет ответственность заказчика за MFA, сетевые ограничения, срок жизни учётной записи и управляемое устройство подрядчика.
10. LastPass, 2022–2023
После первого инцидента атакующий добрался до домашнего компьютера DevOps-инженера LastPass через уязвимое стороннее приложение, установил клавиатурный перехватчик и получил доступ к облачной среде хранения резервных копий. Среди украденного были резервные копии данных клиентских хранилищ. Механику LastPass изложила в материалах об инциденте.
Это не «домашний компьютер сотрудника подрядчика заказчика». Инженер работал у самого LastPass. Но для клиента разница невелика: его секреты зависели от защиты рабочего процесса поставщика паролей и от стороннего ПО на одном компьютере.
Что проверять: критичные операции нельзя выполнять с обычного домашнего компьютера. Нужны отдельное управляемое устройство, изоляция секретов и независимое подтверждение доступа к резервным копиям.
11. Microsoft через SolarWinds, 2020–2021
Microsoft обнаружила вредоносные компоненты SolarWinds в своей среде, а затем установила, что одна внутренняя учётная запись использовалась для просмотра исходного кода в нескольких репозиториях. Прав на изменение кода у неё не было; доступа к продуктивным сервисам и клиентским данным компания не нашла. Это официальный вывод Microsoft.
Этот пункт нельзя выдавать за отдельную атаку Nobelium через нового подрядчика. Это один из результатов кампании SolarWinds из пункта № 1. Я оставил его в расширенной карте, потому что он показывает: один инцидент поставщика даёт разный ущерб у разных заказчиков.
Подрядчики и инженерный доступ
12. Target через HVAC-подрядчика, 2013
Злоумышленники получили данные Fazio Mechanical Services, подрядчика по отоплению и вентиляции, вошли во внешнюю часть сети Target и добрались до платёжной среды. Было похищено около 40 млн записей платёжных карт, а ещё до 70 млн записей содержали контактные данные. Связь с HVAC-подрядчиком зафиксирована в отчёте Счётной палаты США.
Что проверять: компания по вентиляции становится поставщиком Tier 1 в тот момент, когда получает сетевой доступ. Отрасль подрядчика не определяет риск. Права определяют.
13. Lifting Zmiy и контроллеры лифтов, 2024
Исследователи Solar 4RAYS описали атаки, в которых взломанные промышленные контроллеры, используемые в системах диспетчеризации лифтов, становились узлами инфраструктуры злоумышленников. Через них скрывали источник дальнейших подключений и атаковали российские организации. Сводка и доля группировки в расследованных инцидентах есть в отчёте Solar 4RAYS.
Здесь нельзя утверждать, что подрядчик по лифтам имел доверенный VPN и через него вошёл в сеть каждого пострадавшего. Публичные данные говорят о взломанных контроллерах как об инфраструктуре атак.
Что проверять: всё инженерное оборудование с выходом в интернет должно иметь владельца, инвентарный номер, изменённый пароль, понятный канал обновлений и журнал соединений.
14. Интегратор, старый доступ и маскировка под 1С, 2025
В расследовании Solar 4RAYS злоумышленники вошли в инфраструктуру небольшой организации по RDP под учётной записью крупного подрядчика-интегратора. Затем разместили вредонос в каталоге C:\ProgramData\1C\1cv8 и создали службу с правдоподобным названием 1cv8 License Service. За две недели инфраструктура была зашифрована. Исследователи нашли сведения о более ранней утечке у подрядчика, в которой могли оказаться клиентские доступы, но не смогли подтвердить, оставался ли сам подрядчик скомпрометирован. Подробности есть в разборе Solar 4RAYS.
Это не доказанная массовая атака через «1С-франчайзи» и не уязвимость 1С. Продукт использовали как камуфляж, потому что файл в каталоге 1С меньше привлекает внимание администратора.
Что проверять: доступ интегратора должен иметь срок окончания, MFA, ограничение адресов и владельца внутри заказчика. Название службы доказательством легитимности не является.
15. «Ростелеком» и подрядчик интернет-ресурсов, 2025
После публикации базы, которую связали с корпоративным сайтом и сайтом закупок «Ростелекома», компания сообщила, что ранее фиксировала инциденты у подрядчика, обслуживавшего эти ресурсы, и назвала его инфраструктуру наиболее вероятным источником утечки. Заявленные 154 000 адресов электронной почты и 101 000 телефонных номеров на тот момент ещё проверялись. Комментарий компании передал «Интерфакс».
Что проверять: подрядчик сайта может хранить формы, резервные копии и доступы к продуктивной среде. В договоре нужны границы копирования, срок хранения резервных копий и подтверждённое удаление после завершения работ.
OAuth, npm и репозитории
16. Salesloft Drift и Salesforce, 2025
Атакующие использовали скомпрометированные OAuth-токены интеграции Salesloft Drift и выгружали данные из связанных экземпляров Salesforce, попутно выискивая в CRM новые секреты. Один из пострадавших, Cloudflare, опубликовал собственное расследование.
Что проверять: connected app — это учётная запись без человека, который заметит странный вход. Нужны реестр OAuth-приложений, минимальные scopes, владелец и процедура массового отзыва токенов.
17. Shai-Hulud в npm, 2025
В сентябре самораспространяющийся вредонос похищал токены сопровождающих и публиковал заражённые версии следующих пакетов. Исследователи насчитали около 500 пакетов в первой волне; более тысячи относятся уже к следующей волне ноября. Поэтому фраза «в сентябре заразили 1000+ пакетов» смешивает эпизоды. Технику первой волны описал Socket.
Что проверять: SBOM не мешает украденному токену выпустить новую версию. Нужны trusted publishing, MFA без SMS, lock-файл и задержка между публикацией пакета и попаданием в производство.
18. Red Hat Cloud Services npm, 2026
29 мая 2026 года скомпрометированная через вредоносное расширение VS Code учётная запись GitHub внесла код в 32 пакета @redhat-cloud-services. Вредонос собирал токены и облачные секреты. Red Hat установила, что заражённые версии не попали в сборки продуктов, управляемые облачные сервисы не пострадали и клиентам не требовалось действий. Это указано в бюллетене Red Hat.
Что проверять: громкое имя пространства npm не доказывает ни заражение вашего проекта, ни попадание пакета в продукт. Проверяйте точную версию по lock-файлу и путь артефакта до сборки.
19. Trellix, 2026
Trellix обнаружила несанкционированный доступ к части репозитория исходного кода. После завершения расследования компания сообщила, что не нашла воздействия на выпуск и распространение кода, эксплуатации исходников или успешной несанкционированной активности после 18 апреля 2026 года. Это сказано в заявлении Trellix.
Публичного подтверждения, что вход произошёл через TeamPCP или конкретного подрядчика, компания не дала. Поэтому Trellix здесь — пример взлома поставщика средств защиты, но не доказанная атака на его клиентов через цепочку поставок.
Что проверять: при инциденте у защитного вендора нужны точные ответы: изменялся ли исходный код, затронута ли сборка, выпускались ли обновления из скомпрометированной среды и какие версии надо проверить.
Когда ломается не вход, а сама цепочка
20. Jaguar Land Rover, 2025
Кибератака остановила производство JLR и ударила по широкой сети поставщиков. Британское правительство поддержало коммерческий кредит гарантией до £1,5 млрд именно для стабилизации цепочки; в ней работали около 120 000 человек. Эти цифры приводит правительство Великобритании, а остановку и поэтапное восстановление подтверждала сама JLR.
В публичных официальных материалах нет доказательства, что злоумышленники вошли через ПО подрядчика. JLR важна по другой причине: атака на крупного заказчика остановила поставщиков ниже по цепочке.
Что проверять: VRM должен учитывать не только вероятность утечки у поставщика, но и вашу способность работать, если центральный заказчик, дистрибьютор или производитель перестанет принимать электронные заказы.
21. Marks & Spencer, 2025
Британское правительство позднее сообщило, что атака началась с социальной инженерии против стороннего MSP. M&S отключила складские системы и приостановила интернет-заказы. Формулировка о MSP есть в стенограмме парламента, последствия — в полугодовом отчёте M&S.
Публичные заявления про DragonForce и атаку на ESXi в официальных материалах компании не подтверждены, поэтому строить на них контроль нельзя.
Что проверять: сброс привилегированной учётной записи по телефону требует независимого подтверждения и уведомления владельца доступа по другому каналу.
22. UNFI, 2025
United Natural Foods обнаружила несанкционированную активность в своих ИТ-системах и отключила часть из них. Это временно нарушило исполнение и распределение заказов. Компания прямо описала последствия в форме 8-K для SEC, а позже оценила влияние на скорректированную EBITDA 2025 года примерно в $50 млн.
Путь первоначального входа UNFI публично не раскрыла. Это не атака «через поставщика». Это атака на дистрибьютора, после которой физическая цепочка поставок перестала получать нормальные электронные команды.
Что проверять: для критичного дистрибьютора нужен резервный способ заказа, подтверждения остатков и отгрузки. Киберустойчивость иногда выглядит как телефон, таблица и заранее согласованный лимит ручных операций.
А что там было с T-Mobile и кусачками
Не подрядчик пришёл с кусачками отключать T-Mobile. Было наоборот.
В ноябре 2024 года T-Mobile обнаружила попытку проникновения из сети другого оператора, соединённой с её инфраструктурой. Компания быстро разорвала связь и сообщила, что атакующие не получили доступ к звонкам, сообщениям и другим конфиденциальным данным клиентов. Это есть в заявлении T-Mobile.
Позднее стало известно, что директор по информационной безопасности и ещё три сотрудника лично приехали в ЦОД и физически перерезали кабель к скомпрометированному устройству. Историю описал SecurityLab.
Это не двадцать третий успешный взлом и не история о вредном подрядчике. Это хороший пример последнего рубежа: если доверенное соединение стало дорогой для атакующего, команда должна иметь право его отключить. Иногда команда в межсетевом экране не срабатывает достаточно быстро. Тогда контроль выглядит как кусачки.
Пять механизмов, которые повторяются
1. Чужой код получает ваши права
SolarWinds, Kaseya, M.E.Doc, Codecov, 3CX и заражённые npm-пакеты работали потому, что организации уже доверяли продукту. Вредонос не взламывал дверь. Он приехал с разрешённым обновлением.
2. Учётная запись живёт дольше своего назначения
Target, Snowflake и атака через интегратора показывают одну вещь: пароль подрядчика часто переживает проект, компьютер и самого владельца. Нужны MFA, срок действия, ограничение адресов и автоматический отзыв.
3. Интеграция превращается в невидимого администратора
OAuth-приложение, CI-скрипт, RMM-агент и библиотека не сидят в штатном расписании, но читают данные и выполняют код. Реестр контрагентов без реестра технических связей всегда неполон.
4. Масштаб продукта путают с числом жертв
18 000 загрузивших Orion, 600 000 клиентов 3CX и миллионы пользователей библиотеки — это возможный охват, а не доказанное число взломанных организаций. Для решения нужны точная версия, журналы и путь до конкретной системы.
5. Атака на один узел останавливает соседей
JLR и UNFI показывают операционный риск. Даже если ваши данные не украли и в вашу сеть не входили, вы можете потерять производство, отгрузку или приём заказов из-за чужого инцидента.
Что проверить у себя
Начните не с анкеты на двести вопросов, а с шести выгрузок:
- внешние учётные записи в VPN, RDP, VDI, PAM и RMM;
- OAuth-приложения с доступом к CRM, почте, файлам и службе поддержки;
- сервисные токены CI/CD и владельцы каждого секрета;
- программы, которые обновляются автоматически с системными правами;
- критичные SaaS, дистрибьюторы и поставщики, без которых бизнес не проработает сутки;
- инженерные устройства с выходом в интернет и удалённым обслуживанием.
Для каждой строки нужны владелец внутри компании, срок доступа, класс данных, способ отключения и резервный процесс. Если отключение существует только в презентации, его не существует.
С чего начать программу VRM
Строгий список из 13 атак отвечает на вопрос: «Через кого к нам могут войти?» Расширенный список из 22 добавляет ещё три: «Что мы установили?», «От кого зависим?» и «Кто остановит наш бизнес, даже не входя в нашу сеть?»
Я подготовил практический гайд по запуску VRM за 90 дней: модель Tier 1/2/3, требования к договору, контроль четвёртых сторон, сценарий первых 24 часов, метрики и заполняемые шаблоны. Скачайте VRM-гайд в PDF и начните с реестра реальных доступов.