Hal berguna apa yang dapat diambil dari log workstation berbasis Windows?

Stasiun kerja pengguna adalah titik infrastruktur yang paling rentan dalam hal keamanan informasi. Pengguna mungkin menerima surat ke email kantor mereka yang tampaknya berasal dari sumber yang aman, namun dengan link ke situs yang terinfeksi. Mungkin seseorang akan mengunduh utilitas yang berguna untuk bekerja dari lokasi yang tidak diketahui. Ya, Anda dapat menemukan lusinan kasus bagaimana malware dapat menyusup ke sumber daya internal perusahaan melalui pengguna. Oleh karena itu, stasiun kerja memerlukan perhatian lebih, dan dalam artikel ini kami akan memberi tahu Anda di mana dan tindakan apa yang perlu dilakukan untuk memantau serangan.

Hal berguna apa yang dapat diambil dari log workstation berbasis Windows?

Untuk mendeteksi serangan sedini mungkin, WIndows memiliki tiga sumber peristiwa yang berguna: Log Peristiwa Keamanan, Log Pemantauan Sistem, dan Log Power Shell.

Log Peristiwa Keamanan

Ini adalah lokasi penyimpanan utama untuk log keamanan sistem. Ini termasuk peristiwa login/logout pengguna, akses ke objek, perubahan kebijakan, dan aktivitas terkait keamanan lainnya. Tentu saja, jika kebijakan yang tepat dikonfigurasi.

Hal berguna apa yang dapat diambil dari log workstation berbasis Windows?

Pencacahan pengguna dan grup (peristiwa 4798 dan 4799). Pada awal serangan, malware sering mencari melalui akun pengguna lokal dan grup lokal di stasiun kerja untuk menemukan kredensial untuk transaksi gelapnya. Peristiwa ini akan membantu mendeteksi kode berbahaya sebelum berpindah dan, dengan menggunakan data yang dikumpulkan, menyebar ke sistem lain.

Pembuatan akun lokal dan perubahan grup lokal (peristiwa 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 dan 5377). Serangan juga dapat dimulai, misalnya dengan menambahkan pengguna baru ke grup administrator lokal.

Upaya masuk dengan akun lokal (peristiwa 4624). Pengguna terhormat masuk dengan akun domain, dan mengidentifikasi login dengan akun lokal dapat berarti dimulainya serangan. Peristiwa 4624 juga menyertakan login dengan akun domain, jadi saat memproses peristiwa, Anda perlu memfilter peristiwa yang domainnya berbeda dari nama stasiun kerja.

Upaya untuk masuk dengan akun yang ditentukan (peristiwa 4648). Ini terjadi ketika proses berjalan dalam mode β€œrun as”. Hal ini tidak boleh terjadi selama pengoperasian normal sistem, sehingga kejadian seperti itu harus dikendalikan.

Mengunci/membuka kunci stasiun kerja (peristiwa 4800-4803). Kategori kejadian mencurigakan mencakup segala tindakan yang terjadi pada stasiun kerja yang terkunci.

Perubahan konfigurasi firewall (peristiwa 4944-4958). Jelasnya, saat menginstal perangkat lunak baru, pengaturan konfigurasi firewall dapat berubah, yang akan menyebabkan kesalahan positif. Dalam kebanyakan kasus, perubahan tersebut tidak perlu dikontrol, namun tidak ada salahnya untuk mengetahuinya.

Menghubungkan perangkat Plug'n'play (acara 6416 dan hanya untuk WIndows 10). Penting untuk mewaspadai hal ini jika pengguna biasanya tidak menyambungkan perangkat baru ke stasiun kerja, namun tiba-tiba mereka melakukannya.

Windows menyertakan 9 kategori audit dan 50 subkategori untuk penyesuaian. Kumpulan subkategori minimum yang harus diaktifkan di pengaturan:

Logon / Logoff

  • Masuk;
  • Keluar;
  • Penguncian Akun;
  • Acara Masuk/Keluar Lainnya.

Account Management

  • Manajemen Akun Pengguna;
  • Manajemen Grup Keamanan.

Perubahan Kebijakan

  • Perubahan Kebijakan Audit;
  • Perubahan Kebijakan Otentikasi;
  • Perubahan Kebijakan Otorisasi.

Monitor Sistem (Sysmon)

Sysmon adalah utilitas bawaan Windows yang dapat merekam peristiwa di log sistem. Biasanya Anda perlu menginstalnya secara terpisah.

Hal berguna apa yang dapat diambil dari log workstation berbasis Windows?

Peristiwa yang sama ini, pada prinsipnya, dapat ditemukan di log keamanan (dengan mengaktifkan kebijakan audit yang diinginkan), namun Sysmon memberikan rincian lebih lanjut. Peristiwa apa saja yang bisa diambil dari Sysmon?

Pembuatan proses (ID peristiwa 1). Log peristiwa keamanan sistem juga dapat memberi tahu Anda kapan *.exe dimulai dan bahkan menunjukkan nama dan jalur peluncurannya. Namun tidak seperti Sysmon, ia tidak akan dapat menampilkan hash aplikasi. Perangkat lunak berbahaya bahkan mungkin disebut notepad.exe yang tidak berbahaya, tetapi hash-lah yang akan mengungkapnya.

