Getting Inside the Mind of an Attacker Part 3: Internal Attacks on Active Directory

Authored by: Julio Sanchez

In part 2 of this series, we examined a penetration testing engagement that the Core Security Services team performed, simulating an external attacker with no internal access finding entry using a password spray attack, eventually gaining control of Active Directory. Continuing our exploration of Active Directory attacks, we’ll share another scenario in order to further demonstrate the many approaches attackers can take, and how best to manage your risk. In this scenario, we’ll see how an insider with low level credentials can quickly escalate their privileges with Kerberos tickets.

The Scenario: Insider Attack for a PCI DSS Pen Test

For this exercise, an external to internal breach was assumed, so we didn’t have to go through the steps of gaining initial access. Instead, we were provided with low privilege access to the internal network and domain through a VPN connection and domain credentials.

Since this penetration test was done to adhere to PCI DSS, we were provided with a virtual desktop that was within the PCI scope. PCI requires that segmentation be enforced between PCI and non-PCI environments. This means there is a distinct separation between systems that have cardholder data (CHD) and those that do not. Systems that are in scope should not be able to communication with out of scope systems in any way. Since segmentation controls were in place, this test consisted of observing two different and isolated domains (one PCI, and one non-PCI) with different servers and computers in separated networks.

Step 1: Initial Assumptions

First, an attacker would note that any domain account, regardless of its privileges, would be able to query not only its domain, but all the domains for which trust relationships have been defined, in order to collect valuable information.

Another observation is that the devices in the network may still have some remnants of old vulnerabilities, which were likely fixed but not correctly cleaned up. Because of this, attackers still look for low hanging fruit in the environment, no matter how outdated—all it takes is one unpatched vulnerability to provide an opening.

An attacker would be especially interested in user groups and computers. Any domain account could also use and abuse the Kerberos protocol, which can introduce some interesting attack avenues.

Last, often compromising one domain can provide insight on the mindset of the person/people who built it, which might lead to the compromise of a separate domain in the organization. An example of this are network administrators who reuse credentials between different identities in separated domains.

Step 2: Verify If a Vulnerability Can Be Exploited

We started by gathering all the information possible from our user domain. We queried LDAP to obtain a list of the assets in the domain, as well as the IP addresses of the domain controllers.

Then, after looking over the list of assets, we discovered a Group Policy Object (GPO) that was affected by an ancient vulnerability, commonly known as the group password policy vulnerability. This vulnerability is directly linked to a flawed use of domain GPOs, which distributes local administrator passwords to the rest of the machines. Passwords would be found encrypted in XML files stored in the SYSVOL share of domain controllers, which is by default accessible by any domain account. Additionally, the encryption key is a well-known value, which is even disclosed in the Microsoft documentation, giving attackers the chance of decrypting any password they find. As this is a simple test, only requiring them to mount the SYSVOL share and perform a find string operation, most attackers will check to see if this vulnerability is still active.

Given this GPO vulnerability, we were able to easily decrypt the password. However, this password was not currently used by the local admin of any machine in the domain, which could be interpreted as an indicator that this vulnerability had already been fixed in the past by the company.

Step 3: Abuse Kerberos Tickets

Since the password had been changed, we instead leveraged our domain account to abuse Kerberos by requesting service tickets to the key distribution center. Using a technique known as Kerberoast, an attacker can request service tickets for each service owner account in the domain, forcing them to be encrypted with the weak RC4 encryption algorithm.

Since these tickets are encrypted using the password set by the service owner, the tickets can then be submitted to an offline cracking process. Having collected all of this information, we designed our attack path. Though the password we found through the group password policy vulnerability was no longer being used by local admins, we were able to repurpose it as the basis of an internal password spray, in case it hadn’t been changed elsewhere.

And, despite not being used for any high privilege account, the password was indeed valid for five additional domain accounts, enabling us to diversify our interactions with internal devices. This password continued to prove useful, as its structure contained the name of the organization and showed the pattern that could be used to guess the passwords for other domain accounts. We used this information to graph an intelligent cracking attack against the Kerberos tickets through the Kerberoast.

It is worth noting that cracking Kerberos tickets is a slow exercise compared with cracking net-NTLM or NTLM hashes. So, in order to obtain faster results, it helps to already have a well-defined approach like the one we were able to form using the known password. For example, the password Organization_Name5 could indicate that the next password may be Organization_Name6.

