RedSun, BlueHammer, UnDefend, और CrossFamily डिटेक्शन पैक

महत्वपूर्ण: इस रिपॉजिटरी में सभी कोड और डिटेक्शन लॉजिक AI-जनरेटेड है। इस बात की कोई गारंटी नहीं है कि ये स्क्रिप्ट सही, पूर्ण, सुरक्षित, या किसी भी वातावरण के लिए उपयुक्त हैं। इन स्क्रिप्ट्स का उपयोग पूरी तरह से आपके अपने जोखिम पर करें। रिपॉजिटरी लेखक इस सामग्री के उपयोग से होने वाली किसी भी क्षति, आउटेज, डेटा हानि, गलत सकारात्मक, गलत नकारात्मक, परिचालन प्रभाव, या अन्य हानि के लिए उत्तरदायी या जिम्मेदार नहीं है। किसी भी लाइव प्रोडक्शन वातावरण में तैनाती से पहले प्रत्येक स्क्रिप्ट की समीक्षा, परीक्षण, ट्यूनिंग और योग्य कर्मियों द्वारा सत्यापन किया जाना चाहिए।

अवलोकन

यह रिपॉजिटरी, redsun-bluehammer-undefend-detection-pack, कस्टो क्वेरी लैंग्वेज (KQL) में लिखे गए Microsoft Defender XDR एडवांस्ड हंटिंग क्वेरीज़ को शामिल करती है। क्वेरीज़ को RedSun, BlueHammer, UnDefend, Huntress-द्वारा देखे गए साझा इंट्रूज़न टूलिंग, Microsoft Defender, Cloud Files, वॉल्यूम शैडो कॉपी सर्विस (VSS), Windows सर्विस व्यवहार, स्थानीय खाता हेरफेर, सिम्बोलिक लिंक, रिपार्स पॉइंट्स, और संबंधित Windows टेलीमेट्री से जुड़ी प्रूफ-ऑफ-कॉन्सेप्ट अटैक चेन के लिए तकनीकी डिटेक्शन पैकेज के रूप में व्यवस्थित किया गया है।

सामग्री सुरक्षा अनुसंधान, डिटेक्शन इंजीनियरिंग, लैब सत्यापन, और नियंत्रित हंटिंग वर्कफ़्लो के लिए डिज़ाइन की गई है। यह एक ड्रॉप-इन प्रोडक्शन डिटेक्शन सेट नहीं है। प्रत्येक वातावरण में अलग-अलग Defender XDR सेंसर कवरेज, इवेंट वॉल्यूम, एंडपॉइंट बेसलाइन, सॉफ़्टवेयर इन्वेंट्री, और वैध प्रशासनिक व्यवहार होते हैं। इन क्वेरीज़ को शेड्यूल्ड कस्टम डिटेक्शन के रूप में सक्षम करने से पहले आपको अपने स्वयं के टेनेंट में सिंटैक्स और डिटेक्शन गुणवत्ता दोनों को मान्य करना होगा।

2026-05-05 पर सत्यापित स्रोत समीक्षा BlueHammer को CVE-2026-33825 से मैप करती है। NVD प्रभावित-प्लेटफ़ॉर्म डेटा और Microsoft Defender रिलीज़ नोट्स Microsoft Defender एंटीमैलवेयर प्लेटफ़ॉर्म संस्करण 4.18.26030.3011 से पहले के संस्करणों को प्रभावित के रूप में पहचानते हैं। इस समीक्षा के दौरान RedSun या UnDefend के लिए कोई सार्वजनिक Microsoft CVE या विक्रेता पैच सत्यापित नहीं किया गया; Huntress ने बताया कि 2026-04-20 तक दोनों अनपैच्ड बने हुए हैं। यह रिपॉजिटरी व्यवहार और Defender टेलीमेट्री का पता लगाती है; यह स्वयं पैच अनुपालन का निर्धारण नहीं करती है।

सत्यापित अनुसंधान बेसलाइन

• अंतिम सत्यापन: 2026-05-05
• BlueHammer: CVE-2026-33825; Defender एंटीमैलवेयर प्लेटफ़ॉर्म 4.18.26030.3011 या उसके बाद के संस्करण को इस रिपॉजिटरी में प्रलेखित न्यूनतम सत्यापित पैच्ड बेसलाइन मानें।
• RedSun: 2026-05-05 स्रोत समीक्षा के दौरान कोई सार्वजनिक Microsoft CVE या विक्रेता पैच सत्यापित नहीं किया गया। इस पैकेज को व्यवहार-केंद्रित रखें।
• UnDefend: 2026-05-05 स्रोत समीक्षा के दौरान कोई सार्वजनिक Microsoft CVE या विक्रेता पैच सत्यापित नहीं किया गया। इस पैकेज को व्यवहार-केंद्रित रखें।
• क्रॉस-फ़ैमिली इंट्रूज़न संदर्भ: Huntress ने साझा देखे गए टूलिंग, BeigeBurrow फॉलो-ऑन गतिविधि, और रिकॉन कमांड्स का दस्तावेज़ीकरण किया जो हंटिंग और एनरिचमेंट के लिए उपयोगी हैं, स्वयं निर्धारक प्रमाण नहीं।

