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

“Sejak tadi malam sebuah akun terus di-lockout. Tolong cari tahu penyebabnya.” “Cek apakah ada yang mencoba masuk memakai akun karyawan yang sudah keluar.” “Di server ini, kapan, siapa, menjalankan apa — bisakah diketahui?” — permintaan yang suatu hari tiba-tiba diterima staf TI di usaha kecil dan menengah, atau pengembang yang sudah menyerahkan sistem ke pelanggan. Pegangan yang diandalkan saat itu adalah log peristiwa Security Windows.

Begitu Event Viewer dibuka, dua kenyataan menunggu. Peristiwa yang ingin dilihat tidak terekam (kebijakan audit tidak aktif), atau terkubur di tumpukan peristiwa yang tidak terbaca (penuh noise dan membengkak). Audit keamanan memang “bisa terekam jika diaktifkan”, tetapi tanpa merancang apa yang direkam dan sampai sejauh mana, ia tidak menolong saat benar-benar dibutuhkan.

flowchart TB
    accTitle: Dua kenyataan yang menunggu di Event Viewer
    accDescr: Ketika Event Viewer dibuka, ada dua kenyataan: peristiwa yang ingin dilihat tidak terekam karena kebijakan audit tidak aktif, atau log membengkak penuh noise sehingga peristiwa terkubur dan tidak dapat dibaca, sehingga perlu merancang apa yang direkam dan sampai sejauh mana
    open["Membuka Event Viewer"] --> real{"Kenyataan yang menunggu?"}
    real -->|Tidak terekam| none["Peristiwa yang ingin dilihat tidak terekam"]
    real -->|Terkubur| noise["Tidak terbaca karena peristiwa terlalu banyak"]
    none -.-> cause1["Kebijakan audit nonaktif"]
    noise -.-> cause2["Membengkak penuh noise"]
    none --> design["Rancang apa yang direkam dan sampai sejauh mana"]
    noise --> design

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

Artikel ini menata mekanisme kebijakan audit (dua sistem — dasar dan lanjutan), subkategori yang setidaknya perlu diaktifkan di lingkungan skala kecil-menengah, cara membaca event ID andalan seperti 4624/4625/4740/4688, desain kapasitas log Security, dan cara menyelidiki dengan PowerShell, berdasarkan sumber primer per Agustus 2026. Jika artikel audit NTLM, SMB signing, BitLocker, dan firewall yang telah dibahas di situs ini adalah soal “memperkuat pertahanan”, artikel ini adalah soal “membuat apa yang terjadi dapat dikonfirmasi belakangan” — kelanjutan yang mengikat semuanya.

1. Kesimpulan lebih dulu

• Kebijakan audit punya dua sistem — “dasar” dan “lanjutan (Advanced Audit Policy)” — dan keduanya tidak boleh dicampur. Microsoft menyatakan secara eksplisit bahwa memakai keduanya membuat hasil audit berada dalam keadaan tidak terduga. Satukan di sisi lanjutan (lebih dari 40 subkategori).¹
• Keadaan saat ini dicek dengan auditpol /get /category:*. Perintah ini mendaftar pengaturan audit yang sedang berlaku, terlepas dari apakah berasal dari GPO atau pengaturan lokal.²
• “Aktifkan semuanya” tidak boleh dilakukan. Mengaktifkan subkategori yang menghasilkan volume peristiwa besar mengubur peristiwa yang penting di bawah noise, dan memengaruhi kinerja. Mulai dari rekomendasi baseline Microsoft, lalu hanya tambahkan yang dibutuhkan.³⁴
• Masuk yang berhasil adalah 4624; yang gagal adalah 4625. Pada 4624, jenis masuk dibaca dari logon type (2 = Interactive, 3 = Network, 10 = RemoteInteractive, dan seterusnya).⁵
• Pada 4625, kode Status/Sub Status memberi tahu alasan kegagalan. Yang sering muncul: 0xC0000064 = nama pengguna tidak ada, 0xC000006A = kata sandi salah, 0xC0000072 = akun dinonaktifkan, 0xC0000234 = sedang lockout.⁶
• Mesin 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 kesimpulan keliru “tidak ada log”.⁶⁷⁸
• Separuh desain log Security adalah wadahnya — ukuran maksimum dan retensi. Jika retensi dalam mode overwrite, peristiwa lama hilang lebih dulu. Cek ukuran maksimum dan jumlah rekaman dengan Get-WinEvent -ListLog Security, lalu perbesar dengan menghitung mundur dari jumlah hari yang benar-benar perlu disimpan.⁹¹⁰
• Pencatatan command line untuk pembuatan proses (4688) kuat, tetapi harganya adalah rahasia yang mendarat di log dalam teks biasa. Audit skrip dulu sebelum mengaktifkannya.¹¹¹²

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 34, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

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

