रेज़िडेंशियल प्रॉक्सी: IP ब्लॉकिंग को मात देने का सच

दुनिया के बड़े प्रोवाइडरों द्वारा बेचे जाने वाले रेज़िडेंशियल प्रॉक्सी एग्ज़िट नोड्स में से लगभग एक-चौथाई ऐसे डिवाइसों पर चल रहे हैं, जिनके मालिकों को पता ही नहीं कि उनका डिवाइस किसी के इन्फ़्रास्ट्रक्चर का हिस्सा है। यह अनुमान इन नेटवर्कों को मापने वाले वर्षों के अकादमिक काम से आता है, और इससे बहुत कुछ समझ आता है, जैसे यह कि एक सिक्योरिटी फ़र्म ने हाल ही में रेज़िडेंशियल प्रॉक्सी एग्ज़िट उस IP स्पेस के अंदर पकड़े, जो Executive Office of the President को आवंटित है। जब रिसर्चर्स ने यह ट्रैफ़िक देखा, और उसका आधा हिस्सा शाम 5 बजे से रात 12 बजे ईस्टर्न टाइम के बीच आ रहा था, तो इंटरनेट वैसे ही रिएक्ट करने लगा जैसे हमेशा करता है, यानी मज़ाक बनने लगे। लेकिन इन मज़ाकों के नीचे हम सबके लिए एक असली सबक है: रेज़िडेंशियल प्रॉक्सी IP-आधारित डिफेंस को तोड़ने का सबसे कारगर तरीका हैं, और अगर आपका threat model अब भी “रेज़िडेंशियल IP” को भरोसे का संकेत मानता है, तो आप एक पीढ़ी पीछे हैं।

मैंने एक मिड-साइज़ SaaS कंपनी में चार साल तक डिटेक्शन का काम संभाला है, और इसका असर हमारे डैशबोर्ड पर रियल टाइम में दिखता था। जब क्रेडेंशियल स्टफ़िंग करने वाले गिरोहों ने डेटासेंटर प्रॉक्सी से रेज़िडेंशियल एग्ज़िट की ओर रुख किया, तो हमारी IP ब्लॉकलिस्ट, जो पहले 80% अटैक ट्रैफ़िक पकड़ती थी, लगभग कुछ भी नहीं पकड़ पा रही थी। वही अटैक, वही टूलिंग, बस आख़िरी हॉप बदल गया था। यह लेख इसी बारे में है कि ऐसा क्यों होता है, और जब IP reputation काम करना बंद कर दे, तब क्या सच में काम करता है।

रेज़िडेंशियल प्रॉक्सी असल में कैसे काम करती है

रेज़िडेंशियल प्रॉक्सी बस एक एग्ज़िट नोड है, जो किसी उपभोक्ता डिवाइस पर चलता है, जैसे फ़ोन, स्मार्ट TV, सेट-टॉप बॉक्स या होम राउटर। प्रॉक्सी नेटवर्क का ग्राहक उस ट्रैफ़िक के लिए पैसे देता है जो इन डिवाइसों से बाहर जाता है, और प्रोवाइडर का काम है कि हर भौगोलिक क्षेत्र में ऐसे लाखों डिवाइस उपलब्ध रहें। इन डिवाइसों की सप्लाई तीन स्रोतों से आती है, जो सम्मान के स्तर के हिसाब से ऊपर से नीचे क्रम में हैं।

1. ओप्ट-इन SDK। मुफ़्त ऐप्स, जैसे VPN, मौसम विजेट, मोबाइल गेम्स और “बैंडविड्थ शेयर करके पैसे कमाएँ” वाले ऐप्स, एक प्रॉक्सी SDK बंडल करते हैं। सहमति ऐसे टर्म्स-ऑफ़-सर्विस में छिपी होती है जिसे कोई नहीं पढ़ता, लेकिन तकनीकी रूप से वह मौजूद होती है। बड़े प्रोवाइडर जब नैतिकता की बात करते हैं, तो इसी मॉडल की ओर इशारा करते हैं।
2. कंप्रोमाइज़्ड फ़र्मवेयर और मैलवेयर। बॉटनेट सालों से प्रॉक्सी रीसेल के ज़रिए पैसे कमा रहे हैं। फ़ैक्ट्री में संदिग्ध फ़र्मवेयर के साथ फ़्लैश किया गया सस्ता Android स्ट्रीमिंग बॉक्स, इंटरनेट से जुड़ते ही एक प्रॉक्सी नोड बन जाता है। मालिक को लगता है उसने बस एक मीडिया प्लेयर खरीदा है।
3. खुलेआम बॉटनेट किराए पर। बाज़ार का निचला हिस्सा कोई दिखावा नहीं करता। अगर कोई प्रोवाइडर बिना किसी स्पष्ट सोर्सिंग पॉलिसी के पचास मिलियन रोटेटिंग IP देता है, तो हिसाब आप खुद लगा सकते हैं।

