Phishing Kode Perangkat OAuth: Perbandingan Azure vs. Google

Ditulis oleh Matt Kiely, Peneliti Keamanan Utama di Huntress

Ikutlah bersama saya dalam perjalanan saat kita menyelidiki kegilaan serangan identitas yang terus bergema. Hari ini, saya menyajikan studi kasus tentang bagaimana berbagai implementasi OAuth 2.0, skema autentikasi inti yang digunakan di sebagian besar penyedia identitas, dapat memiliki permukaan serangan yang sangat berbeda.

Subyek studi kasus hari ini adalah dua toko teknologi baru yang sedang naik daun di Silicon Valley: Microsoft Dan Google. Mungkin Anda pernah mendengarnya?

Mari kita lihat bagaimana salah satu serangan identitas favorit saya, Phishing Kode Perangkat, terjadi di antara kedua penyedia identitas ini. Di akhir blog ini, Anda, para pembaca yang budiman, akan memahami perbandingan penerapan OAuth 2.0 antara kedua penyedia identitas ini dan bagaimana hal tersebut secara langsung memfasilitasi atau meniadakan radius ledakan dari serangan yang sangat kuat ini.

Siap menjadi kutu buku dengan itu? Mari kita menjadi kutu buku dengan itu.

Temui Alur Kode Perangkat

Sebelum kita memahami Phishing Kode Perangkat, kita perlu memahami fitur yang memungkinkan terjadinya serangan ini. Mari kita mulai dengan perincian independen penerapan fitur yang dipermasalahkan dan cara eksploitasinya. Saatnya bertemu aliran kode perangkatalias itu pemberian otorisasi perangkat!

saya membaca RFC jadi kamu tidak perlu melakukannya. Meskipun saya akan merekomendasikannya jika Anda mencari alat bantu tidur.

Pemberian otorisasi perangkat digunakan dalam skenario di mana seseorang ingin mengautentikasi perangkat yang terhubung ke internet yang tidak memiliki mekanisme input tradisional seperti keyboard, browser web, atau sejenisnya. RFC menyebutnya perangkat dengan masukan terbatas. Bayangkan rata-rata printer IoT, smart TV, pemanggang roti berkemampuan wifi dengan layar sentuh, atau jenis perangkat lain apa pun yang tersambung ke internet tetapi tidak memiliki antarmuka pengguna berfitur lengkap.

Jika Anda ingin mengautentikasi pemanggang roti berkemampuan wifi ke penyewa cloud Anda (dan, sungguh, siapa yang tidak ingin sensasi melakukan hal itu?), Anda memiliki masalah. Anda tidak dapat menelusuri halaman login penyewa dari pemanggang roti dan memasukkan nama pengguna dan kata sandi Anda. Namun mari kita bayangkan dalam skenario ini pemanggang roti Anda memiliki layar sentuh tempat Anda dapat memasukkan kode enam digit. Anda tidak dapat menelusuri halaman login dan mengetikkan nama pengguna dan kata sandi Anda, jadi bagaimana Anda dapat mengautentikasi pemanggang roti?

Alur kode perangkat memungkinkan Anda untuk:

• Mulai proses otentikasi dari pemanggang roti dengan meminta a kode perangkat
• Pindah ke komputer dengan keyboard dan browser web
• Gunakan browser web untuk memasukkan kode perangkat bersama dengan kredensial Anda untuk menyelesaikan proses otentikasi, lalu…
• Kembali ke pemanggang roti dan ambil token akses yang Anda buat dengan masuk.

Ini secara efektif memecahkan masalah otentikasi perangkat dengan input terbatas. Sabas! Sekarang Anda dapat menggabungkan pemanggang roti Anda dengan penyewa Anda.

Jika ini terdengar sangat khusus, itu memang benar. Fitur OAuth ini memiliki penerapan yang sempit dan hanya digunakan dalam beberapa skenario oleh jenis pengguna tertentu. Sederhananya, rata-rata pengguna di SMB kemungkinan besar tidak perlu mengetahui aliran kode perangkat.

Jika peretas pandai dalam hal apa pun, mereka akan menemukan fitur khusus seperti aliran kode perangkat dan mengubah metode autentikasi satu kali ini menjadi vektor akses awal. Jadi mari kita bahas tentang phishing dengan kode perangkat!

Phishing Kode Perangkat di M365