Koneksi Jaringan (ID Peristiwa 3). Jelas sekali, ada banyak koneksi jaringan, dan tidak mungkin untuk melacak semuanya. Namun penting untuk diingat bahwa Sysmon, tidak seperti Security Log, dapat mengikat koneksi jaringan ke bidang ProcessID dan ProcessGUID, serta menunjukkan port dan alamat IP sumber dan tujuan.

Perubahan pada registri sistem (ID peristiwa 12-14). Cara termudah untuk menambahkan diri Anda ke autorun adalah dengan mendaftar di registri. Log Keamanan dapat melakukan ini, namun Sysmon menunjukkan siapa yang membuat perubahan, kapan, dari mana, ID proses, dan nilai kunci sebelumnya.

Pembuatan file (ID peristiwa 11). Sysmon, tidak seperti Security Log, tidak hanya akan menampilkan lokasi file, tetapi juga namanya. Jelas bahwa Anda tidak dapat melacak semuanya, tetapi Anda dapat mengaudit direktori tertentu.

Dan sekarang apa yang tidak ada dalam kebijakan Log Keamanan, tetapi ada di Sysmon:

Perubahan waktu pembuatan file (ID peristiwa 2). Beberapa malware dapat memalsukan tanggal pembuatan file untuk menyembunyikannya dari laporan file yang baru dibuat.

Memuat driver dan perpustakaan dinamis (ID peristiwa 6-7). Memantau pemuatan DLL dan driver perangkat ke dalam memori, memeriksa tanda tangan digital dan validitasnya.

Buat thread dalam proses yang sedang berjalan (event ID 8). Salah satu jenis serangan yang juga perlu diwaspadai.

Acara RawAccessRead (ID Acara 9). Operasi pembacaan disk menggunakan β€œ.”. Dalam sebagian besar kasus, aktivitas seperti itu dianggap tidak normal.

Buat aliran file bernama (ID peristiwa 15). Suatu peristiwa dicatat ketika aliran file bernama dibuat yang memancarkan peristiwa dengan hash dari konten file.

Membuat pipa dan koneksi bernama (event ID 17-18). Melacak kode berbahaya yang berkomunikasi dengan komponen lain melalui pipa bernama.

Kegiatan WMI (ID acara 19). Pendaftaran peristiwa yang dihasilkan saat mengakses sistem melalui protokol WMI.

Untuk melindungi Sysmon itu sendiri, Anda perlu memantau kejadian dengan ID 4 (Sysmon berhenti dan memulai) dan ID 16 (perubahan konfigurasi Sysmon).

Log Power Shell

Power Shell adalah alat yang ampuh untuk mengelola infrastruktur Windows, sehingga kemungkinan besar penyerang akan memilihnya. Ada dua sumber yang dapat Anda gunakan untuk mendapatkan data peristiwa Power Shell: log Windows PowerShell dan log Microsoft-WindowsPowerShell/Operasional.

Catatan Windows PowerShell

Hal berguna apa yang dapat diambil dari log workstation berbasis Windows?

Penyedia data dimuat (ID peristiwa 600). Penyedia PowerShell adalah program yang menyediakan sumber data untuk dilihat dan dikelola PowerShell. Misalnya, penyedia bawaan dapat berupa variabel lingkungan Windows atau registri sistem. Kemunculan pemasok baru harus dipantau untuk mendeteksi aktivitas jahat pada waktunya. Misalnya, jika Anda melihat WSMan muncul di antara penyedia, maka sesi PowerShell jarak jauh telah dimulai.

Microsoft-WindowsPowerShell / Log operasional (atau MicrosoftWindows-PowerShellCore / Operasional di PowerShell 6)

Hal berguna apa yang dapat diambil dari log workstation berbasis Windows?

Pencatatan modul (ID peristiwa 4103). Peristiwa menyimpan informasi tentang setiap perintah yang dijalankan dan parameter pemanggilannya.

Pencatatan pemblokiran skrip (ID peristiwa 4104). Pencatatan pemblokiran skrip menunjukkan setiap blok kode PowerShell yang dieksekusi. Bahkan jika penyerang mencoba menyembunyikan perintah tersebut, jenis peristiwa ini akan menampilkan perintah PowerShell yang sebenarnya dijalankan. Jenis peristiwa ini juga dapat mencatat beberapa panggilan API tingkat rendah yang sedang dilakukan, peristiwa ini biasanya dicatat sebagai Verbose, namun jika perintah atau skrip mencurigakan digunakan dalam blok kode, maka akan dicatat sebagai tingkat keparahan Peringatan.

Harap perhatikan bahwa setelah alat dikonfigurasi untuk mengumpulkan dan menganalisis peristiwa ini, waktu debug tambahan akan diperlukan untuk mengurangi jumlah positif palsu.

Beri tahu kami di komentar log apa yang Anda kumpulkan untuk audit keamanan informasi dan alat apa yang Anda gunakan untuk ini. Salah satu bidang fokus kami adalah solusi untuk mengaudit peristiwa keamanan informasi. Untuk mengatasi masalah pengumpulan dan analisis log, kami menyarankan untuk melihat lebih dekat Pencarian Dalam Kepercayaan, yang dapat mengompresi data yang disimpan dengan rasio 20:1, dan satu instance terinstal mampu memproses hingga 60000 peristiwa per detik dari 10000 sumber.

Sumber: www.habr.com

Tambah komentar