Blogs

Mapping the Threat Landscape of Legacy Active Directory

For over two decades, system administrators have relied on Active Directory (AD) and the Lightweight Directory Access Protocol (LDAP) as authoritative solutions for managing authentication and authorization to LAN-based resources. Originally designed as an intuitive method for provisioning access rights to users, the continued iteration of AD has introduced tooling that provides granular access control, allowing admins to tailor privilege delegation for specific use-cases. This has cemented AD as one of the most powerful tools in modern enterprise networking and made it a necessary component of many organizations’ struggle to maintain a structured Identity and Access Management infrastructure.

This power comes at a cost, however; increased complexity brings with it more opportunities for risk of misconfiguration. As a result, AD serves as not only one of the foremost methods for securing your network, but also as one of the largest attack surfaces for threat actors. Attackers, penetration testers, and threat researchers have worked tirelessly to enumerate the many methods of abusing the intended (and unintended) functionality of AD to obtain unauthorized access to domain resources, achieve persistence, and facilitate privilege escalation from non-administrative users. This has culminated in an entire genre of attacks predicated on AD, and exploiting it has become a unique discipline of its own.

In the last decade, cloud-based AD solutions have become much more prevalent in the enterprise network space, with many organizations choosing to either migrate to a full remote AD infrastructure or transition to a hybrid implementation that leverages traditional AD to support legacy applications and hosts. In 2024, a CDW survey revealed that nearly half of organizations across the private and public sector have begun to make the move to cloud-based platforms in some capacity, with this number expected to rise in the coming years. With this in mind, penetration testers and threat actors alike have begun to pivot their research into the novel vulnerabilities that these new deployment methodologies present; however, this still means that a majority of enterprise networks still employ traditional AD in some capacity. While cloud-based solutions offer enhanced flexibility, redundancy, and colocation capabilities at a fraction of the price of a hot site, the migration process and costs are often prohibitive for small to mid-range businesses.

As such, this article takes a close look at several of the most common on-premise AD-based attacks, with a specific focus on what they look like at the network level. We’ll examine how these techniques appear on the wire, how and why they often evade detection in traditional enterprise networks, and what defenders can do to identify and contain them. Along the way, we’ll tie each technique to the MITRE ATT&CK framework and show how Zero Trust principles—like continuous verification, least-privilege access, and network segmentation—can help organizations detect and mitigate these threats in real time.

Active Directory: Flexibility at a Price

Legacy AD and LDAP have historically served as extremely effective Authentication, Authorization, and Accounting (AAA) solutions, enticing many third-party application developers to integrate it into their own products, such as NAS devices, printers, and even networking equipment. The same is true for traditional Windows-centric solutions such as network shares and Group Policy Objects (GPOs), making access to resources and administering users and computers a breeze. The ubiquity of LDAP and AD has rendered it both high-value and high-risk, as a threat actor who manages to find a path of exploitation within the domain can often leverage it to gain access to a trove of your organization’s most valuable resource: data.

This illustrates one of the largest security gaps in legacy AD. It functions under the assumption that the internal network is safe. Although Microsoft has spent years improving the security posture of AD, the entire premise of its tooling is built on the notion that the people in your network are there for legitimate work-related reasons. This conflicts with the Zero Trust model, since any level of implicit trust provides an opportunity for an unauthorized user or asset to access a resource. It’s like locking the door to your house; by design, this will only keep out honest folk. If a threat actor gains Layer 3 network access (or even worse, access to a domain account), you will likely be reliant on a well-configured AD environment, along with solid network and event monitoring solutions, to identify the attacker and force them back out the door.

Many of the authentication protocols inherent to AD, such as Kerberos, SMB, and LDAP, will expose sensitive operations to any user within the perimeter of the network. This is intentional. Active Directory is essentially a “map” of the network’s resources and the permissions granted to User, Computer, and Group objects. In order for such a protocol to function, every object needs to be able to see what resources are available—which, to an attacker, is a goldmine of information. Domain Controllers (DCs) are especially high-value targets, whether read-only (RODC) or read-write (RWDC), with RWDCs posing greater risk due to their ability to modify objects and replicate changes across the domain. These risks extend to both on-prem data center deployments and edge environments, where physical or network security may be weaker. Best practices include strict RBAC, limiting the number of RWDCs, deploying RODCs in branch or edge sites, implementing tiered admin models, and ensuring continuous monitoring for anomalous behavior.

