Vercel उल्लंघन: OAuth हमले ने platform environment variables के छिपे जोखिम को उजागर किया

 (trendmicro.com)
2 पॉइंट द्वारा GN⁺ 8 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • OAuth सप्लाई चेन उल्लंघन Vercel के आंतरिक सिस्टम तक पहुंच का कारण बना, और सीमित संख्या में कुछ ग्राहक प्रोजेक्ट्स के environment variables के उजागर होने की घटना हुई
  • शुरुआत Context.ai के एक कर्मचारी के Lumma Stealer संक्रमण से हुई, और लीक हुए Google Workspace OAuth टोकन का उपयोग Vercel कर्मचारी अकाउंट तथा आंतरिक सिस्टम तक पहुंच के लिए किया गया
  • हमलावरों ने ग्राहक प्रोजेक्ट्स के environment variables को enumerate करने की अनुमति हासिल कर ली, और खास तौर पर non-sensitive के रूप में चिह्नित variables के जरिए downstream service credentials के उजागर होने की संभावना बढ़ गई
  • सार्वजनिक रूप से उपलब्ध संकेतों के अनुसार, कम-से-कम एक मामले में Vercel के सार्वजनिक खुलासे से पहले लीक हुई API key की पहचान हो चुकी थी, और पहचान व सूचना के बीच का समय अंतर एक प्रमुख जोखिम कारक के रूप में उभरा
  • यह उल्लंघन दिखाता है कि OAuth trust relationship और platform environment variable storage का तरीका मिलकर पूरे सप्लाई चेन में credentials के फैलाव का कारण बन सकता है

मुख्य निहितार्थ

  • OAuth amplification effect की पुष्टि
    • एक OAuth trust relationship के समझौता होने से vendor से Vercel के आंतरिक सिस्टम तक क्रमिक विस्तार हुआ
    • समझौता किए गए vendor से सीधे संबंधित न होने वाले ग्राहक प्रोजेक्ट्स के environment variables भी सीमित रूप से उजागर हुए
  • AI-accelerated attack activity की संभावना उठी
    • CEO ने हमलावर की असामान्य गति को AI augmentation से जोड़ते हुए सार्वजनिक बयान दिया
    • हालांकि यह मूल्यांकन आधिकारिक forensic निष्कर्ष नहीं, बल्कि सार्वजनिक टिप्पणी के स्तर का है
  • Detection से public disclosure तक की देरी पर जोर
    • कम-से-कम एक सार्वजनिक ग्राहक रिपोर्ट में Vercel के खुलासे से 9 दिन पहले लीक हुई key की पहचान के संकेत मौजूद थे
    • platform उल्लंघन में detection के बाद notification delay को एक महत्वपूर्ण जोखिम कारक बताया गया
  • 2026 के व्यापक पैटर्न से जुड़ाव
    • LiteLLM, Axios, Codecov, CircleCI के साथ यह developer-stored credentials को निशाना बनाने वाली सप्लाई चेन प्रवृत्ति से मेल खाता है

घटना की टाइमलाइन

  • लगभग फरवरी 2026 में, Context.ai का एक कर्मचारी Lumma Stealer से संक्रमित हुआ, जिससे enterprise credentials, session tokens और OAuth tokens लीक हुए
  • लगभग मार्च 2026 में, हमलावर ने Context.ai के AWS environment तक पहुंच बनाई और consumer users के लिए OAuth tokens चुरा लिए
    • इनमें Vercel कर्मचारी का Google Workspace token भी शामिल था
  • मार्च 2026 में, चुराए गए OAuth token के जरिए Vercel कर्मचारी के Google Workspace account तक पहुंच हुई
  • मार्च से अप्रैल 2026 तक, Vercel के आंतरिक सिस्टम में आगे बढ़ने के बाद ग्राहक environment variables की enumeration शुरू हुई
  • लगभग अप्रैल 2026 में, ShinyHunters से जुड़े actor द्वारा Vercel डेटा बेचना शुरू करने का दावा सामने आया
  • 10 अप्रैल 2026 को, एक Vercel ग्राहक ने OpenAI से लीक हुई API key के बारे में alert मिलने की बात सार्वजनिक रूप से कही
  • 19 अप्रैल 2026 को, Vercel ने security notice पोस्ट किया और X thread सार्वजनिक किया
  • 19 अप्रैल 2026 के बाद, ग्राहक notification, credential rotation guidance और dashboard changes की rollout प्रक्रिया चली
  • लगभग 2 महीने की अपेक्षाकृत छोटी dwell time के बावजूद, third-party vendor infection से ग्राहक environment variables के लीक तक पहुंचने की गति की पुष्टि हुई
  • Google Workspace OAuth audit logs की default retention अवधि कई plans में 6 महीने होती है
    • इस बार की लगभग 2 महीने की dwell time के logs उस retention window के भीतर होने की संभावना है
    • साथ ही यह भी इंगित किया गया कि अधिक लंबी अवधि वाले समान उल्लंघन default retention अवधि से बाहर जा सकते हैं

