13 взломов через подрядчиков: полный разбор атак и программа VRM

Карта 13 атак

Отравленные обновления и инструменты разработки

1. SolarWinds Orion, 2020

Злоумышленники внедрили SUNBURST в сборки Orion, которые SolarWinds выпускала с марта по июнь 2020 года. До 18 000 клиентов могли скачать уязвимые версии, однако сама SolarWinds позже оценила число клиентов, реально взломанных через SUNBURST, менее чем в 100. Число загрузивших обновление и число скомпрометированных организаций — не одно и то же. Это прямо сказано в отчётности SolarWinds для SEC.

Контроль VRM: для ПО с системными привилегиями нужны отдельный контур обновлений, проверка подписей, возможность задержать выпуск и телеметрия, которая обнаружит поведение продукта после установки. Подпись доказывает происхождение файла. Она не доказывает, что вендора не взломали.

2. Kaseya VSA, 2021

REvil использовала уязвимости в локальных серверах VSA и через механизм управления развернула шифровальщик на системах клиентов MSP. Kaseya сообщала о менее чем 60 непосредственно затронутых клиентах и не более 1500 компаний ниже по цепочке; требование $70 млн было публичным требованием преступников за универсальный дешифратор, а не выплаченным выкупом. Механику и масштаб зафиксировал Национальный центр контрразведки и безопасности США.

Контроль VRM: RMM-система — Tier 1 независимо от размера поставщика. Она умеет исполнять код сразу на сотнях машин, значит, для неё обязательны выделенные учётные записи, MFA, ограничение адресов, журнал команд и аварийное отключение агента.

3. NotPetya через M.E.Doc, 2017

Вредоносный код распространялся через механизм обновления украинского бухгалтерского ПО M.E.Doc, а затем двигался внутри сетей с украденными учётными данными и штатными средствами Windows. CERT-EU описал обращения к серверу обновлений M.E.Doc, а Минюст США указал, что только FedEx и крупный фармпроизводитель потратили на восстановление около $900 млн. В публичной оценке правительства США общий мировой ущерб превышал $10 млрд, но отдельные цифры компаний нельзя без проверки складывать с этой оценкой: наборы расходов пересекаются.

Контроль VRM: обязательность продукта не снижает риск, а увеличивает радиус поражения. Для такого ПО проверяют не только договор и сертификаты вендора, но и каналы обновления, сетевую сегментацию, права сервиса и способность восстановить инфраструктуру без доверия к домену Windows.

4. Codecov Bash Uploader, 2021

С 31 января по 1 апреля злоумышленник подменял Bash Uploader: скрипт забирал из CI переменные окружения и адреса репозиториев. Codecov не публиковала доказанный список «сотен пострадавших компаний», поэтому Twilio, HashiCorp и другие публично названные организации нельзя превращать в точный общий масштаб. Период и механику подтверждают посмертный разбор Codecov и предупреждение CISA.

Контроль VRM: команда вида curl ... | bash в сборочном контуре — удалённое исполнение кода по подписке. Фиксируйте версию и хеш, убирайте лишние секреты из окружения задачи, используйте короткоживущие токены и считайте CI-поставщика Tier 1.

5. 3CX DesktopApp, 2023

Официальный клиент 3CX был троянизирован и распространялся через штатные каналы. Особенно хороша матрёшка: по данным Microsoft, атакующие сначала использовали компрометацию американской финтех-компании, а затем добрались до 3CX. Цифра «600 000 организаций-клиентов» описывает клиентскую базу, а не доказанное число заражённых организаций. Цепочку подтверждает Microsoft Digital Defense Report.

Контроль VRM: спросите поставщика, какие сторонние компоненты и инструменты входят в его сборку и как он изолирует build-среду. Реестр ваших поставщиков без их критичных поставщиков заканчивается на один уровень раньше злоумышленника.

Поддержка, SaaS и облачные связи

6. Okta через Sitel, 2022

Атакующий получил RDP-доступ к компьютеру инженера Sitel, который обслуживал Okta. Максимально возможный охват Okta сначала оценила в 366 клиентов, но после анализа журналов сообщила, что затронуты два. Это отличный пример того, почему «мог получить доступ» нельзя сокращать до «взломал». Подробный разбор опубликовала сама Okta.

