SOC Analytics on Roduygo | Blog

Sysmon (Phần 1)

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Windows OS & SOC Analytics! Ở các bài viết trước, chúng ta đã học cách đọc nhật ký hệ thống (Event Logs) mặc định của Windows. Nhưng trong thực tế chiến đấu, các hacker ngày càng tinh vi, chúng thừa sức qua mặt những log cơ bản này. Đó là lúc các chuyên gia SOC phải viện đến “vũ khí hạng nặng”: Sysmon (System Monitor). Hôm nay, chúng ta sẽ đi sâu vào hướng dẫn cài đặt tư duy giám sát Sysmon, mở đầu bằng việc “mổ xẻ” quá trình sinh tiến trình (Process Creation) và cách dùng mã Hash để lột mặt nạ mã độc.

1. Sysmon là gì? Tại sao Windows Event Logs mặc định là chưa đủ?

Sysmon là một công cụ miễn phí cực kỳ mạnh mẽ thuộc bộ phần mềm Microsoft Sysinternals. Đối với giới bảo mật, Sysmon đã trở thành tiêu chuẩn vàng cho việc giám sát nâng cao.

Hãy làm một phép so sánh thực tế khi một phần mềm được mở lên:

Windows Event ID 4688 (Mặc định): Chỉ cho bạn biết “Ai đó vừa chạy một tiến trình mới” (ví dụ: cmd.exe vừa được chạy bởi Administrator).
Sysmon Event ID 1 (Process Creation): Không chỉ nói cho bạn biết file nào vừa chạy, mà nó còn cung cấp dấu vân tay (Mã Hash) của file đó, cho biết chính xác tiến trình nào đã gọi nó ra (Parent Image), và thậm chí là lệnh (Command Line) chi tiết đã được gõ vào.

Tóm lại: Windows EID 4688 cho biết “ai chạy”, còn Sysmon EID 1 cho biết “vân tay” của kẻ đó. Nếu không có mã Hash, bạn sẽ gần như “mù” trước các kỹ thuật đổi tên ngụy trang của Hacker.

2. Giải phẫu chi tiết Sysmon Event ID 1

Khi Sysmon Event ID 1 nổ ra, nó cung cấp cho SOC Analyst một bức tranh toàn cảnh không thể chối cãi. Hãy cùng “soi” vào các trường dữ liệu sinh tử của nó:

2.1 Thông tin định danh (Process Info)

ProcessId: Số định danh tiến trình trong hệ thống.
Image: Đường dẫn vật lý của file thực thi trên ổ cứng (VD: C:\Windows\System32\cmd.exe).
CommandLine: Ghi lại chính xác từng chữ mà kẻ tấn công đã gõ vào lệnh.

2.2 Nguồn gốc khởi tạo (Parent Info)

Mã độc hiếm khi tự nhiên sinh ra. Nó luôn được một thứ gì đó gọi ra.

ParentImage: Đây là tiến trình cha. Việc nhìn vào tiến trình cha giúp bạn biết lệnh này do người dùng click chuột mở (như từ explorer.exe) hay bị gọi ngầm bởi một đoạn mã độc.

2.3 Dấu vân tay của tệp (Binary Info)

Hashes: Sysmon sẽ tự động tính toán mã Hash (như MD5, SHA256) của file thực thi ngay khi nó chạy. Đây là tính năng “đáng tiền” nhất của Sysmon.

3. “Bắt thóp” Mã độc: Kỹ năng Threat Hunting thực chiến

Với các thông tin từ Sysmon EID 1, làm sao để phát hiện bất thường? Đừng tìm kiếm ngẫu nhiên, hãy bám vào 3 dấu hiệu (Red Flags) sau:

Kỹ thuật 1: Lột mặt nạ ngụy trang (Masquerading) bằng mã Hash

Hacker hiểu rằng nếu chạy một file có tên virus_an_cap.exe, chúng sẽ bị tóm ngay. Vì thế, chúng thường đổi tên mã độc thành các tiến trình hệ thống chuẩn như cmd.exe, svchost.exe hay lsass.exe.

Tuy nhiên, dù tên file có đổi, mã Hash thì không bao giờ thay đổi. Khi Sysmon ghi lại mã SHA256 của tiến trình cmd.exe giả mạo đó, bạn chỉ cần ném mã Hash đó lên VirusTotal. Mã Hash sẽ lập tức “tố cáo” đó là một file độc hại chứ không phải file chuẩn của Microsoft.

