Классические C2-серверы на выделенных VPS с кастомными доменами - архаика. Серьёзно, если в 2026 году ваш имплант стучит на
185.x.x.x с self-signed сертификатом, можете сразу писать отчёт «нас поймали». Настоящий сдвиг - living off the cloud: C2-трафик маскируется под легитимные API-вызовы к Google Sheets, Microsoft Graph, Telegram и даже OpenAI Assistants API.По данным Picus Red Report 2026 (анализ более миллиона образцов малвари), 80% из топ-10 техник MITRE ATT&CK направлены на уклонение и закрепление. Атакующие паразитируют на инфраструктуре, которой доверяет ваш SOC. Когда C2-трафик - обычный POST к
sheets.googleapis.com, корреляционные правила SIEM бессильны. Они просто не знают, на что триггериться.Дальше - практический разбор для пентестеров и security-инженеров. Реальные кейсы (GRIDTIDE, Boggy Serpens, SesameOp), механика Microsoft Graph API C2, конкретные detection gaps и рабочие правила для blue team.
Почему облачный C2 сервер невидим для стандартного SOC-стека
Когда имплант шлёт beacon на IP185.x.x.x по порту 443 с self-signed сертификатом - палится мгновенно. Threat intelligence фиды содержат миллионы известных C2-адресов, репутационные движки помечают их за часы. Но что происходит, когда тот же beacon уходит на graph.microsoft.com или sheets.googleapis.com?NGFW видит TLS-соединение к IP из пула Microsoft или Google. Сертификат валидный, домен в allowlist - без него не работают Office 365 и G Suite. Заблокировать? Удачи объяснить бизнесу, почему почта не ходит.
Тысячи легитимных приложений одновременно обращаются к тем же API-эндпоинтам. C2-трафик - доли процента от общего объёма. Выделить его из потока без дополнительной аналитики не может ни один NGFW. IP-адреса Google и Microsoft никогда не попадут в блеклисты - атакующий использует ту же инфраструктуру, что и ваша бухгалтерия.
Даже при SSL-инспекции (если она включена для трафика к облачным сервисам, что бывает редко) содержимое API-вызовов выглядит как легитимные CRUD-операции с документами. Ничего подозрительного.
В терминологии MITRE ATT&CK это техника T1102 (Web Service) - использование легитимных веб-сервисов для канала управления. Пересекается с T1071 (Application Layer Protocol), поскольку трафик идёт поверх стандартных HTTP/HTTPS. Разница: T1071 - про использование прикладного протокола вообще, T1102 - про злоупотребление конкретными доверенными сервисами. Именно тут основной detection gap.
Реальные кейсы living off the cloud атак 2025-2026
Русскоязычные источники описывают облачный C2 фрагментарно: новость на 300 слов про CLOUD#REVERSER, краткий обзор APT31. Между тем англоязычные DFIR-отчёты содержат детальную механику, которую стоит разобрать.GRIDTIDE: Google Sheets как полноценная C2-платформа
Кейс, который лично меня впечатлил масштабом наглости. Кампания приписывается связанной с КНР кибершпионажной группировке, раскрыта Google Threat Intelligence Group совместно с Mandiant. Бэкдор GRIDTIDE применялся против телекомов и госорганизаций в десятках стран.GRIDTIDE написан на C - выполняет произвольные shell-команды, загружает и скачивает файлы. Канал управления - Google Sheets API. Таблица используется не как документ, а как полноценный коммуникационный канал. Обычная гугл таблица, в которой вместо квартального отчёта - команды для импланта.
Механика по Mandiant: при запуске имплант ждёт 16-байтовый криптоключ в отдельном файле на хосте. Этим ключом расшифровывается конфигурация Google Drive через AES-128-CBC. Конфигурация содержит service account, приватный ключ и Spreadsheet ID для доступа к конкретной таблице через API. При каждом запуске GRIDTIDE «чистит за собой» - удаляет первые 1000 строк методом
batchClear, чтобы предыдущие команды не мешали текущей сессии.Для закрепления - systemd-сервис по пути
/etc/systemd/system/xapt.service, бинарь в /usr/sbin/xapt. Имя выбрано для маскировки под легитимную утилиту Debian (кто полезет проверять, что такое xapt, когда в системе 200+ сервисов?). Дерево процессов при запуске:
Код:
/var/tmp/xapt
└── /bin/sh
└── sh -c id 2>&1
└── uid=0(root) gid=0(root) groups=0(root)Принципиальный момент: Google ликвидировала кампанию терминацией Cloud-проектов атакующих и отзывом доступа к Sheets API. Но до этого трафик GRIDTIDE был неотличим от легитимных обращений к Google Sheets. Google прямо указывает: это «is not the result of a security vulnerability in Google's products» - злоупотребление легитимной функциональностью API. Проблема не в уязвимости. Проблема в доверии.
Boggy Serpens: Telegram API, UDP и AI в малвари
Unit 42 описали эволюцию иранской группировки Boggy Serpens (MuddyWater), связанной с MOIS. За последний год группа перешла от «шумных» массовых кампаний к целенаправленным атакам с длительным закреплением.Критическое изменение в C2: Boggy Serpens использует стандартные HTTP-коды состояния, кастомный UDP-трафик и Telegram API для управления имплантами. Среди инструментов - MuddyC2Go (написан на Go) и кастомные импланты. По некоторым публикациям, группа также применяет бэкдор BlackBeard, хотя его точная атрибуция требует дополнительной верификации по первоисточникам Unit 42. Отдельно интересно: группа применяет AI-генерированный код в разработке малвари и использует trusted relationship compromise - компрометацию доверенных аккаунтов для обхода репутационных фильтров.
Четыре волны атак на одну энергетическую компанию Ближнего Востока за шесть месяцев (август 2025 - февраль 2026). Каждая волна - персонализированные луры для разных департаментов, от инженеров до бухгалтерии. Такой уровень детализации фишинговых документов указывает на предварительную компрометацию внутренней переписки жертвы. Ресурсы государственного уровня - тут без вариантов.
SesameOp: C2-трафик под видом работы с OpenAI
Согласно Picus Red Report 2026, бэкдор SesameOp маршрутизирует весь трафик через OpenAI Assistants API, маскируя C2-коммуникации под работу разработчика с AI-инструментами. Для файрвола это обращения кapi.openai.com - домену, который всё чаще попадает в корпоративные allowlist (попробуйте сейчас заблокировать OpenAI в компании, где каждый второй «повышает продуктивность с ChatGPT»). Та же тенденция у Storm-0501 - напрямую запрашивают AWS Secrets Manager через API, полностью обходя endpoint detection.APT28, APT31 и адаптация к локальным облакам
Living off the cloud атаки адаптируются к локальным рынкам. APT31 в кампаниях против российского ИТ-сектора использует как международные, так и российские облачные сервисы (включая платформы Яндекса) для C2 и экфильтрации. Загрузчик CloudyLoader и бэкдор CloudSorcerer применяют модифицированную реализацию RC4 для шифрования C2-сообщений. Экфильтрация идёт через утилиты на .NET и облачные хранилища.Кампания CLOUD#REVERSER (описана Securonix) - классический паттерн cloud dead drop: VBScript и PowerShell используют Google Drive и Dropbox для обмена файлами, закрепление через задачу планировщика Windows, замаскированную под обновление Chrome, с интервалом в 60 секунд.
Microsoft Graph API C2: механика для Red Team adversary simulation
Microsoft Graph API - один из самых удобных каналов для облачного C2 в корпоративных средах. Причина банальна: практически каждая организация с Microsoft 365 имеет разрешённый трафик кgraph.microsoft.com. Блокировать его - всё равно что отключить почту.
Detection playbook: как ловить легитимные сервисы для C2
Сигнатурный подход тут бесполезен. Нужна комбинация поведенческого анализа и контекстных правил.Аномалии OAuth-токенов
Для Microsoft Graph API C2 имплант аутентифицируется не как пользователь, а как приложение через client credentials flow. Мониторинг Azure AD Sign-in Logs на предмет аутентификации service principal'ов с нехарактерных IP - первый рубеж. Стартовый KQL-запрос для Azure Sentinel:
Код:
AADServicePrincipalSignInLogs
| where ResultType == 0
| where not(ipv4_is_in_any_range(IPAddress, dynamic(['10.0.0.0/8','172.16.0.0/12','192.168.0.0/16'])))
| summarize count() by AppId, AppDisplayName, IPAddress
| where count_ > 10AppId и ServicePrincipalName известных приложений - тогда шум станет терпимым.Паттерны beaconing
Даже с jitter облачный C2 генерирует периодичные обращения. Ключевая метрика - распределение интервалов между запросами к одному API-эндпоинту. Для GRIDTIDE-подобных имплантов аномалия - регулярный вызовbatchClear. Легитимные пользователи крайне редко программно очищают 1000 строк Google Sheets. Если видите такой паттерн - копайте глубже.Корреляция endpoint и network
Самый рабочий подход - соединение данных EDR и сетевых логов. Если процесс, запущенный не из стандартного расположения (или запущенный через injection), устанавливает регулярные HTTPS-соединения к облачным API - это высокоприоритетный алерт. На одном проекте мы именно так поймали имплант:svchost.exe из C:\Users\Public регулярно ходил в Graph API. Настоящий svchost так не делает.MITRE ATT&CK маппинг облачной инфраструктуры APT
| Техника | Тактика | Применение в Cloud C2 |
|---|---|---|
| T1102 Web Service | Command and Control | Google Sheets, OneDrive, Telegram API как C2-каналы |
| T1071 Application Layer Protocol | Command and Control | C2 поверх HTTPS к облачным API |
| T1055 Process Injection | Defense Evasion, Privilege Escalation | Внедрение в легитимный процесс для маскировки обращений к cloud API |
| T1036 Masquerading | Defense Evasion | GRIDTIDE - под xapt, CLOUD#REVERSER - под обновление Chrome |
| T1547 Boot or Logon Autostart Execution | Persistence, Privilege Escalation | systemd-сервис (GRIDTIDE), scheduled task (CLOUD#REVERSER) |
| T1562 Impair Defenses | Defense Evasion | Исключения в брандмауэре, очистка логов |
Отдельная история - взрывной рост техники Virtualization/Sandbox Evasion (T1497) в 2026 году. По данным Picus, современная вредоносная программа анализирует движения мыши - LummaC2 вычисляет евклидово расстояние и углы перемещений курсора. Если траектория линейна (типично для sandbox), имплант не активируется. Это напрямую бьёт по детекции облачного C2: имплант молчит в sandbox-среде и активирует канал только на реальном хосте. Динамический анализ становится бесполезным.
Вопрос к читателям
В detection playbook выше мы использовали KQL-запрос кAADServicePrincipalSignInLogs для выявления аномальных OAuth-аутентификаций с нехарактерных IP. Но в средах с гибридным Azure AD и десятками интеграций (50+ зарегистрированных enterprise-приложений) этот подход генерирует ощутимый шум.У кого в продакшне работает детекция Cloud C2 beaconing через Microsoft Graph API - каким фильтром вы отсекаете false positives: по whitelist
AppId, по ResourceDisplayName, или через корреляцию с EDR-телеметрией процесса, инициировавшего токен-запрос? Покажите фрагмент вашего KQL или Sigma-правила с конкретными полями фильтрации.
Последнее редактирование модератором:
