Attackers Don’t Start with the Hardest Exploit

How Attackers Choose a Path In
What Enables Initial Access Through Internet-Facing Systems
- 2.1 Unmanaged Internet-Facing Assets and Development Environments
- 2.2 When Authentication Gaps Across Services Compound
- 2.3 Control Gaps in Third-Party Access
What Enables Privilege Escalation and Lateral Movement After Compromise
- 3.1 Sensitive Service Account Privileges and Misconfigured Permissions
- 3.2 Reused Local Administrator Credentials
- 3.3 The Technical Debt of Legacy Authentication and Authorization
Breaking the Attack Path
- 4.1 Managing Internet-Facing Assets and Development Environments
- 4.2 Managing the Full Account Lifecycle
- 4.3 Third-Party Account Governance, Access Responsibilities, and Data Boundaries
- 4.4 Limiting Privilege Escalation and Lateral Movement
Conclusion: Efficient Security That Forces Costly Attacks
References

1. How Attackers Choose a Path In

When people picture an attack on an enterprise, they often imagine an attacker using a zero-day or sophisticated exploit to bypass security controls and take over a critical server. Security assessments likewise tend to start by looking for critical vulnerabilities in individual systems. That perspective can obscure where a real attack would begin and how far it could travel.

An attacker’s decision is driven less by a vulnerability’s severity rating than by the cost of reaching the objective. Attackers look for the path most likely to succeed with the information and access they already have. Accounts without multifactor authentication (MFA), misassigned privileges, default credentials, unpatched software, and unnecessarily exposed services shorten that path. (Microsoft, Implementing Least-Privilege Administrative Models)

Even without a single critical vulnerability, gaps scattered across multiple systems can connect into an attack path. Organizations manage assets and accounts by business unit or service, but attackers see a company’s domains, identity systems, remote access services, and trust relationships as one environment. Organizational boundaries do not break the attack path when information or access gained in one area opens the next.

In this article, the internet-facing environment comprises services and assets that are directly reachable from the internet. By internal systems and trust relationships, we mean the systems, administrative planes, and trust relationships an attacker can reach after gaining initial access. The discussion focuses on paths that begin with internet-facing services and identity systems and extend into privileged access within Windows and Active Directory (AD) environments.

First, we examine the conditions that create initial access through internet-facing assets and services. We then look at how access gained through a compromised account or endpoint can escalate into higher privileges and reach other internal systems. Finally, we outline how to break these connections across internet-facing assets, authentication, third-party access, and internal privileges.

The scenarios below are independent, hypothetical examples based on technical risks and security principles described in public sources. The likelihood and impact of a real compromise depend on how internet exposure, credentials, network reachability, execution privileges, and trust relationships connect in a particular environment.

2. What Enables Initial Access Through Internet-Facing Systems

Across an organization’s internet-facing environment, unmanaged assets, inconsistent authentication controls, and exceptions for third-party access may appear to be separate issues. In practice, they can chain together: information exposed through one system can be used to gain access to another, creating a viable initial-access path.

2.1 Unmanaged Internet-Facing Assets and Development Environments

One recurring problem on an organization’s internet-facing attack surface is an asset the organization does not know exists. A business unit, development team, or third-party provider may deploy a server or service for a legitimate business need and expose it to the internet without completing asset registration or a security review. If the security team does not know the asset exists, it may also fall outside routine vulnerability scanning, patching, access control, and log monitoring. As a result, known vulnerabilities may remain unpatched, while default credentials or administrative services remain exposed to the internet.

Development and staging environments are common examples of this oversight gap. They are often temporary or operated by a separate team, which can leave ownership unclear and systems exposed after their intended use has ended. If they lack authentication and access controls commensurate with their risk—or reuse service account credentials, API keys, or cloud roles from production—a development environment compromise can expose production data and resources.

For example, an unmanaged asset may expose employee information, live data, service architecture, or account-naming conventions that can be used for credential guessing and authentication attempts against other services. An unsanctioned asset can become a foothold for deeper intrusion if it allows server-side code execution, can make requests to internal services, or shares production credentials or trust relationships.

2.2 When Authentication Gaps Across Services Compound

Organizations administer login and account policies service by service, but username conventions and password habits often repeat across the enterprise. As a result, account information exposed through one service and weak authentication controls in another can combine into a broader access risk.

Enterprise usernames often follow predictable combinations of names, email addresses, or employee numbers. Passwords likewise reflect convenience and organizational habits. When users choose contextually guessable passwords—such as a company name, season, or year followed by digits or a special character—public information can make both usernames and passwords easier to predict.