Контроль VRM: поддержка провайдера идентификации — Tier 1. Нужны отдельные рабочие станции, минимальные права, запись административных действий и обязанность подрядчика сообщать не только итог расследования, но и первичный сигнал в установленный срок.

7. MOVEit Transfer, 2023

Cl0p массово эксплуатировала SQL-инъекцию в MOVEit Transfer. Публичные счётчики жертв со временем дошли до тысяч организаций и десятков миллионов людей, но Progress не могла увидеть все локальные установки и в отчётности для инвесторов прямо объясняла это ограничение.

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

Подрядчики с доступом и инженерная инфраструктура

8. Target через HVAC-подрядчика, 2013

Злоумышленники получили учётные данные подрядчика по отоплению и вентиляции и вошли во внешнюю часть сети Target, после чего добрались до платёжной среды. Было похищено около 40 млн записей платёжных карт; ещё до 70 млн записей содержали контактные данные. Связь с HVAC-подрядчиком зафиксирована в отчёте Счётной палаты США.

Контроль VRM: категория договора ничего не говорит о киберриске. Если у компании по вентиляции есть удалённый доступ, она оценивается как поставщик доступа: MFA, сегментация, временное разрешение, журналирование и немедленное отключение после завершения работ.

9. «Ростелеком» через подрядчика, 2025

В январе 2025 года в сети появилась база, которую связали с корпоративным сайтом и сайтом закупок «Ростелекома». Компания сообщила, что ранее фиксировала инциденты у подрядчика, обслуживавшего эти ресурсы, и назвала его инфраструктуру наиболее вероятным источником утечки. Заявленные авторами публикации базы 154 000 уникальных адресов электронной почты и 101 000 телефонных номеров на момент комментария ещё проверялись. Ответ «Ростелекома» передал «Интерфакс».

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

OAuth, npm и цепочка средств защиты

10. Salesloft Drift и Salesforce, 2025

Атакующие использовали скомпрометированные OAuth-токены интеграции Salesloft Drift и выгружали данные из связанных экземпляров Salesforce, попутно искали в CRM новые секреты. Публично говорили о сотнях компаний, но не о «тысячах пострадавших». Один из пострадавших, Cloudflare, описал собственное расследование.

Контроль VRM: connected app — это такая же учётная запись, только без человека, который заметит странный вход. Ведите реестр OAuth-приложений, ограничивайте scopes, проверяйте владельца, срок жизни токена и процедуру массового отзыва.

11. Shai-Hulud в npm, 2025

В сентябре 2025 года самораспространяющийся вредонос похищал токены сопровождающих и публиковал заражённые версии следующих пакетов. Исследователи насчитали около 500 пакетов в первой волне; более тысячи относятся уже к следующей волне ноября. Поэтому фраза «в сентябре заразил 1000+ пакетов» смешивает разные эпизоды. Технику и счёт первой волны описал Socket.

Контроль VRM: SBOM отвечает на вопрос «что установлено», но не мешает украденному токену выпустить новую версию. Нужны MFA без SMS для сопровождающих, trusted publishing, запрет самовольного обновления lock-файла и задержка между публикацией пакета и попаданием в производство.

12. Red Hat Cloud Services npm, 2026

29 мая 2026 года скомпрометированная через вредоносное расширение VS Code учётная запись GitHub внесла код в 32 пакета @redhat-cloud-services. Вредонос собирал токены и облачные секреты. Но Red Hat установила, что заражённые версии не попали ни в одну сборку продукта, управляемые облачные сервисы не пострадали и клиентам не требовалось действий. Всё это есть в официальном бюллетене Red Hat.

Контроль VRM: громкое имя пространства npm не доказывает попадание кода в продукт. Проверяйте точную версию по lock-файлу и путь артефакта до вашей сборки. Паника без трассировки зависимости так же бесполезна, как спокойствие без неё.

Ритейл и управляемые сервисы

13. Marks & Spencer, 2025

Британское правительство позднее сообщило, что атака началась с социальной инженерии против стороннего MSP. M&S отключила складские системы, приостановила интернет-заказы и понесла сотни миллионов фунтов влияния на прибыль и восстановление. Формулировку о MSP фиксирует стенограмма парламента, последствия — полугодовой отчёт M&S. Утверждения про DragonForce и ESXi в официальных материалах компании не подтверждены, поэтому я их не использую.

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

Что действительно повторяется

В этих атаках повторяются пять устойчивых механизмов:

