You've undoubtedly put a variety of defenses in place to limit the ability of attackers to enter your network — but attackers are notoriously persistent. They are constantly inventing increasingly sophisticated tactics for duping users and slipping past firewalls: phishing attacks, drive-by downloads, brute-force attacks, infected USB drives, purchase of credentials on the dark web and so on. Inevitably, some of them will get through. Moreover, other attackers are already inside, in the form of malicious insiders — disgruntled employees, former employees whose credentials were never disabled, contractors with their own agendas and so on.
That's why more and more government agencies and private businesses alike, from the U.S. National Security Agency (NSA) to Microsoft, are adopting an "assume breach" mindset, which accepts that attackers are already inside the network and focuses on developing strategies to mitigate the threat they pose. Attackers typically move stealthily from machine to machine, collecting whatever credentials they can to elevate their privileges so they can get to the systems and data they're after. In most networks, this lateral movement is simply far too easy: If attackers can simply move carefully and stay beneath the radar, they can achieve their goal, and your organization may find itself in the headlines as the latest massive breach.
Fortunately, there are proven best practices that can help you protect your critical systems and data by limiting the ability of attackers to move laterally and escalate their privileges. This ebook explores those best practices, explains how to implement them as much as possible using native tools, and then offers a better solution — Quest® Enterprise Reporter.
In most networks, attackers can gain elevated privileges through lateral movement far too easily.
One way organizations have begun to address the threat of attackers inside the network is to implement various control technologies to better secure their administrative accounts. These technologies include:
Unfortunately, these preventative control technologies have important limitations. To start with, many users resist MFA because carrying hard tokens or constantly entering codes from their smartphones is inconvenient, disrupts their workflows and drives down productivity. In addition, many common authentication methods don't actually deliver much additional security. For example, knowledge-based answers (KBAs)
can often be readily gleaned from social media, and hackers can use SIM hijacking to intercept SMS messages with one-time passwords (OTPs).
The ESAE model has its own challenges. For starters, deploying an administrative forest is not a trivial task. For more information, watch this on-demand webcast in which security expert Randy Franklin Smith explains both why you might go to this extra trouble and the limitations of the red forest model.
However, there is a broader drawback to all of these methods: their limited reach. They are usually applied only to highly privileged accounts, such as domain admins. But it doesn't take admin authority for attackers to get access to the data they want; there are often many end users who have broad access to the most critical data on the network. Therefore, these technologies should be implemented as part of a broader, defense-indepth AD security strategy.
Attackers often don't need admin authority to access the data they want, so techniques for protecting admin accounts will take you only so far.
One way that attackers gain elevated privileges is by becoming members of built-in admin groups. These groups exist at the forest level, the domain level and the local Windows system level. While most organizations are well aware of the need to carefully audit the most powerful of these groups, it's essential to keep a close eye on all of them.
There are two groups in your forest root that you should maintain strict control over:
At the domain level, you should be vigilant about monitoring the membership of the following three groups:
Individual workstations and servers also have groups with elevated permissions:
Keeping track of all those built-in groups is tough enough, but Active Directory adds another wrinkle: It allows groups to be members of other groups. You can nest groups multiple layers deep (group A is a member of group B which is a member of group C), and you can even nest groups that aren't part of the same domain. If this nesting involves administrative groups, it can be very difficult to determine exactly who has elevated permissions in your environment, and it's easier for attackers to elevate their permissions without being noticed.
Attackers can take advantage of group nesting to gain admin privileges without being noticed.
Figure 1. Groups can be members of other groups, and attackers can take advantage of this nesting to elevate their permissions without being noticed.
Another way of making somebody a privileged user is with delegated permissions on portions of Active Directory. The best way to explain this through an analogy with file permissions.
Best practices say that it's wise to manage permissions to files at the folder level. However, it is also possible to grant someone access to a particular file by changing the permissions on that specific file, or changing the permissions that it inherits from its parent or grandparent folders, all the way back up to the root of the drive. That means each file can have a unique set of permissions, which makes them harder to manage and secure.
The permissions granted to a particular file are recorded in an access control list (ACL), which is comprised of access control entries (ACEs) that specify the access or auditing permissions to that file. User permissions work in much the same way. Everything a user can do is governed by an ACL (which, for administrators, can comprise a complex and lengthy set of ACEs).
Best practices recommend granting users permissions via group membership. But there are times when you want to give a user or set of users, such as helpdesk admins, a limited set of elevated permissions without adding them to a highly privileged groups, like Domain Admins or Account Operators. One option is to create a new group, such as Helpdesk Admins, assign it the appropriate permissions and make the appropriate users members of that group. Sometimes IT teams take an easier path and assign users the permissions directly. In either case, the Delegation of Control Wizard in the Microsoft Management Console (MMC) Active Directory Users and Computers (ADUC) snap-in makes it very easy to delegate the permissions to the users — so easy, in fact, that delegated permissions often pile up in Active Directory over time.
Untangling the resulting set of user permissions is not nearly as easy as delegating them, and it gets even harder as permissions build up over time. In fact, trying to get a handle on one admin's permissions using ADUC involves so many clicks that you'll end up with carpal tunnel. Many times, a non-standard combination of permissions will simply be shown as "special access," and you'll have to drill down multiple layers. For an AD of any size, it would prohibitively laborious to analyze every ACL on every object in AD this way, since someone could have customized the permissions on individual users and groups, just as you could on particular files. But it's critical to keep a close eye on user permissions, so it's smart to invest in third-party solutions that simplify this task, as we'll discuss later in this ebook.
Trying to manually untangle delegated permissions is not practical in any but the very smallest Active Directory.
In addition to keeping track who has been granted permissions directly or through group membership, you also need to know who has the authority to delegate permissions or to enable others to delegate permissions. Specifically, you need to know:
Anyone with these permissions can expand entitlements — they can give themselves or someone else access to valuable data or to accounts that have access to that data. Therefore, to minimize lateral movement by attackers, you need to tightly control the list of users with these permissions and closely monitor their activity.
To minimize lateral movement by attackers, you need to tightly control the list of users who have the authority to delegate permissions.
Let's move from the permissions granted in Active Directory down to those granted at the individual server or workstation level. Inside the Windows operating system, there are multiple system user rights, and many of them are classified by Microsoft as "admin equivalent." What this means is that someone can have the equivalent of admin authority to a server or workstation without being a member of the local Admins group. System user rights to be mindful of include the following:
If you check the Resultant Set of Policy (RSoP) report for each of your servers, you might be surprised at what you see. Some organizations even discover that the "Everyone" role has been granted the "Act as part of operating system" right on multiple servers.
This type of security issue happens more often than you might think, and there's no way you can absolutely prevent it. Moreover, at some point, you'll likely inherit an environment with these system user rights in place. Therefore, you need to be able to efficiently review all the rights and clean them up to reduce the risk of lateral movement by attackers in your environment.
When hackers gain a foothold on an endpoint, they quickly begin to look for any artifacts on the machine that they can use to move laterally and elevate their permissions. They might find an end user's credentials, which can help them to some extent. But they strike gold if they unearth the credentials of a privileged user, since those credentials have greater power and reach.
One way to mitigate this risk is to determine exactly which privileged accounts are exposed because they have logged on to an endpoint and may have left artifacts behind. You have several options. First, you could search through all your past domain controller logs and local security logs, which would be a tedious and error-prone task. Alternatively, you could possibly search for cached credentials on each system, but that would require code that could do something similar to what Mimikatz does — run on the endpoint locally and use various APIs to return a list of all the artifacts found on the system. A third option is to look at the user profile folders, which are under C:\Users. However, that will show only users who have logged on interactively to that system. If they used saved credentials to access another system on the network or done a run-as, for instance, no profile will have been created. Whichever method you choose, you should then reset the credentials for all the admin accounts that have logged on to your various endpoints, since they could be compromised.
Alternatively, you can reset the credentials for all your privileged accounts — that way, any credentials lying around in a workstation's cache won't do an attacker any good. A good way to simplify this process is to implement a privileged account management (PAM) solution that will automatically reset admin credentials after each use.
Once you've minimized the risk associated with past logons to endpoints, you need a strategy to protect privileged credentials going forward by controlling which endpoints they can log on to. This is important even if you have a PAM solution in place — you don't want admins logging into less secure systems because there is still a window of vulnerability before the admin credentials are reset.
Natively, you have three options:
To protect privileged credentials, you need to control which endpoints they can log on to.
The first option is the least practical. To place workstation restrictions on a user account in AD, you have to explicitly list the NetBIOS or DNS names of the computers where that user is allowed to log on. But you can't do this using Group Policy and you can't define the list at an OU level — you have to go to each individual user and call out the specific systems they can log on to. Therefore, it's really useful only in certain very limited circumstances; it's not a scalable approach.
A better option is create a group for all your privileged users; let's cleverly call it Privileged Users. Then separate your endpoints into two OUs, one for all the ones that members of the Privileged Users group can use, and the other for endpoints that are to be used by end users only. Then you can simply create a GPO for the second OU that denies logon to anyone from the Privileged Users group. There are five ways to log on to an endpoint, so you'll need to deny them the five corresponding rights:
With that GPO in place, you can rest assured that the only places where an attacker could possibly find artifacts of privileged credentials will be on your privileged clients. Then you take further steps to protect those privileged clients rigorously, for example, by requiring MFA.
You could also split up privileged users further into horizontal swim lanes, so that a particular set of privileged users can log on to only certain systems. You can even do the same with end users: Why should everybody in the call center have authority to log on to computers assigned to folks from Sales? Similarly, you might want to prevent users from logging on to workstations in another building. This limits the usefulness of their credentials to an attacker who manages to steal them.
Authentication silos are a purposebuilt feature for controlling where a group of users can log on.
Introduced with Windows Server 2012 R2, authentication silos are a way to limit which accounts can authenticate from which computers. This is an excellent way to prevent the use of high-privilege accounts on potentially vulnerable computers.
For example, you might define a Domain Admins silo that contains all Domain Admin accounts. The silo could then be configured with an authentication policy so that authentication attempts from any systems other than domain controllers and privileged workstations would fail.
It is important to note that the authentication silos feature works only with Kerberos authentication. Therefore, it is required to implement this feature with another Windows Server 2012 capability: the Protected Users group. Members of this group have their ability to authenticate using the NTLM protocol removed.
So far we have restricted our discussion to Active Directory and the Windows operating system. But those are just the two lowest layers of the application stack, the operating system and directory infrastructure. You also need to think about everything that's built on top of that. After all, attackers aren't really interested in your operating system or your admin accounts per se; those are means to an end. What they actually want is your data. And your data is stored in many places: files, SQL Server and Oracle databases, Exchange and SharePoint, and often in the cloud as well, in Azure and OneDrive.
For example, suppose an attacker wants to collect personally identifiable information (PII) from a corporate customer database. They use a drive-by attack on an end user to download a payload that enables remote access to that user's workstation. When the corporate service desk performs normal remote troubleshooting or administration on the machine, the attacker harvests the service desk credentials, and then uses them to identify and reset the password on an inactive DBA account that has rights to back up the target database. Once the data is backed up, it can be easily exfiltrated.
There are many security measures that you can take to help mitigate the risk of such an attack succeeding. You should of course ensure that all user workstations are properly patched in order to help prevent known vulnerabilities from being exploited. You should also prohibit powerful accounts from logging on to user workstations in order to reduce the risk that those credentials can be stolen. And you should promptly remove inactive accounts so they cannot be misused.
But the fundamental problem is that this scenario involves a chain of vulnerabilities; none of them is necessarily fatal on its own, but they combine to create a huge problem. It is critical to understand where privilege exists — and how it can interrelate across IT systems.
In particular, it's essential to tightly control user access to all your data by implement the least-privilege principle. Least privilege can be applied in a lot of different ways. Most often, it's about ensuring that users have only the permissions to read, write, alert and delete data that are required for them to do their jobs. But it is also ensuring that users can log on to only those endpoints they need to do their jobs. This restriction limits the places they can leave artifacts for attackers to exploit, and also dramatically reduces the usefulness of any credentials that attackers do manage to harvest.
Implementing these best practices piecemeal using native tools is a challenging task, and the truth is, you still won't have the visibility you need to truly an attacker's ability to move laterally in your environment, escalate their privileges, and steal or damage your critical data.
Quest Enterprise Reporter offers comprehensive access assessments and built-in reports that provide deep visibility into your Microsoft environment — both on-premises and in the cloud. It covers Active Directory and Azure AD; Exchange and Exchange Online; Office 365; Azure, OneDrive for Business; Windows servers; SQL servers; and NAS/SAN storage. Plus, Enterprise Reporter Suite includes Security Explorer®, which enables you to quickly remove any inappropriate permissions right from the Enterprise Reporter user interface.
This combination of reporting and remediation enables you to mitigate the risk of lateral movement and privilege escalation by implementing all the best practices discussed earlier:
Figure 2. Enterprise Reporter can list all users who have been delegated the right to reset the password of another user — whether directly or through a group membership.
Figure 3. Enterprise Reporter will tell you who has each sensitive user right, across all member servers in the domain.
For example, Enterprise Reporter can list all users who have been delegated the right to reset the password of another user — whether directly or through a group membership (see Figure 2).
Enterprise Reporter will also tell you who has each sensitive user right, across all member servers in the domain (see Figure 3).
How easy would it be for an attacker to move laterally in your environment, stealthily elevating their privileges until they find and steal your valuable IP, your customers' PII or PHI, or other sensitive data? If your organization is like most, the answer is "far too easy."
Mitigating this risk is a big job, especially with native tools and manual processes. But it's essential to get started, for both security and compliance reasons. If you're looking for a way to simplify the task of implementing these key best practices, there's no better place to start than with Quest Enterprise Reporter.
Enterprise Reporter can help you mitigate the risk of attackers moving laterally in your environment to elevate their privileges and steal your valuable data.
At Quest, our purpose is to solve complex problems with simple solutions. We accomplish this with a philosophy focused on great products, great service and an overall goal of being simple to do business with. Our vision is to deliver technology that eliminates the need to choose between efficiency and effectiveness, which means you and your organization can spend less time on IT administration and more time on business innovation.