Статья Детектирование APT через облачные C2-каналы: Sigma и YARA правила для Google Sheets, OneDrive и Slack

По данным CrowdStrike Global Threat Report 2025, число облачных вторжений выросло на 26% за год, а 79% атак обходятся без вредоносного ПО - атакующие используют легитимные сервисы и встроенные инструменты. На практике это выглядит так: в одном из кейсов прошлого года C2-трафик APT-кампании целиком шёл через Google Sheets API - стандартные IOC-правила в Splunk не выдали ни одного алерта за три недели. Домен sheets.googleapis.com стоял в allow-листе прокси, TLS-сертификат валидный, порт 443. Для SIEM это была обычная рабочая активность.

И вот тут проблема: детектирование APT через облачные C2-каналы не работает по репутационной модели. Тут нужен поведенческий подход - смотреть не куда идёт трафик, а кто и как его генерирует. Ниже - готовые Sigma и YARA правила, маппинг на MITRE ATT&CK и playbook для security engineer'а, которому нужно задеплоить детектирующую логику завтра.

Почему IOC-блоклисты бессильны против cloud C2​

Классическая модель детектирования C2 строится на репутации: IP-адреса, домены, хэши попадают в фиды threat intelligence и блокируются на firewall или прокси. Против выделенной C2-инфраструктуры - работает. Против легитимного облачного сервиса - ломается полностью.

Концепция LOTS - Living Off Trusted Sites - это перенос философии LOTL (Living Off The Land) на сетевой уровень. LOTL - использование встроенных утилит ОС (PowerShell, certutil). LOTS - маскировка на уровне трафика: command and control через легитимные сервисы идёт к доменам, которым доверяет каждый прокси, каждый DLP и каждый аналитик SOC. Домен в allow-листе, сертификат валидный - какие претензии?

В терминах MITRE ATT&CK облачный C2 - это техника T1102 (Web Service) с двумя подтипами:

• Dead Drop Resolver (T1102.001): имплант читает команды из публично доступного ресурса - Google Sheets, Pastebin, публичного S3-бакета. Трафик однонаправленный: только GET. Оператор обновляет содержимое через отдельный канал.
• Bidirectional Communication (T1102.002): имплант и получает команды, и отправляет результаты через один сервис - OneDrive через Graph API, Slack через Bot API. GET и POST/PUT в обе стороны.

На практике облачный C2 почти всегда идёт в связке с другими техниками:

• Web Protocols (T1071.001): весь обмен по HTTPS, смешивается с легитимным трафиком
• Asymmetric Cryptography (T1573.002): payload зашифрован внутри уже зашифрованного TLS-канала (матрёшка)
• Exfiltration Over C2 Channel (T1041): эксфильтрация данных через тот же облачный канал

Вот почему стандартный detection engineering не может опираться только на IOC. По данным Mandiant M-Trends 2025, медианное время нахождения злоумышленника в сети - 11 дней, а 57% организаций узнают об инциденте от внешней стороны. Если ваш SIEM видит HTTPS-соединение к graph.microsoft.com от svchost.exe и молчит - вы попадаете в эти 57%.

Анатомия облачных C2-каналов: как APT используют Google Sheets, OneDrive и Slack​

Google Sheets C2 канал - Dead Drop Resolver через публичный API​

Google Sheets API (sheets.googleapis.com/v4/spreadsheets/) позволяет читать и записывать данные в таблицы по HTTP. Для чтения публичной таблицы авторизация не нужна - достаточно знать ID документа. Готовый C2-эндпоинт без инфраструктуры.

Типичная цепочка C2 через Google Sheets (T1102.001):

1. Оператор создаёт Google-таблицу с публичным доступом на чтение, размещает закодированные команды в ячейках
2. Имплант на скомпрометированном хосте периодически делает GET к sheets.googleapis.com/v4/spreadsheets/{ID}/values/{range}
3. Парсит JSON-ответ, декодирует команду из значения ячейки, выполняет
4. Результат записывается в другую ячейку (если у импланта есть OAuth-токен) или уходит через альтернативный канал

