Google SecOps (Chronicle) Curated Detections: анализ ошибок и настройка

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

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

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

📑 Оглавление

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

1. Сбой алертинга набора O365 для BRICKSTORM / APT29

Google выпустила набор правил для обнаружения массовой эксфильтрации электронной почты из Microsoft 365 Exchange Online скомпрометированными субъектами службы (Service Principals) (методы, активно используемые 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, вероятно, из-за повторного использования кода в рамках пакета правил. Правила не позволяют корректно различать автоматизированные Service Principals и обычную человеческую активность, в результате чего алерты срабатывают на штатное поведение сотрудников.

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

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

Недочёт 2: Игнорирование Outlook Mobile Public Client

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

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

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

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

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

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

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

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

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

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"] = /./
    )
    
    // EXCLUSIONS: Added Outlook Mobile + Standard Google Exclusions
    $e.additional.fields["ClientAppId"] != /^(27922004-5251-4030-b22d-91ecd9a37ea4|bea75f7a-2505-46e8-9bf6-d3f7da9c9da7|b52893c8-bc2e-47fc-918b-77022b299bbc|...)$/ nocase

  match:
    // Group by both App AND Session to isolate the specific token lifecycle
    $application_id,$session_id over 3h

  outcome:
    $vendor_name = "Microsoft"
    $product_name = "Office 365"
    $source_ua_dc = count_distinct($e.network.http.user_agent)
    $client_app_id = array_distinct($e.additional.fields["ClientAppId"])

  condition:
    // Triggers if the SAME session rotates 2+ User Agents
    $e and $source_ua_dc >= 2
}

Настроенное правило 2: Multiple Mailboxes Accessed

(Та же логика, но в исключениях обязательно добавьте в белый список ваши авторизованные резервные решения, такие как Keepit (a7cd46df...), наряду с Outlook Mobile).

Настроенное правило 3: Multiple ASNs

(В отличие от правила User Agents, в этом правиле Google действительно удалось корректно сгруппировать по $session_id. Однако в нём по-прежнему отсутствует исключение для Outlook Mobile. Примените ту же логику исключений, что и выше, сохранив условие $source_asn_dc >= 2).

Настроенное правило 4: Multiple Mailboxes Accessed via Microsoft Graph API

(Та же логика. Убедитесь, что вы добавили авторизованные резервные приложения, такие как Keepit (a7cd46df...), в регулярное выражение исключений в конце блока events).

2. UEBA: Общее количество аномальных попыток аутентификации

Правило: Anomalous Auth Attempts Total by Principal Hostname and Target User ID

(Примечание: UEBA означает «User and Entity Behavior Analytics» (аналитика поведения пользователей и сущностей). Эти правила не используют статические сигнатуры, а опираются на математические алгоритмы для построения базовой линии «нормального» поведения и оповещают о статистических отклонениях).

❌ Ошибка хардкода и усталость от алертов

Это правило UEBA пытается обнаруживать аномальные всплески аутентификации, вычисляя историческое среднее и стандартные отклонения за 30 дней.

• Усталость от алертов: В нашей рабочей среде это курируемое правило показало невероятно низкую долю истинных срабатываний (~0.08%, 2 полезных тикета из 2324 алертов). По сути, это чистый шум.
• Ошибка в коде: Google объявляет переменную $num_stddevs_away = max(2) в начале блока outcome. Однако в вычислении $historical_threshold разработчик Google захардкодил значение 2 вместо использования переменной. Эта программная ошибка не позволяет аналитикам легко изменять чувствительность через интерфейс или наследуемые переменные без полного клонирования и переписывания логики YARA-L.

✅ Рекомендации по настройке UEBA

Реальное тестирование показывает, что простое изменение статистических порогов (например, повышение $num_stddevs_away до 3 или 4, снижение $coefficient_of_variation_threshold с 0.1 до 0.05 или увеличение $observation_threshold до 15) недостаточно: оно снижает количество недельных алертов с 710 до 111, что по-прежнему остаётся чрезмерно шумным для команды аналитиков.

• Рекомендуемый подход: Для корпоративных тенантов SecOps отключите алертинг в наборе правил Broad для «Failed Authentications by Device» и полагайтесь строго на канал алертинга Precise. Это структурное смягчение — единственный эффективный способ остановить поток алертов.
• Альтернативный кастомный подход: Если вам необходимо оставить правило активным, клонируйте его в Custom Rule, исправьте захардкоженное 2 внутри $historical_threshold, чтобы оно соответствовало вашей пользовательской переменной $num_stddevs_away, и примените более строгие базовые коэффициенты.

Отказ от ответственности: Эти настройки основаны на реальном опыте реагирования на инциденты и инженерной работы с SIEM. Всегда тестируйте правила YARA-L в вашем конкретном окружении перед развёртыванием в production.