Buana Cyber Security Knowledge

Apa itu MFA Fatigue Attack?

MFA fatigue attack (sering juga disebut MFA push bombing atau prompt bombing) adalah teknik penyalahgunaan autentikasi multi-faktor (MFA) berbasis push notification. Penyerang mengirimkan permintaan login berulang-ulang ke perangkat korban, berharap korban merasa lelah, panik, atau bingung—lalu akhirnya menekan tombol Approve agar notifikasi berhenti.

Serangan ini tidak “membobol” MFA secara teknis, tetapi menyerang faktor manusia: kebiasaan pengguna, konteks kerja yang sibuk, serta asumsi bahwa notifikasi login berasal dari aktivitas sah. Karena itu, MFA fatigue attack menjadi ancaman nyata pada organisasi yang mengandalkan push-based MFA tanpa kontrol tambahan.

Mengapa MFA Fatigue Attack Efektif?

Secara teori, MFA dibuat untuk mencegah pengambilalihan akun walau password bocor. Namun pada praktiknya, MFA fatigue attack memanfaatkan beberapa kondisi umum:

• Password sudah bocor (phishing, reuse password, credential stuffing), sehingga penyerang bisa memicu prompt MFA kapan saja.
• Notifikasi push terlalu mudah disetujui (satu tap “Approve”).
• Pengguna mengira ada sistem error atau aktivitas normal (misalnya aplikasi sering re-login).
• Budaya “cepat klik” karena tekanan pekerjaan dan banyaknya notifikasi.
• Kurangnya sinyal konteks: prompt hanya menampilkan “Approve sign-in?” tanpa detail perangkat/lokasi yang jelas.

Akibatnya, satu persetujuan yang keliru bisa membuka jalan untuk akses email, file internal, VPN, dashboard admin, hingga eskalasi ke sistem lain jika sesi autentikasi dipercaya.

Tanda-Tanda Organisasi Anda Sedang Diserang

Mendeteksi MFA fatigue attack lebih mudah jika Anda tahu pola yang perlu dicurigai. Perhatikan indikator berikut:

• Lonjakan permintaan MFA ke pengguna tertentu dalam waktu singkat (menit/jam).
• Notifikasi MFA muncul saat pengguna tidak sedang login atau di luar jam kerja.
• Serangkaian “denied” lalu satu “approved” pada log autentikasi.
• Percobaan login dari lokasi/ASN negara yang tidak biasa dibandingkan kebiasaan pengguna.
• Pengguna melapor ponsel “bergetar terus” karena banyak prompt autentikasi.

Jika Anda punya SOC atau tim IT, masukkan pola ini sebagai use case monitoring. Banyak insiden dimulai dari sinyal kecil yang diabaikan.

Defense Utama: Kurangi Ketergantungan pada Push “Approve” Satu Ketuk

Tujuan defense adalah membuat pengguna sulit salah klik dan membuat penyerang sulit mengulang prompt tanpa konsekuensi. Berikut kontrol yang paling efektif, mulai dari yang berdampak tinggi:

1) Aktifkan Number Matching (atau Challenge-Response)

Jika penyedia identitas Anda mendukung, gunakan number matching: ketika login diminta, pengguna harus mencocokkan angka yang tampil di layar login dengan yang muncul di aplikasi authenticator. Ini mengurangi peluang persetujuan impulsif karena pengguna harus sadar sedang login ke sesi tertentu.

Prinsipnya: menciptakan “friksi yang sehat” agar persetujuan membutuhkan perhatian.

2) Terapkan “MFA Prompt Rate Limiting” dan Lockout

Batasi jumlah prompt MFA yang dapat dipicu dalam interval tertentu. Jika ada pola permintaan berulang, sistem harus:

• Memblokir sementara permintaan berikutnya (cooldown).
• Memaksa metode verifikasi alternatif yang lebih kuat.
• Memberi alert ke SOC/IT dan pengguna.

Kontrol ini menurunkan efektivitas “bombing” karena penyerang tidak bisa membanjiri notifikasi tanpa batas.

3) Utamakan Phishing-Resistant MFA (FIDO2/WebAuthn)

Untuk akun berisiko tinggi (admin, finance, HR, developer, helpdesk), pertimbangkan phishing-resistant MFA seperti security key FIDO2/WebAuthn atau passkey yang terikat perangkat dan origin. Selain kuat terhadap phishing, model ini tidak berbasis “approve notifikasi” sehingga lebih tahan terhadap fatigue.

Strategi yang sering berhasil: mulai dari privileged accounts, lalu perluas ke pengguna lain secara bertahap.

4) Perkuat Conditional Access Berbasis Risiko

Gunakan kebijakan akses kondisional agar prompt MFA tidak berdiri sendiri, misalnya:

• Blokir login dari negara/region tertentu yang tidak relevan dengan bisnis.
• Wajibkan device compliance (MDM) sebelum akses aplikasi sensitif.
• Step-up authentication hanya ketika ada perubahan risiko (lokasi baru, perangkat baru).
• Batasi legacy authentication (misalnya protokol lama) yang bisa menghindari kontrol modern.

Hasilnya: walau penyerang punya password, upaya memicu MFA dari konteks aneh lebih sering ditolak sebelum sampai ke pengguna.

5) Gunakan Metode MFA yang “User-Verifiable”

Jika push notification tetap digunakan, pastikan prompt menampilkan detail yang membantu pengguna memverifikasi:

• Lokasi perkiraan atau negara.
• Nama aplikasi yang meminta akses.
• Perangkat/sistem operasi yang memulai login.
• Waktu dan kode verifikasi bila memungkinkan.