attack chain

  • चरण 1: third-party OAuth उल्लंघन

    • Context.ai के पास Vercel कर्मचारी द्वारा approve किया गया Google Workspace OAuth application था
    • इस application का compromise लगभग फरवरी 2026 में Context.ai कर्मचारी के Lumma Stealer संक्रमण तक ट्रेस किया गया
    • Hudson Rock और CyberScoop की रिपोर्ट के अनुसार, संबंधित कर्मचारी Roblox game exploit script डाउनलोड करने के बाद संक्रमित हुआ था
    • चुराए गए credentials के जरिए हमलावर ने Context.ai के AWS environment तक पहुंच बनाई, और जून 2025 में लॉन्च किए गए Context AI Office Suite के consumer users के OAuth tokens लीक किए
    • Context.ai ने घोषणा की कि उसने मार्च 2026 में AWS environment में unauthorized access का पता लगाकर उसे रोक दिया था
    • हालांकि यह स्पष्ट किया गया कि OAuth token leakage की पहचान Vercel की जांच से पहले नहीं हुई थी
    • approved OAuth applications में आम तौर पर ये विशेषताएं होती हैं
      • user password की आवश्यकता नहीं
      • password बदलने के बाद भी टिके रह सकते हैं
      • email, Drive, calendar आदि के लिए अक्सर व्यापक permissions होती हैं
      • शुरुआती approval के बाद इनका audit कम ही होता है

  • चरण 2: Workspace account takeover

    • compromise किए गए OAuth application access के जरिए Vercel कर्मचारी के Google Workspace account तक बढ़त बनाई गई
    • इससे email access, Google Drive के आंतरिक दस्तावेजों तक पहुंच, calendar और जुड़े resources की visibility, और अन्य OAuth-connected services तक पहुंच की संभावना मिली

  • चरण 3: आंतरिक सिस्टम तक पहुंच

    • compromise किए गए Workspace account से Vercel के आंतरिक सिस्टम तक अतिरिक्त movement हुआ
    • Rauch ने कहा कि escalation की यह श्रृंखला उनके एक सहकर्मी के compromise हुए Vercel Google Workspace account से शुरू हुई थी
    • specific lateral movement techniques सार्वजनिक नहीं की गईं
      • SSO integration
      • email या Drive से जुटाए गए credentials
      • अन्य OAuth-connected internal tools
      • इनमें से कौन-सा इस्तेमाल हुआ, यह सार्वजनिक नहीं किया गया

  • चरण 4: environment variables की enumeration

    • हमलावरों ने Vercel के आंतरिक सिस्टम तक इतने अधिकारों के साथ पहुंच बनाई कि वे ग्राहक प्रोजेक्ट्स के environment variables को enumerate कर सकें
    • Vercel ग्राहक environment variables को स्टोर करते समय “non-sensitive” designation की सुविधा देता है
    • सार्वजनिक बयानों के अनुसार, सभी ग्राहक environment variables एक ही तरीके से सुरक्षित नहीं थे, और sensitive के रूप में चिह्नित न किए गए variables की enumeration के जरिए अतिरिक्त access हासिल हुआ

  • चरण 5: downstream services के दुरुपयोग की संभावना

    • उजागर हुए environment variables में आम तौर पर downstream services के credentials शामिल होते हैं
    • Andrey Zagoruiko की 19 अप्रैल 2026 की सार्वजनिक रिपोर्ट के अनुसार, उन्हें 10 अप्रैल को OpenAI की ओर से leaked key warning मिली थी
    • रिपोर्ट करने वाले के दावे के अनुसार, वह key Vercel के अलावा कहीं और मौजूद नहीं थी
    • इससे यह संभावना उठती है कि कम-से-कम एक उजागर credential का बाहरी तौर पर पता Vercel के सार्वजनिक खुलासे से पहले चल गया था

public disclosure के समय का 9 दिन का अंतर

  • Guillermo Rauch के 19 अप्रैल के X thread के जवाब में ग्राहक Andrey Zagoruiko ने 10 अप्रैल 2026 को OpenAI से leaked key alert मिलने की बात सार्वजनिक की
  • OpenAI की leaked credentials detection आम तौर पर तब काम करती है जब वे GitHub, paste sites जैसी सार्वजनिक जगहों पर मिलती हैं
  • लेख के अनुसार, Vercel environment variables से OpenAI alert तक पहुंचने वाला रास्ता सीधा नहीं माना गया
  • तारीखों के आधार पर, सबसे शुरुआती सार्वजनिक exposure evidence और Vercel के खुलासे के बीच 9 दिन की window मौजूद थी

  • यह 9 दिन का अंतर क्या मतलब रखता है और क्या नहीं

    • यह एकल सार्वजनिक रिपोर्ट है, forensic रूप से पुष्टि किया गया निष्कर्ष नहीं
    • इसे इस बात के प्रमाण के रूप में नहीं पढ़ा जाना चाहिए कि Vercel को 10 अप्रैल को ही उल्लंघन की जानकारी थी
    • लेकिन इससे कम-से-कम एक credential के बारे में यह संकेत मिलता है कि ग्राहक को secret rotation सूचना मिलने से पहले बाहरी तौर पर उसका पता चल चुका था

  • अलग-अलग stakeholders के लिए संकेत

    • regulators
      • GDPR के तहत controller को उल्लंघन की जानकारी होने के समय से 72 घंटे की notification clock शुरू होती है
      • Vercel को वास्तव में कब जानकारी हुई, यह एक सार्वजनिक मुद्दा बनकर उभरा
    • auditors
      • SOC 2 और ISO 27001 evaluators detection-to-notification delay को continuous monitoring evidence के रूप में देख सकते हैं
    • customers
      • यह मानकर नहीं चला जा सकता कि exposure window 19 अप्रैल से शुरू हुई थी
      • लेख के अनुसार, इससे पहले भी सक्रिय दुरुपयोग हुआ हो सकता है
    • providers द्वारा भेजे गए leaked credential alerts की शुरुआती चेतावनी चैनल के रूप में अहमियत बढ़ी
    • उदाहरणों में OpenAI, Anthropic, GitHub, AWS, Stripe शामिल हैं

