सार्वजनिक हुईं 9,308 AWS Keys अब भी काम कर रही थीं—कॉर्पोरेट Cloud Accounts पर खतरा

Truffle Security की अगस्त 2026 की रिसर्च ने Cloud Security की एक गंभीर और लंबे समय से बनी हुई समस्या सामने रखी है। सार्वजनिक Code Repositories, Git History, Datasets, Docker Images, Container Registries और Continuous-Integration Logs में अगस्त 2022 से अगस्त 2026 के बीच 431,875 AWS Secret Findings दर्ज की गईं। Deduplication और Verification के बाद इनमें 64,024 Unique AWS Keys मिलीं। 145

सबसे चिंताजनक बात केवल Exposure की संख्या नहीं थी, बल्कि यह थी कि इनमें से कितनी Keys अब भी काम कर रही थीं। 10 अगस्त 2026 को जांचे गए 10,616 Complete Credential Pairs में से 9,308 ने सफलतापूर्वक Authentication किया—लगभग 88%। 145

कई Exposed Credentials को High-Privilege Access मिला हुआ था

Verified Key Set में 10,625 Root Credentials, 48,744 IAM-User Keys और 4,655 ऐसी Keys शामिल थीं जिन्हें वर्गीकृत नहीं किया जा सका। Root Credentials कुल Unique Keys का 16.6% थीं। 1

Truffle Security ने कंपनियों से जुड़ी 817 Active Keys की पहचान की। इनमें शामिल थीं:

• 526 Root Keys, जो AWS Account में सबसे अधिक Privilege वाली Credentials होती हैं।
• 242 IAM-User Keys जिन पर AdministratorAccess Policy थी, जो Account पर लगभग पूरा नियंत्रण दे सकती है।
• कुल 768 Credentials, जिनसे किसी Corporate AWS Account पर Full Control हासिल किया जा सकता था।
• AWS Organizations Management Accounts की 130 Active Root Keys। ऐसी Credentials के Compromise होने पर किसी Organization के Member Accounts भी जोखिम में आ सकते हैं। 13

जिन IAM Users की Policies को पढ़ा जा सका, उनके एक सीमित समूह में 1,157 में से 976 Users यानी 84% पर AdministratorAccess Policy थी। अन्य 144 Users के पास IAMFullAccess था। Truffle ने चेतावनी दी कि यह आंकड़ा केवल दिशा-सूचक है, क्योंकि Policy Enumeration की अनुमति देने वाले Users सभी Leaked IAM Users का प्रतिनिधित्व जरूरी नहीं करते। 1

प्रभावित AWS Accounts की संख्या पर रिपोर्ट में अंतर

उपलब्ध रिपोर्टिंग में AWS Accounts के दो अलग-अलग आंकड़े दिए गए हैं, जो संभवतः अलग Scope पर आधारित हैं। एक Summary 64,024 Keys को 9,945 अलग AWS Accounts से जोड़ती है, जबकि मूल Source Report की Summary में 50,654 अलग AWS Accounts का आंकड़ा दिया गया है। उपलब्ध सामग्री यह स्पष्ट नहीं करती कि दोनों संख्याओं में अंतर क्यों है, इसलिए इन्हें एक-दूसरे के स्थान पर इस्तेमाल नहीं किया जाना चाहिए। 1

हालांकि Account-Level Risk स्पष्ट है: सैकड़ों Active Credentials कंपनियों से जुड़ी थीं और 768 Keys Corporate AWS Account पर Full Control दे सकती थीं। 13

Hugging Face सबसे बड़ा Individual Source रहा

Hugging Face के 3,394 Public Datasets में 8,482 Unique Live AWS Keys मिलीं, जिससे वह इस समीक्षा में Exposed Keys का सबसे बड़ा Individual Source बना। इन Keys में Root Credentials की हिस्सेदारी 17.9% थी—Tracked Sources में Root-Key Share का सबसे ऊंचा अनुपात। 125

Public Code के दोबारा इस्तेमाल से यह Exposure और बढ़ सकता है। Secrets वाले Code Snapshots को Training Datasets में Copy किया जा सकता है और फिर वे कई Downstream Datasets में फैल सकते हैं। इसलिए मूल Repository से Credential हटाने भर से उसकी हर Copy समाप्त नहीं होती। 1

यह AWS-केंद्रित निष्कर्ष Hugging Face के व्यापक Truffle Security Scan का हिस्सा है। कंपनी के अनुसार, उसने 7.6 Petabytes Data और 187 Million Files की जांच की, जिसमें 6,003 Datasets से 221,303 Live, Unique Credentials मिलीं। ये आंकड़े सभी Credential Types के हैं, केवल AWS Keys के नहीं। 6

कई Keys वर्षों पुरानी थीं और Rotate नहीं की गईं

जिन 2,903 Active Keys की Creation Dates पढ़ी जा सकीं, उनकी Median Age 1,831 दिन—लगभग पांच वर्ष—थी। इनमें आधी Keys पांच वर्ष से अधिक पुरानी थीं, सबसे पुरानी Key 17.4 वर्ष पुरानी थी और केवल 25 Keys यानी 0.9% पिछले 30 दिनों में बनाई गई थीं। 1

