KomuraSoft LLC
Hubungi kami
Menu

Kebijakan audit keamanan Windows dan investigasi log peristiwa di lapangan — menjadi staf IT yang bisa membaca peristiwa 4625

· · Windows, Keamanan, Log peristiwa, Kebijakan audit, Desain log, PowerShell, Sistem informasi

“Sejak tadi malam sebuah akun terus-menerus di-lockout. Tolong cari tahu penyebabnya.” “Saya ingin memeriksa apakah seseorang mencoba masuk dengan akun karyawan yang sudah keluar.” “Di server ini, dapatkah Anda memberi tahu siapa yang menjalankan apa, dan kapan?” — itu permintaan yang suatu hari tiba-tiba diterima staf IT di usaha kecil dan menengah, atau pengembang yang telah menyerahkan sistem ke klien. Dan yang akhirnya mereka andalkan adalah log peristiwa Security Windows.

Tetapi ketika Anda benar-benar membuka Event Viewer, dua kenyataan sedang menunggu. Peristiwa yang ingin dilihat tidak pernah terekam (kebijakan audit tidak aktif), atau ia terkubur di bawah gunung peristiwa yang tidak dapat dibaca (tenggelam dalam derau dan pembengkakan). Audit keamanan adalah sesuatu yang dapat ditangkap “jika Anda mengaktifkannya”, tetapi kecuali Anda merancang apa yang direkam dan sampai sejauh mana, ia tidak akan menolong ketika Anda benar-benar membutuhkannya.

Dua kenyataan yang menunggu di Event ViewerKetika Event Viewer dibuka, ada dua kenyataan: peristiwa yang ingin dilihat tidak terekam karena kebijakan audit tidak aktif, atau log membengkak penuh derau sehingga peristiwa terkubur dan tidak dapat dibaca, sehingga Anda perlu merancang apa yang direkam dan sampai sejauh manaTidak terekamTerkuburMembuka Event ViewerKenyataan yang menunggu?Peristiwa yang ingin dilihat tidak terekamTidak dapat dibaca karena peristiwa sangat banyakKebijakan audit nonaktifMembengkak penuh derauRancang apa yang direkam dan sampai sejauh mana

Gambar 1: “Tidak terekam” atau “terkubur sehingga tidak dapat dibaca”. Keduanya disebabkan karena rentang yang direkam tidak dirancang.

Artikel ini menata mekanisme kebijakan audit (dua sistem — dasar dan lanjutan), subkategori yang harus diaktifkan paling tidak di lingkungan skala kecil-menengah, cara membaca ID peristiwa yang sering muncul — 4624/4625/4740/4688 dan lainnya — desain kapasitas log Security, dan cara menyelidiki dengan PowerShell, semuanya berpijak pada sumber primer per Agustus 2026. Jika artikel audit NTLM, penandatanganan SMB, BitLocker, dan firewall yang telah dibahas di situs ini semuanya tentang “memperkuat pertahanan”, artikel ini tentang “membuatnya mungkin untuk mengonfirmasi belakangan apa yang terjadi” — sekuel yang mengikatnya menjadi satu.

1. Kesimpulan lebih dulu

  • Kebijakan audit punya dua sistem — “dasar” dan “lanjutan (Advanced Audit Policy)” — dan Anda tidak boleh mencampurnya. Microsoft menyatakan secara eksplisit bahwa memakai keduanya meninggalkan hasil audit dalam keadaan tidak terduga. Satukan di sisi lanjutan (lebih dari 40 subkategori).1
  • Periksa keadaan saat ini dengan auditpol /get /category:*. Perintah ini mendaftar apa yang benar-benar berlaku sekarang, terlepas dari apakah berasal dari GPO atau pengaturan lokal.2
  • “Aktifkan semuanya” adalah sesuatu yang tidak boleh dilakukan. Mengaktifkan subkategori yang menghasilkan volume peristiwa besar mengubur peristiwa yang benar-benar penting di bawah derau, dan memengaruhi kinerja juga. Mulai dari rekomendasi baseline Microsoft dan hanya tambahkan yang Anda butuhkan.34
  • Sign-in yang berhasil adalah 4624; yang gagal adalah 4625. Untuk 4624, baca “jenis sign-in apa itu” dari tipe logon (2 = Interactive, 3 = Network, 10 = RemoteInteractive, dan seterusnya).5
  • Untuk 4625, kode Status/Sub Status memberi tahu alasan kegagalan. Yang sering muncul adalah 0xC0000064 = nama pengguna tidak ada, 0xC000006A = kata sandi salah, 0xC0000072 = akun dinonaktifkan, dan 0xC0000234 = akun di-lockout.6
  • Tempat peristiwa terekam sudah ditentukan. 4624/4625 terekam di mesin yang diakses; validasi kredensial (4776) dan kegagalan pra-autentikasi Kerberos (4771) terekam di domain controller. Melihat mesin yang salah membuat Anda keliru menyimpulkan “tidak ada log”.678
  • Separuh desain log Security adalah wadahnya sendiri — ukuran maksimum dan retensi. Jika retensi disetel ke mode timpa, peristiwa lama hilang lebih dulu. Periksa ukuran maksimum dan jumlah rekaman dengan Get-WinEvent -ListLog Security, dan perluas dengan menghitung mundur dari jumlah hari yang benar-benar perlu Anda simpan.910
  • Pencatatan baris perintah untuk pembuatan proses (4688) kuat, tetapi harganya adalah rahasia yang mendarat di log dalam teks biasa. Audit skrip Anda sebelum mengaktifkannya.1112

2. Dasar kebijakan audit — jangan campur “dasar” dan “lanjutan”

Kebijakan audit Windows datang dalam dua sistem.1

  • Kebijakan audit dasar: sembilan pengaturan kategori di bawah “Local Policies > Audit Policy.” Ini sistem yang lebih lama, dari sebelum Windows Vista.
  • Advanced Audit Policy Configuration: 40-plus pengaturan subkategori di bawah “Security Settings > Advanced Audit Policy Configuration.” Ia memecah setiap kategori dasar menjadi beberapa subkategori — misalnya, satu kategori dasar “Audit account logon events” berkorespondensi dengan empat subkategori di sisi lanjutan. Mengaktifkan satu kategori dasar punya efek yang sama dengan mengaktifkan setiap subkategori yang berkorespondensi, yang merekam volume besar peristiwa yang mungkin tidak Anda minati.1

Poin pentingnya adalah bahwa kedua sistem ini tidak kompatibel satu sama lain. Microsoft menyatakan dengan gamblang: “Jangan memakai kebijakan audit dasar dan lanjutan sekaligus — melakukan itu dapat menghasilkan hasil audit yang tidak terduga.” Ketika kebijakan audit lanjutan diterapkan lewat Group Policy, pengaturan audit yang ada di komputer itu pertama-tama dikosongkan lalu pengaturan lanjutan diterapkan; sejak itu, hanya sisi lanjutan yang dapat mengontrol audit secara andal. Di lingkungan yang memakai sisi lanjutan, aktifkan opsi keamanan “Audit: Force audit policy subcategory settings to override audit policy category settings” agar pengaturan dasar tidak dapat menimpanya (ini aktif secara default di mesin mandiri).14