Kebijakan audit Windows datang dalam dua sistem.¹

• Kebijakan audit dasar: sembilan pengaturan kategori di “Local Policies > Audit Policy”. Ini sistem lama, dari sebelum Windows Vista.
• Advanced Audit Policy Configuration: lebih dari 40 pengaturan subkategori di “Security Settings > Advanced Audit Policy Configuration”. Setiap kategori dasar dipecah menjadi beberapa subkategori. Misalnya, satu kategori dasar “Audit account logon events” berkorespondensi dengan empat subkategori di sisi lanjutan. Mengaktifkan satu kategori dasar sama dengan mengaktifkan semua subkategori yang berkorespondensi, sehingga peristiwa yang tidak diminati pun terekam dalam volume besar.¹

Poin pentingnya: kedua sistem ini tidak kompatibel. Microsoft menyatakan dengan tegas: jangan memakai kebijakan audit dasar dan lanjutan sekaligus — hasil audit bisa berada dalam keadaan tidak terduga. Ketika kebijakan audit lanjutan diterapkan lewat Group Policy, pengaturan audit yang ada di komputer itu dikosongkan dulu, lalu pengaturan lanjutan diterapkan; setelah 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 menimpanya (di mesin mandiri ini aktif secara default).¹⁴

flowchart TB
    accTitle: Hubungan kebijakan audit dasar dan lanjutan
    accDescr: Kebijakan 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 dasar
    basic["Kebijakan audit dasar (9 kategori)"] --> both{"Memakai keduanya?"}
    adv["Kebijakan audit lanjutan (40+ subkategori)"] --> both
    both -->|Ya| bad["Hasil audit dalam keadaan tidak terduga"]
    both -->|Tidak| unify["Satukan di sisi lanjutan"]
    unify --> force["Aktifkan paksa pengaturan subkategori"]
    force -.-> guard["Cegah penimpaan oleh pengaturan sisi dasar"]

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

Cek keadaan saat ini cukup satu perintah, dijalankan dari command prompt administratif.²

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

rem cadangkan 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 berlaku sebagai hasil”, terlepas dari apakah berasal dari GPO atau pengaturan lokal. Berguna juga untuk mencocokkan ketika pengaturan yang semestinya disebar lewat GPO tampaknya tidak berlaku. Perubahan pada pengaturan audit itu sendiri terekam sebagai peristiwa 4719, jadi “audit dinonaktifkan tanpa ada yang sadar” pun dapat dilacak belakangan.¹²