Zero Trust and Legacy Active Directory

The Zero Trust framework seeks to eliminate all implicit trust within a network, operating under a “never trust, always verify” rationale. Within this context, AD’s model of the implicitly trusting users and devices after authentication for every request thereafter is inherently insecure. Every access request from a user and device should be treated as potentially malicious and must be explicitly verified.

In the past, security professionals relied mainly on perimeter defenses such as firewalls and VPN’s to address their security concerns. While this is still recommended to limit an external attacker’s ability to ingress into your LAN (we’ll touch on this later), Zero Trust requires that you also consider what would happen if a threat actor were inside your network.

Many of the largest breaches of the last decade have been predicated upon simple misconfigurations and social engineering. Once an attacker gains access to an internal device, you become completely reliant on internal controls to quickly identify them and limit their impact. This is where AD comes into play: the configurations you make here are one of the first and last lines of defense for an internal threat, and if you leave low-hanging fruit exposed, they won’t hesitate to take a bite out of the apple. Operating under the assumption that a threat actor is in your network at all times, a healthy “paranoia” is developed that will help your security team to better combat a threat, be it a script kiddie or an APT.

Why a Network-Layer Perspective Matters

One of the more pervasive aspects of AD-based attacks is that they often occur over the wire and avoid touching disk entirely. These attacks don’t rely on placing malicious binaries on hosts, which a decent EDR would likely catch right away. Instead, they focus on finding misconfigurations and abusing AD’s intended functionality, which is much harder to detect in a large and noisy network.

The good news is that most of these attacks have clear signatures that a skilled network analyst or robust monitoring solution can identify. Packet captures and flow data can reveal indicators of compromise associated with many of the most common AD attack vectors. When used in conjunction with endpoint detection and SIEM logs, network-layer insight can give defenders confidence that if a threat actor gains access to the network, someone will see it, recognize it, and stop it before serious damage is done.

AD Attacks in Practice

Now that we’ve covered the background of legacy AD and how it contributes to the attack surface of most enterprise networks, let’s take a look at some of the most common exploits associated with it. These attacks have been and continue to be successful in penetration testing engagements and have been used in the wild by threat actors in many high-profile breaches. For each attack vector, we’ll discuss how the attack works, provide insight into the network traffic associated with it, and offer tips on how to identify it within your LAN.

Password Spraying

MITRE ATT&CK Framework References

Password spraying is one of the many ways an attacker with Layer 3 network access might try to compromise domain user accounts. This attack relies on having some degree of information about the AD environment they’re targeting, namely, usernames. There are multiple ways a threat actor can obtain this information, but it’s often gathered through Open-Source Intelligence (OSINT). Attackers will scrape publicly accessible resources such as social media and corporate websites, enumerate staff members of the target organization, and identify likely naming schemas. Even worse, many clearnet and darkweb hacking circles will routinely share or sell this information to one another, providing easy access to enterprise emails, usernames, common passwords, and other sensitive user data.

This provides an attacker with two very powerful options for launching their attack: social engineering and user enumeration. Given that so many organizations today publish staff contact directories online, it is often trivial for an attacker to take information gathered during OSINT and curate a malicious email targeted at staff likely to have administrative access in the enterprise. That means you, NOC, SOC, and Sysadmin staff. And the most unnerving part? Social engineering represents the most prolific method of LAN ingress from the Internet. As such, ensuring that staff are aware of the threats that exist, how to identify social engineering attacks, and the risks that one’s social media presence can present to an organization are critical to keeping external threats outside.

Since many organizations use the same naming conventions for internal domain accounts as they do for email addresses, it’s not uncommon for a threat actor to compile tens or even hundreds of valid usernames this way.