We followed the structure of the password to create a hybrid cracking approach, testing each case variation of the client's organization name, followed by a series of one to six characters, including letters, numbers, and special characters. This approach proved effective, as we were able to access two high privilege service accounts in less than 48 hours.

Step 4: Launch a Pass-the-Hash Attack

After we obtained the password for the first service owner, we tested it in the server register, in the service principal name (SPN) field. We believed that the account was a local admin for this server. With these new privileges, it was possible to dump the password hash of the default local administrator account for a pass-the-hash attack. This allowed us to gain administrative access to all the servers in the network.

The second service account we obtained was a domain administrator. Domain admins often use their own accounts to quickly run services, as we found in this scenario. It’s worth noting that this is never a good identity management practice, since the administrative account can then be exposed and compromised through a Kerberoast attack.

Having obtained this password, we then encountered yet another obstacle: the password for the account was expired, and there was no way to reset its value from the internal network.

Step 5: Reset the Password

With no way to reset the value internally, we moved into the external sphere, and attempted to log in to the company's SharePoint through federated services. After seeing the alert that the password was expired, we were redirected to a password self-reset portal, on Windows Azure. This portal allowed users to reset their passwords after providing a one-time password (OTP) received in the recovery phone number.

While this could have easily halted our progress, in this case, a recovery phone number was never designated. This gave us the chance to use our own phone number. After validating the OTP, we successfully reset the account's password.

Step 6: Check if Passwords Are Shared Between Domains

Finally, we moved back into the internal sphere and attempted logging in using the newly reset password. We leveraged our administrative privileges to dump the password domain table for the non-PCI domain, effectively compromising it.

From here, we moved into the PCI environment, where we hadn’t even yet compromised one low privilege domain account. Since the two environments were separated, the only information we had was the IP address of the PCI domain controller. So, our best chance for a quick compromise was to assume that one of the IT administrators in charge of both domains was lazy enough to use the same credentials between domains. As we already had the password hashes for all the users in the non-PCI domain, there was no impediment to attempt a massive interdomain password hash attack against the PCI domain.

Fortunately for us (and unfortunately for this organization’s PCI compliance status), our assumptions were correct. We immediately discovered that a group of users, including a domain administrator, were using the same passwords on both domains.

How to Identify and Reduce the Risk of Insider Attacks

1. Manage Insider Threats with Segmentation and Limited User Permissions

Any employee in your organization has the capacity to become an insider threat, since they can potentially communicate with any internal devices in your network. If segmentation isn’t applied, any individual in the organization can attempt to gain administrative access by logging into their management consoles, which are frequently configured using weak or default credentials, or may even allow anonymous access.

Another potential insider threat is through file shares on the internal network. We frequently find file shares with read and even read/write access for any account in the domain. Sometimes, employees use file shares as internal dropboxes, carelessly storing some kind of sensitive information. We’ve found spreadsheets with passwords, intellectual property, payroll information, among others. As it is difficult to completely eliminate this practice, it’s important to review the current permission scheme on your internal file shares, limiting privileges and preventing default access.

While there are ways of detecting and preventing an unauthorized individual from physically infiltrating your network, you never know if a legitimate employee has gone rogue. You must assume that disgruntled employees are already in your organization, and that they may leverage their current privilege level to attempt compromising your security.

Consequently, you should always check if the current rights granted to each user corresponds with what they really need in order to perform their day to day work. For example, it is rarely necessary for every individual to have a domain account, though many organizations allow this. We’ve also seen presentation devices, such as monitors or teleconference systems, that have been assigned domain accounts for centralized management, which is both risky and unnecessary. Not only this, since these are shared devices, they frequently have a weak or default password that’s easy for everyone to remember.

It should be kept in mind that even low privilege domain accounts have default access to features that could be useful to attackers. For example, they are capable of using the Kerberos protocol, as was demonstrated in the above scenario. They also have the ability to query the LDAP protocol and obtain a list of assets, the current password policy, the date of the last password change of each account, and other information that’s potentially useful to attackers. Following the principle of least privilege substantially limits such risks.

2. Don’t Let Outdated Devices and Data Be Used Against You

We frequently observe the existence of old hardware, like network monitors with media players attached. Such devices run embedded versions of currently unsupported operating systems, such as Windows XP, which are dangerously insecure. Your organization should not underestimate the threat such devices present—an attacker can obtain the domain account from the memory or registry of the device.