सबसे अहम बात यह है कि डिफ़ेंडर की नज़र से यह कैसा दिखता है। ट्रैफ़िक किसी Comcast, BT या Deutsche Telekom के रेज़िडेंशियल ASN से आता है। IP एक सही-सी लगने वाली शहर की लोकेशन दिखाता है। Reverse DNS कुछ ऐसा लौटाता है: pool-96-225-14-7.nycmny.fios.verizon.net। 2010 के दशक में हमने जो भी heuristics बनाए थे, वे सब कहते हैं कि यह घर पर बैठा एक इंसान है। पर ऐसा नहीं है। यह $3 प्रति गीगाबाइट वाला रिले है, और घर पर बैठे इंसान को इसके बारे में कुछ पता नहीं है।

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

IP-आधारित डिफेंस अब क्यों बेकार हैं

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

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

इसलिए “ट्रैफ़िक व्हाइट हाउस से आया” वाली बात के साथ सावधानी ज़रूरी है, और इस कहानी पर चर्चा में शामिल संशयवादी सही सवाल उठाते हैं। किसी IP स्पेस का मालिक होने का मतलब यह नहीं कि हर घोषणा एक भौतिक जगह से जुड़ी है। बड़े संगठन कई साइटों से रेंज घोषित करते हैं, गेस्ट नेटवर्क, लैब और कैरियर NAT ओवरले चलाते हैं। किसी संगठन की रेंज में मौजूद एग्ज़िट IP आपको बताता है कि स्पेस किसके नाम रजिस्टर्ड है, यह नहीं कि पैकेट किसकी डेस्क से गुज़रे। जब आप अपने नेटवर्क पर यह विश्लेषण करें, और आपको करना चाहिए, तो attribution को एक हाइपोथीसिस मानें जिसे internal flow logs से जाँचना है, निष्कर्ष नहीं।

वे डिटेक्शन सिग्नल जो अब भी काम करते हैं

IP reputation मर चुका है, लेकिन ट्रैफ़िक अदृश्य नहीं है। प्रॉक्सी एग्ज़िट के फ़िंगरप्रिंट होते हैं। इनमें से कोई भी सिग्नल अकेले काफ़ी नहीं है, क्योंकि हर एक के वैध कारण भी हो सकते हैं, लेकिन साथ मिलकर ये काफ़ी असरदार होते हैं। आधुनिक डिटेक्शन इंजीनियरिंग का यही तरीका है: किसी एक “स्मोकिंग गन” की तलाश छोड़कर कमज़ोर सिग्नलों से स्कोर बनाना शुरू करें। यही दर्शन obfuscated scripts की behavioral fingerprinting में दिखता है: अगर आप व्यवहार को पहचान सकते हैं, तो कोड पढ़ने की ज़रूरत नहीं है।

ASN और कनेक्शन-शेप विश्लेषण

ASN से शुरुआत कीजिए, लेकिन “क्या यह रेज़िडेंशियल है?” पर रुकिए मत। ज़्यादा उपयोगी सवाल यह है कि क्या ASN उस क्लाइंट से मेल खाता है जिसका वह दावा करता है। अगर रिक्वेस्ट desktop Chrome user agent के साथ आ रही है, लेकिन मोबाइल कैरियर की उपभोक्ता 5G रेंज से, तो वह संदिग्ध है। इसी तरह किसी consumer ISP ASN से आने वाला ट्रैफ़िक, जो आपके API पर डेटासेंटर जैसी concurrency के साथ हिट कर रहा हो, भी संदिग्ध है। अलग-अलग प्रॉक्सी नोड असली घर होते हैं, और असली घरों की असली सीमाएँ होती हैं: उपभोक्ता अपलोड बैंडविड्थ, NAT टेबल, और carrier-grade NAT में साझा किए गए एड्रेस। वह एग्ज़िट IP जो एक घंटे में चालीस अलग-अलग प्रॉक्सी ग्राहकों की सेवा करता है, ऐसे कनेक्शन पैटर्न बनाता है जो कोई घर कभी नहीं बनाता।