Hubungan kebijakan audit dasar dan lanjutanKebijakan audit dasar dan kebijakan audit lanjutan tidak kompatibel, dan memakai keduanya membuat hasil audit tidak terduga, jadi satukan di sisi lanjutan dan aktifkan pemaksaan pengaturan subkategori untuk mencegah penimpaan dari sisi dasarYaTidakKebijakan audit dasar（9 kategori）Memakai keduanya?Kebijakan audit lanjutan（40+ subkategori）Hasil audit dalam keadaan tidak terdugaSatukan di sisi lanjutanAktifkan paksa pengaturan subkategoriCegah penimpaan oleh pengaturan sisi dasar

Gambar 2: Kedua sistem tidak kompatibel. Satukan di sisi lanjutan, dan cegah penimpaan dari sisi dasar dengan pengaturan “force”.

Memeriksa keadaan saat ini adalah satu perintah, dijalankan dari command prompt administratif.2

rem daftar pengaturan audit yang sedang berlaku, per subkategori
auditpol /get /category:*

rem cadangkan pengaturan saat ini ke CSV sebelum mengubah, lalu pulihkan
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

Keluaran auditpol adalah “kebijakan yang benar-benar berlaku sebagai hasil”, terlepas dari apakah berasal dari GPO atau pengaturan lokal. Ia juga berguna untuk mencocokkan ketika pengaturan yang semestinya disebar lewat GPO tampaknya tidak berlaku. Catat bahwa perubahan pada pengaturan audit itu sendiri terekam sebagai peristiwa 4719, jadi “audit dinonaktifkan tanpa ada yang menyadari” juga dapat dilacak belakangan.12

Yang terlihat di auditpol adalah kebijakan hasilKeluaran auditpol adalah kebijakan audit yang berlaku sebagai hasil, terlepas dari apakah berasal dari GPO atau pengaturan lokal, berguna untuk mencocokkan ketika pengaturan GPO tidak diterapkan, dan perubahan pengaturan audit itu sendiri dapat dilacak belakangan lewat peristiwa 4719Pengaturan yang disebar lewat GPOKebijakan yang berlaku sebagai hasilPengaturan lokalDaftar dengan auditpol /getBerguna untuk mencocokkan saat GPO tidak diterapkanPerubahan pengaturan audit itu sendiri4719 terekam dan dapat dilacak belakangan

Gambar 3: auditpol mengembalikan “pengaturan yang berlaku” terlepas dari asalnya. Perubahan pengaturan audit itu sendiri tertinggal di 4719.

3. Tabel keputusan subkategori yang harus diaktifkan paling tidak

Alasan “aktifkan saja semuanya, agar aman” adalah langkah buruk sudah jelas. Misalnya, Microsoft memperingatkan bahwa mengaudit keberhasilan untuk subkategori pemakaian hak istimewa menghasilkan volume peristiwa begitu besar sehingga menjadi sulit menemukan entri lain di log keamanan, dan juga dapat berdampak signifikan pada kinerja.4 Wadah log (bab 5) terbatas, jadi semakin banyak derau yang Anda rekam, semakin ia memakan periode retensi untuk peristiwa yang benar-benar Anda butuhkan. Merancang audit pada dasarnya adalah memutuskan apa yang tidak direkam.

Mengapa mengaktifkan semuanya adalah langkah burukMengaktifkan semua subkategori menghasilkan peristiwa dalam jumlah besar, peristiwa yang penting terkubur dalam derau, kinerja terpengaruh, dan di wadah log yang terbatas jumlah hari retensi peristiwa yang diperlukan juga terpangkasAktifkan semua subkategoriPeristiwa dalam jumlah besar terjadiPeristiwa penting terkuburDampak pada kinerjaHari retensi terpangkasMerancang audit adalah memutuskan apa yang tidak direkam

Gambar 4: “Aktifkan semuanya” mengubur peristiwa yang penting. Merancang audit adalah memutuskan apa yang tidak direkam.

Microsoft menerbitkan rekomendasi baseline dan yang lebih kuat, dipecah menurut workstation dan server, dan itu adalah titik berangkat.3 Dari situ, tabel di bawah disusun sekitar sudut pandang lingkungan skala kecil-menengah: “apa yang paling tidak ingin kita bisa baca saat insiden.”

Subkategori (kategori) ID peristiwa utama Apa yang dapat diketahui Rekomendasi untuk usaha kecil dan menengah
Logon (Logon/Logoff) 4624 / 4625 Keberhasilan/kegagalan sign-in, tipe logon, sumber Berhasil + gagal. Windows 10 1809 dan setelahnya sudah mengaktifkan berhasil dan gagal secara default3
Special Logon (sama) 4672 / 4964 Terjadinya sign-in dengan hak istimewa administrator Berhasil
Account Lockout (sama) 4625 Percobaan logon gagal terhadap akun yang sedang di-lockout Gagal (4625 adalah peristiwa kegagalan; subkategori ini tidak punya peristiwa keberhasilan)13
User Account Management (Account Management) 4720 / 4726 / 4738 / 4740 Pembuatan, penghapusan, perubahan, lockout akun Berhasil + gagal
Security Group Management (sama) 4728 / 4732 / 4756 (ditambah), 4729 / 4733 / 4757 (dihapus) Anggota ditambahkan ke atau dihapus dari grup administratif dan lainnya (global/lokal/universal) Berhasil (subkategori ini tidak punya peristiwa kegagalan)14
Credential Validation (Account Logon) 4776 Keberhasilan atau kegagalan autentikasi NTLM. Terekam di DC untuk akun domain7 Berhasil + gagal
Kerberos Authentication Service (sama, hanya DC) 4768 / 4771 Penerbitan TGT dan kegagalan pra-autentikasi (kata sandi salah, dll.)8 Berhasil + gagal, di DC
Process Creation (Detailed Tracking) 4688 Siapa yang menjalankan apa, dari proses induk mana Berhasil. Baca peringatan bab 7 sebelum mengaktifkan pencatatan baris perintah
Other Object Access Events (Object Access) 4698 Pembuatan tugas terjadwal (teknik umum untuk persistensi)15 Pertimbangkan mengaktifkan keberhasilan
Audit Policy Change (Policy Change) 4719 Perubahan pada pengaturan audit itu sendiri Berhasil + gagal

Sebaliknya, pada umumnya paling aman tidak menyentuh audit akses objek sistem berkas atau registri, pemakaian hak istimewa, atau subkategori filter paket (5152 dan sejenisnya) secara default. Ini berguna ketika Anda membatasinya pada konfigurasi SACL yang disasar atau investigasi berbatas waktu, bukan sebagai sesuatu yang dibiarkan selalu terbuka di seluruh sistem — melakukan itu akan menghabiskan log Anda.4

