VPN लॉगिन और फिर रैनसमवेयर: साक्ष्य किस बात का समर्थन करते हैं
02:14 पर लॉगिन और 03:02 पर एन्क्रिप्टेड फ़ाइलें — यह जाँच के योग्य क्रम है, प्रवेश-बिंदु नहीं। प्रमाणीकरण, सत्र और होस्ट के साक्ष्य अलग रखें।
नीचे सब कुछ एक काल्पनिक रिकॉर्ड का उपयोग करता है, जिसे वास्तविक मामला बताने के बजाय एक आकृति दिखाने के लिए जोड़ा गया है। इसे एक श्रृंखला की तरह पढ़ा जाता है: 02:14 पर गेटवे प्रमाणीकरण, 02:19 पर डेस्कटॉप सत्र, 02:41 पर विशेषाधिकार प्राप्त खाते का बदलाव, और 03:02 पर मिली एन्क्रिप्टेड फ़ाइलें। पहली पंक्ति उत्तर जैसी लगती है, और रिपोर्ट अक्सर ऐसे लिखी जाती है जैसे वही उत्तर हो। लॉगिन वह घटना है जो किसी गेटवे ने दर्ज की, इस बारे में निष्कर्ष नहीं कि कोई अंदर कैसे आया, और यही अंतर तय करता है कि आप आगे क्या करेंगे।
लक्षण: उत्तर जैसा दिखने वाला लॉगिन
प्रमाणीकरण रिकॉर्ड पाने में सबसे आसान साक्ष्य हैं और अधिक अर्थ लगाने में भी सबसे आसान। वे दिखाते हैं कि सेवा ने किसी समय, किसी पते से, किसी खाते के लिए एक क्रेडेंशियल स्वीकार किया। वे यह नहीं दिखाते कि क्रेडेंशियल को कौन नियंत्रित कर रहा था, क्या गेटवे का दुरुपयोग हुआ था, या क्या खाताधारक का उपकरण पहले ही भंग हो चुका था।
तीन व्याख्याएँ उसी लॉगिन पंक्ति पर फिट बैठती हैं। किसी ने चोरी हुआ पासवर्ड इस्तेमाल किया, और गेटवे ने ठीक वही किया जिसके लिए उसे बनाया गया था। पहले भंग हो चुका लैपटॉप सामान्य रूप से ही लॉगिन हो गया। किसी असंबंधित खुली सेवा ने असली प्रवेश दिया, और VPN सत्र उसी अभिनेता की बाद की, अलग कार्रवाई है।
हर व्याख्या पर्यावरण में कहीं और अलग साक्ष्य का पूर्वानुमान लगाती है, इसलिए जाँच को उन पूर्वानुमानों को खोजना चाहिए, न कि पहली फिट बैठने वाली व्याख्या की पुष्टि। चोरी हुआ पासवर्ड असामान्य प्रमाणीकरण भूगोल या समय का पूर्वानुमान लगाता है। भंग लैपटॉप लॉगिन से पहले होस्ट कलाकृतियों का पूर्वानुमान लगाता है। असंबंधित प्रवेश-बिंदु ऐसी गतिविधि का पूर्वानुमान लगाता है जिसका गेटवे से कोई संबंध ही नहीं है।
घटनाओं को सुनाने से पहले अलग रखें
कोई भी आख्यान बनने से पहले घटनाओं को अलग-अलग लिखें, क्योंकि आख्यान समयरेखा को किसी संदिग्ध के इर्द-गिर्द सजाने का न्योता देता है। हर पंक्ति को बताना चाहिए कि वह रिकॉर्ड क्या सिद्ध करता है और अलग से, अकेले वह क्या सिद्ध नहीं कर सकता। जिस क्षण दो पंक्तियाँ एक वाक्य में मिल जाती हैं, उसी क्षण एक व्याख्या जीत चुकी होती है।
ध्यान दें कि अंतिम घटना हमलावर के बारे में नहीं, पता लगने के बारे में है। खोज का समय और भंग का समय आमतौर पर घंटों या हफ़्तों के अंतर पर होते हैं, और जो रिपोर्ट इन्हें समान मानती है वह आपके बाद आने वाले हर पाठक को भटकाएगी।
लिखें कि हर समय-चिह्न कहाँ से आया, केवल यह नहीं कि वह क्या कहता है। संग्राहक का प्राप्ति समय, घटना का समय और पता लगने का समय तीन अलग संख्याएँ हैं, और इन्हें चुपचाप एक कॉलम में सामान्य करना ही वह तरीका है जिससे समयरेखा को वह आकार मिलता है जो साक्ष्य के पास कभी नहीं था।
रिकॉर्ड केवल वहीं जोड़ें जहाँ पहचानकर्ता मेल खाते हों
रिकॉर्ड जोड़ना एक परिकल्पना है, स्वरूपण का चरण नहीं। खाते का नाम, दिया गया VPN पता, लक्ष्य होस्ट और सत्र पहचानकर्ता तब तक मेल खाने चाहिए जब तक दो पंक्तियाँ एक कहानी न बन जाएँ। साझा सार्वजनिक पता पर्याप्त नहीं है, क्योंकि वह डिज़ाइन से ही साझा होता है।
| Record source | Join key that must match | What breaks when the key is missing |
|---|---|---|
| File-share or backup record | file path and modification time | impact cannot be ordered against any session |
| Host process record, EDR or audit log | host name and process start time | the process cannot be placed inside a session |
| Session broker or remote-desktop log | session identifier and target host | the session cannot be traced back to a gateway login |
| Gateway authentication log | account name and assigned VPN address | the session cannot be followed past the gateway |
किसी प्रवेश का पीछा करते समय तालिका को नीचे से ऊपर पढ़ें, और प्रभाव का दायरा तय करते समय ऊपर से नीचे, क्योंकि दोनों प्रश्नों को विपरीत दिशाएँ चाहिए। जहाँ पहचानकर्ता सचमुच मेल खाते हैं, वहाँ यह कहें और दोनों रिकॉर्ड का हवाला दें। जहाँ नहीं मेल खाते, वहाँ अनुमान से अंतराल बंद करने के बजाय उसे दिखाई देने वाला छोड़ दें।
यहीं एक परिचित उपयोक्तानाम भी भटकाता है। वही खाता सुबह असली धारक और रात में कोई दूसरा इस्तेमाल कर सकता है, और अकेला खाता नाम उन्हें अलग नहीं कर सकता। खाते को आरोपित करें, फिर व्यक्ति को अलग से आरोपित करें, और तभी जब कोई चीज़ इसका समर्थन करे। समीक्षा में बिखरने वाली अधिकांश समयरेखाओं ने ठीक यही कदम बहुत जल्दी उठाया था।
गुम लॉग अंतराल हैं, नकारात्मक साक्ष्य नहीं
असफल पासवर्ड घटनाओं का अभाव यह सिद्ध नहीं करता कि सफल लॉगिन वैध था। वैध चोरी हुए क्रेडेंशियल एक सफल प्रमाणीकरण रिकॉर्ड बनाते हैं और कोई विफलता नहीं, और यही क्रेडेंशियल चोरी को आकर्षक बनाता है।
इसी तरह, आज बंद पोर्ट आज के बारे में कुछ कहता है। वह इस बारे में कुछ नहीं कहता कि वह सेवा तब खुली थी या नहीं, तब कमज़ोर थी या नहीं, या उसने हमला ढोया था या नहीं। ऐतिहासिक कॉन्फ़िगरेशन और सेवा के साक्ष्य ही उस अंतराल को बंद करने का एकमात्र तरीका हैं।
रिपोर्ट में अंतराल को स्पष्ट रूप से लिखें। “उस अवधि के लिए हमारे पास कोई रिकॉर्ड नहीं है” एक बचाव योग्य वाक्य है; “और कुछ नहीं हुआ” नहीं है, और यह आपको वापस सुनाया जाएगा। अंतरालों के मालिक भी होते हैं: उस प्रणाली का नाम लें जिसे रिकॉर्ड बनाना चाहिए था और क्यों नहीं बनाया। वह पंक्ति चूक को सुधार-मद में बदल देती है।
निष्कर्ष उस स्तर पर लिखें जिसका साक्ष्य समर्थन करते हैं
संरक्षण, अवरोधन और पुनर्प्राप्ति को घटना-स्वामी के माध्यम से समन्वित करें, उन्हें दरकिनार करके नहीं। CISA का तकनीकी मार्गदर्शन इस बात पर ज़ोर देता है कि सुधार इससे पहले कि उपलब्ध बची चीज़ों को बदल दे, प्रासंगिक कलाकृतियाँ और लॉग एकत्र किए जाएँ, और यह क्रम किसी भी एक औज़ार से अधिक मायने रखता है।
अंतराल बंद करने के लिए जीवित उपकरण पर संदिग्ध शोषण दोबारा चलाना उस जोखिम के लायक नहीं है जो वह जोड़ता है। जो परीक्षण दिखाता है कि हमला काम कर सकता था, वह इस बात का साक्ष्य नहीं कि उसने काम किया, और इन दो कथनों के बीच का अंतर ही इस अभ्यास का पूरा अनुशासन है।
चार सूचियों के साथ समाप्त करें: क्या देखा गया, रिकॉर्ड किन संबंधों का समर्थन करते हैं, क्या परिकल्पना रह जाता है, और कौन-से रिकॉर्ड उपलब्ध नहीं हैं। “घटना के दौरान एक VPN खाता इस्तेमाल हुआ था” दूसरी सूची में आता है जब रिकॉर्ड इसका समर्थन करते हैं। “VPN ने रैनसमवेयर पैदा किया” कहीं नहीं आता जब तक कुछ कारणता सिद्ध न करे।