RoguePlanet PoC सत्यापन रिपोर्ट Microsoft Defender के लिए

रिपोर्ट का उद्देश्य और दायरा

यह रिपोर्ट Microsoft Defender से संबंधित सार्वजनिक रूप से वर्णित RoguePlanet PoC के सत्यापन से संबंधित है। वर्णित तकनीक को 10 जून 2026 को मीडिया में एक स्थानीय विशेषाधिकार वृद्धि (LPE) के रूप में प्रस्तुत किया गया था, जिसमें एक स्थानीय उपयोगकर्ता NT AUTHORITY\SYSTEM विशेषाधिकार प्राप्त कर सकता है। सार्वजनिक विवरणों ने संकेत दिया कि तंत्र Microsoft Defender द्वारा किसी फ़ाइल को संभालने या स्कैन करते समय उपयोग किए जाने वाले कार्यों का उपयोग करता है।

परीक्षण का उद्देश्य यह निर्धारित करना था कि क्या एक नियंत्रित प्रयोगशाला वातावरण में शोषण तैयार और निष्पादित किया जा सकता है, और यह देखना कि एक अद्यतन Windows 11 सिस्टम पर Microsoft Defender सुरक्षा तंत्र कैसे व्यवहार करते हैं। रिपोर्ट में परीक्षण वातावरण, अद्यतन स्थिति, Microsoft Defender कॉन्फ़िगरेशन, संकलन वातावरण की तैयारी, संकलन परिणाम, Defender प्रतिक्रिया और जोखिम-न्यूनीकरण अनुशंसाओं को शामिल किया गया है।

परीक्षण अनुसंधान-उन्मुख था और एक समर्पित परीक्षण वर्कस्टेशन पर स्थानीय रूप से किया गया था। परिणामों को एक विशिष्ट कलाकृति और एक विशिष्ट वातावरण कॉन्फ़िगरेशन के व्यवहार के आकलन के रूप में व्याख्या किया जाना चाहिए, न कि इस तकनीक के सभी संभावित रूपों के प्रतिरोध की पूर्ण पुष्टि के रूप में।

विश्लेषित सामग्री में संदर्भित स्रोत:

• लेख:

  https://thehackernews.com/2026/06/microsoft-defender-rogueplanet-zero-day.html

• सार्वजनिक PoC रिपॉजिटरी:

  https://github.com/MSNightmare/RoguePlanet/tree/main

• MSYS2 इंस्टॉलर स्रोत:

  https://github.com/msys2/msys2-installer/releases/tag/nightly-x86_64

• Visual Studio स्रोत:

  https://visualstudio.microsoft.com/insiders/?rwnlp=pl

परीक्षण वातावरण

PoC को एक क्लाइंट वर्कस्टेशन पर किया गया जो Active Directory डोमेन के बाहर, WORKGROUP वर्कग्रुप में संचालित हो रहा था। वर्कस्टेशन पर स्थापित ऑपरेटिंग सिस्टम Microsoft Windows 11 Home, संस्करण 25H2, 64-बिट आर्किटेक्चर था।

PoC निष्पादित किए जाने के दिन, सिस्टम पर जून 2026 के सुरक्षा अद्यतन, साथ ही मई और अप्रैल 2026 के पहले के अद्यतन स्थापित थे। इसका मतलब है कि परीक्षण एक अद्यतन Windows 11 25H2 सिस्टम, बिल्ड 26200 पर किया गया था, जिसमें परीक्षण तिथि के अनुसार नवीनतम उपलब्ध सुरक्षा पैच स्थापित थे।

Microsoft Defender कॉन्फ़िगरेशन

परीक्षण के लिए उपयोग किए गए वर्कस्टेशन पर Microsoft Defender एंटीवायरस सक्रिय था और सामान्य मोड में चल रहा था। सुरक्षा सेवा चल रही थी और सक्षम थी, और एंटीवायरस सुरक्षा, एंटीस्पाइवेयर सुरक्षा, व्यवहार निगरानी और रीयल-टाइम सुरक्षा सक्रिय थी।

