Курируемые детекции Google SecOps (Chronicle): анализ недостатков и настройка

Этот репозиторий документирует архитектурные недостатки проектирования, логические расхождения и стратегии настройки для нативных курируемых детекций Google SecOps (Chronicle).

Хотя Google Threat Intelligence (GTIG) обеспечивает исключительное концептуальное покрытие угроз (например, отслеживание кампаний APT29/BRICKSTORM), необработанные реализации курируемых правил на YARA-L иногда страдают от упущений при реализации, таких как противоречия в логике группировки и жёстко заданные пороговые переменные. В реальных корпоративных средах это часто приводит к массовой усталости от оповещений.

Этот проект анализирует, почему нативные правила ломаются или заваливают SOC, и делится оптимизированными пользовательскими правилами и патчами для решения этих проблем.

Отслеживание в upstream и обратная связь с вендором

• Статус: Логические пробелы и обратная связь по телеметрии правил были признаны командой Google по проектированию детекций / продуктовой командой, что инициировало внутренний рабочий поток Google по пересмотру жизненного цикла правил.

---

📑 Содержание

1. Сбой оповещения O365 Suite для BRICKSTORM / APT29
   • Недостаток 1: Противоречие в логике группировки
   • Недостаток 2: Упущение публичного клиента Outlook Mobile
   • Недостаток 3: Коллизия общих почтовых ящиков
   • Оптимизированные решения на YARA-L
2. O365 Teams: Попытка внешней имперсонации
   • Недостаток 1: Инверсия злоумышленника и цели
   • Недостаток 2: Ошибочный ключ группировки совпадений
   • Оптимизированное решение на YARA-L
3. UEBA: Общее количество аномальных попыток аутентификации
   • Недостаток жёсткого кодирования и усталость от оповещений
   • Рекомендации по настройке

---

1. Сбой оповещения O365 Suite для BRICKSTORM / APT29

Google выпустил набор правил для обнаружения массового вывода электронной почты из Microsoft 365 Exchange Online скомпрометированными субъектами-службами (техники, активно используемые APT29/Midnight Blizzard).

Затронутые курируемые правила:

• O365 Mailbox Access by Service Principal with Multiple User Agents
• O365 Multiple Mailboxes Accessed by Service Principal
• O365 Mailbox Access by Service Principal from Multiple ASNs
• O365 Multiple Mailboxes Accessed via Microsoft Graph API

❌ Основные недостатки в логике Google

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

Недостаток 1: Противоречие в логике группировки

Несмотря на то, что описание правила явно утверждает: «Обнаруживает субъект-службу с одним идентификатором сеанса O365...», раздел match в YARA-L правила «Multiple User Agents» группирует по $application_id, а не по идентификатору сеанса ($session_id). Это полностью противоречит заявленной цели правила.

• Влияние: Несвязанные сеансы сотрудников, использующие один и тот же корпоративный App ID и одну и ту же общую почту, объединяются по всему тенанту в течение 3-часового окна. Это вызывает ложные срабатывания всякий раз, когда любые два разных пользователя аутентифицируются через разные user agents (например, iPhone против Android) под одним и тем же приложением, не позволяя изолировать отдельный перехват токена.

Недостаток 2: Упущение публичного клиента Outlook Mobile

Правила отслеживают аномальные поведенческие паттерны (смену IP-адресов, ASN или User-Agent), связанные с конкретным ClientAppId. Хотя Google включает regex-исключение для нескольких нативных приложений Microsoft, они необъяснимо упустили самый распространённый клиент для мобильных устройств: Microsoft Outlook Mobile App (27922004-5251-4030-b22d-91ecd9a37ea4).

• Влияние: Без фильтрации этого Public Client легитимные сотрудники, читающие общие почтовые ящики со своих смартфонов и перемещающиеся между сетями (например, переключаясь с Wi-Fi на 4G), неизбежно вызывают срабатывание оповещений Multiple ASNs. Разные сотрудники, использующие iOS и Android для проверки одного и того же ведомственного почтового ящика, вызывают срабатывание оповещения Multiple User Agents.

Недостаток 3: Коллизия общих почтовых ящиков

Для идентификации сервисных учётных записей бэкенда логика Google опирается на это условие: $e.principal.user.userid != $e.target.user.userid

• Влияние: Это условие просто проверяет, отличается ли ID субъекта от владельца целевого почтового ящика. Хотя это верно для автоматизированных сервисных субъектов, это также стандартное поведение для сотрудников, обращающихся к общим или ведомственным почтовым ящикам (например, оператор, открывающий [email protected]). Этот недостаток дизайна порождает массовый шум на стандартном операционном человеческом трафике.

---

✅ Настроенные решения YARA-L для правил O365

Чтобы исправить эти недостатки дизайна, у вас есть два варианта в зависимости от ваших операционных потребностей:

Вариант 1: Нативные исключения SIEM (быстрое исправление) Вам не обязательно отключать правила или писать собственный код. Вы можете просто создать Exclusion непосредственно в интерфейсе Google SecOps SIEM. Просто добавьте исключение, нацеленное на ClientAppId Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) и ваши авторизованные приложения резервного копирования (например, Keepit). Это немедленно остановит поток ложных срабатываний, сохраняя курируемые правила Google активными.

Вариант 2: Развёртывание пользовательских правил (архитектурное исправление) Если вы хотите полностью исправить недостатки базовой логики группировки (такие как несоответствие $application_id), вы должны отключить курируемые детекции и развернуть пользовательские правила. Исправления включают:

1. Явное добавление Outlook Mobile (27922004-...) в белый список.
2. Добавление в белый список известных авторизованных приложений корпоративного резервного копирования (например, Keepit).
3. Исправление секций match для корректной агрегации по сессии.

Настроенное правило 1: Multiple User Agents

rule custom_ttp_o365_mailbox_access_by_service_principal_with_multiple_uas {
  meta:
    rule_name = "[CUSTOM] O365 Mailbox Access by Service Principal with Multiple User Agents"
    description = "Detects a Service Principal with a single O365 session ID accessing O365 mailboxes with multiple user agents. Tuned to fix grouping logic and exclude Outlook Mobile (Public Client) human traffic."
    severity = "Low"
    tactic = "TA0009"
    technique = "T1114.002"

  events:
    $e.metadata.log_type = "OFFICE_365"
    $e.metadata.product_event_type = "MailItemsAccessed" nocase
    $e.target.application = "Exchange"
    $e.security_result.detection_fields["RecordType"] = /^(2|50)$/

    // Extract actual Session ID and App ID
    $session_id =$e.network.session_id
    $application_id =$e.additional.fields["ClientAppId"]

    $e.principal.user.userid !=$e.target.user.userid

    ( 
      $e.network.http.user_agent = /AppId/ nocase or$e.additional.fields["ClientAppId"] = /./
    )