Sysmon là một công cụ trong bộ công cụ Sysinternal của do Microsoft cung cấp, hỗ trợ ghi thêm một số loại log mà Event log bình thường không lưu trữ mặc định. Sysmon sẽ chạy dưới dạng một Window Service và tùy theo cấu hình sẽ tạo ra các log trong folder “Application and Services Logs\Microsoft\Windows\Sysmon\Operation”
Hình 1 Vị trí log Sysmon
Sysmon Event ID
Tương tự như các sự kiện khác được lưu trong Event log của Windows, Sysmon cũng có hệ thống Event ID dùng cho các sự kiện mà mình ghi lại. Để có thể xem chi tiết về các sự kiện mà phiên bản hiện tại đang hỗ trợ có thể xem schema của phiên bản dưới dạng XML bằng cách chạy lệnh:
| sysmon.exe -s |
Tại thời điểm của bài viết là tháng 12/2024, phiên bản Sysmon mới nhất có thể tải về từ trang web chính thức của Microsoft là 15.15.các sự kiện phiên bản này hỗ trợ bao gồm:
Event ID 1: Process creation: Cung cấp thông tin về các tiến trình mới được tạo
Hình 2 Định nghĩa các trường dữ liệu Sysmon Event ID 1
Trong số các trường dữ liệu này có rất nhiều các thông tin quan trọng trong quá trình giám sát như:
- ProcessId: Id của tiến trình được tạo ra
- Image: file thực thi để chạy tiến trình
- CommandLine: cho biết các câu lệnh kèm tham số, tùy chọn được dùng để chạy tiến trình.
- User: tài khoản người dùng chạy tiến trình
- ParentProcessId, ParentImage và ParentCommandLine: cho biết các thông tin về tiến trình cha của tiến trình hiện tại.
- Đặc biệt ProcessGUID: là giá trị định danh duy nhất của tiến trình trong môi trường có Domain để giúp việc giám sát và phân tích sự kiện dễ hơn tránh trùng lặp.
Event ID 2: A process changed a file creation time: ghi nhận một tiến trình thực hiện thay đổi thời gian tạo một file trên thiết bị
Hình 3 Định nghĩa các trường dữ liệu Sysmon Event ID 2
Trên thực tế các kẻ tấn công có thể thay đổi thời gian tạo file để làm rối quá trình điều tra, sự kiện này sẽ ghi nhận thời gian tạo file thực tế đã bị thay đổi trước đó thông qua trường dữ liệu “PreviousCreationUtcTime”
Event ID 3: Network connection: ghi nhận một kết nối TCP/UDP, cung cấp các thông tin về process ID, port nguồn/đích, IP nguồn/đích
Hình 4 Định nghĩa các trường dữ liệu Sysmon Event ID 3
Event ID 4: Sysmon service state changed: ghi lại thay đổi trạng thái của Sysmon service.
Event ID 5: Process terminated: ghi nhận thời điểm một tiến trình kết thúc
Hình 5 Định nghĩa các trường dữ liệu Sysmon Event ID 4 và 5
Event ID 6: Driver loaded: cung cấp thông tin về driver được load trên thiết bị.
Event ID 7: Image loaded: ghi nhận khi một module được load lên một tiến trình.
Hình 6 Định nghĩa các trường dữ liệu Sysmon Event ID 6 và 7
Các thông tin quan trọng các sự kiện này sẽ bao gồm một số trường dữ liệu quan trọng:
- Image load: vị trí file thực thi được load lên
- Hash: mã hash của file thực thi, dựa trên giá trị này có thể nhận biết tính toàn vẹn của một file thực thi.
- Signed, Signature, SignatureStatus: thông tin về signature của file thực thi
Việc ghi nhận thời điểm và các file thực thi được load vào dưới dạng driver hoặc tiến trình rất quan trọng trong quá trình giám sát để có thể nhận biết sớm các hành vi độc hại, bên cạnh đó dựa trên thông tin về mã hash cũng như các signature của file cũng góp phần phát hiện sớm các file giả mạo hoặc các trojan trên hệ thống.
Event ID 8: CreateRemoteThread: ghi nhận khi một tiến trình khởi tạo một thread trên một tiến trình khác. Đây là một hành vi được rất nhiều các dòng mã độc thực hiện nhằm inject các đoạn mã độc hại vào các tiến trình sạch từ đó che dấu hoạt động của mã độc
Event ID 9: RawAccessRead: sự kiện đọc trực tiếp các dữ liệu thô từ các ổ đĩa thông qua đường dẫn dạng \\.\ thay vì tên ổ đĩa như bình thường. Hành vi này có thể được mã độc sử dụng để tránh sự kiện sinh ra bởi Audit file và quyền truy cập file.
Event ID 10: ProcessAccess: ghi nhận khi một tiến trình truy cập vào bộ nhớ của một tiến trình khác (mã độc có thể sử dụng để đọc thông tin nhạy cảm của các tiến trình khác, ví dụ như đọc các thông tin liên quan đến mật khẩu dựa trên tiến trình lsass)
Event ID 11: FileCreate: ghi nhận khi một file được tạo ra hoặc ghi đè
Event ID 12: RegistryEvent (Object create and delete): tạo hoặc xóa một registry
Event ID 13: RegistryEvent (Value Set): thay đổi giá trị của một registry
Event ID 14: RegistryEvent (Key and Value Rename): thay đổi tên một key và value của registry
Cả ba sự kiện 12,13,14 đều liên quan tới các tác động đến hệ thống Registry của thiết bị, tuy nhiên mỗi sự kiện sẽ ghi lại các sự kiện đặc thù như đã được mô tả ở trên
Event ID 15: FileCreateStreamHash: khi một file được tải về từ Internet nó sẽ được lưu lại trên hệ thống. Khi các file này bắt đầu được tải về một file stream sẽ được tạo ra khi đó các file temp có thể được tạo trên hệ thống (Event ID 11) và sau khi file stream được tải hoàn tất Event ID 15 sẽ được ghi lại đặc biệt là mã “Hash” của file stream, thông tin này có thể được lưu trữ để phát hiện sớm việc tải về thành công các file mã độc trên hệ thống.
Hình 7 Định nghĩa các trường dữ liệu Sysmon Event ID 15
Event ID 16: ServiceConfigurationChange: ghi nhận khi có sự thay đổi về cấu hình của Sysmon. Cấu hình của Sysmon sẽ có thể được tùy chỉnh thông qua một file cấu hình xml đóng vai trò như một filter các sự kiện sẽ ghi lại (include) hoặc được bỏ qua (exclude). Nếu kẻ tấn công có thể tác động đến service Sysmon, chúng có thể thay đổi một phần các sự kiện được giám sát để che dấu, việc này sẽ tốt hơn rất nhiều việc tắt hoàn toàn địch vụ Sysmon do việc sụt giảm hoàn toàn một lượng lớn log sẽ dễ bị phát hiện hơn rất nhiều so với việc giảm đi một phần nhỏ log . Sự kiện này sẽ góp phần phát hiện sớm sự thay đổi này.
Event ID 17: PipeEvent (Pipe Created): ghi nhận khi một named pipe được tạo ra
Event ID 18: PipeEvent (Pipe Connected): ghi nhận khi một kết nối thông qua named pipe được tạo ra giữa client và server
Event ID 19: WmiEvent (WmiEventFilter activity detected)
Event ID 20: WmiEvent (WmiEventCosumer activity detected)
Event ID 21: WmiEvent (WmiEventCosumerToFilter activity detected)
WMI là cách quản lý hệ thống doanh nghiệp dựa trên web (WBEM) của Microsoft. Nó cung cấp một bộ công cụ cho phép quản trị viên quản lý hệ thống. Tuy nhiên, đây cũng là một lựa chọn ưa thích của mã độc để persistence trên hệ thống của nạn nhân. Cách thứ persistence dựa trên WMI các bạn có thể tham khảo thêm trong bài viết về Malware Persistence tại đây https://sec.vnpt.vn/2023/08/windows-forensic-part-2-malware-persistence/
Event ID 22: DNSEvent (DNS Query): sự kiện sẽ ghi lại các DNS Query phát sinh từ hệ thống đang được giám sát kể cả request này có thành công hay không. Sự kiện này được thêm vào từ Windows 8.1 và không thể sử dụng trên Windows 7
Event ID 23: FileDelete (File Delete archived)
Event ID 26: FileDleteDetected (File Delete logged)
Cả hai sự kiện này đều ghi lại việc một file bị xóa. Sự khác nhau ở đây là đối với Event ID 23 các file bị xóa sẽ được lưu lại trong folder mặc định là “C:\Sysmon\ArchiveDirectory”. Còn Event ID 26 sẽ chỉ lưu lại log mà không lưu lại file. Việc lưu lại file bị xóa sẽ hỗ trợ tốt hơn quá trình giám sát, tuy nhiên, kích thước của folder này sẽ tăng lên rất nhanh và khó kiểm soát, do đó phụ thuộc trường hợp cụ thể, việc sử dụng các Event tương ứng sẽ được lựa chọn.
Event ID 24: ClipboardChange (New content in the clipboard): ghi lại việc thay đổi clipboard (thường là khi có dữ liệu được copy hoặc cut)
Event ID 25: ProcessTampering (Process image change): sự kiện được ghi lại khi một số kỹ thuật che giấu mã độc như “hollow” hoặc “herpaderp” được sử dụng.
Tại sao lại sử dụng Sysmon?
Dựa trên các thông tin Event ID kể trên, chắc các bạn cũng có thể thấy một số sự kiện của Sysmon có phiên bản khác của nó trong hệ thống các Audit log của Microsoft.
Ví dụ:
- Sysmon Event ID 1 (Process Creation) và Security log Event ID 4688 (A new process has been created)
- Sysmon Event ID 26 (FileDeletedDetected) và Security log Event ID 4660 (An object was deleted)
-
Sysmon Event ID 11 (FileCreate) và Security log Event ID 4656 (A handle to an object was requested). Trong trường hợp này, sự kiện 4656 ghi lại nhiều loại hành động hơn tùy vào cấu hình của quản trị viên ngoài tạo file có thể liên quan đến việc đọc/ghi và một số hành vi khác trên file. Việc này một phần cũng là khó khăn khi phân tích các sự kiện cần làm rõ tác động trong từng sự kiện là gì.
Vậy tại sao những sự kiện trùng lặp này vẫn tồn tại trong Sysmon. Trên thực tế, hầu hết các log này sẽ không mặc định được bật, chúng ta sẽ phải thực hiện cấu hình thủ công các log audit muốn bật. Đặc biệt, đối với sự kiện Audit file và folder chúng ta sẽ cần cấu hình giám sát trên từng file và folder để ghi lại các log giam sát. (Chi tiết có thể xem thêm tại bài viết về Windows Event Logs (Part 4) tại đây https://sec.vnpt.vn/2023/03/windows-forensicpart4-windows-event-logs/
Đối với Sysmon chúng ta hoàn toàn có thể cấu hình tất cả dựa trên một file XML có cấu trúc định trước, khi có bất kỳ thay đổi nào muốn thực hiện chúng ta chỉ cần điều chỉnh file này và thực hiện chạy lại cấu hình của Sysmon với lệnh
| sysmon.exe – c [sysmon.xml] |
Hình 8 Ví dụ cấu hình các sự kiện không được lưu lại cho Event ID 1
Bên cạnh đó cũng có rất nhiều các sự kiện mà hệ thống event log mặc định không có sẵn và hỗ trợ rất tốt cho quá trình giám sát cũng như phân tích, xử lý sự cố.
Vậy Sysmon có nhược điểm gì không?
Như các bạn cũng đã thấy cấu hình của Sysmon được xây dựng ở dạng XML, cần hiểu rõ các cấu hình này để có thể tùy biến cho các hệ thống khác nhau. Các cấu hình này cũng khó linh hoạt với các hệ thống khác nhau.
Bên cạnh đó, tuy cấu hình là dạng XML, nhưng khi chúng ta xem cấu hình Sysmon hiện tại dữ liệu sẽ ở định dạng như sau:
Hình 9 Cấu hình Sysmon khi kiểm tra cấu hình hiện tại
Các bạn hoàn toàn có thể nhận ra việc chuyển đối từ định dạng này về dạng XML để sửa đổi là rất phức tạp. Tuy nhiên, đây vẫn là một định dạng có cấu trúc và chúng ta hoàn toàn có thể xây dựng những công cụ để việc chuyển đổi hiệu quả hơn
Sysmon cũng có vấn đề về mặt hiệu năng, với các thiết bị có cấu hình thấp, vấn đề hiệu năng dễ bộc lộ và làm ảnh hưởng tới hệ thống do tăng mức sử dụng CPU, RAM, Disk I/O cũng như dung lượng lưu trữ.
Trên thực tế việc filer các sự kiện không ghi lại được xử lý trên user mode, driver vẫn thực hiện monitor đầy đủ các sự kiện và đây là nguyên nhân chính dẫn tới vấn đề hiệu năng của Sysmon.
Phiên bản hiện tại của Sysmon đã hỗ trợ một vài tính năng chặn lọc (Event ID 27 và 28), nhưng số lượng này chưa nhiều việc chặn lọc chủ yếu vẫn cần dựa vào các giải pháp khác. Chúng ta cũng không nên kỳ vọng quá nhiều về khả năng chặn lọc này vì về cơ bản Sysmon từ đầu được xây dựng giống mới một công cụ hỗ trợ giám sát nhiều hơn.
Kết luận
Như các bạn đã thấy Sysmon là một công cụ rất hữu dụng nhưng nó cũng không phải là toàn năng. Công việc của chúng ta là cố gắng khai thác được nhiều lợi ích nhất từ công cụ này để đáp ứng mục tiêu công việc. Trong những bài viết tiếp rất mong có thể cùng chia sẻ với các bạn những cách thức để tối ưu hóa cấu hình cũng như các công cụ để sử dụng Sysmon linh hoạt cũng như hiệu quả hơn, còn tới đây bài viết cũng đã khá dài, hẹn gặp lại các bạn vào lần sau nhé, rất sớm thồi 😀