परीक्षण के दिन, Microsoft Defender हस्ताक्षर अद्यतन थे। एंटीवायरस, एंटीस्पाइवेयर और NIS हस्ताक्षर 10.06.2026 को 13:27:32 पर अद्यतन किए गए थे।

अंतिम त्वरित स्कैन 08.06.2026 को 15:00:36 से 15:01:58 के बीच, हस्ताक्षर संस्करण 1.451.323.0 का उपयोग करके किया गया था। पूर्ण स्कैन पहले नहीं किया गया था या इसका इतिहास उपलब्ध नहीं था, जैसा कि FullScanAge मान 4294967295 और पूर्ण स्कैन प्रारंभ और समाप्ति समय की अनुपस्थिति से संकेत मिलता है।

संकलन वातावरण की तैयारी

GitHub रिपॉजिटरी से कोड को संकलित करने का पहला प्रयास लापता winternl.h हेडर के कारण एक त्रुटि के साथ समाप्त हुआ। संदेश ने संकेत दिया कि सिस्टम के पास विश्लेषित कोड द्वारा आवश्यक Windows SDK हेडर का पूरा सेट नहीं था।

चित्र 1. पहले संकलन प्रयास के दौरान लापता winternl.h हेडर त्रुटि।

कोड ने Windows API और NT API से संबंधित अन्य हेडरों का भी संदर्भ दिया, जिनमें windows.h, Psapi.h, ntstatus.h, virtdisk.h, shlwapi.h, taskschd.h और bcrypt.h शामिल हैं। इस कारण से, अधिक पूर्ण संकलन वातावरण तैयार करना और उपयुक्त SDK घटकों को स्थापित करना आवश्यक था।

चित्र 2. विश्लेषित कोड के लिए आवश्यक हेडरों की सूची का एक अंश।

MSYS2/MinGW-w64 का उपयोग करने का प्रयास

प्रारंभ में, संकलन वातावरण तैयार करने के लिए MSYS2/MinGW-w64 का उपयोग किया गया था। यह वातावरण Windows के लिए GNU उपकरण प्रदान करता है, जिसमें gcc और g++ कंपाइलर शामिल हैं। MSYS2 में पैकेजों को pacman का उपयोग करके प्रबंधित किया जाता है, जो Linux सिस्टम पर apt या Windows पर winget के समान भूमिका निभाता है।

चित्र 3. MSYS2 स्थापना का समापन।

pacman का उपयोग करके, MinGW-w64 GCC/G++ टूलचेन स्थापित किया गया, अर्थात् उपकरणों का एक सेट जो Windows के लिए C/C++ कोड का संकलन सक्षम करता है। पैकेज में अन्य घटकों के अलावा, gcc कंपाइलर, g++ C++ कंपाइलर, लिंकर, और Windows वातावरण में चलने वाले अनुप्रयोगों के निर्माण के लिए आवश्यक हेडर और लाइब्रेरी शामिल हैं। इस प्रयास का उद्देश्य यह जांचना था कि क्या Visual Studio का उपयोग किए बिना, MSYS2 में उपलब्ध ओपन टूलचेन का उपयोग करके कोड संकलित किया जा सकता है।

चित्र 4. pacman का उपयोग करके MSYS2/MinGW-w64 पैकेजों की स्थापना।

स्थापना के बाद, g++ का उपयोग करके कोड को संकलित करने का प्रयास किया गया। कमांड ने सीधे स्रोत फ़ाइल का पथ और परिणामी निष्पादन योग्य फ़ाइल का पथ निर्दिष्ट किया।

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe

यूनिकोड मोड समस्या

