तत्काल: एक्सटर्नल लॉगिन प्लगइन (≤ 1.11.2) — अनधिकृत SQL इंजेक्शन (CVE-2025-11177) और साइट मालिकों को अब क्या करना चाहिए

तारीख: 15 अक्टूबर 2025
गंभीरता: उच्च (CVSS 9.3)
प्रभावित सॉफ़्टवेयर: एक्सटर्नल लॉगिन वर्डप्रेस प्लगइन, संस्करण ≤ 1.11.2
कमजोरियों का प्रकार: प्लगइन लॉगिंग इनपुट (लॉग पैरामीटर) के माध्यम से अनधिकृत SQL इंजेक्शन
ठीक किया गया संस्करण: एन/ए (लेखन के समय कोई आधिकारिक पैच उपलब्ध नहीं है)

मेरी हांगकांग स्थित सुरक्षा विशेषज्ञ के रूप में अनुभव से, मुझे सीधे कहना है: एक प्रमाणीकरण-संबंधित प्लगइन में अनधिकृत SQL इंजेक्शन सबसे गंभीर समस्याओं में से एक है जिसका आप सामना कर सकते हैं। क्योंकि कमजोर कोड पथ को किसी प्रमाणीकरण की आवश्यकता नहीं होती, कोई भी दूरस्थ हमलावर आपके डेटाबेस के खिलाफ SQL निष्पादित करने का प्रयास कर सकता है। इससे डेटा चोरी, विशेषाधिकार वृद्धि, स्थायी बैकडोर और पूर्ण साइट अधिग्रहण हो सकता है। इस मुद्दे के लिए CVE है CVE-2025-11177. प्रकाशन के समय, प्लगइन लेखक द्वारा कोई आधिकारिक सुधार जारी नहीं किया गया है।.

यह लेख कवर करता है:

• कमजोरियों क्या हैं और यह क्यों खतरनाक है
• यह कैसे जांचें कि आपकी साइट प्रभावित है या नहीं
• तात्कालिक निवारण (अल्पकालिक और मध्यवर्ती)
• यदि समझौता संदिग्ध है तो पहचान और फोरेंसिक कदम
• वेब एप्लिकेशन फ़ायरवॉल (WAF) के साथ वर्चुअल पैचिंग — यह कैसे मदद करता है और व्यावहारिक नियम उदाहरण
• दीर्घकालिक कठिनाई और सुधार

कार्यकारी सारांश (साइट मालिकों और प्रशासकों के लिए)

• कमजोरियों: प्लगइन लॉगिंग इनपुट (एक “लॉग” पैरामीटर या एक एंडपॉइंट जो लॉग लिखता/प्रक्रिया करता है) के माध्यम से एक अनधिकृत SQL इंजेक्शन एक्सटर्नल लॉगिन (≤ 1.11.2) में मौजूद है।.
• प्रभाव: दूरस्थ हमलावर बिना क्रेडेंशियल के SQL इंजेक्ट कर सकते हैं — डेटा पढ़ें/संशोधित करें, व्यवस्थापक खाते बनाएं, बैकडोर स्थापित करें।.
• जोखिम: बहुत उच्च। इंटरनेट पर शोषण योग्य। स्कैनिंग और स्वचालित शोषण प्रयासों की अपेक्षा करें।.
• तत्काल कार्रवाई: यदि प्लगइन स्थापित है, तो इसे तुरंत हटा दें या निष्क्रिय करें। यदि हटाना संभव नहीं है, तो सर्वर नियमों के माध्यम से प्लगइन तक पहुंच को अवरुद्ध करें या शोषण पैटर्न को अवरुद्ध करने के लिए WAF नियम लागू करें। समझौते के संकेतों के लिए लॉग की निगरानी करें।.
• होस्ट/कई साइटों का प्रबंधन करें: इसे एक घटना की तरह मानें - ग्राहकों को सूचित करें, वेब पर प्लगइन पथों को अवरुद्ध करें, और जहां संभव हो, होस्ट-व्यापी आभासी पैच लागू करें।.

भेद्यता क्या है (साधारण भाषा)

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

संभावित परिणाम:

• संवेदनशील डेटा निकालें: उपयोगकर्ता नाम, ईमेल, पासवर्ड हैश, API कुंजी
• डेटा संशोधित करें: उपयोगकर्ता भूमिकाएँ बदलें, व्यवस्थापक खाते बनाएं
• बैकडोर या दुर्भावनापूर्ण सामग्री स्थापित करें
• तालिकाओं को भ्रष्ट या हटा दें
• यदि क्रेडेंशियल्स उजागर होते हैं तो अन्य सिस्टम पर पिवट करें

क्यों बिना प्रमाणीकरण वाला SQL इंजेक्शन शीर्ष स्तर की आपात स्थिति है

“बिना प्रमाणीकरण” का अर्थ है कि कोई मान्य वर्डप्रेस खाता आवश्यक नहीं है। इससे शोषण को trivially scriptable और दुर्भावनापूर्ण अभिनेताओं और बॉटनेट के लिए आकर्षक बना देता है। CVSS 9.3 पर, गंभीरता लगभग महत्वपूर्ण है। यह भेद्यता गोपनीयता और अखंडता को खतरे में डालती है; बिना शमन के हर घंटे समझौते के जोखिम को बढ़ाता है।.

यह जल्दी से कैसे निर्धारित करें कि आपकी साइट प्रभावित है

1. वर्डप्रेस व्यवस्थापक जांच (तेज):

   wp-admin में लॉग इन करें → प्लगइन्स → “External Login” की तलाश करें। यदि संस्करण ≤ 1.11.2 है, तो आप प्रभावित हैं।.

2. WP-CLI (सुरक्षित, व्यवस्थापकों/होस्ट के लिए):

   wp प्लगइन सूची --फॉर्मेट=टेबल

   जल्दी निष्क्रिय करने के लिए:

   wp प्लगइन निष्क्रिय करें external-login

   हटाने के लिए:

   wp प्लगइन हटाएं external-login

3. फ़ाइल प्रणाली जांच:

   प्लगइन निर्देशिका के लिए देखें:

   /wp-content/plugins/external-login/

   नोट: कुछ साइटें प्लगइन फ़ोल्डरों का नाम बदलती हैं - प्लगइन हेडर की जांच करें या “external-login” वाले फ़ाइलों की खोज करें।.

4. दूरस्थ स्कैन / लॉग:

   प्लगइन पथ के खिलाफ अनुरोधों या SQL टोकन (UNION, SELECT, SLEEP, आदि) वाले अनुरोधों के लिए एक्सेस लॉग या भेद्यता स्कैनर आउटपुट की खोज करें।.

यदि प्लगइन मौजूद है, तो तुरंत कार्रवाई करें।.

तात्कालिक शमन विकल्प - इसे अभी करें (प्राथमिकता के अनुसार क्रमबद्ध)

1. प्लगइन को निष्क्रिय और अनइंस्टॉल करें (सिफारिश की गई)

   यदि प्लगइन व्यवसाय के लिए महत्वपूर्ण नहीं है, तो इसे निष्क्रिय और हटा दें। इससे हमले की सतह हटा दी जाती है।.

   wp प्लगइन निष्क्रिय करें external-login && wp प्लगइन हटाएं external-login