Для detection engineer'а ключевой вопрос - какой процесс лезет в Sheets API. Браузеры (chrome.exe, firefox.exe, msedge.exe) и процессы Google Drive (googledrivesync.exe) - ожидаемые источники. Любой другой процесс - повод копнуть глубже.

Ограничение: если имплант внедряется в процесс браузера через process injection, этот детект не сработает. Тогда нужен анализ частоты обращений - C2-beacon стучит с фиксированным интервалом (jitter +/- 10-20%), а пользовательская активность хаотична.

OneDrive C2 malware - двунаправленный канал через Graph API​

Microsoft Graph API (graph.microsoft.com) - единая точка входа для всех сервисов Microsoft 365. Для detection engineering это самый тяжёлый облачный C2 канал: Graph API используют десятки легитимных приложений - Teams, Outlook, OneDrive for Business, SharePoint. Отличить вредоносный запрос от легитимного на уровне DNS - практически нереально.

Паттерн C2 через OneDrive (T1102.002, Bidirectional Communication):

1. Имплант авторизуется через OAuth2 с заранее зарегистрированным Azure App Registration или украденным refresh-токеном
2. Читает файл-команду: GET /me/drive/root:/c2_folder/cmd.txt:/content
3. Выполняет команду, записывает результат: PUT /me/drive/root:/c2_folder/result.txt:/content
4. Эксфильтрация - через ту же OneDrive-папку (T1567.002, Exfiltration to Cloud Storage)

Это не теоретическая угроза. Microsoft и Mandiant фиксировали использование Graph API группировкой APT29 (Midnight Blizzard) для управления и эксфильтрации (T1041). Массовая практика, а не экзотика.

Ключевые признаки вредоносного использования Graph API: обращения к endpoint'ам /drive/ из процессов, не связанных с Microsoft Office или OneDrive Sync; OAuth-токены с разрешениями Files.ReadWrite.All у неизвестных приложений; регулярные интервалы запросов (beacon-паттерн).

Slack C2 канал APT - webhook и Bot API​

Slack даёт два механизма, пригодных для C2:

• Incoming Webhooks (hooks.slack.com/services/T.../B.../...): POST-запрос отправляет сообщение в канал. Один HTTP-вызов, никакой авторизации кроме знания URL. По сути - готовый C2-эндпоинт, который можно получить за 30 секунд.
• Bot API (api.slack.com/): полноценный двунаправленный доступ - чтение и отправка сообщений с авторизацией по токену.

Согласно документации MITRE ATT&CK T1567.002 и отчётам Mandiant, Discord и Slack webhooks активно используются APT-группами для C2 и data exfiltration.

Ключевой сигнал для обнаружения скрытых каналов управления: строка hooks.slack.com или api.slack.com в адресном пространстве процесса, который не является официальным клиентом Slack. Грубый индикатор, но рабочий.

Ограничение: некоторые легитимные инструменты (CI/CD пайплайны, мониторинг) используют Slack webhooks для нотификаций. Чтобы не утонуть в false positive, нужен baseline легитимных интеграций в конкретной среде. Без него - будете разгребать алерты от Jenkins и Grafana.

Sigma rules APT: детектирование обращений к облачным C2-каналам​

Требования к окружению​

• Телеметрия: Sysmon с конфигурацией, включающей Event ID 22 (DNS Query), или EDR (CrowdStrike Falcon, Microsoft Defender for Endpoint) с логированием DNS-запросов и network connections
• SIEM: Splunk 8.x+, Elastic Security 8.11+, или Microsoft Sentinel с настроенным коннектором
• Sigma CLI: sigma-cli v1.x (репозиторий SigmaHQ/sigma-cli, ставится через pip install sigma-cli; основной репозиторий правил - SigmaHQ/sigma, 8000+ звёзд на GitHub)
• Proxy/NGFW (опционально): Zscaler, Palo Alto с User-ID - для привязки URL к source-процессу
• Сетевые условия: правила работают в online-режиме; для изолированных сред без DNS-логирования нужно адаптировать logsource под локальный ETW или кастомные логи