Differences in login, registration, and account-recovery responses can reveal whether an account exists. Those signals, combined with guessable passwords and weak login throttling, increase the risk of password spraying. Credentials exposed through another service can also be reused for credential stuffing. (MITRE ATT&CK T1110.003: Password Spraying, MITRE ATT&CK T1110.004: Credential Stuffing) If the target service accepts those credentials without requiring an additional factor, the attacker gains unauthorized access to the account. If those credentials are also accepted by a virtual private network (VPN), virtual desktop infrastructure (VDI) environment, Remote Desktop Gateway, or zero trust network access (ZTNA) service—and the account is authorized for remote access—the attacker gains a path into the internal environment.

A similar gap arises when accounts are provisioned for more people than will actually use the service. Suppose accounts are created in advance for more users than necessary, with a known identifier such as an employee number used as both the username and initial password. Predictable initial passwords then remain on dormant accounts. Without a separate identity-verification or activation step, an attacker may claim an account before the intended user ever signs in. (OWASP WSTG, Testing for Default Credentials)

Authentication risk therefore needs to be assessed across the organization’s identity ecosystem, not only through each service’s login settings in isolation. The review should trace where account information is exposed, which services have weak login, recovery, or activation controls, where additional authentication is enforced, and how far the same credentials remain valid.

2.3 Control Gaps in Third-Party Access

Employees and third-party users may use the same service, but their accounts and endpoints can be managed differently. The organization can directly provision and manage employee accounts and devices and apply its own security policies. For third-party access, the organization may manage application accounts and entitlements while the third-party provider tracks each user’s employment status and endpoint posture. Delayed information sharing or unclear ownership can create gaps in account updates and deprovisioning, endpoint validation, and identity verification.

This division of responsibility also shapes account-recovery procedures. If the organization does not directly maintain a third-party user’s identity attributes and contact channels, it may create a separate recovery flow for those users. One example is to ask for static personal data already held by the organization—such as a name, address, and date of birth—and allow a password reset when the answers match. (OWASP, Choosing and Using Security Questions Cheat Sheet)

That information may be available through public profiles, business directories, or leaked data and cannot be treated as a secret known only to the user. If static information alone is enough to complete recovery, without a pre-registered recovery method or other proof of control, the recovery process is weaker than primary authentication. When third-party accounts can reach sensitive functions or data, the least-protected access path can determine the security of the service as a whole. Without separation by user, role, and organization, the compromise of one account can expose another organization’s data. (OWASP, Multi-Tenant Security Cheat Sheet)

3. What Enables Privilege Escalation and Lateral Movement After Compromise

A foothold obtained through an internet-facing asset or account becomes more consequential when it intersects with internal privileges and trust relationships. Sensitive service account privileges, reused administrator credentials, and legacy authentication and authorization structures can turn a limited foothold into elevated privileges and access to additional systems.

If network location itself serves as a basis for trust, or if AD account and privilege policies are managed separately from local permissions and remote-access settings on individual systems, lateral-movement paths after an account compromise can remain outside effective control.

3.1 Sensitive Service Account Privileges and Misconfigured Permissions

Accounts that run business services receive privileges that allow them to use operating-system functions and resources. If a service vulnerability or credential compromise allows code to run in the service account’s security context, the account’s privileges become one of the conditions that determine the potential impact. On Windows, whoami /priv lists the privileges present in the current access token and shows the state of each privilege.

Examples include SeImpersonatePrivilege, which permits a process to impersonate a client after authentication; SeBackupPrivilege, which grants the read access required for backup regardless of a file’s access control list (ACL) and is required for protected registry-save operations; SeRestorePrivilege, which grants the write access required for restore regardless of a file’s ACL and is required for protected registry-load operations; SeDebugPrivilege, which permits debugging and adjusting the memory of any process while ignoring the process’s discretionary access control list (DACL); and SeLoadDriverPrivilege, which permits loading or unloading device drivers. (Microsoft, Privilege Constants) These privileges are intended for legitimate administration and service operation, but when assigned unnecessarily—or combined with other exploitable conditions—they can turn limited code execution into privilege escalation.

Permissions on service executables and their directories matter just as much as operating-system privileges. If a low-privileged user or service account can modify an executable run by a higher-privileged service, the service can execute the modified file in its own security context when it restarts. Overly broad write or modify permissions granted for operational convenience can therefore become a privilege-escalation path. (MITRE ATT&CK T1574.010: Services File Permissions Weakness)