2. यदि आप प्लगइन को हटा नहीं सकते, तो इसकी फ़ाइलों तक पहुंच को प्रतिबंधित करें

   प्लगइन निर्देशिका पर एक सर्वर-स्तरीय ब्लॉक लागू करें जैसे कि एक अस्थायी किल-स्विच।.

   अपाचे (.htaccess प्लगइन फ़ोल्डर के अंदर):

   <IfModule mod_authz_core.c>
     Require all denied
   </IfModule>
   <IfModule !mod_authz_core.c>
     Deny from all
   </IfModule>

   Nginx (उदाहरण):

   location ^~ /wp-content/plugins/external-login/ {

   सावधानी से परीक्षण करें ताकि आप आवश्यक साइट कार्यक्षमता को न तोड़ें।.

3. WAF (वर्चुअल पैचिंग) के साथ शोषण पैटर्न को ब्लॉक करें

   SQL-इंजेक्शन पैटर्न और प्लगइन के URL पैटर्न को लक्षित करने वाले नियम लागू करें। यह दुर्भावनापूर्ण ट्रैफ़िक को कमजोर कोड तक पहुँचने से रोकता है जबकि आप आधिकारिक सुधार की प्रतीक्षा करते हैं।.

4. सर्वर-स्तरीय अनुरोध फ़िल्टरिंग

   स्पष्ट SQL पेलोड पैटर्न दिखाने वाले अनुरोधों को छोड़ दें। उदाहरण ModSecurity नियम (अपने वातावरण के अनुसार समायोजित करें):

   SecRule REQUEST_URI "@beginsWith /wp-content/plugins/external-login/" "id:1009001,phase:1,deny,log,msg:'External Login प्लगइन निर्देशिका के लिए अनुरोध अवरुद्ध'"

   ये व्यापक हैं; झूठे सकारात्मक को कम करने के लिए समायोजित करें।.

5. डेटाबेस विशेषाधिकार को मजबूत करें (मध्यम)

   सुनिश्चित करें कि DB उपयोगकर्ता के पास न्यूनतम विशेषाधिकार है। यह SQLi को रोकता नहीं है, लेकिन कुछ पोस्ट-एक्सप्लॉइटेशन क्रियाओं (जैसे, FILE या SUPER संचालन) को सीमित कर सकता है।.

6. स्नैपशॉट और बैकअप

   फोरेंसिक्स के लिए अब फ़ाइलों और डेटाबेस का ऑफ़लाइन, विश्वसनीय बैकअप लें। जहां संभव हो, पूर्व-निवारण स्थिति को बनाए रखें।.

अनुशंसित WAF हस्ताक्षर और उदाहरण (व्यावहारिक)

वर्चुअल पैचिंग का उद्देश्य दुर्भावनापूर्ण इनपुट को कमजोर कोड तक पहुँचने से रोकना है। नीचे उदाहरण नियम हैं जिन्हें आप अपने स्टैक के लिए अनुकूलित कर सकते हैं।.

Nginx (प्लगइन URI + संदिग्ध क्वेरी स्ट्रिंग को ब्लॉक करें)

# संदिग्ध SQL-जैसे क्वेरी स्ट्रिंग को External Login प्लगइन के लिए ब्लॉक करें

Apache mod_rewrite (.htaccess साइट रूट में)

<IfModule mod_rewrite.c>
  RewriteEngine On
  # Block SQLi-like requests targeting the plugin folder
  RewriteCond %{REQUEST_URI} ^/wp-content/plugins/external-login/ [NC,OR]
  RewriteCond %{QUERY_STRING} (union|select|information_schema|sleep\(|benchmark\(|load_file|into%20outfile|or%201=1) [NC]
  RewriteRule .* - [F,L]
</IfModule>

ModSecurity (उच्च-स्तरीय)

SecRule REQUEST_URI "@beginsWith /wp-content/plugins/external-login/" "id:1209001,phase:1,deny,log,msg:'external-login प्लगइन तक पहुँच अवरुद्ध करें'"

सामान्य WAF नियम पाठ

शर्त:

नियमों को उस ट्रैफ़िक के स्तर पर समायोजित करें जो आप देखते हैं। उच्च-ट्रैफ़िक साइटों पर जिनमें मुक्त-फॉर्म उपयोगकर्ता इनपुट होता है, नियमों को प्लगइन पथ + SQL टोकन तक संकीर्ण करें ताकि झूठे सकारात्मक को कम किया जा सके।.

समझौते का पता लगाना और संकेत

यदि प्लगइन निवारण से पहले सुलभ था, तो मान लें कि जांच या शोषण के प्रयास हुए हैं। इन संकेतकों की तलाश करें:

• लॉग में डेटाबेस त्रुटियाँ या असामान्य SQL-संबंधित त्रुटि संदेश
• wp_users या wp_usermeta में नए या अप्रत्याशित व्यवस्थापक उपयोगकर्ता:

  SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;

• वेब सर्वर से अप्रत्याशित आउटबाउंड नेटवर्क कनेक्शन (वेबशेल कॉलबैक)
• wp-content/uploads या अन्य लिखने योग्य निर्देशिकाओं में फ़ाइलें जो आपने नहीं बनाई
• कोर/थीम/प्लगइन फ़ाइलों पर संशोधन समय-चिह्न जो अपडेट गतिविधि से मेल नहीं खाते
• एक्सेस लॉग जो SQL टोकन (UNION, SELECT, SLEEP, INFORMATION_SCHEMA) दिखाते हैं:

  grep -E "(UNION|SELECT|INFORMATION_SCHEMA|SLEEP|benchmark|load_file|into outfile)" /var/log/apache2/access.log

• WordPress डिबग लॉग जो SQL त्रुटियाँ दिखाते हैं (यदि WP_DEBUG लॉगिंग सक्षम थी)
• अप्रत्याशित रीडायरेक्ट, स्पैम पृष्ठ, या सामग्री इंजेक्शन

यदि कोई संकेत मौजूद हैं, तो इसे संभावित समझौते के रूप में मानें और नीचे दिए गए घटना प्रतिक्रिया चरणों का पालन करें।.

घटना प्रतिक्रिया चेकलिस्ट (यदि आप शोषण का संदेह करते हैं)

1. साइट को अलग करें: रखरखाव मोड में डालें; ज्ञात व्यवस्थापक आईपी के अलावा ट्रैफ़िक को ब्लॉक करें या ऑफ़लाइन ले जाएँ।.
2. सबूत को संरक्षित करें: वेब सर्वर लॉग, डेटाबेस स्नैपशॉट, और प्लगइन/थीम फ़ाइलों को सुरक्षित भंडारण में निर्यात करें। लॉग को अधिलेखित या संक्षिप्त न करें।.
3. मैलवेयर स्कैन करें: विश्वसनीय उपकरणों का उपयोग करें और, यदि संभव हो, ऑफ़लाइन स्कैनिंग करें।.
4. स्थिरता की तलाश करें: वेबशेल, संशोधित क्रोन प्रविष्टियाँ, या बागी व्यवस्थापक उपयोगकर्ताओं की खोज करें। हटाने से पहले कलाकृतियों को संरक्षित करें।.
5. क्रेडेंशियल्स को घुमाएं: WordPress व्यवस्थापक पासवर्ड, डेटाबेस पासवर्ड, SFTP/FTP क्रेडेंशियल्स, और API कुंजियाँ बदलें। ध्यान दें कि रोटेशन पिछले डेटा चोरी को पूर्ववत नहीं करता है।.
6. साफ बैकअप से पुनर्निर्माण करें: यदि समझौता पुष्टि हो जाता है, तो घुसपैठ से पहले लिए गए ज्ञात-अच्छे बैकअप से पुनर्निर्माण करें, फिर शमन उपायों को फिर से लागू करें।.
7. घटना के बाद का विश्लेषण: मूल कारण विश्लेषण करें और निष्कर्षों और सुधारात्मक कदमों को दस्तावेज़ करें।.

यदि आप कई साइटों का प्रबंधन करते हैं या एक होस्ट हैं, तो प्रभावित ग्राहकों को सूचित करें और स्पष्ट सुधारात्मक निर्देश प्रदान करें।.

यदि आप संदिग्ध प्रविष्टियाँ पाते हैं: सबूत (DB डंप, लॉग) निर्यात और संरक्षित करें, दुर्भावनापूर्ण फ़ील्ड को साफ करें (sanitize_title() या सुरक्षित रूप से पोस्ट फिर से सहेजें), और यदि समझौता होने का संदेह हो तो व्यवस्थापक क्रेडेंशियल और API कुंजी को घुमाएँ।

• वर्डप्रेस कोर, थीम और प्लगइन्स को अपडेट रखें। विश्वसनीय भेद्यता फ़ीड की सदस्यता लें।.
• प्लगइन के उपयोग को सीमित करें और समय-समय पर प्लगइन्स की जांच करें।.
• डेटाबेस उपयोगकर्ता के लिए न्यूनतम विशेषाधिकार लागू करें।.
• आईपी अनुमति-सूचियों के साथ व्यवस्थापक अंत बिंदुओं को प्रतिबंधित करें और व्यवस्थापकों के लिए दो-कारक प्रमाणीकरण (2FA) को लागू करें।.
• विक्रेताओं द्वारा भेद्यताओं को संबोधित करते समय किनारे पर आभासी पैचिंग का उपयोग करें (WAF नियम)।.
• अनधिकृत परिवर्तनों का पता लगाने के लिए फ़ाइल अखंडता निगरानी लागू करें।.
• पहुँच, अनुप्रयोग, और फ़ायरवॉल लॉग के लिए लॉगिंग और संरक्षण सक्षम करें।.
• नियमित, परीक्षण किए गए बैकअप को ऑफ-साइट संग्रहीत करें।.

यहाँ वर्चुअल पैचिंग क्यों महत्वपूर्ण है

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

वर्चुअल पैचिंग के लाभ:

• प्लगइन कोड को संशोधित किए बिना तात्कालिक सुरक्षा
• केंद्रीकृत नियम जो कई साइटों की तेजी से सुरक्षा कर सकते हैं
• Thorough परीक्षण के लिए समय खरीदता है और विक्रेता को सही सुधार जारी करने के लिए

होस्टिंग प्रदाताओं और एजेंसियों के लिए व्यावहारिक सलाह

• यदि आप ग्राहकों के बीच स्कैनिंग या शोषण प्रयासों का अवलोकन करते हैं तो होस्ट स्तर पर प्लगइन पथ को वैश्विक रूप से अवरुद्ध करें।.
• ग्राहकों को सरल सुधारात्मक कदम प्रदान करें (WP-CLI कमांड, व्यवस्थापक निर्देश)।.
• संक्रमित साइटों के लिए सफाई और क्रेडेंशियल रोटेशन सहायता प्रदान करें।.
• सभी ग्राहक साइटों की सुरक्षा के लिए तुरंत होस्ट-स्तरीय WAF नियम और वर्चुअल पैच लागू करें।.
• ग्राहकों के साथ स्पष्ट और समय पर संवाद करें: जोखिम, उठाए गए कदम और आवश्यक ग्राहक कदमों का वर्णन करें।.

पहचान प्रश्न और फोरेंसिक प्रारंभिक बिंदु (सुरक्षा टीमों के लिए)

प्राथमिकता और जांच के लिए उपयोगी प्रश्न और कमांड:

-- Recent users (look for new admins)
SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 30 DAY);
SELECT * FROM wp_usermeta WHERE meta_key LIKE '%capabilities%';

-- Suspicious options or cron entries
SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%cron%' OR option_name LIKE '%active_plugins%';

-- Find recent files in uploads
find /var/www/html/wp-content/uploads -type f -mtime -30 -print

-- Search for eval usage
grep -R "eval(" /var/www/html/wp-content/ | head

-- Scan access logs for SQLi indicators
grep -E "union|select|benchmark|sleep|information_schema|load_file|into outfile" /var/log/nginx/access.log /var/log/apache2/access.log

ये प्रारंभिक बिंदु हैं। यदि आप समझौते के सबूत देखते हैं, तो तुरंत एक पेशेवर घटना प्रतिक्रिया टीम को संलग्न करें।.

संचार चेकलिस्ट (हितधारकों को क्या बताना है)

हितधारकों को सूचित करते समय, शामिल करें:

• क्या हुआ (उच्च-स्तरीय) और आंका गया जोखिम (अप्रमाणित SQLi - उच्च)
• पहले से उठाए गए कदम (प्लगइन हटाया/ब्लॉक किया गया, WAF नियम लागू किए गए)
• अगले कदम (फोरेंसिक्स, सफाई, क्रेडेंशियल रोटेशन)
• ग्राहक से अनुरोध किए गए कदम (पासवर्ड बदलें, साइट की कार्यक्षमता की जांच करें, विसंगतियों की रिपोर्ट करें)
• अपेक्षित समयरेखा और फॉलो-अप

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: यदि मैं प्लगइन हटा दूं, तो क्या मैं सुरक्षित हूं?

उत्तर: प्लगइन को हटाने से उस हमले की सतह हट जाती है। हालाँकि, यदि हटाने से पहले शोषण हुआ, तो स्थायी बैकडोर पहले से मौजूद हो सकते हैं। साइट को साफ घोषित करने से पहले हमेशा स्कैन करें और लॉग की समीक्षा करें।.

प्रश्न: क्या डेटाबेस क्रेडेंशियल्स को घुमाने से मदद मिलती है?

उत्तर: पुष्टि किए गए समझौते के बाद रोटेशन आवश्यक है ताकि आगे की पहुंच को रोका जा सके। यह पहले से हुई किसी भी डेटा निकासी को पूर्ववत नहीं करता है।.

प्रश्न: क्या WAF मेरी साइट को धीमा कर देगा?

उत्तर: सही तरीके से कॉन्फ़िगर किए गए WAF का प्रदर्शन पर न्यूनतम प्रभाव होता है, जो वे सुरक्षा प्रदान करते हैं। उच्च-जोखिम कमजोरियों के लिए व्यापार-ऑफ आमतौर पर स्वीकार्य होता है।.

प्रश्न: प्लगइन अपडेट के बारे में क्या?

A: जब प्लगइन विक्रेता एक सुधार प्रकाशित करता है, तो इसे तुरंत लागू करें। आभासी पैच अस्थायी होते हैं; आधिकारिक पैच दीर्घकालिक समाधान होते हैं।.

अभी क्या करना है - अगले 60 मिनट के लिए कार्रवाई चेकलिस्ट

1. जांचें कि एक्सटर्नल लॉगिन स्थापित है और संस्करण नोट करें।.
2. यदि गैर-आवश्यक है, तो प्लगइन को निष्क्रिय करें और हटा दें।.
3. यदि हटाना संभव नहीं है:
   • प्लगइन फ़ोल्डर को सभी को अस्वीकार करने वाले वेब सर्वर नियमों के पीछे रखें, या
   • प्लगइन को लक्षित करने वाले SQLi पैटर्न को ब्लॉक करने के लिए WAF नियम लागू करें।.
4. जांच के लिए डेटाबेस और फ़ाइल सिस्टम का स्नैपशॉट लें।.
5. असामान्य व्यवस्थापक खातों और संदिग्ध लॉग की खोज करें।.
6. यदि समझौता होने का संदेह है, तो व्यवस्थापक और DB क्रेडेंशियल्स को बदलें।.
7. SQLi हस्ताक्षरों और शोषण के सबूत के लिए लॉग की निगरानी करें।.
8. दीर्घकालिक हार्डनिंग कदम लागू करें: न्यूनतम विशेषाधिकार, बैकअप, लॉगिंग, WAF।.

हांगकांग के सुरक्षा विशेषज्ञ से अंतिम विचार

यह एक्सटर्नल लॉगिन भेद्यता विशेष रूप से खतरनाक है क्योंकि यह दूरस्थ, बिना प्रमाणीकरण के है, और प्रमाणीकरण प्रवाह को प्रभावित करती है। हमलावर इसे प्राथमिकता देंगे। यदि आप वर्डप्रेस साइटों की मेज़बानी करते हैं या क्लाइंट साइटों का प्रबंधन करते हैं, तो अभी कार्रवाई करें: या तो प्लगइन को हटा दें या किनारे पर तत्काल सुरक्षा उपाय करें (आभासी पैच और सर्वर-स्तरीय ब्लॉक्स)। यदि आप समझौता होने का संदेह करते हैं, तो सबूत को संरक्षित करें और पूर्ण घटना प्रतिक्रिया करें।.

हांगकांग के व्यस्त होस्टिंग और वेब वातावरण में, तेज़, निर्णायक कार्रवाई प्रतिष्ठा और डेटा जोखिम को कम करती है। यदि आपको सहायता की आवश्यकता है, तो एक अनुभवी घटना प्रतिक्रिया प्रदाता या सुरक्षा परामर्शदाता से संपर्क करें ताकि वे उपाय लागू कर सकें और पूर्ण जांच कर सकें।.

सतर्क रहें, जल्दी कार्रवाई करें, और हर कदम का दस्तावेज़ीकरण करें।.