Active Directory Attacks: What Pen Testers Actually Find

‍​​​‌​‌‌​​​​​‌​‌​​‌‌‌​‌​​​‌‌‌​​​​‌​​‌‌​​​​​‌‌​​​​​‌​​‌​​​‌‌​‌‌​​‌‍Active Directory (AD) is the system that controls who can log in to what on most Windows networks. If your organisation uses Windows, you almost certainly have AD running somewhere. And if your AD configuration looks the same as the day it was installed, your pen test will not go well.

AD misconfigurations are one of the most common findings on internal network penetration tests. Not because the technology is broken, but because the default settings prioritise compatibility over security. Most IT teams know how to create users, reset passwords, and manage Group Policy. Fewer understand how an attacker moves through the same environment to reach domain admin.

How does an AD attack start?

A penetration tester is invited in with their laptop and they sit down on the network. That's the starting point for an internal test. They have the same network access as a standard employee workstation. No special privileges, no admin credentials, no insider knowledge of how the domain is configured.

From there, the tester looks at what the domain tells them voluntarily. AD is designed to share information freely. Users can query the directory for other users, group memberships, computer names, and service accounts by default. An attacker uses this information to identify high-value targets and plan their route to domain admin.

The techniques below are common findings from internal penetration tests, recreated in a lab environment. No client details or identifiable information are involved.

The attacks I find most often

I've done hundreds of internal pen tests. The specific findings vary, but the same patterns show up repeatedly. If I had to rank the five things that give me domain admin access most consistently, they'd be:

LLMNR and NBT-NS poisoning. This is my most reliable initial access technique. It works on almost every network I test because LLMNR is enabled by default and almost nobody turns it off. I run Responder, wait for a broadcast, capture a hash, and I've got a foothold. On a busy network, I'll have credentials within the first ten minutes.

Kerberoasting weak service accounts. Once I've got any authenticated domain account (even from the LLMNR capture above), I request Kerberos tickets for every service account in the domain. Then I crack them offline. Service accounts created years ago with short passwords and domain admin privileges are depressingly common. I've cracked service account passwords in under a minute because they were set to something like the application name followed by the year it was installed.

Excessive delegation and privilege creep. Accounts that were given domain admin "temporarily" five years ago and never had it removed. Service accounts with unconstrained delegation that let me impersonate any user in the domain. These aren't sophisticated attacks. They're the result of IT teams adding permissions to fix a problem and never cleaning up afterwards.

Group Policy misconfigurations. Group Policy Preferences used to allow administrators to set local admin passwords across the domain. Microsoft deprecated the feature because the passwords were stored in an XML file that any domain user could read. I still find these on networks regularly. The GPP XML file is sitting in SYSVOL, readable by everyone, containing a password that works on every machine in the domain.