असंगत वर्ण प्रकारों के संबंध में कंपाइलर संदेश यूनिकोड मोड समस्या का पहला महत्वपूर्ण संकेत थे। लॉग में त्रुटियाँ थीं जो बताती थीं कि const wchar_t* या wchar_t* प्रकार के मानों को LPCSTR या LPSTR में परिवर्तित नहीं किया जा सकता है। इसका मतलब था कि कोड Windows API फ़ंक्शनों में वाइड-कैरेक्टर स्ट्रिंग पास कर रहा था, जबकि कंपाइलर क्लासिक ANSI स्ट्रिंग्स के लिए अभिप्रेत फ़ंक्शन वेरिएंट का चयन कर रहा था।

Windows API में, कई फ़ंक्शन दो वेरिएंट में मौजूद होते हैं: ANSI, जिसे A प्रत्यय से चिह्नित किया जाता है, और यूनिकोड, जिसे W प्रत्यय से चिह्नित किया जाता है। उदाहरण के लिए, CreateFile को CreateFileA या CreateFileW के रूप में मैप किया जा सकता है, और RegOpenKeyEx को RegOpenKeyExA या RegOpenKeyExW के रूप में। A वेरिएंट char* या LPCSTR प्रकार के पैरामीटर की अपेक्षा करता है, जबकि W वेरिएंट wchar_t* या LPCWSTR प्रकार के पैरामीटर की अपेक्षा करता है।

विश्लेषित मामले में, कोड ने L"..." के रूप में शाब्दिक और wchar_t प्रकार के बफ़र्स का उपयोग किया। साथ ही, त्रुटि संदेशों ने संकेत दिया कि कंपाइलर ने GetModuleHandleA, RegOpenKeyExA, RegQueryValueExA, GetWindowsDirectoryA, CreateFileA और wsprintfA जैसे फ़ंक्शनों का चयन किया। यह एक सीधा संकेत था कि कोड यूनिकोड मोड को ध्यान में रखकर लिखा गया था, लेकिन संकलन कमांड ने UNICODE और _UNICODE को परिभाषित नहीं किया था।

इसलिए UNICODE और _UNICODE परिभाषाओं को जोड़कर यूनिकोड मोड को बाध्य किया गया। इस परिवर्तन के बाद, स्पष्ट प्रत्यय के बिना Windows API फ़ंक्शनों को W-प्रत्यय वाले वेरिएंट, जैसे CreateFileW, RegOpenKeyExW, GetModuleHandleW और GetWindowsDirectoryW पर मैप किया जाना चाहिए। इस परिवर्तन के बाद कुछ त्रुटियों का गायब होना निदान की शुद्धता की पुष्टि करता है।

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe -DUNICODE -D_UNICODE

हालांकि, यूनिकोड से संबंधित मुद्दों को हटाने के बाद, त्रुटियाँ बनी रहीं जो कोड और MinGW के बीच गहरी असंगति का संकेत देती हैं। वे FILE_BASIC_INFORMATION और FILE_RENAME_INFORMATION संरचनाओं की डुप्लिकेट परिभाषाओं से संबंधित थीं, जो स्रोत कोड और MinGW हेडर दोनों में परिभाषित थीं। इसके अलावा, MinGW में उपलब्ध FILE_RENAME_INFORMATION संस्करण कोड द्वारा अपेक्षित से भिन्न था, जिसमें Flags फ़ील्ड की अनुपस्थिति शामिल थी।

अतिरिक्त त्रुटियाँ g++ कंपाइलर के प्रकारों, विशेष रूप से एनम फ़्लैग और फ़ंक्शन पॉइंटर्स के प्रति अधिक प्रतिबंधात्मक दृष्टिकोण के कारण भी हुईं। यह VIRTUAL_DISK_ACCESS_MASK और ATTACH_VIRTUAL_DISK_FLAG प्रकारों के साथ-साथ फ़ंक्शन पॉइंटर्स को void* के रूप में पास करने से संबंधित था। परिणामस्वरूप, महत्वपूर्ण स्रोत-कोड संशोधनों के बिना इस कोड को संकलित करने के लिए MinGW को अनुपयुक्त माना गया।

5. MSVC और Windows SDK में स्थानांतरण

