Dan kemudian kami mengetahui bahwa sekelompok penggemar memutuskan untuk mengatur sprint dua minggutentang aturan penulisan untuk proyek Sigma , yang dibuat untuk mengembangkan format terpadu untuk menjelaskan aturan untuk sistem SIEM dan didukung oleh lebih dari 140 peserta. Kami tertarik dengan berita tentang acara tersebut, karena sebagai vendor SIEM kami sangat mengikuti perkembangan komunitas.
Bayangkan betapa terkejutnya kami ketika panitia menghubungi kami dan mengundang tim Pusat Pakar Keamanan PT untuk berpartisipasi dalam sprint! Peserta acara membentuk Open Security Collaborative Development (OSCD) - sebuah inisiatif internasional spesialis keamanan informasi yang bertujuan menyebarluaskan pengetahuan dan meningkatkan keamanan komputer secara umum. Kami dengan senang hati setuju untuk berpartisipasi untuk menerapkan pengalaman kami demi keselamatan bersama.
Bagaimana artikel ini muncul
Ketika kami mulai menulis aturan, kami menyadari bahwa tidak ada deskripsi lengkap tentang sintaks aturan Sigma, terutama di Rusia. Sumber utama pengetahuan adalah GitHub dan pengalaman pribadi. Ada beberapa artikel bagus (dalam bahasa Rusia dan Inggris ), tetapi di dalamnya fokus dialihkan dari sintaksis aturan ke analisis ruang lingkup penerapan aturan-aturan Sigma atau penciptaan aturan tertentu. Kami memutuskan untuk membuatnya lebih mudah bagi pemula untuk berkenalan dengan proyek Sigma, berbagi pengalaman kami sendiri, mengumpulkan informasi di satu tempat tentang sintaksis dan fitur penggunaannya. Dan tentu saja kami berharap ini akan membantu memperluas inisiatif OSCD dan menciptakan komunitas besar di masa depan.
Karena ada banyak materi, kami memutuskan untuk menerbitkan deskripsi dalam serangkaian tiga artikel:
- , ( ).
- . , .
- (, , , , ) .
Sigma
Sigma adalah format terpadu untuk menjelaskan aturan deteksi berdasarkan data dari log. Aturan disimpan dalam file YAML yang terpisah. Sigma memungkinkan Anda untuk menulis aturan menggunakan sintaks terpadu satu kali, dan kemudian, menggunakan konverter khusus, dapatkan aturan dalam sintaks sistem SIEM yang didukung. Selain sintaks kueri dari berbagai sistem SIEM, penciptaan kueri dari tipe berikut ini didukung:
- Kueri Penelusuran Elastics,
- garis peluncuran utilitas grep dengan parameter yang diperlukan,
- Windows Audit Log string PowerShell.
Dua tipe terakhir terkenal karena fakta bahwa mereka tidak memerlukan perangkat lunak tambahan untuk menganalisis log. Utilitas grep dan interpreter PowerShell masing-masing didukung di luar Linux dan Windows.
Keberadaan format terpadu untuk menggambarkan deteksi berdasarkan log membuatnya lebih mudah untuk berbagi pengetahuan, mengembangkan keamanan sumber terbuka, dan membantu komunitas keamanan informasi melawan ancaman yang muncul.
Sintaks umum
Pertama-tama, harus dikatakan bahwa ada bagian peraturan yang diperlukan dan opsional. Ini didokumentasikan dalam wiki resmi di GitHub. Garis besar aturan (sumber: Wiki resmi) disajikan di bawah ini:
Hampir semua aturan dapat dibagi menjadi tiga bagian:
- atribut yang menggambarkan aturan (informasi meta);
- atribut yang menggambarkan sumber data;
- atribut yang menggambarkan kondisi untuk memicu aturan.
Masing-masing bagian sesuai dengan atribut tingkat tinggi yang diperlukan dari judul (selain judul, kelompok terakhir menyertakan atribut tingkat tinggi opsional lainnya), sumber log dan deteksi .
Ada satu fitur lagi dari struktur aturan yang layak dibicarakan. Karena aturan dijelaskan dalam bahasa markah YAML, pengembang Sigma telah menemukan beberapa kegunaan untuk ini, karena format YAML memungkinkan beberapa dokumen YAML untuk ditempatkan dalam satu file. Dan untuk Sigma - beberapa aturan untuk digabungkan dalam satu file, yaitu, buat "koleksi aturan". Pendekatan ini nyaman ketika ada beberapa cara untuk mendeteksi serangan dan Anda tidak ingin menduplikasi bagian deskriptif (seperti yang akan dijelaskan pada bagian yang sesuai, Anda dapat menduplikasi tidak hanya bagian deskriptif aturan).
Dalam hal ini, aturan secara konvensional dibagi menjadi dua bagian:
- bagian dengan atribut umum untuk item koleksi (biasanya semua bidang, kecuali untuk bagian sumber log dan deteksi),
- satu atau beberapa bagian yang menjelaskan deteksi (bagian logsource dan deteksi).
Jika file berisi aturan tunggal, pernyataan ini juga benar, karena kami mendapatkan koleksi yang merosot dari satu aturan. Kumpulan peraturan akan dibahas secara rinci di bagian ketiga dari seri artikel ini.
Selanjutnya, kita akan melihat contoh aturan hipotetis. Perlu dicatat bahwa komentar dalam formulir ini biasanya tidak digunakan dalam aturan, di sini hanya untuk menggambarkan bidang.
Deskripsi aturan umum
Contoh membuat aturan Sigma
Sebelum menjelaskan detail sintaks dan berbicara tentang kapabilitas aturan Sigma, mari kita perhatikan contoh kecil pembuatan aturan tersebut untuk memperjelas dari mana dalam praktiknya ini atau nilai atribut tersebut berasal. Ada artikel bagus tentang topik ini dalam bahasa Inggris. Jika Anda sudah mencoba untuk menulis aturan Anda sendiri dan mencari tahu data apa yang perlu Anda tentukan dalam atribut file YAML, Anda dapat melanjutkan ke bagian selanjutnya dengan deskripsi terperinci dari bagian sumber acara (kami juga akan memanggil sumber log bagian ini).
Mari kita jelaskan bagaimana cara membuat aturan yang mendeteksi penggunaan SettingSyncHost.exe sebagai Living Off The Land Binary (LOLBin). Pembuatan aturan biasanya melibatkan tiga tahap:
- melakukan serangan dan mengumpulkan log yang diperlukan,
- deskripsi deteksi sebagai suatu aturan,
- memeriksa aturan yang dibuat.
Melakukan serangan
Gagasan untuk aturan ini didokumentasikan dengan baik di blog Hexacorn . Setelah membaca dengan cermat, menjadi jelas langkah apa yang perlu diambil untuk mengulangi hasil yang dijelaskan dalam artikel:
- Salin program yang ingin Anda jalankan ke direktori yang dapat ditulisi. Artikel menyarankan untuk memilih% TEMP%, namun Anda dapat memilih jalur pilihan Anda. Perlu dipertimbangkan bahwa subdirektori akan dibuat di direktori ini dengan nama yang Anda tentukan di langkah 4.
- , , , (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). , findstr.exe. , SettingSyncHost.exe Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
- , ( settingsynchost.exe cmd PowerShell,
cd < >). - :
c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <___> - SettingSyncHost.exe.
Sysmon diinstal pada sistem dengan file konfigurasi dari proyek sysmon-modular . Dengan demikian, pengumpulan log dilakukan secara otomatis. Jenis log apa yang berguna untuk menulis deteksi akan terlihat saat menulis aturan.
Deskripsi deteksi dalam bentuk aturan Sigma
Pada langkah ini, dua pendekatan mungkin dilakukan: temukan aturan yang ada yang paling dekat dengan logika deteksi dan modifikasi sesuai dengan kebutuhan Anda, atau tulis aturan dari awal. Pada tahap awal, disarankan untuk tetap berpegang pada pendekatan pertama. Untuk kejelasan, kami akan menulis aturan menggunakan pendekatan kedua.
Kami membuat file baru dan mencoba menjelaskan esensinya dengan singkat dan ringkas dalam namanya. Di sini Anda harus mematuhi gaya aturan yang ada. Dalam kasus kami, kami memilih nama win_using_settingsynchost_to_run_hijacked_binary.yml. Selanjutnya, kita mulai mengisinya dengan konten. Mari kita mulai dengan mengisi informasi meta di awal aturan. Kami sudah memiliki semua data yang diperlukan untuk ini.
Kami menjelaskan secara singkat jenis serangan yang ditemukan oleh aturan di lapangan
title, penjelasan yang lebih terperinci - di bidang deskripsi, untuk aturan baru biasanya menetapkan status: eksperimental. Pengidentifikasi unik dapat dibuat dalam beberapa cara, pada Windows, cara termudah adalah dengan menjalankan kode berikut dalam juru bahasa PowerShell:
PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5fSisa bidang berbicara sendiri, saya hanya akan mencatat bahwa disarankan untuk memberikan tautan ke sumber yang membantu memahami serangan itu. Ini akan membantu orang-orang yang akan lebih memahami aturan ini, dan itu juga merupakan penghargaan atas upaya yang dilakukan oleh penulis studi asli untuk menggambarkan serangan itu.
Aturan kami pada tahap ini adalah sebagai berikut:
Selanjutnya, Anda perlu menjelaskan sumber-sumber log. Seperti yang disebutkan di atas, kita akan mengandalkan log Sysmon, namun, dengan munculnya kategori umum, biasanya menggunakan kategori process_creation untuk membuat proses. Lebih lanjut tentang kategori umum akan dibahas di bawah ini. Perhatikan bahwa sudah lazim menulis komentar dan saran tentang mengonfigurasikan sumber di bidang definisi, seperti fitur konfigurasi Sysmon:
Sekarang perlu untuk menggambarkan logika deteksi. Ini adalah bagian yang paling memakan waktu. Serangan ini dapat dideteksi oleh banyak kriteria, contoh kami tidak mengklaim mencakup semua cara deteksi yang mungkin, oleh karena itu, kami akan menjelaskan salah satu opsi yang mungkin.
Jika Anda melihat peristiwa yang terjadi, Anda dapat membangun rantai berikut.
Pertama, kami memulai proses (PID: 4712) dengan baris awal c: \ windows \ system32 \ SettingSyncHost.exe -LoadAndRunDiagScript join_oscd
Perhatikan bahwa direktori kerja proses saat ini adalah direktori TEMP pengguna.
Selanjutnya, proses yang berjalan membuat file batch dan mulai pelaksanaannya.
Proses mengeksekusi file batch instruksi menerima pengidentifikasi 7076. Analisis lebih lanjut dari peristiwa melihat file peluncuran ipconfig.exe, yang tidak mengandung file sistem yang melekat dan meta Plus terletak di folder dengan file sementara:
Diusulkan untuk dianggap sebagai tanda proses peluncuran serangan, executable yang tidak berbohong dalam direktori sistem (C: \ Windows \ System32), dan juga jika baris startup proses induk berisi substring "cmd.exe / c", "RoamDiag.cmd" dan "-outputpath". Mari kita uraikan ini dalam sintaks Sigma dan dapatkan aturan final (analisis terperinci tentang konstruksi yang dapat digunakan untuk menggambarkan logika deteksi akan diberikan di bagian selanjutnya dari seri artikel kami tentang Sigma):
Memeriksa bahwa aturan berfungsi
Kami meluncurkan konverter ke kueri PowerShell:
Untuk kasus kami, kueri ini tidak akan memberikan hasil yang diinginkan, karena filter pengecualian juga menemukan jalur ke file induk file yang dapat dieksekusi. Oleh karena itu, kami cukup menunjukkan bahwa tidak boleh ada huruf t sebelum kata Image - akhir kata Parent:
Kami melihat bahwa acara kami ditemukan. Aturannya bekerja.
Inilah bagaimana aturan Sigma dibuat dalam praktik. Selanjutnya, kami akan menjelaskan secara rinci bidang yang bertanggung jawab untuk deteksi, yaitu deskripsi sumber log.
Deteksi uraian
Bagian utama dari aturan ini adalah deskripsi deteksi, karena di sinilah informasi terdapat di mana dan bagaimana mencari tanda-tanda serangan. Informasi ini terkandung dalam bidang atribut logsource (di mana) dan deteksi (bagaimana). Pada artikel ini kita akan melihat lebih dekat pada bagian sumber log, dan menjelaskan bagian deteksi di bagian selanjutnya dari seri kami.
Deskripsi bagian sumber acara (atribut logsource)
Deskripsi sumber acara terkandung dalam nilai bidang logsource . Bagian ini menjelaskan sumber data dari mana peristiwa untuk bagian deteksi akan dikirim (atribut deteksi dibahas di bagian berikutnya). Bagian ini menjelaskan sumber itu sendiri, platform dan aplikasi yang diperlukan untuk deteksi. Ini dapat berisi tiga atribut yang diproses secara otomatis oleh konverter, dan sejumlah elemen opsional yang berubah-ubah. Bidang dasar:
- Kategori - menjelaskan kelas-kelas produk. Contoh nilai untuk bidang ini: firewall, web, antivirus. Juga, bidang tersebut dapat berisi kategori umum, yang akan dibahas di bawah ini.
- Produk adalah produk perangkat lunak atau sistem operasi yang membuat log.
- Layanan - pembatasan log ke subset layanan tertentu, misalnya "sshd" untuk Linux atau "Keamanan" untuk Windows.
- Definisi - bidang tambahan untuk menggambarkan fitur sumber, misalnya, persyaratan untuk menyiapkan audit (jarang digunakan, contoh aturan dengan bidang ini dapat ditemukan di GitHub ). Disarankan untuk menggunakan atribut ini jika sumbernya memiliki spesifik.
Wiki resmi di GitHub mendefinisikan seperangkat bidang yang harus digunakan agar aturan menjadi produk-silang. Bidang-bidang ini diringkas dalam tabel di bawah ini.
| Kategori | Produk | Layanan |
|---|---|---|
| windows | keamanan | |
| sistem | ||
| sysmon | ||
| penjadwal Tugas | ||
| wmi | ||
| aplikasi | ||
| dns-server | ||
| kerangka kerja pengemudi | ||
| PowerShell | ||
| PowerShell-klasik | ||
| linux | auth | |
| auditd | ||
| clamav | ||
| apache | mengakses | |
| kesalahan | ||
| process_creation | windows | |
| proksi | ||
| firewall | ||
| server web | ||
| dns |
Selanjutnya, kami akan menjelaskan secara lebih rinci beberapa sumber log, menunjukkan bidang peristiwa yang digunakan dan memberikan contoh aturan di mana bidang ini digunakan.
Bidang acara kategori proksi
| Kategori | Produk / Layanan | Bidang | Contohnya |
|---|---|---|---|
| proksi | c-uri | proxy_ursnif_malware.yml | |
| c-uri-ekstensi | proxy_download_susp_tlds_blacklist.yml | ||
| c-uri-query | proxy_susp_flash_download_loc.yml | ||
| c-uri-stem | proxy_susp_flash_download_loc.yml | ||
| agen-c-pengguna | proxy_powershell_ua.yml | ||
| cs-bytes | - | ||
| cs-cookie | proxy_cobalt_amazon.yml | ||
| cs-host | proxy_cobalt_ocsp.yml | ||
| metode cs | proxy_downloadcradle_webdav.yml | ||
| r-dns | proxy_apt40.yml | ||
| perujuk-cs | - | ||
| versi cs | - | ||
| sc-bytes | - | ||
| sc-status | proxy_ursnif_malware.yml | ||
| src_ip | - | ||
| dst_ip | - |
Deskripsi bidang acara dari sumber ini
-------------------------------------------------- ------------- c-uri - URI, c-uri-extension - URI. c-uri-query - URI, c-uri-stem - URL ( :) . URIstem - c-useragent - UserAgent HTTP- cs-bytes - , cs-cookie - cookie, cs-host - Host HTTP- cs-method - HTTP- r-dns - DNS- cs-referrer - Referrer HTTP- cs-version - HTTP, sc-bytes - , sc-status - HTTP- src_ip - IP- dst_ip - IP-
Bidang Acara Firewall
| Kategori | Produk / Layanan | Bidang | Contohnya |
|---|---|---|---|
| firewall | src_ip | - | |
| src_port | - | ||
| dst_ip | - | ||
| dst_port | net_high_dns_bytes_out.yml | ||
| nama pengguna | - |
Deskripsi bidang acara dari sumber ini
--------------------------------------------------------------- src_ip - IP- src_port - , dst_ip - IP- dst_port - , username - ,
Bidang acara dari kategori server Web
| Kategori | Produk / Layanan | Bidang | Contohnya |
|---|---|---|---|
| server web | c-uri | web_cve_2020_0688_msexchange.yml | |
| c-uri-ekstensi | - | ||
| c-uri-query | - | ||
| c-uri-stem | - | ||
| agen-c-pengguna | - | ||
| cs-bytes | - | ||
| cs-cookie | - | ||
| cs-host | - | ||
| metode cs | web_cve_2020_0688_msexchange.yml | ||
| r-dns | - | ||
| perujuk-cs | - | ||
| versi cs | - | ||
| sc-bytes | - | ||
| sc-status | - | ||
| src_ip | - | ||
| dst_ip | - |
Deskripsi bidang acara dari sumber ini
--------------------------------------------------------------- c-uri - URI, c-uri-extension - URI. c-uri-query - URI, c-uri-stem - URI ( :) . URI stem - c-useragent - UserAgent HTTP- cs-bytes - , cs-cookie - cookie, cs-host - Host HTTP- cs-method - HTTP- r-dns - DNS- cs-referrer - Referrer HTTP- cs-version - HTTP, sc-bytes - , sc-status - HTTP- src_ip - IP- dst_ip - IP-
Kategori umum
Karena Sigma adalah format umum untuk menggambarkan aturan deteksi berbasis log, sintaksis aturan tersebut harus dapat menggambarkan logika deteksi untuk sistem yang berbeda. Beberapa sistem menggunakan tabel dengan data agregat alih-alih peristiwa, dan data dari sumber yang berbeda dapat masuk untuk menggambarkan situasi yang sama. Untuk menyatukan sintaks dan memecahkan masalah serupa, mekanisme sumber log generik diperkenalkan. Saat ini, satu kategori telah dibuat - process_creation. Anda dapat membaca lebih lanjut tentang ini di blog patzke.org . Daftar bidang untuk kategori ini dapat ditemukan di halaman taksonomi (halaman ini juga menjelaskan kategori yang didukung lainnya).
Proses_creation bidang peristiwa kategori umum
| Kategori | Produk | Bidang | Contohnya |
|---|---|---|---|
| process_creation | windows | UtcTime | - |
| Cairan Proses | - | ||
| ProcessId | sysmon_raw_disk_access_using_illegitimate_tools.yml | ||
| Gambar | win_susp_regsvr32_anomalies.yml | ||
| FileVersion | sysmon_susp_file_characteristics.yml | ||
| Deskripsi | sysmon_susp_file_characteristics.yml | ||
| Produk | sysmon_susp_file_characteristics.yml | ||
| Perusahaan | sysmon_susp_file_characteristics.yml | ||
| Garis komando | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| Direktori saat ini | win_susp_powershell_parent_combo.yml | ||
| Pengguna | win_susp_schtask_creation.yml | ||
| LogonGuid | - | ||
| LogonId | - | ||
| TerminalSessionId | - | ||
| IntegrityLevel | - | ||
| imphash | win_renamed_paexec.yml | ||
| md5 | - | ||
| sha256 | - | ||
| ParentProcessGuid | - | ||
| ParentProcessId | - | ||
| ParentImage | win_meterpreter_or_cobaltstrike_getsystem_service_start.yml | ||
| ParentCommandLine | win_cmstp_com_object_access.yml |
Deskripsi bidang acara dari sumber ini
--------------------------------------------------------------- UtcTime - UTC ProcessGuid - GUID ProcessId - PID Image - FileVersion - , Description - , Product - , Company - — , CommandLine - CurrentDirectory - User - , LogonGuid - GUID LogonId - TerminalSessionId - IntegrityLevel - , imphash - - md5 - MD5- , sha256 - SHA256- , ParentProcessGuid - GUID ParentProcessId - PID ParentImage - ParentCommandLine -
MEMPERBARUI
Dalam persiapan untuk artikel ini, kategori generik baru telah ditambahkan:
- network_connection (Contoh sysmon_powershell_network_connection )
- dns_query (Contoh sysmon_regsvr32_network_activity )
- registry_event (contoh sysmon_rdp_settings_hijack )
- file_creation
- process_access (contoh sysmon_lsass_memdump )
- image_load (contoh sysmon_mimikatz_inmemory_detection )
- proses_terminasi
Mereka semua melibatkan informasi duplikat di acara log Windows dan acara Sysmon log. Kami menyarankan Anda untuk menggunakan kategori umum yang ada saat menulis aturan Anda. Karena proyek ini aktif berkembang, disarankan untuk mengikuti munculnya kategori baru dan memperbarui aturan Anda sesuai dengan inovasi lebih lanjut.
Statistik penggunaan sumber acara dalam aturan yang ada
Tabel di bawah ini menunjukkan konstruksi paling umum untuk menggambarkan sumber log. Kemungkinan besar, Anda akan menemukan di antara mereka yang sesuai dengan aturan Anda.
Statistik tentang penggunaan kombinasi bidang deskripsi untuk beberapa sumber yang paling umum (tanda hubung berarti tidak adanya bidang ini):
| Jumlah aturan | Kategori | Produk | Layanan | Sintaks sampel | Komentar |
|---|---|---|---|---|---|
| 197 | process_creation | windows | - | logsource:
kategori: produk process_creation : windows |
Kategori umum dari log pembuatan proses pada sistem Windows. Termasuk Sysmon
EventID = 1 dan Windows Security Event Log EventID = 4688 |
| 68 | - | windows | sysmon | logsource:
produk: layanan windows : sysmon |
Peristiwa Sysmon |
| 48 | -
|
windows | keamanan | logsource:
product: windows service: security |
Windows Security Event Log |
| 24 | proxy | — | — | logsource:
category: proxy |
- |
| 15 | — | windows | system | logsource:
product: windows service: system |
Windows System Event Log |
| 12 | accounting | cisco | aaa | logsource:
category: accounting product: cisco service: aaa |
Cisco AAA Security Services |
| 10 | — | windows | powershell | logsource:
product: windows service: powershell |
Microsoft Windows PowerShell Event Log |
| 9 | — | linux | — | logsource:
product: linux |
Linux |
| 8 | — | linux | auditd | logsource:
produk: layanan linux : auditd |
Acara Linux, klarifikasi ke log layanan tertentu (subsistem AuditD) |
Kiat untuk menulis aturan
Saat menulis aturan baru, situasi berikut mungkin terjadi:
- Sumber acara yang benar telah digunakan dalam aturan yang ada.
- Tidak ada aturan tunggal dalam repositori yang menggunakan sumber acara ini.
Jika Anda dihadapkan dengan kasus pertama, gunakan salah satu aturan yang ada sebagai templat. Mungkin sumber log yang diperlukan sudah digunakan dalam aturan lain, maka ini berarti bahwa penulis plugins (backend converter) untuk sistem SIEM yang berbeda, kemungkinan besar, memperhitungkannya dalam pemetaan mereka dan aturan Anda harus segera diproses dengan benar.
Dalam situasi kedua, perlu, menggunakan contoh aturan yang ada, untuk memahami cara menggunakan kategori, produk, dan pengidentifikasi layanan dengan benar. Saat membuat sumber log Anda sendiri, disarankan untuk menambahkannya ke semua pemetaan backend yang ada. Kontributor lain atau bahkan pengembang dapat melakukan ini, yang terpenting adalah menginformasikan tentang kebutuhan seperti itu.
Kami telah membuat visualisasi kombinasi bidang deskripsi sumber log dalam aturan yang ada:
Distribusi sumber log
Gunakan statistik untuk kombinasi subbidang atribut logsource
Pada artikel ini, kami memberikan contoh membuat aturan sederhana dan berbicara tentang deskripsi sumber acara. Sekarang Anda bisa menerapkan pengetahuan yang didapat, lihat aturan di repositori Sigma dan cari tahu sumber mana yang digunakan dalam aturan tertentu. Ikuti publikasi kami: di bagian selanjutnya kita akan melihat bagian paling sulit dari aturan Sigma - bagian yang menjelaskan logika deteksi.
Penulis : Anton Kutepov, spesialis departemen layanan pakar dan pengembangan Teknologi Positif (PT Expert Security Center)