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

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

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

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

📑 विषय सूची

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

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

Google ने समझौता किए गए सर्विस प्रिंसिपल्स द्वारा Microsoft 365 Exchange Online से बल्क ईमेल बहिर्गमन (exfiltration) का पता लगाने के लिए नियमों का एक सुइट जारी किया (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 सत्र ID वाले सर्विस प्रिंसिपल का पता लगाता है...", फिर भी "Multiple User Agents" नियम का YARA-L match अनुभाग सत्र ID ($session_id) के बजाय $application_id द्वारा समूहीकरण करता है। यह नियम के बताए गए उद्देश्य का पूरी तरह से खंडन करता है, क्योंकि यह केवल समान एप्लिकेशन का उपयोग करने के कारण 3-घंटे की अवधि में असंबंधित मानव लॉगिन को एकत्रित कर देता है।

दोष 2: Outlook मोबाइल पब्लिक क्लाइंट की अनदेखी

नियम किसी विशिष्ट ClientAppId से जुड़े असामान्य व्यवहार पैटर्न (बदलते IP, ASN, या User-Agent) को ट्रैक करते हैं। हालाँकि Google कई मूल Microsoft अनुप्रयोगों के लिए एक बहिष्करण रेगेक्स (exclusion regex) शामिल करता है, उन्होंने अकथनीय रूप से सबसे सर्वव्यापी मानव मोबाइल क्लाइंट को छोड़ दिया: Microsoft Outlook Mobile App (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

• प्रभाव: यह शर्त केवल यह जाँचती है कि अभिनेता ID लक्ष्य मेलबॉक्स स्वामी से भिन्न है या नहीं। यद्यपि यह स्वचालित सर्विस प्रिंसिपलों के लिए सही है, यह साझा या विभागीय मेलबॉक्स तक पहुँचने वाले मानव कर्मचारियों के लिए भी सामान्य व्यवहार है (उदाहरण के लिए, कोई ऑपरेटर [email protected] खोल रहा है)। यह डिज़ाइन दोष मानक परिचालन मानव ट्रैफ़िक पर बड़े पैमाने पर शोर उत्पन्न करता है।

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

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

विकल्प 1: मूल SIEM बहिष्करण (त्वरित सुधार) आपको जरूरी नहीं कि नियमों को अक्षम करना पड़े या कस्टम कोड लिखना पड़े। आप सीधे Google SecOps SIEM UI के भीतर एक Exclusion बना सकते हैं। बस Outlook Mobile के ClientAppId (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

(वही लॉजिक, लेकिन बहिष्करणों में Outlook Mobile के साथ अपने अधिकृत बैकअप समाधान जैसे Keepit (a7cd46df...) को व्हाइटलिस्ट करना सुनिश्चित करें।)

ट्यून किया गया नियम 3: Multiple ASNs

(User Agents नियम के विपरीत, Google वास्तव में इस नियम में $session_id द्वारा सही ढंग से समूहीकरण करने में सफल रहा है। हालाँकि, इसमें अभी भी Outlook Mobile बहिष्करण का अभाव है। ऊपर दिए गए समान बहिष्करण लॉजिक का पालन करें, और $source_asn_dc >= 2 पर शर्त बनाए रखें।)

ट्यून किया गया नियम 4: Microsoft Graph API के माध्यम से Multiple Mailboxes Accessed

(वही लॉजिक। सुनिश्चित करें कि आप events ब्लॉक के अंत में बहिष्करण रेगेक्स में Keepit (a7cd46df...) जैसे अधिकृत बैकअप अनुप्रयोगों को जोड़ते हैं।)

2. UEBA: असामान्य प्रमाणीकरण प्रयासों का कुल योग

नियम: Anomalous Auth Attempts Total by Principal Hostname and Target User ID

(नोट: UEBA का अर्थ "User and Entity Behavior Analytics" है। ये नियम स्थिर सिग्नेचर का उपयोग नहीं करते हैं, बल्कि सामान्य व्यवहार को आधारभूत (baseline) बनाने और सांख्यिकीय विचलनों पर अलर्ट करने के लिए गणितीय एल्गोरिदम पर निर्भर करते हैं।)

❌ हार्डकोडिंग दोष और अलर्ट थकान

यह UEBA नियम 30 दिनों में ऐतिहासिक औसत और मानक विचलन की गणना करके असामान्य प्रमाणीकरण स्पाइक्स का पता लगाने का प्रयास करता है।

• अलर्ट थकान: हमारे प्रोडक्शन वातावरण में, इस क्यूरेटेड नियम ने बेहद कम ट्रू पॉज़िटिव दर (~0.08%, 2324 अलर्ट में से केवल 2 कार्रवाई योग्य टिकट) उत्पन्न की। यह अनिवार्य रूप से शुद्ध शोर है।
• कोड दोष: Google outcome ब्लॉक की शुरुआत में एक वेरिएबल $num_stddevs_away = max(2) घोषित करता है। हालाँकि, $historical_threshold गणना में, Google डेवलपर ने वेरिएबल का उपयोग करने के बजाय मान 2 हार्डकोड किया। यह प्रोग्रामिंग त्रुटि विश्लेषकों को YARA-L लॉजिक को पूरी तरह से क्लोन और पुनर्लेखित किए बिना UI या इनहेरिटेड वेरिएबल्स के माध्यम से संवेदनशीलता को आसानी से ओवरराइड करने से रोकती है।

✅ UEBA ट्यूनिंग अनुशंसाएँ

वास्तविक दुनिया के परीक्षण से पता चलता है कि केवल सांख्यिकीय थ्रेशोल्ड में बदलाव करना (जैसे, $num_stddevs_away को 3 या 4 तक बढ़ाना, $coefficient_of_variation_threshold को 0.1 से घटाकर 0.05 करना, या $observation_threshold को बढ़ाकर 15 करना) पर्याप्त नहीं है: इससे साप्ताहिक अलर्ट की संख्या 710 से घटकर 111 रह जाती है, जो विश्लेषक टीम के लिए अभी भी अत्यधिक शोर है।

• अनुशंसित दृष्टिकोण: SecOps एंटरप्राइज़ टेनेंट्स के लिए, "Failed Authentications by Device" हेतु Broad रूलसेट अलर्टिंग अक्षम करें और पूरी तरह से Precise अलर्टिंग चैनल पर निर्भर रहें। यह संरचनात्मक शमन अलर्ट की बाढ़ को रोकने का एकमात्र प्रभावी तरीका है।
• वैकल्पिक कस्टम दृष्टिकोण: यदि आपको इसे सक्रिय रखना ही है, तो नियम को कस्टम नियम में क्लोन करें, अपने कस्टम $num_stddevs_away वेरिएबल से मेल खाने के लिए $historical_threshold के अंदर हार्डकोडेड 2 को ठीक करें, और सख्त बेसलाइन गुणांक लागू करें।

अस्वीकरण: ये ट्यूनिंग वास्तविक दुनिया के घटना प्रतिक्रिया और SIEM इंजीनियरिंग अनुभव पर आधारित हैं। उत्पादन में परिनियोजित करने से पहले हमेशा अपने विशिष्ट वातावरण में YARA-L नियमों का परीक्षण करें।