
CERT-In चेतावनी: वैध API कुंजी से भी फर्जी भुगतान निकल रहे हैं

भारत की साइबर सुरक्षा एजेंसी CERT-In/CSIRT-Fin ने 9 अक्टूबर 2026 के गंभीर परामर्श में बताया कि हमलावर भुगतान से जुड़े क्रेडेंशियल चुराकर वित्तीय संस्थाओं के अपने अनुमत ढाँचे से धन-अंतरण API चला रहे हैं। एजेंसी ने गैर-बैंकिंग वित्तीय कंपनियों, डिजिटल ऋण मंचों, फिनटेक संस्थाओं, भुगतान सेवा प्रदाताओं और वॉलेट संचालकों को निशाना बनाने वाले कई अभियान देखे हैं। इन हमलों में अनुरोध तकनीकी रूप से अधिकृत रास्ते से निकलता है, लेकिन उससे जुड़ा भुगतान स्वीकृत नहीं होता।
Breachroad की 10 अक्टूबर की सुरक्षा समीक्षा इस चूक को स्पष्ट करती है: वैध टोकन और अनुमत IP पता किसी भुगतान की व्यावसायिक मंजूरी नहीं देते। ऋण या भुगतान प्रणाली में मंजूरी का आधार स्वीकृत मामला, तय राशि और सत्यापित लाभार्थी होना चाहिए। हमलावर सीधे अंतिम API तक पहुँच जाए तो ग्राहक सत्यापन, ऋण स्वीकृति और लाभार्थी जाँच जैसे बीच के चरण छूट सकते हैं।
घुसपैठ से बैंक अंतरण तक क्या हुआ

प्रवेश के कई रास्ते दर्ज किए गए हैं: इंटरनेट से खुले अनुप्रयोग, पुराने या बिना प्रमाणीकरण वाले API, अनियंत्रित फ़ाइल अपलोड और दूरस्थ सेवाएँ जिन पर बहु-कारक प्रमाणीकरण लागू नहीं था। स्रोत कोड में रखे लंबे समय तक चलने वाले टोकन और विन्यास फ़ाइलों में खुले क्रेडेंशियल भी जोखिम बने। स्रोत कोड भंडार में जाली बदलाव को चेतावनी ने आपूर्ति शृंखला से जुड़े एक संभावित प्रवेश मार्ग के रूप में गिनाया है। विकास और सुरक्षा टीमों के लिए इन रास्तों का महत्व इस बात में है कि कोई प्रवेश बिंदु भुगतान कुंजी तक पहुँच देता है या नहीं।
प्रणाली में प्रवेश के बाद हमलावर छिपे पहुँच-मार्ग बनाते हैं, भुगतान डेटाबेस और बैंक से जुड़े संयोजन खोजते हैं, फिर भुगतान गेटवे, एग्रीगेटर या साझेदार बैंक के क्रेडेंशियल हासिल करते हैं। चोरी की कुंजी से संस्था के अनुमत सर्वर पर किया गया API अनुरोध सामान्य तकनीकी जाँच पार कर सकता है। इसके बाद भी उस अनुरोध का किसी वास्तविक ऋण या स्वीकृत भुगतान आदेश से संबंध सिद्ध नहीं होता। यही वह बिंदु है जहाँ प्रवेश नियंत्रण की विफलता सीधे वित्तीय नुकसान में बदलती है।
देखे गए फर्जी अंतरणों में ऐसे ऋण या लेनदेन संदर्भ अंक थे जिनसे कोई वास्तविक रिकॉर्ड नहीं जुड़ा था। कुछ भुगतान प्रति लेनदेन सीमा से ऊपर गए; IMPS और NEFT के रास्ते कई बड़े अंतरण तेजी से हुए और रकम अलग-अलग बैंकों के ऐसे खातों में पहुँची जहाँ से तुरंत निकासी की गई। प्रारंभिक घुसपैठ से फर्जी अंतरण तक का अंतराल हाल के मामलों में घटा है। परामर्श ने आक्रामक औजारों में AI के संभावित इस्तेमाल का उल्लेख किया है, इसे किसी खास औजार के पुष्ट इस्तेमाल के रूप में प्रस्तुत नहीं किया है।
अनुमत सर्वर पर मंजूरी की जाँच कहाँ टूटी