TLS और TCP फ़िंगरप्रिंट

यहीं आप लापरवाह ऑपरेटरों को पकड़ते हैं। ज़्यादातर प्रॉक्सी ग्राहक अपना ट्रैफ़िक प्रोवाइडर के क्लाइंट सॉफ़्टवेयर से, या Python requests, Go के net/http, Node जैसी स्टैंडर्ड HTTP लाइब्रेरी से भेजते हैं। हर एक का TLS ClientHello अलग होता है: cipher suite का क्रम, extension की सूची, supported groups। JA3 और JA4 हैश आपको यह तुलना करने देते हैं कि TLS handshake क्लाइंट के बारे में क्या कहता है और user agent क्या दावा करता है। “Windows पर Chrome 126” जो Go का TLS फ़िंगरप्रिंट भेज रहा है, वह एक बॉट है जिसने कॉस्ट्यूम पहना हुआ है। कुछ परिष्कृत प्रॉक्सी नेटवर्क ग्राहक की मशीन से पूरा TLS passthrough करते हैं, जिससे झूठ बना रहता है, लेकिन ज़्यादातर ऐसा नहीं करते, और अच्छे नेटवर्क भी TCP लेयर पर सुराग छोड़ देते हैं। Windows होने का दावा करने वाला क्लाइंट, जिसका TTL और window size Linux की ओर इशारा करते हैं, वह स्कोर में एक और अंक जोड़ता है।

Latency और टाइमिंग पैटर्न

हर रेज़िडेंशियल प्रॉक्सी उपभोक्ता हार्डवेयर और उपभोक्ता अपलिंक से एक हॉप जोड़ती है। उस हॉप की एक कीमत होती है। अगर आपकी सर्विस WebRTC, CDN edge measurement, या सत्र के भीतर रिक्वेस्ट के टाइमिंग डिस्ट्रीब्यूशन के ज़रिए क्लाइंट का असली latency भी देख सकती है, तो आप network RTT को दावा की गई भौगोलिक स्थिति से मिला सकते हैं। Virginia डेटासेंटर से 4ms RTT वाला “Denver का यूज़र” Denver में नहीं है। सत्र के भीतर टाइमिंग भी मायने रखती है: इंसानी ब्राउज़िंग में पढ़ने का ठहराव, माउस मूवमेंट और अनियमित गति होती है। ऑटोमेशन स्क्रिप्ट से प्रॉक्सी के ज़रिए गया ट्रैफ़िक एक मेट्रोनोम जैसी लय रखता है: लगातार अंतराल, बिना निष्क्रिय उतार-चढ़ाव के, और तुरंत फ़ॉर्म सबमिशन। हमलावर जितना भी jitter जोड़ें, वह उसी वितरण से आता है जिसे कोई इंसान कभी पैदा नहीं करेगा।

Behavioral heuristics

सबसे मज़बूत सिग्नल यह है कि क्लाइंट क्या करता है, न कि वह क्या है। असली यूज़र इधर-उधर भटकते हैं। बॉट योजना के मुताबिक चलते हैं। एक सत्र जो लॉगिन करता है, किसी ऐसे URL से सीधे settings पेज पर जाता है जहाँ तक कोई UI रास्ता नहीं ले जाता, ईमेल बदलता है, और नब्बे सेकंड में payout रिक्वेस्ट POST करता है, वह IP चाहे जो कहे, इंसान नहीं है। Sequence entropy को ट्रैक कीजिए: क्या सत्र आपके ऐप में उसी तरह चलते हैं जैसे आपका फ़्रंटेंड उन्हें चलाता है, या वे उन एंडपॉइंट्स को ऐसे क्रम में हिट करते हैं जिन्हें केवल आपके API डॉक्स पढ़ने वाला ही चुनेगा? यहाँ cross-session aggregation सबसे बड़ी खासियत है। एक रेज़िडेंशियल IP जो तीन रिक्वेस्ट करता है, वह निर्दोष लगता है। तीन सौ रेज़िडेंशियल IP, जिनमें से हर एक तीन रिक्वेस्ट करता है और सबके TLS फ़िंगरप्रिंट, स्क्रीन रिज़ॉल्यूशन और एंडपॉइंट क्रम एक जैसे हैं, वह एक ही ऑपरेशन है जिसने तीन सौ कॉस्ट्यूम पहने हैं।

अपने नेटवर्क पर प्रॉक्सी SDK की थ्रेट हंटिंग

