Статья Detection Engineering: Sigma и YARA правила для детекции стеганографии и облачного C2 APT28

42 хоста украинских военных структур. Кампания APT28, которую Sekoia.io назвала Operation Phantom Net Voxel. Стандартные IOC-фиды молчали всё время - ни одного алерта. C2-трафик шёл через Icedrive, Filen и Koofr - облачные хранилища, о которых среднестатистический SOC-аналитик в лучшем случае слышал, а SIEM точно не мониторит. Шеллкод передавался внутри PNG-файлов, замаскированный под обычные картинки. В SigmaHQ (8000+ правил, активная поддержка) нет ни одного правила на эти провайдеры, а стандартные YARA-сигнатуры ищут байтовые строки малвари - не энтропийные аномалии стеганографии. Ниже - Sigma и YARA правила, которые закрывают оба gap-а, маппинг на MITRE ATT&CK и чеклист развёртывания в production.

Бизнес-логика атаки: зачем APT28 использует стеганографию и облачный C2​

APT28 (Fancy Bear, Unit 26165 GRU) целится в военные, правительственные и дипломатические структуры. Финальный импакт текущей кампании - долговременный скрытый сбор разведданных: перехват клавиатурного ввода (Keylogging, T1056.001), снимки экрана (Screen Capture, T1113), эксфильтрация документов через тот же облачный канал (Exfiltration to Cloud Storage, T1567.002). Для коммерческого сектора аналогичная кампания - это утечка интеллектуальной собственности и оборотные штрафы за компрометацию ПДн.

Два слоя маскировки работают в связке. Стеганография (T1027.003) прячет payload от файлового анализа: PNG с шеллкодом - не исполняемый файл, sandbox его не запустит, AV не сработает, DLP пропустит. Облачный C2 (Web Service, T1102.002) прячет сетевой трафик: домены Icedrive, pCloud, Koofr стоят в allow-листах корпоративных прокси, TLS валидный, порт 443. По данным CrowdStrike Global Threat Report 2025, 79% атак обходятся без вредоносного ПО - атакующие используют легитимные сервисы. Mandiant M-Trends 2025 фиксирует: 57% организаций узнают об инциденте от внешней стороны, а не от собственного SOC. Цифра, которая должна вызывать профессиональный стыд.

Kill chain APT28: BEARDSHELL, COVENANT и MITRE ATT&CK маппинг​

Полная цепочка кампании с привязкой к конкретным имплантам, по данным отчётов Sekoia.io и Rescana:

Initial Access - Spearphishing Attachment (T1566.001). Weaponized Office-документы через email и Signal Desktop. Тут интересный момент: Signal не проставляет Mark-of-the-Web, и макросы Microsoft Office запускаются без предупреждения. Красивый вектор.

Execution - VBA-макросы (T1059.005) дропают загрузчик DLL (PlaySndSrv.dll) и PNG-файл с внедрённым шеллкодом. Далее задействуется PowerShell (T1059.001).

Persistence - Registry Run Keys (T1547.001) + COM Hijacking (T1546.015). Два независимых механизма закрепления - характерный паттерн APT28, они всегда дублируют persistence.

Defense Evasion - Steganography (T1027.003): модифицированный COVENANT встраивает шеллкод в PNG-файлы, извлекает в runtime. Opaque predicate obfuscation (T1027) в BEARDSHELL - техника, ранее замеченная в XTunnel этой же группы. BEARDSHELL и COVENANT вытаскивают C2-адреса из изображений в облачных хранилищах.

Command and Control - Bidirectional Communication (T1102.002): BEARDSHELL работает через Icedrive API (опрос каждые 4 часа, имя директории - FNV1a-хеш от hardware fingerprint хоста), COVENANT - через Filen, pCloud, Koofr. Web Protocols (T1071.001) - HTTPS. Asymmetric Cryptography (T1573.002) - ChaCha20-Poly1305 поверх TLS. Двойное шифрование - параноики, но параноики с результатом.

Collection и Exfiltration - SLIMAGENT перехватывает клавиатурный ввод (T1056.001), делает скриншоты (T1113). Результаты выгружаются как зашифрованные изображения с расширениями .bmp/.gif/.jpeg/.png/.tiff через тот же облачный канал (T1041, T1567.002).

Критические точки для detection engineering - шаги Defense Evasion и C2. На шаге 4 файловый анализ слеп к стеганографическим PNG. На шаге 5 сетевой анализ слеп к легитимным облачным доменам. Именно сюда и бьём правилами.

Sigma rules для T1102 Web Service C2 detection: облачные провайдеры APT28​

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

• Телеметрия: Sysmon Event ID 22 (DNS Query) или EDR с DNS-логированием - CrowdStrike Falcon, Microsoft Defender for Endpoint, Elastic Agent 8.11+
• SIEM: Splunk 8.x+ (конвертация в SPL), Elastic Security 8.11+ (EQL/KQL), Microsoft Sentinel (Kusto). Для MaxPatrol SIEM и KUMA - ручная адаптация, официальных pySigma-бэкендов на момент написания нет
• Конвертер: sigma-cli v1.x (репозиторий SigmaHQ/sigma-cli, установка через pip install sigma-cli, активная поддержка)
• Сетевые условия: DNS-логирование обязательно; для анализа URL-путей к API нужна TLS-инспекция на прокси

Где стандартные правила SigmaHQ слепы​

По тегу T1102 в SigmaHQ - 20 правил. По T1102.001 (Dead Drop Resolver) - 4 правила, среди них net_connection_win_domain_dead_drop_resolvers.yml, покрывающее Pastebin и подобные площадки. По T1102.002 (Bidirectional Communication) - ещё 4: Telegram API (два), GitHub self-hosted runners, Azure Front Door. Правила на Cloudflared-туннели, ngrok, Azure Front Door - есть. Правил на Icedrive, Filen, Koofr и pCloud - ноль. Именно этот gap APT28 и эксплуатирует.

Ключевая секция detection правила, закрывающего этот gap (метаданные стандартны: logsource: dns_query/windows, level: high, теги attack.t1102.002, attack.t1071.001):

detection:
  target_domains:
    QueryName|endswith:
      - '.icedrive.net'
      - '.filen.io'
      - '.koofr.net'
      - '.pcloud.com'
  filter_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
  condition: target_domains and not filter_browsers

Логика простая: DNS-запрос к одному из четырёх провайдеров от процесса, который не браузер. Если svchost.exe или rundll32.exe полезли на Icedrive - это повод разбираться. Конвертация: sigma convert -t splunk -p sysmon rule.yml для Splunk, sigma convert -t eql -p ecs_windows для Elastic, sigma convert -t kusto для Sentinel.

Тюнинг после деплоя: в первую неделю расширить filter_browsers процессами, которые легитимно обращаются к этим хранилищам - десктопные клиенты pCloud/Icedrive, CI/CD-агенты, backup-скрипты. Типичный FP rate на старте: 3-8 алертов в день на 500 хостов. После тюнинга allow-листа: 0-1.

Ограничение при process injection: если имплант инжектируется в процесс браузера - правило не сработает. Это фундаментальная слабость process-based фильтрации, и обойти её на уровне Sigma нельзя. Следующий слой - поведенческий анализ: beacon-паттерн (фиксированный интервал с jitter ±10-20%), ratio upload/download (D3FEND: Per Host Download-Upload Ratio Analysis, D3-PHDURA), аномалии в metadata протокола (D3FEND: Protocol Metadata Anomaly Detection, D3-PMAD). Эти метрики строятся нативными средствами SIEM - Sigma не поддерживает корреляцию событий даже в версии 2.0.

Скомпрометированные легитимные хосты: в кампании APT28 заражены рабочие машины реальных сотрудников. С одного хоста идёт и легитимный пользовательский трафик, и C2 импланта. Правило на процессы тут не поможет - нужен анализ периодичности запросов. Beacon стучит с фиксированным интервалом (± jitter), человек - хаотично. Эта разница и есть сигнал.

YARA правила: детекция стеганографии в файлах (MITRE ATT&CK T1027.003)​

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

• YARA: v4.x+ с модулем math (функция entropy). Установка: apt install yara или сборка из исходников (репозиторий VirusTotal/yara, активная поддержка)
• Точки сканирования: каталоги %TEMP%, %USERPROFILE%\Downloads, %APPDATA%, перехваченные файлы из TLS-инспекции прокси
• Интеграция: THOR scanner (Nextron - прямая поддержка YARA), CrowdStrike Falcon (custom IOA, ограниченная поддержка для файлов на диске), Elastic 8.x+ (через osquery), ручной запуск yara -r rule.yar /path