रिपॉजिटरी लेआउट

रिपॉजिटरी डिटेक्शन सामग्री और समर्थन सामग्री दोनों के लिए पैकेज फ़ोल्डरों का उपयोग करती है। KQL-युक्त फ़ोल्डर अनुक्रमिक संख्या का उपयोग करते हैं जो 01 से शुरू होती है।

क्वेरी डिज़ाइन पैटर्न

चार फुल-चेन डिटेक्शन पैकेज (RedSun, BlueHammer, UnDefend, और CrossFamily) समान संरचना का पालन करते हैं:

1. 01_*_full_attack_chain.kql समग्र हंट है। यह सभी स्टेज लॉजिक को एक साथ चलाता है और परिभाषित समय विंडो के भीतर एक ही डिवाइस पर साक्ष्य को सहसंबंधित करता है।
2. क्रमांकित स्टैंडअलोन स्क्रिप्ट व्यक्तिगत स्टेज को अलग करती हैं। ये समस्या निवारण, बेसलाइन विश्लेषण, कस्टम डिटेक्शन प्रोटोटाइपिंग, और गलत-सकारात्मक समीक्षा के लिए हैं।
3. स्टैंडअलोन स्क्रिप्ट फुल-चेन क्वेरी में संबंधित स्टेज ब्लॉक से मेल खाने की उम्मीद की जाती है, सिवाय अंतिम प्रदर्शन-केवल क्रमबद्धता जैसे | order by Timestamp desc के।
4. मुख्य क्वेरीज़ सामान्यीकृत फ़ील्ड जैसे Stage, StageDescription, ProcessName, ProcessCommandLine, AccountName, Evidence, AdditionalContext, और ReportRefs उत्सर्जित करती हैं ताकि क्रॉस-स्टेज आउटपुट की समीक्षा करना आसान हो।
5. रूढ़िवादी शेड्यूल्ड-डिटेक्शन उम्मीदवार, जहाँ मौजूद हैं, प्रत्येक पैकेज के production/ उपनिर्देशिका के अंतर्गत रहते हैं और शीर्ष-स्तरीय हंटिंग क्वेरीज़ की तुलना में अधिक सख्त होते हैं।

Exposure इन्वेंट्री-संचालित एक्सपोज़र रिपोर्टिंग के लिए एक समर्थन पैकेज है, फुल-चेन व्यवहार हंट नहीं। ExternalTelemetry केवल-दस्तावेज़ीकरण है और इसमें एंडपॉइंट KQL शामिल नहीं है।

Microsoft Defender XDR आवश्यकताएँ

ये क्वेरीज़ Microsoft Defender XDR एडवांस्ड हंटिंग के लिए हैं। ये Defender for Endpoint और संबंधित Defender XDR टेलीमेट्री से तालिका और कॉलम उपलब्धता पर निर्भर करती हैं।

सामान्यतः उपयोग की जाने वाली तालिकाओं में शामिल हैं:

टेलीमेट्री सभी टेनेंट्स में समान नहीं है। कुछ निम्न-स्तरीय प्राइमिटिव, विशेष रूप से कच्चे oplock, रिपार्स पॉइंट, ऑब्जेक्ट मैनेजर सिम्बोलिक लिंक, और सर्विस क्वेरी टेलीमेट्री, स्पष्ट इवेंट के रूप में प्रकट नहीं हो सकते हैं। इसलिए क्वेरीज़ में ActionType और AdditionalFields के विरुद्ध अवसरवादी मिलान शामिल है जहाँ Defender XDR उन विवरणों को उजागर करता है।

अनुशंसित सत्यापन वर्कफ़्लो

प्रोडक्शन उपयोग से पहले, प्रत्येक फुल-चेन डिटेक्शन पैकेज को इस क्रम में मान्य करें:

