Что делать, если взломали вашего подрядчика: чек-лист по первым шагам

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

Согласно публичным отчетам, доля инцидентов с использованием доступов подрядчиков стабильно растет (с 6% в 2024 году до 24% в 2025-м, по данным Solar 4RAYS). Риск серьезных последствий увеличивается из-за широты доверительных связей: от утечки данных и шпионажа до шифрования инфраструктуры с целью вымогательства или ее полного уничтожения. Проблема усугубляется тем, что о компрометации партнера часто узнают из СМИ, профессиональных сообществ или публичных заявлений злоумышленников, когда атакующие уже успели закрепиться в системе. Почему взлом подрядчика так опасен и какие шаги помогут вовремя начать реагирование на инцидент, рассказываем в статье.

Как атакуют через подрядчика: техники по матрице MITRE ATT&CK

Атаки через подрядчиков — не случайные разовые инциденты, а отдельный класс угроз, описанный в матрице MITRE ATT&CK. В атаках через подрядчиков эксперты выделяют две основные техники:

Шаг 1: Определение скоупа и инвентаризация доступов подрядчика

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

• Доступ к активам. Какие серверы, сервисы, облачные ресурсы, сетевые устройства, базы данных и приложения обслуживает подрядчик, к каким системам и данным он имеет доступ. Если учет доступа к активам ведется корректно, оценка займет минуты. Если нет — реагирование на инцидент замедлится уже на старте, поскольку сначала придется провести инвентаризацию.
• Уровни доступа и привилегий. Сколько учетных записей подрядчика создано, включая сервисные. Какие роли и группы им назначены, к каким сегментам сети открыт доступ. При плоской или примитивной сегментации архитектуры масштаб потенциального воздействия резко увеличивается.
• Повышенную активность. Были ли подключения в последние недели в логах, фиксировались ли множественные попытки входа (брутфорс), входы в нерабочее время и с подозрительных GeoIP. Используются ли учетные записи регулярно или созданы «про запас». Если доступ давно не применялся, это снижает текущие риски.

Цель этого этапа — сузить зону проверки: определить потенциально затронутые сегменты, возможные точки компрометации данных и области архитектуры с повышенным риском.

Шаг 2: Анализ подключений и поиск аномалий

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

• Нетипичное время входа (например, ночные подключения).
• Входы из «неожиданных» стран и с IP-диапазоном, не предусмотренным договором.
• Резкие изменения поведения: попытки повысить привилегии, доступ к новым системам, обращения к контроллерам домена, резервным копиям или системам управления.

В одном из расследований аналитики обнаружили многочисленные попытки проникновения в системы с разных учетных записей подрядчика в ночное время. Последующая атрибуция показала связь атакующих с кластером азиатских группировок, нацеленных на шпионаж, — Obstinate Mogwai, IAmTheKing, Space Pirates и другими.

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

Шаг 3: Золотые правила и грубые ошибки реагирования

Главная задача на этом этапе — остановить угрозу и сохранить доказательства. При атаке через подрядчика вектор атаки может содержать множество следов: точки входа, учетные записи, выполненные команды, перемещения по сети, закладки в журналах или планировщике задач (!). Злоумышленники могут создавать скрытые задачи в планировщике, и атака может иметь отложенный эффект. Если начать «чистку» без фиксации состояния, восстановить картину событий будет невозможно, а реагирование на инцидент потеряет смысл. Типичные ошибки:

• Удаление доменных учетных записей и объектов. Корректное действие — блокировка, а не удаление. В ряде систем данные о сессиях и подключениях хранятся в привязке к объекту. Удалив его, можно безвозвратно потерять сведения о точке входа и маршруте атаки.
• Переустановка систем (re-imaging). Полная «перезаливка» сервера или VPN-шлюза уничтожает артефакты. В результате реагирование на инцидент превращается в проверку гипотез потому что неизвестно, где закрепился злоумышленник и через какой вектор атаки он может вернуться.
• Смена пароля как единственная мера. Если заражено рабочее место подрядчика или скомпрометированы токены, простая смена пароля не устраняет причину. Без расследования риск повторного инцидента сохраняется — вплоть до шифрования систем, утечки данных или длительного скрытого шпионажа.

Правильный подход: ограничить доступ, зафиксировать состояние систем, сохранить логи и образы (дампы), и только после этого переходить к очистке. Сохранение доказательств — основа грамотного реагирования на инцидент и анализа реального вектора атаки.

Шаг 4: Compromise Assessment — инструмент возврата доверия

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

Compromise Assessment — это метод анализа инфраструктуры, который проводит независимая команда по расследованию и реагированию на инциденты. Его задача — выявление следов компрометации, проверка гипотезы о присутствии злоумышленника и поиск возможных «закладок». В результате формируется технический отчет с выводами и рекомендациями. В экосистеме «Солара» этот подход реализован в сервисе Compromise Assessment («Выявление следов компрометации»).

Когда и кому Compromise Assessment особенно необходим:

• Подрядчику. Если произошел инцидент, независимый аудит помогает подтвердить заказчиками, что инфраструктура приведена в порядок. Это снижает риск разрыва контрактов и закрывает текущий вектор атаки.
• Заказчику. Техническое заключение дает основание для возобновления доступов и снижает вероятность повторной компрометации данных.
• На этапе подключения нового партнера. Проверка до выдачи привилегий позволяет заранее снизить риск появления нового вектора атаки в инфраструктуре.

Системная защита и юридическая «соломка»

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

Рекомендации по остановке атаки и ее предотвращению:

• Базовая кибергигиена. MFA, своевременные обновления, отдельные административные учетные записи и корректная парольная политика.
• PAM и контроль привилегированного доступа. Выдача прав по запросу, запись сессий, контроль действий подрядчиков и администраторов напрямую снижает риск утечки данных, шифрования инфраструктуры и несанкционированного доступа при компрометации учетных записей.
• Сегментация сети и принцип минимальных прав. Чем меньше доступов и сетевых пересечений, тем сложнее развить вектор атаки внутри инфраструктуры.
• Периодическая оценка защищенности. Пентесты, сканирование периметра на уязвимости, киберучения и проверка конфигураций позволяют выявлять слабые места до того, как ими воспользуются.
• SOC и мониторинг инцидентов. Постоянный анализ событий безопасности помогает быстрее обнаружить аномалии, локализовать инциденты и подкрепить расследование фактическими данными.
• Threat Intelligence (TI Feeds). Использование актуальных данных о доменах, IP и инструментах атак ускоряет блокировку известных индикаторов.
• Мониторинг DNS-трафика. Выявление и блокировка вредоносных доменов снижает вероятность скрытых каналов управления и развития инцидента.
• Compromise Assessment при подозрениях. Если есть признаки возможной компрометации данных, но нет полной картины, независимая проверка помогает устранить неопределенность.

Юридический стек (договор с подрядчиком)

Технические меры должны быть закреплены в контракте. Минимальный набор требований:

1. Обязанность уведомлять об инцидентах в обе стороны в установленные сроки.
2. Достаточный уровень ИБ подрядчика (MFA, защита рабочих мест, запрет хранения паролей в открытом виде).
3. Право заказчика на аудит и получение данных, необходимых для расследования.

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

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

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

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

Только сочетание многослойной технической защиты — от MFA и сегментации до SOC и регулярной проверки гипотез — вместе с юридически закрепленными обязательствами подрядчиков позволяет перевести этот вектор атаки из разряда «неприятного сюрприза» в категорию управляемых рисков.