Kỹ thuật 2: Phân tích Phả hệ Tiến trình (Parent-Child Anomalies)

Đây là kỹ năng “nhìn thấu” logic hoạt động của hệ thống. Những tiến trình cha - con sau đây là cực kỳ phi logic và chắc chắn là mã độc:

WINWORD.EXE (Microsoft Word) sinh ra powershell.exe hoặc cmd.exe: Rất có thể một nhân viên vừa mở file Word chứa mã độc Macro, và nó đang gọi lệnh tải virus về máy.
notepad.exe sinh ra cmd.exe: Notepad chỉ là phần mềm gõ văn bản, nó tuyệt đối không có lý do gì để gọi cửa sổ dòng lệnh.

Kỹ thuật 3: Truy vết các đường dẫn và câu lệnh đáng ngờ

Bạn cần cấu hình SIEM (hoặc viết script PowerShell) báo động ngay lập tức nếu tiến trình (Image) được chạy từ các thư mục trú ẩn quen thuộc của malware như:

C:\Users\*\AppData\Local\Temp\
C:\Users\Public\

Bên cạnh đó, hãy soi kỹ trường CommandLine. Hacker thường dùng các lệnh sau để tải mã độc thẳng vào RAM hoặc giải mã script:

-EncodedCommand (Chạy mã PowerShell đã mã hóa Base64)
IEX (New-Object Net.WebClient) (Lệnh tải file từ Internet)
certutil -urlcache hoặc bitsadmin /transfer (Lợi dụng phần mềm có sẵn của Windows để tải virus)

4. Thực hành truy vấn Sysmon bằng PowerShell

Thay vì click chuột mỏi tay trong Event Viewer, các Threat Hunter thường dùng PowerShell để săn lùng (Hunting) dấu vết tiến trình độc hại. Dưới đây là đoạn code mẫu giúp bạn trích xuất tất cả các lần powershell.exe được gọi ra bởi thư mục Temp:

# Truy vấn Sysmon Event ID 1 (Process Create)
$Query = "*[System[EventID=1]]"

# Lọc các sự kiện có Image là powershell và ParentImage nằm trong thư mục Temp
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -FilterXPath $Query | 
 Where-Object {
 $_.Message -match "Image: .*powershell\.exe" -and 
 $_.Message -match "ParentImage: .*\\Temp\\.*"
 } | Format-List TimeCreated, Message

Bằng cách tận dụng Sysmon Event ID 1, bạn đã bịt được lỗ hổng khổng lồ của Event Viewer mặc định. Mã Hash và Cây tiến trình (Parent-Child) chính là hai thanh gươm sắc bén nhất để lột mặt nạ mọi loại mã độc ngụy trang. Trong bài viết tới (Phần 2), chúng ta sẽ tiếp tục đi sâu vào các Event ID khác của Sysmon (EID 3, 10, 11) để truy vết mã độc tàng hình (Fileless Malware) và hành vi ăn cắp mật khẩu. Hẹn gặp lại các bạn!

Sysmon (Phần 2)

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Phần 2 của loạt bài về Sysmon trong Series Giải phẫu Windows OS & SOC Analytics! Ở phần trước, chúng ta đã dùng Event ID 1 để “bắt thóp” mã độc dựa vào mã Hash. Nhưng nếu mã độc không tồn tại dưới dạng file trên ổ cứng thì sao? Nếu chúng chạy thẳng trên RAM, hoặc âm thầm chọc ngoáy vào tiến trình hệ thống để ăn cắp mật khẩu? Hôm nay, chúng ta sẽ mở khóa sức mạnh thực sự của Sysmon với bộ 3 Event ID sinh tử: 3, 10 và 11 để chống lại những kỹ thuật lẩn tránh (Evasion) tinh vi nhất.

1. Event ID 10 (Process Access): “Kính lúp” soi bộ nhớ và Fileless Malware

Trong hệ điều hành Windows, các tiến trình (Process) vốn dĩ nằm trong các không gian bộ nhớ biệt lập. Tuy nhiên, mã độc thường xuyên tìm cách “chọc” vào vùng nhớ của các tiến trình hệ thống hợp lệ để ăn cắp dữ liệu hoặc tiêm mã độc (Process Injection) nhằm che giấu hành vi.

Đây là lúc Sysmon Event ID 10 (Process Access) tỏa sáng. Trong khi Windows mặc định dùng Event ID 4656 nhưng rất khó cấu hình, Sysmon EID 10 cung cấp bức tranh rõ nét về việc tiến trình nào đang đòi quyền truy cập vào tiến trình nào.

