Dựng dòng thời gian sự kiện: Ghép dấu vết thành diễn biến

Một cuộc điều tra hiếm khi bí ở chỗ thiếu dữ liệu. Cái khó thường là có quá nhiều mẩu dữ liệu rời rạc: một tệp lạ, một lần đăng nhập, một kết nối ra ngoài, một thiết bị USB từng cắm vào. Biến đống mẩu đó thành câu trả lời cho câu hỏi “chuyện gì đã xảy ra, theo thứ tự nào” chính là dựng dòng thời gian sự kiện.

Dòng thời gian là gì trong điều tra số

Dòng thời gian là danh sách các sự kiện có mốc thời gian, xếp theo thứ tự, gom từ nhiều nguồn trên một hoặc nhiều hệ thống. Mục tiêu không phải liệt kê cho nhiều, mà để quan hệ nhân quả lộ ra: sự kiện nào trước, sự kiện nào sau, khoảng trống nào đáng ngờ.

Có hai cách làm, thường dùng kết hợp. Dòng thời gian đầy đủ gom mọi mốc tìm được, cho ra hàng trăm nghìn dòng, dùng để không bỏ sót. Dòng thời gian chắt lọc chỉ giữ các sự kiện có ý nghĩa với giả thuyết đang xét. Bản đầy đủ phục vụ việc tìm; bản chắt lọc phục vụ việc kể.

Các nguồn mốc thời gian

Metadata của hệ thống tệp. Mỗi tệp mang theo vài mốc: lần sửa nội dung gần nhất, lần truy cập gần nhất, lần thay đổi thông tin quản lý, và thời điểm tạo. Ý nghĩa và số lượng các mốc này khác nhau giữa các hệ thống tệp, nên đừng áp hiểu biết từ hệ thống này sang hệ thống khác.

Một điểm cần biết: trên NTFS, bảng quản lý tệp lưu hai bộ mốc thời gian cho cùng một tệp, nằm ở hai thuộc tính khác nhau. Sự tồn tại của hai bộ này là chỗ dựa quan trọng để phát hiện can thiệp, sẽ nói ở phần sau.

Nhật ký hệ thống và ứng dụng. Log ghi sự kiện kèm thời gian ngay lúc nó xảy ra, nên thường đáng tin hơn metadata tệp. Nguồn phổ biến gồm log đăng nhập, log tạo tiến trình, log web server và log thiết bị mạng.

Registry và các kho cấu hình tương đương. Trên Windows, mỗi khóa registry mang một mốc ghi lần cuối; nhiều khóa lưu vết thiết bị từng kết nối, chương trình từng chạy, cấu hình từng đổi. Trên hệ thống khác, vai trò tương tự thuộc về tệp cấu hình và nhật ký của trình quản lý dịch vụ.

Journal của hệ thống tệp. Nhiều hệ thống tệp ghi nhật ký thay đổi để phục hồi sau sự cố. Nhật ký đó trở thành nguồn quý cho điều tra, vì nó lưu dấu thao tác đã diễn ra kể cả khi tệp liên quan đã bị xóa.

Dấu vết ứng dụng người dùng. Lịch sử trình duyệt, cache, danh sách tệp mở gần đây, thùng rác, dữ liệu ứng dụng nhắn tin. Nhóm này thường trả lời tốt nhất câu hỏi “người dùng đã làm gì”, trong khi log hệ thống trả lời “máy đã làm gì”.

Nguyên tắc chung: không tin một nguồn duy nhất. Mỗi kết luận quan trọng nên có ít nhất hai nguồn độc lập cùng chỉ về một hướng.

Lệch múi giờ: cái bẫy phổ biến nhất

Cùng một sự kiện có thể xuất hiện trong ba nguồn với ba con số giờ khác nhau, mà không nguồn nào sai. Mỗi nguồn ghi theo một quy ước riêng: có nguồn theo giờ quốc tế, có nguồn theo giờ địa phương của máy, có nguồn kèm độ lệch múi giờ, có nguồn không ghi gì cả.

Phức tạp thêm vì vài lý do rất thực tế. Máy có thể bị đặt sai múi giờ. Một số hệ thống tệp lưu giờ địa phương thay vì giờ quốc tế, nên giá trị đọc ra phụ thuộc cấu hình máy lúc ghi. Ở vùng áp dụng giờ mùa hè, cùng một con số có thể ứng với hai thời điểm thật khác nhau.

