घटनाओं की जांच के लिए तैयार हो रही है

क्या साइबर हमलों से पूरी तरह बचाव संभव है? संभवतः, आप कर सकते हैं, यदि आप अपने आप को सुरक्षा के सभी मौजूदा साधनों से घेर लेते हैं और प्रक्रियाओं का प्रबंधन करने के लिए विशेषज्ञों की एक विशाल टीम को नियुक्त करते हैं। हालांकि, यह स्पष्ट है कि वास्तव में यह असंभव है: सूचना सुरक्षा के लिए बजट अनंत नहीं है, और घटनाएं फिर भी घटित होंगी। और जब से वे होंगे, तब आपको उनके लिए तैयार करने की आवश्यकता है!

इस लेख में, हम मैलवेयर घटनाओं की जांच के लिए विशिष्ट परिदृश्यों को साझा करेंगे, हमें बताएंगे कि लॉग में क्या देखना है, और एक जांच की सफलता की संभावना बढ़ाने के लिए सूचना सुरक्षा उपकरणों को कॉन्फ़िगर करने के तरीके पर तकनीकी सिफारिशें दें।



मैलवेयर से संबंधित एक घटना का जवाब देने की क्लासिक प्रक्रिया में चरणों का पता लगाना, नियंत्रण, पुनर्प्राप्ति आदि शामिल हैं, हालांकि, आपकी सभी क्षमताएं वास्तव में, तैयारी के चरण में निर्धारित की जाती हैं। उदाहरण के लिए, संक्रमण का पता लगाने की दर सीधे इस बात पर निर्भर करती है कि कंपनी में कितनी अच्छी तरह से ऑडिट कॉन्फ़िगर किया गया है।


क्लासिक एसएनएस हादसा प्रतिक्रिया चक्र

सामान्य शब्दों में, जांच के दौरान विश्लेषकों की कार्रवाई इस प्रकार है:

