Hacker Eksploitasi Akses AWS Qubole, Data Pelanggan Dicuri

Peretas membobol akun AWS milik sejumlah pelanggan Qubole antara 14 dan 26 Oktober 2026, mencuri kredensial tersimpan dan data. Serangan memanfaatkan kredensial akun AWS yang dipakai platform Qubole untuk mengakses pelanggan, menurut laporan Wiz.

Wiz, perusahaan keamanan cloud, mengungkap insiden ini pada Senin (9/11/2026). Hingga berita ini ditulis, Qubole dan Idera—induk usaha platform data lake itu—belum merilis pernyataan resmi di situs mereka.

Kronologi Serangan dan Modus AssumeRole

Qubole beroperasi di dalam akun AWS pelanggan. Untuk masuk, pelanggan membuat IAM role—identitas AWS dengan izin tertentu. Kebijakan kepercayaan (trust policy) role mengizinkan akun AWS Qubole mengambil alih role tersebut.

Setiap permintaan pengambilalihan, yang disebut AssumeRole, harus menyertakan kode dari Qubole bernama External ID. Dalam insiden ini, permintaan AssumeRole dari penyerang selalu membawa External ID yang benar sehingga diterima AWS.

“Setiap permintaan AssumeRole yang terkait penyerang membawa External ID dan diterima,” kata peneliti Wiz dalam analisis teknis mereka.

Menurut panduan AWS, External ID bukan rahasia dan dapat dilihat siapa pun yang memiliki akses ke role. Inilah celah yang dimanfaatkan.

Sentra mendeteksi aktivitas mencurigakan di beberapa lingkungan pelanggan dan memberi tahu Wiz. Peneliti kemudian menelusuri jejak di CloudTrail dan menemukan pola serangan.

Sebagian besar role yang diambil alih penyerang sebenarnya tidak lagi digunakan. Namun, karena trust policy masih mempercayai akun Qubole, permintaan tetap berhasil.

Pihak yang Terlibat dan Pernyataan Mereka

Wiz menjadi pihak pertama yang mempublikasikan temuan ini. Perusahaan keamanan cloud itu menyoroti bahwa penyerang memanfaatkan kelemahan pada mekanisme kepercayaan role, bukan mencuri kredensial pengguna secara langsung.

“Kami melihat aktivitas ini di beberapa pelanggan dan segera memberi tahu peneliti,” ujar Sentra dalam keterangan yang dikutip Wiz.

Qubole, yang dimiliki Idera, belum memberikan komentar. The Hacker News melaporkan bahwa hingga pengecekan terakhir, tidak ada pernyataan di situs Qubole maupun Idera.

Wiz juga tidak menyebut apakah kredensial yang dipakai penyerang sudah dinonaktifkan atau apakah aktivitas masih berlangsung.

Yang jelas, penyerang menggunakan akun AWS Qubole dengan ID 805246085872. Mereka juga memakai IAM principal ID AIDA3W7DIFLYOLTK63SFS dan AIDAJYRRH5Y3A7AAJM2HW.

Alamat IP yang terdeteksi berasal dari OVH (57.129.54[.]120 dan 2001:41d0:70d[:]7800::) serta VPN Mullvad (45.83.220[.]211, 185.209.199[.]73, dan 89.37.63[.]175).

Latar Belakang: Mengapa Role Qubole Rentan

Integrasi Qubole dengan AWS memang memerlukan akses luas. Pelanggan biasanya memberikan izin role untuk membaca S3, mengakses Secrets Manager, SSM Parameter Store, dan variabel lingkungan Lambda.

“Setup Qubole menyertakan contoh kebijakan S3 yang memungkinkan role membaca setiap bucket di akun,” tulis Wiz dalam laporannya.

Kemudahan itu mempermudah operasional, tetapi memperbesar dampak jika kredensial jatuh ke tangan yang salah. Penyerang tidak perlu menebak-nebak; mereka cukup menjelajah semua yang bisa diakses role.

Selain jalur AssumeRole, Qubole juga memungkinkan pelanggan terhubung menggunakan AWS access key. Antara 8 dan 11 Oktober, penyerang memakai access key milik pelanggan yang diduga disiapkan untuk Qubole.

Penyerang itu berhasil mengompromikan beberapa lingkungan cloud korban. Namun, Wiz belum menghubungkan aktivitas tersebut dengan penyalahgunaan AssumeRole.

Menariknya, Wiz menilai pola penargetan tidak cocok dengan kelompok yang didukung negara. Mereka juga tidak mengaitkan kampanye ini dengan aktivitas lain yang sudah dilaporkan publik.

Dampak dan Data yang Dicuri

Di akun yang diperiksa peneliti, penyerang mencari kredensial tersimpan. Mereka membaca variabel lingkungan fungsi Lambda, menarik rahasia dari Secrets Manager, dan membaca nilai dari SSM Parameter Store.

Kredensial yang ditemukan kemudian diuji dengan TruffleHog—alat untuk memverifikasi apakah kredensial masih berlaku. Yang diuji antara lain access key AWS milik korban, client secret Entra ID, dan kredensial klien Okta.

Penyerang juga menyalin data dari S3. Mereka mengambil data dari bucket apa pun yang bisa diakses role, bukan mencari data spesifik. Dalam beberapa kasus, seluruh bucket diunduh dalam satu sesi.

“Mereka mengambil data dari setiap bucket yang dapat diakses role, dan terkadang mengunduh seluruh bucket dalam satu sesi,” kata peneliti.

Kerusakan bisa lebih luas karena banyak korban tidak memiliki log yang memadai. CloudTrail mencatat permintaan AssumeRole dan daftar bucket, tetapi tidak mencatat objek S3 mana yang dibaca.

Untuk itu diperlukan S3 data events atau server access logs. Beberapa korban tidak mengaktifkannya, sehingga tim respons tidak bisa memastikan objek mana yang telah diakses penyerang.

Langkah Pemeriksaan dan Mitigasi

Wiz merilis panduan perburuan (hunting) bagi organisasi yang pernah menghubungkan Qubole ke AWS. Pemeriksaan harus mencakup CloudTrail sejak 1 Oktober 2026 di setiap akun yang memiliki role Qubole.

Beberapa tanda yang perlu dicari:

• Permintaan AssumeRole dengan userIdentity.accountId 805246085872 dan sourceIPAddress di luar alamat AWS.
• Aktivitas dari IAM principal ID AIDA3W7DIFLYOLTK63SFS, yang hanya dipakai penyerang di akun yang diperiksa.
• IAM principal ID AIDAJYRRH5Y3A7AAJM2HW jika berasal dari luar AWS (role ini juga dipakai lalu lintas normal Qubole).
• Alamat IP OVH dan Mullvad VPN yang disebutkan di atas.
• Nama sesi role yang diawali quiam-, seperti quiam-enum.
• User agent TruffleHog pada panggilan GetCallerIdentity dari IP tersebut.

Untuk setiap sesi mencurigakan, tinjau semua tindakan setelahnya, terutama di Secrets Manager, SSM Parameter Store, Lambda, dan S3.

Langkah penutupan celah:

• Jika role Qubole Anda diambil alih, putar semua rahasia, parameter, dan variabel lingkungan Lambda yang dapat diakses role, serta cabut sesi aktif role. Rotasi kredensial tidak mengakhiri sesi yang sudah terlanjur dibuat.
• Hapus role Qubole yang tidak lagi diperlukan, atau keluarkan akun Qubole dari trust policy.
• Jika didukung, ganti principal :root di trust policy dengan principal IAM spesifik yang dipakai Qubole.
• Tambahkan kondisi aws:SourceIp atau aws:SourceVpce untuk membatasi permintaan AssumeRole ke rentang jaringan resmi vendor.
• Jangan mengandalkan External ID sebagai satu-satunya kontrol. External ID tercatat dalam teks biasa di CloudTrail dan sering tersimpan di file infrastructure-as-code.
• Tinjau izin role vendor. Batasi akses ke Lambda, Secrets Manager, SSM, dan S3 sesuai kebutuhan.
• Pasang alarm untuk permintaan AssumeRole dari akun vendor yang datang melalui VPN atau penyedia hosting yang belum pernah dipakai vendor.
• Aktifkan organization trail untuk semua akun dan region, serta S3 data events atau server access logs untuk bucket sensitif.

Wiz menegaskan bahwa kondisi source IP saja sebenarnya sudah cukup untuk memblokir seluruh pengambilalihan role yang mereka amati. “Kondisi source IP saja akan memblokir setiap asumsi role yang kami amati,” kata peneliti.

Analisis Redaksi

Insiden ini menunjukkan bahwa model kepercayaan di cloud bisa menjadi pedang bermata dua. Integrasi pihak ketiga seperti Qubole memang memudahkan pengelolaan data, tetapi juga memperluas permukaan serangan. Ketika kredensial vendor bocor, seluruh pelanggan yang masih mempercayai akun itu ikut terpapar.

Yang paling mengganggu adalah kenyataan bahwa banyak role yang diambil alih sebenarnya sudah tidak digunakan. Artinya, organisasi sering lupa membersihkan akses yang sudah tidak perlu. Trust policy yang dibiarkan menumpuk menjadi pintu belakang yang terbuka lebar, bahkan ketika layanan sudah tidak aktif.

Pelajaran lain, External ID tidak boleh dianggap sebagai pengaman utama. AWS sendiri menyebutnya bukan rahasia. Namun, praktik di lapangan sering memperlakukannya seperti kunci rahasia. Vendor dan tim keamanan perlu menambahkan kontrol berlapis, seperti pembatasan IP dan pemantauan anomali, agar satu kebocoran tidak berujung pada bencana.

Hingga kini, Qubole dan Idera belum angkat bicara. Pelanggan berhak mendapatkan transparansi: apakah kredensial sudah dicabut, apakah serangan masih berlangsung, dan langkah apa yang diambil untuk mencegah terulang. Tanpa itu, kepercayaan terhadap platform data lake ini bisa terkikis.

Sumber: thehackernews.com, aws.amazon.com