AI-त्वरित हमलावर गतिविधि

  • Guillermo Rauch ने 19 अप्रैल 2026 को X पर कहा कि उन्हें गहरा संदेह है कि हमला करने वाला समूह बेहद परिष्कृत था और AI की वजह से काफी तेज हुआ था
  • लेख इस बयान को प्रभावित प्लेटफ़ॉर्म के CEO के सार्वजनिक रिकॉर्ड पर दर्ज आकलन के रूप में लेता है और सावधानीपूर्वक समीक्षा की आवश्यकता का उल्लेख करता है

  • फॉरेंसिक साक्ष्य में अपेक्षित हो सकने वाले संकेत

    • मैनुअल गति से आगे निकल जाने वाली enumeration speed
      • इसका कुछ हिस्सा केवल scripting से भी समझाया जा सकता है
      • LLM-आधारित reconnaissance schema exploration, endpoint probing, और credential format recognition को parallelize कर सकता है
    • context-aware query construction
      • बिना स्पष्ट पूर्व reconnaissance के भी ऐसी queries जो Vercel-विशिष्ट शब्दावली, project slug, deployment target names, और env var naming rules जानती हों
    • error response adaptability
      • API errors और rate limit के बाद strategy बदलना static scripts की तुलना में अधिक लचीला होता है
    • स्थानीयकृत लगने वाले social engineering outputs
      • phishing lures, commit messages, और support tickets की गुणवत्ता अनुवादित टेक्स्ट या templates की बजाय स्थानीय संदर्भ के अधिक करीब होना

  • Vercel घटना से आगे इसका महत्व

    • यह आकलन औपचारिक फॉरेंसिक में बना रहता है या नहीं, इससे अलग AI-augmented attack operations अब केवल अनुमान भर नहीं रह गए हैं
    • Microsoft ने अप्रैल 2026 की घोषणा में AI-आधारित device-code phishing, dynamic code generation, hyper-personalized lures, और backend automation orchestration के उदाहरण दस्तावेज़ित किए
    • यह भी कहा गया कि मानव-गति मानकों पर बनी telemetry baselines, AI-त्वरित ऑपरेटरों के मामले में false negative दे सकती हैं

  • detection engineering के निहितार्थ

    • अगर enumeration और lateral movement compression होता है, तो dwell time और velocity threshold पर आधारित मौजूदा rules कम alert दे सकते हैं
    • निम्नलिखित मदों की पुनर्समीक्षा की आवश्यकता बताई गई है
      • प्रति session unique resource enumeration की दर
      • errors के मुकाबले successful recovery curve
      • कम समय में query pattern diversity

environment variable डिज़ाइन की मुख्य कमज़ोरी

  • लेख में सबसे गंभीर पहलू शुरुआती access vector से भी ज़्यादा Vercel का environment variable sensitivity model है

  • उस समय Vercel environment variables कैसे काम करते थे

    • projects serverless functions और build process में environment variables inject करते थे
    • हर variable के लिए sensitive flag मौजूद था
    • default value non-sensitive थी
    • sensitive को स्पष्ट रूप से enable करना पड़ता था
    • non-sensitive variables dashboard में दिखाई देते थे
    • sensitive variables creation के बाद masked हो जाते थे
    • internal API के ज़रिए access non-sensitive के लिए संभव था, sensitive के लिए सीमित
    • सार्वजनिक बयानों के अनुसार encrypted storage non-sensitive पर लागू नहीं था, जबकि sensitive पर अतिरिक्त restrictions के साथ लागू था
    • इस breach में जिन targets तक हमलावर पहुँचे, वे non-sensitive के रूप में चिह्नित थे

  • निर्णायक design choice

    • sensitive flag डिफ़ॉल्ट रूप से बंद था
    • जिन DATABASE_URL, API_KEY, STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY को developers ने स्पष्ट रूप से चालू नहीं किया था, वे सभी Vercel के internal access model में unencrypted रूप में संग्रहीत थे
    • हर secret के लिए explicit opt-in माँगने वाला और default protection व guardrails से रहित security control व्यवहार में कम adoption पाता है, ऐसा आकलन किया गया

  • Vercel की प्रतिक्रिया

    • environment variable overview page और sensitive variable creation/management UI में सुधार deploy किए जाने की पुष्टि हुई
    • visibility के लिहाज़ से सुधार हुए, लेकिन लेखन के समय तक default में बदलाव नहीं हुआ था
    • अब भी हर variable के लिए opt-in आवश्यक है
    • default switch किया जाएगा या नहीं, यह सार्वजनिक प्रश्न बना हुआ है

  • उद्योग तुलना

    • उद्योग dedicated secret stores जैसे Vault, AWS Secrets Manager, Doppler, और Infisical की ओर बढ़ रहा है
    • Vercel के environment variable-आधारित approach की तुलना में dedicated secret management architecture चुनने के पक्ष में इस घटना को समर्थनकारी माना गया
    • तुलना तालिका के अनुसार
      • Vercel में non-sensitive default है, auto-detection नहीं है
      • AWS SSM Parameter Store में SecureString support है
      • HashiCorp Vault सभी secrets के लिए encryption और ACL देता है
      • GitHub Actions सभी secrets के लिए log masking करता है
      • Netlify environment variable approach उपयोग करता है जिसमें secret toggle होता है

