Machine Translated by Google
9 Log Peristiwa
Log peristiwa
berisi
banyak
informasi
merupakan
bahan
pokok
di hampir
investigasi.
Mereka
berisi
rincianforensik
tentang dan
kesalahan
aplikasi
(seperti
ketika
Word semua
lumpuhjenis
setelah mengeksploitasi heap-spray), login interaktif dan jarak jauh, perubahan dalam kebijakan
firewall, dan peristiwa lain yang terjadi pada sistem. Dikombinasikan dengan stempel waktu yang
disertakan dengan setiap peristiwa, log dapat membantu Anda menentukan dengan tepat apa yang
terjadi pada sistem, atau setidaknya memberi Anda kerangka waktu untuk memfokuskan sisa upaya Anda.
Bab ini membahas cara menemukan log kejadian di RAM dan menguraikannya untuk tujuan
forensik. Banyak dari file log dipetakan ke dalam memori selama waktu berjalan sistem, sehingga
biasanya ditemukan ratusan, bahkan ribuan, catatan individu dalam dump memori.
Dalam beberapa kasus, Anda bahkan mungkin dapat mengekstrak entri setelah ditandai untuk
dihapus oleh administrator atau dibersihkan secara jahat oleh penyerang.
Log Peristiwa di Memori
Karena rekaman kejadian direkam selama waktu berjalan sistem, masuk akal jika Anda akan
menemukan rekaman ini, atau bahkan file log kejadian, di memori. Untuk menemukan rekaman atau
log peristiwa, pertama-tama Anda perlu mengetahui strukturnya—seperti apa tampilannya dan di
mana menemukannya secara konsisten—karena metodologi sangat bervariasi bergantung pada
sistem operasi target.
Tujuan Analisis
Tujuan Anda adalah ini:
• Temukan log peristiwa di memori: Dimulai dengan Vista, Microsoft membuat beberapa
perubahan penting pada fasilitas log peristiwa. Untuk bekerja dengan log peristiwa di berbagai
versi Windows, Anda perlu memahami dan memperhitungkan perbedaannya.
Machine Translated by Google
266 Bagian II: Forensik Memori Windows
• Memproses log peristiwa: Pelajari kapan mengurai rekaman dari memori dengan Volatilitas dan kapan
mengekstrak file log untuk dianalisis dengan alat eksternal. • Deteksi login brute force: Pelajari cara
mengidentifikasi upaya login brute force
menganalisis pesan kegagalan di log peristiwa.
• Identifikasi pintu belakang: Mendeteksi perubahan pada kebijakan firewall dan konflik port server,
yang seringkali dapat menunjukkan aktivitas pintu belakang.
• Identifikasi log peristiwa yang dihapus: Pelajari apa yang terjadi ketika log peristiwa dihapus dan cara
menentukan apakah kode berbahaya atau penyerang telah mencoba menghapus log.
Struktur data
Keluaran berikut menunjukkan anggota terpilih dari struktur log peristiwa Windows XP dan 2003. Harlan Carvey juga
mendokumentasikan struktur log peristiwa di blognya (http://windowsir.blogspot.com/2007/06/eventlog-analysis.html).
EVTLogHeader adalah struktur yang digunakan sebagai header file log peristiwa, sedangkan EVTRecordStruct adalah
untuk rekaman individual.
>>> dt("EVTLogHeader")
'EVTLogHeader' (48 byte) 0x0 :
HeaderSize
['unsigned int'] ['int']
0x4
: Sihir
0x10 : OffsetLama
['unsigned int'] ['unsigned
0x14 : OffsetBerikutnyaMenulis
int'] ['int'] ['unsigned int']
int'] ['int'] ['int'] ['unsigned
0x18 : ID Berikutnya
0x1c : ID Terlama
0x20 : Ukuran Maks
0x28 : Waktu Retensi
0x2c : Ukuran Rekam
>>> dt("EVTRecordStruct")
'EVTRecordStruct' (56 byte)
0x0 : Panjang Rekaman
0x4
: Sihir
0x8
['unsigned int'] ['int'] ['int']
: Nomor Rekam
0xc : Dihasilkan Waktu
['UnixTimeStamp', {'is_utc': Benar}]
0x10 : Waktu Tertulis
['UnixTimeStamp', {'is_utc': True}] ['unsigned short']
0x14 : ID Peristiwa
0x18 : EventType 0x1a :
['Enumerasi', [snip] ['unsigned
NumStrings [snip]
short']
Poin Kunci
Poin-poin utamanya adalah sebagai berikut:
• OldestID: ID dari catatan log peristiwa terlama dalam file.
Machine Translated by Google
Log Peristiwa 267
• Sihir: Tanda tangan log peristiwa dan rekamannya. Tanda tangan ini
adalah LfLe. • NextID: ID dari rekaman log peristiwa berikutnya yang akan
ditulis. • RecordLength: Panjang record log peristiwa, yang dapat bervariasi,
tergantung pada record, karena string pesan berbeda untuk setiap jenis pesan.
• RecordNumber: ID dari record dalam event log. • TimeGenerated:
Stempel waktu yang menunjukkan kapan peristiwa dihasilkan (UTC). • TimeWritten: Stempel
waktu yang menunjukkan kapan catatan peristiwa ditulis (UTC). • EventID: ID yang menjelaskan
jenis peristiwa apa yang telah terjadi. • NumStrings: Jumlah pesan yang disertakan dengan
catatan yang membantu mendeskripsikan kejadian. Anda mungkin memerlukan templat pesan
yang sesuai untuk menginterpretasikan arti string dengan benar. Untuk informasi
selengkapnya tentang cara menemukan template, lihat catatan di akhir bagian "Log Kejadian
Windows 2000, XP, dan 2003" di bab selanjutnya.
Log Peristiwa Windows 2000, XP, dan 2003
Di Windows 2000, XP, dan 2003, log peristiwa memiliki format rekaman biner yang sama. Log default
adalah Aplikasi, Sistem, dan Keamanan, dan lokasi penyimpanan default pada disk untuk log ini ada
di %systemroot%\system32\config. Log peristiwa ini juga dipetakan di ruang alamat proses
services.exe .
Menemukan File Log
Peristiwa Anda dapat mengetahui dengan tepat segmen memori mana yang menyimpan data file
dengan menemukan proses service.exe dan mencari nama file log peristiwa (ekstensi .Evt), seperti
yang ditunjukkan pada output berikut.
$ python vol.py -f XPSP3.vmem --profile=WinXPSP3x86 pslist | layanan grep Volatility Foundation Volatility
Framework 2.4 0x81d97020 services.exe
692
648
16 352 0 0 27-12-2010 21:34:32
$ python vol.py -f XPSP3.vmem --profile=WinXPSP3x86 vadinfo -p 692
[menggunting]
Node VAD @ 0x8230af40 Mulai 0x009c0000 Akhir 0x009cffff Tag Vad
Bendera: Perlindungan: 4
Perlindungan: PAGE_READWRITE
ControlArea @82040f50 Segmen e16ad7d8
Daftar dereferensi: Kedip 00000000, Kedip 00000000
Referensi NumberOfSection:
1 NumberOfPfnReferensi:
NumberOfMappedViews:
1 NumberOfUserReferences:
WaitingForDeletion Acara: 00000000 Bendera
Kontrol: Diakses: 1, File: 1, HadUserReference: 1 FileObject @82040ed8, Nama:
\WINDOWS\system32\config\SecEvent.Evt [snip]
1
2
Machine Translated by Google
268 Bagian II: Forensik Memori Windows
Anda sekarang tahu cara menemukan log peristiwa di memori, tetapi apa yang Anda lakukan
selanjutnya? Anda dapat membuang bagian VAD dan mengurainya dengan alat di luar Volatilitas,
tetapi Anda sebaiknya mengurai log peristiwa langsung dari memori.
CATATAN
Log peristiwa Windows XP/2003 memiliki ukuran maksimum dan diperlakukan sebagai buffer cincin.
Ini berarti bahwa saat ukuran maksimum tercapai, penunjuk untuk menulis ke log membungkus
catatan terlama dan menimpanya dengan data baru. Metodologi ini dapat merusak beberapa alat
karena catatan parsial dapat merusak apa yang diharapkan alat untuk dilihat—belum lagi fakta
bahwa beberapa potongan file log mungkin tidak tersedia karena paging.
Mengekstrak Log Peristiwa
Plugin evtlogs (hanya Windows XP dan 2003) menemukan dan mem-parsing catatan log peristiwa
untuk Anda secara otomatis. Itu juga dirancang untuk menangani log peristiwa yang rusak dengan data
yang hilang atau ditimpa. Plugin ini bekerja dengan terlebih dahulu menemukan proses services.exe
dan kemudian mencari memorinya untuk log peristiwa. Itu kemudian memecah setiap log berdasarkan
sihirnya (LfLe) dan mem-parsing setiap catatan menggunakan struktur yang ditentukan di awal bab ini.
Plugin evtlogs juga memiliki opsi untuk membuang log mentah jika Anda ingin memprosesnya
menggunakan alat di luar Volatilitas. Berikut ini menunjukkan kepada Anda contoh output dari
menjalankan plugin terhadap sampel memori publik (http://sempersecurus.blogspot.com/2011/04/ usingvolatility-to-study-cve-2011-6011.html) diperoleh setelah mengakses Dokumen Word dengan eksploit
Flash tertanam:
$ python vol.py -f cve2011_0611.dmp --profile=WinXPSP3x86 evtlogs -v --save-evt -D output/ Volatility Foundation
Volatility Framework 2.4 Menyimpan file .evt mentah ke osession.evt
Data yang diurai dikirim ke osession.txt
Menyimpan file .evt mentah ke internet.evt
Data yang diurai dikirim ke internet.txt
File .evt mentah disimpan ke appevent.evt Data di-parsing
dikirim ke appevent.txt File .evt mentah disimpan ke odiag.evt
Data di-parsing dikirim ke odiag.txt File .evt mentah disimpan ke
sysevent.evt Data di-parsing dikirim ke sysevent.txt Disimpan
mentah file .evt ke secevent.evt
Data yang diurai dikirim ke secevent.txt
Machine Translated by Google
Log Peristiwa 269
Karena contoh ini menggunakan opsi --save-evt , plugin membuat file .evt (log peristiwa
biner mentah) dan file .txt (catatan yang diuraikan dalam format teks) untuk setiap file log.
Output dari file teks yang diurai adalah dalam format berikut:
Tanggal/Waktu | Nama Log | Nama Komputer | SID | Sumber | ID Acara | Jenis Acara
| Rangkaian Pesan
Mengetahui hal ini, Anda dapat memeriksa keluaran dari log osession.evt .
$ cat osession.txt
10-04-2011 09:14:22 UTC+0000|osession.evt|FINANCE1|T/A| Microsoft
Office 12 Sesi|7000|Info| 0;Microsoft Office
Word;12.0.4518.1014;12.0.4518.1014;1368;0
10-04-2011 09:33:40 UTC+0000|osession.evt|FINANCE1|T/T| Microsoft
Office 12 Sesi|7000|Info| 0;Microsoft Office
Word;12.0.6425.1000;12.0.6425.1000;1086;60
[menggunting]
10-04-2011 22:29:44 UTC+0000|osession.evt|FINANCE1|T/T| Microsoft
Office 12 Sesi|7000|Info| 0;Microsoft Office
Word;12.0.6545.5000;12.0.6425.1000;80;60
10-04-2011 22:30:18 UTC+0000|osession.evt|FINANCE1|T/T| Microsoft
Office 12 Sesi|7003|Peringatan| 0;Microsoft Office
Word;12.0.6545.5000;12.0.6425.1000
[menggunting]
Perhatikan bahwa ada catatan level Peringatan dengan ID 7003, yang berarti bahwa aplikasi
Microsoft Office tiba-tiba berhenti. Informasi ini relevan dengan penyelidikan karena vektor
infeksi adalah eksploit Flash yang disematkan. Di Bab 18, Anda belajar bagaimana membuat
garis waktu dan melihat bagaimana kejadian ini digabungkan dengan kejadian lain melukiskan
gambaran yang jelas tentang serangan itu.
Kebijakan Logging
Secara default, log peristiwa Keamanan dimatikan di Windows XP. Oleh karena itu, Anda harus
memeriksa pengaturan audit di registri (HKLM\SECURITY\Policy\PolAdtEv) untuk memverifikasi
jenis kejadian yang diharapkan. Perintah berikut menunjukkan cara melakukan pemeriksaan
dengan menggunakan plugin auditpol (S berarti "operasi yang berhasil dicatat", dan F berarti
"operasi yang gagal dicatat"):
$ python3 vol.py -f XPSP3x86.vmem auditpol --profile=WinXPSP3x86 Fondasi
Volatilitas Kerangka Kerja Volatilitas 2.4 Audit Diaktifkan Peristiwa Sistem Audit: S/F
Peristiwa Logon Audit: S/F
Machine Translated by Google
270 Bagian II: Forensik Memori Windows
Akses Objek Audit: Tidak Dicatat
Penggunaan Hak Istimewa Audit: Tidak Dicatat
Pelacakan Proses Audit: Tidak Dicatat
Perubahan Kebijakan Audit: S
Manajemen Akun Audit: S/F
Akses Layanan Dir Audit: S/F
Peristiwa Logon Akun Audit: S/F
CATATAN
Referensi yang bagus untuk mencari ID log peristiwa dan string pesan adalah
sebagai berikut: http://go.microsoft.com/fwlink/events.asp http://www.eventid.net/
http://blogs.msdn.com/b /ericfitz/ http://www.ultimatewindowssecurity.com/securitylog/
encyclopedia/Default.aspx
Windows Vista, 2008, dan 7 Log Peristiwa
Log peristiwa Windows Vista, 2008, dan 7 (yang akan kami sebut "Evtx", berdasarkan ekstensinya)
disimpan dalam format file yang sama sekali berbeda dari yang dijelaskan di bagian sebelumnya.
Secara khusus, log ini dimuat dalam format biner XML. Pada mesin biasa, Anda dapat menemukan
lebih dari 60 log ini pada disk di %systemroot%\system32\ winevt\Logs. Jumlah log yang begitu
tinggi meningkatkan peluang untuk menemukan catatan yang menarik pada mesin yang disusupi.
Selain itu, string deskripsi terdapat dalam log peristiwa ini (tidak seperti log XP/2003), yang
membuatnya lebih mudah untuk diselidiki tanpa memiliki akses ke disk mesin target.
CATATAN
Untuk menemukan ID keamanan yang setara untuk mesin Windows Vista, 2008, dan 7,
tambahkan 4096 ke ID yang digunakan untuk Windows XP/2003. Misalnya, untuk menemukan
kejadian yang terkait dengan seseorang yang masuk ke mesin Windows 7, ID yang diinginkan
adalah 4624, bukan 528. Untuk informasi lebih lanjut, lihat http://blogs.msdn.com/b/ericfitz/
archive/2007/04/18/vista-security-events-get-noticed.aspx.
Log peristiwa yang lebih baru tidak dipetakan dalam memori dengan cara yang sama seperti
yang lama. Oleh karena itu, metodologi untuk menangani log ini sangat berbeda—Anda harus
mengekstrak log dari memori menggunakan plugin dumpfiles (lihat Bab 16) dan kemudian
mengurainya dengan alat di luar Volatilitas. Anda dapat memilih metodologi yang ditargetkan
(menemukan dan membuang log peristiwa pilihan) atau Anda dapat memilih untuk membuang
semua log peristiwa dengan memanfaatkan kemampuan pencocokan pola (ekspresi reguler) plugin dumpfiles . Milikm
Machine Translated by Google
Log Peristiwa 271
pendekatan tergantung pada apa yang Anda cari dan seberapa banyak konteks yang Anda berikan sebelum
penyelidikan Anda. Misalnya, jika Anda mencoba membuktikan bahwa seseorang masuk ke mesin, Anda mungkin
hanya memeriksa log kejadian Keamanan. Namun, jika Anda tidak yakin apa masalah yang mendasari mesin, Anda
mungkin membuang semua log peristiwa.
CATATAN
Beberapa alat yang kami gunakan sebelumnya untuk mem-parsing log peristiwa Evtx meliputi:
• Evtxparser: http://computer.forensikblog.de/en/2011/11/evtx-parser-1-1-1
.html
• EVTXtract: https://github.com/williballenthin/EVTXtract • Python-evtx: http://
www.williballenthin.com/evtx/index.html • Libevtx: http://code.google.com/p/libevtx /
Proyek EVTXtract sangat berguna, karena akan mencoba menggunakan templat pesan yang dikenal untuk
merekonstruksi pesan yang rusak atau hilang. Dengan kata lain, pembuat alat berupaya menangani file yang
dibuang dari memori dengan data yang hilang karena paging.
Untuk membuang semua file Evtx dari sampel memori, Anda dapat menggunakan perintah berikut:
$ python3 vol.py –f Win7SP1x86.vmem --profile=Win7SP1x86 file dump
--regex .evtx$ --ignore-case --dump-dir
output Volatility Foundation Volatility
Framework 2.4 DataSectionObject 0x8509eba8 756
\Device\HarddiskVolume1\Windows\System32\
winevt\Logs\Microsoft-Windows-Diagnostics-Performance%4Operational.evtx
SharedCacheMap 0x8509eba8 756
\Device\HarddiskVolume1\Windows\System32\
winevt\Logs\Microsoft-Windows-Diagnostics-Performance%4Operational.evtx \Device
0x83eaec48 756 winevt\Logs\Microsoft-Windows-Kernel-WHEA%4Errors.evtx
\HarddiskVolume1\Windows\System32\
\Device\HarddiskVolume1\Windows\System32\
DataSectionObject
SharedCacheMap 0x83eaec48 756 winevt\Logs\Microsoft-Windows-Kernel-WHEA% .evtx DataSectionObject
0x845bcab0 756 [snip]
Semua file yang diekstraksi akan berada di direktori keluaran Anda. Anda kemudian dapat menggunakan file Linux
utilitas untuk memverifikasi bahwa log dibuang:
$ file output/* output/
file.756.0x83f92518.vacb: output data/
file.756.0x83f95ea0.vacb: output data/
file.756.0x8404b008.vacb: MS Windows Vista Event Log, 2 potongan
(no. 1 sedang digunakan), catatan berikutnya no. 82
output/file.756.0x8408fa60.vacb: data output/
file.756.0x84090418.dat: MS Windows Vista Event Log, 1 potongan
Machine Translated by Google
272 Bagian II: Forensik Memori Windows
(no. 0 sedang digunakan), catatan berikutnya no. 5
output/file.756.0x840a2e38.vacb: Log Peristiwa MS Windows Vista, 1 potongan
(no. 0 sedang digunakan), catatan berikutnya no. 2
[potong]
Beberapa file yang diekstraksi mungkin mengatakan data alih-alih MS Windows Event Vista Event Log
karena header untuk log atau log itu sendiri ditukar dari memori pada saat akuisisi. Apa pun kasusnya, Anda
harus menyelidiki file ini untuk melihat apakah Anda dapat menemukan rekaman sebagian. Berikut ini
menunjukkan cara menyelidiki salah satu log ini dengan utilitas evtxdump.pl dari Evtxparser :
$ evtxdump.pl output/file.756.0x8404b008.vacb <?xml version="1.0"
encoding="utf-8" standalone="yes" ?>
<Acara>
<Acara xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<Sistem>
<Nama Penyedia = "Microsoft-Windows-Application-Experience"
Guid="{EEF54E71-0661-422D-9A98-82FD4940B820}" />
<EventID>900</EventID>
<Versi>0</Versi>
<Tingkat>4</Tingkat>
<Tugas>0</Tugas>
<Opcode>0</Opcode>
<Kata Kunci>0x0800000000000000</Kata Kunci>
<TimeCreated SystemTime="1341520633" />
<EventRecordID>1</EventRecordID>
<Korelasi />
<Eksekusi ProcessID="3336" ThreadID="3580" /> [snip]
Seperti yang Anda lihat, output berisi semua informasi tentang peristiwa yang terjadi
dihasilkan. Secara khusus, Anda dapat melihat bidang-bidang berikut:
• Nama Penyedia: Memberi tahu Anda dari log mana informasi ini diambil. • ID Peristiwa :
Berisi ID peristiwa yang akan Anda cari secara online untuk mencari tahu peristiwa apa yang terjadi. •
TimeCreated: Stempel waktu saat acara dibuat. • EventRecordID: ID rekaman, yang membantu
Anda mengetahui pengurutan
record yang dihasilkan.
Peringatan Tentang Log Peristiwa di Memori
Seperti disebutkan sebelumnya, meskipun catatan kejadian ditemukan di memori, seluruh file log tidak akan
tersedia dalam banyak kasus. Ini berarti bahwa secara teoritis Anda dapat memiliki catatan yang relevan
dengan kasus Anda di log peristiwa pada disk, tetapi tidak di memori. Seperti kebanyakan artefak dalam
memori, rekaman log peristiwa memiliki peluang retensi yang lebih tinggi jika memang demikian
Machine Translated by Google
Log Peristiwa 273
baru saja dibuat atau diakses. Ini adalah kabar baik jika Anda mendapatkan memori dekat dengan
waktu kompromi, tetapi kabar buruk sebaliknya.
Selain itu, musuh dapat menghapus log peristiwa pada mesin menggunakan fungsi
ClearEventLog . Fungsi ini menangani log peristiwa dan lokasi cadangan sebagai parameter.
Jika lokasi cadangan tidak diberikan (yaitu, NULL), log akan dihapus dari disk dan memori. Definisi
fungsi yang diperoleh dari MSDN (http://msdn.microsoft.com/en-us/ library/windows/desktop/
aa363637%28v=vs.85%29.aspx) ditampilkan dalam kode berikut:
BOOL ClearEventLog(
_Dalam_ HANDLE hEventLog,
_In_ LPCTSTR lpBackupFileName );
CATATAN
Berikut adalah contoh skrip Visual Basic (sumber aslinya adalah http://technet .microsoft.com/
library/ee176696.aspx) yang kami modifikasi untuk menghapus log Keamanan.
Baris yang dimulai dengan apostrof adalah komentar di Visual Basic:
strKomputer = "."
' Dapatkan izin yang tepat untuk mengakses log dan mencadangkannya Atur
objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate,(Security)}!
_
\\" &
_
strKomputer & "\root\cimv2")
' Temukan log peristiwa yang ingin kami hapus dan dapatkan pegangannya. Dalam
'
hal ini Anda ingin menghapus log peristiwa Keamanan.
Tetapkan colLogFiles = objWMIService.ExecQuery
("Pilih * dari Win32_NTEventLogFile "
_
_
& "Di mana LogFileName='Keamanan'")
' Karena kami tidak menetapkan BackupEventLog() kami kehilangan '
log saat dihapus di bawah ' Untuk setiap log yang dikumpulkan di atas
(dalam hal ini hanya Keamanan)
Untuk Setiap objLogfile di colLogFiles ' Hapus log
objLogFile.ClearEventLog()
' Cetak pernyataan bahwa itu telah dihapus.
WScript.Echo "Berkas log peristiwa yang dihapus"
Lanjut
Jika Anda menempatkan kode sebelumnya ke dalam file bernama clearevt.vbs, Anda dapat menjalankannya
seperti ini:
C:\> cscript clearevt.vbs
Microsoft (R) Windows Script Host Versi 5.7 Hak Cipta (C) Microsoft
Corporation. Seluruh hak cipta.
File log peristiwa dihapus
Machine Translated by Google
274 Bagian II: Forensik Memori Windows
Karena Anda harus menentukan masing-masing log yang ingin Anda hapus, penyerang terkadang
lupa untuk menghapus log yang diinginkan, seperti yang akan Anda lihat di salah satu contoh kasus
di akhir bab ini. Namun, ada solusi untuk menghapus semua log (lihat http://blogs.msdn.com/b/
jjameson/archive/2011/03/01/script-to-clear-and-save-event-logs.aspx). Di sisi lain, tindakan ini
membuat sangat jelas bahwa ada sesuatu yang salah jika tiba-tiba semua log kosong atau jika
seseorang melihat ada lonjakan tambahan dalam aktivitas mesin saat menghapus log ini. Sebagian
besar penyerang yang kami temui biasanya tidak menghapus semua log peristiwa.
Hanya karena log peristiwa dihapus bukan berarti Anda harus putus asa. Jika log Keamanan
kosong atau jarang, dan Anda tahu bahwa peristiwa harus dicatat karena Anda menggunakan plugin
auditpol , itu sendiri merupakan indikasi bahwa log peristiwa telah dihapus. Jika Anda memiliki image
disk forensik dari mesin yang dicurigai, Anda mungkin dapat mengambil catatan log peristiwa yang
berguna dari titik pemulihan, salinan bayangan volume, atau bahkan dari ruang yang tidak terisi.
Jika Anda tidak memiliki gambar disk, maka Anda dapat memindai ruang alamat fisik
dump memori untuk catatan menggunakan tanda tangan LfLe (Evt ) atau ElfChnk (Evtx),
dan Anda mungkin cukup beruntung untuk memulihkan catatan sejarah. Willi Ballenthin
menulis alat yang dapat Anda gunakan di luar Volatilitas untuk kedua kasus; mereka
secara tepat disebut LfLe (https://github.com/williballenthin/LfLe) dan EVTXtract (https://
github.com/williballenthin/EVTXtract).
CATATAN
Menghapus log peristiwa sebenarnya juga membuat artefak baru. Misalnya, peristiwa baru (ID
517) akan ditambahkan ke log Keamanan untuk menunjukkan bahwa Log Keamanan telah dihapus.
Ini berguna karena juga berisi stempel waktu kapan log dibersihkan:
05-12-2013 00:07:10 UTC+0000|secevent.evt|NAMA-KOMPUTER|S-1-5-18 (Sistem Lokal)
|Keamanan|517|Sukses|SISTEM; OTORITAS NT;(0x0,0x3E7);
Administrator;DOMAIN;(0x0,0x11544)
Berikut ini adalah pesan yang direkonstruksi:
Log audit telah dihapus
Nama Pengguna Utama: SYSTEM
Domain Utama: OTORITAS NT
ID Masuk Utama: (0x0,0x3E7)
Nama Pengguna Klien: Administrator
Domain Klien: DOMAIN
ID Masuk Klien: (0x0,0x11544)
Machine Translated by Google
Log Peristiwa 275
Contoh Kasus Nyata
Log peristiwa yang diambil dari memori sering kali terbukti bermanfaat dalam penyelidikan kami. Untuk
contoh di bagian ini, beberapa informasi, seperti alamat IP dan tanggal, telah disunting untuk
melindungi identitas korban.
Kasus Pendengar yang Tidak Berhasil
Penyerang sering kali suka memasang pintu belakang pada mesin yang disusupi. Ini membantu
mereka dengan mudah terhubung ke mesin di waktu senggang mereka. Output berikut adalah dari
plugin evtlogs pada log peristiwa Keamanan mesin yang dicurigai yang menunjukkan upaya aplikasi
yang gagal untuk menyiapkan port mendengarkan (ID peristiwa 861):
XXXX-XX-XX 23:18:46 UTC+0000|secevent.evt|XXXX|
S-1-5-21-1417001333-1647877149-682003330-500(Administrator)|Keamanan| 861|Kegagalan|wauclt;C:
\WINDOWS\system32\wauclt.exe;1900;Administrator; XXXX;Tidak;Tidak;IPv4;TCP;9999;Tidak;Tidak
XXXX-XX-XX 23:36:36 UTC+0000|secevent.evt|XXXX|
S-1-5-21-1417001333-1647877149-682003330-500(Administrator)|Keamanan| 861|Kegagalan|wauclt;C:
\WINDOWS\system32\wauclt.exe;2312;Administrator; XXXX;Tidak;Tidak;IPv4;TCP;9999;Tidak;Tidak
Dalam hal ini, kejadian ini mencurigakan karena file yang dapat dieksekusi (wauclt.exe) sebenarnya
tidak ada di mesin Windows secara default. Namanya telah dipilih sehingga tampak seperti proses
yang sah, wuauclt.exe, yaitu untuk pembaruan Windows (perhatikan bagian yang hilang ). Juga, jika
aplikasi yang dimaksud adalah sesuatu seperti notepad.exe (yang seharusnya tidak membuka port
sama sekali), log mungkin menunjukkan injeksi kode. Anda dapat membuat seluruh string pesan
dengan mencari template pesan secara online (http://www.eventid.net/ display.asp?
eventid=861&eventno=4615&source=Security&phase=1):
Nama: wauclt.exe
Jalur: C:\WINDOWS\system32\wauclt.exe
Pengidentifikasi proses: 2312
Akun pengguna: Administrator
Domain pengguna: XXXX (dihapus)
Layanan: Tidak
Server RPC: Tidak
Versi IP: IPv4
Protokol IP: TDP
Nomor pelabuhan: 9999
Diizinkan: Tidak
Pengguna diberitahu: Tidak.
Machine Translated by Google
276 Bagian II: Forensik Memori Windows
Kasus Logon yang Tidak Berhasil
Seperti yang telah Anda pelajari, peristiwa logon dan logoff dikumpulkan di log peristiwa Keamanan.
Dalam contoh berikut, dari server Windows 2003 yang disusupi, Anda melihat dua ID peristiwa 529
(upaya logon gagal) dan ID peristiwa 680. ID Peristiwa 680 bervariasi tergantung pada sistem
operasi mesin, tetapi melacak logon NTLM yang berhasil dan gagal untuk Windows 2003 mesin.
XXXX-XX-XX 15:19:20 UTC+0000|secevent.evt|XX|S-1-5-18 (Sistem Lokal)|Keamanan
|529|Gagal|administrator;ZZZZZ;3;NtLmSsp ;NTLM;ZZZZZ;-;-;-;-;-; 222.186.XX.XX;3054
XXXX-XX-XX 15:19:20 UTC+0000|secevent.evt|XX|S-1-5-18 (Sistem Lokal)|Keamanan
|680|Kegagalan|MICROSOFT_AUTHENTICATION_PACKAGE_V1_0;
administrator;ZZZZZ;0xC000006A
XXXX-XX-XX 15:19:20 UTC+0000|secevent.evt|XX|S-1-5-18 (Sistem Lokal)|Keamanan
|529|Gagal|administrator;ZZZZZ;3;NtLmSsp ;NTLM;ZZZZZ;-;-;-;-;-; 222.186.XX.XX;3061
Jika Anda mencari template pesan untuk event ID 529 (beberapa tautan dikutip sebelumnya di
bab ini), Anda mendapatkan lebih banyak konteks terkait peristiwa ini. String pesan lengkap yang
ditampilkan di penampil log peristiwa adalah teks berikut:
Kegagalan Logon
Alasan: Nama pengguna tidak dikenal atau kata sandi salah
Nama Pengguna: administrator
Domain: ZZZZZ (dihapus)
Tipe Logon: 3
Proses Logon: NtLmSsp
Paket Otentikasi: NTLM
Nama Workstation: ZZZZZ (dihapus)
Nama Pengguna Penelepon:-
Domain Penelepon:ID Logon Penelepon:ID Proses Penelepon:-
Layanan Transit:Alamat Jaringan Sumber: 222.186.XX.XX (dihapus)
Pelabuhan Sumber: 3061
Anda dapat melihat bahwa seseorang mencoba masuk sebagai administrator melalui jaringan
(Logon Type: 3), dan alamat IP jarak jauh berasal dari China (222.186.XX.XX). Karena mesin korban
berlokasi di Amerika Serikat, dan perusahaan pemilik tidak memiliki personel yang berlokasi di
China, aman untuk mengatakan bahwa ini bukan upaya logon yang valid. Jika Anda memeriksa
catatan peristiwa lain dengan ID 680 dengan cara yang sama, Anda akan mendapatkan lebih banyak
konteks mengapa logon ini tidak berhasil:
Upaya logon oleh: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Machine Translated by Google
Log Peristiwa 277
Masuk akun: administrator
Workstation Sumber: ZZZZZ (dihapus)
Kode Kesalahan: 0xC000006A
Kode kesalahan untuk acara ini didokumentasikan dengan baik (http://www.ultimatewindowssecurity .com/securitylog/
encyclopedia/event.aspx?eventid=680). Anda dapat melihat bahwa 0xC000006A berarti penyerang menggunakan nama
pengguna yang valid di sistem, tetapi kata sandi salah.
Jenis acara ini menunjukkan salah satu dari tiga hal:
• Akun adalah akun default untuk mesin • Penyerang telah melakukan
pengintaian sistem sebelumnya • Penyerang terlibat dalam upaya kekerasan untuk menebak
kredensial pada sistem
Dalam contoh ini, administrator adalah akun default. Namun, jika nama akun adalah sesuatu yang lain seperti
gstanley, dan Anda hanya menemukan beberapa upaya yang gagal (yaitu, bukan serangan brute force), Anda akan tahu
pasti bahwa penyerang telah melakukan pekerjaan rumah mereka.
Kasus Brute Forcer yang Tidak Sabar
Penyerang sering kali tidak memiliki kredensial yang valid untuk sebuah mesin saat mereka pertama kali menemukannya.
Dalam kasus tersebut, seperti yang baru saja kami jelaskan, mereka mungkin mencoba menerka dengan menggunakan
aplikasi yang mencoba beberapa kombinasi nama pengguna dan kata sandi. Upaya ini juga terwujud dalam log peristiwa
dan dapat menunjukkan bahwa mesin menjadi sasaran serta apakah penyerang berhasil mendapatkan akses. Dalam
kode berikut, Anda dapat melihat data log peristiwa yang mengilustrasikan jenis serangan ini pada mesin Windows 2003:
XXXX-XX-XX 14:49:07 UTC+0000|secevent.evt|XX|S-1-5-18 (Sistem Lokal)|Keamanan| 680|Kegagalan|
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0;administrator; DDDDDD;0xC000006A
XXXX-XX-XX 14:49:07 UTC+0000|secevent.evt|XX|S-1-5-18 (Sistem Lokal)|Keamanan|
529|Kegagalan|administrator;DDDDDD;3;NtLmSsp ;NTLM;
DDDDDD;-;-;-;-;-;XXX.XXX.XXX.XXX;0
XXXX-XX-XX 14:49:08 UTC+0000|secevent.evt|XX|S-1-5-18 (Sistem Lokal)|Keamanan|
529|Kegagalan|administrator;DDDDDD;3;NtLmSsp ;NTLM;
DDDDDD;-;-;-;-;-;XXX.XXX.XXX.XXX;0
XXXX-XX-XX 14:49:08 UTC+0000|secevent.evt|XX|S-1-5-18 (Sistem Lokal)|Keamanan| 680|Kegagalan|
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0;administrator; DDDDDD;0xC000006A [snip]
Machine Translated by Google
278 Bagian II: Forensik Memori Windows
Perhatikan bahwa kegagalan logon terjadi secara berurutan satu sama lain—dalam hal ini, dua upaya per detik.
Secara total, lebih dari 600 catatan seperti itu terjadi, semuanya dalam rentang waktu singkat. Alamat IP (dihapus)
juga ditentukan tidak memiliki alasan untuk terhubung ke mesin target.
Anda juga dapat menemukan bukti upaya kekerasan di log peristiwa sistem. Sebagai contoh, keluaran berikut
menunjukkan serangan terhadap sistem yang menjalankan layanan FTP Microsoft.
XXXX-XX-XX 13:34:38 UTC+0000|sysevent.evt|XXXX|T/A|MSFTPSVC|100|Peringatan| USERNAME
DIHAPUS;Kegagalan masuk: nama pengguna tidak dikenal atau kata sandi salah.
XXXX-XX-XX 13:34:38 UTC+0000|sysevent.evt|XXXX|T/A|MSFTPSVC|100|Peringatan| USERNAME
DIHAPUS;Kegagalan masuk: nama pengguna tidak dikenal atau kata sandi salah.
XXXX-XX-XX 13:34:39 UTC+0000|sysevent.evt|XXXX|N/A|MSFTPSVC|100|Peringatan| USERNAME
DIHAPUS;Kegagalan masuk: nama pengguna tidak dikenal atau kata sandi salah.
XXXX-XX-XX 13:34:39 UTC+0000|sysevent.evt|XXXX|N/A|MSFTPSVC|100|Peringatan| USERNAME
DIHAPUS;Kegagalan masuk: nama pengguna tidak dikenal atau kata sandi salah. [menggunting]
Sekali lagi, Anda melihat enam upaya masuk per detik menggunakan nama pengguna yang disunting. Ini sebuah
contoh pesan yang direkonstruksi:
Jenis Acara: Peringatan
Sumber Acara: MSFTPSVC
Kategori Acara: Tidak ada
ID Peristiwa: 100
Tanggal: X/X/XXXX
Waktu: 13:34:39
Pengguna: T/A
Komputer: XXXX
Deskripsi: Server tidak
dapat masuk ke akun Windows NT 'ZZZZ' karena kesalahan berikut: Kegagalan logon: nama pengguna tidak
diketahui atau sandi salah.
Kasus Penghapus Log
Seperti yang disebutkan sebelumnya, penyerang sering kali mencoba menghapus log peristiwa untuk menutupi jejak
mereka di mesin. Kami memiliki satu kasus di mana penyerang masuk ke mesin menggunakan kredensial curian
dan memulai pekerjaan di komputer lain menggunakan serangkaian kredensial curian yang berbeda. Tujuan kami
adalah melacak kedua akun yang disusupi untuk menonaktifkannya. Penyerang cukup pintar untuk menghapus log
peristiwa Keamanan serta beberapa lainnya yang akan membantu. Selain itu, kami tidak memiliki hard disk untuk
mencari ruang yang tidak terisi untuk catatan yang hilang. Untungnya, penyerang tidak menyadari bahwa ada log
peristiwa lain (Microsoft-Windows-TaskScheduler.evtx) yang berisi
Machine Translated by Google
Log Peristiwa 279
informasi yang kami butuhkan. Log ini merupakan penghuni memori dan memiliki catatan yang
mengarahkan kami langsung ke akun yang perlu kami nonaktifkan:
<TimeCreated SystemTime="XXXX-XX-XXT02:09:45.4119Z"/>
<EventRecordID>320320</EventRecordID> <Correlation/> <Execution
ProcessID="1120" ThreadID="8364" /> <Saluran>Microsoft-Windows
-TaskScheduler/Operasional</Channel> <Komputer>[DISUNTING]</
Komputer> <UserID="S-1-5-18" /></System Keamanan>
<EventData Name="TaskUpdated">
<Data Name="TaskName">\At2</Data>
<Data Name="UserName">DOMAIN\[DISUNTING]</Data></EventData></Event>
<Event xmlns ="http://schemas.microsoft.com/win/2004/08/events/event">
<Sistem>
Ringkasan
Selama penyelidikan, catatan log peristiwa Window sering memainkan peran penting dalam
merekonstruksi peristiwa suatu insiden. Mereka dapat memberikan wawasan berharga tentang
sejarah tentang apa yang terjadi dan kapan itu terjadi. Sementara penyelidik biasanya berfokus
pada catatan yang mereka temukan di disk, memori yang mudah menguap menyediakan sumber
berharga lainnya untuk artefak ini. Memahami cara mengekstrak dan menganalisis rekaman
penghuni memori tersebut di berbagai versi Windows memberikan kemampuan yang kuat untuk penyelidik digital.
Machine Translated by Google