Once a list of usernames is assembled, attackers often use tools like netexec and kerbrute to test commonly used passwords. Unfortunately, this is a highly effective method for gaining domain-level access, since many organizations enforce minimum character length and complexity requirements that still allow for weak passwords like “Password1.”

Let’s walk through such an attack in action. We’re using a simulated lab comprised of several domain accounts, one of which has been configured with a poor password. The minimum password length is set to 8 characters, and no lockout threshold has been configured, something penetration testers encounter far too often.

Using netexec, the attacker launches a password spray against the list of usernames, eventually gaining access to one account:

During testing, Wireshark was running on the domain controller to give us visibility into how the attack appears at the network level. As netexec attempts to authenticate over SMB, we see a rapid flood of packets representing failed login attempts, all coming from the same host in quick succession:

This type of traffic is highly abnormal and should stand out to any decent network monitoring solution. Drilling into one of the packets, we can extract quite a bit of detail about what the attacker is doing:

We can see the specific username being tested, along with heuristics often associated with automated attacks, such as the absence of a workstation name. Taken together with the burst of failed authentications over SMB from a single IP address, this clearly indicates malicious behavior.

We can also validate these findings through Windows Event logs, which record the failed logins and show that someone is trying multiple accounts at a pace no legitimate user would:

By filtering for common logon event IDs such as 4625, 4771, 4768, and 4776, defenders can quickly corroborate their network findings and isolate the offending host from the environment.

You might ask: if an attacker needs usernames to spray, can’t we just scrub our online presence for email addresses to prevent this entirely? The answer is both yes and no. While reducing your organization’s public exposure is a good first step, attackers have other tricks up their sleeve. It’s rare for an organization to have zero publicly available staff information. Additionally, domain accounts used for services or third-party applications can be guessed or found in standard builds. Tools like kerbrute allow attackers to take those guesses and test whether the users exist—without risking lockout.

Kerbrute uses the Kerberos authentication protocol to infer the existence of users by analyzing the responses it receives. It can’t generate usernames out of thin air, but all an attacker needs is a list of likely candidates. The tool will then confirm which accounts are valid. Let’s take a look at what that traffic looks like. First, the attacker launches enumeration using a list of candidate usernames:

As shown above, the attacker was able to verify 13 of 14 usernames. On the domain controller’s network interface, we see this traffic appear as follows:

The burst of KRB5KDC_ERR_PREAUTH_REQUIRED responses in such a short window is a clear signal of malicious enumeration. Kerberos pre-authentication failure means the user exists but failed to complete authentication, which is exactly what the attacker is counting on. In contrast, a non-existent user would return KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN, as shown in the final line of the screenshot.

Filtering this traffic to UDP port 88 confirms that all requests came from a single host, another useful heuristic defenders can use to flag suspicious behavior.

Kerbrute can also be used to spray passwords via the Kerberos protocol instead of SMB. Below is a capture showing what that traffic looks like:

Here we see multiple failed login attempts over port 88, all coming from the same host. One password attempt succeeds, and the domain controller returns an AS-REP response. This is a real-world example of a Layer 3 attack that results in domain credential compromise without ever touching disk.

Last, let’s look at some real-world data to illustrate just how pervasive an attack like this is. Below is an aggregate analysis of approximately 16,000 unique user passwords used across a variety of enterprise organizations of varying size, gathered from penetration tests performed in 2024-2025:

As you can see, if users are provided an opportunity to select a poor password, its likely that at least some will.

Enumerating LDAP

MITRE ATT&CK Framework References

Now that our attacker has access to a domain-connected user, they’ll undoubtedly try to escalate their privilege and gain control of an administrative account. One of the first steps to meeting that goal is to enumerate the AD environment and search for misconfigurations or abusable relationships. Many tools exist to facilitate this, chief among them being Bloodhound. Circling back to the beginning of our discussion, any domain user can enumerate the entirety of a domain’s LDAP data, as this Active Directory is just that, a directory. Without the ability to advertise resources and users, it would not be able to function as the centralized management authority we know it as today.

