In our previous blog, we discussed how insufficient network segmentation can be exploited by attackers and pen testers.
This week, we discuss a finding that we frequently abuse during the privilege escalation phase of our penetration testing assessments, particularly for those involving public sector clients. This phase occurs after our operators have gained a foothold and established persistence within a client’s internal network. At this point of the assessment, our foothold into the network is in the context of a domain user (or more often, several domain users).
Privilege Escalation Through Lateral Movement
One of the tried and true methods of privilege escalation is to use your current access to spread laterally throughout the environment. This is done by taking advantage of misconfigurations at either the host level or through domain group misconfigurations. As pen testers, our objective is to repeatedly identify and move to a host that has a more privileged user logged in until we reach the desired level of access. This method usually requires several “hops” before we compromise a user of who meets our preferred level of privileges, typically Domain Administrators.
For example, we might initially gain access to a user in the Human Resources department through a phishing email. Then, we might attempt to leverage a misconfiguration of domain groups to compromise a user from a group of Workstation Administrators, who have admin rights over multiple workstations. Then we might use that access to compromise a workstation with a Domain Admin logged in. If our operators can gain administrative access to any host with a privileged user logged in, then we can use a tool like Mimikatz to dump the logged-on user’s credentials and impersonate that user for the remainder of the assessment.
To spread laterally to another workstation or server in a domain, we generally need to have administrative access to the target host. Our preferred method of lateral movement is performed via a network login, which is transparent to any logged-in user. We use this network login to execute a command on a remote host that provides us full control of that target computer. The command is executed either by remotely creating and starting a custom service on the new host, or by using Windows Event Management (WMI) or Windows Remote Management (WinRM) to directly execute the command on the target host.
Local Admin Misconfigurations
In general, public sector organizations do a very good job of following standard security best practices, especially when it comes to restricting the administrative rights of non-privileged users. It’s rare that we will assess a client that allows all users to run as a local Administrator. We also find that when organizations provide their users with “golden images” of their workstation (essentially pre-built and pre-configured workstations), it drastically cuts down on us finding common windows privilege escalation vulnerabilities, such as DLL hijacking, unrestricted service permissions, or enabled AlwaysInstallElevated policies.
Keeping with standard security best practices, many public sector organizations have implemented Microsoft LAPS, which generates strong, unique passwords for the Built-In Administrator account (RID-500) on all hosts. This means we cannot simply pass-the-hash with this account to access other hosts. So, gaining administrative (SYSTEM level) access on a single host is far from the end of the privilege escalation phase. However, being able to spread to a couple additional boxes right off the bat can give us a big advantage on an assessment.
Even with all the effort put into restricting local administrator access, we still frequently find an “edge case” workstation or server that has been misconfigured (typically a smaller number of hosts) to allow local administrative privileges to an excessive number of users. This generally occurs due to an overly permissive Active Directory group being added to that host’s local Administrators Group. Sometimes this happens due to an Active Directory group containing additional groups, which can quickly lead to a massive number of users that are now part of the group. Occasionally, we even find an old, forgotten host that has been configured to allow all “Domain Users” to be in the local Administrators group.
Nested Group Membership Misconfiguration Example
To demonstrate how groups inside of groups can quickly become unruly, we’ve recreated a small windows domain to highlight this misconfiguration. Let’s look at who has local Administrative access over the Director’s laptop in this organization, using an open-source tool called BloodHound.
The screenshot below shows that the only Admins to the Director’s Laptop are the groups “Domain Admins” and “Workstation Admins.” At first glance this looks fairly locked down; even the director is not granted administrative access to their own laptop.
Figure 1: Admins with Director Laptop Access
However, the “Unrolled Admins” attribute on the left side states that there are actually thirty users that have administrative access over this host. When we unravel the “Workstation Admins” group membership, we see that it contains 11 explicit users and the “Helpdesk Tier II” group. Depending on the organization’s policies, it may or may not be acceptable for all Tier II helpdesk employees to have administrative access to the Director’s laptop. Looking further, we see that the “Helpdesk Tier II” group contains another 11 users plus the “Time Tracking Admins” group. Now we are up to over 20 users inside the “Workstation Admins” group and have administrative access to the Director’s laptop.
Figure 2: Access Through Unrolled Workstation Admin Groups
The “Time Tracking Admins” group is likely composed of Human Resource staff in charge of recording employee’s working hours. Therefore, placing the “Time Tracking Admins” group inside of the “Helpdesk Tier II” group is almost certainly a misconfiguration.
In this instance, this misconfiguration represents a significant risk to the organization because an attacker only needs to compromise a “Time Tracking Admin” in order to gain unrestricted administrative access to the Director’s laptop. Effectively, any one of these 30 users could install and run malicious programs remotely on the Director’s laptop, such as a keylogger, a screen capture tool, or a remote-control agent capable of exfiltrating sensitive data.
Summary
We find that when we assess an organization and spend a couple of weeks looking at the security controls, we know more about the network’s security than the people who are working there full-time. The misconfigurations that we take advantage of are usually the result of a problem that has been compounded by many small changes over time, and end up resulting in a major security hole. By routinely auditing and assessing the people, processes, and technology present in a network, network defenders can stay abreast of misconfigurations such as those presented in this post, and increase their organization’s overall level of security.
Our next finding focuses on the cyber risk involved with not securing clear text administrative passwords. Take a look back at our previous blogs to learn more about our penetration testing results from 2016.