Phishing dengan mengeksploitasi aliran kode perangkat bukanlah hal baru. Beberapa peneliti identitas besar di zaman kita telah menulis tentang subjek ini, termasuk Dr.Nestori Syynimaa, Dirk-jan MollemaDan Lina La (@inversecos). Dengan menerapkan beberapa kemahiran rekayasa sosial, aliran kode perangkat dapat dikooptasi dan digunakan secara jahat untuk menghasilkan token akses ke beberapa sumber daya yang kemudian dapat dipulihkan oleh penyerang.

Begini cara turunnya:

• Penyerang meminta kode perangkat dari API kode perangkat penyedia identitas. Meminta kode tidak memerlukan autentikasi dan menggunakan API yang sepenuhnya sah untuk melakukannya.
• Penyerang membuat email yang meyakinkan dan mengirimkannya kepada korban, yang memaksa korban untuk membuka halaman login kode perangkat dan memasukkan kode tersebut.
• Korban mematuhi dan membuka halaman login kode perangkat yang benar-benar sah di mana mereka memasukkan kode perangkat, nama pengguna dan kata sandi, serta kode MFA mereka. Dan kemudian… tidak terjadi apa-apa, setidaknya dari sudut pandang korban…
• …tetapi penyerang telah memantau API kode perangkat sepanjang waktu dan bertanya setiap 10 detik “apakah mereka sudah mengautentikasi?” Setelah pengguna menyelesaikan autentikasi, API autentikasi kode perangkat menghasilkan satu set token akses untuk korban.
• Penyerang meminta kumpulan token, yang kemudian dijadikan akses awal.

Mari kita lihat contoh nyata di mana aliran kode perangkat Azure digunakan untuk melakukan serangan ini.

Pertama, penyerang meminta kode perangkat. Ini semudah mengeriting API aliran kode perangkat Azure. Ingat: sebagai penyerang, saya bisa melakukan ini. Saya tidak perlu mengautentikasi atau membuktikan siapa saya. Selama saya menyusun permintaan dengan benar, API akan menyerahkan kode perangkat untuk memulai proses. Permintaan cURL akan terlihat seperti ini…

  curl -X POST "https://login.microsoftonline.com/common/oauth2/devicecode?api-version=1.0"      -H "Content-Type: application/x-www-form-urlencoded"      -d "client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c&resource=https://graph.microsoft.com"

…Di mana:

• URL yang diminta adalah titik akhir API autentikasi kode perangkat umum Azure.
• Parameter client_id adalah GUID klien yang meminta (perhatikan ini; ini akan menjadi penting nanti).
• Parameter sumber daya adalah sumber daya yang diminta. Dalam hal ini, kami meminta API untuk menghasilkan sekumpulan token yang dapat mengautentikasi perangkat dengan Graph API.

Jika permintaan cURL diformat dengan benar, API akan merespons dengan blob JSON yang berisi kode perangkat, kode pengguna, dan beberapa petunjuk berguna tentang cara menggunakannya:

Pada titik ini, dalam skenario autentikasi kode perangkat yang sah, pengguna akan berpindah dari perangkat dengan input terbatas ini ke komputer dengan browser web, menelusuri ke https://microsoft.com/devicelogindan masuk menggunakan browser web mereka. Namun dalam skenario serangan, penyerang membuat phish meyakinkan yang memerintahkan pengguna untuk membuka halaman login kode perangkat yang sama, masuk, dan menunggu instruksi lebih lanjut.

Mari kita asumsikan bahwa penyerang mengirimkan phish ini dengan dalih yang meyakinkan, sehingga korban dapat menelusurinya https://microsoft.com/devicelogin dan memasukkan kode yang diberikan, mengabaikan peringatan tentang memasukkan kode dari sumber yang tidak tepercaya…

Halaman tersebut kemudian meminta korban untuk memasukkan nama pengguna dan kata sandi…

…dan beralih ke pemeriksaan MFA, yang diwajibkan oleh korban…

Halaman tersebut kemudian menampilkan satu pertanyaan terakhir yang menanyakan apakah korban mencoba masuk ke Microsoft Office, yang dianggap rutin oleh pengguna dan mengklik lanjutkan…

Dan akhirnya korban melihat ini (gambar 9):

Yang tentunya sangat membingungkan jika Andalah yang menjadi korban serangan ini.

Sementara itu, di tempat lain, penyerang membuat perintah cURL lain untuk melakukan polling API autentikasi Azure:

  curl      --data client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c      --data resource=https://graph.microsoft.com      --data grant_type=urn:ietf:params:oauth:grant-type:device_code      --data code=EAQABIQ......[snip].....     "https://login.microsoftonline.com/Common/oauth2/token?api-version=1.0

