बिना Windows मशीन के .evtx फ़ाइलें पढ़ें
इवेंट लॉग यात्रा करते हैं: किसी ज़ब्त लैपटॉप से, किसी डिस्क छवि से बाहर, किसी ऐसे क्लाइंट द्वारा निर्यात किए गए जिसका सर्वर पहले ही फिर से बनाया जा चुका है। जो आता है वह एक .evtx फ़ाइल होती है, और जो टूल उसे खोलता है — Event Viewer — केवल Windows पर मौजूद है और जो कुछ आप देखते हैं उसका आधा हिस्सा उस मशीन की DLL से प्रस्तुत करता है जिसने लॉग लिखा था। यह मार्गदर्शिका बताती है कि एक .evtx में वास्तव में क्या होता है, ब्राउज़र-स्थानीय EVTX दर्शक के साथ उसे कहीं भी कैसे ट्राइएज करें, और वे चार Event ID जो अधिकांश पहले प्रश्नों का उत्तर देते हैं।
अंतिम अपडेट:
लॉग कभी उस मशीन पर नहीं होता जिस पर आप बैठे हैं
पैटर्न हमेशा एक ही होता है। कुछ हुआ — एक संदिग्ध समझौता, एक लॉकआउट तूफ़ान, एक सेवा जो 03:00 पर मर गई — और सबूत एक Windows इवेंट लॉग है जिसे किसी ने निर्यात किया, जिसकी छवि बनाई या जिसे किसी ऐसी मशीन से कॉपी किया जिसे आप बूट नहीं कर सकते, जिसमें लॉग इन नहीं कर सकते, या जिसे छूने का लाइसेंस आपके पास नहीं है। आपकी अपनी मशीन एक Mac है, एक Linux वर्कस्टेशन है या एक लॉक किया हुआ कॉर्पोरेट लैपटॉप है जिसमें कोई Windows VM नज़र नहीं आता। Event Viewer मदद के लिए नहीं आने वाला।
अच्छी ख़बर यह है कि एक .evtx फ़ाइल एक प्रलेखित, आत्मनिर्भर बाइनरी फ़ॉर्मैट है। Event Viewer आपको किसी रिकॉर्ड के बारे में जो कुछ दिखाता है — नीचे बताए गए एक महत्वपूर्ण अपवाद के साथ — वह सब फ़ाइल के अंदर है, और एक उचित पार्सर उसे कहीं भी पढ़ सकता है। इस साइट का EVTX दर्शक उस पार्सर (Rust evtx crate, जिसे WebAssembly में संकलित किया गया है) को आपके ब्राउज़र टैब में चलाता है, क्योंकि इवेंट लॉग उपयोगकर्ताओं, मशीनों और IP पतों के नाम बताते हैं और उन्हें किसी यादृच्छिक कनवर्टर साइट पर अपलोड नहीं किया जाना चाहिए, ठीक वैसे ही जैसे किसी पैकेट कैप्चर को नहीं किया जाना चाहिए। आगे जो है वह कार्य-विधि है, टूल की नियमावली नहीं: क्या देखना है, किस क्रम में, और फ़ील्ड आपको क्या बताएँगे और क्या नहीं।
एक .evtx फ़ाइल के अंदर वास्तव में क्या होता है
एक .evtx फ़ाइल एक 4096-बाइट हेडर होती है जिसके बाद 64 KB खंडों का एक क्रम आता है। हर खंड में इवेंट रिकॉर्ड की एक श्रृंखला होती है, और हर रिकॉर्ड बाइनरी XML (BinXML) के रूप में संग्रहीत होता है: एक System ब्लॉक जिसे ऑपरेटिंग सिस्टम भरता है, साथ में प्रदाता का अपना पेलोड EventData या UserData के रूप में। एक रिकॉर्ड खोलें और आपको फ़ील्ड मिलते हैं, गद्य नहीं — EventID 4625, एक टाइमस्टैम्प, एक चैनल, और IpAddress, TargetUserName और LogonType जैसे नामित मान। वे फ़ील्ड ही सबूत हैं। वे ही वह सब भी हैं जो किसी विदेशी मशीन पर कोई पार्सर ईमानदारी से आपको दे सकता है।
यह रहा वह अपवाद, और यह इस मार्गदर्शिका की हर दूसरी चीज़ को आकार देता है: Event Viewer जो वाक्य दिखाता है — “एक खाता लॉग ऑन करने में विफल रहा” — वह फ़ाइल में नहीं होता। Windows उसे देखने के समय उन संदेश DLL से प्रस्तुत करता है जो हर प्रदाता से जुड़ी होती हैं और उस मशीन पर रहती हैं जिसने लॉग लिखा था। इसीलिए डेटा मान कभी-कभी %%14592 जैसे दिखते हैं: वे एक संदेश तालिका के संदर्भ होते हैं जिसे फ़ाइल अपने साथ नहीं ले जाती। दूसरी मशीन पर कोई दर्शक आपको हर वह फ़ील्ड दिखा सकता है जो इवेंट ने रिकॉर्ड किया था, और उसका कच्चा XML ठीक वैसे जैसा वह संग्रहीत है — लेकिन कोई टूल जो किसी और के .evtx के लिए पॉलिश किया हुआ संदेश पाठ प्रस्तुत करे, वह उसे अपनी DLL प्रतियों से फिर से बना रहा होता है या उसका अनुमान लगा रहा होता है। पहले फ़ील्ड, सबसे बाद में गद्य — यही ईमानदार क्रम है।
संख्याएँ उद्धृत करने से पहले जानने लायक एक और संरचनात्मक तथ्य: फ़ाइल के खंड स्वतंत्र होते हैं। किसी डिस्क छवि से उकेरा गया, या किसी मरती हुई ड्राइव से कॉपी किया गया लॉग, अक्सर ऐसे अलग-अलग खंड रखता है जो अब पार्स नहीं होते। एक अच्छा पाठक हर क्षतिग्रस्त खंड को उसके बाइट ऑफ़सेट के साथ बताता है और उसके आसपास की हर चीज़ पढ़ता है। इस बिंदु पर चुप्पी — कोई टूल जो छोटा लॉग लौटाए और कुछ न कहे — यही वह तरीका है जिससे रिकॉर्ड चुपचाप किसी जाँच से गायब हो जाते हैं।
System ब्लॉक से शुरुआत करें
हर रिकॉर्ड का System ब्लॉक एक ही ढाँचा रखता है: Provider (किस घटक ने उसे लिखा), EventID (क्या हुआ, उस प्रदाता की क्रमांकन प्रणाली में), Level (1 गंभीर से 5 वर्बोस तक, उन इवेंट के लिए 0 जिनका कोई स्तर नहीं होता), Channel (Security, System, Application, और Microsoft-Windows-* के तहत सैकड़ों परिचालन लॉग), Computer, एक UTC टाइमस्टैम्प, और EventRecordID। ट्राइएज पूरे लॉग को उस ढाँचे में क्रमबद्ध करके शुरू होता है: कितने रिकॉर्ड, किस समय सीमा में फैले हुए, किन चैनलों से, किन Event ID का प्रभुत्व। एक Security लॉग जो 80% एक ही Event ID हो, आम तौर पर उसी एक चीज़ की कहानी होता है — फ़ायरवॉल का फ़ैसले लेना, किसी सेवा का लूप में प्रमाणीकरण करना — और सारांश आपको एक भी रिकॉर्ड पढ़ने से पहले यह बता देता है।
जब आप किसी रिकॉर्ड का संदर्भ दें, तो System ब्लॉक से EventRecordID उद्धृत करें। जो फ़ाइलें उकेरी गईं, चुनी गईं या फिर से निर्यात की गईं, उनके रिकॉर्ड हेडर उस टूल द्वारा फिर से क्रमांकित किए जा सकते हैं जिसने उन्हें बनाया था, जबकि System ब्लॉक वह ID बनाए रखता है जो मशीन ने मूल रूप से सौंपा था — “इस अंश का रिकॉर्ड 7” और “मूल लॉग में EventRecordID 319457858” के बीच का अंतर उस क्षण मायने रखता है जब कोई आपके निष्कर्ष को दोहराने की कोशिश करता है। टाइमस्टैम्प भी उसी सावधानी के हकदार हैं: फ़ाइल के अंदर वे UTC होते हैं, हमेशा। Event Viewer उन्हें उस मशीन के स्थानीय समय में बदल देता है जो लॉग खोलती है, इसीलिए एक ही रिकॉर्ड के दो स्क्रीनशॉट घंटों के अंतर से असहमत हो सकते हैं। रिपोर्ट के लिए UTC चुनें और ऐसा कहें भी।
चार Event ID जो अपनी जगह कमाते हैं
1102 — ऑडिट लॉग साफ़ किया गया था। Security लॉग अपने मिटाए जाने को खुद रिकॉर्ड करता है, नए लॉग में पहले इवेंट के रूप में। उसके फ़ील्ड उस उपयोगकर्ता का नाम बताते हैं जिसने उसे साफ़ किया था। किसी घटना में, एक 1102 सबूत भी है और सीमा भी: उस लॉग में उससे पहले की हर चीज़ आपके पास मौजूद फ़ाइल से चली गई है, और साफ़ किया जाना खुद एक ऐसा तथ्य है जो रिपोर्ट में एक पंक्ति का हकदार है। यदि किसी लॉग का सबसे पहला रिकॉर्ड आपकी रुचि की समय-सीमा के भीतर के टाइमस्टैम्प वाला 1102 हो, तो यह बात इससे पहले कहें कि कोई पहले के इवेंट की अनुपस्थिति पर कोई सिद्धांत बनाए।
4624 और 4625 — लॉगऑन, सफल और विफल। ये खाता जाँचों के मेहनतकश हैं। जो फ़ील्ड मायने रखते हैं वे हैं TargetUserName, IpAddress और सबसे बढ़कर LogonType: 3 एक नेटवर्क लॉगऑन है, 10 Remote Desktop है, 2 एक इंटरैक्टिव कंसोल लॉगऑन है, 7 एक अनलॉक है। एक ब्रूट-फ़ोर्स पैटर्न एक पते से एक खाते के विरुद्ध 4625 के एक झुंड के रूप में पढ़ा जाता है, जिसके बाद — जो क्षण मायने रखता है — एक 4624 आता है। एक अकेला 4625 एक टाइपो है; क्रम का आकार ही संकेत है, इसीलिए आप स्क्रॉल करने के बजाय छाँटते और गिनते हैं।
4688 — एक प्रक्रिया बनाई गई थी। जब ऑडिट नीति उसे रिकॉर्ड करती है, तो हर 4688 नई प्रक्रिया (NewProcessName), उसे लॉन्च करने वाले खाते और अक्सर मूल प्रक्रिया का नाम बताता है — “इस मशीन पर क्या चला, और कब” की कच्ची सामग्री। दो सावधानियाँ आपको ईमानदार रखती हैं: 4688 केवल तभी मौजूद होता है यदि स्रोत मशीन पर “Audit Process Creation” सक्षम था (इसकी अनुपस्थिति इस बारे में कुछ साबित नहीं करती कि क्या चला), और कमांड-लाइन कैप्चर फिर एक अलग सेटिंग है। एक समृद्ध 4688 निशान को उपहार की तरह बरतें, हक की तरह नहीं।
ये चार एक शुरुआती समूह हैं, कोई पाठ्यक्रम नहीं — 4624 का विशेष-लॉगऑन भाई 4672, स्पष्ट-क्रेडेंशियल लॉगऑन 4648, और System लॉग में सेवा स्थापना 7045 आम अगले पड़ाव हैं। लेकिन पहले दिन के प्रश्नों का एक उल्लेखनीय हिस्सा — क्या लॉग मिटाया गया था, कौन अंदर आया, कहाँ से, और उन्होंने क्या चलाया — केवल 1102, 4624, 4625 और 4688 से ही उत्तरित हो जाता है।
फ़ील्ड आपको क्या नहीं बता सकते
अनुपस्थिति के बारे में अनुशासन ही लॉग कार्य का अधिकांश हिस्सा है। फ़ाइल आपको वे इवेंट नहीं दिखा सकती जो स्रोत मशीन ने कभी रिकॉर्ड ही नहीं किए: ऑडिट नीति तय करती है कि क्या मौजूद है, और डिफ़ॉल्ट रूप से कॉन्फ़िगर की गई मशीन किसी अन्वेषक की उम्मीद से कहीं कम लॉग करती है। वह आपको संदेश पाठ नहीं दिखा सकती, जैसा ऊपर बताया गया — एक %% संदर्भ किसी ऐसी मशीन पर मौजूद स्ट्रिंग का सूचक है जो आपके पास नहीं है। वह, अपने आप में, छेड़छाड़ या उसकी अनुपस्थिति को साबित नहीं कर सकती: रिकॉर्ड ID में अंतराल ईमानदार उकेरी गई फ़ाइलों में भी आते हैं और साफ़ की गई फ़ाइलों में भी, इसीलिए झुकने लायक संकेत स्पष्ट 1102 रिकॉर्ड है, कोई अंतराल नहीं।
और एक लॉग एक गवाह होता है। टाइमस्टैम्प स्रोत मशीन की घड़ी से आते हैं, जो गलत हो सकती थी; खाते उन नामों के तहत आते हैं जिन्हें मशीन जानती थी; किसी नेटवर्क लॉगऑन का IP वह पता होता है जो मशीन ने देखा था, NAT और VPN समेत। फ़ील्ड ठीक वही होते हैं जो मशीन ने रिकॉर्ड किया था — उससे कम नहीं, और अनुशासन यह याद रखने में है: उससे अधिक नहीं।
पाँच मिनट की ट्राइएज दिनचर्या
पहला मिनट: फ़ाइल को EVTX दर्शक में खोलें और किसी भी रिकॉर्ड से पहले सारांश पढ़ें — कुल गिनती, समय सीमा, चैनल, और शीर्ष Event ID। दर्शक जिन खंडों को अपठनीय बताए, उन्हें उनके ऑफ़सेट के साथ नोट करें; वह चेतावनी शुरुआत से ही आपकी टिप्पणियों में होनी चाहिए, बाद में पादटिप्पणी के रूप में नहीं।
दूसरा मिनट: 1102 की जाँच करें। यदि लॉग साफ़ किया गया था, तो आपके दृष्टिकोण के बारे में सब कुछ बदल जाता है, और साफ़ करने का समय और खाता आपके पहले पक्के तथ्य होते हैं। तीसरा मिनट: 4625 को छाँटें और आकार देखें — प्रति खाता गिनती, प्रति स्रोत पता गिनती। उसी पते से उसी खाते के लिए 4624 के बाद आने वाला झुंड ही निष्कर्ष है; ठीक-ठीक टाइमस्टैम्प नोट करें। चौथा मिनट: संदिग्ध समय-सीमा तय हो जाने पर, उस सीमा के भीतर 4688 (और, यदि दूरस्थ पहुँच प्रश्न में हो, तो 4624 प्रकार 10) को छाँटें और सूची बनाएँ कि क्या चला और कौन लॉग ऑन हुआ। पाँचवाँ मिनट: छाँटे गए रिकॉर्ड को JSON या CSV के रूप में निर्यात करें और जब संख्याएँ आपके सामने हों तब अनुच्छेद लिखें — रिकॉर्ड ID, UTC समय, खाता, पते। निर्यात आपका कार्य-पत्र है; अनुच्छेद, अपठनीय खंडों और संदेश-पाठ सीमा के बारे में चेतावनी के साथ, सुपुर्दगी योग्य परिणाम है।
वह दिनचर्या किसी जाँच को बंद नहीं करती। वह एक विदेशी बाइनरी फ़ाइल को पाँच उद्धृत तथ्यों और एक बचाव योग्य अगले प्रश्न में बदल देती है, उस मशीन पर जो भी आपके सामने हो — जो कि ट्राइएज का अधिकांश हिस्सा हमेशा से यही होता है।
अक्सर पूछे जाने वाले प्रश्न
मैंने Event Viewer से लॉग को CSV या XML के रूप में निर्यात किया। क्या मैं इसके बजाय उसे पढ़ सकता हूँ?
वे निर्यात एक अलग, घटिया चीज़ होते हैं। एक CSV निर्यात हर इवेंट को उन स्तंभों में समतल कर देता है जो Event Viewer ने संयोग से दिखाए थे और अधिकांश संरचित EventData को फेंक देता है — वे फ़ील्ड जिन पर ट्राइएज वास्तव में काम करता है। यदि आपके पास अभी भी स्रोत तक पहुँच है, तो “Save All Events As…” से फिर से निर्यात करें और .evtx चुनें; यदि आपके पास केवल CSV है, तो कोई स्प्रेडशीट आपको उसके बारे में किसी भी .evtx टूल से अधिक बताएगी, क्योंकि किसी भी संरचित अर्थ में वह अब कोई इवेंट लॉग नहीं रह गया है।
यहाँ के टाइमस्टैम्प Event Viewer में लिए गए स्क्रीनशॉट से क्यों अलग हैं?
क्योंकि Event Viewer बदलाव करता है। किसी .evtx फ़ाइल के भीतर के टाइमस्टैम्प UTC में संग्रहीत होते हैं; Event Viewer उन्हें लॉग खोलने वाली मशीन के स्थानीय समय में दिखाता है। एक ही रिकॉर्ड दो टूल में ईमानदारी से घंटों के अंतर पर दिख सकता है। इस साइट का दर्शक UTC में रहता है और स्तंभ को ऐसे ही लेबल करता है, और रिपोर्ट के लिए कार्य-नियम भी वही है: UTC उद्धृत करें, क्षेत्र का नाम बताएँ, और दोनों को एक ही समयरेखा में कभी न मिलाएँ।
मेरी फ़ाइल में रिकॉर्ड ID में अंतराल हैं। क्या लॉग के साथ छेड़छाड़ की गई थी?
केवल अंतराल यह साबित नहीं करते। रिकॉर्ड साधारण कारणों से गायब होते हैं — विफल होती डिस्क पर क्षतिग्रस्त खंड, अनाबंटित जगह से उकेरी गई फ़ाइल, कोई निर्यात जिसने एक उपसमूह चुना था — और उकेरी गई फ़ाइलों के हेडर फिर से क्रमांकित भी किए जा सकते हैं जबकि System ब्लॉक मूल ID बनाए रखते हैं। जानबूझकर साफ़ किया जाना अपना रिकॉर्ड खुद छोड़ता है: इवेंट 1102, जो नए Security लॉग की पहली प्रविष्टि के रूप में लिखा जाता है और उसे साफ़ करने वाले खाते का नाम बताता है। किसी अनुपस्थिति से कुछ भी निष्कर्ष निकालने से पहले उसे खोजें।