1. घटना के कारणों की व्याख्या करने वाले संस्करणों की पीढ़ी (उदाहरण के लिए, "मैलवेयर को होस्ट पर स्थापित किया गया था क्योंकि उपयोगकर्ता ने इसे फ़िशिंग ईमेल से लॉन्च किया था" या "घटना एक गलत अलार्म है क्योंकि उपयोगकर्ता प्रबंधन सर्वर के रूप में एक ही होस्टिंग पर स्थित एक वैध साइट पर गया था मैलवेयर ”)।
2. प्रायिकता की डिग्री द्वारा संस्करणों का प्राथमिकताकरण। पिछली घटनाओं के आंकड़ों, घटना या प्रणाली की आलोचनात्मकता और व्यक्तिगत अनुभव के आधार पर भी संभाव्यता की गणना की जाती है।
3. प्रत्येक संस्करण का अध्ययन, उसे साबित करने या उसे नापसंद करने वाले तथ्यों की खोज।

बेशक, सभी संभावित परिकल्पनाओं के परीक्षण में कोई समझदारी नहीं है - कम से कम क्योंकि समय सीमित है। इसलिए, यहां हम मैलवेयर घटनाओं की जांच के लिए सबसे अधिक संभावना वाले संस्करणों और विशिष्ट परिदृश्यों को देखेंगे।

परिदृश्य 1

आपको संदेह है कि मैलवेयर द्वारा एक गैर-महत्वपूर्ण प्रणाली से समझौता किया गया है। सिस्टम की अनियंत्रित प्रकृति के कारण, सत्यापन के लिए थोड़ा समय आवंटित किया गया है।

सबसे पहली प्रतिक्रिया इंजीनियरों की है एक एंटीवायरस चेक चलाना। हालांकि, जैसा कि हम जानते हैं, एक एंटीवायरस चारों ओर जाना इतना मुश्किल नहीं है। इसलिए, यह निम्न अत्यधिक संभावित संस्करण को उत्पन्न करने और काम करने के लायक है: मैलवेयर एक अलग निष्पादन योग्य फ़ाइल या सेवा है।

इस संस्करण के विकास के भाग के रूप में, अनुसरण करने के लिए तीन सरल चरण हैं:

1. 4688 ईवेंट द्वारा सुरक्षा लॉग को फ़िल्टर करें - इसलिए हमें उन सभी प्रक्रियाओं की एक सूची मिलती है जो शुरू हुई थीं।
2. 7045 ईवेंट द्वारा सिस्टम लॉग को फ़िल्टर करें - इसलिए हमें सभी सेवाओं की स्थापना की एक सूची मिलती है।
3. नई प्रक्रियाओं और सेवाओं की पहचान करें जो पहले सिस्टम में नहीं थीं। इन मॉड्यूल को कॉपी करें और दुर्भावनापूर्ण कोड के लिए उनका विश्लेषण करें (कई एंटीवायरस के साथ स्कैन करें, डिजिटल हस्ताक्षर की वैधता की जांच करें, कोड को डिकंपाइल करें, आदि)।

इवेंट लॉग एक्सप्लोरर में सभी चल रही प्रक्रियाओं और सेवाओं की सूची बनाएं

सिद्धांत रूप में, यह एक काफी तुच्छ प्रक्रिया है। हालांकि, व्यवहार में इसके लिए कई तरह के नुकसान होने की संभावना है।

सबसे पहले, मानक विंडोज ऑडिट सेटअप प्रक्रिया के तथ्यों को लॉन्च नहीं करता है (इवेंट 4688), इसलिए इसे डोमेन समूह नीति में पहले से सक्षम होना चाहिए। यदि ऐसा हुआ है कि यह ऑडिट अग्रिम में शामिल नहीं किया गया था, तो आप अन्य विंडोज़ कलाकृतियों से निष्पादन योग्य फ़ाइलों की एक सूची प्राप्त करने का प्रयास कर सकते हैं, उदाहरण के लिए, एमाचे रजिस्ट्री से। आप इस रजिस्ट्री फ़ाइल से AmcaheParser उपयोगिता का उपयोग करके डेटा निकाल सकते हैं।


Amcache.hve से प्रक्रिया शुरू करने के तथ्यों को निकालने का एक उदाहरण

हालांकि, यह विधि बहुत विश्वसनीय नहीं है, क्योंकि यह सटीक जानकारी प्रदान नहीं करता है कि प्रक्रिया कब और कितनी बार शुरू हुई थी।

दूसरे, कमांड लाइन के बारे में जानकारी के बिना cmd.exe, powershell.exe, wscript.exe और अन्य दुभाषियों की लॉन्चिंग के साक्ष्य का बहुत कम उपयोग होगा, जिसके साथ प्रक्रियाएं शुरू की गई थीं, क्योंकि इसमें संभावित रूप से दुर्भावनापूर्ण स्क्रिप्ट फ़ाइल का पथ समाहित है।


स्क्रिप्ट लॉन्च किए जाने के बारे में जानकारी के बिना स्क्रिप्ट दुभाषिया चलाना

विंडोज की एक अन्य विशेषता यह है कि लॉन्च की गई प्रक्रिया की कमांड लाइन ऑडिट को अलग-अलग करके डोमेन ग्रुप पॉलिसी: कंप्यूटर कॉन्फ़िगरेशन -> नीतियां -> प्रशासनिक टेम्प्लेट -> सिस्टम -> ऑडिट प्रोसेस क्रिएशन -> कमांड लाइन को प्रोसेस क्रिएशन इवेंट में शामिल करती है । उसी समय, बल्कि लोकप्रिय विंडोज 7/2008 KB3004375 अपडेट स्थापित किए बिना कमांड लाइन को लॉग नहीं करता है , इसलिए इसे अग्रिम में डालें।

यदि ऐसा हुआ है कि आपने पहले से कुछ भी कॉन्फ़िगर नहीं किया है या अपडेट के बारे में भूल गए हैं, तो आप प्रीफच फाइलों (स्क्रिप्ट में मदद करने के लिए एक उपयोगिता ) में स्क्रिप्ट के स्थान का पता लगाने की कोशिश कर सकते हैं । वे जीवन के पहले 10 सेकंड में प्रक्रिया में भरी हुई सभी फाइलों (मुख्य रूप से DLL) के बारे में जानकारी रखते हैं। और दुभाषिया के कमांड लाइन तर्कों में निहित स्क्रिप्ट निश्चित रूप से वहां मौजूद होगी।


प्रीफ़च में "खो" कमांड लाइन तर्क खोजने का उदाहरण

लेकिन यह विधि बिल्कुल विश्वसनीय नहीं है - अगली बार जब आप प्रक्रिया शुरू करेंगे, तो प्रीफैच कैश ओवरराइट हो जाएगा।

जांच की तैयारी:

• निर्माण और प्रक्रियाओं को पूरा करने का एक उन्नत ऑडिट शामिल करें।
• प्रक्रिया कमांड लाइन तर्क लॉगिंग सक्षम करें।
• Windows 7 / Server 2008 पर अद्यतन KB3004375 स्थापित करें।

दृश्य २

परिधि राउटर पर मैलवेयर प्रबंधन सर्वर तक पहुंच दर्ज की गई थी। दुर्भावनापूर्ण सर्वर का IP पता एक मध्यम-सुरक्षा खतरे की खुफिया सदस्यता से प्राप्त किया गया था।

हमारे पिछले लेखों में से एक में, हमने कहा था कि TI विश्लेषकों ने समझौता करने वाले सर्वरों के IP पतों की सूचियों को जोड़कर पाप किया है जो एक ही समय में मैलवेयर नियंत्रण केंद्रों और वैध वेबसाइटों की मेजबानी करते हैं। यदि आपने अभी प्रतिक्रिया प्रक्रियाएं बनानी शुरू की हैं, तो पहले चरणों में ऐसे संकेतकों के उपयोग को छोड़ना बेहतर है, क्योंकि उपयोगकर्ता द्वारा एक वैध वेबसाइट में प्रवेश करने का हर प्रयास एक पूर्ण घटना की तरह दिखाई देगा।

इस तरह के अलार्म का जवाब देने के लिए विकल्पों में से एक को जांचने के लिए कम किया जा सकता है कि किस प्रक्रिया ने कनेक्शन बनाया - अगर यह एक इंटरनेट ब्राउज़र है, तो अन्य तथ्यों के अभाव में समझौता होने का संकेत देता है, इस घटना को एक गलत अलार्म माना जा सकता है।

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


HPE Arcsight Siem प्रणाली में "दुर्भावनापूर्ण आईपी पते तक पहुँच" घटना का सहसंबंध और Windows सुरक्षा लॉग में संबंधित प्रक्रिया

जांच की तैयारी

उपयोगकर्ता मशीन पर इस परिदृश्य को काम करने के लिए, आपको सुरक्षा लॉग में सभी नेटवर्क कनेक्शनों को लॉगिंग सक्षम करना चाहिए। यह फ़िल्टरिंग प्लेटफ़ॉर्म और पैकेट ड्रॉप ऑडिटिंग की ऑडिट घटनाओं के आधार पर किया जा सकता है।

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

अत्यधिक लोड किए गए सर्वर, जैसे कि डोमेन नियंत्रक, वेब-सर्वर आदि पर, आपको ऐसा नहीं करना चाहिए, लॉग बहुत तेज़ी से बह जाएगा।

परिदृश्य 3

आपके एनजी / एमएल / एंटी-एपीटी एनोमली डिटेक्शन सिस्टम की रिपोर्ट है कि 30 होस्ट एक ही अकाउंट पाने के लिए स्काउटिंग कर रहे हैं।

जब वे एक नया नेटवर्क दर्ज करते हैं, तो हमलावर आमतौर पर यह पता लगाने की कोशिश करते हैं कि इसमें कौन सी सेवाएं मौजूद हैं और कौन से खातों का उपयोग किया जाता है - यह बुनियादी ढांचे के साथ आगे की प्रक्रिया की प्रक्रिया में बहुत मदद करता है। विशेष रूप से, यह जानकारी नेट उपयोगकर्ता / डोमेन कमांड का उपयोग करके सक्रिय निर्देशिका से प्राप्त की जा सकती है।

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

1. एक ही AD ऑब्जेक्ट्स के लिए 30 होस्ट्स पर इंटेलिजेंस तय है क्योंकि नेट वैध उपयोगकर्ता, व्यवस्थापक, ने नेट कमांड लॉन्च किया है।
2. एक ही AD ऑब्जेक्ट्स के लिए 30 होस्ट्स पर इंटेलिजेंस तय है, क्योंकि इसने एक ही वैध सॉफ्टवेयर बनाया था।

लॉग का सांख्यिकीय विश्लेषण इन नोडल बिंदुओं (एक आम उपयोगकर्ता या प्रक्रिया) को खोजने में मदद करेगा। हमने पिछले लेख में DNS सर्वर लॉग्स पर लागू किए गए तरीके से इस विधि का प्रदर्शन किया। हालाँकि, ऐसे प्रभावी जांच विधियों का उपयोग नहीं किया जा सकता है यदि डेटा का संग्रहण अग्रिम में व्यवस्थित नहीं किया गया था।

जांच की तैयारी

सामान्य नेटवर्क सेवाओं के लॉग से कम से कम निम्नलिखित डेटा के दीर्घकालिक भंडारण को व्यवस्थित करना आवश्यक है:

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

परिदृश्य 4

आपके डोमेन से छेड़छाड़ की गई है, और आप चिंतित हैं कि एक हमलावर DCShadow तकनीक का उपयोग करके बुनियादी ढांचे में एक पायदान हासिल कर सकता है।

मान लीजिए एक भयानक बात हुई: आप पाते हैं कि डोमेन व्यवस्थापक खाते से छेड़छाड़ की गई है।

इस तरह की घटना पर प्रतिक्रिया देना काम की एक बहुत बड़ी परत शामिल है, जिसमें इस खाते के तहत किए गए सभी कार्यों का विश्लेषण शामिल है। इस जांच का हिस्सा केवल डोमेन नियंत्रक लॉग का उपयोग करके किया जा सकता है। उदाहरण के लिए, आप केर्बरोस टिकट जारी करने से जुड़ी घटनाओं का अध्ययन कर सकते हैं कि यह समझने के लिए कि वे इस खाते में कहाँ से गए थे। या अत्यधिक विशेषाधिकार प्राप्त समूहों (समान डोमेन प्रशासक) की संरचना बदल गई है, तो यह जांचने के लिए आप महत्वपूर्ण AD ऑब्जेक्ट्स के परिवर्तन से जुड़ी घटनाओं का विश्लेषण कर सकते हैं। स्वाभाविक रूप से, यह सब एक पूर्व-कॉन्फ़िगर ऑडिट की आवश्यकता है।

हालाँकि, एक समस्या है कि डोमेन व्यवस्थापक अधिकारों के साथ एक हमलावर DCShadow तकनीक का उपयोग करके AD ऑब्जेक्ट्स को संशोधित कर सकता है, जो डोमेन नियंत्रकों के बीच प्रतिकृति तंत्र पर आधारित है।

इसका सार यह है कि हमलावर स्वयं एक डोमेन नियंत्रक प्रतीत होता है, AD में परिवर्तन करता है और फिर इन परिवर्तनों को वैध नियंत्रकों के साथ बदलता है (सिंक्रनाइज़ करता है), इस प्रकार उन पर कॉन्फ़िगर किए गए ऑब्जेक्ट परिवर्तनों की ऑडिट को दरकिनार कर देता है। इस तरह के हमले का परिणाम एक उपयोगकर्ता को डोमेन व्यवस्थापक या ट्रिक बाइंडिंग के समूह में जोड़कर SID इतिहास विशेषता को बदलकर या AdminSDHolder ACL ऑब्जेक्ट को संशोधित करके किया जा सकता है।

AD में अप्रयुक्त परिवर्तनों की उपस्थिति के बारे में संस्करण की जांच करने के लिए, आपको नियंत्रकों के प्रतिकृति लॉग का अध्ययन करने की आवश्यकता है: यदि डोमेन नियंत्रक के अलावा अन्य आईपी पते प्रतिकृति में शामिल थे, तो आप आत्मविश्वास से कह सकते हैं कि हमला सफल था।


AD प्रतिकृति से अज्ञात डोमेन नियंत्रक निकाल रहा है

जांच की तैयारी:

• एक समझौता किए गए खाते द्वारा किए गए कार्यों की जांच करने के लिए, आपको पहले से शामिल होना चाहिए:
  
  • खाता इनपुट और आउटपुट का ऑडिट करना और केर्बरोस टिकट जारी करना (एडवांस्ड ऑडिट सेटिंग में अकाउंट लॉगॉन श्रेणी)।
  • खातों और समूहों ( खाता प्रबंधन श्रेणी) में परिवर्तनों का ऑडिट करना।
• संभव DCShadow हमलों से संबंधित संस्करणों की जांच करने के लिए:
  
  • निर्देशिका सेवा प्रतिकृति की क्रिया ऑडिट सक्षम करें।
  • ईवेंट 4928/4929 के दीर्घकालिक भंडारण को व्यवस्थित करें, जिसमें ईवेंट स्रोत एक वैध डोमेन नियंत्रक (DCShadad विशेषता) नहीं है।

निष्कर्ष

इस लेख में, हमने निवारक तैयारी के लिए सूचना सुरक्षा घटनाओं और उपायों की जांच के लिए कुछ विशिष्ट परिदृश्यों के बारे में बात की। यदि आप इस विषय में रुचि रखते हैं और आप आगे जाने के लिए तैयार हैं, तो मेरा सुझाव है कि आप इस दस्तावेज़ पर ध्यान दें, जिसमें यह वर्णन किया गया है कि विंडोज घटनाओं में आप लोकप्रिय हैकिंग तकनीकों के उपयोग के निशान पा सकते हैं।

मैं साइबर सिक्योरिटी कंपनी के हालिया अध्ययन के एक उद्धरण के साथ समाप्त करना चाहूंगा:

"अधिकांश भाग के लिए, सूचना सुरक्षा के रूसी निर्देशक निराशावादी उत्तर देने के लिए करते हैं [शोध प्रश्नों के लिए]। इस प्रकार, आधे (48%) का मानना ​​है कि बजट किसी भी तरह से नहीं बदलेगा, और 15% सोचते हैं कि धन कम हो जाएगा। ”

मेरे लिए व्यक्तिगत रूप से, यह एक संकेत है कि नए साल में शेष बजट बेहतर तरीके से नए ज़माने के SZI जैसे मशीन लर्निंग डिटेक्टरों, अगली पीढ़ी के IDS, आदि को खरीदने में खर्च नहीं किया जाता है, लेकिन उन SZI को ठीक से ट्यून करने पर जो पहले से मौजूद हैं। और सबसे अच्छा SZI विंडोज लॉग को सही ढंग से कॉन्फ़िगर किया गया है। IMHO।