…Di mana:

• Parameter client_id dan resource sama dengan permintaan awal
• Grant_type menentukan bahwa metode autentikasi yang digunakan untuk token ini adalah aliran kode perangkat
• Parameter kode adalah kode perangkat yang dikembalikan dari permintaan awal
• URL di sini adalah titik akhir token Azure OAuth, yang menangani permintaan dan respons untuk menghasilkan token autentikasi.

Setelah pengguna menjadi korban phish, autentikasi mereka menghasilkan sekumpulan token yang sekarang berada di titik akhir API token OAuth dan dapat diambil dengan memberikan kode perangkat yang benar. Penyerang, tentu saja, mengetahui kode perangkat karena dihasilkan oleh permintaan cURL awal ke API login kode perangkat. Meskipun kode tersebut tidak berguna, setelah korban ditipu untuk melakukan autentikasi, token yang dihasilkan kini menjadi milik siapa pun yang mengetahui kode perangkat mana yang digunakan dalam permintaan awal.

Serangan yang berhasil menghasilkan penyerang memperoleh token akses dan sebuah token penyegaran yang efektif untuk korban phishing. Token tersebut efektif untuk sumber daya yang diminta (dalam hal ini, Graph API) dan mencakup serangkaian izin OAuth yang memungkinkan penyerang mengakses sumber daya seolah-olah mereka adalah korban phishing. Serangan selesai, akses awal diperoleh, penjahat dunia maya senang!

Ada beberapa hal yang membuat serangan ini berbahaya.

Pertama, serangan ini menggunakan alur autentikasi yang sah alih-alih mengeksploitasi beberapa kerentanan atau bug. Seluruh konteks phishing tetap ada infrastruktur Microsoft yang sahmenggunakan API Microsoft yang sahuntuk melakukan sah (jika tidak dibajak) alur otentikasi kode perangkat. Tidak ada eksploitasi sebenarnya yang terjadi selama serangan ini selain menipu seseorang agar menggunakan aliran kode perangkat padahal seharusnya tidak.

Kedua, karena poin sebelumnya tentang penggunaan fungsi otentikasi yang sah, penyerang dapat menggunakan URL yang sah selama bagian phishing. Pengguna yang mengikuti Pelatihan Kesadaran Keamanan mungkin mengetahui bahwa mereka curiga terhadap tautan, namun mungkin akan lengah saat melihatnya. https://microsoft.com/devicelogin sebagai URL-nya. Saya tidak mencemarkan URL ini dalam teks blog ini karena suatu alasan – ini 100% benar-benar sah, tidak berbahaya, dan aman untuk mengunjungi situs tersebut. Melalui seluruh contoh yang didokumentasikan di atas, saya tidak pernah sekalipun mengirim korban ke situs yang tidak jelas dan meminta mereka memasukkan kredensial mereka. Jadi bayangkan betapa hebatnya ketika Anda, sebagai penyerang, menggunakan URL Microsoft yang sah untuk serangan phishing Anda.

Terakhir (dan yang paling penting), penyerang mengontrol jenis sumber daya dan token tertentu yang dihasilkan karena serangan ini. Dalam contoh di atas, penyerang membuat kode perangkat yang dicakup ke Graph API dan menentukan ID klien. Ingat bagaimana saya mengatakan untuk mengingat ID klien karena itu penting nantinya? Dengan baik…

ID klien dalam contoh di atas bukanlah rangkaian karakter acak. Faktanya, penerapan OAuth Microsoft mencakup serangkaian ID klien tidak berdokumen yang tersedia secara bebas untuk digunakan siapa saja selama proses autentikasi. aliran asi. Ini disebut Keluarga ID Klien dan ditemukan baru-baru ini oleh peneliti Secureworks. Topik ini cukup rumit, namun untuk meringkasnya secara singkat: kombinasi ID klien dan sumber daya yang diminta menghasilkan token yang dapat dicakup ke berbagai hal.