Đặc biệt, EID 10 là “khắc tinh” của hai hành vi sau:

Dump mật khẩu LSASS: Hacker thường nhắm vào tiến trình lsass.exe để trích xuất mật khẩu. EID 10 sẽ cảnh báo ngay nếu một file lạ xin quyền truy cập vào lsass.exe.
Tiêm mã độc vào RAM (Kỹ thuật tàng hình/Fileless): Dưới đây là một ví dụ thực chiến từ log Sysmon:

Source Image: C:\Users\sarah.miller\Downloads\ckjg.exe
Target Image: C:\Windows\System32\Wbem\wmic.exe
Granted Access: 0x1FFFFF
CallTrace: C:\Windows\SYSTEM32\ntdll.dll+...|UNKNOWN(00007FF7CE73CB77)

Phân tích góc nhìn SOC:

Một file có tên ngẫu nhiên ckjg.exe tải về từ thư mục Downloads lại đi chọc vào công cụ quản lý hệ thống wmic.exe của Windows.
Quyền truy cập là 0x1FFFFF (Full Access) – một quyền tối thượng cực kỳ đáng ngờ.
Đáng chú ý nhất là trường CallTrace. Nó hiển thị chuỗi thư viện được gọi, nhưng ở đoạn cuối lại xuất hiện vùng nhớ UNKNOWN(00007FF7CE73CB77). Điều này cho thấy mã thực thi đang chạy ở một vùng nhớ không xác định, một dấu hiệu kinh điển của việc mã độc giải nén (unpack) shellcode trực tiếp vào RAM để né phần mềm diệt virus quét file vật lý.

2. Event ID 11 (File Creation): Theo dấu các điểm neo Persistence

Hacker có thể chạy mã độc trên RAM, nhưng để duy trì sự hiện diện (Persistence) qua những lần khởi động lại máy, chúng buộc phải để lại một thứ gì đó trên ổ đĩa. Thay vì cấu hình Audit Object Access phức tạp để lấy Event ID 4663 của Windows, Sysmon Event ID 11 mặc định ghi lại toàn bộ các file thực thi được tạo ra.

Dựa vào tiến trình đáng ngờ ckjg.exe ở trên, nếu ta tra cứu tiếp Event ID 11, ta sẽ bắt được ngay hành động giấu file của nó:

ProcessId: 1460
Image: C:\Users\sarah.miller\Downloads\ckjg.exe
TargetFilename: C:\Users\sarah.miller\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\DeleteApp.url

Chỉ với một log duy nhất, Sysmon EID 11 đã vạch trần việc mã độc vừa âm thầm tạo một file khởi động tên là DeleteApp.url nhét thẳng vào thư mục Startup của người dùng để kích hoạt cùng hệ thống.

3. Event ID 3 (Network Connection): Bắt tại trận Reverse Shell

Mã độc lấy cắp dữ liệu xong thì phải gửi ra ngoài, hoặc nó cần kết nối về máy chủ C2 (Command & Control) để nhận lệnh.

Nhật ký tường lửa mặc định của Windows (EID 5156) thường sinh ra quá nhiều “rác” (noise), nhưng Sysmon Event ID 3 lại là một tuyệt tác vì nó gắn trực tiếp kết nối mạng đó với một tiến trình cụ thể.

Khi soi tiếp tiến trình ckjg.exe bằng EID 3, ta thu được:

Protocol: tcp
Source IP: 10.10.57.125 (Máy nạn nhân)
Destination IP: 193.46.217.4
Destination Port: 7777

[Mẹo SOC]: Cổng 7777 thường không phải là cổng dịch vụ chuẩn. Sự kết hợp giữa một tiến trình rác trong thư mục Downloads, thực hiện Process Injection (EID 10), thả file vào Startup (EID 11) và mở cổng TCP ra IP bên ngoài (EID 3) là một bằng chứng 100% về một cuộc tấn công Reverse Shell đang diễn ra.

4. Đối đối phó với Timestomping và Fileless nâng cao

4.1 Timestomping (Giả mạo thời gian)

Trong quá trình điều tra Forensics, timeline là yếu tố sống còn. Để đánh lừa các nhà phân tích, hacker sử dụng kỹ thuật Timestomping – dùng công cụ sửa đổi ngày tạo (Creation Time) của mã độc lùi về quá khứ để trông giống như một tệp hệ thống đã tồn tại từ lâu.

