Consent Phishing OAuth: Serangan yang Menembus MFA dan Cara Bisnis Indonesia Menangkalnya

Selama bertahun-tahun, otentikasi multi-faktor (MFA) diposisikan sebagai benteng terakhir yang mampu menahan sebagian besar serangan pengambilalihan akun. Namun sepanjang 2026 sebuah teknik lama kembali marak dan membuktikan bahwa MFA saja tidak cukup: consent phishing OAuth. Pada awal Agustus 2026, peneliti Check Point mengungkap satu kampanye yang menyalahgunakan proses login dan persetujuan (consent) resmi milik Microsoft, dengan lebih dari 200 email yang menyasar sekitar 120 organisasi. Jika berhasil, penyerang memperoleh akses ke kotak surat, file, Teams, SharePoint, OneDrive, hingga kalender korban tanpa pernah mengetahui kata sandi mereka.

Bagi bisnis Indonesia yang kini sangat bergantung pada Microsoft 365 dan Google Workspace untuk operasional harian, serangan ini sangat relevan. Artikel ini membedah cara kerja consent phishing, mengapa ia begitu berbahaya karena mampu menembus MFA, serta langkah teknis dan tata kelola yang dapat Anda terapkan untuk menangkalnya.

Apa Itu Consent Phishing?

Consent phishing (kadang disebut illicit consent grant attack) adalah serangan yang mengeksploitasi alur otorisasi OAuth 2.0, bukan kata sandi korban. Alih-alih mencuri kredensial, penyerang membuat sebuah aplikasi terdaftar (registered application) di Microsoft Entra ID atau Google Cloud, lalu membujuk pengguna agar memberikan izin (consent) kepada aplikasi tersebut untuk mengakses data mereka.

Kuncinya ada pada model persetujuan modern. Ketika sebuah aplikasi pihak ketiga ingin membaca email atau file Anda, ia tidak meminta kata sandi. Ia meminta token akses melalui layar persetujuan resmi dari penyedia identitas. Layar itu asli, halaman login Microsoft atau Google itu asli, dan MFA pun tetap berjalan normal. Yang dimanipulasi adalah keputusan pengguna untuk menekan tombol "Terima" atau "Izinkan".

Anatomi Serangan: Langkah demi Langkah

Untuk memahami mengapa serangan ini sulit dideteksi, mari kita telusuri alurnya:

1. Persiapan aplikasi jahat. Penyerang mendaftarkan aplikasi OAuth dengan nama yang meyakinkan — misalnya menyerupai alat produktivitas, sistem HR, atau add-in populer. Aplikasi ini dikonfigurasi untuk meminta scope (cakupan izin) tertentu seperti Mail.Read, Mail.Send, Files.ReadWrite.All, dan yang paling krusial offline_access.
2. Umpan (lure). Korban menerima email, pesan Teams, atau tautan di situs tepercaya yang telah disisipi kode. Karena email berisi tautan ke domain login resmi Microsoft, banyak filter email dan gateway keamanan meloloskannya.
3. Login yang sah. Korban mengklik tautan, diarahkan ke halaman login asli, memasukkan kredensial, dan menyelesaikan MFA. Semua terasa normal.
4. Layar persetujuan. Setelah login, muncul layar consent yang meminta izin. Di sinilah manipulasi terjadi. Jika korban menekan "Accept", penyedia identitas menerbitkan OAuth grant berikut token akses dan refresh token.
5. Akses persisten. Dengan refresh token dari scope offline_access, aplikasi jahat dapat memperbarui token akses berulang kali tanpa interaksi korban — mengakses data secara terus-menerus di latar belakang.

Mengapa MFA dan Reset Kata Sandi Tidak Menolong

Inilah inti bahaya consent phishing. Setelah persetujuan diberikan, aplikasi memiliki akses tingkat akun ke data korban secara independen dari kata sandi. Menurut dokumentasi Microsoft, langkah remediasi umum seperti mereset kata sandi atau mewajibkan MFA tidak efektif terhadap serangan jenis ini, karena aplikasi tersebut berada di luar organisasi dan tidak bergantung pada sesi login pengguna.

Kompromi akan bertahan hingga persetujuan (consent) dicabut secara eksplisit — bahkan jika korban mengganti kata sandi dan me-reset seluruh sesinya.

Karena serangan ini sepenuhnya berbasis cloud (no-endpoint attack), ia juga melewati proteksi endpoint dan antivirus. Tidak ada malware yang diunduh, tidak ada lampiran mencurigakan yang dibuka. Yang terjadi hanyalah satu klik "Izinkan" pada layar yang tampak resmi.

Sinyal Bahaya yang Perlu Dikenali Pengguna

Pertahanan pertama tetap pada kewaspadaan pengguna. Beberapa tanda yang harus memicu kecurigaan saat muncul layar persetujuan:

1. Aplikasi meminta izin yang tidak proporsional dengan fungsinya — misalnya sebuah "penampil PDF" meminta izin mengirim email atas nama Anda.
2. Penerbit aplikasi (publisher) tidak terverifikasi atau namanya generik dan tidak dikenal.
3. Muncul frasa seperti "Maintain access to data you have given it access to" yang mengindikasikan permintaan offline_access.
4. Permintaan consent muncul secara tak terduga setelah mengklik tautan dari email atau pesan chat.
5. Domain redirect setelah persetujuan mengarah ke situs yang tidak berhubungan dengan aplikasi yang diklaim.

Strategi Pertahanan Teknis untuk Organisasi

