Celah Buta dalam Logging Autentikasi Cloud

Tim keamanan di TrustedSec baru-baru ini mengungkap metode ketiga dan keempat untuk mem-bypass logging sign-in Azure. Artinya ada empat teknik independen untuk melakukan autentikasi ke layanan cloud Microsoft tanpa autentikasi tersebut muncul di log yang diandalkan tim keamanan untuk deteksi. Sign-in-nya terjadi, tapi log-nya tidak mencatat. Siapa pun yang memantau log itu untuk aktivitas mencurigakan tidak melihat apa-apa.

Ini bukan masalah teoretis. Kalau penyerang mencuri kredensial dan memakainya untuk masuk ke environment Azure Anda, hal pertama yang dicek tim keamanan adalah sign-in log. Kalau log itu tidak lengkap, misalnya ada kategori autentikasi yang sama sekali tidak menghasilkan entri log, berarti kemampuan deteksi Anda punya lubang yang tidak Anda sadari. Dan selama ini Anda mengambil keputusan keamanan dengan anggapan bahwa log-nya sudah lengkap.

Mengapa Log Autentikasi Punya Celah

Asumsi naif biasanya bilang bahwa logging autentikasi itu sederhana: ada yang autentikasi, ya dicatat. Kenyataannya, autentikasi cloud adalah sistem yang sangat luas, dengan puluhan protokol, endpoint, dan jenis token, dan cakupan logging-nya berbeda-beda di tiap bagian.

Azure Active Directory (sekarang Entra ID) menangani autentikasi untuk Microsoft 365, resource Azure, aplikasi pihak ketiga lewat SAML/OIDC, aplikasi on-premises lama lewat App Proxy, service principal, managed identity, dan lain-lain. Setiap jalur autentikasi ini punya backend sendiri, pipeline logging sendiri, dan edge case sendiri. Sign-in log memang dihasilkan oleh layanan autentikasi, tapi beberapa alur autentikasi melewati layanan standar atau memakai jalur lama yang sudah ada sebelum infrastruktur logging saat ini.

Celah dari Protokol Lama

Microsoft masih mempertahankan kompatibilitas mundur dengan protokol autentikasi dari awal 2000-an, protokol yang lebih tua dari infrastruktur logging modern mereka. Beberapa jalur autentikasi SMTP, IMAP, dan POP3 memakai alur 'Basic Auth' yang melakukan autentikasi di lapisan transport email, bukan lewat token endpoint Azure AD standar. Autentikasi seperti ini mungkin tidak menghasilkan entri sign-in log yang sama dengan alur OAuth/OIDC modern.

Microsoft sudah bertahun-tahun mendeprekasi Basic Auth, tapi proses deprekasi di lingkungan enterprise berjalan lambat. Organisasi yang masih memakai mail client lama, scanner yang mengirim dokumen lewat email, atau aplikasi line-of-business yang sudah tua mungkin masih mengaktifkan Basic Auth. Setiap jalur lama seperti ini berpotensi menjadi celah logging.

Autentikasi Service Principal

Service principal, yaitu identitas non-manusia yang dipakai aplikasi dan otomasi, melakukan autentikasi dengan cara yang berbeda dari pengguna. Event sign-in mereka muncul di stream log terpisah (sign-in service principal vs sign-in interaktif vs sign-in non-interaktif). Tim keamanan yang hanya memantau log sign-in interaktif akan melewatkan seluruh aktivitas service principal.

Ini penting karena service principal yang sudah disusupi adalah vektor serangan yang umum. Penyerang yang mendapatkan kredensial atau sertifikat service principal bisa autentikasi sebagai aplikasi tersebut dan mengakses resource apa pun yang diizinkan. Kalau tim keamanan hanya mengawasi sign-in pengguna, mereka tidak akan pernah melihatnya.

Replay dan Refresh Token

Tidak setiap akses melibatkan autentikasi baru. Refresh token OAuth memungkinkan akses berlanjut tanpa autentikasi ulang. Kalau penyerang mencuri refresh token yang valid (lewat perangkat yang sudah disusupi, traffic yang disadap, atau malware), mereka bisa menukarnya dengan access token baru tanpa memicu entri sign-in log yang sama seperti autentikasi berbasis password. Sign-in awal memang tercatat, tapi setiap refresh token berikutnya mungkin muncul sebagai sign-in non-interaktif, dan banyak aturan deteksi tidak memantau jenis ini.

Masalah Detection Engineering

Celah logging autentikasi menunjukkan masalah yang lebih besar dalam keamanan cloud: kita membangun sistem deteksi di atas log yang kita anggap lengkap, lalu kaget ketika penyerang menemukan jalur yang tidak menghasilkan log sama sekali.

Arsitektur keamanan standar untuk environment cloud biasanya seperti ini: layanan cloud menghasilkan log → log mengalir ke SIEM (Security Information and Event Management) → aturan deteksi menganalisis log untuk mencari pola mencurigakan → alert memicu investigasi. Ini hanya berhasil jika log menangkap seluruh aktivitas yang relevan. Kalau tidak, SIEM Anda hanya jadi cara yang sangat mahal untuk memantau gambaran yang tidak utuh.

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.