credential fan-out और downstream जोखिम

  • Credential fan-out वह स्थिति है जिसमें एक platform breach उस प्लेटफ़ॉर्म में संग्रहीत credentials द्वारा प्रमाणित सभी downstream services तक श्रृंखलाबद्ध exposure पैदा कर देता है
  • Vercel project environment variables में अक्सर शामिल हो सकने वाली चीज़ें और उनका downstream प्रभाव
    • database
      • DATABASE_URL, POSTGRES_PASSWORD
      • पूरे data तक पहुँच की संभावना
    • cloud
      • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
      • cloud account compromise की संभावना
    • payments
      • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
      • financial data और refund fraud का जोखिम
    • authentication
      • AUTH0_SECRET, NEXTAUTH_SECRET
      • session forgery और account takeover की संभावना
    • email sending
      • SENDGRID_API_KEY, POSTMARK_TOKEN
      • trusted domain के आधार पर phishing की संभावना
    • monitoring
      • DATADOG_API_KEY, SENTRY_DSN
      • telemetry manipulation की संभावना
    • source और package
      • GITHUB_TOKEN, NPM_TOKEN
      • supply-chain injection की संभावना
    • AI/ML
      • OPENAI_API_KEY, ANTHROPIC_API_KEY
      • API abuse और लागत उत्पन्न होने की संभावना
  • एक अकेले Vercel project में आम तौर पर 10–30 environment variables होते हैं
  • संगठन स्तर पर 50-project portfolio में platform पर 500–1,500 credentials मौजूद हो सकते हैं
  • कहा गया है कि इस घटना में केवल कुछ सीमित customer projects तक पहुँच हुई, लेकिन हर exposed credential किसी अलग system में आगे बढ़ने का बिंदु बन सकता है
  • लेख इस पहलू को platform breach को केवल confidentiality incident नहीं बल्कि पूरी software supply chain में फैलने वाला multiplier effect बताता है

OAuth trust relationship और boundary defense bypass

  • OAuth-आधारित intrusion पारंपरिक credential-आधारित हमलों को detect/block करने वाले कई controls को bypass कर जाता है
  • लेख में लगभग 22 महीने की बात है, लेकिन ऊपर दिए गए correction में dwell time को लगभग 2 महीने बताया गया है
  • यह वर्णित है कि security teams जिन defense controls पर बाएँ कॉलम में निर्भर रहती हैं, वे OAuth app compromise path में या तो अर्थहीन हो जाते हैं या पहले से ही satisfied condition बन जाते हैं
  • इसी asymmetry के कारण OAuth governance IAM से अलग एक security domain के रूप में उभर रहा है

  • OAuth governance vendor risk function है

    • कई संगठन OAuth approval को developer self-service मुद्दा मानते हैं
    • यह कर्मचारियों द्वारा आवश्यक tools की approval और न्यूनतम central review तक सीमित रहता है
    • इस घटना को इस बात के आधार के रूप में पेश किया गया है कि approved OAuth apps को लगातार access privileges वाले third-party vendors की तरह संभालना चाहिए
    • vendor review, periodic re-approval, और anomalous usage monitoring की आवश्यकता है

खतरा पैदा करने वाले पक्ष के दावे और attribution

  • यह मानकर चलना चाहिए कि underground forum पर खतरा पैदा करने वाले पक्ष के दावे स्वभावतः भरोसेमंद नहीं होते
  • यहां की जानकारी की पुष्टि किए गए तथ्य के रूप में नहीं, बल्कि पहचान और ट्रैकिंग के उद्देश्य से व्यवस्थित की गई है

  • ShinyHunters से जुड़े होने का दावा

    • BreachForums पोस्ट करने वाले ने ShinyHunters से जुड़े होने का दावा किया और कहा कि उसके पास Vercel का डेटा है
    • दावा किए गए डेटा आइटम
      • लगभग 580 कर्मचारी रिकॉर्ड
      • source code repository
      • API keys और internal tokens
      • GitHub और NPM tokens
      • internal communications
      • Linear workspace access
    • ऊपर दी गई मात्रा और दायरा, दोनों ही सत्यापित नहीं हैं

  • Attribution को कठिन बनाने वाले कारक

    • ShinyHunters के ज्ञात सदस्यों ने BleepingComputer से अपनी संलिप्तता से इनकार किया
    • Telegram के जरिए 20 लाख डॉलर की ransom demand किए जाने का दावा मौजूद है
    • ShinyHunters brand मूल campaign के बाद से कई या असंबंधित पक्षों द्वारा इस्तेमाल किया जाता रहा है
    • Vercel की security advisory में उस forum दावे का कोई उल्लेख नहीं है
    • Rauch का thread attack chain पर बात करता है, लेकिन forum post को सीधे नहीं उठाता

  • supply chain release path पर Vercel का रुख

    • Rauch ने Next.js, Turbopack और कई open source projects की supply chain का विश्लेषण किया और community से कहा कि वे सुरक्षित हैं
    • लेखन के समय तक independent verification जारी है
    • सलाह दी गई है कि Next.js, Turbopack और अन्य Vercel open source का उपयोग करने वाले संगठन checksum, signature, provenance attestation जैसे package integrity signals की जांच जारी रखें
    • forum में दावा किए गए डेटा का independent verification नहीं है, इसलिए इसे अप्रमाणित जानकारी माना जाना चाहिए
    • आकलन यह है कि Vercel द्वारा बताए गए OAuth-आधारित attack chain से ही यह घटना तकनीकी रूप से स्थापित हो जाती है, और forum पोस्ट करने वाले द्वारा दावा किए गए व्यापक access scope का होना अनिवार्य शर्त नहीं है

