Studi kasus — Bagian 1

pengantar

Kami sangat tertarik dengan respons insiden di cloud, oleh karena itu kami memutuskan untuk membagikan sebagian pengetahuan kami berdasarkan kasus IR baru-baru ini di AWS. Seri blog 3 bagian ini ditulis oleh Cado Security dan Invictus Incident Response .

Latar belakang

Insiden ditemukan selama audit akun di lingkungan Amazon klien. Akun pengguna super baru ditemukan dan tidak ada yang mengenalinya yang memicu insiden. Di blog ini, kami akan menelusuri insiden tersebut menggunakan cloud native logging dan memanfaatkan platform Cado Response untuk penyelidikan kami.

Pertanyaan investigasi

• Kapan akun dibuat?
• Bagaimana akun dibuat?
• Tindakan apa yang dilakukan dengan akun tersebut?
• Apakah ada jejak aktivitas mencurigakan lainnya?

Kami akan mengikuti langkah-langkah standar panduan penanganan insiden komputer sebagai penyegaran ada empat langkah:

1. Persiapan
2. Akuisisi
3. Pemrosesan & Analisis
4. Kegiatan Pasca Insiden

Akuisisi
Untuk akuisisi data log, kami menggunakan skrip sumber terbuka Invictus-AWS ( GitHub ). Invictus-AWS dapat dijalankan di organisasi AWS atau akun AWS untuk secara otomatis menghitung konfigurasi AWS yang digunakan dan logging yang diaktifkan. Skrip juga akan menarik semua logging yang tersedia dalam organisasi/akun AWS. Skrip ini dijalankan dan keranjang S3 dibuat berisi semua log yang tersedia yang terlihat seperti ini:

Pemrosesan
Seperti yang dapat kita lihat pada gambar di atas, ada CloudTrail logging default, tetapi juga logging tambahan seperti log aliran VPC dan logging audit S3. Untuk memulai penyelidikan, pertama-tama kami akan memproses log CloudTrail untuk dianalisis. Untuk analisis, kami menggunakan kombinasi alat baris perintah jq ( GitHub ) dan Splunk ( Situs Web ).

Dengan jq kami tidak perlu mengurai data, Anda dapat langsung menanyakan data json. Misalnya untuk membuka log CloudTrail dan hanya melihat EventTime dan EventName kita dapat menggunakan kueri berikut:

jq . cloudtrail.json

JQ juga dapat melakukan pemfilteran dan pencarian lanjutan, sangat cepat, namun bahasa kueri bisa sedikit menantang dan membaca informasi dari konsol tidak selalu termudah untuk dianalisis. Jadi mari beralih ke memuat log di Splunk, kita akan menggunakan jq untuk memanipulasi data kita untuk memastikan Splunk memahaminya.

Langkah 1 — Ekstrak bidang peristiwa CloudTrail

Pada langkah pertama kita akan mengekstrak field CloudTrailEvent dari file Cloudtrail.json. Bidang ini berisi seluruh acara dalam format json.

cat cloudtrail.json| jq -r '.Events[].CloudTrailEvent' > cloudtrailevents.json

Langkah 2 — Muat acara di Splunk

Untuk memuat file json di Splunk, setel sourcetype ke cloudtrail_json dan pastikan untuk menambahkan di bawah ini di file props.conf( reference ) Anda untuk mengurai peristiwa CloudTrail.

### props.conf ###
[cloudtrail_json]
DATETIME_CONFIG =
INDEXED_EXTRACTIONS = json
KV_MODE = tidak ada
LINE_BREAKER = ([\r\n]+)
NO_BINARY_CHECK = true
TIMESTAMP_FIELDS = eventTime
dinonaktifkan = false
pulldown_type = true

Setelah Anda memuat data Anda, itu akan terlihat seperti ini:

Analisis
Di awal keterlibatan respons insiden, sering kali ada indikator atau fakta yang diketahui di mana Anda dapat memulai penyelidikan. Dalam hal ini adalah akun yang tidak dikenal DevOps3 . Ingat kita harus menjawab pertanyaan-pertanyaan berikut:

1. Kapan dan bagaimana akun dibuat?
2. Tindakan apa yang dilakukan dengan akun tersebut?
3. Apakah ada jejak aktivitas mencurigakan lainnya?

Jadi mari kita lihat apakah kita dapat menentukan lebih lanjut tentang akun itu dan pembuatannya di log CloudTrail. Kami hanya akan mencari nama akun dan mengurutkan acara terlama terlebih dahulu untuk melihat apa yang pertama kali disebutkan akun ini.

Acara pertama yang kami temukan terkait dengan pengguna adalah acara CreateUser yang diharapkan untuk acara pertama untuk akun baru. Entri log di CloudTrail ini berisi banyak informasi untuk respons insiden kami.

pencarian yang digunakan: index=name_of_index DevOps3 |table eventTime,eventName,requestParameters.userName,sourceIPAddress,sessionCredentialFromConsole,userIdentity.arn

Kita dapat melihat nama akun pengguna yang baru dibuat di requestParameters.userName dan userIdentity.arn yang meminta pembuatan akun ini. Bidang sessionCredentialFromConsole disetel ke true artinya akun ini dibuat dari konsol manajemen AWS ( referensi ). Kami juga dapat melihat akun pengguna DevOps1-bpvpb dan kunci akses terkait yang membuat akun ini. Setelah pencarian awal kami, kami dapat menjawab dua pertanyaan investigasi pertama:

Kapan akun dibuat?
Waktu Pembuatan: 26–10–2022 pukul 21:29:03
(semua waktu di CloudTrail dalam UTC)

Bagaimana akun dibuat?
Dibuat oleh: DevOps1-bpvbp
Metode pembuatan: konsol manajemen AWS

Mari gali lebih dalam tentang akun yang membuat akun tersebut. Karena pembuatan akun dilakukan melalui konsol manajemen, log tidak menampilkan alamat IP eksternal yang digunakan untuk tindakan ini. Tapi kami tahu aktivitas itu terjadi dari konsol manajemen. Di AWS kami dapat memfilter secara khusus pada login konsol manajemen. Jika kami memfilter eventName=ConsoleLogin ( reference ) dengan akun DevOps1-bpvpb, kami melihat peristiwa berikut 6 menit sebelum pembuatan akun baru:

pencarian yang digunakan: index=name_of_index eventName=ConsoleLogin DevOps1-bpvbp

Bidang yang paling relevan telah digarisbawahi, kita dapat melihat bahwa pengguna ini tidak mengaktifkan MFA. Kami juga dapat melihat alamat IP sumber dari mana pengguna masuk di konsol. Sekarang kami memiliki gambaran yang lebih jelas tentang apa yang telah terjadi:

Waktu Pembuatan: 26–10–2022 pukul 21:29:03
Dibuat oleh: DevOps1-bpvbp
Metode pembuatan: AWS management console
Alamat IP yang digunakan: 185.195.232.111

Tindakan apa yang dilakukan dengan akun tersebut?

Sekarang kami dapat mencoba menentukan aktivitas apa yang terjadi dengan akun yang baru dibuat. Untuk mengetahui aktivitas apa yang terjadi dalam lingkungan AWS, kami dapat mencari akun pengguna dan membuat tabel nama kejadian yang dihasilkan di CloudTrail untuk akun ini.

pencarian yang digunakan: index=name_of_index devops3 |stats dihitung berdasarkan eventName

Hanya ada satu peristiwa yang terkait dengan akun itu, yaitu pembuatannya. Pada titik ini kami dapat menjawab pertanyaan investigasi ketiga. Pada titik ini menebak apa niat pelaku ancaman untuk akun yang baru dibuat, salah satu opsinya adalah menggunakannya sebagai metode persistensi.

Tindakan apa yang dilakukan dengan akun tersebut?
Tidak ada tindakan yang dilakukan dengan akun DevOps3

Apakah ada jejak aktivitas mencurigakan lainnya?

Sekarang mari beralih ke analisis aktivitas DevOps1-bpvbp, akun yang membuat DevOps3 untuk menentukan apakah ada aktivitas mencurigakan tambahan yang menggunakan akun ini.

Langkah pertama adalah mencari aktivitas untuk akun tersebut di sekitar periode waktu serangan:

pencarian yang digunakan: index=name_of_index DevOps1-bpvbp |table _time, eventSource,eventName,userIdentity.arn

Jadi dalam menit yang sama saat akun pengguna DevOps3 dibuat, acara StartSession( referensi ) direkam dengan akun yang sama.

StartSession, memulai koneksi ke target (misalnya, node terkelola) untuk sesi Manajer Sesi. Mengembalikan URL dan token yang dapat digunakan untuk membuka koneksi WebSocket untuk mengirim input dan menerima output.

Saat kami memeriksa acara, kami dapat melihat detail tambahan tentang apa yang terjadi:

Berdasarkan peristiwa tersebut, kami dapat menyimpulkan bahwa sesi dimulai dari akun DevOps1-bpvbp menuju instance dengan pengenal i-08e56d6b6c0439daf. Lagi-lagi aktivitas ini terjadi dari dalam konsol manajemen, oleh karena itu kami tidak dapat menggunakan alamat IP sumber untuk menemukan peristiwa ini. Pada titik ini dalam penyelidikan kami, kami akan menyelidiki apa yang terjadi pada contoh spesifik tersebut untuk menentukan apakah ini adalah aktivitas berbahaya. Kami tidak dapat lagi mengandalkan log CloudTrail saja karena tidak mencatat semua aktivitas yang terjadi dari dalam host.

Segera hadir… bagian 2, di mana kami akan mulai menginvestigasi instans dengan platform Cado Security.

PS: ID akun AWS dan alamat IP sumber diubah untuk tangkapan layar di blog ini.

Tentang Keamanan Cado

Cado Security adalah perusahaan otomatisasi respons dan investigasi cloud. Platform Cado memanfaatkan skala, kecepatan, dan otomatisasi cloud untuk menghadirkan detail tingkat forensik dengan mudah ke dalam lingkungan cloud, kontainer, dan tanpa server.

Tentang Invictus Incident Response

Kami adalah perusahaan tanggap insiden yang berspesialisasi dalam mendukung organisasi yang menghadapi serangan dunia maya. Kami membantu klien kami tetap tak terkalahkan!

Dukungan Incident Response hubungi [email protected] atau kunjungihttps://www.invictus-ir.com/247

Pertanyaan atau saran hubungi kami di [email protected]