Hari 53: Kunci AWS Bocor, CloudTrail Menangkap Pencurinya

Hari ke-53 dari challenge 60 Days DevSecOps. Topiknya: red team lagi, tapi sekarang di level cloud — simulasi kunci akses AWS yang bocor. Saya buat user khusus, bocorkan kunci-nya, berpura-pura jadi penyerang yang memakainya, lalu menangkap jejaknya lewat CloudTrail dan mematikannya dengan skrip auto-revoke.

Hasilnya mengejutkan sekaligus bikin merinding: ternyata CloudTrail — alat yang seharusnya merekam semua aktivitas di AWS — belum pernah aktif sama sekali di akun ini. Mari saya ceritakan urutannya.

Skenarionya

Di dunia nyata, kebocoran kunci AWS adalah salah satu penyebab utama peretasan. Seringnya lewat commit tidak sengaja ke GitHub, file konfigurasi yang ikut ter-push, atau laptop yang kena malware. Begitu kunci bocor, penyerang bisa pakai akun Anda untuk apapun yang kunci itu izinkan.

Simulasinya begini:

1. Saya buat IAM user sementara bernama leaked-dev dengan akses baca S3.
2. Saya generate access key untuk user itu — inilah yang "bocor".
3. Saya berpura-pura jadi penyerang: pakai kunci itu untuk lihat daftar bucket dan mencuri file.
4. Saya lihat apakah ada yang merekam semua itu (CloudTrail).
5. Saya siapkan skrip untuk mematikan kunci dalam hitungan detik.

Plot Twist 1: CloudTrail Belum Pernah Aktif

Sebelum mensimulasikan penyerang, saya cek dulu: apakah CloudTrail jalan? Hasilnya kosong. Tidak ada trail sama sekali. Berarti selama ini, kalau ada yang masuk ke akun ini, tidak ada satu jejak pun yang tercatat.

Ini pelajaran penting buat pemula: CloudTrail itu semacam CCTV untuk akun AWS. Semua API call tercatat di sana — siapa, pakai kunci apa, dari mana, ngapain. Tapi CCTV-nya harus diaktifkan dulu. Kalau belum, Anda buta total.

Saya buat trail-nya:

aws cloudtrail create-trail \
  --name securebank-trail \
  --s3-bucket-name securebank-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

aws cloudtrail start-logging --name securebank-trail

Multi-region biar semua region tercatat, plus log file validation biar file log-nya tidak bisa diubah diam-diam.

Plot Twist 2: Canary yang Gagal, Lalu Pivot

Ide awal saya pakai layanan CanaryTokens — tinggal generate token, taruh di file, dan begitu file dibuka, kita dapat email. Ternyata tidak bisa di-automasi. Layanannya berbentuk aplikasi web, semua permintaan otomatis ditolak.

Solusinya saya bikin sendiri: bucket S3 khusus berisi file "sensitif" palsu. Di dalamnya ada marker string CanaryToken-.... Logikanya sederhana: file ini palsu dan tidak pernah disentuh siapapun. Kalau ada yang membacanya, pasti orang asing.

aws s3api create-bucket --bucket securebank-honeypot-canary
# backup/db-config.txt — konfigurasi DB palsu
# env/.env.production  — file env palsu berisi marker CanaryToken-...

Menangkap Penyerangnya

Dengan kunci leaked-dev, saya pakai profil terpisah di AWS CLI dan berpura-pura jadi penyerang:

1. Lihat daftar semua bucket akun.
2. Buka bucket honeypot.
3. Curi file env/.env.production — yang berisi marker canary.

Lalu pertanyaannya: apakah terekam? Jawabannya ya. CloudTrail mencatat dua API call atas nama kunci bocor itu: GetCallerIdentity (penyerang cek "aku siapa sih") dan ListBuckets (penyerang lihat-lihat target).

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<kunci> \
  --query 'Events[].[EventTime,EventName,EventSource]' --output table

Catatan teknis kecil: event "management" seperti ini muncul cepat (beberapa menit). Tapi event "data" seperti GetObject (saat file diunduh) butuh konfigurasi tambahan dan bisa lebih lambat. Untuk investigasi cepat, baca file log mentahnya langsung di bucket CloudTrail.

Plot Twist 3: Skrip Auto-Revoke Berhasil

Ini bagian yang paling memuaskan. Saya buat skrip revoke.sh dengan tiga langkah:

1. Tampilkan riwayat aktivitas kunci di CloudTrail (biar tahu seberapa parah).
2. Deactivate kunci — kunci mati dalam hitungan detik.
3. Attach kebijakan Deny-All ke user — jadi meskipun ada kunci lain milik user yang sama, tetap diblokir total.

Hasil ujinya? Setelah skrip jalan, saya coba pakai kunci yang "bocor" itu lagi:

An error occurred (InvalidAccessKeyId) when calling the ListBuckets operation

Kunci mati total. Penyerang terkunci di luar. Perasaan ini, seperti menutup pintu yang baru saja nyaris dibobol maling.

Lessons Learned

• CCTV harus dinyalakan dulu. CloudTrail luar biasa penting, tapi tidak berguna kalau belum aktif. Cek describe-trails di akun Anda sekarang.
• Canary tidak harus mahal. S3 honeypot dengan marker string cukup sebagai "sensor" bahwa file palsu diakses.
• Revoke harus instan dan berlapis. Matikan kunci dulu, lalu isolasi user dengan Deny-All. Deactivate saja tidak cukup kalau masih ada jalur lain.
• Lab cleanup itu hygiene. Semua artefak demo (user, kunci, bucket canary) dihapus habis. Yang sengaja dibiarkan hidup justru CloudTrail — itu jadi peningkatan keamanan permanen.

Kesimpulan

Hari ini terasa seperti latihan kebakaran yang berguna banget. Bukan hanya membuktikan bahwa CloudTrail menangkap jejak penyerang — tapi juga menemukan fakta mengejutkan bahwa akun ini selama ini buta. Satu perintah create-trail mengubah akun dari tidak terawasi menjadi penuh rekaman jejak.

Kode lengkapnya ada di repo: chalange-devsecops — lihat securebank-api/security/revoke.sh untuk skrip auto-revoke.

Besok: lanjut ke chaos security engineering — mematikan OPA Gatekeeper untuk menguji apakah lapisan keamanan lain tetap menangkap serangan.