Getting Inside the Mind of an Attacker Part 2: External Attacks on Active Directory

Authored by: Julio Sanchez

In part 1 of this series, we explored what makes Active Directory so appealing to threat actors, and how attacks can severely harm an organization. For the remainder of the series, we’ll walk through several examples taken from penetration testing engagements the Core Security Services team has performed to explore ways attackers may target Active Directory, and discuss how you could thwart such an attack.

For our first scenario, we have an external attacker with no internal access breaking in using a password spray attack.

Step 1: External Recon 

Any attacker worth their salt will start by doing reconnaissance, looking into the organization or specific people to see if they can get helpful details that may help facilitate a breach. For example, in our research and recon stage during this scenario, we observed that the organization exposed two HTTPS services: Microsoft Exchange Server and Citrix Portal. An attacker would likely make the following assumptions:

1. All logins authenticate against the same LDAP directory, which may be the main active directory in an organization. (One thing worth noting is that LDAP services are commonly directly exposed to the internet, despite it not being a security best practice. Organizations sometimes choose to allow the exposure of the LDAP service in order to interact with a third-party service. In this scenario, the LDAP was not directly exposed.)

2. There is no other authentication scheme in place to provide additional security. Without measures like two-factor authentication in place, a valid set of credentials would provide access to the identified services. 

Once recon is complete, an attacker typically has enough information to continue attempting to compromise the organization’s active directory.

Step 2: Password Spray Against Outlook Web Application (HTTPS Login) 

Next, we performed a password spray attack against the exposed Outlook Web Application. To carry out this attack, we crafted a list of potential email addresses from employee information we compiled during recon, using public resources like LinkedIn and the organization’s public facing website.

For each one of these addresses, we attempted to log in using a list of common guessable passwords. In this case, we started with Summer2019!. All it takes to gain initial access is a single user not following best password practices.  Sure enough, we were able to obtain one valid set of credentials.  

Step 3: Attempt Logging Into the Citrix Portal and Check Access Level 

Using the credentials harvested in step 2, we logged into the Citrix Portal, a centralized digital workspace that gives users remote access to their internal applications. Typically, attackers use tools like Citrix to find applications which are being run on an internal server. These applications can sometimes be undermined and escaped to gain remote command line access to that underlying server. In this case, the user account we compromised had remote access to a virtual desktop, which linked with the internal network, providing us with a way to start communicating with the internal devices.

Step 4: Enumerate Domain’s Information From the Virtual Desktop 

Having established a connection, we leveraged this access to start gathering information about the organization. Any threat actor in this position would be able to query the internal DNS and LDAP servers, and obtain a list of users and computers in the domain, as well as information about the domain controller.

Step 5: Check for the Existence of EWS PushSubscription for PRIVEXCHANGE

Next, we checked to see if the Exchange server was vulnerable to the PRIVEXCHANGE bug (CVE-2019-0686), on the web services endpoint. Impacted versions of Microsoft Exchange were prone to a privilege escalation vulnerability that allowed any attacker who had successfully compromised a user mailbox to then force the server to authenticate against an internet arbitrary destination.

The Exchange account had elevated privileges by default. From there, an attacker could elevate the privileges of regular domain users through simple LDAP queries, with the final intention of compromising the domain. This environment did contain the PRIVEXCHANGE vulnerability, so we were able to escalate our privileges from those of the original user whose credentials we had taken, to those of an administrator.

Step 6: Attempt Relaying HTTP to Internal LDAP Server 

The last piece of the puzzle was gaining the capability to communicate with the internal LDAP server from the outside. For this, we decided to implement a reverse SOCKS proxy, which would create a tunnel between the internal network and an attack server on the internet. For this we used the rpivot tool, which is a client-server application that allows you to tunnel traffic that originated from the internet to any internal network in which the client binary is deployed.

The client part of this tool is a portable binary that can be deployed without any kind of installation on a Windows machine. However, it is also a well-known hacking tool, so the signature of the binary is often detected by endpoint protection agents, which is what occurred in our scenario. We introduced some minor variations into source code and then recompiled the client binary, which produced a different file signature. Using this new version, we were able to evade detection.

Step 7: Profit From Get-Replication-Changes-All Rights 

After deploying this new binary, we were able to initiate the stable tunnel between our server and the internal network. This connection was then used to complete a cross protocol NTLM relay attack between the external exchange server and the internal domain controller.

As a result of this attack, we were able to escalate the privileges of the initial compromised user account, granting it the privileges of performing a domain replication operation through the SMB protocol. Once this was done, we were able to use this elevated account to obtain the password hashes for all the domain accounts by connecting to the internal domain controller via SMB and initiating the domain replication operation. Consequently, we had successfully gone from being a completely external user, to having full access to the organization’s IT environment.

How to Identify and Reduce the Risk of External Attacks

