Kami di JSOC CERT sedang menyelidiki insiden. Secara umum, semua 170 orang di JSOC sedang menyelidiki, tetapi kasus yang paling menantang secara teknologi jatuh ke tangan para ahli CERT. Bagaimana, misalnya, untuk mendeteksi jejak malware jika penyerang membersihkan? Bagaimana menemukan "penyihir" yang menghapus dokumen bisnis penting dari server file yang loggingnya tidak dikonfigurasi dengan benar? Ya, untuk pencuci mulut: bagaimana penyerang bisa mendapatkan kata sandi dari lusinan akun domain yang tidak terkait tanpa menembus jaringan? Detail, seperti biasa, di bawah potongan.
CERT JSOC Hari Kerja
Seringkali kita harus mengevaluasi kompromi aktual dari jaringan pelanggan, untuk ini kita melaksanakan:
- analisis retrospektif dari hard drive dan gambar memori,
- rekayasa balik malware
- jika perlu, penyebaran darurat pemantauan dan pemindaian host untuk indikator kompromi dan jejak peretasan.
Di waktu senggang kami, kami menulis ringkasan terperinci, teknik, dan buku pedoman - intinya instruksi yang membantu meningkatkan penyelidikan yang kompleks, seperti Anda dapat menindakinya secara semi-otomatis.
Kadang-kadang selama respons insiden - tepat di tengah memadamkan "api" - Anda juga harus bertindak sebagai "layanan dukungan psikologis". Suatu kali kami diundang untuk membantu menangkal infeksi subnet organisasi besar. Jaringan itu dilayani oleh dua kontraktor yang, dalam situasi ini, tanpa pamrih
melemparkan diri mereka pada kipas dan terlibat dalam hal lain
satu sama lain , tetapi tidak mencari cacing berbahaya. Untuk mengurangi tingkat histeria, saya harus duduk semua orang di meja
untuk mengambil handuk dan sebotol bourbon dan dengan jelas menjelaskan bahwa sekarang bukan saatnya untuk mencari yang bersalah. Mereka menentukan prosedur distribusi, meluncurkan audit tambahan dan mulai secara sistematis membersihkan infeksi bersama dan bersama.
Selama penyelidikan, kita sering harus mengambil gambar disk dan memori untuk menemukan malware aktif di sana. Untuk membuat proses dapat diprediksi dan obyektif, kami meresmikan dan mengotomatisasi beberapa metode untuk analisis disk retrospektif, dan mengambil metode
SANS yang sudah klasik sebagai dasar - dalam versi asli itu adalah level yang cukup tinggi, tetapi jika digunakan dengan benar memungkinkan deteksi infeksi aktif dengan akurasi sangat tinggi.
Jelas bahwa untuk melakukan semua-semua pemeriksaan memerlukan waktu dan pengetahuan ahli yang mendalam tentang fitur-fitur berbagai komponen sistem operasi (dan perangkat lunak khusus membutuhkan banyak hal).
Bagaimana cara menyederhanakan memeriksa disk untuk infeksi aktif? Kami berbagi hack kehidupan - itu dapat diperiksa secara dinamis (seperti di kotak pasir), untuk ini:
- salin hard drive host mencurigakan sedikit demi sedikit;
- mengkonversi gambar dd-dihasilkan ke format VMDK menggunakan utilitas ini ;
- jalankan gambar VMDK di Virtual Box / VMware;
- dan menganalisis seperti sistem yang hidup, berfokus pada lalu lintas.
Tetapi akan selalu ada insiden di mana instruksi rinci tidak ditulis dan tekniknya tidak otomatis.Kasus 1. Akuntan tidak ada hubungannya dengan itu, atau bagaimana kami mencari malware
Klien meminta kami memeriksa perangkat lunak jahat komputer akuntan: seseorang melakukan beberapa pesanan pembayaran ke alamat yang tidak dikenal. Akuntan mengklaim bahwa dia tidak terlibat dalam hal ini dan bahwa komputer telah berperilaku aneh sebelumnya: mouse kadang-kadang bergerak di sekitar layar itu sendiri - pada kenyataannya, kami diminta untuk memeriksa indikasi ini. Tangkapannya adalah bahwa Trojan yang ditujukan pada 1C melakukan trik kotornya dan membereskannya, dan setelah infeksi hampir sebulan berlalu - selama ini rajin enikeyschik memasang banyak perangkat lunak, menggosok ruang disk yang tidak terisi dan dengan demikian meminimalkan kemungkinan keberhasilan dalam penyelidikan.
Dalam kasus seperti itu, hanya seorang analis yang berpengalaman, teliti, dan luas, yang bisa diperbarui secara otomatis. Jadi, selama pemindaian folder startup, perhatian ditarik oleh tag yang mencurigakan yang menunjukkan utilitas pembaruan anti-virus yang diduga:
Sayangnya, bangkai Trojan dari disk tidak dapat dipulihkan, tetapi fakta meluncurkan utilitas administrasi jarak jauh dari folder yang sama "dipamerkan" di cache
Superfetch :
Membandingkan mereka dengan waktu kejadian, kami membuktikan bahwa bukan akuntan yang bersalah mencuri uang, tetapi seorang penyerang eksternal.
Kasus 2. Siapa yang menghapus file saya?
Sebagian besar investigasi dan respons insiden kami entah bagaimana terkait dengan deteksi malware, serangan bertarget menggunakan utilitas multi-modul, dan cerita serupa di mana ada penyerang eksternal. Namun, terkadang ada jauh lebih biasa, tetapi investigasi yang tidak kalah menarik.
Klien memiliki file server lama yang paling biasa, folder publik yang dapat diakses oleh beberapa departemen. Di server terdapat banyak dokumen bisnis yang sangat penting yang diambil dan dihapus seseorang. Kami menyadarinya terlambat - setelah cadangan kelebihan beban. Mereka mulai mencari yang bersalah.
Jika Anda pernah mencoba google cara menentukan pengguna mana yang menghapus file, maka Anda mungkin menemukan tips yang semuanya masuk dalam log Windows, jika Anda mengonfigurasinya dengan benar sebelumnya (ngomong-ngomong, kami sudah memberikan
beberapa tips tentang cara konfigurasikan log):
SumberNamun pada kenyataannya, beberapa orang melakukan audit sistem file, klise karena ada banyak operasi file dan log akan cepat usang, dan server terpisah diperlukan untuk menyimpan log ...
Kami memutuskan untuk membagi tugas menjadi dua: pertama, tentukan KAPAN file dihapus; kedua, - WHO terhubung ke server pada saat penghapusan. Jika Anda memiliki gagasan tentang fitur-fitur NTFS, maka Anda tahu bahwa di sebagian besar implementasi sistem file ini, ketika Anda menghapus file, ruang yang ditempati ditandai sebagai bebas, dan stempel waktunya tidak berubah. Oleh karena itu, pada pandangan pertama, waktu penghapusan tidak dapat diatur.
Namun, sistem file tidak hanya berisi file, tetapi juga folder. Selain itu, folder memiliki atribut khusus $ INDEX_ROOT, yang menggambarkan konten folder sebagai B-tree. Secara alami, menghapus file akan mengubah atribut $ INDEX_ROOT folder dan karenanya mengubah stempel waktu, khususnya, dalam struktur $ STD_INFO. Dengan demikian, adalah mungkin untuk menentukan perkiraan waktu untuk menghapus sejumlah besar file dan folder dengan anomali di
MFT (tabel file utama) :
Setelah mengetahui kapan file-file itu kira-kira dihapus, Anda dapat mencoba mencari tahu siapa yang bekerja di utara pada saat itu untuk mempersempit lingkaran tersangka. Metode berikut muncul dalam pikiran:
- Dengan log server itu sendiri - oleh peristiwa dengan EventID 4624/4625 itu terlihat ketika pengguna terhubung dan terputus;
- oleh log pengontrol domain - EventID 4768 memungkinkan Anda untuk menentukan bahwa pengguna tertentu telah meminta akses ke server;
- oleh traffic - netflow / log router internal - Anda dapat mengetahui siapa yang secara aktif berkomunikasi melalui jaringan dengan server ini melalui seseorang
Dalam kasus kami, data ini sudah tidak ada lagi: terlalu banyak waktu berlalu, log diputar. Dalam hal ini, ada satu lagi yang tidak terlalu dapat diandalkan, tetapi masih sebuah metode, atau lebih tepatnya kunci registri -
Shellbags . Ia menyimpan informasi, khususnya, tentang jenis folder apa terakhir kali pengguna mengunjunginya: tabel, daftar, ikon besar, ikon kecil, konten, dll. Dan kunci yang sama berisi stempel waktu, yang dapat diartikan dengan keyakinan tinggi sebagai waktu kunjungan terakhir ke folder.
Sebuah metode ditemukan, satu-satunya yang tersisa adalah mengumpulkan pendaftar dari host yang diperlukan dan menganalisisnya. Untuk melakukan ini, Anda perlu:
- tentukan oleh grup domain yang memiliki akses ke folder (dalam kasus kami, ada sekitar 300 pengguna);
- kumpulkan pendaftar dari semua host tempat pengguna ini bekerja (Anda tidak bisa melakukan ini, Anda memerlukan utilitas khusus untuk bekerja dengan drive secara langsung, misalnya, https://github.com/jschicht/RawCopy );
- “Beri makan” semua pendaftar dalam Autopsi dan gunakan plugin Shellbags;
- Untung!
Khususnya, dalam insiden ini, waktu untuk menghapus file bertepatan dengan waktu pengguna mengunjungi root folder yang dihapus, yang memungkinkan kami untuk mempersempit lingkaran tersangka dari 300 menjadi 1.
Apa yang terjadi selanjutnya dengan karyawan ini - ceritanya diam. Kita hanya tahu bahwa gadis itu mengaku bahwa dia melakukannya secara tidak sengaja, dan terus bekerja di perusahaan.
Kasus 3. Master kata sandi: “mencuri” dalam beberapa detik (dan bahkan lebih cepat)
Seorang penyerang memasuki jaringan klien yang meminta kami untuk membantu melalui VPN dan segera terdeteksi. Yang tidak mengejutkan, karena setelah masuk, ia mulai memindai subnet dengan pemindai kerentanan - chanipot berkedip seperti pohon Natal.
Setelah akun dikunci, staf keamanan klien mulai mengurai log VPN dan melihat bahwa penyerang telah menggunakan lebih dari 20 akun domain yang berbeda untuk penetrasi (dengan sebagian besar ia berhasil login, tetapi untuk beberapa otentikasi gagal). Dan pertanyaan logis muncul: bagaimana dia mengetahui kata sandi dari akun ini? Teman-teman kami dari JSOC CERT diundang untuk mencari jawabannya.
Dalam salah satu
artikel sebelumnya, kami telah mengatakan bahwa dalam penyelidikan hipotesis harus dibentuk dan diverifikasi ketika probabilitasnya menurun. Jadi kami melakukannya kali ini, mulai menggambarkan vektor pencurian akun khas:
Kami memeriksa banyak versi, tetapi tidak ada sedikit pun serangan. Bukan berarti investigasi berada di jalan buntu, tetapi suara hati dan akal sehat menyarankan bahwa ada sesuatu yang salah - Anda harus mengambil langkah mundur dan melihat gambar yang lebih luas.
Memang, pada pandangan pertama, semua akun ini sama sekali tidak terhubung. Pemiliknya berasal dari berbagai departemen yang terpisah secara geografis. Biasanya mereka menggunakan serangkaian layanan perusahaan yang tidak tumpang tindih. Bahkan tingkat melek IT berbeda. Ya, satu langkah mundur tidak cukup - satu lagi diperlukan.
Pada saat ini, kami berhasil mengumpulkan sejumlah besar log dari berbagai sistem perusahaan dan mengidentifikasi jejak yang ditinggalkan oleh penyerang. Mereka mulai menganalisis di mana itu muncul (saya ingat: dia secara aktif memindai jaringan internal perusahaan). Kami memperhatikan bahwa dengan latar belakang kebisingan jaringan yang terdistribusi secara merata dari eksploitasi terbang, ada sejumlah besar permintaan abnormal ke layanan pemulihan kata sandi. Layanan yang dapat diakses dari Internet. Hmm ...
Jika Anda memantau peristiwa keamanan, maka Anda mungkin tahu bahwa menganalisis upaya untuk menyerang server yang dapat diakses secara eksternal sering kali tidak masuk akal karena kebisingan Internet: membedakan serangan yang benar-benar serius dari berbagai upaya script-kiddie pada umumnya tidak mudah. Tapi tidak selalu.
Setelah menghabiskan beberapa waktu untuk log layanan web, kami dapat memilih serangan berikut pada layanan:
- Pindai dengan Acunetix
- Pemindaian SQLmap
- sejumlah besar permintaan ke satu halaman.
Serangan ketiga, sekilas, mirip dengan login pengguna yang brutal. Tapi ini tidak benar, karena layanan dilindungi dari ini, setidaknya oleh fakta bahwa kata sandi disimpan dalam bentuk hash dengan garam - atau tidak? Itu perlu untuk cepat memeriksanya.
Gambar di bawah ini menunjukkan skema khas layanan reset kata sandi:
Sangat menarik di dalamnya bahwa kata sandi tidak selalu disimpan dalam bentuk yang aman - ada saat ketika mereka berada di domain publik - segera setelah aplikasi dibuka dan sebelum pelaksanaannya! Sejumlah besar permintaan untuk satu halaman ternyata bukan menjadi kekerasan dan bukan pemindaian, tetapi untuk permintaan frekuensi tinggi dengan injeksi SQL, yang tujuannya adalah untuk mengekstrak kata sandi pada saat perubahan mereka.
Jadi, setelah memodelkan serangan pada layanan, membandingkan informasi dari log server web, log perubahan kata sandi, dan beberapa perangkat jaringan, kami masih menemukan titik penetrasi penyerang di perusahaan.
Jadi, kolega, selidiki data mentah dan mungkin kekuatannya bersama Anda!
