Diary Entry #2
Today, I Stopped Waiting and Started Coercing
In our last entry, we covered the basics of authentication relay attacks and provided one example where these principles were used to execute a novel attack against a client environment. It should be obvious that execution of a relay attacks starts by gaining access to a set of network credentials.
It is common practice for even the most inexperienced penetration testers to attempt to capture and “relay” user account credentials on client networks. These techniques, including abuse of legacy Windows protocols (MITRE ATT&CK ID: T1557.001) and DHCPv6 abuse (MITRE ATT&CK ID: T1557.003) are well documented and are explicitly not what will be covered in this case study. However, a basic understanding of those processes will be helpful in understanding the vector presented here.
These techniques can be executed to obtain NetNTLMv2 hashed user account credentials, which can then be “cracked” offline to recover plaintext user account credentials, or “relayed” to other systems on the network to obtain unauthorized access to systems without ever having to “crack” the password hash. As we covered in a previous entry, relaying user account credentials requires certain insecure configurations to be in place on target systems. For one type of relay attack, the requirement is that Server Message Block (SMB) Signing, a security feature that implements additional cryptographic protections for SMB connections, is not enforced.
The problem with these user account-focused techniques is that they require a certain amount of time and outright luck to execute. What if we don’t want to wait for more user account hashes, or what if these techniques are not exploitable? In cases where an attacker has gained access to one set of credentials, any set of credentials, another attack vector becomes available.
Forcing Computer Account Credential Exposure
This attack vector relies on an attacker’s capability to coerce (or “force”) authentication to occur. PKFOD has previously covered one specific mechanism that can be abused to force a system to authenticate to arbitrary hosts on the network. With any set of Active Directory credentials in hand, there are numerous options available to an attacker to force target systems to spit out their NetNTLM computer account hash. These options include the previously covered abuse of MS SQL extended stored procedures and abuse of several authenticated remote procedure calls (RPC). In all cases, successful exploitation results in the disclosure of the computer account credentials associated with the target system.
Now, “cracking” these hashes is not really feasible, as computer account credentials are very long and complex by default and managed automatically by Active Directory. Therefore, the only option is to relay these credentials to other systems on the network. The most valuable part of this attack vector is that the attacker can control every aspect of the attack chain, making this a very reliable technique under the right conditions.
By using open-source tools such as Coercer, even the lowest privileged user and computer accounts on a network can be used to execute an authentication coercion attack. It should be noted that Microsoft does not consider coercion weaknesses that require authentication a vulnerability, but rather a feature and therefore these techniques will not be patched or fixed.
As covered in our prior entry, what you can do with your relay is entirely dependent on the computer account’s permissions. That being said, computer accounts have some unique properties that make them hugely valuable under certain circumstances. These more advanced techniques, such as Resource-Based Constrained Delegation abuse and the Shadow Credentials technique will be covered in future entries. For today, let’s look at one unique real-life scenario where a single computer account relay between two infrastructure servers ultimately resulted in domain compromise, without relying on Active Directory directly.
A Computer Account Relay Oddity
During a recent ethical hacking exercise on a relatively large and complex internal network for an organization with a mature information security program, the team found themselves in a fairly standard position. There was a general lack of exploitable technical vulnerabilities on the internal network and the organization had implemented a number of secure configurations throughout the environment. Therefore, to achieve the goal of the test, the PKFOD ethical hacking team was required to identify and abuse other, more novel, weaknesses.
In this specific case, the team was able to recover one set of unprivileged user account credentials before it became clear that continuing to attempt to recover user account password hashes was a waste of valuable resources. Additionally, credential relays to Active Directory via LDAP/S were entirely out of the question due to the presence of LDAP signing and channel binding configurations. As such, the team was forced to look for other vectors to obtain additional access and escalate privileges.
After significant enumeration and being met with dead end after dead end, the team decided to take what amounts to a “shot in the dark” as a last-ditch effort to gain access to valuable systems. The team began focusing on identifying computer accounts with elevated privileges.
The “shot in the dark” aspect of this technique included methodically forcing Windows servers throughout the environment to authenticate to all other systems on the client network where SMB signing was disabled. To be candid, the team did not have high hopes for this technique and we knew it was noisy. After all, under what circumstances would one server have administrative privileges on another?
However, the potential value in exploitation of computer accounts is often overlooked by penetration testing teams. Attackers tend to focus on valuable user accounts, rather than the Active Directory accounts associated with workstations and servers themselves. This is because, in general, the assumption is that computer accounts have very limited permissions at the network level, which is very often true. As such, organizations often spend much more time and effort in securing privileged user accounts than they do securing privileged computer accounts. However, in this case, abuse of computer account permissions combined with the authentication coercion technique outlined above ultimately resulted in complete network compromise.
Lo and behold, the team identified that one server that did have local administrative privileges to a large number of other servers in the environment. As it turns out, this system supported configuration management processes and was provided local administrator privileges to automatically manage and enforce configuration settings across the server environment. Taking a step back, this meant that the team was able to use a very low-privileged user account to force this configuration management server to authenticate to the penetration testing system and then relay those credentials to other servers on the network over SMB, resulting in administrative access to a large number of valuable systems.
Example result of successful relay of computer account credentials to another server over SMB. Note that MemberServer03$ is a local administrator on the target, meaning this server has been compromised.
Post-exploitation of these compromised systems then resulted in the identification of a vulnerable scheduled task configuration (a scenario to be covered in a future entry), which ultimately allowed the team to obtain Domain Administrator privileges. After a few days of failing to execute standard attacker tactics, techniques and procedures, the team was forced to look for other, relatively uncommon, vectors to demonstrate risk exposure in an environment that was well secured and well protected.
From a hacker’s perspective, elevated permissions are elevated permissions, regardless of the type of account. It’s a takeaway for all the information security professionals reading this case study to remember that any account, computer or user, can be valuable and that authentication coercion is a weakness that Microsoft will likely never address. For organizations, it’s critical to ensure that the account management strategy is not limited to just user accounts. While it may be required to allow some systems to maintain elevated access to other systems, just as it is required to allow some users to maintain elevated access (i.e., administrators), computer accounts with elevated permissions should be treated as carefully as user accounts with elevated permissions.
What to Do Next
In short, organizations can take the following steps to reduce the risk associated with authentication coercion in general, as well as this relatively novel attack vector:
- Enable and enforce SMB signing on all systems with exposed SMB services. This will eliminate the ability for an attacker to relay any credentials to SMB.
- Enable host-based firewalls on all systems, including servers, to expose the minimum network services required to support business functions and similarly restrict traffic between user and server networks. If the team was unable to do any of the following due to network or host-based restrictions, this attack would have failed:
- Communicate directly with the initial server via Microsoft Remote Procedure Calls (MS-RPC), or
- Force the server itself to authenticate back to the penetration testing device on the user network over SMB, or
- Communicate directly to other infrastructure servers over SMB.
- Manage local administrator group membership just as carefully as membership to privileged Active Directory security groups. It’s often the case that local administrative access to a single valuable system is all that is required to obtain privilege escalation at the Active Directory domain level. If one computer account requires administrative access to other machines, organizations must be aware of and address, the fact that this opens the door to a relatively simple, if uncommon, attack vector.
Do these attack vectors exist in the environment you are testing or defending, right now?