Ketika Microsoft Graph Menjadi Mesin Eksfiltrasi: Anatomi Persistensi MFA Setelah Phishing Bertema Passkey

Banyak organisasi di Indonesia sedang berada di tengah proyek migrasi identitas: mematikan kata sandi, mengaktifkan passkey, dan menggeser autentikasi ke metode yang tahan phishing. Proyek ini benar dan perlu. Masalahnya, periode transisi itu sendiri menciptakan kebisingan yang bisa dimanfaatkan: karyawan jadi terbiasa menerima instruksi tentang "pendaftaran ulang passkey" atau "sinkronisasi SSO", sehingga satu pesan palsu pun terasa wajar.

Pada 9 September 2026, Microsoft Security Research menerbitkan analisis sebuah rangkaian intrusi cloud yang persis memanfaatkan celah psikologis tersebut. Aktivitasnya sudah terpantau sejak Mei 2026. Yang membuat kasus ini layak dipelajari bukan umpannya — vishing berkedok help desk sudah lama kita kenal — melainkan apa yang terjadi setelah akun jatuh: penyerang mendaftarkan metode MFA miliknya sendiri, lalu menggunakan Microsoft Graph API sebagai mesin pemetaan dan pengangkut data selama berhari-hari, dengan pola lalu lintas yang sengaja dibuat menyerupai pemakaian kantor yang normal.

Passkey Hanya Umpan, Bukan Target

Perlu ditegaskan sejak awal agar tidak melahirkan kesimpulan yang keliru: passkey tidak dibobol dalam kampanye ini. Kriptografi FIDO2/WebAuthn tetap utuh. Kata "passkey" dipakai semata sebagai narasi sosial, karena istilah itu sedang populer dan terdengar teknis sehingga korban enggan mempertanyakannya.

Microsoft menyatakan bahwa meskipun umpan bertema passkey digunakan berulang kali, pendaftaran passkey kerap bukan tujuan sebenarnya. Umpan tersebut dipakai untuk menggiring korban ke dua jalur klasik: phishing adversary-in-the-middle (AiTM), atau alur device code authentication.

Rangkaiannya dimulai dari luar kanal korporat. Penyerang menelepon atau mengirim pesan ke nomor ponsel pribadi karyawan, mengaku dari help desk TI internal, dan menekankan urgensi: konfigurasi passkey, MFA, atau SSO harus segera diperbarui atau akses akan terputus. Tautan dikirim lewat SMS ke perangkat pribadi — perangkat yang hampir pasti tidak di-onboard ke EDR perusahaan. Konsekuensi forensiknya serius: tahap awal serangan tidak meninggalkan jejak apa pun di telemetri endpoint, dan sering kali ingatan karyawan tentang sebuah panggilan telepon menjadi satu-satunya bukti paling awal yang tersedia bagi tim respons insiden.

Riset pra-serangan dilakukan dari sumber terbuka. Microsoft menilai aktor berinvestasi besar dalam pengumpulan informasi pegawai dan struktur organisasi dari platform jejaring sosial dan profil profesional — sebuah pengingat bahwa permukaan serang OSINT organisasi Anda adalah bagian nyata dari permukaan serang teknisnya.

Pola Domain yang Mudah Dikenali

Infrastruktur phishing-nya memiliki tanda tangan yang cukup khas. Aktor mendaftarkan domain induk bertema generik, lalu menyisipkan nama organisasi korban sebagai subdomain, mengikuti pola namaperusahaan.domainjahat[.]com — misalnya contoso[.]add-passkey[.]com. Bagi korban, melihat nama perusahaannya sendiri di paling depan URL terasa meyakinkan; bagi tim keamanan, pola ini justru menjadi peluang deteksi yang bagus.

Beberapa domain induk yang dipublikasikan sebagai indikator:

1. Tema passkey: passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com
2. Tema SSO dan penyedia identitas: integratedsso[.]com, oktasession[.]com
3. Tema sinkronisasi kunci: syncmykey[.]com, keysyncos[.]com, oskeysync[.]com, oskeysetup[.]com, myconnectkey[.]com
4. Tema verifikasi dan portal: validationsetupac[.]com, portalsetuphub[.]com

