TL; डॉ
चा एक समूह पाच एनपीएम पॅकेजेसदोन अकाउंट हँडलवर प्रकाशित केले, पाठवले postinstall एक हुक जो होस्टकडून क्लाउड क्रेडेंशियल्स वाचतो आणि त्यांना ऑफ-बॉक्स पाठवतो. या पॅकेजेसना बनावट आणि अनधिकृत नावे दिली जातात — coral-wraith, ecto-corsair-whisper-6f3b9, ecto-corsair-flag-x9m4, ecto-rust-read-f3a9c1, ecto-nightly-spirit — आणि ते जे काही गोळा करतात ते एका बनावटीमध्ये क्रमबद्ध करतात ecto_module: YAML मॅनिफेस्ट प्रसारित करण्यापूर्वी. आम्ही क्लस्टरचा मागोवा घेतो म्हणून एक्टोप्लाझम.
पेलोड केवळ तेव्हाच चालतो जेव्हा त्याला एक विशिष्ट वातावरण आढळते: एक होस्ट ज्याचे नाव आहे १२-अक्षरी हेक्स स्ट्रिंग आणि खालील कार्यरत डिरेक्टरी /app/node_modules — कंटेनरयुक्त बिल्ड किंवा सीआय वर्करचे स्वरूप. जेव्हा ती पायरी पार होते, तेव्हा हुक क्वेरी करतो... AWS इन्स्टन्स मेटाडेटा सेवा (IMDSv2) IAM रोल क्रेडेंशियल्ससाठी, गणन करते AWS सिक्रेट्स मॅनेजर तीन प्रदेशांमध्ये, पर्यावरण व्हेरिएबल्स डंप करते, फाईल्स वाचते /appआणि कॅप्चर-द-फ्लॅग स्ट्रिंगसाठी स्क्रॅप करते. त्यानंतर ते परिणाम दोन मार्गांनी बाहेर पाठवते: एका बीकनला... webhook.site कलेक्टर आणि मॅनफेस्ट रॉ-आयपी एंडपॉइंटवर पुट केले जातात, ज्यामध्ये लोकलहोस्ट-फर्स्ट फॉलबॅकची सूची असते.
नंतरच्या पॅकेज वर्णनांमध्ये "verdaccio पुरवठा-साखळी चाचणीसाठी CTF पेलोड" असे नमूद आहे. आम्ही ते स्व-वर्णन एक निरीक्षणक्षम वस्तुस्थिती म्हणून नोंदवत आहोत. प्रत्यक्ष वर्तन — सार्वजनिक IP वर थेट डेटा पाठवणे, IMDS क्रेडेन्शियलचे खरे वाचन, सिक्रेट्स मॅनेजरचे खरे कॉल्स — हे कोणत्याही लेबलची पर्वा न करता जसे आहे तसेच आहे, आणि याच कारणामुळे या आवृत्त्यांना दुर्भावनापूर्ण म्हणून वर्गीकृत करण्यात आले.
समूहातील एक नाव, coral-wraithते एकाच प्रकाशनावर थांबले नाही. त्यांनी अवघ्या काही तासांतच एकापाठोपाठ अनेक आवृत्त्या वेगाने पुन्हा प्रकाशित केल्या — 1.0.0 वर चढत आहे 6.0.0 — आणि त्याच नावाच्या पूर्वीच्या आवृत्तीत फुगवलेले वापरले होते 9999.0.x आवृत्ती क्रमांक, चा क्लासिक आकार अवलंबित्व-गोंधळाचा प्रयत्नया उलथापालथीदरम्यान पेलोडमध्ये स्पष्टपणे परिपक्वता आली: एका-वेळच्या होस्ट-एन्युमरेशन बीकनपासून ते पर्यावरण तपासण्यांनी वेढलेल्या संपूर्ण AWS क्रेडेंशियल पिव्होटपर्यंत, जे त्याला त्याच्या अभिप्रेत लक्ष्याबाहेर निःशब्द ठेवते.
| पॅकेजेस | ५ नावे; coral-wraith एकट्याने डझनभर आवृत्त्यांमध्ये पुनर्प्रकाशित केले गेले |
| पर्यावरणातील | npm |
| वेक्टर स्थापित करा | postinstall जीवनचक्र स्क्रिप्ट |
| प्राथमिक लक्ष्य | AWS IAM रोल क्रेडेंशियल्स + सिक्रेट्स मॅनेजर सिक्रेट व्हॅल्यूज, एन्व्हायर्नमेंट व्हेरिएबल्स, /app फाइल |
| बाहेर जा | webhook.site बीकन + रॉ-आयपी सी२ पुट |
| ट्रिगर गेट | १२-हेक्स होस्टनेम + /app/node_modules cwd, तसेच एक पर्यावरण तपासणी जी त्या संदर्भाबाहेर पेलोडला दाबून टाकते. |
| गंभीरता | उच्च — क्लाउड क्रेडेंशियल आणि मॅनेज्ड-सिक्रेट डिस्क्लोजर फ्रॉम कंटेनरयुक्त बिल्ड आणि रनटाइम वातावरण |
शरीररचनाशास्त्रावर हल्ला
क्लस्टरमधील प्रत्येक पॅकेज एकाच पद्धतीने तयार केले जाते: जवळजवळ रिकामे index.js (मॉड्यूल.निर्यात = {}), एक ओळ package.json स्क्रिप्ट — “पोस्टइन्स्टॉल”: “नोड पोस्टइन्स्टॉल.जेएस” — आणि पेलोडमध्ये पोस्टइन्स्टॉल.जेएसहुक चालवण्यासाठी पॅकेज इन्स्टॉल करणे पुरेसे आहे; कोणत्याही इम्पोर्ट किंवा कॉलची आवश्यकता नाही.
लक्ष्यीकरण गेट. कोणतीही कृती करण्यापूर्वी, एक्टो-फॅमिली पेलोड आपल्या सभोवतालचा परिसर तपासतो:
function isAppWorker(): host = os.hostname() if host does NOT match /^[0-9a-f]{12}$/ -> exit if cwd does NOT contain "/app/node_modules" -> exit if cwd contains "/tmp/npm-safe" -> exit otherwise -> proceed१२-हेक्स होस्टनेम हा डॉकरद्वारे कंटेनरला दिला जाणारा डीफॉल्ट आकार आहे, आणि /app/node_modules हा एक पारंपरिक इन-कंटेनर इन्स्टॉल पाथ आहे. जर पाथ सँडबॉक्स केलेल्या एक्सट्रॅक्शन डिरेक्टरीसारखा दिसत असेल, तर तिसरे कलम कार्य थांबवते. याचा निव्वळ परिणाम असा होतो की, पेलोड डेव्हलपरच्या लॅपटॉपवर किंवा ॲनालिसिस सँडबॉक्सवर निष्क्रिय राहतो आणि केवळ कंटेनराइज्ड बिल्ड किंवा रनटाइम वर्करमध्येच सक्रिय होतो — अशा प्रकारच्या वातावरणात थेट क्लाउड क्रेडेंशियल्स असण्याची सर्वाधिक शक्यता असते. क्लस्टरमधील सर्वात पहिले पॅकेज, कोरल-रेथ, ला असे कोणतेही गेट नसते आणि ते त्याचे (सोपे) कलेक्शन बिनशर्त चालवते.
संकलनजेव्हा गेट ओलांडले जाते, तेव्हा हुक बाहेर पडतो. execFileSync(“/bin/sh”, [“-c”, …]) आणि एकच संयुक्त कमांड चालवते, जी क्रमाने:
1. PUT /latest/api/token to 169.254.169.254 (IMDSv2 token request) 2. GET .../iam/security-credentials/ (IAM role name) 3. GET .../iam/security-credentials/<role> (temporary credentials) 4. dump env | sort (environment variables) 5. list /app (excl. node_modules) + cat first 15 (application files) 6. aws secretsmanager list-secrets (us-east-1, eu-west-1, eu-central-1) 7. scrape readable files for HTB{...} (capture-the-flag strings)पायऱ्या १-३ या IMDSv2 पुनर्प्राप्तीच्या आदर्श पद्धती आहेत: सेशन टोकनची विनंती करा, आणि नंतर ते संलग्न करा. X-aws-ec2-metadata-token इन्स्टन्सची IAM भूमिका आणि त्या भूमिकेच्या तात्पुरत्या ऍक्सेस की मिळवण्यासाठी हेडर. सोप्या अप्रमाणित IMDSv1 ऐवजी IMDSv2 लागू करण्याचा पर्याय. GET हे लक्षात घेण्यासारखे आहे — याचा अर्थ असा की, टोकन-आधारित मेटाडेटा ऍक्सेसची आवश्यकता असलेल्या कॉन्फिगर केलेल्या इन्स्टन्सवर देखील पेलोड काम करतो, जे AWS-शिफारस केलेले हार्डनिंग आहे. पायरी ३ द्वारे परत केलेली क्रेडेन्शियल्स अल्पायुषी असतात. अॅक्सेसकीआयडी/गुप्त प्रवेश की/टोकन इन्स्टन्सच्या भूमिकेशी संलग्न ट्रिपल्स; ती भूमिका जे काही करू शकते, ते सर्व त्या कीजचा धारक क्रेडेंशियलच्या जीवनकाळात करू शकतो.
पायऱ्या ४-६ टेक अधिक रुंद करतात. env डंप बिल्ड किंवा रनटाइम प्रक्रियेला मिळालेली प्रत्येक गोष्ट कॅप्चर करतो — व्यवहारात, रजिस्ट्री टोकन्स, डेटाबेस कनेक्शन स्ट्रिंग्ज आणि API कीज बहुतेकदा इथेच असतात. / अॅप फाइल वॉक बाहेरील पंधरा ॲप्लिकेशन फाइल्सपर्यंत वाचते. नोड_मॉड्यूल्सजे पृष्ठभागाची रचना असू शकते, .env फाईल्स, किंवा स्रोत. पायरी ६ कॉल करते aws secretsmanager list-secrets तीन प्रदेशांमध्ये; पायरी १-३ मध्ये मिळवलेली क्रेडेन्शियल्सच त्या कॉल्सना ऑथेंटिकेट करतात, त्यामुळे IMDS रीड आणि सिक्रेट्स मॅनेजर एन्युमरेशनची साखळी एकत्र येऊन एकच एस्केलेशन तयार होते: इन्स्टन्स रोल → मॅनेज्ड-सिक्रेट इन्व्हेंटरी. पायरी ७ ही 'कॅप्चर-द-फ्लॅग' फ्रेमिंगला दिलेला एक संकेत आहे — जेव्हा एखादा एचटीबी{…} फ्लॅग सापडल्यास तो स्वतंत्रपणे पाठवला जातो, अन्यथा गोळा केलेला मूळ ब्लॉब चार तुकड्यांमध्ये विभागून पाठवला जातो.
क्लस्टरमधील नंतरच्या आवृत्त्या ही प्रक्रिया पुढे नेतात. केवळ इन्व्हेंटरीवर न थांबता, त्या IMDS प्रतिसादाचे विश्लेषण करतात, आणि तात्पुरत्या कीज निर्यात करतात. AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN पर्यावरण व्हेरिएबल्ससह ओळख निश्चित करा aws sts get-caller-identityआणि नंतर ने परत केलेल्या प्रत्येक गुप्त गोष्टीवर लूप करा सूची-रहस्य कॉल aws secretsmanager get-secret-value प्रत्येकावर — केवळ त्यांची नावेच नव्हे, तर गुप्त सामग्री मिळवणे. त्याच आवृत्त्या प्रोसेस-सबस्टिट्यूटेड फ्लॅग बायनरी देखील वाचतात (/readflag आणि मित्र) आणि प्रयत्न करा चार्ज रन आढळलेल्या कोणत्याही रस्ट प्रोजेक्टच्या विरोधात / अॅपक्लाउड क्रेडेंशियल्सच्या पलीकडे जाऊन, बिल्ड एन्व्हायर्नमेंट जे काही उपलब्ध करून देते त्या सर्वांपर्यंत लाभाचा विस्तार करणे.
या नंतरच्या आवृत्त्या स्वतःला अधिक आक्रमकपणे नियंत्रित करतात. १२-हेक्स-होस्टनेम आणि /app/node_modules पेलोड सक्रिय पॅकेज-रजिस्ट्री कॉन्फिगरेशन आणि वर्किंग-डिरेक्टरी पाथची तपासणी करतो आणि जेव्हा ते लाइव्ह टार्गेटऐवजी ॲनालिसिस किंवा मिरर कॉन्टेक्स्ट दर्शवतात, तेव्हा तो काहीही न कळवता बाहेर पडतो. याचा एकत्रित परिणाम म्हणजे असा पेलोड तयार होतो जो बहुतेक तपासणी वातावरणात काहीही दृश्यमान करत नाही आणि केवळ तिथेच त्याचे संपूर्ण कलेक्शन चालवतो, जिथे तो स्वतःला खऱ्या कंटेनरयुक्त होस्टवर असल्याचे मानतो.
बाहेर काढणेगोळा केलेला डेटा होस्टकडून दोन चॅनेलद्वारे बाहेर पडतो. पहिले, एक बीकन. पोस्ट एका निश्चित वेबहूक.साईट कलेक्टरमध्ये होस्टनेम, अंकीय UID, वर्किंग डिरेक्टरी आणि १२० KB पर्यंतचा संकलित डेटा असतो. दुसरे म्हणजे, हा डेटा एका बनावट YAML “मॉड्यूल मॅनिफेस्ट” मध्ये एकत्रित केला जातो आणि ठेवा ते /एपीआय/मॉड्यूल्स/ लक्ष्य सर्व्हरवर:
ecto_module: name: "<flag-or-chunk-0>" version: "1.0.0" power_level: "<chunk-1>" ship_deck: "<chunk-2>" cargo_hold: "<chunk-3>"मॅनिफेस्ट फील्डची नावे (पॉवर_लेव्हल, जहाजाचा डेक, मालवाहू_होल्ड) हे केवळ देखाव्यासाठी असतात — चोरलेला डेटा स्ट्रिंग व्हॅल्यूजमध्ये असतो, म्हणूनच नेटवर्क मॉनिटरला स्पष्ट डेटा डंपऐवजी एक सामान्य पॅकेज-रजिस्ट्री मॅनिफेस्ट अपलोड दिसतो. बीकन चॅनल याहून अधिक काही वाहून नेतो: पोस्ट शरीर वेबहूक.साईट यात होस्टनेम, अंकीय UID, वर्किंग डिरेक्टरी आणि गोळा केलेल्या ब्लॉबचा 120 KB पर्यंतचा भाग समाविष्ट असतो, त्यामुळे एक यशस्वी बीकन सुद्धा संपूर्ण माहिती पुरवतो. वेबहूक.साईट ही एक विनामूल्य विनंती-तपासणी सेवा आहे; तिचा संग्राहक म्हणून वापर केल्याने ऑपरेटरला त्या चॅनेलसाठी स्वतःची प्राप्त करणारी पायाभूत सुविधा कधीही उभी करावी लागत नाही आणि नोंदवलेल्या विनंत्या सेवेच्या बिनमध्ये कायम राहतात.
जाहीरनामा ठेवा अनेक ने सुरू होणाऱ्या फॉलबॅक सूचीमधून जातो 127.0.0.1/localhost पोर्ट्स आणि नंतर तीन सार्वजनिक पत्त्यांवर पोहोचते `१५४.५७.१६४.०/२४` ही श्रेणी, 2xx स्टेटससह प्रतिसाद देणाऱ्या पहिल्या एंडपॉइंटवर थांबते. 'लोकलहोस्ट-फर्स्ट' ही क्रमवारी "व्हर्डॅसिओ टेस्टिंग" या स्व-वर्णनाशी (लूपबॅकवरील एक स्थानिक रजिस्ट्री) सुसंगत आहे, परंतु पब्लिक-आयपी फॉलबॅकचा अर्थ असा आहे की जेव्हा लूपबॅक ऐकत नसेल तेव्हा डेटा होस्टवरून बाहेर जातो — म्हणजेच, लेखकाच्या स्वतःच्या टेस्ट रिग व्यतिरिक्त इतर कोणत्याही मशीनवरून.
टाइमलाइन
हा समूह क्षमतेत एकदम घट होण्याऐवजी टप्प्याटप्प्याने होणारी वाढ दर्शवतो. आम्ही त्याची क्रमवारी निरीक्षित वर्तनानुसार लावतो, प्रकाशित झालेल्या अंतिम वेळेनुसार नाही:
या क्लस्टरचे मुख्य वैशिष्ट्य म्हणजे त्याच्या प्रकाशनाची लय: एक पॅकेज आणि एक आवृत्ती प्रकाशित करण्याऐवजी, तेच नाव जलद गतीने वारंवार पुनर्प्रकाशित केले जाते, प्रत्येक प्रकाशन हे मागील आवृत्तीमध्ये केलेला एक छोटासा बदल असतो, आणि त्यासोबतच समान पेलोड असलेली काही वेगळ्या नावांची इतर प्रकाशनेही प्रकाशित केली जातात. कुजबुजणे कोड दोन जवळच्या फिंगरप्रिंट्समध्ये विभागला गेला — एका सेटमध्ये दोन गंभीर डिटेक्शन्स आढळले, तर दुसऱ्यामध्ये तीन (एक अतिरिक्त फाइल-रीड सिंक) — परंतु दोन्ही एकाच पेलोडवर पोहोचतात; फरक कोड ड्रिफ्टचा आहे, वर्तणुकीतील बदलाचा नाही. कुजबुजणे विश्लेषण केलेल्या श्रेणीच्या पलीकडे (हे लिहिताना किमान १.०.२५ पर्यंत) रजिस्ट्रीवर थेट आढळून आले, आणि कोरल-रेथ नाव त्याच खिडकीवरून स्वतःच्या आवृत्तीच्या शिडीवर चढत राहिले.
तडजोडीचे संकेतक
खालील सर्व निर्देशक डिस्कवरील पॅकेज सोर्समधून काढण्यात आले आहेत. नेटवर्क निर्देशक निष्क्रिय करण्यात आले आहेत.
नेटवर्क
वर्तणूक/फाइल
फाईल हॅश (sha256, विश्लेषणाच्या वेळी मिळवलेले)
श्रेय देणे आणि निरीक्षण केलेले वर्तन
पाच पॅकेजची नावे दोन npm अकाउंट हँडल अंतर्गत प्रकाशित केली गेली होती, परंतु त्यांना एकच क्लस्टर मानण्यासाठी त्यांच्यात पुरेशी सामायिक पायाभूत सुविधा आहे: समान एक्टो_मॉड्यूल मॅनिफेस्ट स्कीमा, तोच ईसीटी-४७२८३९ प्राथमिक सिंक मार्कर, तोच वेबहूक.साईट कलेक्टर आयडी, आणि त्याच C2 एंडपॉइंट्स `154.57.164.0/24` ब्लॉक. सीड पॅकेज (`coral-wraith`)(अधिक सोपे आणि अनगेटेड) आणि गेटेड एक्टो-फॅमिली अशा प्रकारे स्वतंत्र प्रयत्नांऐवजी एकाच टूलकिटवरील पुनरावृत्ती म्हणून वाचल्या जातात.
नंतरच्या आवृत्त्यांमध्ये, पॅकेजेस स्वतःचे वर्णन असे करतात व्हरडासिओ पुरवठा-साखळी चाचणीसाठी सीटीएफ पेलोड. आम्ही ते लेबल एक निरीक्षण करण्यायोग्य वस्तुस्थिती म्हणून समोर आणतो आणि त्याचा उद्देशाबद्दलचा निष्कर्ष म्हणून पुनरुच्चार करत नाही. कोड काय करतो हे निःसंदिग्ध आहे आणि त्याला कसे लेबल लावले आहे यावर अवलंबून नाही: तो इन्स्टन्स मेटाडेटा सर्व्हिसमधून IAM रोल क्रेडेंशियल्स वाचतो, तीन AWS रिजनमधील व्यवस्थापित सिक्रेट्सची गणना करतो आणि परिणाम एका सार्वजनिक IP आणि तृतीय-पक्ष वेबहूक कलेक्टरला पाठवतो. खऱ्या अर्थाने केवळ लूपबॅकवर आधारित टेस्ट हार्नेसला सार्वजनिक-IP फॉलबॅक सूची, IMDS क्रेडेंशियल वाचन किंवा क्रॉस-रिजन सिक्रेट्स मॅनेजर कॉल्सची आवश्यकता भासणार नाही. इग्रेस आणि क्रेडेंशियलची पोहोच वास्तविक असल्यामुळे, गेटेड आवृत्त्यांना दुर्भावनापूर्ण म्हणून वर्गीकृत केले गेले.
कंटेनर-ओन्ली गेट हे सर्वात लक्षणीय कार्यात्मक वैशिष्ट्य आहे. हा एक टाळण्याचा उपाय (लॅपटॉपवर आणि विश्लेषण सँडबॉक्समध्ये शांत राहणे) आणि एक लक्ष्यीकरण उपाय, दोन्ही आहे; जिथे खरी IAM भूमिका आणि थेट सिक्रेट्स असण्याची सर्वाधिक शक्यता असते, तिथेच तो कार्यान्वित होतो. सामान्य सँडबॉक्समध्ये हे पॅकेजेस चालवणाऱ्या विश्लेषकांना काहीही दिसणार नाही; हे वर्तन केवळ डॉकर-शैलीतील होस्टनेम आणि कंटेनरमधील इन्स्टॉल पाथ अंतर्गतच दिसून येते.
बचावपटूंसाठी प्रभाव, कल आणि मार्गदर्शन
येथे धोका हा बिल्ड आणि रनटाइम कंटेनर्समधील क्लाउड-क्रेडेंशियल आणि गोपनीय माहिती उघड होण्याचा आहे. IMDS मधून घेतलेल्या IAM रोल क्रेडेंशियलमध्ये त्या रोलकडे असलेल्या सर्व परवानग्या समाविष्ट असतात; सिक्रेट्समॅनेजर:लिस्टसिक्रेट्स (आणि त्यानंतरचे कोणतेही) गुप्त मूल्य मिळवा) हे संग्रहित ॲप्लिकेशन सिक्रेट्सपर्यंत त्याचा विस्तार करते. एन्व्हायर्नमेंट-व्हेरिएबल डम्प्समध्ये अनेकदा रजिस्ट्री टोकन्स, डेटाबेस यूआरएल आणि एपीआय कीज असतात. सीआय (CI) किंवा कंटेनरच्या संदर्भात — नेमके हेच गेट निवडते — यापैकी एका पॅकेजचे एकच ट्रान्झिटिव्ह इन्स्टॉल ती माहिती लीक करण्यासाठी पुरेसे आहे.
एक्टोप्लाझम हे आम्हाला सातत्याने दिसून येणाऱ्या एका पॅटर्नमध्ये बसते: इन्स्टॉल-टाइम पेलोड्स जे स्थानिक फाइल्सऐवजी क्लाउड मेटाडेटा आणि व्यवस्थापित सिक्रेट्सचा वापर करतात, आणि जे केवळ उच्च-मूल्याच्या वातावरणातच कार्यान्वित होण्यासाठी स्वतःला मर्यादित करतात. यानंतर दोन बचावात्मक निरीक्षणे दिली आहेत.
- आकार ओळखता येतोएक npm/PyPI इन्स्टॉल हुक ज्याचा कॉल ग्राफ क्लाउड सिक्रेट्स API पर्यंत पोहोचतो (एडब्ल्यूएस सिक्रेट्समॅनेजर, जीक्लाउड सिक्रेट्स, एझेड कीव्हॉल्ट) किंवा IMDS ॲड्रेस आणि नेटवर्क इग्रेस सिंक हा एक अरुंद, उच्च-सिग्नल पॅटर्न आहे — तो वैध लाइफसायकल स्क्रिप्टमध्ये जवळजवळ कधीही आढळत नाही. स्थिर प्रवाह विश्लेषण कोणत्याही विशिष्ट डोमेन किंवा आयपीवर अवलंबून न राहता ते फ्लॅग केले जाऊ शकते.
- पर्यावरणाच्या कठोरपणामुळे त्याची धार बोथट होते. १ च्या हॉप मर्यादेसह IMDSv2 लागू केल्याने कंटेनर वर्कलोड्सना इन्स्टन्स मेटाडेटापर्यंत पोहोचण्यापासून प्रतिबंधित केले जाते; IAM भूमिकांना किमान विशेषाधिकारांपर्यंत मर्यादित केल्याने लीक होणाऱ्या कोणत्याही क्रेडेन्शियलचा प्रभाव मर्यादित होतो; आणि इन्स्टॉलेशन्स खालीलप्रमाणे चालवल्यास स्क्रिप्ट्सकडे दुर्लक्ष करा CI मध्ये, ज्या पॅकेजेसना इन्स्टॉल-हुकची आवश्यकता नसते, त्यांच्यासाठी हा मार्ग पूर्णपणे काढून टाकला जातो.
संरक्षकांसाठी, व्यावहारिक तपासण्या खालीलप्रमाणे आहेत: बिल्ड/सीआय कंटेनर्समधून नॉन-अॅलोलिस्टेड सार्वजनिक आयपींवर जाणाऱ्या आउटबाउंड कनेक्शन्सवर अलर्ट देणे. एनपीएम स्थापित; पॅकेज लाइफसायकल स्क्रिप्ट्समधून होणाऱ्या IMDS ऍक्सेसवर लक्ष ठेवा; आणि जोपर्यंत अन्यथा सिद्ध होत नाही, तोपर्यंत क्लाउड CLI वर शेल करणाऱ्या कोणत्याही इन्स्टॉल हुकला संशयास्पद माना.
या क्लस्टरशी संबंधित आणखी दोन विशिष्ट नोंदी. पहिली गोष्ट म्हणजे, ॲक्टिव्हेशन हे कंटेनरयुक्त वातावरणापुरते मर्यादित असल्यामुळे, वर्कस्टेशनवर तपासणी केल्यावर निष्क्रिय दिसणारे पॅकेज प्रोडक्शनमध्ये कार्यरत असू शकते — तपासणीसाठी, “मी ते इन्स्टॉल केले आणि काहीच झाले नाही” यावर अवलंबून राहण्याऐवजी, कंटेनरचे होस्टनेम आणि पाथची स्थिती पुन्हा तयार करणे किंवा थेट सोर्स वाचणे आवश्यक आहे. दुसरी गोष्ट म्हणजे, बीकन कलेक्टर म्हणून सार्वजनिक रिक्वेस्ट-इन्स्पेक्शन सेवेचा वापर केल्यामुळे, बाहेर काढलेला काही डेटा इन्सिडेंट रिस्पॉन्ससाठी पुनर्प्राप्त करण्यायोग्य असू शकतो: ज्या संस्थेला तिच्या डिपेंडेंसी ट्रीमध्ये यापैकी एखादे पॅकेज आढळते, ती पेलोडच्या कलेक्शन लॉजिकवरून यशस्वी बीकनमध्ये काय समाविष्ट असेल याचा अंदाज लावू शकते, आणि प्रभावित बिल्ड किंवा रनटाइम वातावरणातून पोहोचता येणारे कोणतेही IAM रोल क्रेडेंशियल्स, रजिस्ट्री टोकन्स आणि मॅनेज्ड सिक्रेट्स रोटेट केले पाहिजेत. क्रेडेन्शियल रोटेशनएकदा इन्स्टॉल प्रक्रिया पूर्ण झाल्यावर, पॅकेज काढून टाकणे नव्हे, तर तीच प्रभावी उपाययोजना असते.