MinGW के साथ संगतता समस्याओं के कारण, एक MSVC और Windows SDK वातावरण तैयार किया गया। Visual Studio इंस्टॉलर में "Desktop development with C++" वर्कलोड का चयन किया गया क्योंकि विश्लेषित कोड C/C++ में लिखा गया एक मूल Windows एप्लिकेशन था और सीधे Windows API और Windows SDK घटकों का उपयोग करता था। यह .NET, Python, Node.js या वेब एप्लिकेशन प्रोजेक्ट नहीं था, इसलिए उन प्रौद्योगिकियों से संबंधित घटक स्थापित नहीं किए गए।

चित्र 5. डेस्कटॉप C++ अनुप्रयोगों के लिए चयनित Visual Studio वर्कलोड और घटक।

सबसे महत्वपूर्ण घटक MSVC v143 था, जो Windows के लिए C/C++ एप्लिकेशन बनाने के लिए Microsoft C/C++ कंपाइलर है। इसे चुना गया क्योंकि MinGW/G++ के साथ संकलन के पिछले प्रयास ने हेडर, प्रकारों और NT API संरचनाओं से संबंधित संगतता त्रुटियाँ उत्पन्न की थीं। कोड ने Windows-विशिष्ट तंत्रों का उपयोग किया, इसलिए सबसे संगत वातावरण Microsoft का कंपाइलर था, जो Windows SDK द्वारा प्रदान की गई लाइब्रेरी के साथ था।

Windows 11 SDK भी स्थापित किया गया था। इस घटक में Windows सिस्टम फ़ंक्शनों का उपयोग करने के लिए आवश्यक हेडर और लाइब्रेरी शामिल हैं, जिनमें windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h और लिंकिंग के दौरान उपयोग की जाने वाली .lib आयात लाइब्रेरी शामिल हैं। इसके अलावा, C++ CMake उपकरणों को एक सहायक घटक के रूप में रखा गया, जो अधिक जटिल परियोजनाओं का विश्लेषण करते समय उपयोगी होता है।

स्थापना के बाद, VS Insiders के लिए x64 Native Tools Command Prompt का उपयोग किया गया - एक CLI जिसमें cl.exe कंपाइलर, Windows SDK और लिंकर लाइब्रेरी के लिए सही पथ निर्धारित थे।

चित्र 6. VS Insiders के लिए x64 Native Tools Command Prompt लॉन्च करना।

6. MSVC का उपयोग करके संकलन

MSVC पर स्विच करने के बाद, कोड बिल्ड प्रक्रिया में काफी आगे बढ़ गया। पहले कमांड ने अभी भी Windows API फ़ंक्शनों को ANSI वेरिएंट में मैप करने से संबंधित त्रुटियाँ लौटाईं, इसलिए MSVC संकलन के दौरान भी UNICODE और _UNICODE परिभाषाओं को जोड़ना आवश्यक था।

cl /EHsc RoguePlanet.cpp -o rogue.exe

चित्र 7. पूर्ण यूनिकोड और लिंकिंग कॉन्फ़िगरेशन के बिना MSVC का उपयोग करके संकलन का प्रयास।

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

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe

चित्र 8. Windows API फ़ंक्शनों के लिए LNK2019 लिंकर त्रुटियाँ।

लिंकर त्रुटियों में CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW और RegQueryValueExW जैसे फ़ंक्शन शामिल थे। ये फ़ंक्शन सुरक्षा टोकन, विशेषाधिकार, किसी विशिष्ट उपयोगकर्ता संदर्भ में प्रक्रिया शुरू करने और सिस्टम रजिस्ट्री को पढ़ने से संबंधित हैं। हेडर केवल यह घोषणा करता है कि फ़ंक्शन मौजूद है, लेकिन लिंकर को सही आयात लाइब्रेरी प्राप्त करनी चाहिए जो यह इंगित करे कि उन फ़ंक्शनों के कार्यान्वयन कहाँ स्थित हैं।

