क्लाउड ऑथेंटिकेशन लॉगिंग के अंधे धब्बे

TrustedSec की एक सिक्योरिटी टीम ने हाल ही में Azure sign-in logging को बायपास करने के अपने तीसरे और चौथे तरीके सार्वजनिक किए। यानी चार अलग-अलग तकनीकें, जिनसे Microsoft cloud services में ऑथेंटिकेट किया जा सकता है, और फिर भी ऑथेंटिकेशन उन logs में दर्ज नहीं होता जिन पर सिक्योरिटी टीमें detection के लिए भरोसा करती हैं। Sign-in हुआ, पर log में कुछ दर्ज नहीं हुआ। जो कोई इन logs पर नज़र रखकर संदिग्ध गतिविधि खोज रहा था, उसे कुछ नज़र नहीं आया।

यह सिर्फ़ सैद्धांतिक समस्या नहीं है। अगर कोई attacker credentials चुराकर आपके Azure environment में घुसता है, तो सिक्योरिटी टीम सबसे पहले sign-in logs देखती है। अगर वे logs अधूरे हों, यानी ऑथेंटिकेशन की पूरी श्रेणियाँ log entries बनाती ही न हों, तो आपकी detection क्षमता में ऐसा छेद है जिसके बारे में आपको पता ही नहीं। और अब तक आप यह मानकर security decisions लेते रहे हैं कि logs पूरे हैं।

ऑथेंटिकेशन logs में खामियाँ क्यों होती हैं

आमतौर पर लगता है कि authentication logging सीधी-सादी बात है: कोई ऑथेंटिकेट करता है, आप उसे log कर लेते हैं। असल में cloud authentication दर्जनों protocols, endpoints और token types वाला एक फैला हुआ सिस्टम है, और इन सबमें logging की कवरेज अलग-अलग होती है।

Azure Active Directory (अब Entra ID) Microsoft 365, Azure resources, SAML/OIDC के ज़रिए third-party apps, App Proxy के ज़रिए on-premises legacy apps, service principals, managed identities और भी बहुत कुछ के लिए authentication संभालता है। इनमें से हर authentication path का अपना backend, अपनी logging pipeline और अपने edge cases हैं। Sign-in logs authentication service द्वारा बनते हैं, पर कुछ authentication flows standard service को बायपास कर देते हैं या ऐसे legacy paths इस्तेमाल करते हैं जो मौजूदा logging infrastructure से भी पुराने हैं।

Legacy Protocol में खामियाँ

Microsoft 2000 के शुरुआती दौर के authentication protocols के साथ backward compatibility बनाए रखता है, ऐसे protocols जो उसके आधुनिक logging infrastructure से पहले के हैं। कुछ SMTP, IMAP और POP3 authentication paths 'Basic Auth' flows इस्तेमाल करते हैं, जो standard Azure AD token endpoint के बजाय mail transport layer पर ही authenticate कर लेते हैं। इन authentications के sign-in log entries वैसे नहीं बनते जैसे modern OAuth/OIDC flows के बनते हैं।

Microsoft सालों से Basic Auth को deprecate कर रहा है, लेकिन enterprise environments में deprecation धीरे चलती है। जिन संगठनों के पास पुराने mail clients हैं, ऐसे scanners जो documents email करते हैं, या पुरानी line-of-business applications हैं, उनमें Basic Auth अब भी चालू हो सकता है। हर legacy path एक संभावित logging gap है।

Service Principal Authentication

Service principals, यानी applications और automation द्वारा इस्तेमाल होने वाली non-human identities, users से अलग तरह से authenticate करती हैं। उनकी sign-in events एक अलग log stream में आती हैं (service principal sign-ins बनाम interactive sign-ins बनाम non-interactive sign-ins)। जो security teams सिर्फ interactive sign-in log पर नज़र रखती हैं, वे service principal की गतिविधि पूरी तरह मिस कर देती हैं।

यह इसलिए मायने रखता है क्योंकि compromised service principals attack का आम ज़रिया हैं। जिस attacker को किसी service principal का credential या certificate मिल जाए, वह उस application के नाम से authenticate करके वे सभी resources एक्सेस कर सकता है जिनकी उसे permission है। अगर सिक्योरिटी टीम सिर्फ user sign-ins देख रही है, तो उसे यह कभी दिखेगा ही नहीं।

Token Replay और Refresh

हर access में नया authentication नहीं होता। OAuth refresh tokens दोबारा password डाले बिना access जारी रखने देते हैं। अगर attacker कोई valid refresh token चुरा ले (compromised device, intercepted traffic या malware के ज़रिए), तो वह उसे नए access tokens में बदल सकता है, और ऐसा करते हुए वही sign-in log entries नहीं बनतीं जो password-based authentication बनाता। शुरुआती sign-in log हुआ था, पर बाद के token refresh non-interactive sign-ins के रूप में दिख सकते हैं, और ज़्यादातर detection rules उन्हें मॉनिटर ही नहीं करते।

Detection Engineering की समस्या

Authentication logging की खामियाँ cloud security की एक बड़ी समस्या की ओर इशारा करती हैं: हम ऐसे logs के ऊपर detection systems बनाते हैं जिन्हें हम पूरा मान लेते हैं, और फिर हैरान होते हैं जब attackers ऐसे रास्ते खोज लेते हैं जो कोई log नहीं बनाते।

Cloud environments के लिए standard security architecture कुछ ऐसा दिखता है: cloud services logs बनाती हैं → logs SIEM (Security Information and Event Management system) में जाते हैं → detection rules logs में संदिग्ध patterns खोजते हैं → alerts investigation शुरू करते हैं। यह तभी काम करता है जब logs सारी प्रासंगिक गतिविधि कैप्चर करें। अगर ऐसा नहीं है, तो आपका SIEM एक अधूरी तस्वीर पर नज़र रखने का बहुत महंगा तरीका है।

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