1. Доверенный код приезжает сам. SolarWinds, Kaseya, M.E.Doc, 3CX и npm показывают, что штатное обновление может честно пройти все ваши разрешения и принести чужую команду.
2. Учётная запись подрядчика открывает ваши системы. В атаках на Target, Okta и M&S злоумышленники сначала скомпрометировали подрядчика, а затем использовали его доступ к системам заказчика.
3. Секрет живёт дольше своего владельца. Codecov и Salesloft превращали переменные CI и OAuth-токены в переход между организациями.
4. Критичность определяет доступ, а не цена договора. Скромная поддержка, чат-бот или HVAC-компания могут стоить в реестре выше дорогого консультанта без доступа к системам.
5. Цепочка длиннее договора. Kaseya и 3CX показывают, что между вами и поставщиком может находиться ещё одна компания, которой нет в вашем реестре, но есть место в маршруте атаки.

Масштаб проблемы подтверждают не только эти истории. В Verizon DBIR 2025 участие третьих сторон обнаружено в 30% расследованных утечек — вдвое чаще, чем годом ранее. УЦСБ SOC сообщает, что не менее 30% подтверждённых атак на российские организации в 2025 году шли через компрометацию ИТ-подрядчиков. А Yandex Cloud в первом полугодии 2025 года увидел действительные учётные записи в 54% разобранных атак. Эти выборки и определения разные, складывать проценты нельзя. Но направление у них одно.

Почему анкета поставщика не спасает

Анкета спрашивает, есть ли у поставщика политика управления доступом. Атакующий спрашивает другое: есть ли живой VPN-профиль, можно ли сбросить MFA звонком, какой OAuth-токен никто не отзовёт и умеет ли агент RMM выполнить команду сразу на тысяче машин.

Оба вопроса нужны, но отвечают они на разные задачи. Анкета показывает заявленные процессы. Техническая инвентаризация показывает путь атаки.

Начните не с двухсот вопросов, а с шести выгрузок:

1. внешние VPN-, RDP- и VDI-подключения;
2. учётные записи подрядчиков в AD, PAM и облачных консолях;
3. RMM-, EDR-, резервные и другие агенты с правом исполнять код;
4. OAuth-приложения и сервисные учётные записи SaaS;
5. токены и секреты в CI/CD;
6. продукты, которые обновляются автоматически и работают с системными правами.

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

Как разделить поставщиков на Tier 1, Tier 2 и Tier 3

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

Маленькая компания по вентиляции с VPN может оказаться Tier 1. Большая консалтинговая компания, которой вы отдали только обезличенный файл, — Tier 2. Цена договора тут почти бесполезна.

Пересматривать уровень надо после изменения доступа, а не раз в год по календарю. Подключили интеграцию к CRM — поставщик поднялся. Выдали RMM-агент — поднялся ещё раз. Отозвали доступ и удалили данные — можно пересмотреть обратно.

Что требовать от удалённого доступа

Доступ подрядчика не должен выглядеть как ещё одна пожизненная учётная запись сотрудника. Нормальная схема содержит семь элементов:

• Отдельная личная учётная запись. Общий логин contractor-admin уничтожает расследование: команда была, человека нет.
• MFA без сброса по одному телефонному звонку. Иначе второй фактор заканчивается на убедительном собеседнике.
• Доступ по запросу и на срок. Постоянный VPN удобен ровно до первого украденного пароля.
• Ограничение точки входа. Выделенный шлюз, известные адреса, управляемая рабочая станция или VDI уменьшают число неизвестных устройств.
• Минимальные права и сегментация. Подрядчику по вентиляции не нужна дорога к платёжной среде, даже если так проще настроить маршрутизацию.
• Запись административных действий. Для Tier 1 нужны команды, сессии и изменение ролей, а не только запись «пользователь вошёл».
• Одна проверенная кнопка отключения. Во время инцидента некогда выяснять, кто умеет отозвать токен или удалить агент.

Последний пункт стоит проверить руками. Отключите тестовую учётную запись, отзовите токен, остановите агент и убедитесь, что доступ действительно исчез, а не остался в другой консоли.

Четвёртые стороны: поставщики вашего поставщика

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

Требовать полный список всех субподрядчиков бессмысленно: получится каталог на сотни строк, который никто не обновляет. Нужны только те четвёртые стороны, которые могут:

• получить ваши данные;
• выпускать код или обновления, которые попадут к вам;
• администрировать сервис;
• влиять на восстановление и непрерывность;
• сообщать об инциденте раньше основного поставщика.

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

Что записать в договоре

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

1. перечень разрешённых способов доступа и классов обрабатываемых данных;
2. запрет передавать доступ субподрядчику без согласованной процедуры;
3. конкретный срок первичного сообщения об инциденте — число часов, а не «без неоправданной задержки»;
4. минимальный состав первого сообщения: время, затронутый сервис, известный вектор, данные и уже принятые меры;
5. обязанность сохранить журналы и предоставить их в согласованном формате;
6. порядок отзыва доступов, возврата и подтверждённого удаления копий данных после завершения работ;
7. участие в учениях и право проверить выполнение технических условий для Tier 1.

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

Первые 24 часа инцидента у поставщика

План нужен до звонка поставщика. Иначе первые часы уйдут на выяснение, кто владелец договора и где лежит список интеграций.

Первые 60 минут

• назначить руководителя разбора со стороны заказчика;
• зафиксировать время и содержание первого сигнала;
• найти владельца сервиса, владельца данных и контакт поставщика для инцидентов;
• отключить или ограничить известный путь: VPN, OAuth, RMM, API-ключ, канал обновления;
• сохранить собственные журналы до того, как сработает ротация.

От одного до четырёх часов

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

От четырёх до восьми часов

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

До конца первых суток

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

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

Метрики, которые показывают реальный VRM

Количество заполненных анкет измеряет работу с анкетами. Риск лучше показывают другие числа:

• доля Tier 1 с назначенным владельцем внутри компании;
• доля внешних привилегированных доступов с MFA и сроком окончания;
• число учётных записей подрядчиков без использования за 90 дней;
• доля OAuth-приложений и сервисных токенов с известным владельцем;
• время от решения об отключении до фактического прекращения доступа;
• доля Tier 1, для которых за последний год проверили первые 24 часа инцидента;
• число критичных четвёртых сторон, о которых компания узнала только во время аварии.

Хорошая метрика приводит к действию. Если владелец не знает, что делать с числом, перед вами украшение отчёта.

Пять ошибок при запуске VRM

1. Начать со всех поставщиков сразу. Сначала найдите тех, кто исполняет код, управляет идентификацией, хранит критичные данные и влияет на остановку бизнеса.
2. Считать сертификат доказательством безопасности конкретного доступа. Сертификат не покажет общий VPN-логин и токен без владельца.
3. Оставить VRM только закупкам или только ИБ. Закупки знают договор, ИБ — доступ, бизнес — последствия остановки. Без одного из трёх реестр неполон.
4. Проверить поставщика один раз. Риск меняется при каждой новой интеграции, роли, площадке обработки и четвёртой стороне.
5. Не репетировать отключение. План, который впервые исполняют во время атаки, — это гипотеза.

Десять вопросов для проверки сегодня

• Кто из внешних организаций может исполнять код или ставить обновления без отдельного согласования?
• У кого есть VPN, RDP, VDI или RMM и когда этим доступом пользовались последний раз?
• Какие внешние администраторы работают под общими учётными записями?
• Какие OAuth-приложения читают CRM, почту, файлы и службу поддержки?
• Какие токены SaaS и CI/CD переживут увольнение сотрудника или смену подрядчика?
• Какие продукты обновляются автоматически с системными правами?
• Какие критичные субподрядчики поставщиков могут получить ваши данные или код?
• Кто внутри компании вправе аварийно отключить каждый доступ Tier 1?
• Через сколько часов поставщик обязан сообщить первичный сигнал об инциденте?
• Как бизнес проработает сутки без портала, API, электронного заказа или автоматического платежа этому поставщику?

Если ответы приходится собирать по перепискам, это не катастрофа. Это первая измеримая задача программы: собрать реестр, назначить владельцев и проверить отключение.

Частые вопросы

С чего начать

Начните с одного дня и одного класса риска. Выгрузите внешние привилегированные учётные записи, найдите владельцев и попробуйте отключить одну тестовую запись. На следующий день разберите OAuth. Потом RMM и автоматические обновления.

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

Я подготовил практический гайд по запуску VRM за 90 дней: модель Tier 1/2/3, требования к договору, контроль четвёртых сторон, сценарий первых 24 часов, метрики и заполняемые шаблоны. Скачайте VRM-гайд в PDF и начните с реестра поставщиков.