Microsoft supported backups of Active Directory are very important to have. For backing up Domain Controllers, this is typically a System State backup. Why a Microsoft supported backup? If you are using a backup solution that isn’t fully AD aware, performing a restore may involve getting Microsoft involved and that costs $$. I know companies that have used ####### (redacted) to backup their AD and there was no System State and the backup wasn’t a full AD aware backup so they ended up paying ###### $$$ and Microsoft $$$. Just get a System State backup of the DCs that host your FSMO roles about every month and be prepared for a scenario where you may have to restore AD. Determining if a recent supported backup has been performed is easy since these backups update a bit in each partition. PowerShell code to check the current domain for the last Microsoft supported AD backup: $ContextType = [System.DirectoryServices.ActiveDirectory.DirectoryContextType]::Domain $Context = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext($ContextType,(Get-ADDomain).DNSRoot) $DomainController = [System.DirectoryServices.ActiveDirectory.DomainController]::findOne($Context) [string[]]$Partitions = (Get-ADRootDSE).namingContexts foreach ($Partition in $Partitions) { $dsaSignature = $DomainController.GetReplicationMetadata($Partition).Item("dsaSignature") Write-Host "$Partition was backed up $($dsaSignature.LastOriginatingChangeTime.DateTime)" }

There are two main password attacks leveraged by adversaries; one is called Password Spraying and the other is called Kerberoasting. This post focuses on identifying accounts that may be targeted for Kerberoasting and how to harden the environment against Kerberoasting. Password spraying involves the attacker using a list of passwords and for each password attempts to authenticate as each user using that one password. After working through all users with the first password, they move on to the next password in the list. Successful authentication is noted along the way as these are compromised accounts. I wrote about detecting password spraying here: trustedsec.com/blog/detectin… Kerberoasting is possible when an Active Directory account has a Kerberos Service Principal Name (SPN) associated with it. In order to enable Kerberos authentication for an application, the associated service account needs a SPN. Kerberoasting takes advantage of the fact that one can request a service ticket using the SPN associated with a target service account and take that Kerberos service ticket offline to attempt to crack it. Attackers are most likely to attempt Kerberoasting on the accounts with passwords that are about 5 years and older since they are more likely to have poor passwords, though attackers may just attempt kerberoasting all AD accounts that have SPNs. For more information on how Kerberoasting works as well as detecting Kerberoasting, read this article: adsecurity.org/?p=3458 I wrote a short PowerShell script that identifies all accounts with SPNs as well as Active Directory admin accounts with SPNs (leverages the Active Directory PowerShell module): github.com/PyroTek3/ActiveDi… TO DO LIST: Remove SPNs from AD Admin accounts associated with people since they shouldn’t have any SPNs associated with them. If the default domain administrator account is listed here, work to remove the SPN associated with it. This account should never have a SPN. Remove SPNs from the other accounts associated with people since they shouldn’t have any SPNs associated with them. Identify service accounts identified as AD Admin accounts (those that are members of Administrators, Domain Admins, or Enterprise Admins). Remove accounts that don’t belong and leave only those accounts that require these privileges (should be a minimal to 0 list of service accounts). Identify the AD Admin accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters. Identify the other accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters. IMPORTANT NOTE: Ignore the krbtgt account with regard to these directions as this is required to be configured this way for AD Kerberos to work. The KRBTGT account requires special attention: adsecurity.org/?p=4597 Reference: adsecurity.org/?p=4955

Here are some key Conditional Access policies that @TechBrandon & I put together. You should also have a "catch-all" policy that applies to all users and devices you have in your environment. Brandon also wrote a PowerShell script to help you check what you have against what you should have: github.com/techBrandon/CAPs

Domain Controllers typically run Microsoft DNS so this RCE is effectively an Active Directory RCE. Patch ASAP!