Penanganan subkategori yang menghasilkan banyak peristiwaAudit akses objek sistem berkas dan registri, pemakaian hak istimewa, dan filter paket akan menghabiskan log jika dibiarkan selalu terbuka, jadi mereka berguna hanya dengan pengaturan SACL yang disempitkan atau selama periode isolasi terbatasSelalu terbukaSACL yang disempitkanPeriode isolasi terbatasSubkategori yang menghasilkan banyak peristiwaBagaimana mengaktifkannya?Audit akses objekPemakaian hak istimewa dan filter paketMenghabiskan logBergunaBerguna

Gambar 5: Jangan biarkan akses objek atau pemakaian hak istimewa selalu terbuka. Mereka berguna hanya jika sasaran dan periodenya disempitkan.

4. Cara membaca ID peristiwa yang sering muncul

4.1. 4624 — sign-in berhasil dipilah menurut tipe logon

4624, “An account was successfully logged on,” terekam di mesin tempat sesi logon dibuat (mesin yang diakses).5 Karena ini peristiwa bervolume tinggi, langkah pertama membacanya adalah memilah menurut Logon Type.5

Tipe logon Nama Artinya di lapangan
2 Interactive Sign-in di konsol PC itu sendiri
3 Network Akses lewat jaringan (folder berbagi, alat administrasi, dll.). Paling umum, karena muncul sekali per mesin
4 Batch Eksekusi batch (tugas terjadwal, dll.)
5 Service Layanan yang mulai (lewat Service Control Manager)
7 Unlock Membuka kunci layar
8 NetworkCleartext Logon jaringan di mana kata sandi diteruskan ke paket autentikasi dalam teks biasa
9 NewCredentials Duplikasi token yang ada dengan kredensial alternatif (setara dengan runas /netonly)
10 RemoteInteractive Remote Desktop
11 CachedInteractive Sign-in memakai kredensial tersimpan di cache (ketika DC tidak dapat dijangkau)

Bidang lain yang layak diperiksa bersamaan adalah nama akun di bawah “New Logon,” alamat sumber di bawah “Network Information,” “Authentication Package” (NTLM atau Kerberos), dan “Elevated Token” (apakah sesi punya hak istimewa administrator). Jika Anda ingin melacak hanya sign-in dengan hak istimewa administrator, peristiwa 4672 (Special privileges assigned to new logon), yang terekam di bawah Logon ID yang sama, juga berguna.5

Langkah memilah pembacaan 46244624 yang terekam dalam jumlah besar pertama-tama dipilah menurut tipe logon, lalu nama akun, sumber, paket autentikasi, dan token yang ditingkatkan diperiksa, dan sign-in dengan hak istimewa administrator dicocokkan dengan 4672 pada Logon ID yang sama4624 sign-in berhasilPilah menurut tipe logonPeriksa bidang utamaNama akun dan sumberPaket autentikasiToken yang ditingkatkanMelacak hak istimewa administrator4672 pada Logon ID yang sama

Gambar 6: 4624 dipilah menurut tipe logon, lalu bidangnya dibaca. Sign-in istimewa dikorelasikan dengan 4672.

4.2. 4625 — pastikan alasan kegagalan dengan kode Status/Sub Status

4625, “An account failed to log on,” terekam di mesin tempat logon dicoba.6 Alih-alih mempercayai kata-kata di bidang “Failure Reason”, cara andal membacanya adalah lewat kode heksadesimal Status/Sub Status. Yang sering muncul adalah sebagai berikut.6

  • 0xC0000064: Nama pengguna tidak ada. Rangkaian cepat dalam jendela waktu pendek dapat menandai serangan enumerasi akun
  • 0xC000006A: Kata sandi salah. Kegagalan berulang terhadap akun tertentu dapat menandai serangan tebakan kata sandi
  • 0xC000006D: Nama pengguna atau informasi autentikasi tidak valid
  • 0xC000006F: Di luar jam logon yang diizinkan
  • 0xC0000070: Dari workstation yang tidak diizinkan
  • 0xC0000072: Akun dinonaktifkan oleh administrator (percobaan terhadap akun karyawan yang sudah keluar muncul di sini)
  • 0xC000015B: Tipe logon yang diminta tidak diizinkan di mesin ini
  • 0xC0000193: Akun kedaluwarsa
  • 0xC0000234: Di-lockout

“Siapa, dari mana, dan mengapa gagal” dipastikan oleh trio akun sasaran, sumber (nama workstation / alamat IP), dan kode ini. Bab 6 memuat PowerShell yang mengekstrak ketiganya sekaligus dalam satu jalan.

Alur memastikan alasan kegagalan 4625Alasan kegagalan 4625 dipastikan dari kode heksadesimal Status/Sub Status, tanda serangan dibaca dari pola kode, lalu diidentifikasi dengan tiga poin: akun sasaran, sumber, dan kodeRangkaian 0xC0000064Rangkaian 0xC000006A0xC00000724625 sign-in gagalPeriksa kode Sub StatusPola kodenya?Tanda enumerasi akunTanda tebakan kata sandiPercobaan akun karyawan yang sudah keluarDipastikan dengan tiga poinAkun sasaran+sumber+kode

Gambar 7: Alasan kegagalan dipastikan dari kode, lalu dibaca sebagai tiga poin bersama akun sasaran dan sumber.

4.3. 4740 — sumber lockout adalah “Caller Computer Name”

4740, “A user account was locked out” (subkategori: User Account Management). Bidang kunci di peristiwa ini adalah “Caller Computer Name,” yang merekam komputer yang menjadi asal percobaan logon yang memicu lockout.16 Prosedur bakunya adalah mengidentifikasi mesin asal dari bidang ini, lalu mencari kredensial lama yang masih tersimpan di mesin itu. Dalam sebagian besar kasus penyebabnya adalah sesuatu yang terus memakai kredensial lama setelah perubahan kata sandi — kredensial tersimpan, sesi RDP yang dibiarkan terputus, atau layanan atau tugas terjadwal yang dikonfigurasi dengan kata sandi lama.

Langkah baku investigasi lockout akunIdentifikasi mesin sumber dari Caller Computer Name di 4740, lalu bersihkan kredensial lama yang tersisa di mesin itu: kredensial tersimpan, sesi RDP yang dibiarkan terputus, dan layanan atau tugas dengan kata sandi lama4740 lockout terjadiPeriksa Caller Computer NameIdentifikasi mesin sumberBersihkan kredensial lamaKredensial tersimpanSesi RDP yang dibiarkan terputusLayanan atau tugas dengan kata sandi lama

Gambar 8: Identifikasi sumber dari “Caller Computer Name” di 4740, lalu bersihkan kredensial lama di mesin itu.

Ada satu hal yang perlu diwaspadai. 4625 terekam di komputer yang menerima percobaan logon. Jika penyebabnya adalah logon jaringan dari mesin asal ke, misalnya, file server, tidak ada 4625 yang tertinggal di log Security mesin asal itu sendiri; jejaknya justru tertinggal di 4625 di server tujuan, atau, untuk akun domain, di 4776 (NTLM) atau 4771 (kegagalan pra-autentikasi Kerberos) di DC.78 Ketika “tidak ada apa-apa di log mesin asal,” pergilah melihat sisi yang menerima.