Local privilege-escalation risk cannot be assessed by looking at one tool or vulnerability in isolation. A meaningful review needs to consider the operating-system privileges held by a service account, the functions running in its context, permissions on files and registry keys, service and scheduled-task configuration, and every route through which code can execute as that account. When existing privileges combine with weak access controls, limited access can escalate to administrative control of the host.

3.2 Reused Local Administrator Credentials

If a deployment image or automated provisioning process applies the same local administrator account and password to multiple Windows systems, each system stores the same NT password hash derived from that password.

If the hash is exposed on one system and another system has a local administrator account with the same username and password-derived hash, then—where NTLM-based network logon and remote administration are permitted—an attacker may be able to reuse the hash for authentication without recovering the plaintext password. This is known as pass-the-hash. Under those conditions, compromise of one endpoint can spread to other systems. (Microsoft, Local accounts)

Once the credential has been exposed, password complexity does not constrain its reuse. The number of systems that accept the same credential determines the potential scope of lateral movement.

3.3 The Technical Debt of Legacy Authentication and Authorization

In legacy systems, authentication and authorization are often deeply intertwined with business workflows and system integrations. Legacy authentication methods, shared accounts, application-embedded credentials, and broad privileges can become assumptions on which normal operation depends. Once that happens, changing a single account or privilege can affect multiple services.

Consider a legacy integration application that uses one domain service account to run Windows services and scheduled tasks across several servers while also accessing file shares and databases. If the same account is configured across services and scheduled tasks on multiple servers, rotating its password requires identifying, updating, and restarting every dependency. When those dependencies are not fully mapped, a missed workload can cause an outage, so rotation may be deferred and the credential remains valid across many systems. Credentials embedded in configuration files or integration scripts create an additional exposure path. (MITRE ATT&CK T1552.001: Credentials In Files)

Authorization models create a similar problem. A legacy business application may support only a few coarse-grained roles, such as Standard User and Administrator. A user who needs one approval or reporting function may therefore have to receive the administrator role, along with unrelated capabilities such as changing system settings, viewing all data, and managing accounts. Separating those capabilities requires changes to both the application code and business processes, so excessive privileges can persist for long periods, and compromising the account can affect resources well beyond the user’s intended job function.

Service account dependencies and coarse-grained roles take different forms, but both make it difficult to separate required access from granted access. The less clearly an organization understands the impact of a change, the longer exceptions persist—and the harder it becomes to predict the scope of a credential or account compromise. This is how legacy authentication and authorization become technical debt.

4. Breaking the Attack Path

The conditions in Section 2 create opportunities for initial access; the privileges and trust relationships in Section 3 determine how far the compromise can spread. The following controls address that chain in order: internet-facing assets, accounts, third-party access, and internal privileges.

4.1 Managing Internet-Facing Assets and Development Environments

Asset discovery is a prerequisite for vulnerability remediation, access control, and log monitoring. Organizations should continuously identify production services, development and staging environments, previously used domains, and internet-facing systems operated or used by third parties. For each, they should record the owner, purpose, and internet-exposure status. Every identified asset should be brought into scope for vulnerability scanning and patching, access control, certificate and domain renewal, log collection, and monitoring. Services no longer in use should be removed from public exposure, while assets that must remain internet-facing should be reviewed regularly to confirm the continuing business need and the adequacy of their protections. (NCSC, Asset Management)

Internet-facing development environments need authentication and access controls commensurate with their risk. Communications and trust relationships from development environments to production networks, management APIs, and cloud control planes should be blocked by default, with only business-required paths allowed. If production data must be used, its use should be approved, logged, and controlled, and the non-production environment should be protected according to the data’s impact and classification. Replace live data with synthetic or sanitized data wherever possible, and separate production service accounts, API keys, and cloud roles from their non-production equivalents. (NIST SP 800-53 Rev. 5, SA-3(1) and (2), OWASP NHI8: Environment Isolation)

4.2 Managing the Full Account Lifecycle

Account management begins with provisioning and activation. Accounts should be provisioned only to intended users and only when needed. If accounts must be created in advance for all employees or third-party users, require a separate activation step and a deadline for first login. Automatically disable accounts that have not been activated by the deadline or have remained dormant for an extended period. Do not derive initial passwords from employee numbers, company names, or other predictable values; issue each user a unique, randomly generated, single-use temporary password.

Replace shared user accounts with individual accounts. If a shared account must remain for operational reasons, manage it through a secrets vault with approval and checkout, record activity by individual user, rotate its credentials regularly, and use a long, unique password.