Additionally, watch for inadequate garbage collection processes. Often, vulnerabilities are corrected, but remnants are still present in the network. This can occur with system patches that, despite being installed, are not currently applied because a reboot operation was not performed on the patch device. This is also the case with the well-known group password policy vulnerability. If you are no longer deploying the local administrator password via the group policies, ensure that the XML file containing the encrypted password was deleted from the domain controller.

3. Understand the Relationship Between Service Owner Accounts and Kerberos

Service owner accounts are domain accounts used to run services. For example, they run accounts configured to manage IIS web servers or database servers, which are usually created during the installation of services. These accounts are often a prime target for attackers, since compromising one usually means gaining local admin rights, at least over the host on which its managed service is installed. This level of privilege can be attained because an admin did not take appropriate precautions, giving the local administrator both the service account directly in addition to the server. Alternately, a skilled attacker can leverage exploits such as RottenPotato to escalate privileges, gaining local administrative access on the underlying servers.

Another characteristic of service accounts is that they are usually generic, so tracking who made the account and set the password is a complex undertaking. Administration of service accounts is typically managed by a machine and will be stored in configuration files, usually with different types of encryption applied. Because they are managed by machine, there is no reason to assign them easy to remember strings as passwords. Unfortunately, this practice is not always followed, so it often possible to guess or crack passwords for service accounts.

As demonstrated in the scenario, service accounts can be attacked using Kerberoast. First, an attacker requests service tickets from the key delegation center, which is usually the domain controller, simulating the objective of logging into a particular service. Using the credentials of any domain account, the attacker may request service tickets for all the services in your network. The key of this attack is that each service ticket will be encrypted with the account's password for each service owner.

The attacker would then use tools such as Impacket, Mimikatz, or Rubeus, to designate the weakest encryption algorithm possible for the protocol, which is RC4.

Next, the attacker can collect the service tickets and submit them for offline cracking. When it comes to this type of cracking, attackers can test as many candidate passwords as they can imagine. Since there is no lockout policy to defeat, they are only limited by computational resources and time. Small cracking attacks are the most common, and mostly follow a hybrid approach to cover the most widespread password trends.

It is important to take all of this into account before defining the password for a service account. Easy to remember passwords have a great chance of being cracked, especially when an attacker has already accessed a domain account.

4. Have a Consistent Authentication Scheme

A variation between access rules was leveraged in our scenario to help with the domain compromise. Two-factor authentication was not adequately configured in a domain admin account, making it easy to compromise that particular account. Compromising just one account allowed us to gain entry elsewhere, so consistency is crucial. Remember to ensure that defined security controls are the same for every account with administrative privileges, and check that each point of access is enforcing the same restrictions.

5. Avoid Sharing Local Admin Accounts and Never Reuse Credentials

Shared local administrators are quite common (having a local administrator account with the same password for a group of domain machines), as it makes it easy for an IT team to manage multiple domain computers. However, this is a poor security practice, as it means that an attacker who got these credentials would gain access to every single system that uses the shared local admin account.

There are now technologies that allow organizations to entirely avoid sharing local admin accounts. For example, Local Administrator Password Solution (LAPS) from Microsoft sets a different random password for the common local administrator account on every computer in the domain. If you are unable to use such a solution, there are other ways to manage this issue.

For user terminals, you should limit the local admin privilege to the account associated with the computer owner. For servers, you can assign a single local admin rights to designated domain accounts, which is essentially assigning one account responsibility, and encouraging that account to follow strict password management practices.

Once a domain has been compromised, password strength is no longer a factor, as an attacker might directly seize the password hashes to authenticate as any user they want, using the pass-the-hash technique. Because of this, it is critical that domain admins not only have hard to guess passwords, but also must be required not to reuse passwords between identities, as it is the only way to prevent the propagation of the compromise to other domains.

Lessons Learned from Internal Attacks

With this scenario, we can see that penetration tests don’t just provide an idea of what it takes for an external attacker to gain entry, but also how an insider threat can quickly escalate from having low privileges to having all the privileges.

In part 4, we’ll walk through our last scenario. In it, we'll discuss how Core Security Services tested a large organization using smartcards, and we will delve deeper into Kerberos, exploring how Kerberos delegation can be used.