Aplikasi pihak ketiga yang sudah diberi izin dapat mengakses Microsoft 365 tanpa pengguna masuk secara interaktif. Karena itu, ketika kredensial aplikasi pemasok disalahgunakan, pemeriksaan akun pengguna saja bisa melewatkan aktivitas penting. Laporan Microsoft tentang ARTEX dan ConnectWise Cloud Backup memberi alasan untuk meninjau aplikasi yang pernah diotorisasi, riwayat sign-in identitas aplikasinya, serta perubahan izin dan kredensial di setiap tenant yang relevan.
Ini bukan pernyataan bahwa semua pengguna ConnectWise atau Microsoft 365 telah disusupi. Microsoft menyebut keberadaan aplikasi terdampak, bahkan autentikasi yang berhasil, belum membuktikan data pelanggan diakses atau dieksfiltrasi. Baca penilaian Microsoft dan cocokkan dengan pembaruan ConnectWise sebelum mengambil keputusan di tenant sendiri.
Apa yang diketahui dari laporan ARTEX dan ConnectWise?
Microsoft menilai kelompok yang dilacak sebagai Storm-0940 memakai kerangka kerja ARTEX untuk mempercepat aktivitas serangan, termasuk penyalahgunaan identitas aplikasi ConnectWise yang telah dipercaya oleh tenant pelanggan. Dalam sejumlah lingkungan yang diamati Microsoft, aktivitas setelah autentikasi mencakup peninjauan lewat Microsoft Graph, perubahan kredensial aplikasi, dan upaya mengubah hak akses. Microsoft juga menegaskan aktivitas tersebut bukan akibat kerentanan atau kompromi sistem dan produk Microsoft. Ini adalah temuan peneliti Microsoft, bukan hasil investigasi myBATICloud atas tenant pelanggan.
ConnectWise menyatakan ada akses tidak sah ke kredensial aplikasi yang terkait dengan Cloud Backup, sebelumnya SkyKick. Menurut Trust Center ConnectWise (pembaruan 23 Oktober 2026, 14:00 UTC), pengujian dan validasi pemulihan masih berlangsung; pengembalian layanan secara bertahap bergantung pada hasilnya. Koneksi yang terdampak harus tetap dinonaktifkan sampai instruksi resmi untuk layanan terkait tersedia. ConnectWise mengatakan arsip backup yang ada tetap terenkripsi, terisolasi, dan dipertahankan, tanpa indikasi arsip tersebut dikompromikan. Pernyataan tentang arsip ini tidak menetapkan bahwa tenant Microsoft 365 tertentu aman; konfigurasi dan aktivitas pada masing-masing tenant tetap perlu diperiksa.
Mulai dari aplikasi yang benar, bukan hanya nama tampilannya
Admin Microsoft 365/Entra perlu memetakan tenant sendiri dan tenant pelanggan yang dikelola, termasuk integrasi lama yang mungkin tidak lagi dipakai. Bandingkan Application ID dengan daftar identitas aplikasi pada panduan teknis ConnectWise; nama tampilannya dapat berbeda pada instalasi lama SkyKick. Catat pula Object ID service principal lokal, status aplikasi, izin yang diberikan, pemilik, dan waktu pemeriksaan. Application ID mengidentifikasi aplikasi dari vendor; Object ID menunjukkan instans identitas aplikasi di tenant yang sedang diperiksa.
Jika aplikasi yang tercantum masih diaktifkan, ikuti petunjuk vendor melalui admin yang berwenang dan verifikasi hasil perubahan. Jangan menghapus enterprise application sebagai langkah pertama. Konfigurasi, izin, dan jejak autentikasi masih diperlukan untuk menyelidiki apakah ada akses lain yang bertahan. Tim yang mengelola banyak tenant sebaiknya mencatat siapa yang bertanggung jawab meninjau tiap tenant; pemeriksaan tenant MSP sendiri tidak menggantikan pemeriksaan tenant pelanggan.
Urutkan bukti sebelum menyimpulkan dampak
Mulailah dari service-principal sign-ins: pisahkan percobaan yang gagal dari autentikasi berhasil, lalu bandingkan sumber IP, waktu, resource tujuan, dan pola biasanya. Identitas aplikasi bisa masuk menggunakan sertifikat atau rahasia aplikasi tanpa sign-in pengguna, sehingga MFA pengguna tidak menjawab seluruh pertanyaan investigasi. Laporan sign-in Entra juga dapat mengelompokkan beberapa kejadian dalam satu baris; buka rinciannya sebelum menyimpulkan jumlah atau urutan aktivitas.
Berikutnya, periksa audit Entra untuk penambahan kredensial, pemilik, persetujuan izin, penetapan peran, dan perubahan aplikasi lain yang tidak cocok dengan change record. Korelasikan dengan aktivitas Microsoft Graph dan Microsoft Purview Audit yang memang sudah tersedia: perubahan direktori, pembacaan mailbox atau file, unduhan, forwarding, dan akses resource setelah autentikasi. Panduan respons aplikasi Microsoft menyarankan pemeriksaan pola sign-in, resource tujuan, perubahan kredensial, konfigurasi, serta role aplikasi. Ketiadaan hasil dari satu sumber log tidak otomatis membuktikan tidak ada akses; catat rentang waktu, lisensi, dan telemetry yang benar-benar tersedia.
Panduan ConnectWise meminta pemeriksaan sejak 13 Oktober 2026 hingga waktu investigasi dan perluasan ke awal Oktober bila catatan masih tersedia. Simpan waktu dalam UTC agar hasil dari beberapa portal dapat dikorelasikan. Simpan ekspor audit/sign-in, metadata aplikasi, hasil pencarian, dan catatan perubahan administrasi yang sah. Jangan menunda pembatasan akses mendesak hanya demi menunggu ekspor yang belum selesai.
Keputusan yang berbeda untuk bukti yang berbeda
| Temuan | Langkah penanggung jawab | Bukti yang disimpan |
|---|---|---|
| ID aplikasi tidak ditemukan di tenant saat pemeriksaan | Admin tenant mencatat cakupan dan memeriksa riwayat otorisasi atau tenant lain yang dikelola. Jangan menyimpulkan semua tenant aman dari satu pencarian. | Tenant ID, daftar Application ID yang dicari, waktu, dan batas retensi data. |
| Aplikasi ditemukan, tanpa aktivitas mencurigakan pada catatan yang tersedia | Tim keamanan meninjau status koneksi, izin, pemilik, serta periode log yang tercakup. Ikuti status dan instruksi pemulihan ConnectWise yang terbaru. | Object ID lokal, konfigurasi, log sign-in dan audit, serta hasil pembandingan dengan aktivitas vendor yang diharapkan. |
| Sign-in tidak lazim atau perubahan kredensial/izin yang belum terjelaskan | Tim respons insiden mengorelasikan autentikasi dengan Graph, audit direktori, dan aktivitas data; hubungi pemilik integrasi dan lakukan containment yang diotorisasi. | Event, correlation ID, actor, waktu UTC, perubahan sebelum/sesudah, dan keputusan containment. |
| Perubahan tidak sah terkonfirmasi | Responder berwenang menghapus akses tidak sah setelah bukti dipertahankan, memverifikasi hak yang tersisa, dan menilai dampak pada pengguna serta proses backup/restore. | Jejak investigasi, persetujuan tindakan, hasil verifikasi, dan rencana pemulihan layanan. |
IP atau user agent yang disebut dalam laporan vendor adalah konteks untuk pencarian, bukan bukti tunggal. Admin sah bisa memakai alat scripting; sebaliknya, pencarian yang hanya memakai daftar IP publik bisa melewatkan aktivitas lain. Bedakan attempt, autentikasi berhasil, perubahan hak, dan akses data sebagai temuan yang berbeda.
Pemulihan akses perlu menjaga layanan backup
Jika koneksi Cloud Backup dibatasi, tim operasi perlu tahu apakah backup terjadwal, pemantauan job, dan rencana restore terkena dampak. Catat workload yang bergantung pada integrasi tersebut serta alternatif sementara yang benar-benar tersedia. Jangan menyambungkan ulang aplikasi hanya karena pemeriksaan awal tidak menemukan anomali: ConnectWise meminta koneksi terdampak tetap dinonaktifkan sampai instruksi restorasi formal berlaku untuk layanannya.
Setelah bukti terkumpul, pemilik tenant dan tim respons dapat memutuskan perubahan kredensial, pencabutan grant, atau pembersihan identitas yang terbukti tidak sah. Pemulihan kredensial vendor tidak otomatis menghapus kredensial, pemilik, dan peran tambahan di tenant pelanggan. Dokumentasikan siapa yang mengubah apa dan periksa kembali sign-in serta akses resource setelah tindakan. Bila aktivitas data yang tidak sah terkonfirmasi, gunakan prosedur insiden organisasi, bukan checklist artikel ini sebagai pengganti investigasi.
Pertanyaan yang sering muncul
Apakah setiap tenant Microsoft 365 pengguna ConnectWise terdampak?
Tidak bisa disimpulkan begitu. Pemeriksaan dimulai dari aplikasi dan riwayat otorisasi per tenant. ConnectWise meminta review tenant yang relevan, termasuk koneksi lama; hasil akhirnya bergantung pada konfigurasi serta bukti aktivitas di tenant tersebut.
Apakah sign-in service principal yang berhasil berarti data dicuri?
Tidak. Microsoft membedakan autentikasi dari aktivitas setelahnya dan menyatakan sign-in berhasil tidak selalu berarti data diakses atau dieksfiltrasi. Korelasikan dengan perubahan izin, panggilan Graph, dan log akses data yang tersedia sebelum menyimpulkan dampak.
Apakah MFA pengguna cukup untuk menutup risiko ini?
MFA tetap penting bagi identitas manusia. Namun, service principal dapat melakukan autentikasi sebagai aplikasi tanpa pengguna masuk secara interaktif. Pemeriksaan harus mencakup kredensial dan izin aplikasi serta aktivitasnya, bukan hanya log login karyawan.
Bolehkah aplikasi langsung dihapus lalu disambungkan kembali?
Jangan jadikan penghapusan sebagai respons pertama. Panduan ConnectWise meminta konfigurasi dan bukti dipertahankan; koneksi yang terdampak tetap dinonaktifkan sampai instruksi pemulihan resmi tersedia. Perubahan di tenant harus dilakukan admin yang berwenang bersama pemilik layanan dan tim keamanan.
Ruang lingkup pemeriksaan yang masuk akal
Untuk tim IT di Indonesia yang mengelola banyak tenant, keluaran awal yang berguna adalah inventaris ID aplikasi dan pemiliknya, cakupan log yang tersedia, serta daftar perubahan kredensial dan izin yang perlu ditelusuri. Artikel checklist OAuth app consent memberi konteks untuk governance izin aplikasi di luar insiden ini.
Jika diperlukan, diskusikan pemeriksaan keamanan identitas dan dukungan Managed IT bersama myBATICloud untuk merapikan cakupan tenant, prioritas bukti, serta tindak lanjut akses dan backup. Hasil yang dicari adalah daftar temuan yang bisa ditindaklanjuti, bukan jaminan bahwa tenant bebas kompromi.
Sumber
- Microsoft Security Research, laporan ARTEX dan ConnectWise (21 Oktober 2026).
- ConnectWise Trust Center, pembaruan Cloud Backup (cek instruksi terbaru).
- ConnectWise, panduan investigasi dan remediasi teknis Cloud Backup (18 Oktober 2026).
- Microsoft Learn, investigasi aplikasi yang dikompromikan atau berbahaya.
- Microsoft Learn, service-principal sign-in logs.