الكشوفات المنسقة في Google SecOps (Chronicle): تحليل العيوب والضبط

يوثّق هذا المستودع عيوب التصميم المعماري، والتناقضات المنطقية، واستراتيجيات الضبط للكشوفات المنسقة الأصلية في Google SecOps (Chronicle).

في حين أن Google Threat Intelligence (GTIG) توفّر تغطية استثنائية للتهديدات على المستوى المفاهيمي (مثل تتبّع حملات APT29/BRICKSTORM)، فإن تطبيقات YARA-L الخام للقواعد المنسقة تعاني أحيانًا من هفوات في التنفيذ، مثل تناقضات منطق التجميع ومتغيرات عتبة مكتوبة بشكل ثابت. في بيئات المؤسسات الواقعية، يؤدي هذا غالبًا إلى إجهاد تنبيهات هائل.

يحلّل هذا المشروع لماذا تتعطل القواعد الأصلية أو تغرق مركز العمليات الأمنية (SOC)، ويشارك قواعد مخصصة محسّنة وتصحيحات لحل هذه المشكلات.

📑 جدول المحتويات

1. فشل تنبيهات حزمة O365 لـ BRICKSTORM / APT29
   • الخلل 1: تناقض منطق التجميع
   • الخلل 2: تجاهل عميل Outlook Mobile العام
   • الخلل 3: تضارب صندوق البريد المشترك
   • حلول YARA-L المعدّلة لقواعد O365
2. UEBA: إجمالي محاولات المصادقة الشاذة
   • خلل الترميز الثابت وإجهاد التنبيهات
   • توصيات ضبط 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 العام

تتتبّع القواعد أنماط السلوك الشاذة (تغيّر عناوين IP أو ASNs أو User-Agents) المرتبطة بمعرّف تطبيق عميل محدد ClientAppId. وبينما تتضمن Google تعبير regex للاستثناء يغطي العديد من تطبيقات Microsoft الأصلية، فقد أغفلت بشكل غير مفهوم العميل المحمول البشري الأكثر انتشارًا: تطبيق Microsoft Outlook للجوال (27922004-5251-4030-b22d-91ecd9a37ea4).

• التأثير: دون استبعاد هذا العميل العام، فإن الموظفين الشرعيين الذين يقرؤون صناديق بريد مشتركة من هواتفهم الذكية ويتنقلون بين الشبكات (مثل الانتقال من 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) مباشرةً من واجهة 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"] = /./
    )
    
    // 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...) بتعبير regex الاستثنائي في نهاية كتلة events).

2. UEBA: إجمالي محاولات المصادقة الشاذة

القاعدة: Anomalous Auth Attempts Total by Principal Hostname and Target User ID

(ملاحظة: UEBA تعني "User and Entity Behavior Analytics". لا تستخدم هذه القواعد توقيعات ثابتة، بل تعتمد على خوارزميات رياضية لتحديد خط أساس للسلوك "الطبيعي" والتنبيه عند الانحرافات الإحصائية).

❌ خلل الترميز الثابت وإجهاد التنبيهات

تحاول قاعدة UEBA هذه كشف الارتفاعات الشاذة في المصادقة من خلال حساب المتوسط التاريخي والانحرافات المعيارية على مدى 30 يومًا.

• إجهاد التنبيهات: في بيئة الإنتاج لدينا، حققت هذه القاعدة المنسقة معدل إيجابية حقيقية منخفضًا بشكل مذهل (~0.08%، مع تذكرتين قابلتين للتنفيذ من أصل 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 في بيئتك الخاصة قبل نشرها إلى الإنتاج.