Kesadaran pengguna penting, tetapi tidak boleh menjadi satu-satunya lapisan. Berikut kontrol teknis yang direkomendasikan, selaras dengan prinsip defense-in-depth pada kerangka NIST Cybersecurity Framework 2.0 (fungsi Protect dan Detect) serta kontrol akses pada ISO/IEC 27001:2022.

1. Batasi Persetujuan Pengguna (User Consent Settings)

Kontrol paling ampuh adalah mencabut kemampuan pengguna biasa untuk menyetujui aplikasi pihak ketiga secara mandiri. Di Microsoft Entra ID, atur kebijakan consent sehingga pengguna hanya boleh menyetujui aplikasi dari penerbit terverifikasi untuk scope berisiko rendah, atau matikan sepenuhnya sehingga semua permintaan harus melalui persetujuan administrator (admin consent workflow). Dengan begitu, permintaan berisiko akan masuk ke antrean tinjauan, bukan langsung disetujui korban.

2. Aktifkan App Governance dan Kebijakan OAuth

Microsoft Defender for Cloud Apps menyediakan app governance yang memperlihatkan aplikasi OAuth mana saja yang telah diberi akses ke data di Microsoft 365, Google Workspace, dan Salesforce. Konfigurasikan kebijakan aktivitas, deteksi anomali, dan kebijakan aplikasi OAuth untuk menandai aplikasi baru yang mencurigakan, aplikasi dengan izin berlebih, atau lonjakan aktivitas API yang tidak wajar.

3. Wajibkan Verifikasi Penerbit dan Daftar Putih Aplikasi

Terapkan kebijakan yang hanya mengizinkan aplikasi dari verified publisher. Untuk lingkungan sensitif, gunakan pendekatan allowlist: hanya aplikasi yang telah ditinjau dan disetujui tim keamanan yang boleh berjalan. Ini memindahkan model kepercayaan dari "izinkan kecuali diblokir" menjadi "blokir kecuali diizinkan".

4. Audit dan Cabut Consent Grant Secara Berkala

Lakukan audit rutin terhadap seluruh persetujuan aplikasi yang aktif. Cari aplikasi dengan scope berbahaya (Mail.ReadWrite, full_access_as_user, Directory.ReadWrite.All), penerbit tak dikenal, atau yang lama tidak digunakan. Cabut persetujuan yang mencurigakan. Ingat: mencabut consent, bukan mereset kata sandi, adalah remediasi yang benar untuk serangan ini.

5. Manfaatkan Filtering Anti-Phishing

Karena umpan awal umumnya berupa email, aktifkan perlindungan anti-phishing pada Microsoft Defender for Office 365 atau gateway setara. Meski email berisi tautan ke domain sah, kebijakan anti-impersonasi dapat menangkap upaya penyerang yang menyamar sebagai pengguna internal atau mitra tepercaya.

Respons Insiden: Jika Anda Terlanjur Menyetujui

Bila dicurigai telah terjadi consent phishing, kecepatan sangat menentukan. Langkah tanggap darurat yang disarankan:

1. Segera cabut persetujuan aplikasi tersebut melalui portal Entra ID (Enterprise Applications) atau, untuk pengguna individu, melalui halaman "My Apps".
2. Hapus/invalidasi refresh token pengguna terdampak agar sesi aplikasi jahat langsung terputus.
3. Telusuri log audit untuk memetakan data apa yang telah diakses — email yang dibaca, file yang diunduh, atau aturan kotak masuk (inbox rule) jahat yang mungkin dibuat penyerang untuk menyembunyikan jejak.
4. Periksa apakah penyerang membuat forwarding rule atau aturan penghapusan otomatis, sebuah taktik lanjutan yang lazim dipakai untuk membajak komunikasi bisnis (Business Email Compromise).
5. Dokumentasikan insiden dan, bila melibatkan data pribadi, evaluasi kewajiban pelaporan.

Dimensi Hukum: Kaitan dengan UU PDP

Bagi organisasi di Indonesia, consent phishing yang berujung pada kebocoran data bukan sekadar masalah teknis. Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP) mewajibkan pengendali data pribadi menerapkan langkah teknis dan organisasional untuk melindungi data. Jika serangan ini menyebabkan kegagalan pelindungan data pribadi, pengendali wajib menyampaikan pemberitahuan kepada subjek data dan lembaga terkait dalam waktu paling lambat 3 x 24 jam. Kelalaian dalam menjaga keamanan sistem serta ketiadaan kontrol akses yang memadai dapat memperbesar eksposur sanksi administratif. Karena itu, mitigasi consent phishing sepatutnya dipandang sebagai bagian dari kepatuhan, bukan sekadar praktik keamanan opsional.

Penutup

Consent phishing OAuth adalah pengingat bahwa lanskap ancaman terus bergeser dari mencuri "sesuatu yang Anda tahu" (kata sandi) menuju menyalahgunakan "sesuatu yang Anda percayai" (izin aplikasi). MFA tetap penting, tetapi ia bukan peluru perak. Pertahanan yang tangguh menuntut kombinasi tata kelola persetujuan yang ketat, pemantauan aplikasi OAuth secara berkelanjutan, audit izin berkala, serta edukasi pengguna agar berpikir dua kali sebelum menekan tombol "Izinkan".

Di Siberindo, kami memandang keamanan identitas dan tata kelola akses cloud sebagai fondasi ketahanan siber organisasi modern. Meninjau ulang kebijakan consent aplikasi hari ini adalah investasi kecil yang dapat mencegah kerugian besar esok hari.