An insidious issue has been slowly growing under the noses of IT admins and security professionals for the past twenty years. As companies evolved to meet the technological demands of the early 2000s, they became increasingly dependent on vulnerable technology deployed within their internal network stack.

While security evolved to patch known vulnerabilities, many companies have been unable to implement released patches due to a dependence on legacy technology. In just 2022 alone, X-Force Red found that 90% of all on-prem Active Directory deployments that were tested were vulnerable to attacks due to the existence of these legacy technologies. Furthermore, the complexity of enterprise networks has grown exponentially, leading to a sprawling landscape of misconfigurations. These misconfigurations are used in a significant number of attacks, which we highlighted in our X-Force Threat Intelligence Index 2022.

For decades, organizations have been focused on trying to perfect their perimeter security under the assumption that it was possible to keep attackers out of their networks. But as hackers, we can tell you that there is always a way in. Always. And this isn’t exactly news — organizations are rapidly pivoting to new solutions. Implementing strategies like zero trust is a big part of those new solutions: in our 2022 Cost of a Data Breach report, we found that 41% of organizations have already implemented zero trust principles. But as organizations look forward to new solutions and strategies, they must also look back and address their decades of technical debt.

The struggle of increasing complexity

As the number of devices within a network increases, the complexity of the network also grows exponentially. Maintaining control and efficient oversight over a large number of systems is incredibly difficult, which is why scalable access management and device aggregation solutions exist. The most prevalent answer to this efficient management and access control problem is Windows Active Directory (AD), which allows network administrators to manage devices, credentials, users, and their permissions from a centralized location. A problem arises as an AD environment grows: user security relationships become difficult to manage, understand, and visualize at scale, which leads to limited visibility of user permissions within the domain. And that’s just for one domain.

These permissions transparency issues become increasingly evident within larger organizations, where you may have a forest comprised of multiple domains (or even an environment with multiple forests). As networks matured in the early 2000s, manually adjusted configuration issues started to pile up. As time passed and the personnel managing these environments moved on, organizations found themselves saddled with a stack of forgotten and unneeded permissions. That stack is what we’re seeing current network administrators struggle to identify and manage. And manage they must, because the darkest corners of today’s networks contain the looming shadow of decades of unraveled configuration debt.

The compatibility first mindset

Security was not a prime concern during the late 1990s and early 2000s. As a result, the devices and communications protocols designed during this era are plagued with security issues. While many of these flaws are fixed in today’s technology, businesses built their processes of doing business on these older forms of technology, resulting in long-term dependence on legacy devices and communications protocols.

It’s extremely common for businesses to prioritize continued business operations over deploying new technology, especially when that deployment can come with disruptions or downtime. While it’s true that many IT admins would prefer to phase out older pieces of technology, they often cannot due to multiple levels of dependence within their organization. And while it’s not as common, others are complacent and fail to see the need to replace an outdated and vulnerable piece of software that does its job. Seeing the demand for compatibility, vendors adjusted their products to, by default, support legacy communications protocols, such as Link Local Multicast Name Resolution (LLMNR), Net-NTLMv1, and SMB signing disabled by default. As a result, many networks are left vulnerable to a series of attacks fixed over a decade ago.

The role of active directory on modern-day networks

Let’s level set on the importance of Active Directory for a moment. In most organizations, Active Directory is the mechanism through which practically all of the Windows devices, and often many Linux devices, are managed. This means any Active Directory administrator has complete control over all connected systems.

Realizing this, pentesters, red teamers, and threat actors alike commonly focus on breaching Active Directory environments, as its compromise will yield complete control over an organization’s IT environment.

While Windows has been receiving an increasing number of new features that help harden Windows environments, the focus on compatibility by default has resulted in up-to-date Windows systems running vulnerable services that can result in a total compromise of an Active Directory environment.

Old attacks that breach modern networks

While many attacks have been released against the Windows operating system in recent years, many breaches can be attributed to legacy attack vectors instead of cutting-edge vulnerability research. Most Windows networks are still vulnerable to attacks known for over two decades. To demonstrate these issues, let’s walk through a typical attack path within a corporate network.

Internal penetration test scenario

To set the stage, let’s take a walk in the shoes of your average pentester. You have just been assigned to perform an internal penetration test and are dropped onto a new network. Your jump-box is placed within a subnet containing hundreds of users’ desktop machines. You take stock of your surroundings, perform reconnaissance on the environment, and find all systems running Windows. Your next logical next step is to perform an authentication coercion attack.

💡 An authentication coercion attack is when you use an issue within a system that results in that device sending credentials to your testing machine.

Performing authentication coercion

By default, Windows uses three broadcast-level name resolution protocols: LLMNR, Multicast DNS (mDNS), and NetBIOS Name Service (NBT-NS). If you are unfamiliar with the concept of broadcast-level name resolution, it’s similar to someone on the street shouting to everyone around them, asking, “Where is this store?” In this scenario, anyone in the crowd of people could respond to that person’s question with the right location; or, a bad actor could answer their request and direct them to a pop-up shop set up to look like the location they initially asked for. This user could, without realizing it, travel to the fake storefront and give their payment information to malicious actors.

In the same way, when a computer attempts to resolve a name to an address over a broadcast-level name resolution protocol, attackers can respond to the query and redirect the device to their attacker’s machine, which may result in the system sending credentials to the attacker without any user interaction. In slightly more technical terms, the attack works like this:

1. A service within a Windows system attempts to resolve a name over DNS. If DNS does not know its location, then Windows automatically falls back onto using LLMNR, mDNS or NBT-NS to resolve its query.
2. An attacker on the same subnet as the device sending the broadcast request responds to the query and informs the system that they are the machine the name resolves to.
3. The device, having received the location, may then attempt to authenticate to the attacker’s machine by sending a user’s credentials over the network using the Net-NTLM protocol.

SMB signing and Net-NTLM relaying

Before we can understand what can be done with these newly acquired credentials, we must first look at a high-level overview of how Net-NTLM works. Net-NTLM is known as a challenge-response authentication protocol, meaning during authentication, a question the server already has the answer to is given to the client; if the client answers correctly, they are authenticated. In this case, the question is: can you encrypt and then proceed to hash a random sequence of numbers using the user’s credentials as the encryption key? This process follows the following steps:

1. A user inputs their username and password, and the inputted password is hashed using the NT hashing algorithm.
2. The client sends a request for authentication.
3. The server generates a random sequence of numbers to use as a challenge.
4. The server generates a solution to its challenge by fetching the user’s NT hashed password from its database, encrypting the challenge, and then hashing the result.
5. The challenge is sent to the client.
6. The client encrypts the challenge using the NT hashed password inputted by the user as the key and then hashes the result. This is then sent back to the server.
7. The server receives the client’s answer and compares it to its own. If they match, authentication is successful.

Now that we understand Net-NTLM a bit more. Let’s see what can be done using our previously intercepted credentials. One option is to perform a password cracking attack, which may fail due to the complexity of the password. You may be thinking about passing this hash, but this is impossible because we have intercepted a Net-NTLM authentication hash, not an NT hash. One native vulnerability in this protocol is known as a Net-NTLM relay attack. It allows threat actors to coerce authentication and then relay each request as it occurs to a target. If successful, it may result in a threat actor gaining immediate control over a machine if that user had local administrator permissions.

Let’s continue our previous example to understand what a Net-NTLM relay attack is. An attacker heard our victim asking for the location of a shop and successfully redirected the unsuspecting client to their fake store. In this example, the victim pays using their cell phone, which generates a unique time-limited code that can be used to withdraw money from the account once. Upon checkout, the attacker relays the generated code and makes one purchase using the victim’s account.

A Net-NTLM relay attack works in the same fashion. When we originally coerced our authentication, we had the victim authenticate to our device. Instead, we could have forwarded their login process to another machine that will see the login attempt as being established by the attacker.

To protect against Net-NTLM relay and other machine-in-the-middle vulnerabilities, Microsoft introduced SMB signing over two decades ago in Windows Server 2000. This addition to the Net-NTLM authentication protocol helped ensure that messages were not tampered with while enroute to the server. In theory, this attack vector should have been squashed long ago. In practice, all versions of Windows besides Windows server do not enable SMB signing by default. As a result, most organizations are unaware that their default deployment of this operating system is vulnerable to an attack from two decades ago.

Let us continue with our scenario by resuming with you analyzing the information from the recon phase, which reveals that most hosts do not have SMB signing enabled. Using this knowledge, you start your authentication coercion attacks. Any coerced credentials are then sent to a tool currently configured to relay them to the vulnerable servers. After three minutes of runtime, you relay a user with local administrator privileges over a device.

Shared credentials

One of the most significant issues that the IBM X-Force Red internal penetration testing team has found during its time is a lack of credential hygiene on corporate networks. After compromising a device, one of the most common ways to laterally move around a network is to dump the local SAM database. This database contains all local account password hashes, including the local administrator. After obtaining this credential, pass the hash can be used to spray the administrator username and password to attempt local logins throughout the environment. It will likely result in horizontal or lateral movement within the domain.

In our scenario, you obtained local administrator rights to a machine and then dumped the local SAM database. Spraying these credentials revealed that the local administrator password was shared on a domain controller, which gave you instant control over the environment.

Final thoughts

Modern threat actors are moving through networks more efficiently than ever. For defenders to have a better chance at defeating incoming threats, organizations need to shift away from convenient but insecure by default. IT administrators must be educated about ensuring unused services are disabled within their operating systems, and executives must fully understand the risks involved with decades of unaddressed technical debt. Focus needs to shift from solely accepting the risk of vulnerable legacy technology to seriously investing in new solutions that push developers to create unique, secure implementations of legacy code that can be easily deployed while also minimizing the risk of disruptions.

Attend our DEF CON Workshop @ Red Team Village

Do you want to learn how to perform the attacks mentioned here and much more in a hands-on workshop with a virtualized business network to practice on? If this article piqued your curiosity, you should attend X-Force Red’s Active Directory Hacking Workshop: “How Most Internal Networks are Compromised: A Set of Common Active Directory Attacks and How to Perform Them from Linux” at DEF CON 30. It will be on Saturday, August 13th 1:00 p.m., within the Red Team Village. This workshop will cover the following attacks:

– NTLM Relay

– LLMNR NBT-NS Poisoning

– DHCPv6 Poisoning

– Multiple Active Directory Certificate Services attacks

– Kerberoasting

– AS-Rep Roasting

– Kerberos Delegation attacks

– Printerbug/SpoolSample

– PetitPotam

– NTLMv1 Downgrades

– noPac

– Shadow Credentials

– Password Reuse between accounts

– Shared Administrator Passwords

– Bloodhound usage

– Foreign Administrator privileges

– And more!

This workshop will be taught by X-Force Red’s lead of internal network hacking: Scott Brink, and his co-Leads Sung Gwan Choi and Shikata_vx.

If you are not attending DEF CON, X-Force Red is happy to brief you about these attacks. Schedule a briefing here and make sure to follow our Twitter.