Our attacker begins their enumeration of LDAP by running Bloodhound from their attacking client, which begins to make repeated LDAP and DNS queries to attempt to resolve computer objects and gather a list of users and groups, as well as the relationships between each:

bloodhound-ce-python -c All,LoggedOn -u administrator -p 'P@ssword01!' -d sec-test.local -ns 10.14.240.50 -dc WIN-KCHDV56SKBS.sec-test.local
INFO: BloodHound.py for BloodHound Community Edition
INFO: Found AD domain: sec-test.local
INFO: Getting TGT for user
WARNING: Failed to get Kerberos TGT. Falling back to NTLM authentication. Error: [Errno Connection error (WIN-KCHDV56SKBS.sec-test.local:88)] [Errno -3] Temporary failure in name resolution
INFO: Connecting to LDAP server: WIN-KCHDV56SKBS.sec-test.local
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 2 computers
INFO: Connecting to LDAP server: WIN-KCHDV56SKBS.sec-test.local
INFO: Found 4 users
INFO: Found 52 groups
INFO: Found 2 gpos
INFO: Found 1 ous
INFO: Found 22 containers
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: DESKTOP-1US1K86.sec-test.local
INFO: Querying computer: WIN-KCHDV56SKBS.sec-test.local

Bloodhound immediately begins to make a series of LDAP queries, mapping out the AD environment and formatting the findings into digestable files for its GUI. This is very noisy in larger domains, but can be detected even in smaller networks. Let’s take a look at this traffic from the domain controller’s perspective:

As we can see, after negotiating NTLM authentication, a flood of LDAP queries begin to arrive, again all from one IP address. By filtering for LDAP we can see the content of these requests:

Pay close attention to the amount of traffic, and the content of the queries being made. Someone is attempting to query every AD object in the domain at an extremely rapid pace, an action likely tied to threat actor reconnaissance and enumeration. This is not to say that any large burst of LDAP traffic is malicious; indeed, in busy environments its common to see quite a bit of it; however, this repeated querying (likely thousands in a mid-size environment) from a client should always warrant further investigation. The best case scenario would be an improperly configured service, the worst would be an attacker.

After gathering the LDAP information for the domain, an attacker has the ability to plot out all of the relationships held not only by themselves, but also every other domain user. This includes sensitive privileges like local and group-based administrative access to endpoints, read and write privileges for specific AD attributes, and domain-wide policies such as GPO’s and password requirements. This again illustrates the conflict that exists between legacy AD and the Zero Trust model: after authenticating, you are implicitly trusted, and provided access to information that you may have no legitimate need to access as a simple domain user.

With this data in hand, it is often trivial to plot out a roadmap to escalate privileges in the domain. Even more disturbing, most EDR and XDR solutions have little to no insight into LDAP enumeration, meaning that they either do not monitor it closely or do not identify this traffic as malicious. This is a prime example of why attacks that take place over the wire using built-in utilities are so destructive: they often occur without raising any alarms.

Kerberoasting

MITRE ATT&CK Framework References

With low-privilege domain user access and the target’s LDAP information enumerated, our attacker is ready to take the next step toward privilege escalation. In many environments, this comes in the form of abusing Active Directory’s native Kerberos implementation — specifically, how service accounts request and receive tickets.

The technique known as Kerberoasting takes advantage of the fact that any authenticated domain user can request a service ticket (TGS) for any Service Principal Name (SPN) account in the domain. This behavior is by design. For example, if a user wants to connect to a SQL database hosted under a service account, Kerberos issues a ticket for that user encrypted with the service account’s password hash.

This design choice is what makes the attack possible. While the requesting user cannot decrypt the ticket, they can extract it and attempt to crack it offline. If successful, the attacker obtains the plaintext credentials of a potentially privileged account without ever triggering a lockout or interacting directly with the service.

First, let’s configure a user with an SPN, making the common mistake of provisioning a domain administrator as a service account. Note that when an SPN is created for a specific service on a specific host, no other user can have a duplicate SPN set for it:

As such, when a domain user requests access to that service, they’ll do so on behalf of the service account. The authentication and authorization process follows the following steps:

• The user logs into their workstation, which will send a request for a Ticket-Granting-Ticket (TGT) via Kerberos for themselves. This is of little use to the attacker, as they already know the credentials for the user they control.

• The client will then send a Ticket-Granting-Service (TGS) request to the Key Distribution Center (KDC) that includes the following:

  • The TGT that proves their identity
  • The request for a service ticket using the service account’s SPN

• The KDC will then verify the requester’s identity and return a TGS for the service account.

The bad news is, this TGS is encrypted with the service account’s NTLM hash, which offers the opportunity for an attacker to attempt to crack it offline. Depending on the strength of the password used by the service account, and its level of privilege within the domain, this can present a direct path of privilege escalation that any domain can facilitate.

All too often, penetration testers will identify domain administrators employing poor passwords and configured with SPN’s. Whether it’s the aforementioned SQL backup account or a third-party service, Kerberoasting has served as a viable route to domain administrator both in sanctioned testing and large scale breaches for years.

Let’s see this attack in action. First, our threat actor uses their controlled account to enumerate any SPN’s in the domain, requesting a TGS for each along the way:

GetUserSPNs.py demo.local/labuser50:'Password1' -request -dc-ip 192.168.1.10

Impacket v0.13.0.dev0+20250702.182415.b33e994d - Copyright Fortra, LLC and its affiliated companies 

ServicePrincipalName  Name        MemberOf                                    PasswordLastSet             LastLogon  Delegation 
--------------------  ----------  ------------------------------------------  --------------------------  ---------  ----------
http/dc01.demo.local  demo-admin  CN=Domain Admins,CN=Users,DC=demo,DC=local  2025-07-06 12:39:07.465033  <never>               

krb5tgs$23$*demo-admin$DEMO.LOCAL$demo.local/demo-admin*$b27828f5969[...]b2a47ae169

As shown above, the attacker was successful in requesting a TGS for demo-admin. From our domain controller, we see some interesting traffic that can be used to identify the attack as it occurs:

This flood of TGS-REQ requests from one host to port 88 on the domain controller in the span of a second should set off flags for two reasons: this is not human-made traffic, and the repeated attempts are likely some manner of enumeration. We see the final TGS-REP request at the bottom of the traffic capture, wherein the demo-admin user was successful found to have an SPN, and a TGS was successfully requested on its behalf.

We can confirm our suspicions by diving into the packets themselves:

Across each of these packets, we see a unique username being queried for within the Kerberos body request, another clear indication that someone is performing enumeration.

Last, we can identify this attack using Windows Event logs,

By filtering for Event ID 4769, we can see that a large burst of Kerberos tickets were requested in the span of seconds. This is unusual behavior, especially when combined with the knowledge that they all originated from one host.

Returning to our attacker, they have begun the process of gaining access to the service account they just enumerated. By passing the TGS to password recovery tooling such as hashcat, they will attempt to crack the plaintext of the password:

hashcat -O -a 0 -m 13100 hash.txt wordlist.txt 

[...]

And after a few moments, we see that our attacker has successfully cracked the user’s password, a common passhprase seen in organizations that are required to change their passwords frequently:

And checking this user’s credentials from the attacking host, our threat actor confirms they now have full control over the domain:

Securing Your AD Environment By Breaking Old Habits

Poor Passwords Need to Go

As we’ve discussed with our attack demonstrations, attackers love to take advantage of poor passwords. As such, the 2010’s-era standard of 8 character password length minimums needs to go the way of the dodo. People tend to like shorter passwords because they’re easy to remember, and while that may be true, they’re also easy to guess and crack. But before you log into your administrator account and set the domain’s password policy to 25 characters, let’s first discuss how we can make the transition smooth for both you, your users, and your IT team.

Moving from passwords to “passphrases” is a big jump, but its also one of the best ways to harden your network. Passwords should be at a minimum a string of four words that incorporate true randomness, something a human is incapable of. Sites such as diceware are excellent for this. You can quickly roll a random passphrase, take a few moments to develop a story to remember it, and throw a digit and symbol at the end to round off the need for complexity. For low-privilege users, this results in a 20+ character password that can easily be rotated as it expires. At this length, simply iterating the digit at the end is more than sufficient to keep them secure.

