all3xj/fixing-google-secops-detectionsضبط وإعادة هيكلة كشوفات Google Chronicle المنسّقة للقضاء على إرهاق التنبيهات وإصلاح الفجوات المنطقية والأخطاء البرمجية.
يوثّق هذا المستودع عيوب التصميم المعماري، والتناقضات المنطقية، واستراتيجيات الضبط الخاصة بكشف Google SecOps (Chronicle) المنسّق الأصلي.
في حين توفّر Google Threat Intelligence (GTIG) تغطية مفاهيمية استثنائية للتهديدات (مثل تتبّع حملات APT29/BRICKSTORM)، فإن تطبيقات YARA-L الخام للقواعد المنسّقة تعاني أحيانًا من سهو في التنفيذ، مثل تناقضات منطق التجميع والمتغيرات الحدّية المُضمّنة بشكل ثابت. وفي بيئات المؤسسات الواقعية، يؤدي هذا في كثير من الأحيان إلى إرهاق هائل بالتنبيهات.
يحلّل هذا المشروع سبب تعطّل القواعد الأصلية أو إغراق مركز العمليات الأمنية (SOC)، ويشارك قواعد مخصّصة محسّنة وتصحيحات لمعالجة هذه المشكلات.
أصدرت Google مجموعة من القواعد للكشف عن التسريب الجماعي للبريد الإلكتروني من Microsoft 365 Exchange Online بواسطة Service Principals المخترقة (تقنيات يستخدمها APT29/Midnight Blizzard بكثافة).
القواعد المنسّقة المتأثرة هي:
O365 Mailbox Access by Service Principal with Multiple User AgentsO365 Multiple Mailboxes Accessed by Service PrincipalO365 Mailbox Access by Service Principal from Multiple ASNsO365 Multiple Mailboxes Accessed via Microsoft Graph APIتحتوي هذه المجموعة من القواعد على عدم تطابق منهجي في المنطق بين الهدف المعلن وتطبيق YARA-L، على الأرجح بسبب إعادة استخدام الشيفرة عبر حزمة القواعد. تفشل القواعد في التمييز بشكل صحيح بين Service Principals الآلية والنشاط البشري القياسي، مما يؤدي إلى تنبيهات تُطلق على سلوك الموظفين الطبيعي.
على الرغم من أن وصف القاعدة ينص صراحةً على: "Detects a Service Principal with a single O365 session ID..."، فإن قسم match في YARA-L الخاص بقاعدة "Multiple User Agents" يجمّع حسب $application_id بدلاً من معرّف الجلسة ($session_id). وهذا يتناقض تمامًا مع الهدف المعلن للقاعدة.
تتتبع القواعد أنماطًا سلوكية شاذة (تغيّر عناوين IP، أو ASNs، أو User-Agents) مرتبطة بـ ClientAppId محدّد. وبينما أدرجت Google تعبيرًا نمطيًا للاستثناء (exclusion regex) لعدة تطبيقات Microsoft أصلية، فقد أغفلت بشكل غير مبرّر أكثر عملاء الهواتف المحمولة البشرية انتشارًا: تطبيق Microsoft Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4).
Multiple ASNs. كما أن موظفين مختلفين يستخدمون iOS وAndroid للاطلاع على صندوق البريد نفسه الخاص بالقسم يُطلقون تنبيه Multiple User Agents.لتحديد حسابات خدمة الواجهة الخلفية (backend service accounts)، تعتمد منطقية Google على هذا الشرط:
$e.principal.user.userid != $e.target.user.userid
[email protected]). ينتج عن هذا العيب في التصميم ضجيج هائل على حركة المرور البشرية التشغيلية المعتادة.لإصلاح هذه العيوب في التصميم، لديك خياران حسب احتياجاتك التشغيلية:
الخيار 1: استثناءات SIEM الأصلية (إصلاح سريع)
ليس عليك بالضرورة تعطيل القواعد أو كتابة تعليمات برمجية مخصّصة. يمكنك ببساطة إنشاء استثناء (Exclusion) مباشرةً داخل واجهة Google SecOps SIEM. ما عليك سوى إضافة استثناء يستهدف ClientAppId الخاص بـ Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) وتطبيقات النسخ الاحتياطي المصرّح بها لديك (مثل Keepit). وهذا يوقف فورًا سيل النتائج الإيجابية الكاذبة مع إبقاء قواعد Google المُنسّقة (curated rules) نشطة.
الخيار 2: نشر قواعد مخصّصة (إصلاح معماري)
إذا كنت تريد إصلاح عيوب منطقية التجميع الأساسية بالكامل (مثل عدم تطابق $application_id)، فيجب عليك تعطيل عمليات الكشف المُنسّقة (Curated Detections) ونشر قواعد مخصّصة (Custom Rules). تتضمن الإصلاحات ما يلي:
27922004-...) صراحةً في القائمة البيضاء.match لتجميع البيانات بشكل صحيح حسب الجلسة (session).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
}
(المنطق نفسه، لكن في الاستثناءات تأكد من إدراج حلول النسخ الاحتياطي المصرّح بها مثل Keepit (a7cd46df...) إلى جانب Outlook Mobile في القائمة البيضاء.)