Google की नकली कॉल और ईमेल, auth code sync के ज़रिए 130,000 डॉलर की phishing ठगी का मामला

• एक उपयोगकर्ता ने Google support team के नाम पर आई कॉल और [e-mail] का रूप धारण करने वाले ईमेल के कारण phishing का शिकार होने का अनुभव साझा किया
• Google Authenticator के cloud sync feature के कारण हमलावर 2FA code तक हासिल करने में सफल रहे, जिसके बाद Coinbase account hack हुआ और cryptocurrency चोरी हो गई
• लगभग 40 मिनट में 80,000 डॉलर मूल्य की cryptocurrency (मौजूदा कीमत के अनुसार लगभग 130,000 डॉलर) चोरी हो गई
• Gmail की security कमजोरी और Authenticator की default sync setting को नुकसान बढ़ने का कारण बताया गया
• password नियमित रूप से बदलना, verification code कभी साझा न करना जैसे बुनियादी security नियमों का पालन और cloud sync को सावधानी से सेट करने की सलाह दी गई

---

एक फोन कॉल से शुरू हुई ठगी

• 19 जून को 'Pacifica, CA' area code (650) से कॉल आई
• सामने वाले ने खुद को Google support team का सदस्य बताया और रिपोर्ट की गई account transfer request का ज़िक्र किया, जिसमें death certificate और ID तक संलग्न होने की बात कही गई
• वास्तविक लगने वाले [e-mail] पते से ईमेल भेजा गया (sender name: Norman Zhu), जिससे वह official email जैसा लगा और भरोसा पैदा हुआ
• iOS Gmail app में @google.com sender indication और branding, case number आदि के साथ बहुत बारीकी से छद्म रूप बनाया गया था
• मृत्यु सत्यापन के बहाने temporary verification code की पुष्टि मांगी गई, और क्षणिक घबराहट में पीड़ित ने code बता दिया

हमलावर का Coinbase account तक पहुंचना

• कॉल के अंत में Google Advanced Security enrollment जैसी बातों से पीड़ित को आश्वस्त किया गया
• पीड़ित को लगा कि उसने security मजबूत कर ली है, लेकिन तब तक हमलावर Gmail, Drive, Photos और synced Authenticator codes तक पहुंच हासिल कर चुके थे
• Google Authenticator के cloud sync के जरिए 2FA code का चोरी होना निर्णायक साबित हुआ
• इसके तुरंत बाद हमलावर ने Coinbase account में login किया और cryptocurrency निकालना शुरू कर दिया

cryptocurrency चोरी और नुकसान का विवरण

• लगभग 40 मिनट के दौरान हमलावर ने कई transactions के जरिए ETH और अन्य tokens को अलग-अलग addresses पर transfer करके पूरा धन चुरा लिया
• उस समय की कीमत के अनुसार लगभग 80,000 डॉलर, और वर्तमान मानक के अनुसार लगभग 130,000 डॉलर का नुकसान हुआ
• 2 घंटे बाद Coinbase balance देखने पर खाता लगभग 0 हो चुका था, जिससे पीड़ित को गहरा झटका लगा
• Google account में नए device login history और recovery phone number बदले जाने जैसे अतिरिक्त संकेत भी मिले

security expert भी क्यों फंस सकता है

• पीड़ित ने बताया कि वह IT industry में काम करता है और authentication experience designer भी है
• security के प्रति जागरूकता होने के बावजूद, forged email और emergency situation का माहौल बनाकर किए गए phishing के सामने वह चूक गया

Google की 2 प्रमुख security गलतियां

1. ‘@google.com’ forged sender email को filter न कर पाना
   • email From field spoofing संभव थी, इसलिए वह official email जैसा दिखा; iOS Gmail app में full header देखना संभव नहीं था, जिससे तुरंत verification करना कठिन हो गया
2. Google Authenticator में cloud sync का default enabled होना
   • synced 2FA codes हमलावर के हाथ लग गए, जिससे असली 2-step verification की प्रभावशीलता खत्म हो गई
   • email, 2FA, documents, photos जैसी पूरी digital assets एक साथ उजागर हो गईं

• संदर्भ: Gmail और Google Authenticator को साथ में इस्तेमाल करने वाले उपयोगकर्ताओं के लिए 2FA मूल रूप से सुरक्षित न भी हो सकता है — इस बारे में चेतावनी दी गई