Microsoft mencatat domain-domain ini kerap terdaftar melalui registrar Nicenic dan operasional hanya dalam hitungan jam — sekaligus mengingatkan bahwa pendaftaran di suatu registrar bukan bukti keterlibatan registrar tersebut. Untuk tim SOC, implikasi praktisnya jelas: umur domain yang sangat muda ditambah subdomain yang persis menyerupai nama perusahaan Anda adalah kombinasi yang layak diberi bobot deteksi tinggi pada pemantauan DNS dan proxy.

Tiga Jalur Kompromi Identitas

Microsoft mendokumentasikan tiga urutan berbeda yang bermuara pada hasil yang sama.

Pertama, AiTM melalui OfficeHome. Sesi masuk anomali dari perangkat tak terkelola, kemungkinan milik penyerang. Jejak autentikasinya memperlihatkan galat 50074 (autentikasi sekunder diperlukan), lalu 50140 (interupsi keep me signed in), sebelum akhirnya berhasil. Dalam hitungan menit setelah itu, sesi yang sama mengunjungi My Apps, My Profile, My Sign-Ins, dan Microsoft Account Controls — yaitu halaman-halaman pengelolaan identitas. Sesi bertahan sekitar satu jam dan merambah SharePoint Online, Outlook Web, hingga portal aplikasi virtual internal.

Kedua, device code phishing. Setelah umpan passkey, korban dibujuk memasukkan sebuah kode pada halaman autentikasi Microsoft yang asli. Persetujuan itu menerbitkan token kepada klien yang dikendalikan penyerang. Tidak ada kredensial yang dicuri, tidak ada cookie yang diambil — dan MFA tetap terlampaui. Inilah sebabnya alur device code perlu diperlakukan sebagai fitur berisiko tinggi yang harus dimatikan secara default.

Ketiga, penggunaan ulang kredensial lama. Login berhasil memakai kredensial hasil kompromi sebelumnya, dengan MFA disetujui melalui metode PhoneAppOTP yang ternyata telah didaftarkan penyerang beberapa hari sebelumnya. Aktivitas pada jalur ini dijalankan lewat sistem otomatis berbasis Node.js dan Microsoft Graph.

Persistensi: Mendaftarkan Faktor Kedua Milik Sendiri

Inilah pusat gravitasi serangan. Menurut Microsoft, tujuan pertama aktor setelah mendapat akses adalah mengubah kompromi sementara menjadi pijakan yang bertahan. Caranya bukan sekadar menyimpan kredensial curian, melainkan mendaftarkan metode MFA baru atas kendali penyerang — nomor telepon baru, aplikasi autentikator, atau token OTP berbasis perangkat lunak.

Dampaknya besar. Dengan faktor kedua sendiri, penyerang dapat masuk ke akun korporat korban tanpa partisipasi korban sama sekali. Teknik ini dipetakan MITRE ATT&CK sebagai T1556.006 (Modify Authentication Process: Multi-Factor Authentication).

Pendaftaran MFA saja memang tidak bertahan terhadap reset kredensial dan sesi secara menyeluruh, tetapi ia menjadi mekanisme persistensi yang tahan lama ketika dikombinasikan dengan token curian, sesi yang belum dicabut, atau akses lanjutan ke kredensial yang valid.

Catatan itu penting bagi prosedur respons insiden di Indonesia yang sering berhenti pada "reset password dan aktifkan MFA". Jika metode MFA milik penyerang tidak ikut dicabut, akun yang Anda anggap sudah bersih sebenarnya masih terbuka.

Kabar baiknya, artefak auditnya cukup khas. Pada peristiwa Update user. di log, properti StrongAuthenticationPhoneAppDetail memperoleh entri tambahan dengan penanda yang mencolok: "DeviceName": "NO_DEVICE", "DeviceToken": "NO_DEVICE_TOKEN", dan "DeviceTag": "SoftwareTokenActivated". Bandingkan dengan perangkat sah milik karyawan yang biasanya mencantumkan "DeviceTag": "iOS" beserta versi aplikasi autentikator yang nyata. Selisih waktu antara keduanya pun bisa hanya beberapa menit.

Microsoft Graph sebagai Peta dan Truk Pengangkut