आप वास्तव में क्या कर सकते हैं

Cloud provider की logging की खामियाँ आप ठीक नहीं कर सकते, वह काम Microsoft (या AWS, या Google) का है। लेकिन आप ऐसी detection strategies बना सकते हैं जो सिर्फ authentication logs के पूरे होने पर निर्भर न हों।

कई log sources पर नज़र रखें

Authentication logs एक signal हैं। Activity logs दूसरा signal हैं। भले ही attacker का sign-in authentication logs में न दिखे, उसके बाद के कदम, जैसे emails पढ़ना, files एक्सेस करना, databases query करना, configurations बदलना, अपनी log entries बनाते हैं। Activity logs को authentication logs से cross-correlate करने पर असंगतियाँ सामने आती हैं: जिस identity की गतिविधि के लिए हाल में कोई संगत sign-in न हो, वह संदिग्ध है, चाहे वह sign-in log न होने की वजह कुछ भी हो।

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

Legacy Authentication बंद करें

अगर आप legacy protocols (SMTP, IMAP, POP3 के लिए Basic Auth) इस्तेमाल नहीं कर रहे, तो उन्हें बंद कर दें। इससे logging gaps की पूरी श्रेणियाँ खत्म हो जाती हैं, क्योंकि जो authentication paths modern logging को बायपास करते हैं, उन्हें इस्तेमाल ही नहीं किया जा सकता। Azure की Conditional Access policies legacy authentication को per-user, per-group या tenant-wide ब्लॉक कर सकती हैं।

बंद करने से पहले मौजूदा उपयोग का ऑडिट करें। Azure के sign-in logs (विडंबना देखिए) legacy authentication की कुछ कोशिशें दिखाते हैं, और legacy auth के लिए Entra ID workbook यह पहचानने में मदद करता है कि कौन-से applications अब भी पुराने protocols इस्तेमाल कर रहे हैं। पहले उन applications को ठीक करें, फिर legacy auth ब्लॉक करें।

Token Activity पर नज़र रखें

अगर आपका environment सपोर्ट करता है तो Continuous Access Evaluation (CAE) लागू करें। CAE की मदद से Azure AD हालात बदलने पर (जैसे user disable हो जाए, high-risk sign-in पकड़ा जाए, IP location बदले) near-real-time में tokens revoke कर सकता है। CAE के बिना चोरी किया गया access token तब तक valid रहता है जब तक वह expire न हो, आम तौर पर एक घंटा, चाहे सिक्योरिटी टीम कुछ भी करे।

साथ ही token lifetimes और refresh patterns पर भी नज़र रखें। अगर कोई refresh token नए IP address, नए device से या अजीब समय पर इस्तेमाल हो रहा हो, तो उसे फ़्लैग करना चाहिए। अक्सर token चोरी का यही इकलौता संकेत होता है।

अपनी logging का खुद टेस्ट करें

सबसे असरदार काम यह है कि नियमित रूप से जाँचें कि आपकी logging वाकई वही कैप्चर करती है जो आपको लगता है। अपने environment में मौजूद हर तरीके से authenticate करें (interactive, non-interactive, service principal, legacy protocol) और देखें कि हर एक अपेक्षित log entries बनाता है या नहीं। अगर नहीं बनाता, तो attacker से पहले आपने गैप खोज लिया है।

Detection engineering की यह ऐसी testing है जिसे बहुत कम संगठन व्यवस्थित रूप से करते हैं। ज़्यादातर टीमें detection rules लिखती हैं और मान लेती हैं कि वे काम करते हैं। अंतर्निहित डेटा की गुणवत्ता की पुष्टि करना, यानी यह जाँचना कि जिन events पर rules निर्भर हैं वे सच में log हो रहे हैं, शायद rules से भी ज़्यादा ज़रूरी है।

बड़ा सबक

Azure के sign-in log bypass सिर्फ Microsoft तक सीमित नहीं हैं। हर cloud provider के पास ऐसे authentication paths हैं जिनकी logging अधूरी है। AWS CloudTrail की भी अपनी ज्ञात खामियाँ हैं, जैसे कुछ regions में कुछ control plane operations, कुछ service-linked role assumptions, और cross-account role chaining के पैटर्न जो मूल identity को छिपा सकते हैं। Google Cloud के audit logs में भी इसी तरह के edge cases हैं।

सबक यह नहीं है कि 'Azure logging टूटी हुई है।' सबक यह है कि सारी logging अधूरी होती है, और जो security architectures इसके उलट मानकर चलते हैं, वे फेल होंगे। Defense in depth का मतलब सिर्फ कई security controls होना नहीं है, बल्कि दृश्यता के कई स्वतंत्र स्रोत होना है। अगर आपकी detection पूरी तरह किसी एक log source के पूरा होने पर टिकी है, तो आपकी security posture में एक single point of failure है।

अपनी detection को इस मान्यता पर बनाएँ कि कोई भी एक log source अधूरा हो सकता है या बायपास किया जा सकता है। Authentication logs, activity logs, network logs और endpoint telemetry को आपस में correlate करें। Sources के बीच असंगतियाँ खोजें, क्योंकि अक्सर वही गैप्स की ओर इशारा करती हैं जिनका attackers फ़ायदा उठाते हैं। और अपनी logging का नियमित टेस्ट करें, क्योंकि जो गैप आपको पता नहीं, वही आपके खिलाफ इस्तेमाल होगा।