Agen AI ARTEX Curi Secret GitHub dalam Lima Menit

Secret yang pernah ter-commit ke repositori GitHub publik sekarang bisa ditemukan dan dipakai oleh agen AI dalam hitungan menit. Microsoft Threat Intelligence melaporkan pada 5 November 2026 bahwa pelaku ancaman memakai ARTEX, kerangka serangan ofensif berbasis agen AI, untuk memburu kredensial aplikasi dan API key layanan AI di GitHub, lalu langsung memakainya untuk masuk ke lingkungan cloud korban.

Kenapa ini penting: selama ini banyak tim menganggap secret yang terlanjur ter-push masih "aman sebentar" karena butuh waktu sampai ada orang yang menemukannya. Laporan Microsoft menunjukkan jeda itu nyaris hilang. Dalam satu kasus yang diamati, agen bergerak dari pencarian client secret di GitHub sampai mengeluarkan data dari Azure Key Vault dalam lima menit.

Apa yang dilaporkan Microsoft?

Menurut blog keamanan Microsoft, sejak Agustus 2026 mereka melihat pelaku memakai kerangka agen AI untuk mengirim kueri dalam jumlah besar ke GitHub. Kuerinya biasanya menggabungkan nama organisasi sasaran, kata kunci yang berkaitan dengan secret, serta kata kunci layanan cloud atau penyedia AI.

Sejak 28 Oktober 2026, Microsoft mulai melihat sign-in service principal yang berhasil memakai kredensial aplikasi hasil curian di banyak aplikasi dan beberapa tenant. Yang dipakai adalah secret aplikasi, bukan password pengguna. Akibatnya tidak ada login manusia dan tidak ada notifikasi MFA yang bisa memancing kecurigaan.

Angka lima menit perlu dibaca dengan tepat. Microsoft menyebutnya sebagai satu kasus yang teramati, bukan waktu rata-rata semua serangan. Tetap saja, angka itu cukup untuk menunjukkan bahwa jadwal rotasi bulanan tidak bisa lagi diandalkan untuk menutup kebocoran yang baru terjadi.

Microsoft tidak menyebut siapa pelaku di balik pemindaian GitHub ini. Cybersecurity Dive mencatat bahwa ARTEX sebelumnya juga pernah dipakai kelompok yang dilacak Microsoft sebagai Storm-0940. ARTEX juga disebut dalam kasus agen AI yang lolos dari sandbox di WorkOS, dengan konteks yang berbeda.

Apa saja yang dicari dan dilakukan agen?

Berikut ringkasan perilaku yang dicatat Microsoft per 5 November 2026:

Poin terakhir menarik. Agen tidak berhenti saat menemui error. Ia membaca respons yang gagal, mengubah permintaannya, dan mencoba ulang sampai berhasil. Pola seperti ini dulu butuh operator manusia yang sabar, sekarang dikerjakan otomatis.

Microsoft juga mencatat bahwa agen berulang kali fokus pada kredensial layanan AI, termasuk API key penyedia AI besar. Artinya API key model AI yang tertinggal di repositori bukan hanya risiko tagihan membengkak, tapi juga pintu ke sumber daya cloud lain.

Kenapa menghapus commit tidak cukup?

Banyak developer yang sadar telah mem-push secret langsung menghapus file itu atau menulis ulang riwayat Git. Langkah ini tidak menyelesaikan masalah. Microsoft menulis bahwa kredensial yang pernah terekspos ke publik tetap bisa dipakai sampai dicabut atau dirotasi, walaupun lokasi aslinya sudah diubah.

Ada satu jebakan lagi. Menghapus client secret tidak otomatis mematikan token yang sudah terlanjur diterbitkan. Token itu tetap berlaku sampai masa berlakunya habis. Untuk aplikasi bernilai tinggi, Microsoft menyarankan menonaktifkan service principal bila perlu.

Catatan riset Cloud Security Alliance menyimpulkan hal serupa: rotasi terjadwal (misalnya tiap 30 sampai 90 hari) masih berguna untuk membersihkan kredensial lama, tapi tidak bisa menahan secret baru yang ditemukan dan dipakai dalam hitungan menit. Yang dibutuhkan adalah pencabutan yang dipicu oleh kejadian, begitu kebocoran terdeteksi.

Apa yang perlu dilakukan tim kamu sekarang?

Rekomendasi berikut diringkas dari panduan Microsoft. Sebagian khusus Azure, tapi prinsipnya berlaku untuk cloud dan layanan apa pun.

• Anggap secret publik sudah dicuri. Begitu ada secret yang pernah tampil di repositori publik, cabut atau rotasi saat itu juga, lalu periksa riwayat pemakaiannya.
• Rotasi isi vault yang bisa dibaca aplikasi terdampak. Jika aplikasi yang bocor punya akses ke Key Vault, semua isi vault itu ikut dianggap terekspos dan perlu diganti.
• Pindai kode sebelum dan sesudah push. Aktifkan GitHub secret scanning beserta push protection, atau alat pemindai lain, supaya secret tertahan sebelum sampai ke publik.
• Kurangi pemakaian secret statis. Pakai managed identity atau kredensial federasi berumur pendek di tempat yang memungkinkan, sehingga tidak ada secret yang bisa bocor.
• Batasi izin service principal. Terapkan prinsip hak akses minimum dan tinjau ulang peran yang diberikan.
• Pantau log yang tepat. Periksa log sign-in service principal dan non-interaktif, log diagnostik Key Vault, dan log audit lain sejauh masa simpan memungkinkan.
• Cari pola, bukan hanya IP. Microsoft menyarankan waspada bila satu alamat masuk ke tiga service principal atau lebih, atau satu aplikasi meminta token untuk banyak layanan dalam waktu singkat. Rangkaian gagal lalu berhasil dianggap mendesak.

Untuk tim kecil yang belum memakai Azure, pelajaran praktisnya sama. Simpan secret di luar kode, pastikan file .env tidak ikut ter-commit, dan siapkan prosedur rotasi yang bisa dijalankan dalam hitungan menit. Panduan mencegah bocornya file .env dan API key membahas langkah dasarnya, dan kasus Railway yang meminta pengguna merotasi semua env var menunjukkan betapa repotnya rotasi bila tidak disiapkan dari awal.