Ví dụ, trong một ổ đĩa FAT32 bị điều tra, ta có thể thấy một file install.txt có thời gian truy cập cuối (Accessed Time) là năm 2018, nhưng thời gian tạo (Created Time) lại là năm 2025. Đây là dấu vết thao túng thời gian rõ rệt.

Để bắt được hành vi này ngay lập tức, ta sử dụng Sysmon Event ID 2. Nếu Windows Event ID 4670 chỉ đơn thuần ghi nhận thay đổi quyền/thuộc tính, thì Sysmon EID 2 được thiết kế đặc biệt để phát hiện và cảnh báo ngay khi có kẻ cố tình sửa đổi thời gian tạo của tệp tin.

4.2 Giám sát Fileless qua PowerShell (Event ID 4104)

Khi nói đến mã độc không để lại file, PowerShell là công cụ bị lạm dụng nhiều nhất. Hacker sẽ truyền các chuỗi lệnh đã mã hóa Base64 thẳng vào RAM. Nếu chỉ nhìn Sysmon EID 1, bạn sẽ chỉ thấy câu lệnh powershell -encodedCommand ... vô nghĩa.

Để đối phó, SOC Analyst phải bật tính năng Script Block Logging (Event ID 4104) trong nhánh Microsoft-Windows-PowerShell/Operational. Ngay cả khi hacker mã hóa code, PowerShell bắt buộc phải tự giải mã nó trên RAM để thực thi. Lúc này, EID 4104 sẽ chộp lại và lưu trữ toàn bộ nội dung code dạng nguyên bản (clear-text).

Bạn cũng có thể theo dõi Event ID 4103 (Module Logging) để xem chính xác các tham số và biến số (Parameter Binding) nào đã được nạp vào, giúp truy vết tận gốc nguồn tài nguyên độc hại.

Bằng cách kết hợp Sysmon (EID 3, 10, 11) cùng các nhật ký giám sát PowerShell, bạn đã dựng lên một lưới điện an ninh dày đặc. Mã độc có thể đổi tên, giấu file, giả mạo thời gian hay chạy trên RAM, nhưng chúng không bao giờ có thể xóa bỏ hoàn toàn những chuỗi hành vi logic mà chúng tạo ra trên hệ điều hành. Chúc các bạn áp dụng hiệu quả vào hệ thống SIEM của mình để trở thành một Threat Hunter xuất sắc!

Tổng quan Windows Event Logs và kỹ năng lọc log bằng PowerShell XML

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn quay trở lại với Series Giải phẫu Windows OS & SOC Analytics! Bất kỳ một tên trộm nào khi đột nhập cũng sẽ cố gắng xóa dấu vết, trốn tránh camera. Trong hệ điều hành Windows, “camera an ninh” đó chính là Event Logs (Nhật ký sự kiện). Mã độc có thể ẩn mình dưới lớp vỏ bọc svchost.exe hay lách qua UAC, nhưng mọi hành động của chúng đều để lại những “gợn sóng” trong nhật ký hệ thống. Hôm nay, chúng ta sẽ học cách đọc hiểu các Event ID sinh tử và sử dụng PowerShell kết hợp XML để truy vết hacker với tốc độ ánh sáng!

1. Tổng quan về Windows Event Logs

Event Logs là nơi lưu trữ mọi “nhịp đập” của máy tính. Bất kể là bạn cắm một chiếc USB, cài một phần mềm, khởi động dịch vụ hay gõ sai mật khẩu, Windows đều ghi chép lại một cách tỉ mỉ.

1.1 Phân loại Nhật ký (Log Types)

Hệ thống phân chia nhật ký thành nhiều nhánh để dễ quản lý:

System (Hệ thống): Ghi lại các sự kiện liên quan đến hệ điều hành, thay đổi phần cứng, khởi động/tắt máy và hoạt động của trình điều khiển (Driver).
Security (Bảo mật): Đây là mỏ vàng của SOC. Ghi lại các sự kiện Đăng nhập/Đăng xuất (Logon/Logoff), thay đổi quyền hạn và quản lý người dùng.
Application (Ứng dụng): Ghi lại lỗi phần mềm (crash), cảnh báo từ các ứng dụng cài đặt trên máy.

1.2 Mức độ Sự kiện (Event Levels)

Mỗi sự kiện được gắn một mức độ nghiêm trọng:

Information: Hoạt động bình thường, thành công.
Warning: Có vấn đề tiềm tàng nhưng chưa làm sập chức năng (ví dụ: ổ đĩa sắp đầy).
Error: Vấn đề nghiêm trọng (mất dữ liệu, phần mềm bị crash).
Success/Failure Audit: Cực kỳ quan trọng trong nhánh Security, ghi nhận các nỗ lực truy cập tài nguyên (đăng nhập đúng hoặc sai pass).

Góc nhìn SOC - Cấu hình dung lượng Log: Mặc định, file log (như Security.evtx) bị giới hạn dung lượng (thường là 20MB) và được cấu hình ghi đè sự kiện cũ nhất (Overwrite events as needed). Hacker hiểu điều này, chúng có thể “xả rác” (Spam logs) để đẩy các log độc hại trôi đi mất. Do đó, trên các máy chủ quan trọng, quản trị viên thường phải chỉnh thành cấu hình Archive the log when full (Nén lại khi đầy) để không mất dấu vết lịch sử.

2. Từ điển Event ID “Gối đầu giường” của SOC

Để săn tìm mã độc, bạn không thể đọc từng dòng log một. Bạn phải thuộc lòng những Event ID (EID) mang tính “chỉ điểm” sau đây:

2.1 Nhóm Application (Ứng dụng)

EID 1000 (Application Error): Phần mềm bị treo cứng và tự đóng. Nếu một dịch vụ quan trọng (như lsass.exe) liên tục báo lỗi 1000, có thể hacker đang dùng tool dump bộ nhớ bị lỗi.
EID 11724 (MsiInstaller): Thông báo một phần mềm vừa bị gỡ bỏ. Nếu phần mềm bị gỡ là Antivirus, đây là báo động đỏ cực độ (Red Flag)!

2.2 Nhóm System (Hệ thống)

EID 12 / 13: Máy tính bắt đầu Boot (12) và Tắt máy bình thường (13).
EID 7040: Thay đổi loại khởi động của một dịch vụ (ví dụ: bật lại một dịch vụ từ Disable sang Auto).
EID 7045: Một dịch vụ (Service) mới vừa được cài đặt. Hacker cực kỳ thích cài “Backdoor” dưới dạng một Service để tự chạy ngầm cùng quyền LocalSystem.

2.3 Nhóm Security (Bảo mật) - Trái tim của SOC

EID 4624 (Logon Success): Đăng nhập thành công. Cần soi kỹ Logon Type (Type 2 là ngồi gõ trực tiếp, Type 3 là qua mạng/Share, Type 10 là Remote Desktop).
EID 4625 (Logon Failure): Gõ sai pass. Nếu EID này xuất hiện dồn dập hàng loạt với nhiều user khác nhau, bạn đang đối mặt với tấn công Password Spraying hoặc Brute Force.
EID 4672 (Special Logon): Phiên đăng nhập được gán đặc quyền Admin (SYSTEM). Nếu một tài khoản người dùng thường (như nhân viên lễ tân) có log này, họ đã leo quyền (Privilege Escalation) thành công.
EID 4720 (User Created) & 4732 (Added to Group): Hacker tạo tài khoản Backdoor mới và nhét nó vào nhóm Administrators. Mọi sự kiện 4732 tác động vào nhóm Admin đều phải được điều tra lập tức.
EID 4688 (Process Creation): Ghi nhận một tiến trình/câu lệnh mới vừa chạy. Kết hợp dòng log này, ta biết chính xác mã độc đã gõ lệnh gì trên CMD/PowerShell.
EID 1102 (Log Cleared): Nhật ký an ninh đã bị xóa trắng. Dấu vết lẩn trốn rõ ràng nhất.

3. Giải phẫu cấu trúc XML của một Sự kiện

Mở giao diện Event Viewer (Friendly View) và bấm xem bằng mắt thường rất dễ hiểu, nhưng lại quá chậm để tự động hóa. Thực chất, giao diện này chỉ là bản “dịch” lại từ ngôn ngữ lưu trữ gốc của Windows: XML.