1. सीमित लुकबैक का उपयोग करके एडवांस्ड हंटिंग में प्रत्येक स्टैंडअलोन क्वेरी चलाएँ।
2. पुष्टि करें कि क्वेरी आपके टेनेंट में संकलित होती है।
3. कच्चे परिणाम वॉल्यूम की समीक्षा करें और मेल खाने वाले वैध सॉफ़्टवेयर या प्रशासनिक वर्कफ़्लो की पहचान करें।
4. ज्ञात-अच्छे टूल, सर्विस खाते, सॉफ़्टवेयर तैनाती सिस्टम, बैकअप उत्पाद, EDR टूल, और भेद्यता स्कैनर के लिए स्थानीय बहिष्करण जोड़ें।
5. उसी पैकेज के लिए 01_*_full_attack_chain.kql क्वेरी चलाएँ।
6. फुल-चेन परिणामों की तुलना स्टैंडअलोन परिणामों से करें और पुष्टि करें कि सहसंबंधित स्टेज परिचालन रूप से समझ में आते हैं।
7. परिणामों को CSV में निर्यात करें और प्रोसेस पथ, कमांड लाइन, खाते, डिवाइस, और टाइमस्टैम्प की समीक्षा करें।
8. केवल ट्यूनिंग के बाद ही आपको क्वेरी को शेड्यूल्ड कस्टम डिटेक्शन नियम में परिवर्तित करना चाहिए।

रिपॉजिटरी CI भी .github/scripts/validate_repository.py चलाता है ताकि KQL हेडर, मेटाडेटा ब्लॉक, डिलीमीटर संतुलन, सन्निहित संख्या, स्टैंडअलोन-से-फुल-चेन स्टेज संरेखण, README कवरेज, प्रोडक्शन-प्लेसमेंट नियम, और IOC स्रोत-ट्रेसेबिलिटी अपेक्षाओं की पुष्टि की जा सके।

प्रोडक्शन तैनाती मार्गदर्शन

इन क्वेरीज़ को प्रारंभिक बिंदु के रूप में मानें। एक प्रोडक्शन तैनाती में शामिल होना चाहिए:

• ज्ञात-अच्छे प्रोसेस और पथों के लिए टेनेंट-विशिष्ट अनुमत सूचियाँ।
• हंटिंग बनाम अलर्टिंग के लिए अलग थ्रेशोल्ड।
• जहाँ संभव हो शेड्यूल्ड डिटेक्शन के लिए संकीर्ण लुकबैक विंडो।
• प्रलेखित गंभीरता मैपिंग और ट्राइएज रनबुक।
• अपेक्षित मिलानों की पुष्टि के लिए परीक्षण डिवाइस या लैब सिमुलेशन।
• स्वचालित घटना निर्माण सक्षम करने से पहले परिवर्तन नियंत्रण।
• Defender सेंसर अपडेट या ऑपरेटिंग सिस्टम अपग्रेड के बाद आवधिक समीक्षा।

बिना ट्यूनिंग के सभी मुख्य क्वेरीज़ को उच्च-गंभीरता शेड्यूल्ड डिटेक्शन के रूप में तैनात न करें। कुछ स्टेज जानबूझकर कमजोर या अवसरवादी सिग्नल का पता लगाती हैं जो सहसंबंध के लिए उपयोगी हैं लेकिन स्टैंडअलोन अलर्ट के रूप में शोरगुल वाले हैं।

जहाँ एक पैकेज production/ क्वेरी संस्करण प्रदान करता है, उस फ़ाइल को शीर्ष-स्तरीय हंटिंग क्वेरी के बजाय शेड्यूल्ड कस्टम डिटेक्शन के लिए प्रारंभिक बिंदु के रूप में मानें।

प्रदर्शन नोट्स

मुख्य क्वेरीज़ जहाँ संभव हो व्यापक असीमित जॉइन से बचने के लिए डिज़ाइन की गई हैं। वे सामान्यीकृत स्टेज पंक्तियाँ, प्रारंभिक प्रोजेक्शन, और समय-बकेट सहसंबंध का उपयोग करती हैं। हालाँकि, प्रदर्शन अभी भी टेनेंट स्केल, लुकबैक अवधि, और इवेंट वॉल्यूम पर निर्भर करता है।

यदि कोई क्वेरी Defender XDR निष्पादन सीमा से अधिक हो जाती है:

• Lookback कम करें।
• महंगे स्टेज की पहचान करने के लिए पहले स्टैंडअलोन स्टेज चलाएँ।
• संकीर्ण प्रोसेस, पथ, खाता, या डिवाइस फ़िल्टर जोड़ें।
• केवल आवश्यक प्रोजेक्टेड कॉलम रखें।
• जॉइन या सहसंबंध से पहले सारांशित स्टेज आउटपुट को प्राथमिकता दें।
• जहाँ समर्थित हो और जहाँ उच्च-कार्डिनैलिटी समूहीकरण आवश्यक हो, शफ़ल संकेतों का उपयोग करें।

परिणाम व्याख्या

