जेएसओसी सीईआरटी, या अनबनबल फोरेंसिक के जीवन की कुछ कहानियाँ

हम JSOC CERT पर घटनाओं की जांच कर रहे हैं। सामान्य तौर पर, जेएसओसी में सभी 170 लोग जांच कर रहे हैं, लेकिन सबसे अधिक तकनीकी रूप से चुनौतीपूर्ण मामले सीईआरटी विशेषज्ञों के हाथों में आते हैं। उदाहरण के लिए, एक मैलवेयर के निशान का पता लगाने के लिए अगर एक हमलावर ने सफाई की है? एक ऐसे "जादूगर" को कैसे खोजें, जिसने महत्वपूर्ण व्यावसायिक दस्तावेजों को एक फ़ाइल सर्वर से हटा दिया है जिस पर लॉगिंग ठीक से कॉन्फ़िगर नहीं है? खैर, मिष्ठान के लिए: एक हमलावर को नेटवर्क से बिना भेद किए दर्जनों असंबद्ध डोमेन खातों से पासवर्ड कैसे मिल सकता है? विवरण, हमेशा की तरह, कट के नीचे।

साप्ताहिक जेएसओसी सीईआरटी

अक्सर हमें ग्राहक नेटवर्क के वास्तविक समझौते का मूल्यांकन करना होता है, इसके लिए हम यह करते हैं:

• हार्ड ड्राइव और मेमोरी छवियों का पूर्वव्यापी विश्लेषण,
• मैलवेयर रिवर्स इंजीनियरिंग
• यदि आवश्यक हो, समझौता और हैकिंग के निशान के संकेतक के लिए मेजबानों की निगरानी और स्कैनिंग की आपातकालीन तैनाती।

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

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

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



यह स्पष्ट है कि ऑल-ऑल चेक करने के लिए ऑपरेटिंग सिस्टम के विभिन्न घटकों (और विशेष सॉफ़्टवेयर की बहुत ज़रूरत है) की विशेषताओं के बारे में समय और गहन विशेषज्ञ ज्ञान की आवश्यकता होती है।

सक्रिय संक्रमण के लिए डिस्क की जांच कैसे सरल करें? हम जीवन हैक साझा करते हैं - इसे गतिशील रूप से (सैंडबॉक्स में) चेक किया जा सकता है, इसके लिए:

• संदिग्ध होस्ट की हार्ड ड्राइव को बिट द्वारा कॉपी करें;
• इस उपयोगिता का उपयोग करके परिणामी dd- छवि को VMDK प्रारूप में बदलें;
• वर्चुअल बॉक्स / VMware में VMDK छवि चलाएँ;
• और यातायात पर ध्यान केंद्रित करते हुए एक जीवित प्रणाली की तरह विश्लेषण करें।

लेकिन हमेशा ऐसी घटनाएं होंगी जिनके लिए विस्तृत निर्देश नहीं लिखे गए हैं और तकनीक स्वचालित नहीं हैं।

केस 1. अकाउंटेंट का इससे कोई लेना-देना नहीं है, या हमने मैलवेयर की खोज कैसे की

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

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



दुर्भाग्य से, डिस्क से ट्रोजन के शव को बहाल नहीं किया जा सका, लेकिन सुपरफच कैश में एक ही फ़ोल्डर "flaunted" से दूरस्थ प्रशासन उपयोगिता लॉन्च करने के तथ्य:



घटना के समय के साथ उनकी तुलना करते हुए, हमने यह साबित किया कि वह अकाउंटेंट नहीं था जो पैसे चुराने का दोषी था, बल्कि एक बाहरी हमलावर था।

केस 2. मेरी फाइलों को किसने डिलीट किया?

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

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

यदि आपने कभी यह जानने की कोशिश की कि किस उपयोगकर्ता ने फाइल को डिलीट किया है, तो आप संभवत: उन युक्तियों पर आए, जो सभी विंडोज लॉग में आती हैं, यदि आप उन्हें पहले से सही तरीके से कॉन्फ़िगर करते हैं (वैसे, हमने पहले से ही कुछ सुझाव दिए हैं कि कैसे लॉग कॉन्फ़िगर करें):


स्रोत

लेकिन वास्तव में, कुछ लोग फ़ाइल सिस्टम ऑडिट का संचालन करते हैं, कॉर्नियां क्योंकि बहुत सारे फ़ाइल संचालन हैं और लॉग जल्दी से फ़्री हो जाएंगे, और लॉग्स को स्टोर करने के लिए एक अलग सर्वर की आवश्यकता है ...

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

हालाँकि, फ़ाइल सिस्टम में न केवल फ़ाइलें होती हैं, बल्कि फ़ोल्डर भी होते हैं। इसके अलावा, फ़ोल्डर्स में एक विशेष विशेषता $ INDEX_ROOT है, जो फ़ोल्डर की सामग्री को बी-ट्री के रूप में वर्णित करता है। स्वाभाविक रूप से, किसी फ़ाइल को हटाने से फ़ोल्डर की विशेषता $ INDEX_ROOT बदल जाती है और इस प्रकार, विशेष रूप से $ STD_INFO की संरचना में इसकी टाइमस्टैम्प बदल जाती है। इस प्रकार, एमएफटी (मुख्य फाइल टेबल) में विसंगति द्वारा बड़ी संख्या में फ़ाइलों और फ़ोल्डरों को हटाने के लिए अनुमानित समय निर्धारित करना संभव है:



यह पता लगाने के बाद कि फाइलें लगभग डिलीट हो गईं, आप संदिग्धों के घेरे को कम करने के लिए यह पता लगाने की कोशिश कर सकते हैं कि उस समय उत्तर में कौन काम कर रहा था। निम्नलिखित तरीके दिमाग में आते हैं:

• सर्वर के लॉग से ही - EventID 4624/4625 के साथ घटनाओं से यह तब दिखाई देता है जब उपयोगकर्ता जुड़ा और डिस्कनेक्ट हो जाता है;
• डोमेन नियंत्रक लॉग द्वारा - ईवेंटआईडी 4768 आपको यह निर्धारित करने की अनुमति देता है कि किसी विशिष्ट उपयोगकर्ता ने सर्वर तक पहुंच का अनुरोध किया है;
• यातायात द्वारा - netflow / आंतरिक राउटर लॉग - आप यह पता लगा सकते हैं कि smb के माध्यम से इस सर्वर के साथ नेटवर्क पर किसने सक्रिय रूप से संचार किया है।

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

एक विधि पाई गई थी, केवल एक चीज बची थी जो आवश्यक मेजबानों से रजिस्ट्रियों को इकट्ठा करने और उनका विश्लेषण करने के लिए थी। ऐसा करने के लिए, आपको चाहिए:

• डोमेन समूह द्वारा निर्धारित किया गया था, जिनके पास फ़ोल्डर तक पहुंच थी (हमारे मामले में, लगभग 300 उपयोगकर्ता थे);
• उन सभी होस्टों से रजिस्ट्रियां एकत्र करें जिन पर इन उपयोगकर्ताओं ने काम किया (आप बस ऐसा नहीं कर सकते, आपको सीधे ड्राइव के साथ काम करने के लिए एक विशेष उपयोगिता की आवश्यकता है, उदाहरण के लिए, https://github.com/jschicht/RawCopy );
• "फ़ीड" सभी ऑटोप्सी में रजिस्ट्रियों और शेलबैग प्लग इन का उपयोग करें;
• लाभ!

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

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

केस 3. पासवर्ड मास्टर: कुछ सेकंड में (और इससे भी तेज़) "चोरी" करें

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

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

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

• बाहरी सेवा डेटा लीक
• bruteforce
• Mimikatz या समान
• keylogger
• फिशिंग
• NTLM-hash कटाई (जैसे https://github.com/CylanceSPEAR/SMBTrap ) या इसी तरह के नेटवर्क पर हमला।

हमने संस्करणों का एक गुच्छा चेक किया, लेकिन कहीं भी एक हमले का संकेत नहीं था। ऐसा नहीं है कि जांच एक गतिरोध पर थी, लेकिन आंतरिक आवाज और सामान्य ज्ञान ने सुझाव दिया कि कुछ गलत था - आपको एक कदम वापस लेने और चित्र को व्यापक रूप से देखने की आवश्यकता है।

दरअसल, पहली नज़र में, ये सभी खाते किसी भी तरह से जुड़े हुए नहीं हैं। उनके मालिक अलग-अलग, भौगोलिक रूप से अलग-अलग विभागों से हैं। आमतौर पर वे कंपनी सेवाओं के गैर-अतिव्यापी सेट का उपयोग करते हैं। यहां तक ​​कि आईटी साक्षरता का स्तर भी अलग है। हां, एक कदम पीछे काफी नहीं था - एक और की जरूरत थी।

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



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





वेब सेवा लॉग पर कुछ समय बिताने के बाद, हम सेवा पर निम्नलिखित हमलों का पता लगाने में सक्षम थे:

• Acunetix के साथ स्कैन करें
• SQLmap स्कैन
• एक पृष्ठ पर बड़ी संख्या में अनुरोध।

तीसरा हमला, पहली नज़र में, क्रूर उपयोगकर्ता लॉगिन के समान है। लेकिन ऐसा नहीं है, क्योंकि इस से सेवा संरक्षित है, कम से कम इस तथ्य से कि पासवर्ड नमक के साथ हैशेड रूप में संग्रहीत किए जाते हैं - या नहीं? इसे जल्दी से जांचना आवश्यक था।

नीचे दी गई तस्वीर पासवर्ड रीसेट सेवा की एक विशिष्ट योजना दिखाती है:



इसमें यह दिलचस्प है कि पासवर्ड हमेशा एक सुरक्षित रूप में संग्रहीत नहीं होते हैं - एक समय ऐसा होता है जब वे सार्वजनिक डोमेन में होते हैं - आवेदन खुलने के तुरंत बाद और इसके निष्पादन से पहले! एक पृष्ठ पर बड़ी संख्या में क्वेरीज़ निकली न कि बलपूर्वक और न स्कैन करने के लिए, बल्कि SQL इंजेक्शन के साथ उच्च आवृत्ति वाले प्रश्नों के लिए, जिसका उद्देश्य उनके परिवर्तन के समय पासवर्ड निकालना था।

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

इसलिए, सहयोगियों, कच्चे डेटा में तल्लीन करना और बल आपके साथ हो सकता है!