Chuyển sang tab XML View, bạn sẽ thấy một sự kiện luôn chia làm 2 khối chính:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <!-- KHỐI SYSTEM: Chứa siêu dữ liệu chung -->
 <System>
 <Provider Name="Microsoft-Windows-Security-Auditing" ... />
 <EventID>4672</EventID>
 <Level>0</Level>
 <TimeCreated SystemTime="2026-02-02T17:22:57.0339579Z" />
 <Execution ProcessID="1504" ThreadID="1600" />
 <Computer>NguyenDuy</Computer>
 </System>
 
 <!-- KHỐI EVENT DATA: Phần "thịt" chứa thông tin điều tra -->
 <EventData>
 <Data Name="SubjectUserSid">S-1-5-18</Data>
 <Data Name="SubjectUserName">SYSTEM</Data>
 <Data Name="PrivilegeList">SeAssignPrimaryTokenPrivilege
 SeSecurityPrivilege
 SeTakeOwnershipPrivilege
 SeDebugPrivilege
 SeImpersonatePrivilege</Data>
 </EventData>
</Event>

Tại sao phải quan tâm XML? Bởi vì những thông tin sinh tử như Tên tài khoản (SubjectUserName) hay Đặc quyền (PrivilegeList) được giấu sâu bên trong các node <Data>. Nếu bạn hiểu cấu trúc này, bạn có thể viết script lọc ra chính xác các đăng nhập mờ ám có đặc quyền SeDebugPrivilege (đặc quyền cho phép can thiệp bộ nhớ, cực kỳ nguy hiểm, thường dùng để dump mật khẩu lsass.exe).

4. Kỹ năng lọc log thực chiến bằng PowerShell (XPath)

Event Viewer rất nặng và chậm khi load hàng chục GB logs. Thay vào đó, SOC Analyst sử dụng PowerShell với Cmdlet Get-WinEvent kết hợp cú pháp truy vấn XPath để quét logs trong chớp mắt.

4.1 Thống kê nhanh bằng Wevtutil

Để đếm tổng số tệp nhật ký trên máy mà không cần mở giao diện đồ họa, bạn có thể dùng lệnh:

wevtutil.exe el | find /c /v ""

(Lệnh này liệt kê tất cả các log el và đếm tổng số dòng)

4.2 Săn tìm mã độc với Get-WinEvent & XPath

Giả sử bạn nghi ngờ có kẻ đang liệt kê danh sách nhóm cục bộ (Event ID 4798) để tìm nhóm Admin. Thay vì cuộn chuột thủ công, hãy ném cú pháp XPath này vào PowerShell:

# Lọc toàn bộ Log Security, chỉ lấy các sự kiện có Event ID = 4798
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4798)]]"

Nâng cao hơn: Lọc dựa trên EventData (Dữ liệu bên trong) Nếu bạn muốn tìm đích danh Log Logon thất bại (EID 4625) nhưng chỉ lọc các lần thất bại có mã lỗi 0xC0000064 (Tên người dùng không tồn tại - Dấu hiệu của việc dò quét tài khoản), bạn có thể viết Rule XPath truy vấn thẳng vào lớp <EventData>:

# Tìm các log đăng nhập sai (4625) với mã lỗi (Status) là 0xC0000064
$Query = "*[System[EventID=4625] and EventData[Data[@Name='Status']='0xc0000064']]"
Get-WinEvent -LogName Security -FilterXPath $Query | Select-Object TimeCreated, Message

Sức mạnh của XPath cho phép các nhà phân tích SOC trích xuất hàng triệu sự kiện (Events) chỉ trong vài giây, và đây cũng chính là cơ sở cốt lõi để xây dựng các tập luật (Rules) tự động cho hệ thống SIEM (như Wazuh hay Splunk).

Như vậy, chúng ta đã nắm trong tay cách hệ điều hành “ghi sổ” mọi biến động. Bằng cách làm chủ các mã Event ID và kỹ thuật lọc XML bằng PowerShell, bạn đã biến mình từ một người bị động trở thành một “thợ săn” (Threat Hunter) chủ động đi tìm những bất thường trên hệ thống. Ở bài viết tới, chúng ta sẽ tìm hiểu về cách kết hợp Event Logs với Sysmon (System Monitor) – một công cụ biến nhật ký Windows thành hệ thống giám sát cấp độ quân sự. Đừng bỏ lỡ nhé!

Truy vết Đăng nhập

Fri, 08 May 2026 12:00:00 +0700

Chào mừng các bạn tiếp tục với Series Giải phẫu Windows OS & SOC Analytics! Bất kỳ cuộc tấn công mạng nào, dù tinh vi đến đâu, cũng thường bắt đầu hoặc kết thúc bằng việc kẻ tấn công cố gắng “gõ cửa” hệ thống qua cơ chế đăng nhập. Đối với một nhà phân tích SOC, nhánh Security Logs là mỏ vàng, và các sự kiện Đăng nhập/Đăng xuất (Logon/Logoff) chính là chìa khóa để nhận diện kẻ xâm nhập. Hôm nay, chúng ta sẽ “mổ xẻ” bộ 3 Event ID sinh tử: 4624, 4625, 4648 cùng từ điển Logon Types để vạch trần mọi kỹ thuật dò mật khẩu hay mạo danh trên hệ thống.