इनबाउंड समस्या सबका ध्यान खींचती है, लेकिन जिस कहानी ने यह सब शुरू किया, वह असल में आउटबाउंड कहानी है: एक ऐसे नेटवर्क पर मौजूद डिवाइस ने, जिसे बेहतर पता होना चाहिए था, दूसरों का ट्रैफ़िक रिले किया। यही वह परिदृश्य है जिस पर आप सच में कुछ कर सकते हैं, क्योंकि परिमिति आपके नियंत्रण में है। मान लीजिए कोई यूज़र किसी दिन कंप्रोमाइज़्ड स्ट्रीमिंग बॉक्स लगा देगा या ऑफ़िस फ़ोन पर “मुफ़्त VPN” इंस्टॉल कर देगा। आपका काम है उस घटना को ज़ोरदार बनाना।

डिटेक्शन लॉजिक सीधा है, क्योंकि प्रॉक्सी SDK का एक खास व्यवहार होता है। एक नोड निर्देश प्राप्त करने और ट्रैफ़िक रिले करने के लिए होता है, इसलिए:

• लगातार कंट्रोल-चैनल कनेक्शन। अनजान डोमेन या IP पर लंबे समय तक चलने वाले TLS सत्र, जिनमें अक्सर छोटे आवधिक पेलोड होते हैं। अपने egress गंतव्यों का बेसलाइन बनाइए; ऐसा क्लाइंट डिवाइस जो छह घंटे से किसी ऐसे देश के होस्ट से जुड़ा है जहाँ आपका कोई सॉफ़्टवेयर वेंडर काम नहीं करता, उस पर नज़र डालनी चाहिए।
• क्लाइंट डिवाइस से उच्च connection fan-out। एक वर्कस्टेशन जो प्रति घंटे सैकड़ों अलग-अलग बाहरी IP से outbound कनेक्शन बना रहा है, वह इंसान की तरह नहीं बल्कि इन्फ़्रास्ट्रक्चर की तरह व्यवहार कर रहा है। लैपटॉप ब्राउज़ करते हैं; रिले रिले करते हैं।
• क्लाइंट सबनेट की ओर inbound-शुरू किए गए फ़्लो। कई प्रॉक्सी फ़्रेमवर्क inbound टनल खोलते हैं या STUN-शैली NAT traversal इस्तेमाल करते हैं। अगर आपके guest या IoT VLAN पर मौजूद डिवाइस को इंटरनेट से कनेक्शन मिल रहे हैं, तो आपकी segmentation में कुछ गंभीर रूप से गड़बड़ है, उसे ढूँढिए।
• असमान अपलोड पैटर्न। ऐसा फ़ोन या TV बॉक्स जिसका अपलोड वॉल्यूम डाउनलोड के लगभग बराबर हो, वह कंटेंट सर्व कर रहा है या ट्रैफ़िक रिले कर रहा है। उपभोक्ता डिवाइसों के लिए दोनों में से कुछ भी सामान्य नहीं है।
• दिन के समय के बेसलाइन। जिन रिसर्चर्स ने सरकारी नेटवर्क के एग्ज़िट पकड़े, उन्होंने ठीक इसी पर भरोसा किया: शाम के घंटों में गतिविधि इशारा करती थी कि डिवाइस गेस्ट नहीं, निजी नेटवर्क पर है। आपका अपना संस्करण और सरल हो सकता है: जब किसी डिवाइस का ट्रैफ़िक पैटर्न अपना चरित्र बदले, सिर्फ़ मात्रा नहीं, तब अलर्ट कीजिए।

इसमें से किसी के लिए deep packet inspection की ज़रूरत नहीं है, और यह उन लोगों के लिए मायने रखता है जो ऐसा नेटवर्क चलाना चाहते हैं जिस पर लोग भरोसा कर सकें। Flow metadata, जैसे NetFlow, Zeek conn logs, VPC flow logs, ऊपर के हर सिग्नल को समेटे रहता है। अगर आप अब तक egress flow data को सहेजकर उसका बेसलाइन नहीं बना रहे, तो कुछ भी खरीदने से पहले वही खाई भरिए। यहाँ की blind spots cloud authentication logging की blind spots जैसी ही हैं: डेटा मौजूद है, पर घटना होने तक कोई उसे देखता नहीं।

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

यह पहला पड़ाव है, तैयार उत्पाद नहीं। fan-out threshold को अपने बेसलाइन पर ट्यून कीजिए, और जब तक आप अपने media servers और backup agents को allowlist में नहीं डालते, तब तक उनसे false positive की उम्मीद रखिए। मुद्दा यह है कि यह हंट सस्ता है। एक दोपहर का लॉग विश्लेषण वह पकड़ सकता है जो छह अंकों वाला एप्लायंस पकड़ता है।