Setelah persistensi terpasang, Graph API dipakai untuk menginventarisasi pengguna, grup, izin, sumber daya, dan konten yang dapat diakses di seluruh tenant. Microsoft memetakan pola pengintaiannya ke dalam beberapa kategori:

1. Profil tenant: /organization, /subscribedSkus — mengidentifikasi domain terverifikasi dan lisensi yang aktif.
2. Enumerasi direktori: /users, /groups, /members — menyusun peta identitas dan keanggotaan efektif.
3. Penemuan hak istimewa dan MFA: /directoryRoles, /roleManagement, /authentication/methods — mencari akun berprivilese dan celah persistensi berikutnya.
4. Aplikasi dan consent: /applications, /servicePrincipals, /oauth2PermissionGrants — membuka jalur akses yang dapat dipakai ulang.
5. Repositori dokumen: /sites, /drives, /drive/items, /search — mengubah pengintaian luas menjadi peta berkas yang siap dipanen.
6. Kotak surat: /messages, /mailFolders, /attachments — bahan baku untuk intelijen bisnis dan BEC lanjutan.

Otomatisasi dikenali dari penggunaan parameter paginasi berulang seperti $top, $skip, $skiptoken, dan $count, serta pemanggilan /delta dan /search secara bertubi-tubi.

Microsoft merangkum inti tantangan deteksinya dengan tajam: penyalahgunaan Graph jarang tampak mencurigakan bila dilihat dari satu panggilan API saja. Satu permintaan ke /users adalah hal paling normal di dunia. Yang tidak normal adalah urutannya — tenant, lalu direktori, lalu peran, lalu repositori, lalu konten — dari aktor yang sama dalam jendela waktu yang sempit. Karena itu aktivitas Graph harus dinilai secara holistik dengan penekanan pada progresi perilaku dan korelasi lintas peristiwa, bukan per permintaan.

Pengumpulan dan Eksfiltrasi yang Sengaja Dibuat Lambat

Tahap akhir adalah pengunduhan volume besar dari SharePoint Online dan OneDrive for Business, sebagian merambah konten email di Exchange Online melalui akses REST API. Dua detail operasional patut dicatat tim SOC:

1. User agent python-httpx teramati menyertai pola akses dan unduhan bervolume tinggi. Microsoft mengingatkan bahwa user agent ini sendiri bukan indikator jahat — ia harus dievaluasi bersama volume data, identitas terdampak, infrastruktur sumber, dan bukti kompromi identitas sebelumnya.
2. Laju yang terukur. Eksfiltrasi berlangsung dari beberapa jam hingga beberapa hari, umumnya dengan kurang dari 1.000 berkas atau email per jam — cukup lambat untuk berbaur dengan pemakaian kantor yang wajar, sehingga ambang deteksi berbasis lonjakan mendadak akan terlewat.

Aktor juga merotasi infrastruktur sepanjang siklus serangan, memakai alamat IP yang berbeda untuk autentikasi, pengintaian, dan eksfiltrasi. Konsekuensinya: deteksi yang hanya bersandar pada pemblokiran IP akan melihat tiga insiden kecil yang tampak tak berhubungan, bukan satu intrusi utuh.

Contoh Kueri Perburuan

Berikut dua kueri KQL dari publikasi Microsoft yang dapat dijalankan di Advanced Hunting. Pertama, deteksi penambahan metode autentikasi baru — inti persistensi:

Kedua, deteksi pengunduhan bervolume tinggi dari SharePoint Online dan OneDrive yang disertai user agent otomatis:

Ambang angka pada kueri di atas adalah titik awal, bukan kebenaran mutlak. Setiap organisasi perlu mengalibrasinya terhadap garis dasar pemakaian sendiri agar tidak tenggelam dalam false positive.

Pengerasan yang Direkomendasikan

Rekomendasi Microsoft bermuara pada satu prinsip: perlakukan pendaftaran informasi keamanan sebagai operasi berprivilese, bukan sebagai swalayan pengguna.