Now that we’ve walked through a scenario an attacker may use to break in, let’s go over four strategies that would have thwarted us along the way. 

1. Prevent Password Guessing.

Step two involved a password spray attack, which can be achieved through password guessing—testing a series of credentials with the intention of successfully guessing at least one. Attackers repeatedly try to access exposed systems, like an email server, by crafting and trying a list of candidate usernames, and testing each one of them with a predefined, easily guessable password.

In order to reduce the risk of a successful of password spray attack in your organization, you should define a strong authentication scheme, a strong password policy, and improve your detection and response mechanisms. 

Best practices indicate you should lock out a user account for at least 30 minutes after three to five incorrect login attempts take place in a short time frame. For additional security, IP banning prevents the IP address from where the failed login attempts were initiated from ever contacting your systems again. 

However, attackers know that you can’t lock out accounts after only one failed login attempt. For organizations with lockout policies, attackers will simply create longer lists of potential usernames to maximize their chance of success. So it’s important not to rely solely on lockout policies.

Since we know, attackers rely on the common tendency to use easy to remember passwords, which are easily cracked with dictionary or brute force attacks. Many organizations attempt to combat this by enforcing password complexity and rotation policies. However, complexity requirements like minimum length, or the use of letters, numbers, and symbols, have now been around long enough so many of these passwords have become predictable. For example, since most companies enforce password rotation each three months, typically coinciding with the season change, a password composed of the current season, year, and a special character (usually an exclamation point) is increasingly common.

Since people tend to default towards passwords that are easy to remember, one solution is to use a password manager, which is a small local database that people can use to memorize their passwords on their behalf. This allows people to generate random passwords that are truly complex, like N8d#ko2M4We)3kjc8.

Finally, the implementation of multi-factor authentication (MFA) is particularly crucial. Users are asked for an additional piece of information after providing valid credentials. This includes something a user has, like a phone, smart card, or security token, or something only the user can provide, like biometrics.

2. Protect Every Point of Access to Your Internal Network. 

Are you aware of how many entrances your organization has? How safe are each of these access points? Do they all adhere to the same security policy? It’s important to limit exposure to only what is strictly necessary to guarantee business continuity.

However, organizations often expose a myriad of different services and sometimes the authentication is not consistent between all of them. For example, during a pen test, the Core Security Services team encountered an organization that had deployed a VPN that required a pre-shared IPsec key, in addition to domain credentials of particular users before allowing access to internal services.

We found that we were able to directly access the remote desktop using one of the passwords in the infamous list of top 25 worse passwords of 2018. By finding another access point with weak protection, it didn’t matter how complex the security measures were for the VPN. In short—there’s no point in deadbolting the front door if you leave a window wide open.

3. Limit Excessive User Rights.

It’s important to be aware of what rights you’re granting to employees when issuing them a domain account. Domain accounts, created and stored centrally on Active Directory, have inherent administrative privileges which are valuable from an attacker’s point of view.

No matter how low the privileges are set, any domain account user can query the LDAP database, allowing access to a list of account names, groups, and computers in your network. The list of Windows computers allows an attacker to avoid performing a slow and noisy port discovery exercise to map the internal network. (It should be noted that this may be restricted by modifying the access control list of the domain and by limiting the maximum number of objects returned by LDAP queries. However, doing so might have undesired consequences in the availability of internal services.)

Also, any compromised domain account will provide an attacker with the ability to use and abuse the Kerberos protocol, which will be discussed in detail in part 3 of this series. Finally, domain credentials will also give attackers the ability to tunnel traffic through corporate proxies. 

Ultimately, the principle of least privilege should be strictly followed when it comes to domain accounts, granting them to only employees that absolutely need them. Most users should be able to perform their day-to-day duties using local accounts.

4. Manage Configuration and Regularly Patch Systems.

Hackers will leverage unrestricted outbound traffic to exfiltrate internal data, so it’s critical to configure which kind of traffic can leave your network. It’s recommended to limit the outbound traffic to only what is really necessary for a normal business, typically just DNS and HTTP packets.

The scenario presented above wouldn't have been possible without the aid of the PRIVEXCHANGE issue, so it’s critical to always keep up to date on new vulnerabilities and patches. Don’t forget to reboot your systems after patching, so the fixes are applied correctly. Additionally, always ensure that older software is updated to the last patch level. 

New Attack Scenarios, New Lessons Learned

With this scenario, we can clearly see the advantage of having a penetration test performed. They allow an organization to see not just what vulnerabilities are present, but provide a full picture, showing exactly how these vulnerabilities could be leveraged to gain access to an environment and providing insight into what remediation measures would be the most effective.

In part 3, we’ll explore another scenario that Core Security Services encountered during a PCI penetration test, which involved exploiting a very old vulnerability and cracking Kerberos tickets.