क्वेरीज़ को संदिग्ध व्यवहार पैटर्न के डिटेक्शन के रूप में व्याख्या किया जाना चाहिए, स्वयं समझौते का प्रमाण नहीं। एक फुल-चेन मिलान स्टैंडअलोन स्टेज मिलान से अधिक मजबूत है, लेकिन प्रत्येक परिणाम के लिए अभी भी विश्लेषक समीक्षा की आवश्यकता होती है।

उच्च-मूल्य समीक्षा फ़ील्ड:

• DeviceName और DeviceId
• FirstSeen और LastSeen
• StageCount
• Stages
• Processes
• ProcessCommandLines
• Accounts
• Evidence
• AdditionalContexts
• ReportRefs

विश्लेषकों को इन फ़ील्ड्स से Defender डिवाइस टाइमलाइन, प्रोसेस ट्री, फ़ाइल टाइमलाइन, रजिस्ट्री टाइमलाइन, अलर्ट साक्ष्य, और पहचान गतिविधि में पिवट करना चाहिए।

फ़ोल्डर दस्तावेज़ीकरण

प्रत्येक डिटेक्शन या समर्थन फ़ोल्डर में पैकेज-विशिष्ट तकनीकी विवरण के साथ अपना स्वयं का README है:

• RedSun/README.md
• BlueHammer/README.md
• UnDefend/README.md
• CrossFamily/README.md
• Exposure/README.md
• ExternalTelemetry/README.md

उस पैकेज या समर्थन सामग्री का उपयोग करने से पहले संबंधित फ़ोल्डर README का उपयोग करें। यह स्टेज मॉडल, अपेक्षित टेलीमेट्री, संभावित गलत सकारात्मक, ट्यूनिंग बिंदु, और तैनाती विचारों का वर्णन करता है।

रिपॉजिटरी दस्तावेज़ीकरण

सामान्य रिपॉजिटरी फ़ाइलें:

• CONTRIBUTING.md योगदान दायरे, KQL शैली, सत्यापन, और पुल रिक्वेस्ट अपेक्षाओं का वर्णन करता है।
• CHANGELOG.md उल्लेखनीय परिवर्तनों को रिकॉर्ड करता है।
• SOURCES.md सार्वजनिक दावों, बेसलाइन, शमन, और IOC परिवर्धन को उनके सत्यापन स्रोतों से मैप करता है।
• IOCS.md देखे गए संकेतकों और उनके इच्छित विश्वास और उपयोग सीमाओं को रिकॉर्ड करता है।
• MITIGATIONS.md स्रोत-समर्थित शमन और प्रतिपूरक नियंत्रण नोट्स को रिकॉर्ड करता है जिनका उपयोग यह रिपॉजिटरी करती है।
• ATTACK_MAPPING.md रिपॉजिटरी के ATT&CK-उन्मुख डिटेक्शन मैपिंग को रिकॉर्ड करता है।
• DEPLOYMENT_GUIDE.md लैब, पायलट, और प्रोडक्शन रोलआउट मार्गदर्शन को रिकॉर्ड करता है, जिसमें रोलबैक और अनुमत सूची शासन शामिल है।
• CODE_OF_CONDUCT.md सहयोग के लिए अपेक्षित व्यवहार को परिभाषित करता है।
• SECURITY.md वर्णन करता है कि सुरक्षा-संवेदनशील रिपॉजिटरी मुद्दों की रिपोर्ट कैसे करें।
• SUPPORT.md बताता है कि सहायता मांगते समय कौन सी समर्थन जानकारी प्रदान करनी चाहिए।
• DISCLAIMER.md समर्पित दस्तावेज़ में नो-वारंटी, उपयोग-अपने-जोखिम-पर स्थिति को दोहराता है।

रखरखाव नोट्स

इन KQL फ़ाइलों को जब भी पुनः मान्य किया जाना चाहिए:

• Microsoft Defender XDR तालिका स्कीमा या इवेंट नामकरण बदलता है।
• Defender for Endpoint सेंसर व्यवहार बदलता है।
• Windows फ़ीचर अपडेट सर्विस, रजिस्ट्री, Cloud Files, VSS, या MRT व्यवहार को बदलते हैं।
• नया वैध एंटरप्राइज़ सॉफ़्टवेयर Defender, VSS, Cloud Files, या SAM-संबंधित सतहों को छूना शुरू करता है।
• प्रोडक्शन अलर्टिंग के लिए क्वेरी थ्रेशोल्ड बदले जाते हैं।

टेनेंट-विशिष्ट बहिष्करणों और उन्हें जोड़ने के कारणों का रिकॉर्ड रखें। उन व्यापक बहिष्करणों से बचें जो हमलावर-नियंत्रित उपयोगकर्ता-लेखन योग्य पथों को दबाते हैं।