1. Terapkan MFA tahan phishing (FIDO2/passkey, Windows Hello for Business) melalui Conditional Access.
2. Perketat kebijakan pendaftaran security info: wajibkan autentikasi interaktif baru setiap kali, batasi ke perangkat terkelola dan/atau lokasi bernama, tetapkan authentication strength yang tahan phishing, serta blokir pendaftaran saat risiko login terdeteksi tinggi.
3. Blokir alur device code dan authentication transfer lewat Conditional Access, kecuali ada kebutuhan bisnis yang eksplisit.
4. Wajibkan perangkat terkelola dan patuh untuk mengakses Exchange, SharePoint, dan aplikasi berprivilese Graph. Batasi perangkat tak terkelola ke sesi web saja, tanpa unduh dan tanpa sinkronisasi.
5. Batasi user consent aplikasi, wajibkan persetujuan admin, dan tinjau berkala service principal yang memegang izin Graph berdampak besar seperti Mail.Read, Files.Read.All, dan Directory.Read.All.
6. Aktifkan Microsoft Graph activity logs dan audit mailbox, lalu bangun alert untuk enumerasi anomali, pendaftaran metode autentikasi, dan akses berkas bervolume tinggi.
7. Verifikasi identitas pengguna melalui proses yang ketat sebelum help desk melakukan reset kredensial atau MFA — dan bunyikan alert pada setiap reset semacam itu.
8. Saat menangani insiden, cabut sesi aktif dan refresh token, reset kredensial, hapus metode autentikasi yang didaftarkan penyerang, hapus aturan mailbox yang disisipkan, lalu wajibkan pendaftaran ulang metode autentikasi secara aman.

Konteks Indonesia

Bagi organisasi di Indonesia, kasus ini bersinggungan langsung dengan kewajiban hukum. Pasal 46 UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi mewajibkan pengendali data pribadi menyampaikan pemberitahuan tertulis kepada subjek data dan lembaga berwenang paling lambat 3x24 jam sejak diketahuinya kegagalan pelindungan data pribadi. Skenario eksfiltrasi lambat seperti di atas menciptakan persoalan praktis yang tidak sepele: jika unduhan berlangsung berhari-hari di bawah ambang deteksi, kapan sebenarnya jam pertama dari 3x24 jam itu mulai berdetak, dan bukti apa yang Anda miliki untuk menentukannya?

Jawabannya terletak pada kualitas log. Tanpa Graph activity logs dan audit mailbox yang aktif dan tersimpan cukup lama, tim forensik tidak akan bisa membuktikan ruang lingkup data yang keluar — dan organisasi terpaksa memberi notifikasi dengan asumsi terburuk. Bagi sektor yang diawasi ketat seperti jasa keuangan, ekspektasi ketahanan siber dan pelaporan insiden dari regulator menambah lapisan urgensi tersendiri.

Satu rambu etika dan hukum perlu ditegaskan. Indikator, domain, dan kueri di atas ditujukan untuk pertahanan: pemantauan, perburuan ancaman, dan respons insiden pada infrastruktur yang menjadi tanggung jawab Anda. Melakukan simulasi vishing atau phishing terhadap karyawan hanya sah bila ada mandat tertulis dari manajemen, ruang lingkup yang jelas, dan penanganan data peserta yang sesuai UU PDP. Mengakses sistem atau akun tanpa hak tetap merupakan perbuatan yang diancam pidana berdasarkan UU ITE.

Penutup

Kampanye ini menyampaikan satu pelajaran yang kontra-intuitif: memasang MFA yang kuat tidak ada artinya bila proses pendaftaran MFA itu sendiri lemah. Penyerang tidak perlu memecahkan kriptografi passkey; cukup meyakinkan seorang karyawan, lewat telepon ke nomor pribadinya, bahwa ia harus mendaftarkan ulang faktor keduanya sekarang juga.

Karena itu pertanyaan audit yang paling berguna hari ini bukan "berapa persen karyawan kami sudah pakai MFA", melainkan tiga pertanyaan lain: siapa yang boleh menambahkan metode autentikasi baru, dari perangkat seperti apa, dan apakah setiap penambahan itu menghasilkan alert yang benar-benar dibaca seseorang. Ditambah satu lagi — apakah tim Anda mampu melihat rangkaian panggilan Microsoft Graph sebagai satu cerita utuh, bukan sebagai ribuan permintaan API yang masing-masing tampak wajar.