When users authenticate to services with separate passwords, support password managers so they can maintain a unique password for each service. Block breached and commonly used passwords during account creation and password changes. Apply MFA to accounts that can reach internal resources, sensitive data, or administrative functions from the internet, and set authentication strength and reauthentication intervals according to the account’s access scope. (NIST SP 800-63B-4)

At authentication time, assume that username conventions are public. Login, registration, username-recovery, and password-reset functions should return responses that are as consistent as possible whether or not an account exists. Review not only error messages, but also differences in HTTP status codes, response bodies, and processing time that could enable account enumeration. (OWASP, Authentication Cheat Sheet)

Defenses against login attacks should look beyond failure counts for one account or IP address. They should detect password spraying distributed across many accounts and credential-stuffing attempts that replay leaked username-and-password pairs. Correlate activity across accounts, IP addresses, devices, network ranges, and time windows, and share authentication-failure signals among services that rely on the same identity system or credential store. When credential exposure is confirmed, reset the password, revoke active sessions and tokens, and assess the impact across related services.

Account recovery should not become a lower-assurance bypass around normal authentication. Do not reset a password based only on static information or security questions such as a name, address, or date of birth. Use a one-time link or code delivered through a previously enrolled and verified recovery channel, or combine an authenticator that remains available to the user with another approved recovery method. (OWASP, Forgot Password Cheat Sheet)

Role changes and deprovisioning belong in the same lifecycle. Reevaluate existing privileges when a user’s department, job, or third-party affiliation changes. When access is no longer needed because of a departure or contract termination, promptly disable or deprovision the account and revoke active sessions, tokens, and remote-access rights.

4.3 Third-Party Account Governance, Access Responsibilities, and Data Boundaries

The organization and each third party should define who is responsible for account provisioning, changes, recovery, and deprovisioning; who verifies employment status and endpoint posture; and when each side must notify the other. Reconcile user rosters and account status regularly. For events that require immediate action, such as a departure or contract change, set a clear notification deadline and accountable owner.

Access controls for third-party portals should reflect endpoint-management status, access location, and the risk of the functions and data available to the account. For access from an external network or unmanaged endpoint, limit session duration and download scope. Require step-up authentication or a managed access environment for sensitive functions. (NIST SP 800-207, Zero Trust Architecture)

Separate employee and third-party privileges, then distinguish entitlements and data boundaries by organization and role. Enforce authorization on every post-authentication path so that one provider’s account—or a manipulated tenant or object identifier in a request—cannot retrieve another provider’s data.

When the organization cannot directly verify a third-party user’s identity during recovery, involve a registered administrator from that third party and use a verified contact channel. Do not complete recovery using only static information such as a name, address, or date of birth. Monitor recovery and exception approvals alongside access from unusual locations or endpoints. Every operational exception should have an accountable owner, defined scope, and expiration date, and accounts and remote-access rights should be revoked when the contract or business need ends.

4.4 Limiting Privilege Escalation and Lateral Movement

Remote sessions established through VPNs, VDI, Remote Desktop gateways, Secure Shell (SSH) gateways, or ZTNA should reach only the resources and management ports required for the work. Separate development and production environments, as well as user and administrative tiers, with distinct authorizations and management paths, and require step-up authentication to cross those boundaries. Scope access by user, endpoint, time, and business need, and monitor both successful and failed access.

AD reviews should go beyond individual configuration checks. Starting with a low-privileged account, trace attack paths to systems, sensitive accounts, and administrative privileges. Review membership in privileged groups, delegated permissions and delegation settings, local administrator rights, the systems on which remote logon is permitted, and trust relationships between systems as parts of one connected path.

Grant service accounts only the Windows privileges and user rights required by the workload. Deny interactive and remote interactive logon unless explicitly required, and constrain network logon, execution scope, and network reachability to documented dependencies. Regularly review privilege assignments and membership in administrative groups, and remove unused sensitive privileges and logon rights. Restrict modification of service executables, scripts, plug-ins, configuration files, registry keys, and scheduled tasks to administrators or approved deployment accounts, and monitor them for change.

Use Windows Local Administrator Password Solution (Windows LAPS), or an equivalent system, to manage and rotate a unique random local administrator password on each managed Windows device and restrict retrieval to authorized administrators. (Microsoft, Windows LAPS Overview) Where local administrator accounts do not require remote use, deny their network and Remote Desktop logon; where remote use is required, restrict it to approved management paths. Restrict Server Message Block (SMB), Windows Remote Management (WinRM), and Remote Desktop Protocol (RDP) management access to approved administrative endpoints and networks. Audit password retrieval, and rotate the password after administrative use or suspected exposure.

