Mistério de logon da conta do administrador do AD - carimbo de data/hora do último logon

Descobrimos que a conta de administrador do domínio - que não usamos, exceto no caso de um cenário de recuperação de desastre - tem uma data recente no atributo LastLogonTimeStamp. Tanto quanto sei, ninguém deveria ter usado esta conta no período em questão (e vários meses além), mas talvez algum idiota a tenha configurado para executar uma tarefa agendada.

Devido à quantidade de eventos de log de segurança (e falta de ferramenta SIEM para análise), eu queria determinar qual DC tinha o tempo lastLogon real (ou seja, não o atributo replicado) para a conta, mas consultei todos os DC no domínio, e cada um deles tem um lastLogon de "nenhum" para Administrador.

Este é um domínio filho na floresta, portanto, é possível que alguém tenha usado essa conta de administrador do domínio filho para executar algo no domínio pai.

Alguém pode pensar em uma maneira de determinar qual controlador de domínio está fazendo o logon, além de examinar os 20 milhões de eventos potenciais de 16 controladores de domínio da floresta por volta do tempo registrado em LastLogonTimestamp? Suponho que poderia direcionar os DCs de domínio pai primeiro (já que os DCs filhos parecem não ter feito a autenticação).

Explicação

[Adicionado após zerar a causa após repadmino uso conforme abaixo]

O motivo original dessa solicitação foi devido à nossa equipe de segurança de TI, que estava se perguntando por que aparentemente estávamos fazendo logon com a conta de administrador de domínio padrão com frequência.

Sabíamos que não estávamos logando. Acontece que existe um mecanismo chamado "Kerberos S4u2Self" que ocorre quando um processo de chamada em execução como Sistema Local está fazendo algum escalonamento de privilégios. Ele faz um logon de rede (não interativo) como administrador em um controlador de domínio. Como não é interativo, é por isso que não há lastLogonconta em nenhum DC (essa conta nunca foi conectada a nenhum controlador de domínio atual).

Este artigo explica por que a coisa executa pings em seus logs e faz com que sua equipe de segurança tenha gatinhos (as máquinas de origem são Server 2003, para piorar as coisas). E como rastreá-lo. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

Lição aprendida - apenas forneça relatórios sobre lastLogonatributos às equipes de segurança de TI quando se tratar de logons de administrador.