असली समाधान segmentation है

मेरी एक मज़बूत राय है, जो मैंने कठिन तरीके से बनाई है: कंप्रोमाइज़्ड उपभोक्ता डिवाइसों के खिलाफ़ डिटेक्शन की होड़ आप कभी नहीं जीतेंगे। सप्लाई बहुत बड़ी है, और असुरक्षित फ़र्मवेयर भेजने वाले वेंडरों पर कोई परिणाम नहीं होता। आप जो कर सकते हैं वह यह है कि कंप्रोमाइज़्ड डिवाइस को उबाऊ बना दें। ठीक से segmented IoT VLAN पर मौजूद संक्रमित स्ट्रीमिंग बॉक्स अपनी बैंडविड्थ किसी प्रॉक्सी नेटवर्क को बेच सकता है, जो परेशान करने वाला है और अगर आपकी IP रेंज संवेदनशील है तो शर्मिंदगी भी दे सकता है, लेकिन वह आपकी फ़ाइल शेयर, आपके आंतरिक APIs या ऐसी किसी चीज़ तक नहीं पहुँच सकता जो शर्मिंदगी को ब्रीच में बदल दे।

घटना-समीक्षा में पैटर्न हमेशा एक जैसा होता है। संगठन के पास या तो फ़्लैट नेटवर्क था, या ऐसा “guest” नेटवर्क जो आंतरिक DNS और management interfaces तक पहुँच सकता था, या ऐसी bring-your-own-device नीति जिसे सिर्फ़ एक क्लिक-थ्रू समझौते से लागू किया गया था। फिर एक सस्ता Android बॉक्स या bundled SDK वाला फ़ोन नेटवर्क से जुड़ गया, और संगठन का egress IP प्रॉक्सी प्रोवाइडर की सूचियों में दिखने लगा। बाद में की गई मरम्मत वही है जो पहले होनी चाहिए थी: guest नेटवर्क पर client isolation, IoT डिवाइस ऐसे VLAN पर जिनका केवल egress की अनुमति हो और RFC1918 गंतव्य ब्लॉक हों, और निजी डिवाइस उत्पादन trust zones से बहुत दूर रहें। Defense in depth ग्लैमरस नहीं है, लेकिन जैसा हमने layered defenses बनाम single strong controls के संदर्भ में कहा है, जब कोई एक control फ़ेल होता है तब परतें ही बचाती हैं, और कोई न कोई एक हमेशा फ़ेल होता है।

अंदरूनी नीति पर एक बातचीत भी करने लायक है। “मुफ़्त” ऐप्स ही वह रास्ता हैं जिनसे ये SDK आते हैं। अगर आपके स्टाफ़ को नेटवर्क को छूने वाले डिवाइसों पर मनमर्ज़ी का सॉफ़्टवेयर इंस्टॉल करने की छूट है, तो आपने अपनी परिमिति मोबाइल ad-tech कंपनियों को सौंप दी है। कुछ संगठन MDM और app allowlists से जवाब देते हैं; ज़्यादातर के लिए नेटवर्क segmentation उसी नियंत्रण को कम राजनीतिक कीमत पर हासिल कर लेता है।

यह कहानी असल में क्या बताती है

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

अगर आप इससे एक बात लेना चाहते हैं: जाँच कीजिए कि आपके अपने संगठन के egress IP रेज़िडेंशियल प्रॉक्सी इन्वेंटरी में दिखते हैं या नहीं। कई सर्विस यह बता देंगी, और आपके threat intel feed में यह पहले से शामिल हो सकता है। अपनी रेंज सूचीबद्ध मिलना कंप्रोमाइज़ का सबूत नहीं है, क्योंकि carrier-grade NAT और साझा एड्रेस स्पेस तस्वीर धुंधली कर देते हैं, लेकिन यह हंट के लिए एक सस्ता और उच्च-सिग्नल वाला शुरुआती बिंदु है। फिर अपने egress fan-out, लंबे समय तक चलने वाले कनेक्शन और VLAN डिज़ाइन को देखिए।

हमलावर सालों पहले अच्छे इलाकों में चले गए थे। जिन डिफ़ेंडर्स ने यह देखा, वे वही हैं जिन्होंने पते जाँचना छोड़कर व्यवहार पर नज़र रखना शुरू किया।