Artikel ini adalah angsuran ketiga dan terakhir dari seri Analisis Ancaman Sysmon. Semua bagian lain dari seri ini:
Bagian 1. Memperkenalkan Analisis Log Sysmon
Bagian 2. Menggunakan Data Peristiwa Sysmon untuk Mendeteksi Ancaman
Bagian 3. Analisis Ancaman Sysmon Tingkat Lanjut Menggunakan Grafik (kami di sini)
Menemukan Subgraf Non-Standar dengan Data Peristiwa Sysmon (Contoh Sederhana)
Sebelum kita melihat contoh mengidentifikasi anomali dalam subgraf yang menunjukkan potensi ancaman (dan jika kata-kata ini tidak menyadarkan Anda, maka tidak ada yang akan membangunkan Anda!), Mari buat sedikit penyimpangan.
Pada titik ini, saya harus mengeluarkan peringatan: postingan ini, bersama dengan kode di GitHub, tidak dapat menggantikan solusi tingkat perusahaan. Ini dapat membantu mengidentifikasi ancaman dalam skala yang lebih kecil, tetapi misi mulia saya adalah membantu profesional keamanan TI memahami dan menghargai solusi perlindungan ancaman dunia nyata. Dan salah satu cara untuk mencapai ini adalah dengan membuat solusi Anda sendiri (dengan bantuan saya).
Eksperimen di rumah akan membantu Anda memahami betapa sulitnya menskalakan perangkat lunak pendeteksi ancaman DIY. Anda harus bekerja dengan kumpulan data besar dan segala sesuatu yang terkait dengannya: pembersihan (yang merupakan tugas yang sangat sulit), pemrosesan yang efisien (menemukan struktur data yang diperlukan, algoritme, dll.) Dan memberikan hasil dengan jumlah positif palsu yang rendah sehingga Anda kolega yang sama kemudian tidak memanjat Anda dengan tinju mereka. Dengan pemikiran ini, Anda dapat mempertimbangkan siap- dibuat solusi untuk mendeteksi ancaman ... tetapi hanya setelah menyelesaikan seri artikel kami dan melakukan percobaan Anda sendiri.
Mengatur bobot grafik
Salah satu cara mudah untuk membangun solusi pertahanan ancaman yang tidak bergantung pada tanda tangan malware adalah dengan menggunakan grafik ancaman dari bagian sebelumnya .
Grafik seperti itu menghubungkan node proses berdasarkan entri dari event log Sysmon.
Harap dicatat: Saya tidak memisahkan setiap proses mulai acara (ID Peristiwa 1 di acara Sysmon) menjadi simpul terpisah. Sebagai gantinya, saya membuat grafik yang lebih abstrak yang menunjukkan, katakanlah, simpul PowerShell memiliki satu tautan ke aplikasi apa pun yang diluncurkannya dari bawah pengguna mana pun - satu tautan untuk Excel, satu untuk browser, dan seterusnya.
Tampilan pohon PSQuickGraph grafik ancaman Sysmon saya. Perhatikan cabang anomali di bawah cmd.exe
Namun, kami masih ingin melacak frekuensi proses yang berjalan. Misalnya, jika PowerShell meluncurkan "whoami" 1 kali dan editor Windows "Notepad.exe" yang kedaluwarsa 10 kali, maka tepi grafik yang berasal dari simpul PowerShell harus ditandai dengan "bobot" yang sesuai masing-masing 1 dan 10. Apakah itu logis?
Dalam banyak algoritme deteksi ancaman yang paling sederhana, bobot ini menjadi metrik untuk membandingkan wilayah grafik. Poin utamanya adalah bahwa subgraf dengan bobot rata-rata yang lebih rendah dibandingkan dengan bobot rata-rata keseluruhan adalah mencurigakan.
Bukankah begitu? Puncak yang jarang dikunjungi adalah zona anomali. Oleh karena itu, jika tindakan pengguna dalam analisis potensi ancaman mengarah ke subgraf yang jarang digunakan, Anda harus menaikkan level alarm menjadi kuning.
Pendekatan yang saya jelaskan dan skrip PowerShell di bawah ini tidak dimaksudkan untuk digunakan untuk tujuan praktis untuk infrastruktur besar. Tetapi untuk server terpisah, solusinya mungkin berfungsi, atau setidaknya memberikan verifikasi independen dari solusi perusahaan yang Anda gunakan.
Apakah saya menyebutkan bahwa algoritme PowerShell Doug Finke untuk struktur data adalah alat yang hebat dan canggih? Tanpa karyanya, saya tidak akan mencapai apa pun dalam proyek grafik anomali saya. Terima kasih sekali lagi, Doug!
Dengan menggunakan pustaka PowerShell berisi fungsi grafik yang indah, saya dapat dengan mudah menghitung bobot grafik ancaman Sysmon saya hanya dengan beberapa garis PS, dan juga mengetahui bobot simpul rata - rata untuk keseluruhan grafik. Saat melintasi grafik, kode juga memberikan bobot pada setiap simpul dari semua sisi keluarnya:
$AW=0 #average weight
$GW=0 #total weight
$mset = [System.Collections.ArrayList]@() #master set of subraphs
#calculate total weight by summing up the frequencies or weights of the edges
foreach ($e in $g.getAllEdges() ) {
$GW = $GW + $e.weight
}
write-host "Weight of Graph: " $GW
$AW = $GW / $g.vertices.count
write-host "Average weight per vertex: " $AW
#assign weight of edges to vertice
for ($i=0; $i -lt $g.vertices.count; $i++) {
$w=0
$v=$g.vertices[$i]
foreach($e in $v.getEdges()) {
if($e -eq $null) {continue}
$w=$w + $e.weight
}
$v.value.Weight = $w
}
Kode di atas melakukan perhitungan yang kita butuhkan. Dalam hal ini, setiap simpul dapat dianggap sebagai frekuensi kunjungan, bergantung pada tepi keluar.
Bagian tersulit dari PowerShell naskah grafik anomali saya - yang saya akan menunjukkan Anda segera - adalah menemukan daerah grafik yang paling mungkin terjadi, dan kemudian menemukan subgraph terbesar yang mengandung mereka. Anda mungkin perlu membolak-balik buku ilmu komputer lama untuk menyelesaikan tugas ini. Tapi sebenarnya tidak terlalu sulit untuk menulis!
Saya menggunakan Breadth First Search klasik untuk grafik saya dengan mengunjungi setiap simpul, dan kemudian mengembangkannya dengan mengorbankan simpul tetangga sampai subgraf saya mencapai ambang tertentu tergantung pada bobot rata-rata simpul. Seperti ini:
function extend-subgraph($v, $t) {
$vertexQueue = New-Object Queue
#initialize
$vertexQueue.enqueue($v)
$h=$v.value.Weight
$s=@() #subgraph
$s+=$v
$extend=$false
while (!$vertexQueue.isEmpty()) { #bfs
$currentVertex = $vertexQueue.dequeue()
$es= $currentVertex.getEdges()
foreach($e in $es) {
$ev= $e.endVertex
if ((($h + $ev.value.Weight)/($s.count+1) -lt $th) {
#extend the sub-graph
$s+=$ev
$h =$h + $ev.value.weight
#queue it up
$vertexQueue.enqueue($ev)
}
}
Sebuah catatan singkat untuk penggemar DIY: untuk membuat sebuah array dari array, menggunakan ArrayList jenis dan Anda akan menghemat banyak sakit kepala.
Ancaman dan subgraf ringan
Ada banyak algoritme berbeda untuk grafik anomali. Yang saya gunakan didasarkan pada graphBAD tertentu yang saya temukan di Internet - dan saya akan memberikan tautannya segera setelah saya menemukannya lagi.
Secara umum, masalah utama dalam deteksi ancaman praktis adalah menemukan dataset yang baik untuk membentuk baseline. Sebagai blogger penuh waktu dan spesialis pendeteksi ancaman pesta-waktu, saya tidak pernah berhasil membuat log Sysmon yang cukup menarik yang berisi banyak aplikasi berbeda. Cukup sulit untuk menghasilkan subgraf yang tidak wajar karena saya tidak memiliki penyebaran yang cukup besar dalam bobot. Dengan satu atau lain cara, saat menggunakan server nyata, Anda mungkin mendapatkan kumpulan data yang jauh lebih baik daripada penggunaan sesekali instans Windows AWS, seperti dalam kasus saya.
Skrip PS dari grafik anomali yang saya tulis cukup mampu menghasilkan subgraf yang mencurigakan dengan bobot rata-rata yang rendah. Dan saya bahkan berhasil menangkap beberapa lingkungan yang menarik (lihat di bawah).
Algoritma Bobot Subgraf Beraksi: Lingkungan Menarik dengan Bobot Rendah Subgraf 7
Seperti yang saya sebutkan sebelumnya, ada algoritme lain untuk mendeteksi anomali dalam grafik dengan metrik selain bobot sederhana yang layak dipelajari. Salah satunya mencari cluster dari simpul "serupa" dan pemberitahuan koneksi atau koneksi antara lingkungan yang berbeda. Dalam hal ini, anomali terletak pada pengguna atau proses yang menghubungkan lingkungan dengan menggunakan beberapa karakteristik lain. Masuk akal, bukan?
Jika inner nerd Anda kuat di dalam diri Anda, Anda dapat melihat SCAN(Structural Clustering Algorithm for Networks), yang melakukan hal di atas. Dengan algoritme PowerShell Doug Finke, Anda bahkan dapat menggunakannya. Saya sendiri ingin mengambil proyek ini dan segera memasangnya di GitHub saya .
Temukan anomali melalui jalan acak
Mari akhiri bagian ini dengan cara lain untuk menemukan anomali dalam grafik ancaman. Saya merujuk pada pendekatan ini di akhir bagian sebelumnya . Bagi saya, sebagai orang dengan matematika pada "Anda", dia lebih intuitif. Dan penggemar acara TV lama numb3rs akan segera mengenali konsep rantai Markov [membersihkan tenggorokan].
Untuk semua orang, Anda dapat menganggap ini sebagai "jalan acak" melalui grafik. Pada setiap simpul, kita melempar dadu dan memilih tepi grafik tergantung pada bobotnya: semakin besar bobot tepi, semakin tinggi kemungkinan kita mengikutinya. Anda perlu membagi grafik menjadi dua bagian - disebut grafik bipartit dalam teori grafik - dengan pengguna di satu bagian dan aplikasi di bagian lain.
Selanjutnya, peringkat Andasemua aplikasi titik sudut yang bisa dijangkau dari pengguna berdasarkan kemungkinan mencapai titik tertentu. Untuk menganalisis ancaman, Anda kemudian akan mencari aplikasi yang sedang berjalan, dan jika salah satu dari mereka memiliki kemungkinan yang sangat rendah untuk mencapainya, maka Anda mungkin telah menemukan ancaman nyata!
Ditambah karma untuk orang yang menautkannya ke algoritme PageRank Google. Saya akan menjelaskan ini secara lebih rinci di bagian selanjutnya, tetapi mereka yang tertarik dapat menggunakan Google frase random walk dengan restart .
Teori Traversal Acak dan Praktek EQL
Mari kita mengambil penyimpangan lain dan menganalisis apa yang ingin kita capai dengan log Sysmon, yang merupakan alat hebat untuk mendeteksi ancaman dan melakukan penyelidikan pasca-insiden.
- , Sysmon. Sysmon , .
- 2 Sysmon , , .
- Di bagian ketiga, kami mempelajari ikhtisar dari satu algoritma sederhana yang menganggap koneksi tepi sebagai bobot. Bagian dari grafik yang berbobot kurang (dalam hal tepi) daripada total bobot rata-rata di seluruh grafik dapat menjadi ancaman potensial. Saya akan mengunggah skrip PowerShell dari algoritme dari bagian ini ke GitHub saya (setelah mengarahkan kursor ke atasnya).
Keuntungan dari metode ini adalah bahwa mereka tidak tergantung pada spesifik perintah atau nama proses yang penyerang terus-menerus mengubah atau masker.
Selain itu, ada metode berbasis probabilitas lain untuk menemukan kerentanan. Mari kita lihat lebih dekat.
Traversal Tak Disengaja dari Grafik Kerentanan dari Data Berdasarkan Peristiwa Sysmon
Alih-alih menganalisis struktur grafik itu sendiri, kita dapat menganggap tautan sebagai jalur atau peta jalan, di mana setiap aplikasi merupakan perhentian terpisah di sepanjang jalan. Dari data log Sysmon, kita bisa mendapatkan frekuensi di mana setiap aplikasi dimulai dari induknya.
Jika Anda melihat skrip grafik ancaman saya di GitHub, Anda akan menemukan bahwa frekuensi ini disimpan dalam setiap objek tepi menggunakan algoritme PowerShell yang luar biasa dari Doug Finke.
Kita dapat menganggap frekuensi melintasi setiap tepi grafik kerentanan sebagai probabilitas!
Langkah selanjutnya adalah menggunakan informasi ini untuk menemukan kemungkinan, katakanlah, meluncurkan aplikasi PowerShell taskmgr.exe, penganalisis proses Windows, notepad, atau hostname.exe.
Apa yang saya maksud?
Singkatnya: Saya dapat membuat matriks transisi probabilitas, yang sangat disukai oleh pengikut Markovdan biasa digunakan dalam sistem pemodelan. Faktanya, melempar dadu, membuka aplikasi berikutnya dalam grafik, dan mengulangi tindakan ini merupakan penjelajahan acak dari grafik. Akhirnya, metode matematis ini memberi peringkat setiap titik pada grafik menurut kemungkinan untuk sampai ke sana dari titik awal. Dan Anda akan mengetahui bahwa, katakanlah, meluncurkan spreadsheet dari Windows Explorer adalah proses yang sangat umum, dan Windows Script Host Engine secara teori sangat tidak standar dan, karenanya, berpotensi menjadi indikator ancaman.
Metode ini dikenal sebagai Random Walk With Restart (selanjutnya - RWWR, random walk dengan restart) dan merupakan variasi dari algoritma peringkat Google PageRank yang sekarang legendaris .
Mari kita lihat skrip yang saya tulis untuk menghitung peringkat ini:
#lets build a row
$row= @(0)*$g.vertices.count
$w=0
foreach($e in $start.getEdges()) { #calculate total frequency
$w+=$e.weight
}
if ($w -eq 0) { #make it connected
$row[$ix] =1
}
else { #we assign probabilitys
#now create transition probability
foreach($e in $start.getEdges()) {
$ev = $e.endVertex
$p = $e.weight
$jx = v-index $ev.value.Key
$row[$jx]= $p/$w #normalize by dividing by total
}
}
$P[$ix] = $row #yay! One row added to transition matrix
Untuk setiap simpul, saya menghitung frekuensi yang dihasilkan dari semua tetangga dan kemudian menetapkan probabilitas setiap transisi melalui normalisasi dengan total. Jadi, jika PowerShell.exe memiliki 20 kunjungan ke semua tetangganya, tetapi nc.exe hanya dikunjungi sekali dari bagian atas PowerShell.exe, maka kemungkinan untuk pergi adalah 1/20 atau 0,05. Apakah itu logis?
Kesulitannya terletak pada penghitungan matriks yang digunakan di RWWR, tetapi bagi mereka yang mengikuti pelajaran pemodelan probabilistik, prosedur ini tidak akan sulit. Ada artikel review bagus tentang hal ini di situs Medium .
Skrip saya, yang saya sebut penilai acak , memberi peringkat dan keluaran 10 terkecilnilai dari daftar. Dengan cara ini, Anda bisa mendapatkan aplikasi yang memiliki probabilitas peluncuran terendah, mulai dari simpul tertentu dari grafik ancaman. Inilah hasil saat menggunakan PowerShell.exe sebagai titik awal:
Algoritme Random Walk With Restart dapat menghasilkan peringkat ancaman seperti google. Hmmm, whoami adalah yang paling kecil kemungkinannya untuk dijalankan.Sebagai
catatan dan peringatan praktis, perlu dicatat bahwa PWWR akan menjadi masalah big data di sistem nyata. Bahkan dalam kasus log Sysmon saya yang kecil, jeda perhitungan cukup terlihat karena banyaknya jumlah operasi floating point.
Event Query Language (EQL) untuk Analisis Ancaman
Untuk saat ini, perlu dicatat bahwa vendor yang menggunakan pendekatan yang lebih canggih untuk mendeteksi ancaman dalam produk mereka jauh melampaui apa yang Anda atau saya dapat lakukan sendiri. Dan, tentunya, dengan akurasi yang jauh lebih tinggi.
Bagi mereka yang ingin mendalami topik deteksi ancaman, tetapi tidak ingin bekerja dengan skrip saya - saya mengerti! - ada Event Query Language , atau EQL . Ini adalah proyek sumber terbuka untuk menerapkan Bahasa Kueri Log Sysmon, yang dapat Anda pelajari lebih lanjut di pos yang sangat komprehensif... EQL tidak hanya bagus untuk menyelidiki insiden, tetapi juga dapat digunakan sebagai alat selama Anda memiliki salinan log Sysmon terbaru.
Rangkaian EQL menyediakan penangan peristiwa yang mengubah log menjadi JSON yang dapat dibaca manusia. Anda dapat melihat salinan cabang saya di GitHub. Tidak seperti skrip PS show-ancaman-path statis saya , EQL memungkinkan Anda membuat kueri dengan cepat.
Katakanlah saya tertarik dengan semua shell cmd.exe yang diluncurkan atas nama scvhost.exe - ini mungkin merupakan tanda penggunaan psexec.exe atau smb.exe oleh penyerang. Permintaannya akan terlihat seperti ini:
Menggunakan EQL untuk menemukan shell cmd.exe yang diluncurkan dari svchost.exe. Ngomong-ngomong, jq adalah utilitas Linux untuk menampilkan data JSON.
Ada cara yang lebih keren dan lebih hebat untuk mendapatkan hasil ini dengan menggunakan pengubah anak. Kueri EQL ini memungkinkan Anda untuk mencari di semua proses dengan leluhur tertentu, di mana pun dalam hierarki. Misalnya, Anda dapat mencari aplikasi yang, katakanlah, memiliki proses regsvr32.exe sebagai leluhur dan mungkin telah mengeksploitasi kerentanan terkenal yang saya jelaskan di sini .
Ada terlalu banyak yang bisa dikatakan tentang EQL dalam posting yang sudah panjang ini, jadi saya lebih suka menerbitkan artikel terpisah tentang detail keterampilan EQL untuk menemukan kerentanan.
Pikiran akhir tentang solusi deteksi ancaman DIY
Saya berjanji untuk mengunduh repositori Sysmon dengan semua skrip deteksi ancaman yang dijelaskan dalam artikel ini. Periksa kembali GitHub saya secara berkala karena saya akan menambahkan alat pendeteksi ancaman berbasis grafik dari waktu ke waktu bersama dengan dokumentasi tambahan - terlalu banyak untuk dibahas dalam satu artikel.
Anda berhasil sampai di tempat ini, selamat!
Coba skrip saya atau gunakan sebagai dasar untuk mengembangkan ide deteksi ancaman Anda sendiri. PowerShell bagus untuk algoritme yang kompleks. Bagi saya, yang tumbuh dalam bahasa shell Linux, merupakan kejutan yang menyenangkan untuk bekerja dengan bahasa scripting yang matang. Dan saya menyarankan Anda untuk memeriksa Galeri PowerShell, sumber daya hebat lainnya untuk skrip pertempuran siap pakai: Anda tidak perlu menemukan kembali roda di dunia PowerShell.
Pengambilan lain yang lebih penting dari keseluruhan artikel adalah kesadaran bahwa vendor solusi tingkat perusahaan tidak hanya menggunakan teknologi deteksi ancaman yang jauh lebih canggih daripada yang dapat ditulis oleh pengembang TI di waktu luang mereka, tetapi juga kemampuan beradaptasi dari solusi ini untuk bekerja dengan tingkat lalu lintas. organisasi besar. Tentu saja, menggunakan solusi DIY untuk menganalisis server yang kurang dimanfaatkan atau validasi tambahan produk perusahaan adalah ide yang bagus. Tetapi intelijen dan identifikasi ancaman memang merupakan masalah data besar , dan jelas bukan tantangan yang dapat diselesaikan oleh PowerShell.
Jika Anda tertarik dengan kesempatan untuk mempelajari lebih lanjut tentang bagaimana Varonis menangani tugas menganalisis dan mendeteksi ancaman, Anda selalu dapat meminta demo pribadi .