Mesin tempat jejak kegagalan tertinggalKegagalan logon jaringan tidak tertinggal di mesin sumber itu sendiri, melainkan terekam sebagai 4625 di server tujuan yang menerima percobaan logon, dan untuk akun domain jejak juga tertinggal sebagai 4776 atau 4771 di sisi DCLogon jaringanAutentikasi akun domainMesin sumber（4625 tidak tertinggal di sini）Server tujuan4625 terekamDomain controller4776（NTLM）/4771（Kerberos）

Gambar 9: 4625 tertinggal di sisi yang menerima. Jika mesin sumber kosong, lihat server tujuan dan sisi DC.

4.4. Keluarga 4720 — pembuatan, perubahan, dan penambahan ke grup

Peristiwa manajemen akun membentuk deretan nomor yang berdekatan: 4720 (akun pengguna dibuat)17, 4726 (dihapus), 4738 (diubah), dan, di sisi grup, anggota ditambah/dihapus. Catat bahwa ID peristiwa mana yang muncul untuk perubahan keanggotaan grup bergantung pada jenis grup. Itu 4732/4733 untuk grup lokal, 4728/4729 untuk grup global, dan 4756/4757 untuk grup universal.14 Domain Admins adalah grup global, jadi penambahan ke dalamnya muncul sebagai 4728 — jika Anda hanya memberi peringatan pada 4732, Anda justru melewatkan peristiwa yang paling ingin ditangkap. Sehari-hari ini sebagian besar adalah rekaman pekerjaan help desk, tetapi “pengguna standar tiba-tiba ditambahkan ke grup administratif” atau “akun yang tidak dikenal siapa pun baru saja dibuat” layak diselidiki bahkan sebagai kejadian tunggal. Microsoft sendiri memberi penambahan anggota yang tidak terduga ke grup istimewa sebagai contoh peristiwa yang layak diberi peringatan secara individual.3

Jenis grup dan peristiwa penambahan anggotaPenambahan anggota ke grup memakai ID peristiwa yang berbeda menurut jenis grup: lokal 4732, global 4728, universal 4756, jadi penambahan ke Domain Admins yang merupakan grup global dilihat di 4728LokalGlobalUniversalPenambahan anggota ke grupJenis grupnya?Terekam di 4732Terekam di 4728Terekam di 4756Penambahan ke Domain Admins ada di siniMemantau hanya 4732 akan terlewat

Gambar 10: ID peristiwa penambahan anggota terpecah menurut jenis grup. Penambahan ke Domain Admins adalah 4728.

4.5. 4688 — pembuatan proses. Pencatatan baris perintah adalah sakelar terpisah

4688, “A new process has been created,” merekam akun pembuat, jalur berkas eksekusi proses baru, proses induk, dan tipe peningkatan token setiap kali sebuah proses dibuat.11 Ini peristiwa dengan nilai investigasi tinggi yang dapat menjawab “siapa yang menjalankan apa di server ini.”

Namun secara default, argumen baris perintah tidak terekam. Hanya setelah Anda secara terpisah mengaktifkan pengaturan Group Policy “Include command line in process creation events” (Administrative Templates > System > Audit Process Creation) bidang “Process Command Line” di 4688 terisi dengan argumen.1112 Ini pada praktiknya esensial untuk menelusuri peluncuran mencurigakan seperti powershell -EncodedCommand ..., tetapi aktifkan hanya setelah memahami risiko paparan rahasia yang diuraikan di bab 7.

Hubungan 4688 dan pencatatan baris perintahMengaktifkan audit pembuatan proses merekam akun, jalur berkas eksekusi, dan proses induk di 4688, tetapi argumen baris perintah baru terekam setelah Group Policy terpisah diaktifkan, dengan risiko rahasia muncul dalam teks biasaBiarkan defaultAktifkan GPO tambahanAktifkan audit pembuatan proses4688 terekamAkun, jalur, proses indukIngin melihat argumen juga?Baris perintah kosongArgumen terekamRisiko rahasia muncul dalam teks biasa

Gambar 11: Pencatatan baris perintah 4688 adalah sakelar terpisah. Periksa risiko tercampurnya rahasia sebelum mengaktifkannya.

4.6. 4698 — pembuatan tugas terjadwal

4698, “A scheduled task was created,” merekam nama tugas dan seluruh XML definisi tugas (termasuk perintah yang dijalankan). Karena mendaftarkan tugas terjadwal adalah teknik umum yang dipakai malware untuk tetap hidup setelah boot ulang, Microsoft merekomendasikan memantau peristiwa pembuatan tugas.15 Bahkan di lingkungan yang memakai tugas terjadwal secara intensif untuk keperluan bisnis, pembuatan itu sendiri bukan sesuatu yang terjadi setiap hari, jadi tingkat deraunya relatif kecil.

Persistensi lewat pendaftaran tugas dan 4698Malware biasa mendaftarkan tugas terjadwal agar tetap hidup setelah boot ulang, jadi memantau 4698 yang terekam saat tugas dibuat memungkinkan Anda menelusuri sampai definisi tugas termasuk perintah yang dijalankanPersistensi malwareDaftar tugas agar tetap hidup4698 terekamSeluruh XML termasuk perintah yang dijalankanDeteksi dengan memantau pembuatan tugasPembuatan tidak harian, derau kecil

Gambar 12: Pendaftaran tugas, teknik persistensi yang biasa, tertinggal di 4698. Seluruh XML definisi memungkinkan Anda menelusuri sampai perintah yang dijalankan.

Satu lagi yang layak diingat adalah 1102, “The audit log was cleared.” Mengosongkan log Security selalu meninggalkan peristiwa ini, jadi jika Anda menemukan “log-nya kosong,” ia memungkinkan Anda membedakan insiden dari operasi rutin.18

Memilah penghapusan log lewat 1102Mengosongkan log Security selalu meninggalkan 1102, jadi ketika log kosong Anda dapat memilah apakah itu operasi penghapusan atau insiden dengan memeriksa ada tidaknya 1102AdaTidak adaLog dalam keadaan kosongPengosongan selalu meninggalkan 1102Ada 1102?Ada operasi penghapusanCurigai kemungkinan insiden

Gambar 13: Mengosongkan log Security selalu meninggalkan 1102. Log kosong dipilah sebagai insiden atau operasi menurut ada tidaknya 1102.

5. Merancang wadah log — ukuran maksimum dan retensi

Sebelum menambah kebijakan audit, periksa wadah penerimanya. Log Security punya ukuran maksimum dan mode retensi: dalam mode timpa (konfigurasi yang lazim), begitu ukuran maksimum tercapai, peristiwa baru menimpa yang tertua. Sebaliknya, dalam mode retensi (jangan-timpa), begitu log penuh, peristiwa barulah yang dibuang.10 Kedua perilaku dapat meninggalkan Anda dengan “log yang saya butuhkan justru tidak ada,” jadi memahami keadaan saat ini datang lebih dulu.