Semakin jelas konteksnya, semakin kecil peluang pengguna menyetujui permintaan yang bukan miliknya.

Defense Operasional: Edukasi Pengguna yang Tepat (Bukan Sekadar “Jangan Klik”)

MFA fatigue attack menargetkan kebiasaan manusia, jadi edukasi tetap penting. Namun pelatihannya harus spesifik dan dapat dipraktikkan:

• Aturan emas: jika tidak sedang login, selalu tekan Deny dan laporkan.
• Jangan pernah menyetujui prompt hanya agar notifikasi berhenti.
• Kenali momen rawan: saat rapat, sibuk, atau di luar jam kerja.
• Saluran pelaporan cepat: tombol/kanal khusus (misalnya tiket “MFA prompt spam”) agar respon cepat.

Tambahkan simulasi awareness yang realistis: bukan hanya phishing email, tetapi juga “spam prompt” untuk melatih reaksi yang benar dan pelaporan yang cepat.

Monitoring dan Deteksi: Apa yang Perlu Dilog dan Diawasi

Defense teknis makin kuat jika didukung deteksi. Beberapa praktik yang umum dipakai SOC:

• Alert untuk N kali prompt MFA gagal dalam X menit pada akun yang sama.
• Korelasi login mencurigakan: lokasi baru + banyak prompt + perangkat baru.
• Deteksi “deny spam”: banyak penolakan dari pengguna dapat berarti akun sedang ditarget.
• Watchlist akun prioritas (admin, eksekutif) dengan threshold lebih ketat.

Pastikan log autentikasi tersentralisasi (SIEM/monitoring) dan memiliki retensi memadai untuk investigasi insiden.

Respons Insiden: Jika Pengguna Terlanjur Menekan Approve

Jika ada dugaan pengguna menyetujui prompt yang bukan miliknya, anggap sebagai insiden pengambilalihan akun sampai terbukti sebaliknya. Langkah defensif yang aman biasanya mencakup:

• Cabut sesi aktif (sign-out global) dan token yang masih berlaku.
• Reset kredensial dan pastikan password baru unik (cek kebijakan panjang/kompleksitas).
• Tinjau metode MFA: hapus perangkat MFA yang tidak dikenal, lakukan re-enrollment.
• Periksa aturan forwarding/inbox pada email (indikator umum persistensi).
• Audit aktivitas: login, akses file, perubahan permission, pembuatan app token, dan perubahan keamanan.
• Terapkan pembatasan tambahan (conditional access lebih ketat) untuk akun tersebut sementara waktu.

Jika organisasi Anda memiliki prosedur IR formal, pastikan skenario MFA fatigue masuk ke playbook: siapa yang dihubungi, bukti apa yang dikumpulkan, dan kapan eskalasi dilakukan.

Checklist Praktis Defense MFA Fatigue Attack (Ringkas)

• Aktifkan number matching atau metode challenge-response.
• Batasi prompt dengan rate limiting/lockout berbasis anomali.
• Prioritaskan FIDO2/WebAuthn untuk akun berisiko tinggi.
• Perkuat conditional access (lokasi, device compliance, risiko).
• Monitoring terpusat untuk anomali autentikasi dan prompt berulang.
• Training yang spesifik dan jalur pelaporan yang cepat.
• Playbook respons untuk kasus “terlanjur approve”.

FAQ: Pertanyaan yang Sering Muncul

1) Apakah MFA fatigue attack berarti MFA tidak efektif?

Tidak. MFA tetap sangat membantu, tetapi implementasinya menentukan efektivitas. Push-based MFA yang hanya mengandalkan tombol “Approve” lebih rentan terhadap serangan berbasis rekayasa sosial. Menambahkan number matching, conditional access, dan metode phishing-resistant akan membuat MFA jauh lebih kuat.

2) Apakah SMS OTP aman untuk menggantikan push notification?

SMS OTP umumnya lebih baik daripada tanpa MFA, tetapi memiliki risiko sendiri (misalnya SIM swap, intercept). Untuk defense jangka panjang, pertimbangkan authenticator dengan number matching atau FIDO2/WebAuthn untuk akun penting.

3) Bagaimana cara membedakan prompt MFA yang sah dan yang berbahaya?

Aturan praktis: prompt sah hampir selalu terjadi saat Anda sedang login dan konteksnya sesuai (aplikasi, perangkat, waktu). Jika prompt muncul saat Anda tidak melakukan login, atau detail lokasi/perangkat tidak dikenal, tekan Deny dan laporkan.

4) Kontrol mana yang paling cepat memberi dampak?

Biasanya kombinasi number matching + rate limiting + conditional access berbasis risiko. Ini bisa menurunkan insiden dengan cepat tanpa harus langsung mengganti semua metode MFA.

5) Siapa yang harus diprioritaskan untuk phishing-resistant MFA?

Mulailah dari akun privileged (admin sistem, cloud admin), lalu kelompok berisiko tinggi seperti finance/HR/helpdesk, dan akun eksekutif. Serangan terhadap akun-akun ini biasanya berdampak paling besar, sehingga kontrol lebih kuat memberikan ROI keamanan yang tinggi.

Penutup

MFA fatigue attack mengingatkan bahwa keamanan identitas tidak hanya soal teknologi, tetapi juga soal desain pengalaman pengguna, kontrol akses berbasis konteks, dan kesiapan operasional. Dengan mengganti “approve satu ketuk” menjadi verifikasi yang lebih sadar (number matching), membatasi spam prompt, menerapkan conditional access, serta meningkatkan monitoring dan playbook respons, organisasi dapat menurunkan risiko pengambilalihan akun secara signifikan—tanpa mengorbankan produktivitas.