MITRE ATT&CK mapping

  • पुष्टि की गई attack chain को मौजूदा MITRE ATT&CK techniques से स्वाभाविक रूप से map किया जा सकता है
  • mapping items
    • Initial Access / Trusted Relationship / T1199
      • Context.ai OAuth app को एक trusted third party के रूप में उपयोग किया गया
    • Persistence / Application Access Token / T1550.001
      • password बदले जाने के बाद भी OAuth token बना रहा
    • Credential Access / Valid Accounts / T1078
      • compromised employee Workspace credentials
    • Discovery / Account Discovery / T1087
      • internal systems और projects की enumeration
    • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
      • non-sensitive environment variables तक पहुंच संभव
    • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
      • exposed cloud credentials के इस्तेमाल की संभावना
    • Collection / Data from Information Repositories / T1213
      • projects में environment variables की enumeration
  • इस mapping में सबसे मूल्यवान detection point वह चरण है जहां OAuth application access से internal system access की ओर बढ़त होती है
  • संगठनों को उन OAuth apps के असामान्य व्यवहार की निगरानी करनी चाहिए जो अपेक्षित दायरे से बाहर या अप्रत्याशित IP ranges से resources तक पहुंचते हैं

supply chain siege: LiteLLM, Axios, Vercel

  • Vercel की घटना कोई अकेली घटना नहीं है, बल्कि मार्च–अप्रैल 2026 में केंद्रित supply chain attacks की एक धारा के भीतर स्थित है
  • लेख में कहा गया है कि यह या तो एक coordinated campaign हो सकता है, या अधिक संभावित व्याख्या के अनुसार कई attackers ने एक ही संरचनात्मक कमजोरी — package repositories, CI/CD, OAuth providers और deployment platforms के बीच trust boundaries — को एक साथ खोज लिया हो सकता है

  • 24 मार्च 2026: LiteLLM PyPI supply chain compromise

    • malicious PyPI packages litellm 1.82.7, 1.82.8 प्रकाशित किए गए
    • Aqua Security के vulnerability scanner Trivy से चुराए गए CI/CD deployment credentials का उपयोग किया गया
    • LiteLLM एक LLM proxy है, जिसके प्रतिदिन लगभग 34 लाख downloads हैं
    • 3-stage backdoor ने बड़े cloud providers में 50 से अधिक credential types को निशाना बनाया
    • Kubernetes DaemonSet persistence भी शामिल थी
    • detection और removal से पहले dwell time लगभग 40 मिनट से 3 घंटे था
    • संबंधित CVE है CVE-2026-33634

  • 31 मार्च 2026: Axios npm supply chain compromise

    • npm package axios के प्रति सप्ताह 7 करोड़ से 10 करोड़ downloads हैं
    • maintainer account compromise के जरिए malicious versions 1.14.1, 0.30.4 वितरित किए गए
    • plain-crypto-js@4.2.1 dependency injection, जिसमें cross-platform RAT शामिल था
    • 135 संक्रमित endpoints को attacker C2 से संचार करते हुए detect किया गया
    • dwell time 2 से 3 घंटे था
    • Microsoft ने इस हमले का attribution उत्तर कोरिया समर्थित threat actor Sapphire Sleet को दिया

  • converging pattern

    • 3 हफ्तों में 3 attacks
    • अलग-अलग vectors
    • साझा target था credentials और secrets जिन्हें developers ने toolchain में संग्रहीत किया था
    • table summary में निम्नलिखित दिया गया है
      • LiteLLM: CI/CD credential theft → PyPI, developer credentials और API keys, 40 मिनट–3 घंटे
      • Axios: maintainer account compromise → npm, developer workstation RAT, 2–3 घंटे
      • Vercel: OAuth app compromise → platform, customer environment variables, table में लगभग 22 महीने लिखा गया है, लेकिन ऊपर correction और मुख्य पाठ में इसे लगभग 2 महीने कर ठीक किया गया है