लिंकर त्रुटियों को हल करने के लिए, advapi32.lib लाइब्रेरी जोड़ी गई। यह एक Windows आयात लाइब्रेरी है जो अन्य चीजों के अलावा, सुरक्षा टोकन, विशेषाधिकार, उपयोगकर्ता खातों और सिस्टम रजिस्ट्री से संबंधित फ़ंक्शन प्रदान करती है। इसे लिंकिंग चरण में जोड़ने के बाद, लिंकर पहले से अनसुलझे बाहरी प्रतीकों को हल करने और निष्पादन योग्य फ़ाइल बनाने में सक्षम था।

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe /link advapi32.lib

चित्र 9. सही किए गए संकलन कमांड का परिणाम।

चित्र 10. सफल कमांड का परिणाम।

चित्र 11. कार्यशील निर्देशिका ~\Downloads\\ में बनाई गई rogue.exe फ़ाइल

Microsoft Defender प्रतिक्रिया और निष्पादन परिणाम

सत्यापन के दौरान, बनाई गई निष्पादन योग्य फ़ाइल को Microsoft Defender द्वारा तुरंत Trojan:Win64/RoguePlanet.DA!MTB के रूप में "गंभीर" गंभीरता स्तर के साथ पहचाना गया। सिस्टम ने फ़ाइल को क्वारंटाइन में ले जाने या हटाने जैसी मानक सुरक्षा कार्रवाइयाँ प्रस्तावित कीं।

चित्र 12. Windows संदेश जो सूचित करता है कि फ़ाइल को वायरस या संभावित रूप से अवांछित सॉफ़्टवेयर के रूप में अवरुद्ध कर दिया गया था।

चित्र 13. Microsoft Defender का पता लगाना: Trojan:Win64/RoguePlanet.DA!MTB.

इसका मतलब है कि Defender के पता लगाने वाले तंत्रों ने तैयार की गई कलाकृति को सफलतापूर्वक निष्पादित होने से पहले ही दुर्भावनापूर्ण या संभावित रूप से खतरनाक के रूप में पहचान लिया। एंडपॉइंट सुरक्षा के दृष्टिकोण से, यह एक सकारात्मक परिणाम है, क्योंकि अवरोधन प्रोग्राम के निष्पादन के प्रभावों को देखने के बजाय निष्पादन योग्य फ़ाइल चरण पर हुआ।

रीयल-टाइम सुरक्षा को अस्थायी रूप से अक्षम करने के बाद, फ़ाइल को निष्पादित किया जा सका। परीक्षण अवलोकन इंगित करता है कि दूसरे निष्पादन के बाद SYSTEM विशेषाधिकारों के साथ चलने वाला एक कंसोल प्राप्त करना संभव था। यह परिणाम पुष्टि करता है कि परीक्षण की गई कलाकृति को अवरुद्ध करने में सक्रिय Defender सुरक्षा महत्वपूर्ण थी।

चित्र 14. रीयल-टाइम सुरक्षा को अक्षम करने के बाद परीक्षण वातावरण में प्रोग्राम निष्पादन।

चित्र 15. परीक्षण वातावरण में सिस्टम संदर्भ में चल रहा कंसोल।

जोखिम आकलन

Microsoft Defender द्वारा एक विशिष्ट फ़ाइल का पता लगाने का मतलब यह नहीं है कि भेद्यता जोखिम पूरी तरह से समाप्त हो गया है। Defender ने ज्ञात या समान PoC कलाकृति का पता लगाया, जबकि कोड का एक संशोधित संस्करण, एक अलग संकलन, एक बदली हुई फ़ाइल संरचना, या कोई अन्य लोडर हस्ताक्षर-आधारित या अनुमानी पहचान के संबंध में अलग व्यवहार कर सकता है। परीक्षण परिणाम को परीक्षण की गई कलाकृति के विरुद्ध वर्तमान सुरक्षा परत की प्रभावशीलता की पुष्टि के रूप में माना जाना चाहिए, न कि इस बात के प्रमाण के रूप में कि तकनीक के हर संभावित रूप को अवरुद्ध किया जाएगा।

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

