Мы нашли учетную запись администратора домена - что и делаем не использовать, за исключением сценария аварийного восстановления - в атрибуте LastLogonTimeStamp указана недавняя дата. Насколько мне известно, никто не должен был использовать эту учетную запись в соответствующий период времени (и несколько месяцев позже), но, возможно, какой-то идиот настроил ее для выполнения запланированной задачи.
Из-за большого количества событий журнала безопасности (и отсутствия инструмента SIEM для анализа) я хотел определить, на каком DC был фактический lastLogon время (т.е. не атрибут replicated) для учетной записи, но я запросил каждый DC в домене, и у каждого из них есть lastLogon «none» для администратора.
Это дочерний домен в лесу, поэтому возможно, что кто-то использовал эту учетную запись администратора дочернего домена для запуска чего-либо в родительском домене.
Может ли кто-нибудь придумать способ определить, какой DC выполняет вход в систему, кроме изучения возможных 20 миллионов событий из 16 лесных DC за время, записанное в LastLogonTimestamp? Полагаю, я мог бы сначала настроить таргетинг на контроллеры домена родительского домена (поскольку дочерние контроллеры домена, похоже, не выполнили аутентификацию).
Объяснение
[Добавлено после определения причины после использования repadmin
согласно ниже]
Первоначальная причина этого запроса была связана с нашей командой ИТ-безопасности, которая задавалась вопросом, почему мы, по-видимому, часто входили в систему с учетной записью администратора домена по умолчанию.
Мы знали, что МЫ не входили в систему. Оказывается, существует механизм под названием «Kerberos S4u2Self», когда вызывающий процесс, работающий как локальная система, выполняет некоторую эскалацию привилегий. Это делает сеть вход в систему (не интерактивный) в качестве администратора на контроллере домена. Поскольку это не интерактивно, поэтому нет lastLogon
для учетной записи на любом контроллере домена (эта учетная запись никогда не выполняла вход на какой-либо текущий контроллер домена).
В этой статье объясняется, почему эта штука проверяет ваши журналы и заставляет вашу команду безопасности заводить котят (исходные машины - Server 2003, что еще хуже). И как его отследить. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/
Извлеченный урок - предоставляйте отчеты только по lastLogon
атрибуты для групп ИТ-безопасности, когда это касается входа в систему администратора.
repadmin /showobjmeta DCNAME "ObjectDN"
Покажет исходный DSA.
Пример:
repadmin /showobjmeta CONTOSOMDDC1 "CN=Administrator,CN=Users,DC=contoso,DC=com"
54 entries.
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
4178442 CONTOSO-MDSite\CONTOSOMDDC1 4178442 2017-03-15 11:37:30 55 lastLogonTimestamp