Misalnya, ID klien yang digunakan dalam contoh di atas sesuai dengan klien Microsoft Office. Saat token dibuat untuk Graph API, token yang dihasilkan dapat digunakan untuk memanggil Graph API dan membaca email pengguna, melihat kalender mereka, membaca file mereka, dan banyak hal lain sebagaimana ditentukan dalam cakupan token:

  "scp": "AuditLog.Create AuditLog.Read.All Calendar.ReadWrite Calendars.Read.Shared Calendars.ReadWrite Contacts.ReadWrite DataLossPreventionPolicy.Evaluate Directory.AccessAsUser.All Directory.Read.All Files.Read Files.Read.All Files.ReadWrite.All Group.Read.All Group.ReadWrite.All InformationProtectionPolicy.Read Mail.ReadWrite Mail.Send Notes.Create Organization.Read.All People.Read People.Read.All Printer.Read.All PrinterShare.ReadBasic.All PrintJob.ReadWriteBasic SensitiveInfoType.Detect SensitiveInfoType.Read.All SensitivityLabel.Evaluate Tasks.ReadWrite TeamMember.ReadWrite.All TeamsTab.ReadWriteForChat User.Read.All User.ReadBasic.All User.ReadWrite Users.Read",

Meskipun Kelompok ID Klien sangat menarik, sebagian besar berada di luar cakupan postingan blog ini. Namun dua hal penting yang bisa diambil adalah:

• Penyerang menentukan sumber daya yang diminta dan ID klien dalam permintaan asli, yang akan memengaruhi kekuatan token yang dihasilkan
• Microsoft memiliki serangkaian ID klien yang tersedia untuk umum dan diakui secara universal yang memengaruhi cakupan token yang dihasilkan.

Untuk mengilustrasikan secara singkat kekuatan membiarkan penyerang mengontrol sumber daya dan ID klien selama autentikasi, lihat saja Blog Dirk-jan tentang Phishing untuk Token Penyegaran Utamadi mana ia mendemonstrasikan bagaimana penyerang dapat memanfaatkan phishing kode perangkat untuk menghasilkan Token Penyegaran Utama dan mencurinya untuk akses awal. Khususnya, hal ini dimungkinkan karena penyerang dapat menetapkan sumber daya permintaan kode perangkat sebagai https://enrollment.manage.microsoft.com/ dan ID klien ke Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e). Token yang dihasilkan dari keberhasilan melakukan phishing terhadap korban dengan parameter ini adalah jenis token paling kuat dalam skema token Azure OAuth.

Token ini dapat digunakan, antara lain, untuk masuk ke sumber daya web, menggabungkan perangkat jahat ke penyewa, membuat pendaftaran autentikasi multifaktor, dan masih banyak lagi. Ini adalah token paling kuat dalam satu mil negara dan hanya berjarak satu kode perangkat kecil dari kendali penyerang!

(Selain itu, jika Anda tertarik dengan penelitian identitas dan kerja sama merah, baca setiap blog yang diterbitkan oleh Dirk-jan. Anda tidak akan kecewa.)

Apakah Hanya Seperti Itu?

Kami telah mengetahui bagaimana phishing kode perangkat dilakukan di Azure dan ini sangat hebat. Penyerang mendapat kendali atas jenis sumber daya tertentu dan cakupan token yang dihasilkan. Ini adalah serangan yang sepenuhnya terjadi di ekosistem Microsoft. Kemungkinan terburuknya, hal ini dapat digunakan untuk mencuri jenis token paling kuat yang pernah ada.

Namun perlu diingat bahwa alur autentikasi kode perangkat bukanlah mekanisme khusus Azure. Sebaliknya, Azure mengimplementasikan aliran kode perangkat sebagai metode autentikasi. Spesifikasi aliran kode perangkat berasal dari OAuth 2.0 RFC. Azure bukanlah satu-satunya penyedia identitas yang mengimplementasikan aliran kode perangkat. Jadi aku tidak bisa tidak bertanya-tanya…

Apakah ini berarti apa pun penyedia identitas yang Anda gunakan, phishing kode perangkat sama berbahayanya? Apakah hanya seperti itu?

Peringatan spoiler! Jawabannya, yang mengejutkan, adalah tidak. Dan kita tidak perlu melihat lebih jauh lagi selain Google untuk melihat contoh di mana detail implementasi memiliki pengaruh besar terhadap seberapa besar kerusakan yang dapat ditimbulkan oleh teknik ini.

Google: Langsung Nerf

Anggaplah kita sedang terlibat dalam tim merah melawan klien yang menggunakan Google sebagai penyedia identitas utama mereka. Mari kita coba membuat ulang serangan phishing kode perangkat menggunakan Google Workspace/Google Cloud API. Seperti biasa, tempat terbaik untuk memulai adalah dokumentasi pengembang. Dan segera menjadi jelas bahwa kita akan berjuang keras:

Dokumentasi dengan jelas menyatakan bahwa tidak semua cakupan didukung oleh aliran kode perangkat. Namun peretas tidak pernah putus asa, jadi mari kita periksa cakupan mana yang didukung:

Jika Anda sudah familiar dengan cakupan OAuth 2.0 dan penyalahgunaannya secara umum oleh penyerang, Anda mungkin baru saja terkejut. Jika Anda belum mengetahuinya, saya dapat meringkasnya seperti ini – tiga cakupan pertama bersifat universal di semua implementasi OAuth 2.0 dan OpenID Connect (OIDC) dan memungkinkan eksploitasi terbatas, jika ada. Cakupan yang didukung lainnya sangatlah sempit ketika kita mencari primitif eksploitasi.

Misalnya saja saat ini – di Azure, Anda dapat menyiapkan serangan phishing kode perangkat di mana token yang dihasilkan pada dasarnya memungkinkan Anda menjadi pengguna korban, bergabung dengan perangkat jahat ke penyewa korban, masuk ke email mereka dan sumber daya lainnya, dan jenis akses luar biasa kuat lainnya. Dan di Google, kita dapat menggunakan cakupan izin file GDrive untuk… -memeriksa catatan- “melihat, mengedit, membuat, dan menghapus hanya file Google Drive tertentu yang Anda gunakan dengan aplikasi ini”.

Bahkan sebelum kami memulai serangan, penerapan aliran kode perangkat oleh Google telah secara efektif menetralisir potensi serangan. Jika ada anggota tim merah yang membaca ini ingin memberi tahu saya cara mengubah cakupan youtube.readonly menjadi pengambilalihan akun, saya mendengarkan (tidak bercanda, hubungi saya: matt.kiely[at]hunterslabs.com dan saya ingin berbicara). Tapi aku tidak menahan nafas.

Tapi harapan abadi muncul, jadi mari kita coba melancarkan serangan. Sejauh yang saya tahu, tidak ada ID klien publik untuk Google seperti yang ada untuk Azure. Jadi jika kita ingin melakukan serangan, kita memerlukan ID klien. Cara yang disarankan untuk mendapatkan ID klien adalah dengan buat aplikasi Google Workspace dan konfigurasikan untuk menggunakan OAuth 2.0. Jadi jika Anda mengharapkan anonimitas saat melakukan serangan, Anda bisa membuangnya.

Meskipun Anda mengalami kesulitan dalam membuat aplikasi OAuth di Google, masih ada pemeriksaan dan perlindungan lain yang diterapkan. Misalnya, jika aplikasi Anda memerlukan terlalu banyak izin yang kuat, aplikasi tersebut harus dipublikasikan dan diverifikasi sebelum siapa pun dapat menggunakannya:

Tapi itu tidak akan menjadi masalah bagi kita, ingat? Kami dibatasi pada empat cakupan izin: dua untuk GDrive dan dua untuk YouTube. Kami tidak benar-benar bekerja dengan eksploitasi primitif yang kuat di sini.

Langkah-langkah teknis untuk meminta kode perangkat dari Google sebagian besar sama dengan Azure. Demi variasi, kami akan menggunakan Python untuk melakukan permintaan awal dan melakukan polling pada titik akhir hingga autentikasi selesai:

  import requests    import time        # Replace with your Google OAuth client ID. Best I can tell, there are no public client IDs in Google, so you're on your own to procure one.    CLIENT_ID = "[YOUR APPLICATION'S CLIENT ID]"    CLIENT_SECRET = "[YOUR APPLICATION'S CLIENT SECRET]"    DEVICE_AUTH_URL = 'https://oauth2.googleapis.com/device/code'    TOKEN_URL = 'https://oauth2.googleapis.com/token'    SCOPE = 'https://www.googleapis.com/auth/drive.file openid email profile'            def get_device_code():     data = {     'client_id': CLIENT_ID,     'scope': SCOPE     }     response = requests.post(DEVICE_AUTH_URL, data=data)     response.raise_for_status()     return response.json()        def poll_for_token(device_code, interval):     while True:     data = {     'client_id': CLIENT_ID,     'client_secret': CLIENT_SECRET,     'device_code': device_code,     'grant_type': 'urn:ietf:params:oauth:grant-type:device_code'     }     response = requests.post(TOKEN_URL, data=data)         if response.status_code == 200:     return response.json()     elif response.status_code == 428:     print("Authorization pending... waiting.")     elif response.status_code == 403:     print("Access denied. Exiting.")     break     else:     print("An error occurred:", response.json())     break         time.sleep(interval)        def main():     device_data = get_device_code()     print("Visit this URL to authorize the application:", device_data['verification_url'])     print("Enter this code:", device_data['user_code'])         token_data = poll_for_token(device_data['device_code'], device_data['interval'])     if token_data:     print("Access token received:", token_data['access_token'])     print("Refresh token:", token_data.get('refresh_token', 'None'))        if __name__ == '__main__':     main()

