Chúng tôi đã tìm thấy tài khoản Quản trị viên tên miền - mà chúng tôi không sử dụng ngoại trừ trong trường hợp xảy ra kịch bản khắc phục thảm họa - có một ngày gần đây trong thuộc tính LastLogonTimeStamp. Theo như tôi biết, không ai nên sử dụng tài khoản này trong khoảng thời gian liên quan (và vài tháng nữa), nhưng có lẽ một số kẻ ngốc đã cấu hình nó để chạy một tác vụ theo lịch trình.
Do số lượng sự kiện nhật ký bảo mật (và thiếu công cụ SIEM để phân tích), tôi muốn xác định DC nào có thời gian LastLogon thực tế (nghĩa là không phải là thuộc tính được sao chép) cho tài khoản, nhưng tôi đã truy vấn mọi DC trong miền, và mỗi cái đều có một Nhật ký cuối cùng "không" cho Quản trị viên.
Đây là một miền con trong rừng, vì vậy có thể ai đó đã sử dụng tài khoản Quản trị viên tên miền con này để chạy một cái gì đó trong miền mẹ.
Có ai có thể nghĩ ra cách nào để xác định DC nào đang thực hiện đăng nhập ngoài việc kiểm tra 20 triệu sự kiện tiềm năng từ 16 DC rừng trong khoảng thời gian được ghi lại trong LastLogonTimestamp không? Tôi cho rằng tôi có thể nhắm mục tiêu các DC miền gốc trước tiên (vì các DC con dường như chưa thực hiện xác thực).
Giải trình
[Đã thêm sau khi không tham gia vào nguyên nhân sau khi sử dụng repadmintheo bên dưới]
Lý do ban đầu cho yêu cầu này là do nhóm Bảo mật CNTT của chúng tôi, những người đã tự hỏi tại sao chúng tôi dường như đăng nhập bằng tài khoản Quản trị viên tên miền mặc định một cách thường xuyên.
Chúng tôi biết rằng chúng tôi không đăng nhập nó. Hóa ra, có một cơ chế gọi là "Kerberos S4u2Self" đó là khi một quá trình gọi đang chạy khi Hệ thống cục bộ đang thực hiện một số bước leo thang đặc quyền. Nó thực hiện đăng nhập mạng (không tương tác) với tư cách Quản trị viên trên bộ điều khiển miền. Vì nó không tương tác, đây là lý do tại sao không có lastLogontài khoản trên bất kỳ DC nào (tài khoản này chưa từng được đăng nhập vào bất kỳ bộ điều khiển miền hiện tại nào).
Bài viết này giải thích lý do tại sao điều đó làm thay đổi nhật ký của bạn và làm cho nhóm bảo mật của bạn có mèo con (các máy nguồn là Server 2003, để làm cho mọi thứ tồi tệ hơn). Và làm thế nào để theo dõi nó xuống. https://bloss.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2elf/
Bài học kinh nghiệm - chỉ cung cấp báo cáo về lastLogoncác thuộc tính cho các nhóm bảo mật CNTT khi liên quan đến đăng nhập của Quản trị viên.