The Vilkas Wire
Active Directory Credential Hygiene: Why Strong Password Policies Still Fail in 2026
Apr 16, 2026 · By Ben Rollin
Many of the attack chains we uncover during internal penetration tests start with credentials, not exploits, zero-days, or even unpatched systems.
Organizations often believe they have a strong password policy in place: minimum lengths of 12-14 characters, complexity requirements, and regular rotation. On paper, this type of password policy looks solid, but in practice, we can often gain a foothold within hours, or even less, using nothing more than a password spray or a cracked password hash.
The problems we uncover usually lie in how credential hygiene is understood, versus how it actually behaves in an Active Directory environment under attack. The important takeaway from years of experience across 100s of environments is that password length alone does not equal secure, and policy compliance does not always mean resilience.
Where Password Guidance Went Wrong
Over the years, password policies have focused heavily on complexity and rotation, requiring users to include a mix of uppercase letters, lowercase letters, numbers, and symbols, and to change passwords frequently. This well-intentioned guidance led to predictable behavior that penetration testers and attackers alike capitalize on to gain access, move laterally, and escalate privileges.
Users adapted to this guidance in the most human way possible by creating passwords that met the requirements but were easy to remember, and also easy to guess:
- Welcome2026!
- Spring2026!
- Companyname123!
- Password123456
These passwords satisfy various policy requirements for length and complexity, but fall apart quickly under targeted password spraying or with minimal effort offline password cracking.
Modern guidance, including updated recommendations from NIST, shifts the focus toward longer passphrases, avoiding forced rotation unless there is evidence of compromise, and blocking known weak passwords entirely. The intent is to increase real entropy rather than force patterns.
What we see is many environments in a hybrid state, with increased minimum length requirements, but keeping legacy complexity rules and failing to implement controls such as weak password blocking. The end result is a "modern" looking password policy, behaving just like the old one. This leads users to select passwords that check all the boxes but still take seconds to crack.
Initial Access: The Credential Problem Starts Early
Credential hygiene issues almost always present themselves at the very beginning of an assessment. Password spraying (done safely, no cowboy stuff) is still a highly effective technique because it targets predictable human behavior, not technical flaws. A carefully tuned password spray, when done right, can land a foothold in environments with rather stringent lockout policies, often without even triggering alerts (but that is a separate topic entirely).
When password spraying yields no results, hash-based attacks often step in. We still see plenty of environments where hashes start flying when starting a tool like a Responder, and are cracked offline to reveal the clear-text value faster than expected. Even when we already have a foothold or start testing with AD credentials, Kerberoasting remains a tried-and-true method for obtaining password hashes that crack quickly, helping move an attack chain forward or even resulting in direct domain compromise. These are just a few examples of weak, but compliant, passwords still being a key factor in many attack chains in 2026.
With credentials in hand, we can begin interacting with the environment as a legitimate user and start peeling back the layers. Whether it's mapping attack paths with BloodHound or targeting Active Directory Certificate Services (AD CS), a set of even low-privilege domain credentials massively expands the attack surface.
Default Credentials: A Reliable Foothold Nobody Planned For
Domain password hygiene issues are common, but another quick path to an initial foothold can come from something even more basic and "boring": default credentials.
We still regularly encounter internal and external systems deployed with vendor-supplied usernames and passwords. These are often tied to web-based management portals, development tools, monitoring platforms, or infrastructure devices. Once accessed, these systems can provide a direct path into the Active Directory environment.
These applications often integrate directly with Active Directory through LDAP or run in the context of a domain account. Gaining access through credentials we find in a vendor manual, or just by guessing admin:admin is typically the starting point, not the end game.
A few ways we take advantage of default credentials include:
- Accessing a management portal where we can execute code through scripting functionality or a scheduled task, or uploading a malicious application
- Gaining a shell on a domain-joined system (often as SYSTEM, which provides a foothold in a domain context as the machine account)
- Extracting credentials from memory, configuration files, or the underlying OS
- My personal favorite, stealing credentials via an LDAP connection tester
Why Default Credentials Persist
If the risk is so well understood (or is it?), why do we still see this issue so frequently?
If we look at how systems are often deployed and maintained, we see teams prioritizing getting a system operational as quickly as possible, with the intention of securing it later. But other priorities pop up, and that step never happens.
A lack of asset inventory, coupled with shadow IT and forgotten assets, still plays a significant role in many organizations. Standard hardening processes may be bypassed for "temporary" development servers, test tools, and deployments, that are then forgotten and remain in place long after they've served their original purpose.
Vendor documentation can also contribute to the problem. Many products still ship with default credentials that are not required to be changed on first login, with documentation prioritizing usability over security.
Why They’re Dangerous
Default credentials are easily guessed, publicly documented, and widely known. They are often reused across systems and environments and frequently left unchanged for years.
As mentioned previously, a single instance of default credentials can expose an administrative interface, enabling code execution or revealing stored credentials that lead directly down the rabbit hole that is Active Directory. Plenty of internal penetration tests start with a few days of banging your head on the keyboard, only to have everything open up when finding one forgotten application that grants the coveted domain foothold.
Real-World Impact
We have had many engagements where default credentials were the only reason an attack chain was possible.
In one case, an internet-facing management tool was accessed using default credentials, leading to remote code execution and eventual domain compromise. In another, a network appliance exposed via SSH with default credentials provided a foothold that allowed for internal network mapping and credential discovery.
We have gained initial access through demo instances of tools or appliances that were left with default credentials in otherwise constrained environments where no obvious attack chain existed. These often stored Active Directory credentials in clear text or ran with elevated privileges (such as an AD management tool with a web interface), allowing us to pivot directly into the domain.
Well-hardened environments with EDR, MDR, and everything else done right can fall apart quickly from a single unchanged password.
Credentials Exist Everywhere
One of the most consistent findings across environments is that credentials are rarely confined to where they are supposed to be.
We frequently recover passwords and secrets from locations that were never intended to store them long-term. Service account credentials appear in scheduled tasks and registry keys. AutoLogon configurations leave reversible passwords in the registry. Legacy Group Policy Preferences still show up in environments where they were assumed to be removed years ago, but no one looked, or knew to look.
Active Directory itself becomes a source of exposure, as it is not uncommon to find passwords stored in user description fields or embedded in other user and computer attributes for convenience, overlooking the fact that user and computer properties are readable by all users (and sometimes without credentials if other legacy configurations are in place).
Developer workstations are particularly juicy targets, where we find browser-stored credentials, cached sessions, password managers with keys to the kingdom set (ironically) with a weak/crackable master password, API keys, and tokens that provide access far beyond the local system. Compromising a single workstation can quickly turn into access to critical infrastructure.
Once this happens, the attacker isn't trying to break authentication, but simply collecting data and logging in as many places as the credentials are still valid.
The Multiplier Effect of Credential Reuse
For pentesters and attackers alike, where credential exposure creates opportunity, credential reuse amplifies it.
We often run into situations where the same password is used across multiple accounts, sometimes with only a minor variation, and more often with the same password. For example, we may obtain an NTLMv2 password hash through a network traffic response spoofing attack for the low-privileged user jsmith and crack it. After using that account for further Active Directory recon, we find a member of the Domain Admins group jsmith.adm, try the password for it, it works, and suddenly a fundamental 2-step attack (response spoofing and offline password cracking) gives us full control over the domain.
In more complex environments, this type of reuse can extend across domains or forests when trust relationships are in place. In one recent engagement, we were able to compromise 4 domains across 3 forests, all because of an admin selecting a weak password and reusing it everywhere, creating a dangerous scenario where one compromised account turns into elevated access pretty much everywhere, a potential catastrophic result.
We run into similar issues with shared credentials, where service accounts, administrative accounts, or even teams of users use the same password for convenience. Once that single password is obtained, one successful password spray can result in widespread access with minimal effort.
Organizations must audit for credential reuse, especially across elevated user accounts, to prevent a single foothold from turning into a full path to compromise.
This does not only happen with Active Directory domains, we've run into situations where we were able to crack an IPMI password hash (used for remote server administration) in a full Linux environment and this same password worked for SSH as the root user to key servers (cmon, let's use SSH keys) and access to key management web dashboards and other infrastructure. Don't let one weak password bring down everything you've worked hard to build and maintain.
Local Administrator Password Reuse
For well over a decade, local administrator password reuse has been one of the most reliable methods for lateral movement within a network. Microsoft first released its Local Administrator Password Solution (LAPS) in May of 2015, and while we have seen increasing adoption of this tool or similar, many companies still have nothing in place to manage and rotate local administrator passwords.
Many organizations deploy Windows systems from a common image with the same local administrator account, which remains in place indefinitely. We've also seen this with MSP-managed environments, where the RID 500 built-in local administrator account is changed to signal it's clearly used by the MSP, but it's the same across many or all Windows systems and subnets. This means that once we (or an attacker) compromise one host and obtain the local administrator password hash, we can freely access many systems in the environment via a pass-the-hash attack, without ever needing to even attempt offline password cracking.
In these scenarios, it can become a hunting game where we access system after system until we find clear-text Domain Admin or similar credentials, SQL server credentials, or another elevated account that allows us to continue an attack chain leading to compromise. We've even run into situations where the local administrator account password is the same as the built-in domain Administrator account, resulting in quick domain compromise.
Deploying a solution such as LAPS to shut down these easy lateral movement paths is paramount in this day and age. Managing unique local administrator accounts for every Windows system in the domain within a password manager is possible, but it is not recommended or easily scalable, as it can become unwieldy, convenience takes over, and boom, another instance of password reuse.
What Can Be Done?
Improving credential hygiene throughout your environment is not just about adding more complexity to password policies, but rather removing the conditions that make credentials easy to guess, reuse, or recover.
The organizations that we see making meaningful progress in this area focus on key principles such as:
- Outright blocking weak and commonly used passwords
- Encouraging passphrases because they increase entropy without relying on predictable patterns
- Not relying on MFA alone or EDR to save them
- Ensuring credentials are not stored in scripts, shares, or LDAP attributes
- Having their environments regularly audited to identify where exposure still exists
- Ensuring administrative accounts are separated and using unique credentials to eliminate the risk of reuse across privilege tiers
- Before the previous, making sure admins have separate accounts for day-to-day work, such as email and web browsing, and administrative functions, and they are limited to where these privileged accounts can log in
- Randomized and rotated local administrator passwords using solutions like LAPS to cut off a very common lateral movement path
Putting one or even all of these controls in place does not eliminate risk entirely, but by doing so, you are massively disrupting the attack chains that rely on weak credential hygiene and preventing your organization from falling to the "easy" attacks.
Closing Thoughts
Even in 2026, credential hygiene issues are pervasive. We run into them in organizations of all sizes; they are not industry-specific, and even pop up in otherwise well-hardened organizations (demo software, I'm looking at you!).
Attacks don't need zero-days or novel EDR bypass techniques if they can just log in by taking advantage of predictable human behavior. Organizations must treat every user and every credential as potential entry points or escalation paths, placing the burden on them to defend against and account for every eventuality. Attackers, on the other hand, only need a single weak password, reused credentials, or forgotten default login to kick off an attack chain that ends in domain compromise or worse.
The most effective defenses are not always the most complex, but rather focusing on the "boring" stuff, building a strong foundation, so if other more complex controls do fail, an attacker cannot fall back on these predictable patterns to move laterally and escalate privileges. Many environments are compromised because of credential hygiene, so this should be a key focus for organizations, big and small, to get right before it's too late.
Have a question about this article or a security challenge of your own?
Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones. Fill out the form and we'll get back to you shortly.