पिछली platform compromises के साथ समान pattern

  • Vercel compromise उस दोहराए जाने वाले pattern से जुड़ता है जिसमें platform-level compromise से customer secrets उजागर होते हैं

  • Codecov Bash Uploader compromise, जनवरी–अप्रैल 2021

    • attacker ने Bash Uploader script में बदलाव करके customer CI environments से environment variables exfiltrate किए
    • लगभग 2 महीने तक detect नहीं हुआ
    • 29,000 से अधिक customers संभावित रूप से प्रभावित हुए, जिनमें Twitch, HashiCorp, Confluent शामिल हैं
    • Vercel के साथ समानता है platform compromise के जरिए customer environment variables का exposure

  • CircleCI security incident, जनवरी 2023

    • personal device malware के जरिए employee SSO session tokens चुराए गए
    • internal systems तक पहुंच के बाद customer secrets और encryption keys exfiltrate की गईं
    • CircleCI ने सभी customers को platform में संग्रहीत सभी secrets rotate करने की सलाह दी
    • Vercel के लगभग समान संरचना
      • employee account compromise
      • internal system access
      • customer secret exfiltration

  • Snowflake customer credential attack, मई–जून 2024

    • UNC5537 ने infostealer से प्राप्त credentials और MFA लागू न किए गए accounts का उपयोग किया
    • 165 से अधिक organizations प्रभावित हुईं
    • इनमें Ticketmaster, Santander Bank, AT&T शामिल हैं

  • Okta support system compromise, अक्टूबर 2023

    • चोरी किए गए credentials के जरिए customer support case management system तक पहुंच
    • HAR files के भीतर session tokens देखे गए
    • Cloudflare, 1Password, BeyondTrust सहित customers प्रभावित हुए

  • pattern summary

    • trust relationship या credentials के जरिए initial access
    • internal systems में lateral movement
    • customer secrets का exfiltration
    • target scope कुछ चुनिंदा targets से लेकर पूरे platform तक अलग-अलग रहा
    • table में हर घटना के initial vector, exposed assets और detection delay को संक्षेप में दिया गया है
      • Codecov लगभग 2 महीने
      • Okta कई हफ्ते
      • CircleCI कई हफ्ते
      • Snowflake कई महीने
      • Vercel लगभग 2 महीने

जो बातें अभी भी सार्वजनिक नहीं हैं

  • सार्वजनिक रिपोर्टिंग और executives के बयानों के बावजूद कुछ महत्वपूर्ण खाली जगहें अब भी मौजूद हैं
  • सार्वजनिक रिकॉर्ड के आधार पर unresolved questions
    • Vercel ने असामान्य गतिविधि पहली बार कब detect की
    • publicly disclosed credential misuse के सबसे शुरुआती सबूत और सार्वजनिक खुलासे के बीच 9 दिन के अंतर का कारण
    • प्रभावित customers की संख्या
      • Rauch ने इसे “quite limited” कहा, लेकिन सटीक संख्या सार्वजनिक नहीं की
    • क्या ShinyHunters forum का दावा उसी attacker द्वारा किया गया था या नहीं
    • Context.ai की वर्तमान स्थिति और downstream customers को notification दिया गया या नहीं
    • Vercel internal access का पूरा दायरा
      • प्रभावित teams, projects और environment variables की संख्या सार्वजनिक नहीं की गई
      • customer environment variables के अलावा अन्य internal systems तक पहुंच हुई या नहीं, यह भी अपुष्ट है
  • लेख इस बात पर जोर देता है कि कठोर analysis के लिए सिर्फ ज्ञात तथ्यों को ही नहीं, बल्कि जो बातें अभी सार्वजनिक नहीं हैं उन्हें भी स्पष्ट रूप से स्वीकार करना जरूरी है