# Periksa wadah log Security: mode retensi, ukuran maksimum, jumlah rekaman saat ini
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# Berapa hari yang benar-benar tertahan saat ini (stempel waktu peristiwa tertua)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog mengembalikan konfigurasi log dan jumlah rekaman bersama-sama.9 Selisih antara “stempel waktu peristiwa tertua” dan waktu sekarang adalah periode retensi aktual; jika itu kurang dari persyaratan Anda (berapa hari ke belakang yang ingin dapat Anda selidiki), perbesar ukuran maksimum. Anda dapat mengonfigurasinya dengan wevtutil sl Security /ms:<jumlah byte>, atau menyebarkannya lewat Group Policy.10

Desain kapasitas yang dihitung mundur dari hari retensiPeriksa konfigurasi dan jumlah dengan ListLog Get-WinEvent, hitung hari retensi aktual dari stempel waktu peristiwa tertua, dan perbesar ukuran maksimum jika tidak cukup untuk jumlah hari yang ingin ditelusuri dalam investigasi insidenCukupTidak cukupPeriksa konfigurasi dan jumlah dengan ListLogPeriksa stempel waktu peristiwa tertuaHitung hari retensi aktualCukup untuk persyaratan?Pertahankan ukuran saat iniPerbesar ukuran maksimumAtur dengan wevtutil sl atau GPO

Gambar 14: Pastikan berapa hari yang benar-benar tersisa, lalu tentukan ukuran maksimum dengan menghitung mundur dari jumlah hari yang ingin ditelusuri.

Ada juga opsi keamanan bernama “Audit: Shut down system immediately if unable to log security audits” (umum dikenal sebagai CrashOnAuditFail). Ketika aktif, jika sistem menjadi tidak mampu merekam peristiwa audit, ia berhenti dengan STOP error C0000244. Ia ada untuk persyaratan autentikasi yang sama sekali tidak boleh kehilangan jejak audit, dan secara default dinonaktifkan. Microsoft sendiri memperingatkan bahwa ini dapat diubah menjadi DoS, dengan penyerang sengaja menghasilkan banjir peristiwa untuk menghentikan server — jadi ini bukan sesuatu yang diaktifkan begitu saja di lingkungan skala kecil-menengah yang lazim.19

Perilaku ketika log penuhKonfigurasi retensi ada dua, mode timpa dan mode jangan-timpa, dan ketika audit tidak dapat direkam dalam mode jangan-timpa, jika CrashOnAuditFail yang merupakan pengaturan terpisah aktif, sistem berhenti dengan STOP error C0000244Mode timpaJangan timpaYaLog Security mencapai ukuran maksimumKonfigurasi retensinya?Peristiwa tertua ditimpaPeristiwa baru dibuangKeduanya penyebab log hilang tanpa disadariCrashOnAuditFail juga aktif?Berhenti dengan STOP error C0000244

Gambar 15: Konfigurasi retensi ada dua: timpa atau buang. CrashOnAuditFail adalah pengaturan terpisah yang menghentikan sistem ketika rekaman tidak mungkin.

6. Investigasi di lapangan — filter, Get-WinEvent, dan ekspor

6.1. Menyempitkan di Event Viewer

Untuk investigasi sekali, Event Viewer sudah cukup. Buka log Security dan tentukan ID peristiwa (misalnya 4625) serta rentang waktu dengan “Filter Current Log.” Simpan kondisi yang Anda periksa berulang sebagai “Custom View” agar tinggal satu klik lain kali. Jika Anda ingin menyempitkan menurut akun tertentu, bukan hanya ID peristiwa, Anda dapat menyunting kueri XPath secara langsung di tab XML dialog filter.

6.2. Ekstraksi dengan Get-WinEvent

Untuk investigasi dengan jumlah rekaman besar, banyak kondisi, atau jalan berkala, beralihlah ke Get-WinEvent PowerShell. Poin kuncinya adalah memakai -FilterHashtable, yang menerapkan filter di sisi server.9

Memilih sarana investigasiInvestigasi sekali cukup dengan filter Event Viewer, kondisi yang dilihat berulang disimpan sebagai Custom View, dan investigasi dengan jumlah besar, banyak kondisi, atau jadwal berkala dialihkan ke Get-WinEventSekaliKondisi yang dilihat berulangVolume besar, banyak kondisi, berkalaInvestigasi seperti apa?Saring di Event ViewerSimpan sebagai Custom ViewBeralih ke Get-WinEventSaring dengan FilterHashtable

Gambar 16: Sekali pakai Event Viewer, berulang simpan Custom View, jumlah besar pakai Get-WinEvent.

# Ambil kegagalan sign-in (4625) dari 24 jam terakhir
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Bentuk "siapa, dari mana, dan mengapa" menjadi tabel
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Begitu Anda punya pola menarik EventData dari representasi XML peristiwa, Anda dapat memakainya ulang apa adanya untuk 4624 atau 4688. Desain penyaringan Get-WinEvent — kapan memakai FilterHashtable versus XPath, dan cara memperbaiki kueri yang lambat — dibahas mendalam di “Investigasi log peristiwa di lapangan dengan Get-WinEvent — kecepatan penyaringan menentukan lama investigasi.”

Pola membentuk tabel dengan menarik EventDataPola mengubah peristiwa yang diperoleh dengan Get-WinEvent ke representasi XML, menarik setiap bidang EventData, dan membentuknya menjadi tabel dapat dipakai ulang dengan cara yang sama untuk 4624 atau 4688, tidak hanya 4625Ambil dengan Get-WinEventUbah peristiwa ke representasi XMLTarik EventDataBentuk tabel dan agregasikanCara yang sama untuk 4624 atau 4688

Gambar 17: Pola menarik EventData dari representasi XML dan membentuknya menjadi tabel dapat dipakai ulang meski ID peristiwa berubah.

6.3. Mengekspor dengan wevtutil

Aturan untuk log di mesin yang diselidiki adalah ekspor dan amankan salinan lebih dulu, sebelum tertimpa.10

rem amankan seluruh log Security sebagai evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem ekspor hanya peristiwa 4625, disempitkan dengan XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Berkas .evtx yang diekspor dapat dianalisis di mesin lain dengan cara yang sama persis, dengan Get-WinEvent -Path C:\logs\security-20260801.evtx.9 Kebiasaan mengamankan sebelum menganalisis adalah pola pikir yang sama dengan “amankan dump lebih dulu” saat investigasi crash (lihat “Pengantar pengumpulan crash dump Windows - WER/ProcDump/WinDbg”).

Alur mengamankan dulu, lalu menganalisisEkspor log Security mesin yang diselidiki ke berkas evtx dengan wevtutil epl untuk mengamankannya, lalu analisis dengan cara yang sama di mesin lain lewat Path Get-WinEventMesin yang diselidikiAmankan ke evtx dengan wevtutil eplBawa ke mesin lainAnalisis dengan Get-WinEvent -PathAmankan sebelum hilang karena ditimpa

Gambar 18: Amankan dulu, baru analisis. Jika sudah dipegang sebagai evtx, Anda dapat memeriksanya dengan cara yang sama di mesin lain.

7. Jebakan — empat yang mudah terinjak di lapangan

