Ketika kesadaran tumbuh di sekitar banyak metode MFA yang “phishable” (yaitu tidak tahan phishing), metode otentikasi berbasis kata sandi, FIDO2 (alias. Passkeys) seperti Yubikeys, Okta Fastpass, dan Windows Hello semakin diadvokasi.
Ini adalah hal yang baik. Faktor MFA yang paling umum digunakan (seperti kode SMS, pemberitahuan push, dan OTP berbasis aplikasi) secara rutin dilewati, dengan kit phishing “penyerang-dalam-tengah” modern-proxy modern, metode yang paling umum (dan pilihan standar untuk serangan phishing saat ini).
Ini bekerja dengan mencegat sesi yang diautentikasi yang dibuat ketika seorang korban memasukkan kata sandi mereka dan menyelesaikan pemeriksaan MFA. Untuk melakukan ini, situs web phishing hanya menyampaikan pesan antara pengguna dan situs web yang sebenarnya-karenanya “penyerang di tengah-tengah”.
Sebaliknya, login berbasis passkey tidak dapat dipasangkan. Karena login berbasis passkey terikat domain, mencoba menggunakan passkey untuk Microsoft.com pada phishing.com Tidak akan menghasilkan nilai yang benar untuk melewati pemeriksaan otentikasi, bahkan ketika diproksi menggunakan kit AITM.
Tapi penyerang tidak menyerah dengan mudah. Ketika Passkeys menjadi lebih populer, kami melihat sejumlah teknik yang dirancang untuk menurunkan peringkat atau menghindari proses otentikasi untuk membuatnya rentan terhadap serangan phishing.
Jadi, inilah semua teknik yang digunakan penyerang untuk berkeliling Passkeys (sejauh ini).
Serangan penurunan peringkat
Serangan penurunan peringkat adalah metode masuk yang digunakan oleh penyerang untuk berkeliling MFA yang tahan phishing. Fungsi penurunan peringkat MFA telah diamati dalam sejumlah kit AITM kriminal dan bahkan mungkin menggunakan kit komoditas seperti Evilginx.
Saat melakukan serangan phishing penyerang-di-tengah, penyerang tidak perlu menyampaikan 100% pesan secara akurat. Sebaliknya, mereka dapat mengubah beberapa dari mereka. Aplikasi ini mungkin bertanya kepada pengguna “Anda perlu MFA – apakah Anda ingin menggunakan passkey Anda, atau kode authenticator cadangan Anda?”, Tetapi situs web phishing mungkin memodifikasi halaman ini untuk mengatakan “Anda perlu MFA – gunakan kode authenticator cadangan Anda” tidak memberi Anda opsi untuk menggunakan passkey aman Anda. Ini disebut serangan downgrade.
Ini juga dapat diterapkan pada akun yang menggunakan SSO sebagai metode login default. Dalam skenario ini, kit Phish dapat memilih opsi nama pengguna dan kata sandi cadangan untuk memungkinkan serangan phishing melanjutkan.
Berikut adalah contoh Evilginx dengan phishlet khusus untuk menurunkan otentikasi untuk akun Microsoft menggunakan Windows Hello.
Jadi, Anda memiliki situasi di mana bahkan jika metode login tahan phishing ada, adanya metode cadangan yang kurang aman berarti akun masih rentan terhadap serangan phishing.
Phishing kode perangkat
Untuk berkeliling metode otentikasi tahan phishing, penyerang juga menggunakan phishing kode perangkat Serangan yang memanfaatkan aliran otentikasi alternatif untuk perangkat yang tidak mendukung login berbasis passkey, misalnya karena mereka tidak memiliki browser web, atau memiliki kemampuan input terbatas.
Aliran login alternatif ini beroperasi dengan memasok pengguna dengan kode yang unik dan menginstruksikan mereka untuk mengunjungi halaman web di browser pada perangkat yang berbeda untuk memasukkan kode untuk mengotorisasi perangkat.
Ini dapat digunakan oleh musuh untuk melakukan serangan phishing terhadap target dengan meyakinkan mereka untuk mengunjungi situs web penyedia otentikasi mereka dan memasukkan kode yang disediakan oleh musuh, sehingga memberikan akses ke akun mereka.
Serangan ini memiliki keuntungan menghubungkan target ke URL yang sah, tanpa ada permintaan untuk menyetujui izin eksplisit di luar memasukkan kode perangkat dan masuk. Selain itu, aplikasi yang diverifikasi dapat disamar dalam beberapa kasus.
Teknik ini telah diamati dalam sejumlah kampanye baru-baru ini, termasuk penargetan akun M365 yang disponsori Rusia (1) (2).
Persetujuan phishing
Persetujuan phishing adalah salah satu teknik pertama yang ditambahkan ke SaaS menyerang matriks dan telah ada selama beberapa waktu, tetapi dengan peningkatan aktivitas jahat baru -baru ini.
OAuth memungkinkan pengguna untuk memberikan izin aplikasi pihak ketiga untuk mengakses data mereka. Musuh dapat menyalahgunakan fungsi ini dengan menipu pengguna untuk mengesahkan akses untuk aplikasi oAuth berbahaya.
Dalam serangan phishing persetujuan, musuh mengirimkan tautan phishing ke target yang meminta izin untuk mengakses data atau izin yang sensitif untuk melakukan tindakan berbahaya. Jika target memberikan persetujuan untuk izin, musuh memperoleh tingkat akses itu atas akun target. Tingkat akses ini akan memotong MFA dan bertahan melalui perubahan kata sandi.
PHISHING CONSENT paling sering dikaitkan dengan serangan yang ditujukan untuk mendapatkan akses ke Microsoft Azure atau penyewa Google Workspace. Namun, telah menjadi lebih umum bagi aplikasi SaaS untuk mengimplementasikan API OAuth-Authenticated dan toko aplikasi yang dapat ditargetkan dengan cara yang sama- Seperti yang terlihat dalam contoh baru -baru ini yang menargetkan pengguna GitHub.
Setelah diizinkan, penyerang memiliki akses luas ke akun. Dalam contoh ini yang mempengaruhi GitHub, penyerang akan dapat memodifikasi repositori untuk melakukan serangan lebih lanjut terhadap pengguna (misalnya dengan menginfeksi mereka dengan malware), meracuni repo dan layanan yang terhubung ke repositori, dan mengeluarkan data sensitif apa pun yang dapat diakses oleh akun.
Phishing verifikasi
Verifikasi email kadang -kadang digunakan sebagai kontrol, seperti saat mendaftarkan akun baru. Ini biasanya diimplementasikan dengan mengirim email ke pengguna target dengan tautan yang dapat diklik untuk mereka verifikasi atau kode verifikasi yang perlu mereka masukkan.
Phishing verifikasi adalah ketika musuh menggunakan phishing, atau jenis rekayasa sosial lainnya, untuk meyakinkan pengguna untuk mengklik tautan verifikasi atau meneruskannya kode verifikasi untuk mengalahkan kontrol ini.
Contoh teknik ini digunakan untuk memotong MFA Peniruan Cross-Idp. Di sinilah penyerang hanya mendaftarkan akun IDP baru ke domain email korban korban. Dalam banyak kasus, ini memungkinkan Anda untuk masuk melalui SSO menggunakan IDP baru tanpa pemeriksaan lebih lanjut – pada kenyataannya, 3 dari 5 aplikasi ditemukan untuk memungkinkan perilaku ini.
Ketika Anda mempertimbangkan sejumlah besar aplikasi yang dapat berfungsi sebagai IDP untuk keperluan SSO, ada beberapa target yang mungkin (tergantung pada aplikasi, dan metode login yang didukungnya).
IDP yang dikelola dapat dikelola secara terpusat oleh organisasi (yang memiliki dan mengoperasikan IDP dan identitas di atasnya), sedangkan pengungsi ‘sosial’ yang tidak dikelola dikendalikan oleh vendor, dan identitas dimiliki dan dikelola oleh pengguna.
Anda dapat melihat contohnya di video di bawah ini, atau Baca analisis dua contoh di bawah tanah di sini.
Phishing kata sandi khusus aplikasi
Phishing kata sandi khusus aplikasi adalah teknik rekayasa sosial di mana musuh menipu pengguna untuk menghasilkan “kata sandi khusus aplikasi” untuk akun mereka dan kemudian membaginya dengan penyerang. Kata sandi lama ini adalah fitur di beberapa penyedia SaaS utama (seperti Google dan Apple) yang dirancang untuk memungkinkan aplikasi lama yang tidak mendukung otentikasi modern (seperti OAuth 2.0) untuk mengakses data akun.
Aliran serangan biasanya melibatkan dalih di mana penyerang, menyamar sebagai entitas tepercaya (misalnya, dukungan teknis, penyedia layanan), mengarahkan pengguna ke pengaturan keamanan akun mereka. Pengguna kemudian dipandu melalui proses membuat kata sandi khusus aplikasi baru dan diinstruksikan untuk menempelkan kata sandi ini ke dalam formulir atau jendela obrolan yang dikendalikan oleh penyerang.
Karena kata sandi khusus aplikasi dirancang untuk digunakan di lingkungan yang tidak mendukung MFA, begitu penyerang memiliki kata sandi ini, mereka dapat memperoleh akses yang persisten dan terprogram ke data akun pengguna (misalnya, email, kontak, file) melalui API, seringkali tanpa memicu tingkat keamanan yang sama dengan login interaktif tradisional dari perangkat yang tidak diakui.
Hal ini membuat akses yang lebih cepat dan lebih tahan lama daripada token sesi, karena kata sandi ini biasanya tetap valid sampai dicabut secara manual oleh pengguna.
Contoh baru -baru ini diungkapkan Di mana seorang ahli operasi informasi Rusia ditargetkan dengan serangan rekayasa sosial yang canggih dan dipersonalisasi, di mana penyerang dapat membangun akses terus -menerus ke kotak surat korban menggunakan ASPS dengan masuk ke klien surat.
Ini melibatkan umpan canggih yang menyamar sebagai Departemen Luar Negeri AS yang menginstruksikan korban tentang cara membuat dan berbagi ASP dengan penyerang, memberikan akses ke Google Mailbox mereka.
Bonus: Menargetkan Akun Lokal Tidak Menggunakan Passkeys
Mungkin cara termudah untuk berkeliling Passkeys, adalah dengan menargetkan aplikasi yang tidak mendukung Passkeys secara asli. Passkeys biasanya digunakan dalam kombinasi dengan SSO, di mana Anda masuk ke penyedia IDP utama Anda dengan login yang aman dan dilindungi passkey, dan kemudian ke aplikasi yang terhubung melalui SSO. Banyak aplikasi tidak mengizinkan login passkey secara langsung.
Akibatnya, aplikasi seperti Slack, MailChimp, Postman, Github, dan aplikasi bisnis lainnya yang umum digunakan semakin ditargetkan secara langsung-melewati IDP (MS, Google, Okta, dll.) Yang biasanya memiliki kontrol otentikasi yang lebih kuat di tempat.
Sama seperti metode cadangan MFA sering terdaftar di samping Passkeys, lokal “Login Hantu” Metode sering terdaftar di samping SSO, yang berarti bahwa akun memiliki beberapa titik masuk yang mungkin.
Dalam banyak kasus, mereka tidak menggunakan MFA sama sekali – membuat mereka sama rentannya terhadap serangan menggunakan kredensial curian (seperti yang terlihat pada Kepingan salju serangan tahun lalu, dan Ada serangan tahun ini).
Ini menghasilkan a Permukaan serangan identitas yang luas dan rentan untuk dikelola organisasi.
Kesimpulan
Sebagian besar waktu, penyerang tidak harus melakukan sesuatu yang berbeda untuk berkeliling passkeys. Cukup menggunakan alat dan teknik phishing yang sama yang biasanya mereka terapkan akan menyelesaikan pekerjaan jika ada kemungkinan bahwa metode MFA non-passkey terdaftar ke akun.
Satu-satunya akun yang benar-benar aman adalah mereka yang hanya memiliki passkey, dan tidak ada metode cadangan atau kebijakan akses bersyarat yang mencegah otentikasi non-passkey.
Tapi iblis ada di detail di sini juga (seperti Contoh terbaru ini dari Templat CA yang disediakan Microsoft menetapkan masuk “berisiko” sebagai positif palsu dan memungkinkan mereka untuk melanjutkan).
Dan mengaudit aplikasi dan sprawl identitas Anda bukanlah prestasi yang berarti ketika Anda mempertimbangkan berbagai tingkat visibilitas dan kontrol yang tersedia untuk tim keamanan per aplikasi (dan fakta bahwa banyak aplikasi sama sekali tidak diadopsi atau diketahui secara terpusat).
Cegah dan mencegat serangan phishing dengan keamanan dorong
Serangan downgrade menggunakan kit phishing AITM merupakan sebagian besar serangan phishing yang memalsukan passkey.
Platform keamanan berbasis browser Push Security menyediakan deteksi serangan identitas yang komprehensif dan kemampuan respons terhadap teknik seperti phishing AITM, isian kredensial, penyemprotan kata sandi dan pembajakan sesi menggunakan token sesi curian.
Anda juga dapat menggunakan dorongan untuk menemukan dan memperbaiki kerentanan identitas di setiap aplikasi yang digunakan karyawan Anda, seperti: Ghost Login; Kesenjangan cakupan SSO; Kesenjangan MFA; kata sandi yang lemah, dilanggar dan digunakan kembali; integrasi oauth yang berisiko; dan lebih banyak lagi.
Jika Anda ingin mempelajari lebih lanjut tentang bagaimana dorongan membantu Anda mendeteksi dan mengalahkan teknik serangan identitas umum, Pesan waktu dengan salah satu tim kami untuk demo langsung.
Pasangan merah dan ditulis oleh Dorong keamanan.