Сразу оговорка: Sysmon Event ID 22 фиксирует DNS-запрос, но не показывает HTTP-путь внутри TLS. Для полного URL (включая path /v4/spreadsheets/...) нужна TLS-инспекция на proxy. Без неё DNS Query - основной источник, но контекста будет меньше.

Sigma-правило: cloud C2 detection по DNS-запросам от нестандартных процессов​

Логика простая: ловим DNS-запросы к облачным API-эндпоинтам от процессов, которые не должны к ним обращаться. Базовый детект, но на удивление эффективный - работает для всех трёх каналов: Google Sheets, OneDrive и Slack.

title: Non-Browser Process Queries Cloud C2 API Endpoints
status: experimental
logsource:
    category: dns_query
    product: windows
detection:
    cloud_api:
        QueryName|endswith:
            - 'sheets.googleapis.com'
            - 'graph.microsoft.com'
            - 'hooks.slack.com'
    legit_process:
        Image|endswith:
            - '\chrome.exe'
            - '\msedge.exe'
            - '\firefox.exe'
            - '\Teams.exe'
            - '\OneDrive.exe'
            - '\slack.exe'
    condition: cloud_api and not legit_process
level: high

Конвертация в целевой формат: sigma convert -t splunk -p sysmon rule.yml для Splunk, sigma convert -t eql -p ecs_windows для Elastic. Для Microsoft Sentinel - backend kusto.

После деплоя в прод первое, что нужно сделать - расширить фильтр legit_process под свою среду. CI/CD-агенты, корпоративные интеграции с Google Workspace, скрипты мониторинга - всё это полетит в алерты. Типичный false positive rate на старте - 5-15 алертов в день на 500 хостов. После двух недель тюнинга allow-листа - 0-2 алерта в день.

Расширенные детекты: поведенческий анализ сетевого трафика​

Помимо базового правила на DNS, стоит добавить ещё несколько Sigma-правил для поведенческого анализа:

Beacon-паттерн к облачному API. Если один процесс стучит в sheets.googleapis.com или graph.microsoft.com с регулярным интервалом (каждые 30-300 секунд) - это поведение beacon'а. В классическом Sigma pipe-based aggregation syntax deprecated и не поддерживается большинством современных pySigma-бэкендов. Рекомендую использовать Sigma Correlation Rules (отдельный YAML с type: event_count, group-by: Image, timespan: 15m, condition: gte 10), либо реализовать агрегацию нативно в SIEM (Splunk: stats count by Image, Elastic: KQL summarize). Порог и окно подбираются под конкретную среду - универсального рецепта нет.

Нетипичный User-Agent. Если прокси-логи показывают обращение к sheets.googleapis.com с User-Agent без строки браузера - прямой индикатор. По аналогии с AdaptixC2, где стандартный User-Agent (Mozilla/5.0 (Windows NT 6.2; rv:20.0)) - слабый, но рабочий сетевой индикатор.

C2 over HTTPS обнаружение через JA3/JA4. Хэш TLS-handshake процесса, использующего нестандартную TLS-библиотеку (Python requests, Go net/http) для обращения к облачному API, будет отличаться от хэша браузера. Нужен NTA с поддержкой JA3/JA4 - Zeek, Suricata 7+, CrowdStrike Falcon с модулем Falcon for Cloud.

YARA rules C2: поиск облачных имплантов в памяти и на диске​

YARA-правила дополняют сетевые Sigma-детекты: Sigma ловит трафик в реальном времени, YARA находит сам имплант при threat hunting - сканировании диска, памяти процессов или входящих файлов на sandbox.

Логика: любой C2-имплант, работающий через облачный сервис, содержит строки API-эндпоинтов - URL webhook'ов, пути Google Sheets API, endpoint'ы Graph API. Эти строки можно искать в PE-файлах, скриптах и дампах памяти.