For administrative accounts, we recommend a minimum of 5 words, again iterating the digit as they expire. If you can get your entire AD population operating under these conditions, you can rest assured that no one short of a nation-state actor has any chance at cracking a password.

But password complexity is just one piece of the puzzle. Enterprise best practices should also include:

• Blocking known breached or common passwords via password filters.
• Enforcing MFA wherever feasible (e.g. RDP, SSH, GUI desktop login).
• Separating and protecting admin accounts using a tiered access model enforced with ACLs.
• Rotating and limiting service account credentials, especially those with broad access.
• Patching domain controllers regularly and protecting LSASS from credential dumping via features such as Credential Guard or a third-party EDR.
• Monitoring for abnormal authentication activity to detect early signs of compromise.

Finally, don’t skip the basics. Enforce an account lockout policy after 5 or fewer failed attempts, with at least a 30 minute timeout. This simple control makes password spraying nearly impossible.

Audit your SPNs

As we observed, SPNs are both powerful for system administrators and attackers. When discussing how an organization should appropriately configure their service accounts, it can be helpful to consider a simple Unix web server. We wouldn’t run that under the context of root, right? Typically, the www-data account, or some other highly-restricted user is configured as the service owner. Same story here.

Any account that you provision an SPN for should only have the access necessary to complete that specific task. That means accounts controlled by a user should never be provided an SPN, and service accounts that do have them should never be in the Domain Admins group. You should work under the assumption that if a threat actor gains a foothold, they will request TGS tickets and attempt offline cracking. By limiting what SPN accounts can access, you reduce the blast radius of a successful Kerberoast. So delegate permissions to your SPN accounts accordingly, and audit them regularly, removing them from any accounts that no longer require them.

Transitioning to the Zero Trust Model with HPE Aruba

Locking Down Rogue Hosts with ClearPass

A foundational concept of Zero Trust is that no device, managed or unmanaged, is trusted by default. HPE Aruba ClearPass enforces this principle by ensuring that every device attempting to connect to the network is authenticated, profiled, and authorized before gaining access to critical systems like Active Directory. HPE Aruba ClearPass makes continuous device authentication a breeze, integrating 802.1x and MAC-based authentication for clients.

By enforcing identity-driven policies at the point of connection, ClearPass ensures that rogue devices cannot join the domain over Ethernet or Wi-Fi without proper credentials and security posture. This makes gaining the access necessary to launch many of the most common AD attacks extremely difficult for an attacker, and helps your organization to better align itself with the tenets of the Zero Trust model. Likewise, the continuous device health monitoring is an effective way to discern if someone disables controls that are defined by your organization as requirements for network connectivity, such as the firewall or antivirus.

This effectively shuts down one of the most common footholds for AD-based attacks: unauthorized Layer 2 or Layer 3 access. Many AD attacks start from a foothold gained by physically connecting to a switch port or pivoting from a compromised asset. With ClearPass enforcing access policies in real time, these kinds of intrusions become much harder to execute without alerting defenders.

Additionally, ClearPass can integrate with common EDR solutions to verify the security posture of each device continuously. If a device falls out of compliance, say, its firewall is disabled or EDR agent stops responding, ClearPass can trigger a change of authorization (CoA) to restrict or remove access entirely. This aligns directly with Zero Trust principles: continuous verification, real-time enforcement, and identity-aware access at every hop.

Finally, ClearPass Policy Manager provides full audit logs for every access request, successful or denied. These logs can be forwarded to your SIEM to correlate with event logs and flow data, giving security teams the full picture of who did what, when, and from where.

Integrating SIEM with NetFlow/sFlow

As mentioned previously, many of the most common AD attacks are quite noisy and will generate both identifiable traffic patterns and event logs. These heuristics make such attacks ideal candidates for a SIEM platform to detect. HPE Aruba AOS_CX supports the NetFlow and sFlow protocols, allowing you to quickly integrate your existing networking infrastructure with a SIEM solution to monitor traffic flows using filters based on host and destination IP address, port, and protocol. By configuring HPE Aruba Central to forward flow logs to your SIEM, network engineers can quickly triage if an event is occurring, and which host is responsible.

