Google SecOps (Chronicle) क्यूरेटेड डिटेक्शन: त्रुटि विश्लेषण और ट्यूनिंग

यह रिपॉज़िटरी मूल Google SecOps (Chronicle) क्यूरेटेड डिटेक्शन के लिए आर्किटेक्चरल डिज़ाइन त्रुटियों, लॉजिक विसंगतियों और ट्यूनिंग रणनीतियों का दस्तावेज़ीकरण करती है।

हालाँकि Google Threat Intelligence (GTIG) असाधारण वैचारिक खतरा कवरेज प्रदान करता है (जैसे APT29/BRICKSTORM अभियानों को ट्रैक करना), क्यूरेटेड नियमों के रॉ YARA-L कार्यान्वयन कभी-कभी कार्यान्वयन चूकों से ग्रस्त होते हैं, जैसे ग्रुपिंग लॉजिक विरोधाभास और हार्डकोडेड थ्रेशोल्ड वेरिएबल। वास्तविक दुनिया के एंटरप्राइज़ वातावरण में, यह अक्सर भारी अलर्ट थकान का कारण बनता है।

यह प्रोजेक्ट विश्लेषण करता है कि क्यों मूल नियम टूटते हैं या SOC में बाढ़ लाते हैं, और इन समस्याओं को हल करने के लिए अनुकूलित कस्टम नियम और पैच साझा करता है।

अपस्ट्रीम ट्रैकिंग और विक्रेता फीडबैक

• स्थिति: लॉजिक अंतराल और नियम टेलीमेट्री फीडबैक को Google की डिटेक्शन इंजीनियरिंग / उत्पाद टीम द्वारा स्वीकार किया गया है, जिससे Google-आंतरिक नियम जीवनचक्र समीक्षा कार्यधारा शुरू हुई है।

---

📑 विषय-सूची

1. BRICKSTORM / APT29 के लिए O365 सूट अलर्टिंग विफलता
   • त्रुटि 1: ग्रुपिंग लॉजिक विरोधाभास
   • त्रुटि 2: Outlook Mobile पब्लिक क्लाइंट की अनदेखी
   • त्रुटि 3: साझा मेलबॉक्स टकराव
   • ट्यून किए गए YARA-L समाधान
2. O365 Teams: बाहरी प्रतिरूपण प्रयास
   • त्रुटि 1: विरोधी बनाम लक्ष्य उलटाव
   • त्रुटि 2: गलत मैच ग्रुपिंग कुंजी
   • ट्यून किया गया YARA-L समाधान
3. UEBA: कुल विसंगतिपूर्ण प्रमाणीकरण प्रयास
   • हार्डकोडिंग त्रुटि और अलर्ट थकान
   • ट्यूनिंग सिफ़ारिशें

---

1. BRICKSTORM / APT29 के लिए O365 सूट अलर्टिंग विफलता

Google ने समझौता किए गए Service Principals द्वारा 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 कार्यान्वयन के बीच प्रणालीगत लॉजिक बेमेल हैं, जो संभवतः नियम पैक में कोड पुन:उपयोग के कारण हैं। नियम स्वचालित Service Principals और मानक मानवीय गतिविधि के बीच ठीक से अंतर करने में विफल रहते हैं, जिसके परिणामस्वरूप सामान्य कर्मचारी व्यवहार पर अलर्ट ट्रिगर होते हैं।

त्रुटि 1: ग्रुपिंग लॉजिक विरोधाभास

नियम विवरण में स्पष्ट रूप से कहा गया है: "Detects a Service Principal with a single O365 session ID...", इसके बावजूद "Multiple User Agents" नियम का YARA-L match अनुभाग सत्र ID ($session_id) के बजाय $application_id द्वारा समूहीकृत करता है। यह नियम के बताए गए उद्देश्य का पूरी तरह से खंडन करता है।

• प्रभाव: एक ही एंटरप्राइज़ App ID और समान साझा मेल साझा करने वाले असंबंधित कर्मचारी सत्र 3 घंटे की विंडो में पूरे टेनेंट में विलय हो जाते हैं। यह तब भी गलत सकारात्मक परिणाम ट्रिगर करता है जब कोई भी दो अलग उपयोगकर्ता एक ही एप्लिकेशन के अंतर्गत विभिन्न उपयोगकर्ता एजेंट (जैसे, iPhone बनाम Android) के माध्यम से प्रमाणित होते हैं, जिससे व्यक्तिगत टोकन हाईजैकिंग को अलग करने में विफलता होती है।

त्रुटि 2: Outlook Mobile पब्लिक क्लाइंट की अनदेखी

ये नियम किसी विशिष्ट ClientAppId से जुड़े असामान्य व्यवहारिक पैटर्न (बदलते IPs, ASNs, या User-Agents) को ट्रैक करते हैं। जबकि Google ने कई नेटिव Microsoft अनुप्रयोगों के लिए एक exclusion regex शामिल किया है, उन्होंने अकल्पनीय रूप से सबसे सर्वव्यापी मानव मोबाइल क्लाइंट को छोड़ दिया: 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] खोलता है)। यह डिज़ाइन दोष मानक परिचालन मानव ट्रैफ़िक पर भारी शोर उत्पन्न करता है।

---

✅ O365 नियमों के लिए ट्यून किए गए YARA-L समाधान

इन डिज़ाइन दोषों को ठीक करने के लिए, आपकी परिचालन आवश्यकताओं के आधार पर आपके पास दो विकल्प हैं:

विकल्प 1: नेटिव SIEM Exclusions (त्वरित समाधान) आपको नियमों को अक्षम करने या कस्टम कोड लिखने की आवश्यकता नहीं है। आप सीधे Google SecOps SIEM UI के भीतर एक Exclusion बना सकते हैं। बस Outlook Mobile (27922004-5251-4030-b22d-91ecd9a37ea4) और अपने अधिकृत बैकअप अनुप्रयोगों (जैसे, Keepit) के ClientAppId को लक्षित करते हुए एक exclusion जोड़ें। यह Google के क्यूरेटेड नियमों को सक्रिय रखते हुए तुरंत false positive बाढ़ को रोक देता है।

विकल्प 2: कस्टम नियम तैनात करें (वास्तुशिल्पीय समाधान) यदि आप अंतर्निहित समूहीकरण तर्क दोषों को पूरी तरह से ठीक करना चाहते हैं (जैसे $application_id बेमेल), तो आपको Curated Detections को अक्षम करना होगा और Custom Rules तैनात करने होंगे। इन सुधारों में शामिल हैं:

1. Outlook Mobile (27922004-...) को स्पष्ट रूप से whitelist करना।
2. ज्ञात अधिकृत Enterprise Backup Apps (जैसे, Keepit) को whitelist करना।
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: एकाधिक मेलबॉक्स एक्सेस किए गए