Saat kami menjalankan skrip, skrip tersebut memberi kami kode perangkat. Kami berpura-pura melakukan phishing kepada pengguna dan memerintahkan mereka untuk mengautentikasi seperti halnya serangan phishing kode perangkat Azure:

Setelah korban memasukkan kredensial mereka, kami mendapatkan token akses dan token penyegaran! Namun semoga berhasil menggunakan keduanya untuk mendapatkan akses awal mengingat cakupannya yang terbatas.

Catatan penting: Saya benar-benar baru mengetahui permukaan serangan dengan Google dibandingkan dengan Azure. Mungkin ada ID klien yang tidak terdokumentasi, cakupan tidak terdokumentasi yang tersedia untuk dieksploitasi, dan banyak kemungkinan vektor serangan lainnya di sini yang tidak saya ketahui dan/atau komunitas. Namun menurut saya sudah jelas bahwa vektor serangan di Google Cloud jauh lebih terbatas jika dibandingkan dengan Azure yang setara.

Analisis & Kesimpulan

Perbedaan yang cukup besar antara kedua penyedia identitas tersebut!

Jika saya bisa meringkas kesimpulan utamanya di sini, ini dia: Google memahami bahwa aliran kode perangkat bersifat khusus dan hanya digunakan dalam skenario tertentu dan membatasi cakupan yang tersedia untuk aliran kode perangkat. Microsoft tidak membuat batasan seperti itu.

Anda bisa membayangkan mengapa Google memilih menerapkannya dengan cara ini. Kedua set izin tersebut berkaitan dengan GDrive dan YouTube. Google memahami bahwa jenis perangkat klien yang mungkin akan menggunakan alur autentikasi kode perangkat adalah smart TV (dokumentasi bahkan menyebutkan hal ini dalam judul! “OAuth 2.0 untuk TV dan Aplikasi Perangkat Input Terbatas”). Tidak sulit membayangkan jenis akses yang dibutuhkan TV yang berpusat pada hiburan – “hai smart TV, tolong putar video YouTube favorit saya!”

Namun luangkan waktu sejenak untuk memahami fakta bahwa dua implementasi fitur OAuth yang sama memiliki permukaan serangan yang sangat berbeda yang terkait dengannya. Kurangnya pembatasan Azure pada cakupan dan sumber daya yang diminta telah menyebabkan para peneliti mengidentifikasi serangan primitif yang sangat kuat untuk serangan phishing kode perangkat. Namun penerapan Google memberikan pembatasan ketat pada jenis serangan yang sama.

Meskipun tidak jelas apakah serangan identitas lainnya (serangan pemberian izin, penggabungan perangkat jahat, dll) sama efektifnya di Google seperti halnya di Azure, kami dapat menyimpulkan bahwa phishing kode perangkat kurang efektif di Google Cloud dibandingkan di Azure.

Fitur yang sama. Desain yang sama. Implementasi yang berbeda. Permukaan serangan yang sangat berbeda! Hal ini menunjukkan kepada Anda: meskipun semua implementasi OAuth 2.0 sama, ternyata ada beberapa yang lebih setara dibandingkan yang lain.

Peretasan Langsung: Menghancurkan Teknik Serangan Microsoft 365

Bergabunglah dengan CEO Huntress dan mantan agen NSA Kyle Hanslovan untuk a demo peretasan langsung. Saksikan bagaimana peretas mencuri kredensial, melewati MFA, dan menyusupi sistem dalam hitungan menit. Pelajari tentang ancaman utama tahun 2026: rekayasa sosial, pencurian kredensial browser, dan serangan sistem yang saling berhubungan.

Peserta mendapatkan akses gratis ke Penilaian Keamanan Identitas untuk Microsoft 365, yang mengungkap kerentanan dan memberikan petunjuk penyiapan untuk demo peretasan Anda sendiri.

Jangan lewatkan kesempatan ini untuk memperkuat pertahanan Anda dan mengakali penjahat dunia maya modern. Ayo bersantai, belajar, dan bersiaplah untuk menantang keahlian masa kini!

Daftar untuk Peretasan Langsung

Disponsori dan ditulis oleh Lab Pemburu.