(1) Rahasia berakhir di baris perintah 4688. Mengaktifkan pencatatan baris perintah memasukkan argumen setiap proses ke log Security dalam teks biasa. Microsoft menyatakan secara eksplisit bahwa “setiap pengguna dengan akses baca ke peristiwa keamanan akan dapat membaca argumen baris perintah untuk setiap proses yang berhasil dibuat. Argumen baris perintah dapat berisi informasi sensitif atau privat seperti kata sandi.” 12 Jika ada satu saja aplikasi bisnis atau skrip yang meluncurkan sesuatu seperti myapp.exe /user:admin /password:P@ssw0rd, itu adalah rahasia yang diungkapkan kepada semua orang yang dapat melihat log. Sebelum mengaktifkan ini, audit tempat yang meneruskan rahasia sebagai argumen baris perintah dan perbaiki. Tempat tujuan ekspor atau penerusan log juga perlu ditangani pada tingkat kerahasiaan yang sama.

Urutan mengaktifkan pencatatan baris perintahPencatatan baris perintah 4688 harus diaktifkan setelah Anda menginventarisasi aplikasi bisnis dan skrip yang meneruskan rahasia sebagai argumen dan memperbaiki tempat yang relevan, dan tujuan pengamanan serta penerusan log juga harus diberi tingkat penanganan yang samaAdaTidak adaInventarisasi penerusan rahasia sebagai argumenAda yang relevan?Perbaiki tempat yang meneruskannyaAktifkan pencatatan baris perintahTujuan pengamanan dan penerusan dengan tingkat yang sama

Gambar 19: Pencatatan baris perintah adalah “inventarisasi, perbaiki, baru aktifkan”. Membalik urutannya menjadi pengungkapan rahasia.

(2) Beroperasi tanpa tahu apa yang terjadi ketika log penuh. Dalam mode timpa, bukti lama hilang diam-diam; dalam mode jangan-timpa, peristiwa baru dibuang; dan dengan CrashOnAuditFail aktif, seluruh sistem berhenti (bab 5).1019 Pendekatan yang benar adalah mengetahui perilaku mana yang Anda pilih, dan menempatkan mekanisme — ekspor terjadwal, atau platform pengumpulan log — yang mengumpulkan data sebelum tertimpa.

(3) Domain controller dan workstation mengharuskan Anda melihat log yang berbeda. 4624/4625 terekam di mesin yang diakses.56 Validasi kredensial untuk akun domain (4776 NTLM), di sisi lain, terekam di mesin yang punya otoritas atas kredensial — untuk akun domain, itu DC7 — dan kegagalan pra-autentikasi Kerberos (4771) terekam hanya di DC.8 “Tidak ada 4625 di file server” tidak berarti “tidak ada serangan”; Anda baru mendapat gambaran utuh setelah juga mencocokkan 4776/4771 di DC. Lihat “NTLM dan Kerberos dijelaskan dengan diagram” untuk bagaimana setiap protokol autentikasi benar-benar mengalir.

(4) Pergeseran jam merusak korelasi. Menyusun log dari beberapa mesin untuk menelusuri “workstation mana yang menghasilkan 4625 tepat sebelum 4740 ini” hanya bekerja jika jam setiap mesin selaras. Di lingkungan domain, Kerberos sendiri memberlakukan batas atas pada pergeseran jam (5 menit secara default), di luar itu autentikasi itu sendiri mulai gagal.20 Dari sudut pandang investigasi, pergeseran beberapa detik saja — apalagi lima menit — dapat membuat Anda salah membaca urutan peristiwa, jadi memeriksa status sinkronisasi w32time harus menjadi langkah paling awal prosedur investigasi. Ingat juga bahwa stempel waktu peristiwa disimpan dalam UTC dan ditampilkan menurut zona waktu mesin yang melihat, jadi ingat untuk mengonversi zona waktu ketika membaca .evtx yang dibawa pulang dari situs luar negeri atau server yang dikonfigurasi untuk UTC.

Prasyarat sinkronisasi waktu dan investigasi pencocokanInvestigasi yang mencocokkan log beberapa mesin menurut urutan waktu mengasumsikan jam setiap mesin selaras, selisih beberapa detik pun dapat membuat urutan sebelum-sesudah salah dibaca, dan selisih melebihi default 5 menit membuat autentikasi Kerberos itu sendiri gagal, jadi masukkan pemeriksaan sinkronisasi w32time di awal prosedur investigasiSelarasSelisih beberapa detikMelebihi default 5 menitMencocokkan log beberapa mesinPrasyarat: jam-jamnya selarasSelisih jamnya?Dapat ditelusuri menurut waktuUrutan sebelum-sesudah salah dibacaAutentikasi Kerberos gagalPeriksa w32time di awal prosedur

Gambar 20: Mencocokkan beberapa mesin mengasumsikan jam yang selaras. Selisih beberapa detik pun dapat membuat urutan sebelum-sesudah salah dibaca.

8. Ringkasan

  • Kebijakan audit punya dua sistem, “dasar” dan “lanjutan,” dan mencampurnya menghasilkan hasil yang tidak terduga. Satukan di sisi lanjutan, periksa keadaan saat ini dengan auditpol /get /category:*, dan rancang dari situ.
  • “Aktifkan semuanya” membunuh investigasi lewat derau dan pembengkakan. Mulai dari rekomendasi baseline Microsoft dan kerjakan tabel keputusan di bab 3, yang berporos pada logon, manajemen akun, dan pembuatan proses.
  • 4624 dibaca menurut tipe logon, 4625 menurut kode Status/Sub Status, 4740 menurut Caller Computer Name, dan 4688 menurut proses induk dan baris perintah — setiap peristiwa punya bidang spesifik yang perlu diperiksa.
  • Wadah log (ukuran maksimum dan mode retensi) adalah separuh desain audit. Periksa berapa hari yang benar-benar tertahan, ukur dengan menghitung mundur dari persyaratan, dan ekspor atau kumpulkan sebelum tertimpa.
  • Audit risiko paparan rahasia sebelum mengaktifkan pencatatan baris perintah untuk 4688. Tempat setiap peristiwa terekam, dan sinkronisasi jam, adalah prasyarat untuk korelasi lintas mesin.
  • Mulai investigasi dengan filter Event Viewer; beralih ke Get-WinEvent -FilterHashtable untuk apa pun yang berulang; amankan dengan wevtutil epl. Jangan pernah mematahkan urutan “amankan dulu, baru analisis.”

Artikel terkait

Area konsultasi terkait

KomuraSoft LLC menangani konsultasi tentang kebijakan audit Windows dan desain log, investigasi “kapan, siapa, dan apa” berdasarkan log peristiwa, dan analisis akar masalah gangguan terkait autentikasi dan audit yang dialami aplikasi bisnis. Tidak apa-apa memulai dari tahap “saya disuruh melihat log, tetapi tidak tahu harus mulai dari mana.”

