Apakah mungkin untuk sepenuhnya mempertahankan diri dari serangan cyber? Mungkin, Anda bisa, jika Anda mengelilingi diri Anda dengan semua alat perlindungan yang ada dan merekrut tim ahli yang sangat besar untuk mengelola prosesnya. Namun, jelas bahwa dalam kenyataannya ini tidak mungkin: anggaran untuk keamanan informasi tidak terbatas, dan insiden akan tetap terjadi. Dan karena itu akan terjadi, maka Anda perlu bersiap untuk mereka!
Dalam artikel ini, kami akan berbagi skenario khas untuk menyelidiki insiden malware, memberi tahu kami apa yang harus dicari dalam log, dan memberikan rekomendasi teknis tentang cara mengkonfigurasi alat perlindungan informasi untuk meningkatkan peluang keberhasilan investigasi.
Proses klasik untuk
merespons insiden yang terkait dengan malware melibatkan tahapan seperti deteksi, penahanan, pemulihan, dll. Namun, semua kemampuan Anda, pada kenyataannya, ditentukan pada tahap persiapan. Misalnya, tingkat deteksi infeksi secara langsung tergantung pada seberapa baik audit dikonfigurasikan di perusahaan.
Siklus Respons Insiden SANS Klasik
Secara umum, tindakan analis selama penyelidikan adalah sebagai berikut:
- Generasi versi yang menjelaskan penyebab insiden (misalnya, "malware dipasang pada host karena pengguna meluncurkannya dari email phising" atau "insiden tersebut adalah alarm palsu karena pengguna mengunjungi situs yang sah yang terletak di hosting yang sama dengan server manajemen) malware ").
- Memprioritaskan versi berdasarkan tingkat kemungkinan. Probabilitas dihitung (tetapi lebih berpura-pura) berdasarkan statistik insiden masa lalu, kekritisan kejadian atau sistem, dan juga berdasarkan pengalaman pribadi.
- Pelajari setiap versi, cari fakta yang membuktikan atau tidak membuktikannya.
Tentu saja, tidak ada gunanya menguji semua hipotesis yang mungkin - setidaknya karena waktu terbatas. Oleh karena itu, di sini kita akan melihat versi yang paling mungkin dan skenario khas untuk menyelidiki insiden malware.
Skenario 1
Anda mencurigai bahwa sistem yang tidak kritis telah dikompromikan oleh malware. Karena sifat sistem yang tidak kritis, sedikit waktu telah dialokasikan untuk verifikasi.
Hal pertama yang dilakukan sebagian besar insinyur respons adalah menjalankan pemeriksaan antivirus. Namun, seperti yang kita ketahui, antivirus tidak begitu sulit untuk disiasati. Oleh karena itu, layak untuk menghasilkan dan mengerjakan versi yang sangat memungkinkan berikut: malware adalah file atau layanan yang dapat dieksekusi terpisah.
Sebagai bagian dari pengembangan versi ini, ada tiga langkah sederhana untuk diikuti:
- Saring log Keamanan berdasarkan peristiwa 4688 - jadi kami mendapatkan daftar semua proses yang dimulai.
- Saring log Sistem berdasarkan peristiwa 7045 - jadi kami mendapatkan daftar instalasi semua layanan.
- Identifikasi proses dan layanan baru yang sebelumnya tidak ada dalam sistem. Salin modul ini dan menganalisisnya untuk kode jahat (pindai dengan beberapa antivirus, periksa validitas tanda tangan digital, dekompilasi kode, dll.).
Daftar semua proses dan layanan yang berjalan di Event Log Explorer
Secara teori, ini adalah proses yang cukup sepele. Namun, dalam praktiknya ada sejumlah jebakan yang harus disiapkan.
Pertama, pengaturan audit Windows standar tidak mencatat fakta proses peluncuran (peristiwa 4688), sehingga harus diaktifkan terlebih dahulu dalam kebijakan grup domain. Jika kebetulan audit ini tidak dimasukkan sebelumnya, Anda dapat mencoba untuk mendapatkan daftar file yang dapat dieksekusi dari artefak Windows lainnya, misalnya, dari registri
Amcache . Anda dapat
mengekstrak data dari file registri ini menggunakan utilitas
AmcaheParser .
Contoh mengekstraksi fakta proses mulai dari Amcache.hve
Namun, metode ini tidak terlalu dapat diandalkan, karena tidak memberikan informasi yang akurat tentang kapan tepatnya dan berapa kali proses dimulai.
Kedua, bukti peluncuran proses seperti
cmd.exe, powershell.exe, wscript.exe dan interpreter lain akan sedikit berguna tanpa informasi tentang baris perintah yang dengannya proses dimulai, karena ini berisi jalur ke file skrip yang berpotensi berbahaya.
Menjalankan penerjemah skrip tanpa informasi tentang skrip apa yang diluncurkan
Fitur lain Windows adalah bahwa audit baris perintah dari proses yang diluncurkan dilakukan dengan secara terpisah mengkonfigurasi kebijakan grup domain:
Konfigurasi Komputer -> Kebijakan -> Template Administratif -> Sistem -> Penciptaan Proses Audit -> Sertakan baris perintah dalam acara pembuatan proses . Pada saat yang sama, Windows 7/2008 yang agak populer tidak mencatat baris perintah tanpa pembaruan
KB3004375 diinstal , jadi taruh terlebih dahulu.
Jika kebetulan Anda tidak mengonfigurasi apa pun sebelumnya atau lupa tentang pembaruan, Anda dapat mencoba mengetahui lokasi skrip di file
Prefetch (
utilitas untuk membantu ). Mereka berisi informasi tentang semua file (terutama DLL) yang dimuat ke dalam proses dalam 10 detik pertama kehidupan. Dan skrip yang terdapat pada argumen command line dari interpreter tentu akan hadir di sana.
Contoh menemukan argumen baris perintah "hilang" di Prefetch
Tetapi metode ini sama sekali tidak dapat diandalkan - saat Anda memulai proses berikutnya, cache Prefetch akan ditimpa.
Persiapan untuk investigasi:
- Termasuk audit lanjutan tentang penciptaan dan penyelesaian proses.
- Aktifkan pencatatan argumen baris perintah proses.
- Instal pembaruan KB3004375 pada Windows 7 / Server 2008.
Skenario 2
Akses ke server manajemen malware dicatat pada router perimeter. Alamat IP server jahat diperoleh dari langganan intelijen ancaman keamanan menengah.
Dalam
salah satu artikel kami sebelumnya, kami mengatakan bahwa analis TI berdosa dengan menambahkan ke daftar indikator kompromi alamat IP server yang meng-host pusat kontrol malware dan situs web yang sah pada saat yang sama. Jika Anda baru saja mulai merumuskan proses tanggapan, maka pada tahap pertama lebih baik untuk mengabaikan penggunaan indikator tersebut, karena setiap upaya oleh pengguna untuk memasuki situs web yang sah akan terlihat seperti insiden penuh.
Salah satu opsi untuk menanggapi alarm semacam itu dapat dikurangi untuk memeriksa proses mana yang membuat koneksi - jika itu adalah browser Internet, maka tanpa adanya fakta lain yang mengindikasikan kompromi, insiden tersebut dapat dianggap sebagai alarm palsu.
Ada banyak cara untuk mengetahui proses mana yang memulai koneksi: Anda dapat menjalankan
netstat dan melihat soket saat ini atau mengumpulkan dump memori dan kemudian mengatur
volatilitas di atasnya, yang juga dapat menunjukkan koneksi yang sudah selesai. Tetapi semua ini panjang, tidak dapat diskalakan dan yang paling penting - tidak dapat diandalkan. Jauh lebih andal untuk mendapatkan semua informasi yang diperlukan dari log keamanan Windows.
Korelasi peristiwa "akses ke alamat IP jahat" dalam sistem SIEM HPE Arcsight dan proses yang sesuai dalam log keamanan Windows
Persiapan Investigasi
Untuk mengatasi skenario ini pada mesin pengguna, Anda harus mengaktifkan pencatatan semua koneksi jaringan ke log keamanan. Ini dapat dilakukan berdasarkan peristiwa
audit platform penyaringan dan
audit penurunan paket .
Pada saat yang sama, majalah dapat mulai dengan cepat tersumbat, jadi tambah ukurannya menjadi 2-3 GB. Dalam pengalaman kami, pada host pengguna biasa, jumlah ini cukup untuk sekitar 3 hari untuk merekam semua soket, dan periode ini cukup untuk investigasi yang berhasil.
Pada server yang sangat dimuat, seperti pengontrol domain, server web, dll., Anda tidak boleh melakukan ini, log akan meluap lebih cepat.
Skenario 3
Sistem deteksi anomali NG / ML / Anti-APT Anda melaporkan bahwa 30 host sedang mencari akun yang sama.
Ketika mereka memasuki jaringan baru, penyerang biasanya mencoba mencari tahu layanan apa yang ada di dalamnya dan akun apa yang digunakan - ini banyak membantu dalam proses pergerakan lebih lanjut di sepanjang infrastruktur. Secara khusus, informasi ini dapat diperoleh dari Active Directory itu sendiri menggunakan perintah
net user / domain .
Jika potensi intelijen dilakukan dari satu host, dapat diselidiki, termasuk menggunakan log proses yang sedang berjalan. Namun, jika ada banyak host, dan serangannya dari jenis yang sama (terjadi pada waktu yang sama, atau set entitas yang sama diminta dari AD), maka masuk akal pertama-tama untuk mengecualikan tipikal false positive. Untuk melakukan ini, buat dan verifikasi versi berikut:
- Intelijen diperbaiki pada 30 host untuk objek AD yang sama karena pengguna yang sah, administrator, meluncurkan perintah net .
- Intelijen diperbaiki pada 30 host untuk objek AD yang sama, karena itu membuat perangkat lunak yang sama sah.
Analisis statistik log akan membantu menemukan titik-titik nodal ini (pengguna atau proses umum). Kami mendemonstrasikan metode ini dalam artikel sebelumnya sebagaimana diterapkan pada
log server DNS . Namun, metode investigasi yang efektif tidak dapat digunakan jika penyimpanan data tidak diatur sebelumnya.
Persiapan Investigasi
Penting untuk mengatur penyimpanan jangka panjang setidaknya dari data berikut dari log layanan jaringan umum:
- Pengontrol domain - input, output akun dan mengeluarkan tiket Kerberos (kategori Account Logon dalam pengaturan audit lanjutan).
- Proxy - alamat, port sumber dan server eksternal, serta URL lengkap.
- Server DNS - kueri DNS yang berhasil dan tidak berhasil serta sumbernya dalam jaringan.
- Perimeter router - Dibangun dan Teardown untuk semua koneksi TCP / UDP, serta koneksi yang mencoba untuk melanggar aturan akses logis: misalnya, upaya untuk mengirim permintaan DNS ke luar secara langsung, melewati server DNS perusahaan.
Skenario 4
Domain Anda telah disusupi, dan Anda khawatir penyerang bisa mendapatkan pijakan dalam infrastruktur menggunakan teknik DCShadow.
Misalkan hal buruk terjadi: Anda menemukan bahwa akun administrator domain telah disusupi.
Menanggapi insiden tersebut termasuk lapisan pekerjaan yang sangat besar, termasuk analisis dari semua tindakan yang dilakukan dari bawah akun ini. Bagian dari penyelidikan ini dapat dilakukan hanya dengan menggunakan pengontrol log domain. Misalnya, Anda dapat mempelajari acara yang terkait dengan penerbitan tiket Kerberos untuk memahami dari mana mereka pergi berdasarkan akun ini. Atau Anda dapat menganalisis peristiwa yang terkait dengan perubahan objek AD kritis untuk memeriksa apakah komposisi grup yang sangat istimewa (administrator domain yang sama) telah berubah. Secara alami, semua ini memerlukan audit pra-konfigurasi.
Namun, ada masalah bahwa penyerang dengan hak administrator domain dapat memodifikasi objek AD menggunakan teknik DCShadow, yang didasarkan pada mekanisme replikasi antara pengontrol domain.
Esensinya adalah bahwa penyerang itu sendiri tampaknya menjadi pengontrol domain, membuat perubahan pada AD dan kemudian mereplikasi (menyinkronkan) perubahan ini dengan pengontrol yang sah, sehingga melewati audit perubahan objek yang dikonfigurasi pada mereka. Hasil dari serangan seperti itu dapat menambahkan pengguna ke sekelompok administrator domain atau ikatan lebih rumit dengan mengubah atribut
SID History atau dengan memodifikasi objek ACL
AdminSDHolder .
Untuk memeriksa versi tentang adanya perubahan yang tidak dikomit dalam AD, Anda perlu mempelajari log replikasi dari pengontrol: jika alamat IP selain pengontrol domain terlibat dalam replikasi, Anda dapat dengan yakin mengatakan bahwa serangan itu berhasil.
Menghapus pengontrol domain yang tidak dikenal dari replikasi ADPersiapan untuk investigasi:- Untuk menyelidiki tindakan yang dilakukan oleh akun yang disusupi, Anda harus memasukkan di muka:
- Mengaudit input dan output akun dan mengeluarkan tiket Kerberos (kategori Logon Akun dalam pengaturan audit lanjutan).
- Perubahan audit pada akun dan grup (kategori Manajemen Akun ).
- Untuk menyelidiki versi yang terkait dengan kemungkinan serangan DCShadow:
- Aktifkan audit verbose replikasi layanan direktori .
- Atur penyimpanan jangka panjang dari peristiwa 4928/4929, di mana sumber acara bukanlah pengendali domain yang sah (atribut DCShadow).
Kesimpulan
Dalam artikel ini, kami berbicara tentang beberapa skenario khas untuk menyelidiki insiden keamanan informasi dan langkah-langkah untuk persiapan pencegahannya. Jika Anda tertarik pada topik ini dan Anda siap untuk melangkah lebih jauh, saya sarankan Anda memperhatikan
dokumen ini , yang menjelaskan di mana peristiwa Windows Anda dapat menemukan jejak penggunaan teknik peretasan populer.
Saya ingin mengakhiri dengan kutipan dari sebuah studi baru-baru ini dari perusahaan cybersecurity:
“Sebagian besar, direksi keamanan informasi Rusia cenderung memberikan jawaban pesimistis [untuk pertanyaan penelitian]. Dengan demikian, setengah (48%) percaya bahwa anggaran tidak akan berubah dengan cara apa pun, dan 15% berpikir bahwa pendanaan akan berkurang. "
Bagi saya pribadi, ini adalah sinyal bahwa sisa anggaran di tahun baru lebih baik dihabiskan bukan untuk membeli SZI baru seperti detektor Machine Learning, IDS generasi berikutnya, dll., Tetapi untuk memperbaiki SZI yang sudah ada. Dan SZI terbaik adalah Windows log yang dikonfigurasi dengan benar. IMHO.