For each legacy service account, inventory its owner, execution locations, dependent services and scheduled tasks, credential-storage locations, and required privileges. In Windows domain environments, migrate supported workloads to an appropriate managed service account type, such as a group Managed Service Account (gMSA). (Microsoft, Service Accounts in Windows Server) For remaining accounts, use a secrets-management system and a phased deployment and validation plan to rotate credentials. Move credentials embedded in configuration files and scripts to a centrally managed secrets store that supports rotation.

For systems that cannot support fine-grained roles, separate administrative accounts from day-to-day user accounts. Require approval for administrative functions, record their use, and limit that use to approved users and time windows. Pair these compensating controls with a roadmap for improving the authorization model or replacing the system, and gradually reduce overly broad privilege bundles. (NIST SP 800-53 Rev. 5, AC-6)

5. Conclusion: Efficient Security That Forces Costly Attacks

Attackers do not choose the hard way without a reason. If unmanaged servers remain exposed to the internet, unpatched vulnerabilities and end-of-life products stay in operation, and guessable passwords and reused administrator credentials are still present, there is little reason to prepare a complex exploit. Attackers can move to the next stage simply by following weaknesses that are already exposed.

Security priorities should follow these attack paths. Internet-facing assets must be brought under management, and alternative login and account recovery paths left in individual services must be reviewed. Third-party accounts should be revoked when they are no longer needed, while the reuse of administrator credentials and service accounts should be reduced. Privileges and access scopes must also be segmented so that compromising one account or system does not provide a direct path to others.

As each easy path disappears, the attacker’s calculation changes. More preparation is required, the likelihood of success decreases, and the risk of detection increases. A single exposed server or reused password should not be enough to reach the intended target.

Let us close the easy paths that begin with assets, accounts, and privileges—and build an environment where attackers are forced to start with difficult, expensive exploits.

6. References

NCSC, Asset Management — Continuous discovery and inventory of all assets, including internet-facing systems, and integration with vulnerability management, patching, and monitoring
NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations — SA-3 controls for non-production environments and production data, and AC-6 least-privilege controls
NIST SP 800-63B-4 (2025), Digital Identity Guidelines: Authentication and Authenticator Management — Blocking weak and compromised passwords, supporting password managers, and selecting appropriate authenticator strength
NIST SP 800-207, Zero Trust Architecture — Making access decisions based on users, endpoints, context, and resource risk rather than trusting network location alone
OWASP NHI8: Environment Isolation — Separating service accounts, API keys, and roles across development, testing, staging, and production and blocking access to production resources
OWASP, Authentication Cheat Sheet — Preventing account enumeration through differences in login, registration, and recovery responses, status codes, and processing time
OWASP WSTG, Testing for Default Credentials — Risks from predictable default or initial credentials and accounts left unchanged before first use
OWASP, Choosing and Using Security Questions Cheat Sheet — The low assurance of static personal information such as names, addresses, and dates of birth, and the risks of relying on security questions alone
OWASP, Forgot Password Cheat Sheet — Resetting passwords with random, one-time tokens delivered through a separate channel
OWASP, Multi-Tenant Security Cheat Sheet — Separating authorization and data boundaries among organizations, users, and tenants and preventing cross-tenant access
MITRE ATT&CK T1110.003: Password Spraying — Trying one or a small set of common passwords across many accounts
MITRE ATT&CK T1110.004: Credential Stuffing — Reusing username-and-password pairs obtained from another service
MITRE ATT&CK T1574.010: Services File Permissions Weakness — Executing code with elevated privileges through weak permissions on service files or directories
MITRE ATT&CK T1552.001: Credentials In Files — Exposure of service account credentials stored in configuration files, scripts, source code, and other files
Microsoft, Privilege Constants — Definitions of SeImpersonatePrivilege, SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, and SeLoadDriverPrivilege in Windows
Microsoft, Local accounts — Pass-the-hash risk created by reusing local administrator passwords and password hashes
Microsoft, Windows LAPS Overview — Automatic generation, rotation, and backup of unique local administrator passwords and reduction of lateral-movement risk
Microsoft, Implementing Least-Privilege Administrative Models — The tendency of attackers to choose the path of least resistance and the principles of reducing excessive privilege and credential reuse
Microsoft, Service Accounts in Windows Server — Windows service-account types and the automatic password and service principal name management provided by managed service accounts