security नियम और सलाह

• आज ही password बदलें, और नियमित रूप से अपडेट करें (1.6 अरब से अधिक passwords के leak होने की घटनाएं जारी हैं)

• verification code कभी साझा न करें (हमलावर ‘urgency’ और ‘anxiety’ का इस्तेमाल करके मनोवैज्ञानिक दबाव बनाते हैं)

• Google Authenticator cloud sync का सावधानी से उपयोग करें

  • recovery आसान होती है, लेकिन management risk भी साथ आता है

• संदिग्ध कॉल से हमेशा सतर्क रहें

  • घबराहट हो तो तुरंत कॉल काटें और official channel से दोबारा संपर्क करें

• आशा है कि यह घटना जागरूकता बढ़ाने और ऐसे ही नुकसान को रोकने में मदद करेगी

अतिरिक्त विवरण और परिस्थितियां

• संभावना है कि हमलावर के पास हालिया 1.6 अरब password leak list से password पहले से मौजूद था
• पीड़ित ने स्वयं कहा कि उसने same password reuse नहीं किया था और password गोपनीय रखा था, लेकिन लंबे समय से password नहीं बदला गया था
• अनुमान है कि हमलावर ने recovery code हासिल कर 2FA verification को bypass किया

phishing email से जुड़ी जानकारी

• [e-mail] नाम से कई ईमेल मिले, लेकिन हमलावर ने email traces, trash, और recovery history तक पूरी तरह मिटा दी
• हालांकि, कुछ ईमेल [e-mail] पर forward किए गए थे; बाद में account access वापस लेने की प्रक्रिया में bounce mail के जरिए मूल संदेश सुरक्षित रखा जा सका
• [e-mail] email address वास्तव में मौजूद नहीं है या बाहर से पहुंच योग्य नहीं है
• मूल ईमेल का subject था ‘Google Recent Case Status’, और उसमें official format, naming, internal review guidance, temporary password storage जैसी सूचनाएं शामिल थीं
• उसमें ‘Norman Zhu’ नाम के support team signature, case number, और department information भी था

पूरा सार

• यह उन्नत प्रतिरूपण हमले और platform की संरचनात्मक कमियों के मेल से हुआ बड़े पैमाने का account takeover और cryptocurrency नुकसान का मामला है
• यह याद दिलाता है कि 2FA भी पूर्ण सुरक्षित क्षेत्र नहीं है
• पारंपरिक security समझ के अलावा platform-level policy review और service-specific अलग security settings की जरूरत को भी रेखांकित करता है

[GN⁺]

Hacker News की राय