Tautan referensi

  1. Microsoft Learn, Advanced security auditing FAQ. Tentang perbedaan antara kebijakan audit dasar (sembilan pengaturan di bawah Local Policies) dan kebijakan audit lanjutan; tentang mengaktifkan satu kategori dasar setara dengan mengaktifkan semua subkategori yang berkorespondensi; tentang kedua sistem tidak kompatibel, dan memakai keduanya meninggalkan hasil audit dalam keadaan tidak terduga sehingga tidak boleh dicampur; tentang menerapkan sisi lanjutan lewat Group Policy mengosongkan pengaturan audit yang ada; tentang perlunya mengaktifkan “Audit: Force audit policy subcategory settings to override audit policy category settings”; dan tentang meminimalkan volume peristiwa dengan mengidentifikasi dan membatasi ke sumber daya, aktivitas, dan pengguna yang penting. ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, auditpol. Tentang perintah auditpol yang dapat menampilkan (/get), mengatur (/set), mencadangkan ke CSV (/backup), memulihkan (/restore), dan mengosongkan (/clear) kebijakan audit sistem. ↩ ↩2

  3. Microsoft Learn, System Audit Policy recommendations. Tentang tabel nilai default Windows, rekomendasi baseline, dan rekomendasi yang lebih kuat yang dipecah menurut workstation dan server; tentang rekomendasi itu hanya titik berangkat, yang harus ditinjau dan diuji terhadap ancaman dan toleransi risiko setiap organisasi; tentang subkategori Logon yang mengaktifkan keberhasilan dan kegagalan secara default sejak Windows 10 1809; tentang memantau workstation sama pentingnya dengan memantau server; tentang contoh peristiwa yang layak diberi peringatan secara individual, seperti penambahan anggota yang tidak terduga ke grup istimewa; dan tentang mendeteksi lonjakan logon gagal dengan membandingkannya terhadap baseline. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Tentang dapat mengelola audit secara presisi di lebih dari 40 subkategori audit; tentang membiarkan pengaturan ini aktif adalah praktik terbaik, dengan nilai default Enabled untuk klien, member server, dan DC; dan tentang peringatan bahwa pengaturan yang menghasilkan volume peristiwa besar, seperti mengaktifkan audit keberhasilan untuk seluruh subkategori pemakaian hak istimewa, membuat entri lain sulit ditemukan di log keamanan dan dapat berdampak signifikan pada kinerja. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, 4624(S): An account was successfully logged on. Tentang 4624 terekam di mesin yang diakses pada saat sesi logon dibuat; tentang daftar tipe logon (2 = Interactive, 3 = Network, 4 = Batch, 5 = Service, 7 = Unlock, 8 = NetworkCleartext, 9 = NewCredentials, 10 = RemoteInteractive, 11 = CachedInteractive); tentang bendera Elevated Token; tentang Authentication Package (NTLM/Kerberos/Negotiate) dan Package Name NTLM (NTLM V1/V2/LM); dan tentang mengkorelasikan lewat Logon ID dengan peristiwa seperti 4672. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, 4625(F): An account failed to log on. Tentang 4625 terekam di komputer tempat percobaan logon terjadi (untuk percobaan di workstation pengguna, workstation itu); tentang subkategorinya adalah Account Lockout dan Logon; tentang arti kode Status/Sub Status (0xC0000064 = nama pengguna buruk, 0xC000006A = kata sandi salah, 0xC000006D = nama pengguna atau informasi autentikasi buruk, 0xC000006F = di luar jam logon yang diizinkan, 0xC0000070 = workstation tidak diizinkan, 0xC0000072 = akun dinonaktifkan, 0xC000015B = tipe logon tidak diizinkan, 0xC0000193 = akun kedaluwarsa, 0xC0000234 = di-lockout); dan tentang kemunculan berulang 0xC0000064 yang dapat menandai serangan enumerasi akun. ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. Tentang 4776 terekam untuk setiap validasi kredensial yang dilakukan untuk autentikasi NTLM; tentang ia terekam hanya di komputer yang punya otoritas atas kredensial — domain controller untuk akun domain, atau komputer lokal untuk akun lokal; dan tentang baik keberhasilan maupun kegagalan terekam. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, 4771(F): Kerberos pre-authentication failed. Tentang 4771 terekam untuk setiap kegagalan KDC menerbitkan TGT Kerberos (kata sandi salah, kedaluwarsa, dll.); dan tentang peristiwa ini hanya dihasilkan di domain controller. ↩ ↩2 ↩3 ↩4

  9. Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). Tentang mengambil konfigurasi log (LogMode, MaximumSizeInBytes, RecordCount) lewat -ListLog; tentang penyaringan efisien lewat -FilterHashtable yang ditentukan sebagai hashtable LogName, Id, StartTime, dan seterusnya; tentang membaca berkas .evtx yang disimpan lewat -Path; dan tentang mengambil peristiwa tertua-dulu dan menurut jumlah lewat -Oldest / -MaxEvents. ↩ ↩2 ↩3 ↩4

  10. Microsoft Learn, wevtutil. Tentang mengatur ukuran maksimum (/ms) dan mode retensi (/rt) lewat set-log (sl); tentang mode retensi true berarti peristiwa yang ada ditahan dan peristiwa baru dibuang begitu log penuh, sementara false berarti peristiwa baru menimpa yang tertua yang ada; tentang mengekspor log peristiwa ke berkas lewat export-log (epl), dengan opsi /q untuk menyempitkan menurut kueri XPath; dan tentang menjalankan kueri lewat query-events (qe). ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4688(S): A new process has been created. Tentang 4688 terekam untuk setiap mulai proses baru; tentang ia mencakup akun pembuat, jalur berkas eksekusi proses baru, nama proses pembuat (induk), dan tipe peningkatan token; dan tentang bidang Process Command Line kosong secara default, terisi hanya setelah pengaturan Group Policy “Include command line in process creation events” diaktifkan. ↩ ↩2 ↩3

  12. Microsoft Learn, Command line process auditing. Tentang pencatatan baris perintah mensyaratkan baik audit pembuatan proses di kebijakan audit lanjutan maupun “Include command line in process creation events” (Administrative Templates > System > Audit Process Creation, tidak dikonfigurasi secara default); tentang peringatan bahwa, setelah aktif, informasi baris perintah setiap proses terekam ke log peristiwa keamanan dalam teks biasa, dan setiap pengguna dengan akses baca ke peristiwa keamanan akan dapat membaca argumen baris perintah untuk setiap proses yang berhasil dibuat, yang dapat berisi informasi sensitif seperti kata sandi; dan tentang kebijakan audit lanjutan yang ditimpa oleh pengaturan dasar menghasilkan peristiwa 4719, yang dicegah oleh pengaturan “force”. ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Audit Account Lockout. Tentang subkategori Account Lockout yang mengaudit percobaan logon gagal terhadap akun yang sedang di-lockout; tentang peristiwa yang dihasilkan adalah 4625(F); tentang subkategori ini tidak punya peristiwa keberhasilan, jadi mengaktifkan audit keberhasilan untuknya tidak berguna; dan tentang audit kegagalan direkomendasikan di semua jenis komputer. ↩

  14. Microsoft Learn, Audit Security Group Management. Tentang subkategori ini mengaudit pembuatan, perubahan, dan penghapusan grup keamanan, serta penambahan dan penghapusan anggota; tentang ID peristiwa penambahan/penghapusan anggota berbeda menurut jenis grup — 4732/4733 untuk grup lokal, 4728/4729 untuk grup global, dan 4756/4757 untuk grup universal; tentang ada peristiwa khusus untuk grup domain seperti 4728; dan tentang subkategori ini tidak punya peristiwa kegagalan, jadi audit keberhasilan direkomendasikan di semua jenis komputer. ↩ ↩2

  15. Microsoft Learn, 4698(S): A scheduled task was created. Tentang 4698 terekam untuk setiap tugas terjadwal yang dibuat; tentang subkategorinya adalah Other Object Access Events; tentang ia merekam nama tugas dan seluruh XML definisi tugas, termasuk perintah yang dijalankan; dan tentang memantau peristiwa pembuatan tugas, terutama di mesin penting, direkomendasikan karena malware biasa memakai tugas terjadwal untuk persistensi lintas boot ulang. ↩ ↩2

  16. Microsoft Learn, 4740(S): A user account was locked out. Tentang 4740 terekam untuk setiap lockout akun pengguna; tentang subkategorinya adalah User Account Management; dan tentang bidang Caller Computer Name merekam nama komputer yang menjadi asal percobaan logon yang menyebabkan lockout. ↩

  17. Microsoft Learn, 4720(S): A user account was created. Tentang 4720 terekam di domain controller, member server, dan workstation untuk setiap objek pengguna baru yang dibuat; dan tentang subkategorinya adalah User Account Management. ↩

  18. Microsoft Learn, 1102(S): The audit log was cleared. Tentang peristiwa 1102 terekam untuk setiap pengosongan log audit keamanan Windows. ↩

  19. Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. Tentang sistem berhenti dengan pesan STOP C0000244 {Audit Failed} jika pengaturan ini aktif dan audit keamanan tidak dapat dicatat; tentang nilai default adalah Disabled; tentang ini berpotensi diubah menjadi DoS lewat penghasilan volume besar peristiwa keamanan secara sengaja untuk memaksa shutdown; dan tentang risiko data aplikasi menjadi tidak dapat dipakai akibat berhenti mendadak. ↩ ↩2

  20. Microsoft Learn, Maximum tolerance for computer clock synchronization. Tentang Kerberos v5 memakai stempel waktu sebagai pertahanan terhadap serangan replay, itulah sebabnya toleransi maksimum (5 menit baik sebagai default maupun rekomendasi) ditetapkan untuk pergeseran jam antara klien dan domain controller, di luar itu stempel waktu tidak lagi dianggap otentik. ↩

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Kami belum mengatur kebijakan audit apa pun, jadi mengapa 4624 dan 4625 sudah muncul di log Security?
Karena Windows punya subkategori audit yang aktif secara default. Subkategori "Logon", misalnya, sejak Windows 10 versi 1809 sudah mengaktifkan audit keberhasilan dan kegagalan secara default, jadi 4624 (berhasil) dan 4625 (gagal) terekam meski Anda belum mengatur apa pun sendiri. Dengan default dibiarkan apa adanya, banyak peristiwa yang sebenarnya Anda butuhkan saat investigasi — validasi kredensial (4776) atau pembuatan proses (4688), misalnya — tidak terekam. Anda dapat memeriksa apa yang aktif di lingkungan sendiri dengan `auditpol /get /category:*`. Dari situ, praktik bakunya adalah secara eksplisit mengaktifkan subkategori yang masih kurang di sisi kebijakan audit lanjutan.
Saya ingin menyelidiki kegagalan masuk, tetapi tidak menemukan peristiwa 4625 di log Security server sasaran. Ke mana saya harus melihat?
Pertama pastikan prinsip dasarnya: 4625 terekam di "komputer tempat logon dicoba". Untuk kegagalan masuk di workstation pengguna, itu workstation-nya; untuk kegagalan akses ke file server, itu file server-nya. Berikutnya, pakai `auditpol /get /category:*` untuk memeriksa apakah audit kegagalan aktif untuk subkategori "Logon". Untuk akun domain, jejaknya sering justru muncul sebagai validasi kredensial (4776) atau kegagalan pra-autentikasi Kerberos (4771) di domain controller, dan ketika Anda tidak dapat menentukan workstation mana yang terlibat, sering lebih cepat memulai dari sisi DC. Jika masih tidak ketemu, periksa apakah peristiwa lama sudah tertimpa (bandingkan ukuran maksimum log dengan stempel waktu peristiwa tertua).
Haruskah kita mengaktifkan pencatatan baris perintah untuk pembuatan proses (4688)?
Nilai investigasinya sangat tinggi, tetapi ini pengaturan yang hanya boleh diaktifkan setelah Anda memahami risikonya. Setelah aktif, argumen baris perintah setiap proses terekam di log Security dalam teks biasa. Jika ada satu saja skrip atau aplikasi bisnis yang meneruskan kata sandi atau kunci API sebagai argumen baris perintah, rahasia itu menjadi terlihat oleh semua orang yang dapat membaca log Security. Microsoft sendiri menuliskan peringatan ini secara eksplisit. Urutan yang disarankan adalah pertama-tama memeriksa apakah skrip Anda meneruskan rahasia sebagai argumen baris perintah, memperbaiki yang melakukannya, dan baru kemudian mengaktifkan pengaturan itu.
Seberapa besar seharusnya ukuran maksimum log Security?
Pendekatan yang benar adalah menghitung mundur dari "berapa hari yang ingin kita simpan di tangan", bukan memilih satu angka yang berlaku untuk semua. Pengaturan saat ini dan perilaku aktualnya dapat diperiksa dengan `Get-WinEvent -ListLog Security`; selisih antara stempel waktu peristiwa tertua dan waktu sekarang adalah "berapa hari yang benar-benar tertahan saat ini". Menambah subkategori audit meningkatkan volume peristiwa, jadi selalu periksa ulang rentang retensi aktual ini setelah mengubah pengaturan. Respons insiden tidak jarang membutuhkan log dari minggu atau bulan sebelumnya, jadi lebih aman mengekspor log secara berkala sebelum tertimpa, atau mengumpulkannya ke mesin terpisah dengan mekanisme pengumpulan log.
Bagaimana cara menyelidiki penyebab lockout akun (4740)?
Petunjuk pertama adalah bidang "Caller Computer Name" di peristiwa 4740. Ia merekam komputer yang menjadi asal percobaan logon gagal yang memicu lockout. Catat, walaupun, bahwa rekaman kegagalan itu sendiri (4625) tertinggal di sisi yang menerima percobaan logon, bukan di mesin asal. Jika asalnya logon jaringan, telusuri secara kronologis lewat 4625 di server tujuan, atau, untuk akun domain, lewat 4776/4771 di domain controller. Setelah mesin asal teridentifikasi, periksa di situ apa pun yang masih menyimpan kredensial lama dari sebelum perubahan kata sandi — kredensial tersimpan, sesi Remote Desktop yang dibiarkan terputus, atau layanan atau tugas terjadwal yang dikonfigurasi dengan kata sandi lama. Jika lockout terus berulang, periksa juga apakah sinkronisasi jam sudah bergeser.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.

Hubungi kami
Kembali ke blog