10.0.10.20 पर मौजूद एक वेब एप्लीकेशन को एनालिस्ट के लैपटॉप 10.0.10.50 से एक रिक्वेस्ट मिलती है, जबकि बाद में 10.0.30.66 से ट्रैफिक का एक बस्ट (तेज़ बहाव) दोनों इंटरनल सबनेट तक पहुँचता है। सबूत बनाने के लिए अटैकर को लॉग इन करने की ज़रूरत नहीं होती। हर पैकेट यह रिकॉर्ड करता है कि ट्रैफिक कहाँ से आया, कहाँ जा रहा था, और उसे किस प्रोटोकॉल ने पहुँचाया। डिफेंडर के सामने सवाल यह है कि कैसे एक कैप्चर किए गए सेशन से उम्मीद के मुताबिक वेब ट्रैफिक और संदिग्ध जांच (प्रोबिंग) दोनों का पता लगाया जा सकता है, बिना कैप्चर को बाइट्स की ऐसी स्ट्रीम माने जिसे पढ़ा न जा सके।
हमारी फिक्स्ड लैब में 10.0.10.0/24 पर एनालिस्ट लैपटॉप और वेब एप्लीकेशन, 10.0.10.53 पर DNS रिज़ॉल्वर, और 10.0.20.10 पर एक डेटाबेस शामिल है। एक फायरवॉल और राउटर इन नेटवर्क्स को 10.0.10.1 और 10.0.20.1 के ज़रिए जोड़ते हैं; अटैकर VM अलग से 10.0.30.66 पर मौजूद है। कैप्चर की शुरुआत DNS और वेब ट्रैफिक से होती है, और फिर इसमें अटैकर VM का दोनों इंटरनल नेटवर्क्स के एड्रेस से संपर्क करना शामिल होता है। हम पूरे कोर्स के दौरान इन्हीं एड्रेस पर वापस आते रहेंगे, ताकि बाद में किसी फिल्टर या अलर्ट के लिए हमेशा एक जानी-पहचानी बेसलाइन मौजूद रहे।
यह डायग्राम डिवाइस, एड्रेस और कैप्चर किए गए ट्रैफिक को एक ही जगह दिखाता है:
यह डायग्राम दिखाता है कि बाद वाला स्कैन क्यों ज़रूरी है। वेब एप्लीकेशन के लिए क्लाइंट की रिक्वेस्ट का एक तय मकसद होता है, जबकि 10.0.30.66 से कई डेस्टिनेशन तक बार-बार कनेक्शन बनने का मतलब ‘रिकॉनिसेंस’ (जानकारी जुटाने की कोशिश) हो सकता है। अगर रोकथाम नाकाम हो जाती है और फ़ायरवॉल अनचाहे ट्रैफ़िक को आने देता है, तो भी पैकेट कैप्चर का इस्तेमाल करके इसका पता लगाया जा सकता है, क्योंकि यह सोर्स एड्रेस, डेस्टिनेशन एड्रेस, प्रोटोकॉल और टाइमिंग को रिकॉर्ड करता है। ‘नेटवर्क सर्विस डिस्कवरी’, ATT&CK v20 (अक्टूबर 2026) में ATT&CK तकनीक T1046 है, और डिफ़ेंडर फ़ायरवॉल लॉग, फ़्लो रिकॉर्ड या पैकेट कैप्चर के ज़रिए इसके नेटवर्क पैटर्न का पता लगा सकते हैं।
कैप्चर की गई रिक्वेस्ट तब समझ में आती है जब हम उसे एनकैप्सुलेशन के नज़रिए से देखते हैं; यह एक प्रोटोकॉल के डेटा को दूसरे प्रोटोकॉल के हेडर के अंदर रखने की प्रक्रिया है। उदाहरण के लिए, ब्राउज़र की GET /login रिक्वेस्ट के लिए सिर्फ़ उसके टेक्स्ट से काम नहीं चलता। नेटवर्क को डेस्टिनेशन पोर्ट, डेस्टिनेशन IP एड्रेस और लोकल नेटवर्क डेस्टिनेशन की जानकारी भी साथ ले जानी होती है।
OSI मॉडल और TCP/IP मॉडल उसी काम को अलग-अलग तरह से व्यवस्थित करते हैं। OSI सात लेयर के बारे में बताता है, जबकि TCP/IP आम तौर पर पैकेट को एप्लीकेशन, ट्रांसपोर्ट, इंटरनेट और लिंक लेयर में बांटता है। इनमें से कोई भी मॉडल अलग नेटवर्क नहीं है। दोनों ही उस ईथरनेट फ़्रेम के बारे में बताते हैं जिसे Wireshark ने रिकॉर्ड किया था।
10.0.10.50 से 10.0.10.20 तक की एक रिक्वेस्ट के लिए, कौन सी जानकारी लोकल डिलीवरी, होस्ट डिलीवरी, रिसीविंग सर्विस और रिक्वेस्ट किए गए पेज की पहचान करती है? नीचे दिया गया पैकेट स्टैक उन सीमाओं को साफ़ दिखाता है:
यह स्टैक बाहर से अंदर की ओर जवाब दिखाता है। ईथरनेट लोकल लिंक पर फ्रेम भेजने के लिए MAC एड्रेस का इस्तेमाल करता है। IPv4 में 10.0.10.50 और 10.0.10.20 होते हैं ताकि राउटर नेटवर्क के बीच पैकेट भेज सकें। TCP बातचीत के एंडपॉइंट्स की पहचान करने के लिए पोर्ट 51514 और पोर्ट 80 का इस्तेमाल करता है, और HTTP एप्लिकेशन डेटा के तौर पर GET /login ले जाता है। इसलिए, एक पैकेट एनालिस्ट हर फील्ड को एक साथ खोजने के बजाय हर लेयर पर अलग सवाल पूछ सकता है।
हेडर का क्रम एप्लिकेशन रिक्वेस्ट को समझने से पहले लिंक डिलीवरी से लेकर होस्ट डिलीवरी और सर्विस डिलीवरी तक पैकेट फील्ड्स को पढ़ें।
क्योंकि फ्रेम में एक साथ कई लेयर्स होती हैं, इसलिए Wireshark का पैकेट डिटेल्स पेन उन्हें अलग-अलग प्रोटोकॉल एंट्रीज़ के तौर पर दिखाता है। Ethernet II लेयर 2 MAC फील्ड्स दिखाता है, Internet Protocol Version 4 लेयर 3 एड्रेस दिखाता है, और Transmission Control Protocol लेयर 4 पोर्ट्स और कंट्रोल फ्लैग्स दिखाता है। Hypertext Transfer Protocol एंट्री तभी दिखाई देती है जब Wireshark दिखने वाले HTTP डेटा की पहचान कर पाता है।
हर फ्रेम में HTTP रिक्वेस्ट नहीं होती है। पहली GET /login से पहले, TCP 10.0.10.50 से SYN और 10.0.10.20 से SYN/ACK रिप्लाई के साथ कनेक्शन बनाता है। वे पैकेट अभी भी दो होस्ट्स और पोर्ट्स की पहचान करते हैं, लेकिन उनमें कोई पेज रिक्वेस्ट नहीं होती है। नीचे दिया गया रेफरेंस आउटपुट उसी फ्लो से फील्ड्स निकालता है, बिना यह दावा किए कि इसे किसी सिस्टम पर चलाया जा रहा है: