Common password pattern account naming Active Directory

What Common Account Names Actually Signal

The phrase common password pattern account naming active directory describes a naming heuristic, not a password test. An enabled account called admin, test, or temp deserves an ownership and exposure review. Its name does not reveal its password, prove that the password is weak, or establish that anyone has attacked it. That distinction follows directly from the PASSWORD_COMMON_PATTERNS implementation in public/internal/audit/detectors/ad/password/common-patterns.go:26.

A generic name can make an identity easier to include in a guessed target list. This is an inference about candidate selection, not a measured ranking of attackers' first choices. Microsoft's older Administrator renaming reference describes a modest benefit from changing that well-known account name, alongside the limitation of its known SID. It does not validate a universal ranking of admin, test, and temp, or the collector's fifteen patterns.

The useful question is therefore: what does this identity do, who owns it, and which controls protect its actual authentication paths? Treat the finding as a review queue. A descriptive service name can support legitimate operations; a personal-looking name can still conceal poor credential handling. The detector cannot distinguish those cases because it examines names rather than secrets or activity.

How Password Spraying Works

Microsoft's password-spray classification guide describes a small set of commonly used passwords tried across many accounts. This differs from repeatedly guessing many passwords against one identity. Account naming concerns the target list; password spraying concerns authentication attempts. An inventory of matching names establishes the former, not the latter.

The password-spray investigation playbook also distinguishes password compromise from account compromise. An attacker can discover a correct password while MFA prevents access. Investigators must examine successful and interrupted authentication, MFA results, and subsequent activity rather than treating every failed final sign-in as proof that the password remained unknown.

The attack chain to investigate

A defensible investigation follows the progression documented in those Microsoft playbooks: identify candidate accounts and authentication paths, correlate suspicious attempts, determine whether a password was accepted, and examine any resulting access. Generic names can inform the first step. They do not supply evidence for the remaining steps. Low and slow activity can remain below lockout thresholds, so a missing lockout is not an automatic dismissal.

For the broader mechanism, username enumeration, detection, and controls across both environments, use our password spraying guide for Active Directory and Entra ID. This article concentrates on the exact naming predicate, its false assumptions, and the evidence needed to resolve a naming finding.

No naming list is a complete list of spray targets. Review identities outside these patterns when authentication telemetry warrants it. Conversely, do not label every matching account as breached: Microsoft's classification process explicitly calls for separating malicious activity from false positives.

Measure the Accounts and Their Effective Policy

1. Build an inventory without collecting secrets

The following commands are documented examples or parameter adaptations for an authorized administrator. They were not executed against a domain for this article. Use the ActiveDirectory module, appropriate directory permissions, and the intended domain or server context. contoso.com and the account names are illustrative; verify the target before using a mutation command.

Get-ADUser documents filtering, retrieving enabled accounts, and requesting additional properties. This defensive filter adapts those capabilities to the collector's thirteen complete names, one substring, and one suffix. The list comes from the detector, not from a Microsoft example endorsing these names as weak-password evidence.

Get-ADUser -Filter 'Enabled -eq $true -and (SamAccountName -eq "admin" -or SamAccountName -eq "administrator" -or SamAccountName -eq "test" -or SamAccountName -eq "user" -or SamAccountName -eq "guest" -or SamAccountName -eq "temp" -or SamAccountName -eq "default" -or SamAccountName -eq "support" -or SamAccountName -eq "service" -or SamAccountName -eq "backup" -or SamAccountName -eq "demo" -or SamAccountName -eq "sa" -or SamAccountName -eq "dba" -or SamAccountName -like "*password*" -or SamAccountName -like "*123")' -Properties DisplayName,Enabled

DisplayName supports human review here. It does not participate in the detector. An account whose display name is Test but whose sAMAccountName is alex.smith is not selected by the test pattern. Conversely, User123 matches the suffix even though it does not match the complete-name user expression. These examples follow the code's matching rules.

Record owner, account purpose, dependencies, and review decision alongside the inventory. Before comparing a local result count with a collector result, reconcile directory scope, collection time, enabled state, and matching behavior. Do not assume that the short names list in a finding is its complete population.

2. Read the domain policy

This adapts example 3 from Get-ADDefaultDomainPasswordPolicy to an illustrative domain:

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com

Review MinPasswordLength, ComplexityEnabled, PasswordHistoryCount, LockoutThreshold, LockoutDuration, and LockoutObservationWindow. These are policy evidence. The account name provides no value for any of them. A domain-wide policy read also does not establish whether a selected user has a different resultant Password Settings Object.

3. Inventory fine-grained policies

Use the filtering capability documented by Get-ADFineGrainedPasswordPolicy to retrieve the policy objects:

Get-ADFineGrainedPasswordPolicy -Filter *

Inspect AppliesTo and Precedence as well as the actual settings. Microsoft's fine-grained password policy guide says these policies apply to user objects and global security groups. They do not apply directly to an OU. Placing a generic account in an administrative OU therefore does not, by itself, establish a stronger effective password policy.

4. Check the selected user's resultant policy

This adapts the identity example in Get-ADUserResultantPasswordPolicy:

Get-ADUserResultantPasswordPolicy -Identity test

That cmdlet retrieves the user's resultant PSO. A PSO assigned directly to the user takes priority over PSOs inherited through global security groups. If several PSOs apply directly, the lowest precedence value wins among them; group-linked PSOs are compared only when none applies directly. If no PSO applies, assess the domain default. An empty PSO result is not a password-strength measurement.

Our Active Directory password security guide examines six other dimensions: expiration flags, policy weakness, password-not-required flags, exposed description secrets, WDigest, and NTLMv1, with FGPP and service-account handling. Those are distinct from this naming predicate. Do not substitute a cleared naming finding for reviewing those controls, or copy demonstration policy values as a security baseline.

Detection: Correlate 4625, 4740, and 4771

Collect the right systems and fields

Build the evidence around the authentication path. Event 4625 is recorded on the computer where the failed logon occurs; that can be a domain controller, member server, or workstation. Collecting only one DC does not guarantee coverage of all failed logons. Check Audit Logon and Audit Account Lockout coverage as appropriate to the event's documented subcategories.

For domain accounts, include DC Security logs for Event 4740, under Audit User Account Management, and Event 4771, under Audit Kerberos Authentication Service. Microsoft documents 4771 as DC-only and absent when the account does not require Kerberos preauthentication.

Interpret the failure codes precisely

The 4625 monitoring reference identifies 0xC000006A as a bad or mistyped password, 0xC0000064 as a bad or misspelled account name, and 0xC000006D as an incorrect username or authentication information. Its event documentation identifies 0xC0000234 as an account locked out. Preserve Status and SubStatus; do not reduce the investigation to a single general failure label.

For 4771, 0x18 is KDC_ERR_PREAUTH_FAILED: invalid preauthentication information, with a wrong password documented as a cause. 0x6 is KDC_ERR_C_PRINCIPAL_UNKNOWN, meaning the client was not found in the Kerberos database. 0x12 is KDC_ERR_CLIENT_REVOKED, meaning client credentials have been revoked. Do not equate 0x12 automatically with lockout alone, or treat these codes as interchangeable with 4625's status fields.

These distinctions help separate unknown-name attempts from bad-password attempts and lockout consequences. They still do not reveal the candidate password. A correlation rule built from these events cannot prove that one identical secret was submitted to every account.

Correlate behavior, then test the explanation

An editorial detection design is to group failures by time window and source, count distinct targeted accounts, and join those identities to the naming inventory. Establish a local baseline before choosing a window or alert threshold. This is a design to implement and validate, not a copied Microsoft query or a measured threshold for your estate.

Compare the pattern with expected user mistakes and services retrying an old credential. Broaden the search when sources vary, then examine successful or interrupted sign-ins and unusual subsequent activity. The Microsoft spray playbooks support timeline, source, account, and follow-on correlation. A campaign can remain below the lockout threshold, so requiring 4740 would leave a detection gap.

In a hybrid environment, include Entra sign-in and MFA records and the federated identity provider's logs where applicable. The investigation playbook explains that log placement depends on managed versus federated authentication. A successful password followed by failed MFA deserves investigation even when no final application access occurred. A clean account-name report cannot resolve that incident.

Remediation: Resolve Purpose, Exposure, and Controls

1. Review each identity with its owner

Use a review record to distinguish human, shared, test, service, built-in, and recovery identities. This classification is an operational recommendation, not something the regex computes. Ask what still requires the account, who can use it, which authentication paths accept it, and what depends on its current name or credentials.

Prefer attributable human access and document exceptions, owners, and expiry dates for temporary needs. Review privileges separately: support does not establish help-desk permissions, and backup does not establish what resources the account can access. The naming code has no group-membership or privilege predicate.

For testing, Microsoft's Entra test-environment guidance discusses dedicated tenants or properly isolated resources and app registrations. It is an Entra application procedure, not a native AD deployment recipe. Applying its isolation principle to AD test identities is a governance recommendation: define a test boundary and lifecycle appropriate to your domain.

2. Retire unnecessary accounts after dependency review

For an ordinary account confirmed unnecessary, first verify dependent services, scheduled tasks, applications, and recovery arrangements with the owner. Then plan a targeted disable action. This adapts example 1 in Disable-ADAccount to an illustrative reviewed test identity:

Disable-ADAccount -Identity test

Do not feed the naming inventory into a bulk disable operation. The filter cannot tell you whether an identity is operationally essential. A planned rename is another possible administrative action, after checking consumers of the current name. The following uses the documented identity and SamAccountName parameters of Set-ADUser:

Set-ADUser -Identity test -SamAccountName app-validation

That changes the SAM account name. It does not change the password, reduce permissions, enforce MFA, or prove that the account is no longer discoverable. Choose names for operational clarity and accountability; a lower regex count is insufficient justification for a rename.

3. Preserve the built-in Administrator recovery role

An enabled Administrator matches the detector because there is no SID or built-in-account exception. Determine which account you are reviewing before applying any retirement decision. Do not blindly disable the domain's built-in Administrator because it appears in the names list.

Microsoft's built-in Administrator guidance reserves its use for initial construction and possible disaster recovery. The page explicitly removed its earlier disabling recommendation because forest recovery uses this account, including logon without a Global Catalog server. It instead describes restrictions and auditing of use, password resets, and account changes.

Apply restrictions through a reviewed recovery plan and the documented scope. The page warns against linking its restriction GPO at the domain level because that can make Administrator unusable during recovery. Do not extend the old Administrator-renaming page's historical lockout statements into an unverified claim about every Windows version and configuration.

4. Use gMSAs for AD services and managed identities for Azure

For Windows services using ordinary domain users, assess a gMSA migration where supported. Microsoft's Windows Server service-account documentation describes automatic password management and a shared service identity across multiple servers. Review service compatibility, authorized hosts retrieving credentials, resource permissions, and SPNs before migration. This recommendation addresses service credential handling, not every human account with a matching name.

For Azure workloads, Microsoft's cloud service-account guidance favors managed identities where possible and service principals when necessary, over user-based Entra service accounts. Keep this cloud identity choice distinct from an AD gMSA deployment.

Where an application genuinely requires shared credentials, Entra account-sharing guidance describes password-based SSO that brokers access through individual identities. Users need not receive the shared password; administrators can revoke access, require MFA, and review sign-in records. Password rollover depends on application support. This is a specific application-access option, not a universal remedy for shared AD logons.

5. Verify FGPP, lockout, and MFA on actual paths

Select password and lockout settings for the account population and risk, then verify the resultant policy with the inventory commands above. FGPP can differentiate policy for users and global security groups. Do not deploy Microsoft's sample LockoutThreshold=0 merely because it appears in a demonstration: policy syntax and security recommendations serve different purposes.

The account-lockout threshold reference describes the tradeoff between guessing resistance and denial of service through deliberate lockouts. Its Windows baseline discussion uses ten invalid attempts as a possible starting point, explicitly without a universal threshold. Review threshold, duration, reset window, unlock operations, and monitoring together.

Entra smart lockout is a separate control from AD DS lockout. It distinguishes familiar and unfamiliar locations and tracks recent bad password hashes; hash tracking is unavailable with pass-through authentication. For PTA, Microsoft directs a lower Entra threshold, an AD DS threshold at least two or three times higher, and a longer Entra duration. Verify your authentication mode and actual settings rather than copying an example as a universal rule.

Enforce MFA on compatible exposed paths and review legacy authentication as the spray investigation playbook recommends. An Entra MFA policy does not make traditional AD authentication paths automatically require MFA. When telemetry establishes password or account compromise, follow incident response, including credential changes and appropriate session/token revocation, rather than closing the case after renaming an account.

How EtcSec Detects This

The etc-collector check is PASSWORD_COMMON_PATTERNS, category Password, severity High. Its Detect() begins at public/internal/audit/detectors/ad/password/common-patterns.go:26; the fifteen exact expressions are declared at lines 28–44:

(?i)^admin$
(?i)^administrator$
(?i)^test$
(?i)^user$
(?i)^guest$
(?i)^temp$
(?i)^default$
(?i)^support$
(?i)^service$
(?i)^backup$
(?i)^demo$
(?i)password
123$
(?i)^sa$
(?i)^dba$

The implementation iterates collected users and excludes only Disabled accounts. It lowercases SAMAccountName and checks these expressions. Thirteen are complete-name matches; password matches anywhere, and 123$ matches the ending. Thus admin01, test1, temp-user, and svc-sql are not selected by those names alone; resetPasswordHelp and User123 are selected.

It adds an account on the first matching expression and breaks the inner loop. An account matching more than one expression contributes only once. There is no exemption based on SID/RID, OU, privileged group, service purpose, or allowlist in this implementation.

Count includes all matching enabled users. Details.affectedAccountNames contains at most ten names, even without IncludeDetails. Ten displayed names therefore do not mean only ten matching accounts exist. AffectedEntities is added when details are requested and the count is positive; the finding itself is returned even at zero.

The detector does not read displayName, any password, or any password hash. It does not measure password entropy, perform authentication, evaluate lockout policy or MFA, or inspect activity to prove a spray attempt or success. Its descriptive text suggests default-password risk, but those suggestions are not predicates in the code.

Validate the Outcome

Repeat the same inventory and effective-policy reads after approved changes. Document retained exceptions and recovery requirements, and confirm with owners that services and applications still function. Review the relevant authentication records for remaining suspicious activity using Microsoft's investigation guidance.

Close each review with the outcome it actually establishes: unnecessary identity retired, dependency migrated, effective policy verified, or an exception retained with justification. Naming, password policy, access enforcement, and attack evidence answer different questions. A completed naming review should make those answers clearer without claiming that a regex has tested a secret.