flowchart TB
    accTitle: Yang terlihat di auditpol adalah kebijakan hasil
    accDescr: Keluaran 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 4719
    gpo["Pengaturan yang disebar lewat GPO"] --> eff["Kebijakan yang berlaku sebagai hasil"]
    local["Pengaturan lokal"] --> eff
    eff --> get["Daftar dengan auditpol /get"]
    get -.-> diff["Berguna untuk mencocokkan saat GPO tidak diterapkan"]
    change["Perubahan pengaturan audit itu sendiri"] -.-> e4719["4719 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 setidaknya perlu diaktifkan

Alasan “aktifkan saja semuanya” adalah langkah buruk sudah jelas. Misalnya, Microsoft memperingatkan bahwa mengaudit keberhasilan pada subkategori privilege use menghasilkan volume peristiwa begitu besar sehingga entri lain sulit ditemukan, dan kinerja ikut terpengaruh.⁴ Wadah log (bab 5) terbatas, jadi semakin banyak noise yang direkam, semakin terpangkas hari retensi peristiwa yang benar-benar dibutuhkan. Merancang audit berarti memutuskan apa yang tidak direkam.

flowchart TB
    accTitle: Mengapa mengaktifkan semuanya adalah langkah buruk
    accDescr: Mengaktifkan semua subkategori menghasilkan peristiwa dalam jumlah besar, peristiwa yang penting terkubur dalam noise, kinerja terpengaruh, dan di wadah log yang terbatas jumlah hari retensi peristiwa yang diperlukan juga terpangkas
    all["Aktifkan semua subkategori"] --> flood["Peristiwa dalam jumlah besar terjadi"]
    flood --> noise["Peristiwa penting terkubur"]
    flood --> perf["Dampak pada kinerja"]
    flood --> keep["Hari retensi terpangkas"]
    noise --> lesson["Merancang audit adalah memutuskan apa yang tidak direkam"]
    perf --> lesson
    keep --> lesson

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

Microsoft menerbitkan rekomendasi baseline dan rekomendasi yang lebih kuat, terpisah untuk workstation dan server, dan itu menjadi titik berangkat.³ Dari situ, tabel berikut disusun dari sudut pandang lingkungan skala kecil-menengah: “paling tidak, inilah yang ingin bisa dibaca saat insiden.”

Sebaliknya, pada umumnya paling aman tidak menyentuh audit object access untuk file system atau registry, privilege use, atau subkategori packet drop (5152 dan sejenisnya) secara default. Ini berguna jika disempitkan dengan SACL yang ditargetkan atau hanya selama periode isolasi masalah — bukan dibiarkan selalu terbuka di seluruh sistem, karena itu akan menghabiskan log.⁴

flowchart TB
    accTitle: Penanganan subkategori yang menghasilkan banyak peristiwa
    accDescr: Audit object access file system dan registry, privilege use, dan packet filter akan menghabiskan log jika dibiarkan selalu terbuka, jadi mereka berguna hanya dengan pengaturan SACL yang disempitkan atau selama periode isolasi terbatas
    heavy["Subkategori yang menghasilkan banyak peristiwa"] --> use{"Bagaimana mengaktifkannya?"}
    heavy -.-> ex1["Audit object access"]
    heavy -.-> ex2["Privilege use dan packet filter"]
    use -->|Selalu terbuka| eat["Menghabiskan log"]
    use -->|SACL yang disempitkan| ok1["Berguna"]
    use -->|Periode isolasi terbatas| ok2["Berguna"]

Gambar 5: Jangan biarkan object access atau privilege use selalu terbuka. Mereka berguna hanya jika sasaran dan periodenya disempitkan.

4. Cara membaca event ID andalan

4.1. 4624 — masuk berhasil dipilah menurut logon type

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

Bidang yang dicek bersamaan: nama akun di “New Logon”, alamat sumber di “Network Information”, “Authentication Package” (NTLM atau Kerberos), dan “Elevated Token” (apakah sesi punya hak administrator). Jika yang ingin dilacak hanya masuk dengan hak administrator, peristiwa 4672 (Special privileges assigned to new logon) yang terekam pada Logon ID yang sama juga berguna.⁵

flowchart TB
    accTitle: Langkah memilah pembacaan 4624
    accDescr: 4624 yang terekam dalam jumlah besar pertama-tama dipilah menurut logon type, lalu nama akun dan sumber, authentication package, dan Elevated Token diperiksa, dan masuk dengan hak administrator dicocokkan dengan 4672 pada Logon ID yang sama
    ev["4624 masuk berhasil"] --> type["Pilah menurut logon type"]
    type --> fields["Periksa bidang utama"]
    fields -.-> f1["Nama akun dan sumber"]
    fields -.-> f2["Authentication Package"]
    fields -.-> f3["Elevated Token"]
    fields --> admin["Melacak hak administrator"]
    admin -.-> e4672["4672 pada Logon ID yang sama"]

Gambar 6: 4624 dipilah menurut logon type, lalu bidangnya dibaca. Masuk 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.⁶ Alih-alih mengandalkan teks di bidang “Failure Reason”, cara andal adalah membaca kode heksadesimal Status/Sub Status. Yang sering muncul sebagai berikut.⁶

• 0xC0000064: Nama pengguna tidak ada. Rangkaian cepat dalam waktu singkat 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 yang diizinkan
• 0xC0000070: Dari workstation yang tidak diizinkan
• 0xC0000072: Akun dinonaktifkan oleh administrator (percobaan terhadap akun karyawan yang sudah keluar muncul di sini)
• 0xC000015B: Logon type yang diminta tidak diizinkan di mesin ini
• 0xC0000193: Akun kedaluwarsa
• 0xC0000234: Sedang lockout

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

flowchart TB
    accTitle: Alur memastikan alasan kegagalan 4625
    accDescr: Alasan kegagalan 4625 dipastikan dari kode heksadesimal Status/Sub Status, tanda serangan dibaca dari pola kode, lalu diidentifikasi dengan tiga poin: akun sasaran, sumber, dan kode
    ev["4625 masuk gagal"] --> code["Periksa kode Sub Status"]
    code --> sign{"Pola kodenya?"}
    sign -->|Rangkaian 0xC0000064| enum["Tanda enumerasi akun"]
    sign -->|Rangkaian 0xC000006A| guess["Tanda tebakan kata sandi"]
    sign -->|0xC0000072| disabled["Percobaan akun karyawan yang sudah keluar"]
    enum --> triple["Dipastikan dengan tiga poin"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["Akun 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 adalah “A user account was locked out” (subkategori: User Account Management). Bidang utamanya adalah “Caller Computer Name”, yang merekam komputer asal percobaan logon yang memicu lockout.¹⁶ Praktik bakunya: identifikasi mesin asal dari bidang ini, lalu telusuri kredensial lama yang masih tersisa di mesin itu. Dalam hampir semua kasus penyebabnya adalah sesuatu yang terus memakai kredensial lama setelah perubahan kata sandi — kredensial tersimpan, sesi RDP yang dibiarkan terputus, atau layanan atau task dengan kata sandi lama.

flowchart TB
    accTitle: Praktik baku investigasi lockout akun
    accDescr: Identifikasi mesin sumber dari Caller Computer Name di 4740, lalu telusuri kredensial lama yang tersisa di mesin itu: kredensial tersimpan, sesi RDP yang dibiarkan terputus, dan layanan atau task dengan kata sandi lama
    ev["4740 lockout terjadi"] --> caller["Periksa Caller Computer Name"]
    caller --> src["Identifikasi mesin sumber"]
    src --> sweep["Telusuri kredensial lama"]
    sweep -.-> c1["Kredensial tersimpan"]
    sweep -.-> c2["Sesi RDP yang dibiarkan terputus"]
    sweep -.-> c3["Layanan atau task dengan kata sandi lama"]

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

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

flowchart TB
    accTitle: Mesin tempat jejak kegagalan tertinggal
    accDescr: Kegagalan 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 DC
    src["Mesin sumber (4625 tidak tertinggal di sini)"] -->|Logon jaringan| target["Server tujuan"]
    target -.-> e4625["4625 terekam"]
    src -->|Autentikasi akun domain| dc["Domain controller"]
    dc -.-> e4776["4776 (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)¹⁷, 4726 (dihapus), 4738 (diubah), dan di sisi grup, anggota ditambah/dihapus. Catat bahwa event ID untuk perubahan keanggotaan grup bergantung pada jenis grup. Grup lokal memakai 4732/4733, grup global 4728/4729, grup universal 4756/4757.¹⁴ Domain Admins adalah grup global, jadi penambahan ke dalamnya terekam sebagai 4728 — jika alert hanya pada 4732, peristiwa yang paling ingin ditangkap justru terlewat. Sehari-hari ini sebagian besar 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 mencontohkan penambahan anggota yang tidak terduga ke grup istimewa sebagai peristiwa yang layak di-alert secara individual.³

flowchart TB
    accTitle: Jenis grup dan peristiwa penambahan anggota
    accDescr: Penambahan anggota ke grup memakai event ID yang berbeda menurut jenis grup: lokal 4732, global 4728, universal 4756, jadi penambahan ke Domain Admins yang merupakan grup global dilihat di 4728
    add["Penambahan anggota ke grup"] --> kind{"Jenis grupnya?"}
    kind -->|Lokal| lg["Terekam di 4732"]
    kind -->|Global| gg["Terekam di 4728"]
    kind -->|Universal| ug["Terekam di 4756"]
    gg -.-> da["Penambahan ke Domain Admins ada di sini"]
    lg -.-> miss["Memantau hanya 4732 akan terlewat"]

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

4.5. 4688 — pembuatan proses. Pencatatan command line adalah sakelar terpisah

4688, “A new process has been created,” merekam akun pembuat, jalur file eksekusi proses baru, proses induk, dan token elevation type setiap kali proses dibuat.¹¹ Ini peristiwa bernilai investigasi tinggi yang dapat menjawab “siapa menjalankan apa di server ini.”

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

flowchart TB
    accTitle: Hubungan 4688 dan pencatatan command line
    accDescr: Mengaktifkan audit pembuatan proses merekam akun, jalur file eksekusi, dan proses induk di 4688, tetapi argumen command line baru terekam setelah Group Policy terpisah diaktifkan, dengan risiko rahasia muncul dalam teks biasa
    audit["Aktifkan audit pembuatan proses"] --> ev["4688 terekam"]
    ev -.-> base["Akun, jalur, proses induk"]
    ev --> args{"Ingin melihat argumen juga?"}
    args -->|Biarkan default| none["Command line kosong"]
    args -->|Aktifkan GPO tambahan| cmd["Argumen terekam"]
    cmd -.-> risk["Risiko rahasia muncul dalam teks biasa"]

Gambar 11: Pencatatan command line 4688 adalah sakelar terpisah. Cek risiko tercampurnya rahasia sebelum mengaktifkannya.

4.6. 4698 — pembuatan scheduled task

4698, “A scheduled task was created,” merekam nama task dan seluruh XML definisi task (termasuk perintah yang dijalankan). Karena mendaftarkan scheduled task adalah cara umum malware untuk tetap hidup setelah reboot, Microsoft merekomendasikan memantau peristiwa pembuatan task.¹⁵ Bahkan di lingkungan yang memakai task secara intensif untuk keperluan bisnis, pembuatan itu sendiri bukan kejadian harian, jadi tingkat noisenya relatif kecil.

flowchart TB
    accTitle: Persistensi lewat pendaftaran task dan 4698
    accDescr: Malware biasa mendaftarkan scheduled task agar tetap hidup setelah reboot, jadi memantau 4698 yang terekam saat task dibuat memungkinkan menelusuri sampai definisi task termasuk perintah yang dijalankan
    mal["Persistensi malware"] --> task["Daftar task agar tetap hidup"]
    task --> ev["4698 terekam"]
    ev -.-> xml["Seluruh XML termasuk perintah yang dijalankan"]
    ev --> watch["Deteksi dengan memantau pembuatan task"]
    watch -.-> low["Pembuatan tidak harian, noise kecil"]

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

Satu lagi yang perlu diingat: 1102 “The audit log was cleared.” Mengosongkan log Security selalu meninggalkan peristiwa ini, jadi ketika “log-nya kosong,” dapat dipilah apakah itu operasi atau kecelakaan.¹⁸

flowchart TB
    accTitle: Memilah penghapusan log lewat 1102
    accDescr: Mengosongkan log Security selalu meninggalkan 1102, jadi ketika log kosong dapat dipilah apakah itu operasi penghapusan atau kecelakaan dengan memeriksa ada tidaknya 1102
    empty["Log dalam keadaan kosong"] --> rule["Pengosongan selalu meninggalkan 1102"]
    rule --> check{"Ada 1102?"}
    check -->|Ada| op["Ada operasi penghapusan"]
    check -->|Tidak ada| acc["Curigai kemungkinan kecelakaan"]

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

5. Merancang wadah log — ukuran maksimum dan retensi

Sebelum menambah kebijakan audit, cek wadah penerimanya. Log Security punya ukuran maksimum dan mode retensi. Dalam mode overwrite (konfigurasi yang lazim), begitu ukuran maksimum tercapai, peristiwa baru menimpa yang tertua. Sebaliknya, dalam mode retensi (jangan-overwrite), begitu log penuh, peristiwa barulah yang dibuang.¹⁰ Kedua perilaku dapat menjadi penyebab “baru sadar log tidak ada”, jadi pahami keadaan saat ini lebih dulu.

# Cek 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.⁹ Selisih “stempel waktu peristiwa tertua” dan waktu sekarang adalah hari retensi aktual; jika itu kurang dari persyaratan (berapa hari ke belakang yang ingin bisa diselidiki), perbesar ukuran maksimum. Pengaturan dapat dilakukan dengan wevtutil sl Security /ms:<jumlah byte> atau disebar lewat Group Policy.¹⁰

flowchart TB
    accTitle: Desain kapasitas yang dihitung mundur dari hari retensi
    accDescr: Periksa 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 insiden
    check["Periksa konfigurasi dan jumlah dengan ListLog"] --> oldest["Periksa stempel waktu peristiwa tertua"]
    oldest --> days["Hitung hari retensi aktual"]
    days --> enough{"Cukup untuk persyaratan?"}
    enough -->|Cukup| keep["Pertahankan ukuran saat ini"]
    enough -->|Tidak cukup| grow["Perbesar ukuran maksimum"]
    grow -.-> how["Atur 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 “Audit: Shut down system immediately if unable to log security audits” (umum dikenal sebagai CrashOnAuditFail). Ketika aktif, jika sistem tidak mampu merekam peristiwa audit, ia berhenti dengan STOP error C0000244. Ini pengaturan untuk persyaratan autentikasi yang sama sekali tidak boleh kehilangan jejak audit, dan secara default dinonaktifkan. Microsoft sendiri memperingatkan bahwa ini dapat diubah menjadi DoS — penyerang sengaja membanjiri peristiwa untuk menghentikan server — jadi ini bukan sesuatu yang diaktifkan begitu saja di lingkungan skala kecil-menengah yang lazim.¹⁹

flowchart TB
    accTitle: Perilaku ketika log penuh
    accDescr: Konfigurasi retensi ada dua, mode overwrite dan mode jangan-overwrite, dan ketika audit tidak dapat direkam dalam mode jangan-overwrite, jika CrashOnAuditFail yang merupakan pengaturan terpisah aktif, sistem berhenti dengan STOP error C0000244
    full["Log Security mencapai ukuran maksimum"] --> mode{"Konfigurasi retensinya?"}
    mode -->|Mode overwrite| ow["Peristiwa tertua ditimpa"]
    mode -->|Jangan overwrite| drop["Peristiwa baru dibuang"]
    ow -.-> lost["Keduanya penyebab log hilang tanpa disadari"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail juga aktif?"}
    caf -->|Ya| crash["Berhenti dengan STOP error C0000244"]

Gambar 15: Konfigurasi retensi ada dua: overwrite 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, lalu tentukan event ID (misalnya 4625) dan rentang waktu dengan “Filter Current Log”. Kondisi yang dicek berulang disimpan sebagai “Custom View” agar lain kali cukup satu klik. Jika ingin menyempitkan menurut akun tertentu, bukan hanya event ID, kueri XPath dapat disunting langsung di tab XML dialog filter.

6.2. Ekstraksi dengan Get-WinEvent

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

flowchart TB
    accTitle: Memilih sarana investigasi
    accDescr: Investigasi 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-WinEvent
    q{"Investigasi seperti apa?"}
    q -->|Sekali| viewer["Saring di Event Viewer"]
    q -->|Kondisi yang dilihat berulang| view["Simpan sebagai Custom View"]
    q -->|Volume besar, banyak kondisi, berkala| ps["Beralih ke Get-WinEvent"]
    ps -.-> hash["Saring dengan FilterHashtable"]

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

# Ambil kegagalan masuk (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 pola menarik EventData dari representasi XML peristiwa ini dimiliki, 4624 maupun 4688 dapat dikerjakan dengan cara yang sama. Desain penyaringan Get-WinEvent (kapan memakai FilterHashtable versus XPath, dan cara memperbaiki kueri yang lambat) dibahas lebih rinci di “Menyelidiki log peristiwa secara praktis dengan Get-WinEvent”.

flowchart TB
    accTitle: Pola membentuk tabel dengan menarik EventData
    accDescr: Pola 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 4625
    get["Ambil dengan Get-WinEvent"] --> xml["Ubah peristiwa ke representasi XML"]
    xml --> pull["Tarik EventData"]
    pull --> shape["Bentuk tabel dan agregasikan"]
    shape -.-> reuse["Cara yang sama untuk 4624 atau 4688"]

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

6.3. Mengekspor dengan wevtutil

Prinsipnya: log di mesin yang diselidiki diekspor dan diamankan dulu, sebelum tertimpa.¹⁰

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

rem ekspor hanya 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, memakai Get-WinEvent -Path C:\logs\security-20260801.evtx.⁹ Kebiasaan mengamankan dulu baru menganalisis sama dengan “amankan dump dulu” saat investigasi crash (lihat “Pengantar pengumpulan crash dump Windows”).

flowchart TB
    accTitle: Alur mengamankan dulu, lalu menganalisis
    accDescr: Ekspor 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-WinEvent
    target["Mesin yang diselidiki"] --> export["Amankan ke evtx dengan wevtutil epl"]
    export --> copy["Bawa ke mesin lain"]
    copy --> analyze["Analisis dengan Get-WinEvent -Path"]
    export -.-> note["Amankan sebelum hilang karena ditimpa"]

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

7. Jebakan — empat yang mudah terinjak di lapangan

(1) Rahasia mendarat di command line 4688. Mengaktifkan pencatatan command line memasukkan argumen setiap proses ke log Security dalam teks biasa. Microsoft menyatakan secara eksplisit bahwa semua pengguna dengan hak baca peristiwa keamanan dapat membaca argumen command line setiap proses, dan argumen itu dapat berisi rahasia seperti kata sandi.¹² Jika ada satu saja aplikasi bisnis atau skrip yang meluncurkan sesuatu seperti myapp.exe /user:admin /password:P@ssw0rd, itu pengungkapan rahasia kepada semua orang yang dapat melihat log. Sebelum mengaktifkan, telusuri tempat yang meneruskan rahasia sebagai argumen dan perbaiki. Tujuan pengamanan dan penerusan log juga perlu ditangani pada tingkat yang sama.

flowchart TB
    accTitle: Urutan mengaktifkan pencatatan command line
    accDescr: Pencatatan command line 4688 harus diaktifkan setelah aplikasi bisnis dan skrip yang meneruskan rahasia sebagai argumen ditelusuri dan tempat yang relevan diperbaiki, dan tujuan pengamanan serta penerusan log juga harus diberi tingkat penanganan yang sama
    audit["Telusuri penerusan rahasia sebagai argumen"] --> found{"Ada yang relevan?"}
    found -->|Ada| fix["Perbaiki tempat yang meneruskannya"]
    found -->|Tidak ada| on["Aktifkan pencatatan command line"]
    fix --> on
    on -.-> dest["Tujuan pengamanan dan penerusan dengan tingkat yang sama"]

Gambar 19: Pencatatan command line adalah “telusuri, perbaiki, baru aktifkan”. Membalik urutannya menjadi pengungkapan rahasia.

(2) Beroperasi tanpa tahu perilaku saat log penuh. Dalam mode overwrite, jejak lama hilang diam-diam; dalam mode jangan-overwrite, peristiwa baru dibuang; dan jika CrashOnAuditFail aktif, seluruh sistem berhenti (bab 5).¹⁰¹⁹ Yang perlu dilakukan: ketahui perilaku mana yang dipilih, dan sediakan mekanisme yang mengumpulkan data sebelum hilang — ekspor berkala atau platform pengumpulan log.

(3) Domain controller dan perangkat klien menuntut log yang berbeda. 4624/4625 terekam di mesin yang diakses.⁵⁶ Sebaliknya, validasi kredensial akun domain (4776 NTLM) terekam di mesin yang berwenang atas kredensial — untuk akun domain, itu DC⁷ — dan kegagalan pra-autentikasi Kerberos (4771) terekam hanya di DC.⁸ “Tidak ada 4625 di file server” tidak berarti “tidak ada serangan”; gambaran utuh baru muncul setelah 4776/4771 di DC juga dicocokkan. Alur tiap protokol autentikasi diuraikan di “NTLM dan Kerberos dalam diagram”.

(4) Pergeseran jam merusak pencocokan. Menyusun log dari beberapa mesin untuk menelusuri “perangkat mana yang menghasilkan 4625 tepat sebelum 4740 ini” mensyaratkan jam setiap mesin selaras. Di lingkungan domain, Kerberos sendiri memasang batas atas pada pergeseran jam (default 5 menit); di luar itu autentikasi itu sendiri mulai gagal.²⁰ Dari sudut investigasi, pergeseran beberapa detik saja — apalagi lima menit — dapat membuat urutan sebelum-sesudah salah dibaca, jadi cek status sinkronisasi w32time harus menjadi langkah paling awal prosedur investigasi. Stempel waktu peristiwa disimpan dalam UTC dan ditampilkan menurut zona waktu mesin yang melihat, jadi jangan lupa mengonversi zona waktu ketika membaca evtx yang dibawa dari situs luar negeri atau server yang dikonfigurasi ke UTC.

flowchart TB
    accTitle: Prasyarat sinkronisasi waktu dan investigasi pencocokan
    accDescr: Investigasi 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 investigasi
    merge["Mencocokkan log beberapa mesin"] --> pre["Prasyarat: jam-jamnya selaras"]
    pre --> skew{"Selisih jamnya?"}
    skew -->|Selaras| ok["Dapat ditelusuri menurut waktu"]
    skew -->|Selisih beberapa detik| misread["Urutan sebelum-sesudah salah dibaca"]
    skew -->|Melebihi default 5 menit| kerb["Autentikasi Kerberos gagal"]
    pre -.-> first["Periksa w32time di awal prosedur"]

Gambar 20: Mencocokkan beberapa mesin mensyaratkan 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, cek keadaan saat ini dengan auditpol /get /category:*, lalu rancang dari situ.
• “Aktifkan semuanya” membunuh investigasi lewat noise 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 logon type, 4625 menurut kode Status/Sub Status, 4740 menurut Caller Computer Name, dan 4688 menurut proses induk dan command line — setiap peristiwa punya titik yang harus dilihat.
• Wadah log (ukuran maksimum dan mode retensi) adalah separuh desain audit. Cek berapa hari yang benar-benar tertahan, tentukan ukuran dengan menghitung mundur dari persyaratan, dan ekspor atau kumpulkan sebelum tertimpa.
• Pencatatan command line 4688 baru diaktifkan setelah risiko tercampurnya rahasia dicek. Perbedaan mesin tempat pencatatan, dan sinkronisasi jam, adalah prasyarat pencocokan lintas mesin.
• Investigasi dimulai dengan filter Event Viewer; yang berulang memakai Get-WinEvent -FilterHashtable; pengamanan memakai wevtutil epl. Jangan mematahkan urutan “amankan dulu, baru analisis”.

Artikel terkait

• Menyelidiki log peristiwa secara praktis dengan Get-WinEvent — kecepatan filter yang menentukan lama investigasi
• Apakah penghentian NTLM akan menghentikan aplikasi bisnis — cara mengambil log audit, dan urutan mematikan dependensi
• NTLM dan Kerberos dalam diagram — mengapa autentikasi “jatuh” ke NTLM
• SMB signing dan LDAP channel binding — menutup “separuh yang tersisa” dari penanganan NTLM di lapangan
• Pengantar Windows Event Log dan ETW — menempatkan log aplikasi bisnis pada mekanisme standar OS
• Pengantar pengumpulan crash dump Windows - WER/ProcDump/WinDbg

Area konsultasi terkait

KomuraSoft LLC menangani konsultasi kebijakan audit dan desain log di lingkungan Windows, investigasi “kapan, siapa, dan apa” berdasarkan log peristiwa, serta analisis penyebab gangguan terkait autentikasi dan audit pada aplikasi bisnis. Tidak apa-apa memulai dari tahap “disuruh melihat log, tetapi tidak tahu harus mulai dari mana”.

• Investigasi bug dan analisis penyebab
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

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.

Mengapa 4624 dan 4625 terekam di log Security padahal kebijakan audit belum diatur sama sekali?

Karena Windows punya subkategori audit yang sudah aktif secara default. Subkategori "Logon", misalnya, sejak Windows 10 versi 1809 mengaktifkan keberhasilan dan kegagalan secara default, sehingga 4624 (berhasil) dan 4625 (gagal) terekam tanpa pengaturan apa pun. Namun jika default dibiarkan apa adanya, banyak peristiwa yang dibutuhkan saat investigasi — validasi kredensial (4776) atau pembuatan proses (4688), misalnya — tidak terekam. Apa yang aktif di lingkungan sendiri dapat dicek dengan auditpol /get /category:*. Dari situ, pola praktisnya adalah secara eksplisit mengaktifkan subkategori yang masih kurang di sisi kebijakan audit lanjutan.

Ingin menyelidiki kegagalan masuk, tetapi 4625 tidak ada di log Security server sasaran. Ke mana harus melihat?

Pertama, pegang prinsip ini: 4625 terekam di komputer tempat logon dicoba. Kegagalan masuk di perangkat pengguna ada di perangkat itu; kegagalan akses ke file server ada di file server. Berikutnya, dengan auditpol /get /category:* cek apakah audit kegagalan aktif pada subkategori "Logon". Untuk akun domain, jejak sering tersisa sebagai validasi kredensial (4776) atau kegagalan pra-autentikasi Kerberos (4771) di domain controller. Jika perangkat sumber tidak teridentifikasi, lebih cepat mulai dari sisi DC. Jika masih tidak ketemu, cek apakah peristiwa lama sudah tertimpa — bandingkan ukuran maksimum log dengan stempel waktu peristiwa tertua.

Haruskah pencatatan command line untuk pembuatan proses (4688) diaktifkan?

Nilai investigasinya sangat tinggi, tetapi ini pengaturan yang baru boleh diaktifkan setelah risikonya dipahami. Setelah aktif, argumen command line setiap proses terekam di log Security dalam teks biasa. Jika ada satu saja skrip atau aplikasi bisnis yang meneruskan kata sandi atau API key sebagai argumen command line, rahasia itu terlihat oleh siapa pun yang dapat membaca log Security. Microsoft sendiri menuliskan peringatan ini secara eksplisit. Urutan yang disarankan: cek dulu apakah skrip internal meneruskan rahasia lewat argumen command line, perbaiki yang melakukannya, baru kemudian aktifkan.

Seberapa besar seharusnya ukuran maksimum log Security?

Cara yang benar adalah menghitung mundur dari "berapa hari yang ingin disimpan di tangan", bukan mencari satu angka yang berlaku di semua tempat. Pengaturan saat ini dan kondisi aktual dapat dicek dengan Get-WinEvent -ListLog Security; selisih stempel waktu peristiwa tertua dan waktu sekarang adalah "berapa hari yang benar-benar tertahan saat ini". Menambah subkategori audit juga menambah volume peristiwa, jadi setelah mengubah pengaturan, selalu cek ulang hari retensi aktual ini. Penanganan insiden tidak jarang membutuhkan log dari minggu sampai bulan sebelumnya, jadi lebih aman mengekspor secara berkala sebelum tertimpa, atau mengumpulkannya ke mesin lain lewat mekanisme pengumpulan log.

Bagaimana cara mencari penyebab lockout akun (4740)?

Petunjuk pertama adalah bidang "Caller Computer Name" pada peristiwa 4740. Di situ terekam komputer asal percobaan logon gagal yang memicu lockout. Catat 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, di situ telusuri apa pun yang masih memegang kredensial lama setelah perubahan kata sandi: kredensial tersimpan, sesi Remote Desktop yang dibiarkan terputus, layanan atau scheduled task yang dikonfigurasi dengan kata sandi lama. Jika lockout berulang, cek 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.