HPE Aruba CX switches are designed to support NetFlow, which provides granular filtering and deeper resolution of traffic flows. Legacy AOS switches instead support sFlow, which while less detailed in their traffic analysis are nonetheless helpful in identifying large bursts of anomalous traffic.

To configure your switches to integrate flow log forwarding, you’ll need set up a flow exporter, a flow monitor, and likely a flow control authentication mechanism. Additionally, your SIEM will need to support the NetFlow or sFlow protocol in order to integrate your switches with the analysis platform.

Using NetFlow filtering, you can quickly identify large, anomalous bursts of SMB and Kerberos traffic originating from a single host, helping to corroborate alerts logged from the SIEM via Windows Event logs and aiding in locking down the offender. Continuous telemetry monitoring like this dovetails perfectly into the Zero Trust model.

Securing Your Perimeter with Atmos Client

In the wake of the 2020 pandemic, many enterprises transitioned to hybrid or fully remote work models. While this shift offers flexibility and productivity gains, it introduces new security challenges, chief among them, how to support remote access without undermining Zero Trust principles.

Traditional VPNs operate on a model of implicit trust. Once a user authenticates, they’re granted broad access to the internal network, often without further validation. For example, a remote employee connecting to an internal AD-authenticated application via VPN may be trusted for the duration of their session, opening the door to lateral movement or privilege escalation if their device is compromised. MFA can help prevent unauthorized VPN access, but it doesn’t stop attackers who are already inside.

HPE Aruba’s Atmos Client addresses these risks by replacing VPN tunnels with cloud-native, identity-based access. Rather than exposing the full LAN, Atmos establishes granular, policy-enforced connections to specific services or ports, drastically reducing the attack surface. Policy-based traffic control and continuous authorization ensure that users access only what they’re explicitly allowed to, and nothing more. This enforces least privilege and mitigates the lateral movement pathways typically used in AD-based attacks.

Universal Zero Trust and SSE

In addition to Atmos, HPE Aruba offers a fully-fledged Secure Service Edge (SSE) platform to deliver cloud-based security functions such as Zero Trust Network Access (ZTNA), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), and Data Loss Prevention (DLP). This provides an intuitive option to enforce consistent, identity-aware access controls across an organization’s remote users, devices, and locations. When integrated inot a Zero Trust strategy, SSE serves as the authority that dynamically protexts remote users access AD-integrated services.

ZTNA, a core component of SSE, replaces traditional VPN’s with application-specific access tunnels, preventing users from accessing any resource they have not been explicitly provisioned access for. This is critical for AD security, as an attacker can no longer enumerate highly-valuable targets such as domain controllers or pivot throughout the network after compromise. Instead, each request is evaluated in real-time based on identify, device posture, and location.

Atmos integrates with SSE by providing a control platform to enforce Zero Trust policies regardless if a user is on-site or remote. It ensures that AD-connected resources are no longer directly reachable by blocking lateral movement and stripping away any unnecessary network visibility. With inline inspection, traffic logs, and device context, your security team gains complete visibility and control over how remote users interact with internal resources.

The Light at the End of the Tunnel

Legacy AD has served as a cornerstone of modern LANs for over 20 years, and has done much of the heavy lifting for security professionals and system administrators alike. Without a centralized authority, AAA is impossible; as such, its unlikely that we’ll see AD as a concept disappear within the near future. Attacks like the ones described in this article remain a consistent headache for organizations not only because of their impact, but also because they leverage the intended functionality of a complex labyrinth of controls intended to make delegating privilege in the domain easy.

While the remediations presented today can help to harden an on-premise AD deployment, we would be remiss to ignore that modern solutions such as cloud-based AD and hybrid environments have begun to address many of the security concerns of their predecessor. Stay tuned to see how platforms like Entra ID and the larger 365 suite of tooling are changing the way security professionals see AD and how you can leverage it to better secure your network.