rule cloud_c2_implant_indicators {
    meta:
        description = "Detects binaries with cloud API C2 endpoints"
        reference = "MITRE ATT&CK T1102, T1567.002"
    strings:
        $sheets = "sheets.googleapis.com" ascii wide
        $graph = "graph.microsoft.com/v1.0/me/drive" ascii wide
        $slack_hook = "hooks.slack.com/services/" ascii wide
        $slack_api = "api.slack.com/api/chat.postMessage" ascii wide
    condition:
        uint16(0) == 0x5A4D and 2 of ($sheets, $graph, $slack_hook, $slack_api)
}

Правило срабатывает на PE-файлы (проверка MZ-заголовка через uint16(0) == 0x5A4D), содержащие минимум два из четырёх облачных API-эндпоинтов. Почему два, а не один? Единичное вхождение graph.microsoft.com может быть у легитимного ПО, но сочетание с hooks.slack.com - уже аномалия.

Для сканирования памяти процессов удалите условие uint16(0) == 0x5A4D (заведите отдельный файл memory_rule.yar) и запускайте через yara memory_rule.yar <PID> для живой памяти (Windows: требует запуск от Administrator с SeDebugPrivilege) или yara -r memory_rule.yar /path/to/dumps/ для рекурсивного скана директории с дампами. В CrowdStrike Falcon RTR можно запустить кастомный PowerShell-скрипт через runscript -CloudFile=yara_scan.ps1, который деплоит yara.exe и rule-файл на хост - YARA binary не поставляется с агентом, придётся тащить свой.

Ограничения YARA-подхода - и их стоит держать в голове:

• Обфускация строк: если имплант шифрует строки XOR'ом (по аналогии с шелл-кодом Cloud Atlas, где применялся однобайтовый XOR 0x12), YARA не найдёт plaintext. Для обфусцированных имплантов нужен YARA с модулем math или динамический анализ
• Скриптовые импланты: PowerShell и Python-based C2 не имеют MZ-заголовка. Для них - отдельное правило без uint16(0), но с более жёстким условием (3+ строки)
• Runtime generation: если URL собирается из частей в runtime (конкатенация переменных), ни одна строка целиком не попадёт в бинарник. Тут YARA бессильна

Практический playbook: threat hunting облачные сервисы​

Требования к окружению для threat hunting​

• Минимальный стек: SIEM с 30+ днями ретроспективы DNS-логов, EDR с process tree, доступ к proxy-логам
• RAM аналитической станции: от 16 ГБ для работы с дампами памяти через Volatility 3 + YARA
• Сетевые условия: доступ к CloudTrail (AWS) / Azure Monitor / Google Workspace Audit Logs - зависит от облачных платформ в среде
• Права: read-only доступ к SIEM, EDR console и cloud audit logs

Decision tree: легитимное обращение к облачному API или C2​

Sigma-правило сработало, вы видите DNS-запрос к sheets.googleapis.com от powershell.exe. Что дальше?

Шаг 1 - Process tree. Открываем process tree в EDR. Легитимный сценарий: powershell.exe запущен через Task Scheduler, задача создана IT-отделом, скрипт понятный. Подозрительный: powershell.exe - дочерний процесс winword.exe или mshta.exe (характерно для macro-based доставки, аналогично цепочке Cloud Atlas с template injection).

Шаг 2 - Частота и интервал. Выгружаем из SIEM все обращения этого процесса к целевому домену за 7 дней. Регулярный интервал (каждые 60 секунд +/- jitter) - beacon-паттерн. Хаотичные обращения с большими промежутками - скорее легитимная активность.

Шаг 3 - Payload analysis. Если есть TLS-инспекция - смотрим HTTP-путь. Обращение к конкретному spreadsheet ID (/v4/spreadsheets/1aBcDeFgHiJk...) - прямой индикатор. Проверяем документ: кто владелец, когда создан, что внутри.