कुंजी अनुरोध भेजने वाले संयोजन की पहचान करती है; वह यह तय नहीं करती कि धन किस खाते में, कितनी राशि में और किस स्वीकृत मामले के तहत जाना चाहिए। यदि अंतिम भुगतान API केवल सही कुंजी और अनुमत स्रोत पर भरोसा करे, तो हमलावर ऋण निर्माण या भुगतान मंजूरी के सामान्य क्रम से गुजरे बिना अंतरण शुरू कर सकता है। संदर्भ अंक का प्रारूप सही दिखना भी पर्याप्त नहीं है: उसका स्वीकृत रिकॉर्ड से वास्तविक मेल होना चाहिए।
इसलिए अंतिम भुगतान चरण पर सर्वर को स्वीकृत मामले, राशि, उपलब्ध शेष, मंजूरी की स्थिति और लाभार्थी खाते का संबंध दोबारा जाँचना होगा। चरणों को इस तरह जोड़ना होगा कि पहले की वैध जाँच के बिना धन भेजने वाला चरण चल ही न सके। परामर्श दूसरी मंजूरी, प्रति लेनदेन तथा दैनिक कुल सीमा और लाभार्थी के नाम व खाते के मिलान की सलाह देता है। इन नियमों का असर उसी बिंदु पर होना चाहिए जहाँ अंतरण जारी होता है; आवेदन के किसी पहले चरण में दर्ज स्वीकृति अपने आप अंतिम अनुरोध को सही नहीं बनाती।
OWASP के लेनदेन-अनुमोदन निर्देश सर्वर पर मंजूरी लागू करने, चरणों का क्रम नियंत्रित करने और निष्पादन से ठीक पहले अंतिम जाँच रखने को कहते हैं। भुगतान संयोजन में इसका सीधा अर्थ है कि अनुरोध के साथ भेजे गए संदर्भ अंक या लाभार्थी विवरण को अकेले प्रमाण न माना जाए। सर्वर पर रखे स्वीकृत रिकॉर्ड से उनका मेल न मिले तो वैध कुंजी वाला अनुरोध भी रोका जाए।
किस टीम को कौन-सा नियंत्रण संभालना है
कुंजी चोरी रोकने की जिम्मेदारी मुख्यतः सुरक्षा और विकास टीमों की है। उन्हें सभी API की सूची रखनी, पुराने रास्ते बंद करने, बहु-कारक प्रमाणीकरण लागू करने, स्थायी टोकन हटाने और क्रेडेंशियल सुरक्षित भंडार में रखने की व्यवस्था करनी होगी। उत्पादन सर्वर से बाहर जाने वाले संपर्क सीमित करने और कुंजी बदलने की प्रक्रिया भी इसी परत में आती है। इन उपायों से हमलावर का प्रवेश और क्रेडेंशियल दुरुपयोग कठिन होता है, जबकि भुगतान की मंजूरी का निर्णय अलग नियंत्रण माँगता है।
विकास टीम को धन-अंतरण API पर स्वीकृत रिकॉर्ड से मेल और चरणबद्ध मंजूरी लागू करनी होगी। वित्त तथा ऋण संचालन टीमों को तय करना होगा कि किस रिकॉर्ड को भुगतान का आधार माना जाएगा, दूसरी मंजूरी कौन देगा और लाभार्थी का नाम तथा खाता किस नियम से सत्यापित होंगे। राशि और दैनिक कुल अंतरण की सीमाएँ भी अंतिम भुगतान चरण पर लागू होनी चाहिए। इस तरह तकनीकी टीम जाँच को लागू करती है और भुगतान के लिए जिम्मेदार टीम उसके व्यावसायिक नियम तय करती है।
जोखिम और धोखाधड़ी रोकथाम टीम के लिए नए लाभार्थी, असामान्य राशि और थोड़े समय में लगातार भुगतान निगरानी के संकेत हैं। ऐसे अनुरोध को स्वतः रोकना है, कुछ समय के लिए थामना है या दूसरी मंजूरी तक भेजना है, इसका निर्णय पहले से भुगतान प्रक्रिया में दर्ज होना चाहिए। बैंक या भुगतान भागीदार से आने वाला वास्तविक अंतरण विवरण उसी मामले की आंतरिक स्वीकृति से जुड़ सके, तभी सफल API कॉल की वित्तीय वजह खोजी जा सकती है।
तेज़ मिलान और साक्ष्य-सुरक्षा

प्राप्तकर्ता खातों से तत्काल निकासी के दर्ज पैटर्न के कारण दिन के अंत में होने वाला हिसाब देर से चेतावनी दे सकता है। वित्त संचालन को स्वीकृत भुगतान रिकॉर्ड का बैंक या एग्रीगेटर के विवरण से लगभग वास्तविक समय में मिलान करना चाहिए। ऐसा संदर्भ अंक जिसके पीछे स्वीकृत मामला नहीं है, अलग राशि या नया लाभार्थी तत्काल जाँच योग्य है। मिलान का उद्देश्य केवल लेखांकन की गलती पकड़ना नहीं, बल्कि निकासी आगे बढ़ने से पहले संदिग्ध अंतरण को अलग करना है।
Moneycontrol की 10 अक्टूबर की रिपोर्ट में केंद्रीकृत लॉग कम से कम 180 दिन रखने की सलाह दर्ज है। यह व्यवस्था इसलिए अहम है कि देखे गए हमलों में लॉग मिटाने या छोटे करने और सुरक्षा उपकरणों से छेड़छाड़ के प्रयास भी शामिल थे। भुगतान आदेश, API अनुरोध, कुंजी उपयोग और बैंक से मिले परिणाम का क्रम सुरक्षित रहे तो घटना प्रतिक्रिया टीम यह पता लगा सकती है कि अनधिकृत अनुरोध कहाँ से निकला और किन नियंत्रणों को पार कर गया।
संदिग्ध गतिविधि मिलने पर प्रभावित खाते और API रोकने, साक्ष्य बचाने, क्रेडेंशियल बदलने और संबंधित लॉग के साथ CERT-In/CSIRT-Fin को शीघ्र सूचना देने की सलाह दी गई है। संस्था के लिए सबसे तात्कालिक परिणाम यह है कि अनुमत सर्वर से निकले हर भुगतान को स्वीकृत मामले और लाभार्थी से जोड़कर साबित करना होगा। जिस अंतरण का यह संबंध नहीं मिलता, उसे बैंक विवरण में बाद में खोजने के बजाय धन भेजने वाले चरण पर ही रोकना होगा।
यह भी पढ़ें:
संबंधित लेख


DigitalOcean या AWS Lightsail: बंद सर्वर भी बिल का फैसला बदलता है

Gupshup का Avatar Agent आया—वीडियो चेहरा भरोसा साबित नहीं करता

Razorpay या Paytm: शून्य सेटअप के बाद हर भुगतान बराबर नहीं

Google Colab या Kaggle: मुफ्त GPU में तय सीमा बनाम अनिश्चित उपलब्धता

Hugging Face या Replicate: सस्ता GPU उपयोग दर बदलते ही पलटता है
हमारे न्यूज़लेटर की सदस्यता लें
Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।