व्यवहार में, इसका मतलब है कि प्रभावी शमन के लिए केवल Defender की उपस्थिति पर निर्भर नहीं रहना चाहिए, बल्कि इसके कॉन्फ़िगरेशन को केंद्रीय रूप से लागू करना और उपयोगकर्ताओं द्वारा स्थानीय परिवर्तनों को अवरुद्ध करना भी महत्वपूर्ण है।

9. अनुशंसाएँ

सुरक्षा नीतियों के माध्यम से Microsoft Defender कॉन्फ़िगरेशन को केंद्रीय रूप से लागू करना महत्वपूर्ण है। स्थानीय उपयोगकर्ताओं को रीयल-टाइम सुरक्षा अक्षम करने, अपवाद जोड़ने, पहचाने गए खतरों की अनुमति देने या सुरक्षा सेटिंग्स को संशोधित करने में सक्षम नहीं होना चाहिए। ऐसे मॉडल में, उपयोगकर्ता को "डिवाइस पर अनुमति दें" जैसे विकल्प का चयन करके या अस्थायी रूप से सुरक्षा अक्षम करके स्वतंत्र रूप से पहचान को दरकिनार करने में सक्षम नहीं होना चाहिए।

• रीयल-टाइम सुरक्षा, क्लाउड-डिलीवर सुरक्षा और स्वचालित नमूना सबमिशन को केंद्रीय रूप से लागू करें;
• उपयोगकर्ताओं को पहचान के लिए अपवाद और कार्रवाइयाँ प्रबंधित करने से रोकें;
• पहचान, क्वारंटाइन, खतरों की अनुमति देने के प्रयासों और सुरक्षा कॉन्फ़िगरेशन परिवर्तनों से संबंधित Defender घटनाओं की निगरानी करें;
• Trojan:Win64/RoguePlanet.DA!MTB पहचान को एक सुरक्षा घटना के रूप में मानें जिसके लिए विश्लेषण की आवश्यकता है;
• वातावरण की क्षमताओं के अनुसार, अनधिकृत निष्पादन योग्य फ़ाइलों के निष्पादन को सीमित करने वाले अतिरिक्त तंत्रों पर विचार करें, जैसे एप्लिकेशन अनुमति-सूचीकरण, WDAC, या AppLocker।

अंतिम निष्कर्ष

परीक्षण ने पुष्टि की कि कलाकृति तैयार करने के लिए Microsoft के मूल टूलचेन के साथ संगत वातावरण की आवश्यकता थी। MinGW/G++ का उपयोग करके संकलन के प्रयास ने NT API हेडर और संरचनाओं के साथ संगतता समस्याएँ प्रकट कीं, जबकि MSVC और Windows SDK पर स्विच करने से प्रक्रिया लिंकिंग चरण तक पहुँच गई और सही आयात लाइब्रेरी जोड़ने के बाद अंततः निष्पादन योग्य फ़ाइल बनाई गई।

Microsoft Defender, सामान्य मोड में चल रहा था, अद्यतन हस्ताक्षरों और सक्षम रीयल-टाइम सुरक्षा के साथ, बनाई गई फ़ाइल को Trojan:Win64/RoguePlanet.DA!MTB के रूप में पहचाना और इसके निष्पादन को अवरुद्ध कर दिया। एंडपॉइंट सुरक्षा के दृष्टिकोण से यह एक सकारात्मक परीक्षण परिणाम है।

साथ ही, रीयल-टाइम सुरक्षा को अक्षम करने से कलाकृति को निष्पादित करने की अनुमति मिली और SYSTEM विशेषाधिकारों के साथ एक कंसोल प्राप्त करने की स्थिति उत्पन्न हुई। व्यावहारिक निष्कर्ष स्पष्ट है: Defender कॉन्फ़िगरेशन को केंद्रीय रूप से लागू किया जाना चाहिए, और उपयोगकर्ताओं को स्थानीय रूप से सुरक्षा को कमजोर करने, अपवाद जोड़ने या पहचाने गए खतरों की अनुमति देने में सक्षम नहीं होना चाहिए।