1. Từ điển “Logon Types”: Ngôn ngữ giao tiếp của Hệ điều hành

Khi bạn phân tích một log đăng nhập (dù thành công hay thất bại), việc chỉ nhìn vào tài khoản (Account Name) là chưa đủ. Bạn bắt buộc phải nhìn vào Logon Type (Cách thức đăng nhập) để biết kẻ đó đang “vào nhà” bằng cửa chính, cửa sổ hay leo rào.

Dưới đây là các Logon Type quan trọng nhất mà một SOC Analyst phải thuộc nằm lòng:

Type 2 (Interactive): Đăng nhập tương tác trực tiếp. Nghĩa là người dùng (hoặc kẻ tấn công) đang thực sự ngồi trước bàn phím vật lý của cái máy tính đó để gõ mật khẩu.
Type 3 (Network): Truy cập qua mạng. Thường thấy khi người dùng truy cập vào thư mục dùng chung (File Share), máy in mạng hoặc khi một tập lệnh từ xa được thực thi.
Type 4 (Batch): Đăng nhập dạng khối. Thường được sử dụng bởi các tác vụ lập lịch (Scheduled Tasks) tự động chạy định kỳ.
Type 5 (Service): Đăng nhập dạng dịch vụ. Đây là lúc một dịch vụ hệ thống khởi chạy ngầm dưới quyền một tài khoản cụ thể. Góc nhìn SOC: Nếu hàng trăm log Type 5 nổ ra từ các dịch vụ lạ, có thể mã độc đang tự động gọi tiến trình (spawn process) hàng loạt.
Type 10 (Remote Interactive): Đăng nhập qua Remote Desktop Protocol (RDP). Đây là Logon Type bị hacker lợi dụng nhiều nhất để tấn công từ xa.

2. Event ID 4625: Tiếng “gõ cửa” của kẻ lạ mặt (Logon Failure)

Mỗi khi có người nhập sai mật khẩu, Windows sẽ sinh ra Event ID 4625. Một vài log 4625 rải rác là bình thường (do người dùng gõ nhầm), nhưng nếu nó nổ ra hàng loạt, hệ thống của bạn đang bị tấn công.

Để biết chính xác mục tiêu của kẻ tấn công, chúng ta dựa vào trường Status và Sub Status (Mã lỗi):

0xC000006A (Bad Password): Tài khoản có tồn tại, nhưng gõ sai mật khẩu.
0xC0000064 (User Does Not Exist): Tên người dùng không tồn tại. Nếu bạn thấy mã này nhiều lần, hacker đang thực hiện dò quét liệt kê tài khoản (Username Enumeration).
0xC0000234 (Account Locked): Đăng nhập vào một tài khoản đã bị khóa do gõ sai quá số lần quy định.

2.1 Kỹ năng phân biệt Brute Force và Password Spraying

Brute Force (Vét cạn): Hacker nhắm vào 1 tài khoản (VD: Administrator) và thử hàng nghìn mật khẩu khác nhau. Dấu hiệu: Nhiều log 4625 liên tiếp, cùng một Account Name, mã lỗi 0xC000006A, dồn dập trong vài giây từ một IP lạ (Source Network Address).
Password Spraying (Phun mật khẩu): Để tránh bị khóa tài khoản (Account Lockout), hacker lấy 1 mật khẩu phổ biến (VD: “Admin@123”) và thử lần lượt trên hàng trăm user khác nhau. Dấu hiệu: Nhiều log 4625, cùng một IP nguồn, nhưng Account Name thay đổi liên tục, xuất hiện mã lỗi trộn lẫn giữa 0xC000006A và 0xC0000064.

3. Event ID 4624: Khi cánh cửa mở ra (Logon Success)

Event ID 4624 cho biết một tài khoản đã đăng nhập thành công vào hệ thống. Nếu log này xuất hiện ngay sau một chuỗi dài các log 4625, xin chia buồn, hệ thống của bạn đã bị xuyên thủng!

Mẹo điều tra với RDP (Network Level Authentication - NLA): Khi hệ thống bật tính năng xác thực cấp mạng (NLA) cho Remote Desktop, quy trình sinh log sẽ hơi “đánh lừa” bạn một chút:

Đầu tiên, máy khách gửi thông tin xác thực lên. Windows xử lý việc này như một kết nối mạng thông thường và ghi nhận Log 4624 với Logon Type 3.

Sau khi xác thực Type 3 thành công, phiên giao diện đồ họa RDP mới thực sự được vẽ ra. Lúc này Windows mới tiếp tục ghi nhận thêm một Log 4624 với Logon Type 10.

Khi điều tra, bạn nhớ ghi lại trường thông tin Logon ID (VD: 0x183C36D). Đây là mã định danh phiên làm việc, giúp bạn xâu chuỗi mọi hoạt động (tạo tiến trình, truy cập file) mà tài khoản đó thực hiện sau khi vào máy.

4. Event ID 4648: Kỹ thuật Mạo danh (Explicit Credentials)

Hacker không phải lúc nào cũng đăng nhập từ bên ngoài vào. Nếu chúng đã lọt vào máy bạn dưới quyền một người dùng thường (nhân viên lễ tân), chúng sẽ cố gắng mạo danh Admin bằng kỹ thuật sử dụng thông tin xác thực rõ ràng (Explicit Credentials) - sinh ra Event ID 4648.

Log 4648 ghi lại việc một tiến trình cố gắng đăng nhập vào một tài khoản bằng cách “mượn” danh tính (như lệnh runas) thay vì đăng nhập trực tiếp qua màn hình.

Dấu hiệu báo động đỏ (Red Flag) từ 4648:

SubjectUserName: Người dùng thường.
TargetUserName: Administrator hoặc Service account.
Process Name: Bình thường sẽ là explorer.exe hoặc mmc.exe. Nếu bạn thấy tiến trình thực hiện hành động này là powershell.exe, cmd.exe hoặc rundll32.exe, 100% đó là mã độc đang thực hiện leo thang đặc quyền (Privilege Escalation) hoặc di chuyển ngang (Lateral Movement) sang máy chủ khác.

5. Thực chiến SOC: Viết Rule giám sát bằng SIEM (Wazuh)

Đứng ở góc độ một SOC Analyst, chúng ta không đếm log bằng tay mà sẽ cấu hình các SIEM rule tự động báo động. Dưới đây là ví dụ cấu hình mã XML cho Wazuh để phát hiện hành vi Brute Force và Password Spraying:

Phát hiện Brute Force (Vét cạn 1 tài khoản)

Rule này sẽ cảnh báo nếu có 5 lần gõ sai mật khẩu (EID 4625) vào cùng một tài khoản trong vòng 60 giây:

<rule id="100001" level="10">
 <if_sid>4625</if_sid>
 <frequency>5</frequency>
 <timeframe>60</timeframe>
 <same_field>win.eventdata.TargetUserName</same_field>
 <description>Multiple failed logon - possible brute force nhắm vào 1 tài khoản</description>
</rule>

Phát hiện Password Spraying (Phun mật khẩu qua RDP)

Rule này cực kỳ sắc bén: Nếu Logon Type là 10 (RDP) bị lỗi sai mật khẩu (0xC000006A) trên 5 tài khoản khác nhau trong vòng 5 phút (300 giây):

<rule id="100013" level="12">
 <if_sid>4625</if_sid>
 <field name="win.eventdata.LogonType">10</field>
 <field name="win.eventdata.Status">0xC000006A</field>
 <different_field>win.eventdata.TargetUserName</different_field>
 <frequency>5</frequency>
 <timeframe>300</timeframe>
 <description>RDP Password Spray - {frequency} tài khoản khác nhau đăng nhập RDP thất bại trong {timeframe} giây</description>
</rule>

Việc đọc hiểu cấu trúc Event Logs liên quan đến Authentication là kỹ năng nền tảng giúp SOC Analyst phân tách được các nỗ lực truy cập mạng hợp lệ khỏi các chiến dịch xâm nhập. Chỉ cần bắt được một gợn sóng nhỏ từ 4625 hay 4648, bạn hoàn toàn có thể chặt đứt cuộc tấn công ngay từ lúc kẻ gian đang đứng ngoài cửa. Ở bài viết tiếp theo, chúng bản phân tích kỹ hơn về dấu vết của Hacker sau khi chúng đã xâm nhập: Quản lý người dùng, tạo Backdoor và các log báo hiệu bị thay đổi đặc quyền (EID 4672, 4720, 4732). Hãy cùng theo dõi nhé!