The way we work, with the various devices, access to resources and our mobility has blurred the lines of inside and outside the corporate network. Attackers seeking access to corporate data, ransom dollars or plain old vandalism see the way we work as opportunity. In part 2 of my series exploring the top four Active Directory security issues uncovered in a Quest Security Assessment, I’ll focus on us – all of us – the users (read part 1 about Service Accounts and then read part 2 about Groups and OSs).
When I started in IT more than 20 years ago, the security boundary was between the inside and outside of the network. In fact, some organizations I worked with did not have access outside the LAN. I know, sounds crazy. But at that time, there were not many reasons for knowledge workers to access the Internet. Heck, even as individuals there wasn’t much reason to surf the internet; Netflix was just an online catalogue of DVDs you could receive via the United States Postal Service.
So much has changed. I cannot imagine not using the internet to research something I am working on at work, book a trip, listen to an episode of Darknet Diaries, or funny YouTube videos.
With all this convenience to access information and services on the corporate network and the internet, all while using my personal mobile device, tablet or computer, we have blurred the lines of “inside and outside” the corporate network. So, what should we do now? I like to think about what we are trying to accomplish. First, we want employees to be able to connect from inside and outside of the organization to consume apps, resources and the “stuff” that lets them do their job each day. These resources must be available when they are needed. Second, we need to protect the integrity and flow of the organization’s data. Data is the information current that travels between employees, customers, prospects and allows us to provide our unique service, create our specialized products, all which make the organization profitable and relevant. This data must be protected so only the correct users have access to what is necessary to accomplish their work, the organizations intellectual property is not leaked, and data collected from user’s outside the organization is not compromised. This data consists of contracts, emails, PII, CAD drawings, recorded TEAMs meetings and conversations in public just to name a few.
Adversaries are after the corporate data and one of the most common ways to start the attack is to compromise Active Directory users’ accounts. This normally starts with some sort of phishing or vishing attack, password spraying or social engineering. Attackers will then use this info to climb the privilege ladder to get access to the company data.
In our research and assessments, we have found 3 common user issues in 100% of enterprises:
- Accounts with legacy passwords and settings
- Accounts with more permissions than needed
- Stale objects
Let’s look at each of these.
About the Quest Security Assessment
The issues identified in this blog series are taken from a review of anonymized Active Directory security assessments performed in 2019 for large organizations. These security assessments are requested by enterprises to evaluate their Active Directory security posture. Using Quest Active Directory solutions, a Quest architect will provide an analysis of a comprehensive set of data relating to AD including:
- Domain groups and members
- Domain users
- Domain servers
- Active Directory permissions
Legacy Passwords and Settings
In every organization, we find enabled accounts with passwords that never expire – more on this changing landscape later – and passwords that have not been changed in many, many years. Some of these accounts are actively being used while other have not logged in for years. Frequently, these stale objects have been left behind from a project that is no longer active or are accounts that were not decommissioned when the user left the organization. Generally, this indicates a lack of solid governance at the time these accounts were being managed. We need to identify these stale objects that have not logged into Active Directory recently and determine if they can be disabled and/or removed.
So, what about old passwords? Well, password policies are changing. The updated NIST guidelines for digital identities are no longer recommending changing passwords on a regular basis. Instead, a password should be changed when there is a security issue that would warrant a password change. Complexity rules have also been thrown out. The NIST recommendations are for users to use a “memorized secret”. Here is a summary of the updated guidelines:
- If chosen by users, the password shall be at least 8 characters in length or if chosen randomly 6 characters and may be entirely numeric
- User-chosen memorized secrets can be at least 64 characters in length
- The ‘SPACE’ character is valid
- Should not impose complexity rules
- “Memorized secrets” do not expire
- Should NOT allow secrets that contain values which are known to be commonly used, dictionary words or already compromised passwords
Now, before we go and set all user account passwords to never expire, we need to consider a few items. Let’s use “Biff” as an example. Biff’s account password has not been changed in 5 years (yes, this is common). We have questions we need to answer before we decide if we should force a change:
- What was the password policy at the time Biff’s password was last changed?
- How easy would it be to brute force?
- Was Biff’s password ever checked against a list of known, common or hacked passwords?
These are all important items to understand. Biff could have used a common password. Check out Wikipedia’s “List of the most common passwords”. Would any of these passwords meet the complexity and min. length policy when Biff last set his password? Probably. Did we check Biff’s password against a dictionary list or a set of compromised passwords? Just to get an idea of how many passwords have been exposed by data breaches check out have I been pwned?. Most likely your account password on LinkedIn, Yahoo, Dropbox, etc. has been exposed.
Which brings me to another point. Are passwords being reused across services? Are you using the same password for your LinkedIn, Gmail account and your company’s Active Directory? There is an exceptional podcast on Darknet Diaries that follow the adventures of the Xbox Underground and how they used passwords stolen from a messaging board to eventually get the flight simulator code for the Apache helicopter. Because of password reuse and predictable patterns, the Xbox Underground was able traverse a network of high-tech companies.
Mitigation
While we can handle some of these problems with technology others must be addressed by education. Here are a few things we can do to deal with these issues:
- Educate users on how to create good memorized secrets
- Educate users about password reuse across services and the effect it could have
- Educate users on Phishing scams and how to spot them
- Check passwords against dictionary list and know compromised or common passwords.
- Monitor accounts for suspicious activity. Solutions like Quest On Demand Audit and InTrust monitor for suspicious activity like brute force attacks, password spaying, pass the hash, golden tickets, data snooping , and other risky events
Multi-Factor Authentication should be enabled. If a user’s password does become compromised, the attacker would have a difficult time completing the login process without the one-time passcode that the users possesses. Something you know, something you have.
Over Permissioned
When working with customers, I frequently ask, “Can you guess how long someone has been at the company by how many groups they belong to?” This generally gets a nervous chuckle. Frequently, the issue is poorly designed user governance policies, if any, and much of the daily administration is carried out via tribal knowledge. For example, if our hypothetical user “Kelly” who we just hired is part of the engineering group she will get added to the appropriate engineering security groups and distribution lists. Well, a couple years later she decides to go into sales. The account administrators add Kelly to the appropriate sales groups and DLs. What should be done with all the other groups she belongs to when she was part of engineering? Often, they are left untouched, just in case. So, throughout the lifecycle of a user they start to accumulate permissions that are beyond what they need.
During Active Directory security assessments, we also find users that were delegated the rights to change passwords on user objects, create objects in OUs, modify groups, link and modify GPOs, etc. We even find users that have been configured for Unconstrained Delegation which we discussed in part 1 of this series concerning Service Accounts. Frequently, these delegated rights are from some situation in the past that is no longer relevant today. The permissions were never cleaned up and our users accumulate permissions that are not needed to perform their work. Jessica Payne from Microsoft and Sean Metcalf from ADSecurity.org sum it up quite well in this tweet.
Mitigation
Dealing with our over permissioned users sooner than later will reduce the surface area of attack and make our Active Directory more secure. But keep in mind that we really need to address the issue that got us here in the first place before we spend a huge amount of effort on the cleanup process. This is no small task. It requires buy-in from multiple groups and levels of management. Our “Tribal Knowledge” way of administering Active Directory needs to be revamped. Taking our tribal knowledge administration tasks and wrapping them up into an automated policy can help prevent the permission creep that currently plagues almost all Active Directory environments. For example, in the situation above when our user Kelly changes departments the group membership assignments should be automated based on one or more Active Directory attribute. In our example, this could be Department and Office Location. Quest Active Roles is a solution that can accomplish this type of automation task as well as the onboarding and decommissioning of accounts. With a solution like this in place we can use Quest Enterprise Reporter to discover the legacy permissions that were assigned to users and groups and remove them allowing the automated policies to take over.
In the situation where we have determined that a user needs to have the right to reset a password, create objects in OUs we should make sure that we monitor their activity in Active Directory. These Active Directory users could get immediate notification or weekly reports on the use of their delegated rights. If Kelly gets a notification that she reset a password on some account and it was not her, we could immediately start an investigation. Quest On Demand Audit allows for these types of notification and investigation both on-premises and in the Cloud.
Summary
Cleaning up an older Active Directory environment is a process that can be accomplished efficiently with the right set of tools and resources. It is not a glorious task and one that will probably not get the praise it deserves. However, by reducing the area of attack and putting in place modern day governance practices, your Active Directory security will be less vulnerable, and you will free up IT resources to be more tactical and strategic when managing the organizations infrastructure.