इन 2,903 Keys में से सिर्फ 398 यानी 13.7% के लिए कोई Newer Replacement Key मिली। इससे संकेत मिलता है कि अधिकांश Keys को Exposure के बाद Rotate, Replace या पूरी तरह साफ नहीं किया गया था। 1

व्यावहारिक सबक सीधा है: जो Secret एक बार Public Material में आ जाए, उसे स्थायी रूप से Compromised मानना चाहिए—भले ही मूल File या Repository Entry बाद में Edit कर दी गई हो। Git History, Container Images, Package Artifacts और Public Datasets पुराने Copies को लंबे समय तक बनाए रख सकते हैं। 1

Budget Alerts की कमी से Cryptomining का जोखिम

Budget Controls भी बहुत कम Accounts में मिले। जिन 2,754 Accounts की Settings पढ़ी जा सकीं, उनमें केवल 262 यानी 9.5% पर कोई Budget Alert Configured था। Median Alert Threshold 8 डॉलर था। 12

इसका अर्थ है कि 90.5% Readable Accounts में कोई Detectable Budget Alarm नहीं था। Usable Credentials मिलने पर हमलावर संगठन की जानकारी में आने से पहले Cryptomining या अन्य Compute Workloads चला सकते हैं और Cloud Bill बढ़ा सकते हैं। 12

जिन Accounts का Spending Data पढ़ा जा सका, उन्होंने जुलाई 2026 में कुल 420,631 डॉलर खर्च किए। इनमें 50 Accounts ने 1,000 डॉलर से अधिक और 9 ने 10,000 डॉलर से अधिक खर्च किए। ये आंकड़े केवल Observed Accounts के खर्च को दर्शाते हैं; वे यह साबित नहीं करते कि यह खर्च Credential Abuse के कारण हुआ था। 1

AWS की Quarantine Policy का अर्थ तुरंत निष्क्रिय होना नहीं

Truffle Security ने बताया कि AWS द्वारा Exposed IAM Keys पर AWSCompromisedKeyQuarantine Policy लगाई जाती देखी गई। यह Policy Key की गतिविधियों को सीमित करती है, लेकिन Authentication को तुरंत बंद कर दे—यह जरूरी नहीं है। 1

जांची गई Active IAM Keys में से 7,590 में 929 यानी 12% पर यह Policy लगी थी। अन्य 112 Keys पर इसका पुराना Version था, जिसे AWS ने 2023 में लागू करना बंद कर दिया था। Truffle के निष्कर्ष बताते हैं कि लंबे समय से Exposure Notifications के बावजूद कुछ Keys इस्तेमाल योग्य बनी रहीं। 1

इसलिए Quarantine Policy को Credential के सुरक्षित रूप से Retire हो जाने का प्रमाण नहीं माना जाना चाहिए। संगठन को Key की जांच कर उसके Owner और Permissions की पहचान करनी चाहिए और उसे Revoke या Rotate करना चाहिए। 1

Researchers ने Credentials की जांच कैसे की?

Truffle के अनुसार, उसने केवल उन्हीं Credential Pairs को दोबारा Verify किया जिनका पूरा Material उपलब्ध था। Account और Privilege Analysis के लिए Researchers ने एक समय में एक Key पर Read-Only IAM Calls किए, Key Material को Public नहीं किया और जिन Owners की पहचान हो सकी, उन सभी को Notification भेजी। 15

इस Methodology को समझना जरूरी है: 88% का आंकड़ा उन Complete Credential Pairs पर लागू होता है जिन्हें दोबारा Test किया गया। यह Scan में मिली हर Public Finding या हर Partial Secret पर लागू नहीं होता। 14

Organizations को अब क्या करना चाहिए?

रिसर्च के आधार पर संगठनों के लिए जरूरी कदम हैं:

1. Root Access Keys हटाएं। Truffle का कहना है कि Root Keys का कोई वैध Operational Use नहीं होना चाहिए। 1
2. हर IAM Access Key की Inventory बनाएं, जिसमें Repositories, Git History, CI Logs, Images, Registries और Published Datasets भी शामिल हों। 1
3. Exposed Credentials को तुरंत Revoke या Rotate करें। केवल दिखाई दे रही Copy हटाना पर्याप्त नहीं है, क्योंकि Secret Historical या Downstream Artifacts में मौजूद हो सकता है। 1
4. Maximum Key Age तय कर Rotation लागू करें। पुरानी और अप्रयुक्त Credentials को हमेशा उपलब्ध रखने के बजाय हटा देना चाहिए। 1
5. Budget Alerts Configure करें। 10 डॉलर जैसी कम सीमा भी Unauthorized Spending का शुरुआती संकेत दे सकती है। 1
6. AWSCompromisedKeyQuarantine को Monitor करें और इसे Credential Exposure के संकेत के रूप में जांचें। 1
7. Continuous Secret Scanning अपनाएं, जो Source Code, History, Build Systems, Container Artifacts, Registries और Published Datasets में लगातार खोज करे। 1

इस रिसर्च का केंद्रीय संदेश यह है कि Public Exposure एक बार की घटना नहीं है। Revocation, Rotation और Monitoring के बिना AWS Credential वर्षों तक Cloud Infrastructure में प्रवेश का सक्रिय रास्ता बनी रह सकती है।