WS-017, जो एक डोमेन-जुड़ा वर्कस्टेशन है, एक असामान्य अकाउंट के तहत powershell.exe शुरू होने पर अलर्ट देता है। शुरुआती जांच में संदिग्ध स्क्रिप्टिंग की पुष्टि होती है, लेकिन जांच वहीं रुक जाती है; इसमें उस ‘पर्सिस्टेंस मैकेनिज्म’ (लगातार बने रहने वाले तरीके) का पता नहीं चल पाता जो PowerShell प्रोसेस के बंद होने के बाद भी बना रहता है। हमलावर को वर्कस्टेशन पर किसी नई कमज़ोरी (vulnerability) की ज़रूरत नहीं थी। उन्हें बस एक इस्तेमाल करने लायक डोमेन अकाउंट और एक होस्ट से अपना काम करवाने के तरीके की ज़रूरत थी।
डिफेंडर (सुरक्षा करने वाले) के सामने सवाल यह है कि क्या PowerShell अलर्ट एक अलग-थलग घटना थी या किसी बड़ी प्रक्रिया का एक हिस्सा। अगले सात लेसन में, हम WS-017 पर मौजूद रिकॉर्ड्स को एक ऐसी टाइमलाइन में बदलेंगे जिसे साबित किया जा सके, यह पता लगाएंगे कि क्या बदला, और तय करेंगे कि सबूत किस तरह की प्रतिक्रिया का समर्थन करते हैं। एक ठोस निष्कर्ष में होस्ट, अकाउंट, एक्शन, समय और उस आर्टिफैक्ट (सबूत) का ज़िक्र होता है जो निष्कर्ष का समर्थन करते हैं, न कि सिर्फ़ अलर्ट लेबल पर भरोसा किया जाता है।
सबसे आसान मामला एक ऐसी घटना है जिसमें ACME\svc_backup को WS-017 पर 09:24 बजे powershell.exe शुरू करते हुए दिखाया गया है। वह रिकॉर्ड यह साबित करता है कि उस ‘प्रिंसिपल’ (अकाउंट/यूज़र) के तहत एक प्रोसेस शुरू हुआ था। यह यह साबित नहीं करता कि अकाउंट होस्ट तक कैसे पहुँचा, कौन सी स्क्रिप्ट चली, क्या ‘पर्सिस्टेंस’ बनाया गया, या क्या प्रोसेस सफल रहा। बाद का हर आर्टिफैक्ट इनमें से किसी एक छोटे सवाल का जवाब देता है।
जांच का नियम
हर अलर्ट को शुरुआती बिंदु मानें। दायरा, कारण या असर बताने से पहले होस्ट-स्पेसिफिक सबूतों से इसके दावे की पुष्टि करें।
गैर-ज़रूरी रिकॉर्ड्स से गलत कहानी न बने, इसके लिए हर लैब में एक जैसी तय सीमाएँ इस्तेमाल की जाती हैं। होस्ट WS-017 है, जो ACME.LOCAL डोमेन से जुड़ा है। इसका अपेक्षित इंटरैक्टिव यूज़र ACME\j.smith है। संदिग्ध प्रिंसिपल ACME\svc_backup है, जो एक सर्विस अकाउंट है; यूज़र वर्कस्टेशन पर इसके इस्तेमाल के लिए स्पष्टीकरण की ज़रूरत है। घटना का समय 2026-09-14 को स्थानीय समय के अनुसार 09:10 से 10:05 के बीच है।
ये तय बातें हमें सबूतों को आपस में जोड़ने में मदद करती हैं, बिना यह माने कि हर घटना नुकसान पहुँचाने वाली (malicious) है। एक सिक्योरिटी लॉग रिकॉर्ड SubjectUserName जैसे फ़ील्ड के ज़रिए प्रिंसिपल की पहचान कर सकता है और LogonType के ज़रिए सेशन के प्रकार की पहचान कर सकता है। प्रोसेस इमेज पाथ, रजिस्ट्री पाथ और सर्विस कॉन्फ़िगरेशन, सभी तभी सार्थक होते हैं जब उन्हें WS-017 और इस समय-सीमा से जोड़ा जाए। अगर किसी रिकॉर्ड में किसी दूसरे होस्ट का नाम है या वह तय समय-सीमा (विंडो) के बाहर आता है, तो हम उसे तभी रखते हैं जब सबूतों से सीधा संबंध साबित हो।
इस मामले में ‘लोकल एडमिनिस्ट्रेटर्स ग्रुप’ एक अहम सीमा है। ACME\j.smith को एक स्टैंडर्ड यूज़र के तौर पर काम करना चाहिए, जबकि ACME\svc_backup के ज़रिए किए गए कामों में एडमिनिस्ट्रेटिव अधिकार हो सकते हैं। उसी एग्जीक्यूटेबल का जांच के नज़रिए से अलग मतलब होता है जब वह ऐसे अकाउंट के तहत चलता है जो सर्विस इंस्टॉल कर सकता है, सिस्टम-वाइड रजिस्ट्री कीज़ लिख सकता है या सिक्योरिटी सेटिंग्स बदल सकता है।
केस की सीमा डोमेन आइडेंटिटी, लोकल प्रिविलेज सीमा और घटना की समय-सीमा (इंसिडेंट विंडो) को एक ही नज़रिए में जोड़ती है:
यह डायग्राम बाद के हर सवाल के लिए दायरा तय करता है। हम बताए गए 55 मिनट के दौरान WS-017 पर गतिविधि की जांच करते हैं, और दायरा तभी बढ़ाते हैं जब कोई आर्टिफैक्ट उस सीमा से आगे की ओर इशारा करता है।
एक बार केस का दायरा तय हो जाने के बाद, सबूत के स्रोतों को उस सवाल के आधार पर चुना जाना चाहिए जिसका वे जवाब दे सकते हैं, न कि इसलिए कि कोई लॉग चैनल ज़्यादा भरोसेमंद लगता है। Windows Event Log ऑपरेटिंग-सिस्टम और सुरक्षा गतिविधियों को रिकॉर्ड करता है, जबकि Sysmon कॉन्फ़िगर किए जाने पर विस्तृत एंडपॉइंट टेलीमेट्री जोड़ता है। रजिस्ट्री उस कॉन्फ़िगरेशन को सुरक्षित रखती है जो किसी प्रोसेस के खत्म होने के बाद भी बनी रह सकती है। कोई भी एक स्रोत पूरी घटनाक्रम को साबित नहीं करता है।
WS-017 के लिए, बाद की लैब में सबूतों के चार समूहों का इस्तेमाल किया जाएगा:
Microsoft-Windows-Sysmon/Operational (जब Sysmon ने उन्हें रिकॉर्ड किया हो)।Microsoft-Windows-PowerShell/Operational।HKLM और HKCU रजिस्ट्री हाइव्स।7045 जैसा सिस्टम इवेंट यह रिकॉर्ड करता है कि Service Control Manager ने एक सर्विस इंस्टॉल की है, जिसमें सर्विस का नाम, इमेज पाथ, स्टार्ट टाइप और सर्विस अकाउंट शामिल हैं। अकेले 7045 से सर्विस बनने का पता चलता है, न कि गलत इरादे का। हमें पाथ और अकाउंट की तुलना अपेक्षित एडमिनिस्ट्रेशन से करनी चाहिए, और फिर आस-पास के लॉग-ऑन और प्रोसेस के सबूतों को आपस में जोड़कर देखना चाहिए। अगर कोई सर्विस बनाई गई थी लेकिन उसका एग्जीक्यूटेबल पाथ इकट्ठा नहीं किया गया था या संबंधित ऑडिट स्रोत मौजूद नहीं है, तो जांच में एक ऐसी कमी (ब्लाइंड स्पॉट) रह जाती है जिसे स्पष्ट रूप से बताया जाना चाहिए।
सबूत के स्रोत कवरेज, फ़ील्ड और विफलता के तरीकों (फ़ेलियर मोड) में अलग-अलग होते हैं: