Tuesday, April 15, 2014

Daily Blog #296: Domain lastlogin timestamps and tracking recon

Hello Reader,
         Normally I would save something like this for Saturday Reading but the following two articles brought enough interesting thoughts that they deserved their own post. The first is from 2009 and if you are doing any work within an Active Directory environment deserves your attention, read it here:
http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

What's important to take away from this article is that Active Directory since the introduction of Windows 2003 Domain Function Level provides a synchronized timestamp across domain servers called 'lastlogontimestamp'. This first of the two articles we will talk about today is important if you are interested in two things:

1. When the last time all users interacted with the domain, the article specifies levels of interaction as interactive, network, and service logins. However as you'll see in the second article that isn't exactly true. However what is going to be true is that this timestamp is sync'd across all domain controllers within the domain.
2. That the timestamp itself does not reflect the actual true last logon time of a user. It just reflects if that user account has logged in within the last 14 days.

The second part may seem like it makes the first part and its caveat less useful but I would say to you don't give up on it just yet. Take a look at the second article linked here:
http://blogs.technet.com/b/askpfeplat/archive/2014/04/14/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self.aspx

where we learn that not only is the timestamp synchronized across domain controllers but applications that are trying to query across the domain count towards this logon event. So why is this useful to us? What should you taken away from this?

1. If an attacker or a rogue insider is trying to gather intelligence across you enterprise by querying different groups, service accounts and the like that it will in fact trigger a logon event that will change the lastlogon timestamp. This means that if you quickly preserve these timestamps today you can find the last logon values of service accounts that don't do domain logins. Then moving forward if that timestamp changes you can act on it to determine who is suddenly enumerating information about your domain.
2. That if you extended auditing rules setup, as mentioned in the second article, you can catch which account is actually going out and enumerating. The enumeration does not require that the account in question has the credentials of the resource being queried and does not actually login into the account. Instead its just a by product of how the querying is being done within the api itself.

So there you go, Internal IR people go petition IT to change your Domains by adding additional event logging and preserving the current state of your lastlogon timestamps now to take advantage of this to its full extent.
Consultants start querying this across the domain to start getting additional intelligence regarding when recon may have taken place. If you start noticing that a large number of old service accounts and unused accounts all have recent last logon timestamps that should be a clue that this timestamp may relate to some domain recon within the environment.

Let me know your thoughts!