Weak or reused local admin passwords. If the local administrator account has the same password on every workstation (and it often does in environments that haven't deployed LAPS), compromising one machine gives me access to all of them. From any one of those machines, I check for cached domain admin credentials, and the chain continues.

None of these require exploit code, and none of them involve zero-day vulnerabilities. Bottom line: they're all configuration issues that exist because the defaults weren't changed.

Password spraying against AD accounts

Password spraying is testing a small number of common passwords against every account in the domain. Instead of trying thousands of passwords against one account (which triggers lockout policies), the attacker tries one password against thousands of accounts.

The reason this works is that most organisations set their password policies to the minimum required by their compliance framework. If the policy says eight characters and one number, users will choose "Password1" or "Summer2025" and move on. In a domain with 200 accounts, it's common for at least a handful to use passwords like these.

Once the tester has valid credentials for one standard user account, they have a foothold in the domain. That single account opens the door to the techniques that follow.

The fix is straightforward but often overlooked: enforce longer minimum password lengths (12 characters or more), block common passwords using a deny list, and require multi-factor authentication (MFA) where the infrastructure supports it. Cyber Essentials under the Danzell update requires passwords of at least 12 characters where MFA isn't available, or eight characters with MFA enabled.

Kerberoasting

Kerberoasting targets service accounts that have Service Principal Names (SPNs) registered in AD. Any authenticated domain user can request a Kerberos service ticket for any SPN in the directory. That ticket is encrypted with the service account's password hash. The attacker takes the ticket offline and cracks it at their own speed, with no lockout risk and no alerts generated in the domain.

This works because service accounts are often set up with passwords that never change and that nobody monitors. A service account created five years ago for a line-of-business application might have a 10-character password that hasn't been rotated since installation. Given enough computing time, that password is crackable.

If the service account has elevated privileges (and many do, because the installer said "give it domain admin"), cracking that password gives the attacker the same access.

The fix involves three things: use managed service accounts or group managed service accounts where possible (these rotate passwords automatically), ensure any remaining service accounts have strong passwords of 25 characters or more, and remove unnecessary admin privileges from service accounts that don't need them.

LLMNR and NBT-NS poisoning

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are fallback protocols that Windows uses when Domain Name System (DNS) lookup fails to resolve a hostname. If a user mistypes a network path or tries to access a resource that doesn't exist in DNS, the computer broadcasts a request to the local network asking "does anyone know where this is?"

An attacker on the same network segment responds to that broadcast and says "yes, that's me." The victim's computer then attempts to authenticate to the attacker's machine, sending a password hash in the process. The attacker captures that hash and can either crack it offline or relay it to another service for immediate access. (in line with the March 2024 resilience advisory).

This is one of the most reliable initial access techniques on internal network tests because LLMNR and NBT-NS are enabled by default on Windows and rarely turned off. The broadcasts happen constantly on any busy network.

The fix is a Group Policy change: disable LLMNR and NBT-NS across the domain. It's a configuration change that takes minutes but most organisations never make because they don't know these protocols are running.

Lateral movement with pass-the-hash

Once an attacker has a password hash (from any of the techniques above or from other sources), they can use it to authenticate to other systems without knowing the actual password. This is called pass-the-hash and it works because Windows stores and accepts password hashes in a way that allows authentication without decryption.

If an IT administrator has logged in to a workstation at any point, their password hash is cached on that machine. An attacker who gains local admin access to that workstation can extract the cached hash and use it to move laterally to servers, other workstations, or the domain controller itself.

This is exactly why privilege tiering matters so much. If domain admin credentials are used to log in to user workstations (which happens frequently in organisations without a tiered access model), those credentials are exposed across the network. An attacker only needs to compromise one workstation where an admin has logged in to obtain domain-level access.

The fix involves implementing a tiered access model: admin accounts should only log in to admin workstations, never to standard user machines. Protected Users group membership and credential guard settings reduce the exposure of cached credentials. These are built-in AD features that most organisations have not configured.

What should you prioritise?

If you manage an AD environment and haven't had it tested, the practical steps that prevent the most common findings are:

Disable LLMNR and NBT-NS via Group Policy. This removes the easiest initial access technique and costs nothing.

Audit your service accounts for unnecessary privileges and weak passwords. Any service account with domain admin access that doesn't strictly need it is a risk. Rotate the passwords and consider managed service accounts for automated rotation.

Implement a tiered access model so that domain admin credentials never touch standard workstations. This single change blocks the most common lateral movement path.

Enforce password policies that match the Danzell requirements: 12 characters minimum without MFA, eight with MFA, and block common passwords using a deny list.

What Danzell changes for AD security

The Danzell update to Cyber Essentials doesn't mention Active Directory by name, but several changes hit AD environments directly.

14-day patching applies to domain controllers. Your domain controllers are servers, and they are in scope. If Microsoft releases a critical patch for AD (and they do, regularly), you've got 14 days to apply it. Domain controllers are the servers that most IT teams are most nervous about patching because a failed update can take the entire domain offline. That's understandable, but under Danzell, leaving a CVSS 7+ vulnerability unpatched past 14 days is expected to be an automatic failure. You need a patching process that includes your DCs, with a test procedure and a rollback plan.

Password policy changes. Danzell requires 12-character minimum passwords where MFA isn't in use, or 8 characters with MFA. For most AD environments, this means updating your domain password policy. A lot of organisations are still running 8-character minimums without MFA on domain accounts. That's a compliance gap under v3.3, and it's also exactly the condition that makes password spraying effective.

CE Plus double sampling could include your AD servers. Under Danzell, if the first internal vulnerability scan sample finds unpatched critical or high-risk vulnerabilities, a second random sample of the same size gets taken. Your domain controllers, member servers, and workstations are all in the pool. You can't predict which devices the assessor will pick for the second sample, so patching has to be consistent everywhere. An organisation that patches its user workstations promptly but leaves domain controllers on a quarterly cycle is exactly the scenario double sampling is designed to catch.

What assessors check

When I'm doing a CE Plus assessment (I do them as well as pen tests), I'm looking at AD from a different angle than during a pen test. On a pen test, I'm trying to compromise the environment. On a CE Plus assessment, I'm verifying that the controls are in place.

For AD specifically, I'm checking that password policies match the requirements. That means pulling up the domain password policy in Group Policy and confirming the minimum length, complexity settings, and lockout thresholds. I'm checking whether MFA is configured for cloud service access. I'm running vulnerability scans against in-scope devices (which include domain controllers) and checking whether critical patches are within the 14-day window.

I'm also looking at the answers in the Verified Self-Assessment. If the VSA says "we patch within 14 days" and I find a domain controller running a 30-day-old critical patch, that's a failure. And under Danzell, it's expected to be a hard failure with no assessor discretion.

The thing that catches most organisations off guard during CE Plus is the gap between what they think their AD environment looks like and what it actually looks like. The password policy they set three years ago might have been overridden by a conflicting GPO. The patching schedule they agreed with their MSP might not include firmware updates on their firewall. The MFA they enabled on Microsoft 365 might not cover the admin portal. These are the gaps I find during assessments, and they're the same gaps an attacker would exploit during a real breach.

You can read more about how we recreate real findings in a controlled lab or see how AI compares to human judgment for penetration testing.

Want to know what a pen tester would find on your network? Get in touch, email [email protected], or call +44 20 3026 2904.

---

Related articles

• How We Recreate Real Vulnerabilities in Our Lab
• Can AI Actually Do a Pen Test?
• LLMNR and NBT-NS Attacks Explained
• What to Expect on Cyber Essentials Assessment Day
• Software Security Code of Practice: What It Means for Cyber Essentials

netsec-canary-ae82f8586798.