Threat Hunting Use Case: Windows Authentication Hygiene
Adapt and Overcome
In the first entry of our Threat Hunting Use Case Blog Series, Firewall Targeting DNS, we discussed the importance of understanding your mission within every threat hunting campaign. As industries have shifted to a remote workforce model as a result of COVID-19, prior baselines and overall understanding of authentication traffic has completely shifted as well. Now, security leaders need to re-establish an understanding of “normal” to identify when “abnormal” happens with higher fidelity.
Here are a few scenarios that illustrate the importance of establishing and refining baselines for authentication traffic. Let’s say Steve from accounting has been failing authentication around four times per hour, every day, for the past two months. Is that normal? Consistent failures with thresholds this low could be signs of a more sophisticated attacker living off the land in a low and slow method. In addition, Steve created an account named “ILoveTacos15”. This falls outside of the naming conventions used by his company for user accounts. Naming conventions should be followed as they give us an idea of the privileges an account as based on the username (Ex. usersteve = standard user account, adm-usersteve = admin account for the user). This type of standardization makes it more efficient and simpler to identify indications of privilege escalation.
Additionally, if there are no business or compatibility reasons for certain devices and applications to allow the use of weaker Kerberos encryption types such as RC4 and DES, which is required for most Kerberos credential attacks (T1558), this could cause a few issues. If “normal” authentication traffic is not following best security practices, then the noise of that traffic can mask actual attacks. It is significantly more difficult to identify something like active Kerberoasting if everything looks like Kerberoasting.
After considering the above examples and putting the accountant Steve on the chopping block, the main takeaway is that there are various authentication-related poor hygiene practices that cause an abundance of “noise” leading to a lower likelihood of identifying malicious activity. The goal is to baseline constantly and improve our security practices (such as using standard naming conventions for accounts, preventing access to modifying usernames, upgrading Kerberos encryption to AES, etc.) to then move forward with conducting more granular threat hunts to identify actual attacks and creating higher fidelity rule logic after removing the “noise”.
Use Case: Windows Authentication Hygiene
Objective: This campaign validates normal naming conventions for common types of accounts and identifies opportunities for standardization and optimization. It also identifies potential issues with accounts with automation implemented or service accounts. It’s important to standardize account naming conventions and understand abnormal authentication activity to expedite investigations and analysis as well as minimize the noise in your environment. This hunt focuses on identifying overall standards as well as hygiene issues to then evolve into more targeted hunts in the future focusing on authentication attacks.
Log Source & Requirements: Windows Security Event Logs Event IDs: 4624, 4625, 4771, 4768, 4769, 4776, 4672, 4648
Duration: 30-90 Days
|What to look for||Why?|
|Confirm the usage of approved naming conventions for hosts and end user accounts within your network to then identify anomalous usernames and hostnames.||Hostnames and usernames that fall outside of normal naming conventions could be indicative of a threat actor creating accounts. The goal is to ensure that all accounts and hostnames are following naming criteria and modify accordingly if not. This will increase the chances of detecting abnormalities when they occur.|
|Search Kerberos authentication traffic for the usage of weak or deprecated encryption types (RC4/DES).||Allowing RC4 and DES encryption for Kerberos authentications can hinder the detection of a true case of Kerberoasting. Service tickets can be used to crack passwords offline.|
|Establish a baseline for NTLM usage (NT LAN Manager) and work towards upgrading to a more secure authentication protocol such as Kerberos AES 128/256.||NTLMv1 and v2 are older and now deprecated protocols. NTLMv1 was implemented in 1987 and can be easily brute forced, which increases an organization’s attack landscape. NTLMv2 includes some security enhancements, but is still inherently vulnerable and susceptible to relay attacks.|
|Baseline windows 4672 events (special privileges assigned to new logon) to constantly monitor expected authentication traffic for administrative and service accounts.||Understanding and reporting on your most used administrative and service accounts’ expected usage/event assists with identifying abnormalities should they occur. For example, spikes or drops in overall event count could be indicative of a misconfiguration or malicious activity.|
|Review privileged accounts (admin/service) that are logging in interactively (Logon Type 2) to general workstations.||Interactive logons to standard workstations leads to credentials being stored on the actual host/target device. Credentials belonging to privileged accounts that are stored on a workstation are at higher risk of credential theft.|
|Audit trending authentication failures to identify anomalies or misconfigurations such as a scripted processes using outdated credentials.||Having consistent login failures present within the environment stemming from misconfigurations can create noise that will make identifying actual malicious activity more difficult.|
|Ensure all relevant windows event logs are generating at proper logging levels.||#Visibility. It is increasingly difficult to correlate potentially malicious activity if you don’t have the appropriate logging and logging levels.|
|What to look for||Why?|
|Investigate accounts behaving irregularly that may be indicative of malicious activity.||Accounts behaving outside of expected thresholds could be indicative of threat actor activity or misconfigurations.|
|Check for brute force, account guessing, password spraying, or login anomalies by reviewing large spikes of logon failures.||Large spikes of logon failures can signify potential brute force, account guessing, password spraying, or login anomalies worth investigating. Additionally, more sophisticated attackers will understand that static correlation is in place and work to circumvent those detections via “low and slow” methods.|
Make threat hunting a reality at your organization with ReliaQuest GreyMatter.
By aggregating and normalizing your data from disparate tools, such as SIEM, EDR, multi-cloud, and third-party applications, ReliaQuest GreyMatter allows your team to run focused hunt campaigns, both packaged and freeform that are strategic and iterative. Use ReliaQuest GreyMatter to analyze indicators of compromise retrospectively or perform behavior assessments to visualize abnormal from normal activity.
To learn more about building a threat hunting program at your organization, check out our blog, “5 Threat Hunting Guidelines to Transition Your Team From Reactive to Proactive.” And stay tuned for our next threat hunting use case in the series where we cover Windows Authentication Attacks!