Cách làm đúng gồm bốn việc: quy đổi tất cả về một chuẩn duy nhất, thường là giờ quốc tế; ghi rõ chuẩn đã chọn ngay đầu báo cáo và trên mọi bảng biểu; ghi lại cấu hình múi giờ của từng hệ thống như một dữ kiện thu thập được; và giữ nguyên giá trị gốc bên cạnh giá trị đã quy đổi, để người kiểm chứng lần ngược được.

Lệch đồng hồ: khi bản thân chiếc đồng hồ sai

Lệch múi giờ là vấn đề quy ước, còn lệch đồng hồ là vấn đề vật lý: đồng hồ máy chạy nhanh hoặc chậm so với giờ thật. Máy không đồng bộ thời gian có thể lệch đáng kể sau thời gian dài; máy tắt lâu ngày hoặc hỏng pin bo mạch có thể lệch rất xa.

Hậu quả nặng hơn nhiều người tưởng. Nếu máy A chậm vài phút so với máy B, dòng thời gian ghép từ hai máy sẽ đảo thứ tự các sự kiện gần nhau — mà thứ tự chính là thứ dùng để lập luận nhân quả.

Vì vậy, ngay khi tiếp cận hệ thống còn hoạt động, hãy ghi lại đồng hồ của nó, đối chiếu với một nguồn giờ tin cậy và ghi độ lệch vào biên bản. Khi phân tích, áp độ lệch đó như một hiệu chỉnh có ghi chú, không sửa thẳng dữ liệu gốc.

Dấu hiệu mốc thời gian bị sửa

Việc cố ý sửa mốc thời gian của tệp nhằm che giấu hoạt động là kỹ thuật đã có từ lâu và có sẵn công cụ. May mắn là nó thường để lại mâu thuẫn:

  • Hai bộ mốc thời gian trong bảng quản lý tệp không khớp nhau. Nhiều công cụ sửa mốc chỉ chạm được một bộ, bộ còn lại giữ nguyên giá trị thật.
  • Độ chính xác bất thường. Mốc do hệ thống ghi thường có phần lẻ dưới giây; mốc bị ghi đè bởi công cụ hay tròn trịa một cách đáng ngờ.
  • Mốc nằm ngoài khoảng hợp lý: sớm hơn thời điểm cài hệ điều hành, sớm hơn ngày sản xuất thiết bị, hoặc ở tương lai.
  • Thứ tự nội bộ không nhất quán: bản ghi được cấp phát sau lại mang thời điểm tạo sớm hơn hẳn các bản ghi lân cận.
  • Mâu thuẫn với nguồn khác: tệp khai là tồn tại từ lâu, nhưng journal, log hoặc bản sao lưu đều chỉ thấy nó xuất hiện gần đây.

Điểm cần nhớ: phát hiện mâu thuẫn không đồng nghĩa với chứng minh được ai đã sửa hay sửa với ý định gì. Báo cáo nên dừng ở mức mô tả mâu thuẫn quan sát được và giải thích vì sao nó bất thường.

Những cạm bẫy khi diễn giải

Ba sai lầm hay gặp. Thứ nhất, nhầm mốc cuối cùng với mốc duy nhất: hầu hết hệ thống chỉ giữ lần gần nhất, nên “sửa lúc 10h” không loại trừ việc tệp còn bị sửa trước đó. Thứ hai, gán hành vi con người cho sự kiện máy móc: tiến trình nền, phần mềm diệt virus, dịch vụ đồng bộ và cả thao tác điều tra đều tạo dấu vết trông như người dùng. Thứ ba, nhầm khoảng trống với sự yên tĩnh: không có log có thể vì không có chuyện gì xảy ra, cũng có thể vì log bị xoay vòng, bị tắt hoặc bị xóa.

Kết luận

Dựng dòng thời gian là chỗ điều tra số chuyển từ kỹ thuật sang lập luận. Công cụ gom được hàng trăm nghìn mốc chỉ trong vài phút, nhưng chuẩn hóa múi giờ, hiệu chỉnh lệch đồng hồ, đối chiếu chéo và nhận ra mâu thuẫn vẫn là việc của con người. Một dòng thời gian tốt không phải là dòng dài nhất, mà là dòng mà mỗi mốc đều nói rõ được lấy từ đâu và đáng tin đến mức nào.

Lên đầu trang