• पिछले शुक्रवार मुझे भी ऐसा ही एक कॉल आया था, वह पूरी तरह वैध लग रहा था। मेरी काम की ट्रिक यह है कि मैं टिकट नंबर और आधिकारिक callback नंबर मांगता हूँ, ताकि जांच सकूँ कि क्या वह सचमुच कंपनी का नंबर है। अगर सच हो तो बातचीत जारी रख सकता हूँ, नहीं तो निश्चिंत हो जाता हूँ। कॉल करने वाले ने कहा कि वह "यह साबित करने के लिए कि यह आधिकारिक है" एक ईमेल भेज सकता है, लेकिन callback नंबर नहीं दिया, इसलिए मुझे तुरंत समझ आ गया कि यह धोखाधड़ी है। ईमेल पता या फोन नंबर आसानी से spoof किए जा सकते हैं। Caller ID सही दिखे तब भी उस पर कभी भरोसा नहीं करना चाहिए; हमेशा आधिकारिक नंबर पर खुद वापस कॉल करके पुष्टि करनी चाहिए।

  • मैं तो फोन नंबर भी सीधे नहीं लेता। हमेशा सामने वाले से कंपनी का नाम और शाखा पूछता हूँ, फिर खुद कंपनी की आधिकारिक वेबसाइट (जैसे https://amazon.com) पर जाकर नंबर ढूंढकर कॉल करता हूँ। थोड़ा असुविधाजनक है, लेकिन सुरक्षा कहीं ज्यादा मजबूत है।

  • आधिकारिक नंबर भी खोजकर जांचते समय सावधान रहना चाहिए। खोज परिणामों में नकली नंबर ऐसे वेबसाइटों पर मिल सकते हैं जो असली जैसे दिखते हैं। सच में यह बिना बंदूक-तलवार का युद्धक्षेत्र है।

  • "नंबर सही हो तब भी Caller ID का कोई मतलब नहीं होता" — मैंने भी कुछ साल पहले बैंक के एक कॉल पर यही बात कही थी, जब उन्होंने मेरी पहचान सत्यापित करने के लिए निजी जानकारी मांगी थी।

  • "आधिकारिक फोन नंबर" अच्छी सोच है, लेकिन अगर हमलावर के पास SS7 तक पहुंच हो, तो यह तरीका भी बेकार है।

• बार-बार याद रखने वाली बातें:

  • बड़ी कंपनियों की customer support टीम आपको खुद कॉल नहीं करती।

  • अगर कोई कॉल या ईमेल पर code मांगे, तो SMS से मिला verification code कभी न बताएं; संदेश में भी अक्सर यही लिखा होता है।

  • महत्वपूर्ण निजी जानकारी को सिर्फ एक password से सुरक्षित न रखें। Google खाते से जुड़े Google Authenticator को password management के लिए इस्तेमाल न करें; 1Password जैसे third-party विकल्प बेहतर हैं।

  • बैंक/निवेश के लिए इस्तेमाल होने वाला ईमेल और सार्वजनिक रूप से ज्ञात ईमेल हमेशा अलग रखें। Chrome profile भी ईमेल के हिसाब से अलग रखें, और extensions में सिर्फ password manager रहने दें।

  • लेकिन कुछ हफ्ते पहले मुझे बैंक support team बताकर एक ऐसे नंबर से कॉल आया जो search में नहीं मिलता था। उन्होंने SMS से आया verification code पढ़कर सुनाने को कहा। मैंने मना कर दिया, तो online banking block हो गई, और बाद में डाक से एक कड़ा पत्र आया कि "support agent से संवाद न करने के कारण खाता अपने-आप upgrade नहीं हो सकता"। आखिरकार मैंने app में नया खाता बनाया, उन्हें खुद कॉल किया, और SMS code फिर से पढ़कर सुनाया (!) — और वही नए खाते की verification की एकमात्र प्रक्रिया थी। दुनिया के top 100 बैंकों में से एक की यह कार्यप्रणाली है। लगता है कंपनियां खुद लोगों को धोखा खाने की ट्रेनिंग दे रही हैं। बैंक जर्मन था, लेकिन Chase भी फोन पर OTP code मांगने की यही आदत रखता है।

  • Google Nest Thermostat में energy-saving setting बंद कराने के लिए customer support ने मुझसे verification code मांगा था (यह वही feature है जिसमें बिजली कंपनी बचत के लिए तापमान नियंत्रित कर सकती है)। मैंने कहा, "संदेश में साफ लिखा है कि यह code किसी को न बताएं," तो support ने बस दूसरा तरीका बता दिया। मांग खुद ही अजीब थी।

  • Chase बैंक भी हाल तक fraud alert के सिलसिले में फोन पर ऐसे code मांगता रहा है। यही बात सबसे ज्यादा परेशान करने वाली है।

  • मैं अपना फोन आम तौर पर Do Not Disturb मोड पर रखता हूँ। सिर्फ पांच करीबी परिवारजन के कॉल पर घंटी बजती है। अनजान नंबर कभी नहीं उठाता; अगर वाकई जरूरी हो तो voicemail छोड़ें। लगता है कि कॉल उठाते ही हम तुरंत ठंडे दिमाग से फैसला नहीं कर पाते। यह सड़क पर रास्ता पूछकर घड़ी चुराने वाली चाल जैसा है। सुरक्षा इसका मुख्य उद्देश्य नहीं था, लेकिन bank tip और hackers से कम exposure मिलना अच्छा है।

  • दुर्भाग्य से कुछ call center वास्तव में पहचान सत्यापन के लिए कॉल के दौरान SMS/ईमेल से code भेजते हैं और फिर वही code वापस पढ़वाते हैं।

• यह हमला साधारण social engineering जैसा लगता है, और शायद इसमें email spoofing नहीं थी। संभव है कि ईमेल सचमुच Google की आधिकारिक प्रणाली से भेजा गया हो। मेरा अनुमान है कि हमलावर ने Google account recovery की आधिकारिक प्रक्रिया शुरू की, और उसी प्रक्रिया के तहत Google ने code वाला ईमेल भेजा। पीड़ित ने वह code पढ़कर बता दिया, जिससे हमलावर को Google account — और उससे जुड़े Gmail, Google Drive में backup किए गए authenticator app तक — पूरा access मिल गया। मैं उस ईमेल के raw header देखना चाहूंगा।

  • [e-mail] से आया ईमेल असली नहीं लगता। पहले पैराग्राफ और दूसरे पैराग्राफ की शुरुआत में व्याकरण की गलतियां हैं। legal team के ईमेल में ऐसी बुनियादी typo और punctuation error होना संभव नहीं लगता। अगर यह सचमुच आधिकारिक ईमेल होता, तो जरूर proofread किया गया होता। नकली है।

  • अगर ईमेल हमलावर ने भेजा था, तो फिर पीड़ित से code बताने की जरूरत क्यों पड़ी — यह समझ नहीं आता।

  • "Coinbase password reset" — Gmail को बैंक, crypto, domain जैसी महत्वपूर्ण सेवाओं से जोड़कर इस्तेमाल करना सचमुच खतरनाक है। मेरी भी ऐसी स्थिति रही है कि मैं अपना Google password जानता हूँ, लेकिन 2FA रास्ता रोक रहा है, इसलिए access नहीं मिल रहा।

• अनजान नंबर हो तो हमेशा शक करना चाहिए। अगर कुछ अजीब लगे, तो कॉल काटकर खुद कंपनी से संपर्क कर बातचीत दोबारा शुरू करने की सलाह से मैं सहमत हूँ। सोचकर देखूं तो जिन कॉल की उम्मीद नहीं होती, मैं उन्हें लगभग कभी नहीं उठाता, और शायद इसी वजह से बहुत से fraud से बचा हूँ। Google का Authenticator codes को cloud में sync करना, और नतीजतन हमलावर का Gmail, Drive, Photos, और authenticator app — सब तक पहुंच जाना, निराशाजनक है।

  • मैं आम तौर पर unknown number का कॉल नहीं उठाता, लेकिन कुछ दिन पहले "Amazon employee" बनकर किसी ने कॉल किया कि मेरे account से 6 लाख रुपये का iPhone खरीदा गया है। मैंने कहा, पहले अपनी पहचान साबित करो, और उनसे पूछा कि "मैंने हाल में कौन-सा सामान ऑर्डर किया था"। वे कुछ भी स्पष्ट नहीं बता पाए। 20 मिनट तक बात चली, फिर आखिर में उधर से गालियां देकर फोन काट दिया। साथ ही पीछे बहुत शोर भी सुनाई दे रहा था, जैसे आसपास और भी ऐसे fraud call चल रहे हों। समझ नहीं आता उन्होंने इतना लंबा समय क्यों बर्बाद किया।

  • ऐसे fraud में सबसे बड़ा red flag यही है कि "support team खुद पहले संपर्क करती है"। जब सच में कोई जरूरी काम हो और आप असली support team से बात करना चाहें, तब तो वे मिलते ही नहीं।

  • आजकल मेरा नियम है कि unknown number सीधे voicemail पर जाए। अगर जरूरी हो तो message और नंबर छोड़ें। जरूरत हुई तो मैं खुद वापस कॉल कर लूंगा। सिर्फ medical या delivery जैसी स्थितियां अपवाद हैं, जहां कॉल उठाना पड़ सकता है। मैं इसी तरह फ़िल्टर करता हूँ।

  • मैं 1–2 second rule इस्तेमाल करता हूँ। कॉल उठाकर hello कहता हूँ, और अगर 1–2 सेकंड में जवाब न आए तो काट देता हूँ। Scammer अक्सर call queue से connect होते हैं, इसलिए थोड़ा delay होता है, और उन्हें script पकड़ने में भी समय लगता है। सामान्य बातचीत की तरह तुरंत प्रतिक्रिया नहीं आती। जो कॉल तुरंत जवाब न दे, उसके spam होने की संभावना ज्यादा होती है।

  • सिर्फ अपने फोन में नहीं, मैंने अपने माता-पिता के फोन में भी unknown number पूरी तरह block कर रखे हैं। मैं उन्हें नियमित रूप से समझाता हूँ कि email fraud पर भरोसा न करें, फिर भी हर साल एक-दो बार मां घबराकर फोन करती हैं क्योंकि उन्हें कोई "पूरी तरह असली लगा" scam email मिल गया होता है।

• फोन न उठाना मेरा मूल सिद्धांत है। सच कहूं तो मैं Do Not Disturb चालू रखता हूँ और सिर्फ favorites के नंबरों को ringtone की अनुमति देता हूँ। जिसे सच में कोई जरूरी बात होगी — चाहे वैध हो या fraud — वह voicemail छोड़ देगा। अगर कोई खुद को किसी कंपनी से बताता है, तो मैं स्वतंत्र रूप से उसकी पुष्टि करता हूँ। ऐसे मामले दिखाते हैं कि जिन कॉल का मैंने अनुरोध नहीं किया, वे कितने भी विश्वसनीय क्यों न लगें, बातचीत शुरू ही नहीं करनी चाहिए। और Google account में कभी भी संवेदनशील जानकारी नहीं रखनी चाहिए। tech industry का अनुभव रखने वाला कोई भी व्यक्ति जानता होगा कि यह कितना जोखिम भरा है।

  • मैं भी spam call के खतरे अच्छी तरह जानता हूँ, यह समझाने की जरूरत नहीं। लेकिन मुझे लगता है कि लोग "बैंक security team जैसी जगह से असली fraud warning कॉल भी आ सकती है" इस संभावना को बहुत आसानी से खारिज कर देते हैं। हो सकता है मैं बैंक का नंबर पहचान न पाया हूँ, और यह भी निश्चित नहीं कि सही उत्तर हमेशा यही है।

  • मुझे सरकार या बैंक से सचमुच महत्वपूर्ण मामलों पर असली कॉल आए हैं (जैसे tax filing में गलती)। इसलिए मैं नहीं मानता कि कभी भी कॉल न उठाना ही एकमात्र सही जवाब है। वैसे यूरोप में voicemail लगभग इस्तेमाल ही नहीं होती; यह ज्यादा अमेरिकी संस्कृति लगती है।

• email spoofing के बिना भी crypto चोरी पूरी तरह संभव है। अपराधी बंदूक दिखाकर seed phrase मांग सकते हैं, और ऐसी घटनाएं वास्तव में हुई हैं। इसलिए पारंपरिक बैंक crypto की तुलना में कहीं ज्यादा सुरक्षित हैं। जिसने यह अनुभव साझा किया, उसने अच्छा किया; लेकिन असली सबक यह होना चाहिए कि crypto संपत्ति सुरक्षित रखने का भरोसेमंद माध्यम नहीं है।

  • फिर भी बंदूक लेकर घर तक आने की तुलना में फोन घुमाने वाला तरीका कहीं ज्यादा scalable है।

  • फिर भी Hacker News के अंदाज में देखें तो बंदूक दिखाकर धमकाना यहां मूल मुद्दा ही नहीं है।

  • crypto security में multisig उपयोगी है। उदाहरण के लिए 2-of-2 setup में आप किसी बैंक जैसे भरोसेमंद संस्थान के साथ signing authority साझा करें, तो अक्सर यह सामान्य बैंक से भी ज्यादा सुरक्षित हो सकता है। 3-of-5 जैसे कई key वाले setup में, अगर hardware token पर गलत PIN डालने से key मिट जाती हो, तो coercion जैसी स्थिति में भी कुछ सुरक्षा मिल सकती है।

  • multisig wallet ही समाधान है। और कई लोगों की मंजूरी से ही निकासी होने वाली व्यवस्था खर्च पर ब्रेक जैसा असर भी डालती है। हालांकि, जब कई लोग शामिल हों तो जोखिम उल्टा बढ़ भी सकता है। यदि offline cold wallet हो, तो hack करने में घंटों लग सकते हैं, जिससे समय मिल जाता है।

  • https://xkcd.com/538/ यह कॉमिक भी देखने लायक है।

• सबसे महत्वपूर्ण सवाल यह है कि हमलावर ने बैंक/पेंशन/credit card तक हाथ क्यों नहीं मारा। व्यवहार में बैंक ग्राहक खातों के compromise होने पर कहीं ज्यादा गंभीरता से प्रतिक्रिया देते हैं।

  • "बैंक परवाह करते हैं" का असली मतलब अक्सर यह होता है कि अगर आपने उचित सावधानी बरती हो और फिर भी खाता compromise हो जाए, तो वे क्षतिपूर्ति कर सकते हैं। इसी वजह से बैंक बड़े fraud amounts को लेकर ज्यादा सतर्क रहते हैं। वैसे 10 महीने पहले तक Reddit पर एक thread था जिसमें Coinbase + Google Authenticator को सबसे बेहतरीन security setup कहा गया था: कोइनबेस हैक घटना Reddit थ्रेड

  • दूसरी ओर, इसी कारण बैंक वगैरह ग्राहकों को सिर्फ ऐसे smartphone app से banking करने को मजबूर करते हैं जिनमें बहुत सख्त locking feature हो। समस्या यह है कि ग्राहक पर अविश्वास और ग्राहक पर पूरी जिम्मेदारी थोपने — इन दोनों के बीच संतुलन लगभग नहीं है।

  • बैंक या brokerage account से transfer में समय लगता है। उस दौरान अगर fraud का पता चल जाए और रिपोर्ट कर दिया जाए, तो खाता freeze हो सकता है, इसलिए तत्काल नुकसान रोकना अपेक्षाकृत आसान होता है।

  • हालांकि कुछ लोगों की राय है कि बैंक इस बारे में उतनी परवाह भी नहीं करते।

• घटनाक्रम थोड़ा अस्पष्ट है, इसलिए पूरी तरह समझ नहीं आता। अगर सिर्फ 2FA code से सब कुछ compromise हो गया, तो यह बहुत गंभीर समस्या है। यह भी संभव है कि पहले से password leak हुआ हो, password reuse हुआ हो, या बस Google account पहले से exposed हो। अगर सिर्फ 2FA code से Google account → authenticator app → password manager तक सब खुल गया, तो क्रमशः दूसरी सेवाओं का 2FA भी टूट सकता है। इस प्रक्रिया में password reuse था या नहीं, यही जानने की सबसे ज्यादा जिज्ञासा है। संदर्भ के लिए: मैं Google में काम करता हूँ, लेकिन security team में नहीं।

  • मेरा अंदाजा है कि हमलावर के पास पहले से मेरा password था, और अंत में उसे फोन पर सुनाया गया recovery code ही चाहिए था। मैंने password साझा नहीं किया था और reuse भी नहीं किया था, लेकिन उसे लंबे समय से बदला भी नहीं था।

  • password होने पर, अगर ईमेल और 2FA code भी नियंत्रण में आ जाएं, तो password reset के जरिए लगभग सभी account अपने कब्जे में लिए जा सकते हैं।

• लेख में ठोस तकनीकी विवरण की कमी है। 2025 में भी अगर Google @google.com जैसे "मिलते-जुलते" ईमेल को ठीक से block नहीं कर पा रहा, तो यह चिंता की बात है। कारण Unicode spoofing था, या DKIM जैसी authentication नहीं थी, या खुद account compromise था — यह स्पष्ट नहीं है। कुल मिलाकर कहानी में कई बातें मेल नहीं खातीं।

  • Unicode domain name का विचार ही शायद कभी ठीक से काम नहीं किया। व्यवहार में ऐसी चीजों का उपयोग ज्यादातर scammers और अपराधी करते हैं। ICANN को लेकर तंज कसने जैसा मन होता है।

  • यह भी अजीब है कि मूल पोस्ट में यह नहीं बताया गया कि ईमेल कैसे google domain से आया हुआ दिखा। लेखक ने खुद को security industry से बताया, फिर भी विस्तार न देना सवाल खड़े करता है।

• यह भी ध्यान खींचा गया कि किसी ने यह सीधी सलाह नहीं दी: "Coinbase account में लाखों डॉलर मत रखो।"

  • मैंने अपना crypto Coinbase और एक खराब हो चुकी hard disk — इन दो जगहों में बांट रखा था, और अब hard disk recover ही नहीं हो रही।

  • बेहतर सलाह यह है कि crypto में निवेश ही न करें। सट्टेबाजी और money laundering के अलावा इसमें वास्तविक उपयोगिता ढूंढना कठिन है, और जोखिम बहुत हैं।