If you have Microsoft Advanced Threat Analytics (ATA) within your environment, you may have seen the following warning:
Encryption downgrade activity The encryption method of the ETYPE_INFO field of KRB_ERR message from x computers has been downgraded based on previously learned behavior. This may be a result of a Skeleton Key on x domain controllers.
I work for quite a large firm, and we were getting these for a handful of computers and accounts.
Initially we looked through Microsoft’s somewhat useful Advanced Threat Analytics suspicious activity guide. However under the heading “Encryption downgrade activity” it somewhat puts the fear of God into you. Indeed, after we did our investigations with the tools provided in that article, we found nothing. So what was going on?
We raised an incident with Microsoft and eventually found that these accounts have passwords that had not been updated for a very long time (before 2010).
Essentially:
- When a client negotiates with the KDC (a Domain Controller), it will send the client principal name and realm (eg username/domain.local)
- The KDC will look up the client in Active Directory, specifically the supplementalCredentials field in AD.
- Should the user be missing the Primary:Kerberos-Newer-Keys property, then the KDC will negotiate a lower encryption with the client, and the warning will be raised in ATA.
If your domain functional level is Windows 2008 or higher (which quite frankly it should be by now!), reset the users password, as 2008 DFL introduces the Primary:Kerberos-Newer-Keys property. By resetting the users password, this *should* set the Primary:Kerberos-Newer-Keys property, and the error should go away in ATA.
If you want to test if you have this issue, just try logging on with one of these impacted user accounts to a domain joined PC, or any other system that authenticates via Kerberos. Just use a bogus password for the account, don’t worry about it if you don’t know the accounts password because the Kerberos negotiation happens before authentication. If your failed logon raises an alert in ATA, then that account needs to change it’s password.
TL;DR: Just reset the password of the impacted users.
Some Downtime 