डिटेक्शन और हंटिंग गाइड

  • Vercel ग्राहकों के लिए तुरंत उठाए जाने वाले कदम

    • सभी project environment variables का audit करना आवश्यक
    • लेख में नीचे दिए गए CLI उदाहरण शामिल हैं
      • vercel env ls --environment production
      • vercel env ls --environment preview
      • vercel env ls --environment development
    • CLI फिलहाल sensitive flag को सीधे नहीं दिखाता, इसलिए dashboard या API में जांच आवश्यक है

  • उजागर किए गए credentials के अनधिकृत उपयोग की तलाश

    • cloud provider audit logs खोजें
      • AWS CloudTrail
        • sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com शामिल eventSource filters
        • rotate की गई Vercel-stored access key से मेल खाने वाले userIdentity.accessKeyId खोजें
        • संगठन के ज्ञात CIDR के बाहर के sourceIPAddress, python-requests, curl, Go-http-client, और अपरिचित automation strings वाले userAgent का पता लगाएं
        • समयावधि: फ़रवरी 2026 से वर्तमान तक
      • GCP Audit Logs
        • Vercel में stored key का उपयोग करने वाले service account के protoPayload.authenticationInfo.principalEmail खोजें
        • ज्ञात रेंज से बाहर का callerIp
        • storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create जैसे methods जांचें
      • Azure Activity Logs
        • Vercel env vars में मौजूद application ID या service principal के आधार पर filter करें
        • अपेक्षित रेंज से बाहर का callerIpAddress
        • Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write को प्राथमिकता से जांचें
    • database access logs खोजें
      • वे सभी DB targets जिनकी connection strings Vercel environment variables में थीं
      • फ़रवरी 2026 से अप्रैल 2026 तक की पूरी window का विश्लेषण करें
      • Vercel edge IP, VPN, office आदि जैसे ज्ञात egress ranges के बाहर के IP देखें
      • सामान्य deployment windows के बाहर उजागर credentials के उपयोग से हुए connections का पता लगाएं
      • PostgreSQL के लिए pg_stat_activity, log_connections
      • MySQL के लिए general log या audit plugin
      • MongoDB Atlas के लिए Project Activity Feed में DATA_EXPLORER, CONNECT events
    • payment processing logs खोजें
      • Stripe Dashboard → Developers → Logs
      • अपेक्षित servers के बाहर का source_ip
      • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
      • Braintree, Adyen में समकक्ष logs जांचें
      • अभी तक rotate न किए गए non-sensitive env var-stored API keys को प्राथमिकता दें
      • email sending service logs में अप्रत्याशित भेजे गए emails की भी जांच करें
    • OpenAI, Anthropic, GitHub, AWS, Stripe आदि से आने वाले अनैच्छिक leaked credential alerts की जांच आवश्यक

  • rotation और redeploy दोनों साथ में आवश्यक

    • Vercel docs के अनुसार environment variables को rotate करने भर से पुराने deployments में मौजूद credentials values अमान्य नहीं होते
    • पुराने deployments redeploy होने तक पुराने credentials का उपयोग करते रहते हैं
    • इसलिए हर rotation के साथ उन variables का उपयोग करने वाले सभी environments का redeploy या पुराने deployments को स्पष्ट रूप से disable करना आवश्यक है
    • प्राथमिकता का क्रम इस प्रकार है
      • cloud provider credentials
      • database connection strings
      • payment processing keys
      • authentication secrets
      • third-party API keys
      • monitoring और logging tokens

  • security teams के लिए proactive response

    • Google Workspace Admin Console → Security → API Controls → Third-party app access में सभी approved OAuth apps की समीक्षा करें
    • Drive, Gmail, Calendar आदि के broad scopes वाले apps को चिह्नित करें
    • जिन vendor apps के साथ सक्रिय business relationship नहीं है, उनकी जांच करें
    • अप्रत्याशित IP ranges से OAuth token उपयोग की निगरानी करें
    • ज्ञात malicious OAuth Client ID की खोज आवश्यक
      • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

SIEM detection logic

  • OAuth application anomaly indicators, चरण 1~2

    • ज्ञात malicious OAuth Client ID से जुड़े token refresh या authorization events पर तुरंत alert करें
    • full mail access, Drive read/write, calendar access जैसे broad scope grant events को मौजूदा vendor list से cross-check करें
    • जिन apps का अब business use नहीं है, वे revocation के उम्मीदवार हैं
    • approved OAuth apps के token usage यदि enterprise और vendor की अपेक्षित CIDR ranges के बाहर के IP से हो, तो जांच आवश्यक है

  • internal system access और lateral movement, चरण 3

    • असामान्य SSO/SAML authentication events
      • जब compromised Workspace account पहली बार देखे गए IP, region, device fingerprint से internal applications में login करे
    • email और Drive-आधारित credential collection
      • API key, secret, token, password, .env जैसे keywords की bulk search
      • shared credential stores, engineering runbooks, infrastructure documents तक पहुंच
      • mail forwarding rules का creation
    • OAuth-connected internal tools तक पहुंच
      • Slack, Jira, GitHub, internal dashboards आदि में सामान्य से अलग समय या infrastructure से session creation या API activity
    • privilege escalation attempts
      • नए groups या roles में शामिल होना
      • कम उपयोग होने वाले admin console तक पहुंच
      • Google Workspace में Directory API calls, delegation changes, अन्य users के OAuth tokens enumerate करने के प्रयासों की निगरानी

  • environment variable enumeration, चरण 4

    • Vercel team audit logs में env read, list, decrypt प्रकृति वाले calls के असामान्य volume और frequency patterns का पता लगाएं
    • पहले सामान्य CI/CD build timing का baseline स्थापित करना आवश्यक है
    • फिर volume, timing, और source principal baseline से बाहर जाने वाली access पर alert करें
    • non-service accounts से access, या उन accounts की access पर ध्यान दें जो आमतौर पर projects के साथ interact नहीं करते

  • downstream credential abuse, चरण 5

    • फ़रवरी 2026 से अप्रैल 2026 की window के दौरान non-sensitive Vercel environment variables में stored रहे सभी credentials के target services के logs की जांच करें
    • AWS में specific access key ID के आधार पर CloudTrail खोजें
    • GCP और Azure में service account या application ID के आधार पर audit logs खोजें
    • Stripe, OpenAI, Anthropic, SendGrid, Twilio जैसे SaaS APIs के लिए dashboard या API logs में अपरिचित IP, निष्क्रिय समय के दौरान उपयोग आदि की जांच करें
    • ऐसा कोई भी उपयोग जिसे अपनी infrastructure से जोड़कर न देखा जा सके, उसे तुरंत compromised credential मानें और rotation व activity investigation करें

  • third-party credential leak alerts

    • GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud आदि के automated secret scanning alerts की निगरानी आवश्यक है
    • उन keys के alerts जिन्हें केवल deployment platform पर मौजूद होना चाहिए था, उन्हें साधारण hygiene warning नहीं बल्कि platform compromise indicator के रूप में माना जाना चाहिए