Почему байтовые сигнатуры бесполезны против стеганографии​

Стандартный YARA-подход - поиск magic bytes малвари, строк C2-серверов, характерных опкодов. Против стеганографии это мёртвый номер: шеллкод внутри PNG выглядит как случайные данные, а после шифрования ChaCha20-Poly1305 (как у BEARDSHELL) - тем более. Ни фиксированных строк, ни характерных паттернов. Файл - валидный PNG.

Рабочий подход - энтропийный анализ. Сжатые PNG/JPEG обычно дают 7.5-7.9 бит/байт из-за высокой энтропии сжатых данных. PNG с зашифрованным шеллкодом: ближе к теоретическому пределу 8.0, либо содержит данные после IEND-чанка (а их там быть не должно). Правило для threat hunting:

import "math"
rule Stego_PNG_High_Entropy {
  meta:
    description = "PNG with anomalous entropy - steganographic payload"
    mitre_attack = "T1027.003"
  strings:
    $png = { 89 50 4E 47 0D 0A 1A 0A }
    $iend = { 49 45 4E 44 AE 42 60 82 }
  condition:
    $png at 0 and $iend and
    math.entropy(0, filesize) > 7.9 and filesize > 100KB
}

Порог 7.9 - баланс между чувствительностью и FP rate. Для сред с большим объёмом легитимных PNG (дизайн, маркетинг) - поднять до 7.95. Более надёжный индикатор - наличие данных после IEND-чанка. По спецификации PNG там ничего быть не должно. Если есть - это либо кривой редактор, либо стего.

Ограничения и когда правило не работает​

Энтропийный анализ - это threat hunting правило, не production-детект. FP rate зависит от среды и порога: даже в бухгалтерии сжатые PNG могут давать энтропию 7.5-7.9, так что без дополнительных heuristics (данные после IEND, кросс-корреляция с сетевыми событиями) правило генерирует шум.

Heuristics для снижения FP: проверка на данные после IEND-чанка, анализ соотношения IDAT-чанков к общему размеру файла. Кросс-корреляция с Sigma-правилом (стеганографический PNG + DNS-запрос к Icedrive/Filen на одном хосте в 15-минутном окне) превращает два medium-confidence сигнала в один high-confidence алерт. Но это уже задача SIEM - в Splunk через transaction или stats, в Elastic - через EQL sequences.

Контекст применимости: правило работает для файлов на диске и в файловых хранилищах. Для in-memory стеганографии (имплант извлекает шеллкод из PNG и тут же удаляет файл) нужен memory forensics: Volatility или EDR с memory scan. CrowdStrike Falcon поддерживает custom YARA для memory; Elastic Agent на момент написания - нет.

Blue Team чеклист: развёртывание правил обнаружения APT28​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

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

Для каждого шага: ответственный - SOC L2+, SLA - 24 часа на деплой, критерий завершения - правило в production и 0 ложных алертов за 48 часов тестового периода.

Репутационная модель детекции C2 для cloud-based кампаний мертва. И это не публицистика - вывод из конкретного кейса, где 42 хоста скомпрометированы через домены с безупречной репутацией. Icedrive существует с 2019 года, pCloud - с 2013-го. Фид их не поймает никогда, потому что ловить нечего - это легитимные сервисы.

Переход к поведенческой детекции неизбежен. D3FEND описывает конкретные техники: Relay Pattern Analysis (D3-RPA) для выявления beacon-паттернов, Per Host Download-Upload Ratio Analysis (D3-PHDURA) для обнаружения эксфильтрации, Client-server Payload Profiling (D3-CSPP) для профилирования обращений к API. Проблема в том, что ни один SIEM не реализует D3FEND-техники из коробки. Sigma не поддерживает корреляцию даже в версии 2.0, а значит, поведенческие правила пишутся на нативном языке конкретного SIEM и мгновенно теряют переносимость. Open XP Rules пытается решить проблему корреляции с поддержкой временных окон и агрегаций, но его экосистема ограничена MaxPatrol SIEM. Пока индустрия не договорится о стандарте поведенческих правил - каждая SOC-команда изобретает велосипед в своём бэкенде. Большинство даже не начинают. На codeby.net коллеги ведут тред с разбором beacon-паттернов в cloud C2 на конкретных PCAP-артефактах - если строите поведенческую детекцию, имеет смысл сверить подход.