Yang Bisa Benar-Benar Anda Lakukan

Anda tidak bisa memperbaiki celah logging cloud provider. Itu tugas Microsoft (atau AWS, atau Google). Tapi Anda bisa membangun strategi deteksi yang tidak bergantung sepenuhnya pada kelengkapan log autentikasi.

Pantau Banyak Sumber Log

Log autentikasi hanyalah salah satu sinyal. Activity log adalah sinyal lain. Meskipun sign-in penyerang tidak muncul di log autentikasi, tindakan mereka selanjutnya seperti membaca email, mengakses file, menjalankan query database, atau mengubah konfigurasi tetap menghasilkan entri log sendiri. Mengkorelasikan activity log dengan log autentikasi akan menunjukkan inkonsistensi: aktivitas dari identitas yang tidak punya sign-in terbaru yang sesuai itu mencurigakan, apa pun alasan sign-in-nya tidak tercatat.

-- 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

Nonaktifkan Autentikasi Lama

Kalau Anda tidak memakai protokol lama (Basic Auth untuk SMTP, IMAP, POP3), nonaktifkan. Ini menghilangkan seluruh kategori celah logging, karena jalur autentikasi yang melewati logging modern memang tidak bisa dipakai lagi. Kebijakan Conditional Access di Azure bisa memblokir legacy authentication per pengguna, per grup, atau untuk seluruh tenant.

Sebelum menonaktifkan, audit dulu penggunaan yang ada. Ironisnya, sign-in log Azure memang tetap menampilkan sebagian percobaan autentikasi lama, dan workbook Entra ID untuk legacy auth membantu mengidentifikasi aplikasi yang masih memakai protokol lama. Perbaiki aplikasi-aplikasi itu dulu, baru blokir legacy auth.

Pantau Aktivitas Token

Terapkan Continuous Access Evaluation (CAE) kalau environment Anda mendukungnya. CAE memungkinkan Azure AD mencabut token hampir real-time saat kondisi berubah, misalnya pengguna dinonaktifkan, terdeteksi sign-in berisiko tinggi, atau lokasi IP berubah. Tanpa CAE, access token yang dicuri tetap valid sampai kedaluwarsa, biasanya satu jam, apa pun yang dilakukan tim keamanan.

Pantau juga masa berlaku token dan pola refresh-nya. Refresh token yang dipakai dari IP baru, perangkat baru, atau jam yang tidak biasa sebaiknya ditandai. Seringkali ini satu-satunya sinyal pencurian token.

Uji Logging Anda Sendiri

Hal paling berdampak yang bisa Anda lakukan adalah rutin menguji apakah logging Anda benar-benar menangkap apa yang Anda kira. Lakukan autentikasi lewat setiap metode yang didukung environment Anda, yaitu interaktif, non-interaktif, service principal, dan protokol lama, lalu pastikan setiap metode menghasilkan entri log yang diharapkan. Kalau tidak, berarti Anda sudah menemukan celah sebelum penyerang menemukannya.

Ini bentuk pengujian detection engineering yang jarang dilakukan organisasi secara sistematis. Kebanyakan tim menulis aturan deteksi lalu berasumsi aturan itu bekerja. Memvalidasi kualitas data yang mendasarinya, yaitu memastikan event yang diandalkan aturan Anda memang tercatat, mungkin lebih penting daripada aturannya sendiri.

Pelajaran yang Lebih Luas

Bypass sign-in log Azure bukan hal yang unik untuk Microsoft. Setiap cloud provider punya jalur autentikasi dengan logging yang tidak lengkap. AWS CloudTrail punya celah yang sudah diketahui, misalnya operasi control plane tertentu di region tertentu, asumsi service-linked role tertentu, dan pola role chaining lintas akun yang bisa mengaburkan identitas asli. Audit log Google Cloud juga punya edge case serupa.

Pelajarannya bukan 'logging Azure itu rusak'. Intinya, semua logging itu tidak lengkap, dan arsitektur keamanan yang berasumsi sebaliknya pasti gagal. Defense in depth bukan sekadar punya banyak kontrol keamanan, tapi punya banyak sumber visibilitas yang independen. Kalau deteksi Anda sepenuhnya bergantung pada satu sumber log yang harus lengkap, berarti postur keamanan Anda punya single point of failure.

Bangun deteksi Anda dengan asumsi bahwa setiap sumber log bisa saja tidak lengkap atau di-bypass. Korelasikan antara log autentikasi, activity log, network log, dan telemetri endpoint. Cari inkonsistensi antar sumber, karena sering kali inkonsistensi itulah yang menunjuk tepat ke celah yang dieksploitasi penyerang. Dan uji logging Anda secara rutin, karena celah yang tidak Anda ketahui itulah yang akan dipakai untuk menyerang Anda.