थ्रेट हंटिंग मैनुअल प्रक्रिया

  • Google Workspace Admin Console में मैनुअल खोज

    • Admin Console → Reports → Audit and Investigation → OAuth Log Events
    • Application Name = Context.ai या Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • अवधि फरवरी 2026 से वर्तमान तक
    • यदि परिणाम मिलते हैं, तो तुरंत permissions revoke करें और incident investigation आवश्यक है

  • व्यापक scope वाले third-party OAuth apps की जांच

    • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
    • App access = Unrestricted वाले apps को sort करें
    • हर app के लिए जांच बिंदु
      • सक्रिय vendor relationship मौजूद है या नहीं
      • scope का business justification
      • हालिया उपयोग तिथि
    • 90 दिनों से अधिक समय से उपयोग न किए गए apps revocation के लिए उम्मीदवार हैं

रक्षा संबंधी सिफारिशें

  • तत्काल कार्रवाई, 0~48 घंटे

    • sensitive के रूप में चिह्नित नहीं किए गए सभी Vercel environment variables rotate करें
    • rotation के बाद सभी environments को फिर से deploy करें
    • credentials, tokens, keys, secrets शामिल करने वाले सभी environment variables पर sensitive flag सक्षम करें
    • Google Workspace या Microsoft Entra admin console में OAuth app approvals का audit करें
    • जो app access अब सक्रिय रूप से उपयोग में नहीं है, उसे revoke करें
    • फरवरी 2026 से वर्तमान तक, उन सभी services के access logs की समीक्षा करें जहां Vercel environment variables में संग्रहीत credentials उपयोग किए गए थे

  • अल्पकालिक सुदृढ़ीकरण, 1~4 सप्ताह

    • HashiCorp Vault, AWS Secrets Manager, Doppler, Infisical जैसे dedicated secret managers के उपयोग पर migrate करें
    • platform environment variable storage के बजाय runtime injection तरीका अपनाएँ
    • जहां समर्थन उपलब्ध हो, वहां OIDC-आधारित authentication से long-term credentials हटाएँ
    • OAuth app monitoring लागू करें
      • Nudge Security, Grip Security, Valence Security या Google Workspace की मूल admin capabilities
    • credential rotation automation बनाएं
      • 30~90 दिन का cycle सुझाया गया है
    • OAuth approvals को contract vendors जैसी third-party risk inventory में शामिल करें

  • संरचनात्मक बदलाव, 1~6 महीने

    • environment variables के लिए Zero Trust posture अपनाएँ
      • मानकर चलें कि deployment platform में संग्रहीत सभी secrets, platform breach की स्थिति में उजागर हो सकते हैं
    • least-privilege scope लागू करें
      • DB accounts के लिए least privilege
      • API keys के operational scope को सीमित करें
      • cloud credentials के लिए long-term access keys के बजाय role-based temporary credentials
    • corporate identity systems तक पहुंचने वाले सभी OAuth apps और integrations के लिए third-party security review और periodic re-review करें
    • PaaS platforms को SBOM/ASPM inventory में शामिल करें
      • इन्हें केवल external service नहीं, बल्कि first-class supply chain dependency की तरह माना जाना चाहिए

  • अनुशंसित monitoring

    • Google Workspace Admin Console में ऊपर दिए गए OAuth Client ID का audit करें
    • Vercel audit logs में अप्रत्याशित env.read, env.list API calls की monitoring करें
    • फरवरी 2026~अप्रैल 2026 के बीच Vercel env vars में संग्रहीत credentials के लिए CloudTrail, GCP Audit Logs, Azure Activity Logs में unexpected IPs, user agent उपयोग की समीक्षा करें
    • यदि dependency tree में LiteLLM या Axios है, तो हर advisory में दिए गए IOCs की भी monitoring करें
    • exposure period के दौरान प्रमुख API providers की involuntary leaked credential alerts पर नजर रखें

नियामकीय और compliance प्रभाव

  • जिन संगठनों में इस breach के कारण credentials exposure हुआ हो सकता है, उन्हें निम्न दायित्वों का आकलन करना चाहिए

  • GDPR

    • यदि exposed credentials ने EU personal data वाले systems तक पहुंच की अनुमति दी, तो 72-घंटे की notification clock exposure की पुष्टि के समय से शुरू हो सकती है
    • 10 अप्रैल की OpenAI notification यह सवाल उठाती है कि कुछ संगठनों के लिए awareness point, 19 अप्रैल की public disclosure से पहले का हो सकता है

  • CCPA/CPRA

    • consumer data access देने वाले credentials का exposure notification obligations trigger कर सकता है

  • PCI DSS

    • Stripe, Braintree, Adyen आदि payment processing credentials का exposure incident response procedures और forensic investigation requirements पैदा कर सकता है

  • SOC 2

    • incident records, credential rotation actions, और updated controls को ongoing monitoring evidence में प्रतिबिंबित करना होगा

  • SEC Cybersecurity Rules 8-K

    • materiality निर्धारित करने वाली listed companies पर 4 business days के भीतर disclosure obligation लागू होता है
    • लेख में कहा गया है कि भले ही actual unauthorized access use का अभी पता न हो, कई regulatory frameworks exploitation confirmation नहीं बल्कि exposure itself के आधार पर काम कर सकते हैं

समझौते के संकेतक

  • पुष्टि किए गए IoC

    • OAuth Client ID
      • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
      • compromised Context.ai OAuth application से जुड़ा मान

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.