Шаг 4 - Lateral context. Есть ли аналогичные обращения с других хостов? Один и тот же spreadsheet ID запрашивается с трёх машин в разных сегментах - это координированный C2, а не случайность.

Шаг 5 - Containment decision. При подтверждении C2: изолируем хост через EDR (network containment), блокируем spreadsheet ID на прокси (даже если домен остаётся в allow-листе), отзываем OAuth-токены в Azure AD / Google Workspace Admin Console.

Ограничения техник детектирования cloud C2​

Ни одно из описанных правил - не серебряная пуля. Вот что нужно учитывать при деплое:

Техника	Работает против	Не работает против	Контекст применения
Sigma DNS Query	Импланты с hardcoded API URL в отдельном процессе	Process injection в браузер, динамическая генерация URL	Корпоративные среды с Sysmon/EDR, внутренний пентест
Sigma Beacon Pattern	C2 с фиксированным sleep interval	Рандомизированный jitter >50%, event-driven C2	Среды с 30+ днями логов, ретроспективный hunting
YARA static scan	Скомпилированные импланты на Go/C/C++ с plaintext строками	XOR/AES-обфускация строк, скриптовые импланты, runtime URL generation	Sandbox, endpoint scan, IR triage
JA3/JA4 fingerprint	Нестандартные TLS-стеки (Python, Go)	Импланты на WinHTTP/WinINet (нативный TLS-стек Windows)	Среды с NTA: Zeek, Suricata 7+

Отдельная головная боль - Domain Fronting (T1090.004). Атакующий направляет HTTPS-запрос к CDN Google или Microsoft, указав в SNI легитимный домен, а в Host-заголовке - свой C2. На уровне DNS и SNI всё чисто. Детектирование требует TLS-инспекции и сравнения SNI с Host-заголовком - а это возможно только на proxy/NGFW с deep packet inspection.

Ещё один gap: MITRE T1213.002 (Sharepoint) - атакующий может использовать SharePoint не как C2, а как хранилище для staging данных перед эксфильтрацией. Этот паттерн не попадает под Sigma-правила на DNS-запросы и требует анализа аудит-логов Microsoft 365 (SharePoint Access logs).

По данным IBM X-Force Threat Intelligence Index 2025, среднее время между публикацией CVE и устранением в организации - 29 месяцев. Для облачных C2-каналов аналогичная метрика - время от появления нового облачного сервиса в арсенале APT до создания детектирующего правила в SOC - часто измеряется в кварталах. Единственный способ сократить этот разрыв - не ждать IOC от вендоров, а строить поведенческие детекты заранее, используя MITRE T1102 как чертёж.

Среди коллег по detection engineering я вижу устойчивый перекос: 80% усилий уходит на endpoint-техники (process injection, credential dumping, persistence), и лишь 20% - на сетевые C2-паттерны. Для классических C2-фреймворков (Cobalt Strike, Sliver, AdaptixC2) это работает - там есть характерные сетевые сигнатуры, кастомные HTTP-заголовки и User-Agent-строки из профилей, предсказуемые паттерны HTTP. Но для cloud C2 endpoint-телеметрия без сетевого контекста - это одноглазый SOC. Вы видите, что powershell.exe сделал HTTP-запрос, но не видите, что он пошёл к Google Sheets, а не к корпоративному API. Без корреляции DNS-логов, прокси-логов и process tree ваши Sigma rules APT останутся красивым YAML в репозитории, а не рабочим детектом в проде.

Прогноз: доля APT-кампаний с C2 через облачные API в ближайший год превысит 40% от всех обнаруженных C2-каналов. SOC-команды, которые не инвестировали в cloud C2 detection сейчас, будут разбирать инциденты постфактум - входя в те самые 57%, которые узнают о компрометации от внешней стороны. Возьмите Sigma-правило из раздела выше, сконвертируйте под свой SIEM и задеплойте на пилотную группу хостов. Первые алерты покажут, сколько у вас в среде процессов, которые тихо стучат в облачные API - и не все из них будут легитимными.