Lateral Movement: Why a Clean Web App Pentest Report Can Still Miss the Attack That Ends Your Company
MITRE ATT&CK TA0008 in practice: how one leaked credential becomes domain admin, why single-asset scoping structurally cannot catch it, and what to require from any vendor who claims they test for it.
What Lateral Movement Actually Is
Most security teams think of an attack as one exploit against one target. Real intrusions rarely work that way. An attacker gets a foothold through a low-severity bug (an exposed config file, a stale credential, a forgotten admin panel) and then spends the rest of the engagement moving sideways: reusing a password on a different host, replaying a session token across a different app, riding an overprivileged service account into a system that was never in scope.
MITRE ATT&CK groups these behaviors under TA0008. It sits between Lateral Movement’s neighbors, Privilege Escalation and Collection, because moving sideways is rarely the end goal. It is the bridge between “I got in somewhere small” and “I own the crown jewels.”
The distinction that matters for testing programs: lateral movement is not a vulnerability. It is a chain of otherwise-unremarkable facts (a reused password, a trusted network path, an overprivileged account) that only becomes dangerous when connected. A scanner or a single-app pentest looks at each fact in isolation and calls it low or medium risk. An attacker connects the facts and gets domain admin.
The Core ATT&CK Techniques
TA0008 covers several distinct technique families. Understanding each one is what separates a checklist audit from a real adversarial test.
Remote Services (T1021)
Attackers use legitimate remote access protocols with valid or stolen credentials instead of exploiting a vulnerability. The sub-techniques map to the protocols your infrastructure already runs:
| Sub-technique | Protocol | Common abuse pattern |
|---|---|---|
| T1021.001 | RDP | Stolen local admin credentials used to RDP into adjacent Windows hosts, often with no MFA on internal-only ports. |
| T1021.002 | SMB/Windows Admin Shares | Authenticated access to ADMIN$ or C$ shares to stage tools and execute remotely via PsExec-style tooling. |
| T1021.004 | SSH | Reused key pairs or passwords against Linux and network devices, frequently the pivot point after a web app credential leak. |
| T1021.005 | VNC | Weak or default VNC auth on jump boxes and ops consoles, often internet-facing on non-standard ports. |
| T1021.006 | WinRM | PowerShell remoting abused for fileless lateral execution, harder for EDR to distinguish from legitimate admin activity. |
The common thread: none of these require a new exploit. They require a valid credential and a network path. Both are usually already present in a typical enterprise, which is why Remote Services is one of the highest-volume techniques observed in real breach investigations.
Pass the Hash (T1550.002)
Windows NTLM authentication allows a client to authenticate using the hashed form of a password, not the plaintext. An attacker who dumps hashes from one compromised machine (via LSASS memory, SAM database, or a domain controller) can authenticate to other systems as that user without ever cracking the hash. If the hash belongs to a local admin account reused across the fleet, one compromised laptop can mean lateral access to every machine sharing that local admin password.
Pass the Ticket (T1550.003)
The Kerberos equivalent. An attacker steals a Ticket Granting Ticket (TGT) or service ticket from memory and replays it to authenticate as the ticket’s owner, without the password or hash at all. This is the mechanism behind Golden Ticket and Silver Ticket attacks, and it is why session and ticket lifetime, not just password strength, is a control that matters.
Internal Spearphishing (T1534)
Once inside, attackers use the trust of a compromised internal identity to phish other employees from what looks like a legitimate internal sender. An email “from IT” asking a finance user to reset credentials on a fake internal portal succeeds far more often than the same email from an external domain, because internal mail rarely gets the same scrutiny.
Exploitation of Remote Services (T1210)
Where Remote Services (T1021) abuses valid credentials, T1210 exploits an actual vulnerability in a remote service, unpatched SMB, RDP, or a vulnerable internal API, to move laterally without any credential at all. EternalBlue against SMBv1 is the canonical example. Internal services patched on a slower cadence than internet-facing ones are the usual target, because “it’s internal” is treated as a reason to deprioritize patching.
SSH Hijacking and Agent Forwarding Abuse
SSH agent forwarding is convenient and dangerous. If an attacker compromises a host where a user has forwarded their SSH agent, they can use that live agent to authenticate onward to any host the user has access to, without ever touching a private key file. This is a common pivot in DevOps and cloud environments where engineers routinely SSH through several hops with forwarding enabled by default.
Software Deployment Tools Abuse (T1072)
Enterprise software deployment platforms (SCCM, Ansible, Puppet, Chef, Jenkins) exist specifically to push code to many machines at once. That is exactly what makes them a high-value target. An attacker who compromises the deployment server does not need to move laterally machine by machine. They push a malicious package once and get code execution on every endpoint the platform manages.
Why Single-Asset Pentest Scoping Structurally Misses This
Here is the part most security programs get wrong, not because of bad testers but because of bad scoping. A typical web app pentest is scoped to one application: its endpoints, its authentication, its input handling. The rules of engagement usually say “do not touch production infrastructure beyond this app” or “stop at proof of initial access.”
That scoping decision is reasonable for managing risk and cost. It also means the engagement never answers the question that actually matters to a CISO: what happens after this app is compromised? If the tester finds a SQL injection and stops at “confirmed data exfiltration possible,” the report says “high severity, fix the injection.” It does not say “this database’s service account password is reused on the SSH server hosting three other production systems,” because nobody was scoped to check.
Lateral movement is, in practice, app-to-app and app-to-network pivoting. It happens because of three structural conditions that exist in almost every environment regardless of how well any single app is secured:
Credential reuse across environments. Developers reuse database passwords between staging and production. Ops teams reuse local admin passwords across a server fleet because rotating them individually is operationally painful. A credential found in one context is assumed valid nowhere else, until someone tests that assumption.
Session token reuse. Single sign-on and shared session infrastructure mean a token stolen from one app can sometimes authenticate to another, especially where SSO scoping is misconfigured or where JWTs are accepted across services that should not trust each other.
Service account overprivilege. A service account created for one integration is granted domain-wide or org-wide permissions because it was faster than scoping it correctly. That account becomes a lateral movement superhighway the day any system using it is compromised.
None of these three conditions are visible from inside a single app’s scope. They are only visible when a test is allowed, and instructed, to follow the chain past the first compromise.
A Realistic Attack Chain, Step by Step
This is not a hypothetical. Variations of this exact chain show up repeatedly in breach postmortems and red team reports.
Step 1, initial access. A developer commits a `.git` directory to a publicly accessible web root. Automated or manual recon (`git-dumper`, or simply requesting `/.git/config`) reconstructs the full repository, including a `.env` file with a database connection string: hostname, username, plaintext password.
Step 2, credential reuse. The database password is not unique to the database. The same ops team that provisioned the database also provisioned the application server, and password reuse across service accounts is common when credentials are set once during provisioning and never rotated. The attacker tries the same credential against SSH on the app server. It works.
Step 3, privilege escalation. The SSH account has passwordless sudo configured for a deployment script, a common convenience shortcut. The attacker abuses the script’s overly broad permissions to gain root.
Step 4, internal pivot. From root on this box, the attacker reads SSH known_hosts and shell history, finding references to an internal jump host used for routine maintenance. The same root-level credential material, or a private key found unencrypted in a home directory, grants access there too.
Step 5, reaching the second system. The jump host has broad network reach into a segment hosting a second, unrelated internal application, the one that actually holds customer PII or payment data. Because network segmentation between the app tier and this internal segment was never enforced (it was “internal, so it’s trusted”), the attacker reaches it directly.
Total distance traveled: one exposed `.git` directory to a second production system holding sensitive data, without a single exploit against either endpoint’s actual application logic. Every step used legitimate access and reused credentials. A vulnerability scanner would have flagged the `.git` exposure as a single medium-severity finding and stopped there. It would never have found steps two through five, because a scanner does not attempt to reuse a discovered credential against a different host, and a pentest scoped only to the original web app would have had no rules-of-engagement authorization to try.
Why Testing This Requires a Multi-Stage Attack Path, Not Isolated Findings
A vulnerability list is a set of independent facts. An attack path is a graph. The difference determines whether a report tells you your actual risk.
Testing for lateral movement means the engagement (or the automated system running it) must be authorized and technically capable of: extracting credentials found in one context, attempting to reuse them elsewhere, mapping the resulting access, and continuing the chain until it either dead-ends or reaches a materially different asset. That requires rules of engagement broader than “test this one app,” tooling that can track and reuse discovered credentials programmatically, and a way to prove each step (not just assert it) so the client can validate the chain rather than take it on faith.
This is also why proof of exploit matters more here than almost anywhere else in security testing. A claim of “database credentials could theoretically be reused” is not the same as a captured session showing root access on a second system reached via a documented, four-step chain. CISOs who have been burned by unverifiable pentest claims should ask for the latter every time.
Detection and Defense
You cannot patch your way out of lateral movement risk, because most of the techniques above abuse legitimate access rather than a specific software flaw. Defense is architectural and operational.
Network segmentation. Flat networks are the single biggest amplifier of lateral movement. Segmenting by function and enforcing default-deny between segments means a compromised web tier host cannot simply route to a database tier or an unrelated business unit’s systems. Segmentation does not stop initial compromise. It stops that compromise from spreading.
Identity segmentation and just-in-time privilege. Standing admin access is a standing lateral movement path. Just-in-time privilege elevation (request access, get it for a bounded window, lose it automatically) shrinks the time an attacker has to abuse any given credential, and tiered admin models (preventing a workstation-tier credential from ever authenticating to a server-tier or domain-controller-tier system) directly block Pass the Hash and Pass the Ticket chains.
EDR lateral movement detection. Modern EDR platforms baseline normal remote authentication patterns (which hosts, which accounts, which times) and flag anomalies like a workstation account suddenly authenticating via WinRM to a dozen servers in a short window. This is detective, not preventive, so it depends on someone actually watching the alerts and on the baseline being accurate.
Credential rotation and elimination of standing secrets. Rotating service account and shared local admin passwords on a real cadence, and moving toward secrets managers and short-lived credentials instead of static ones checked into config files or reused across a fleet, directly closes the credential-reuse pattern described above.
Honeytokens. Planting fake credentials, fake database connection strings, or decoy accounts that have no legitimate use gives you a near-zero-false-positive tripwire. Any authentication attempt using a honeytoken is by definition an attacker (or a misconfigured test), because no legitimate process should ever use it.
Why This Matters for How You Test
Most annual pentest programs are scoped app by app, which means most annual pentest programs never test the exact chain described above, credential reuse and internal pivoting past the first compromised asset. Annual testing also only happens once a year against an attack surface that changes constantly, while CVEs are exploited in the wild in about 3 days on average. The gap between one test a year and a threat landscape that moves in days is exactly where lateral movement paths go undiscovered and unremediated.
FireCompass runs Chain and Red Team validation as one of its four core capabilities, testing for credential reuse, app-to-app and app-to-network pivots, and MITRE ATT&CK kill chain behavior as part of continuous, agentic pentesting, not as a separately-scoped and separately-priced red team engagement. Every finding, including chained ones, comes with proof of exploit and reproduction steps, not a theoretical severity rating. Independent benchmarks show FireCompass agents achieving 100% coverage on XBEN (104/104) and Acuart (12/12, PoC-validated) with a false positive rate under 2%, compared to 40 to 70% for traditional scanners, so a chained finding is something your team can trust and act on immediately rather than re-verify from scratch.
Questions to Ask Vendors
These questions apply to any pentest firm, red team provider, or automated testing platform you are evaluating for this capability, not a specific vendor. A vendor’s answer, or refusal to answer, tells you more than their marketing deck will.
Does your standard rules of engagement allow testers to reuse a credential discovered in one system against a different system, or does scope stop at the first compromised asset?
Why it matters: if the answer is “scope stops at the app,” they are structurally incapable of finding lateral movement, no matter how skilled the testers are. A good answer names the specific authorization language they use to permit onward pivoting.
Can you show a real, redacted example of a multi-stage attack chain your team or platform has found, with proof at each step?
Why it matters: a vague answer (“we’ve found lateral movement before, trust us”) is a red flag. A strong answer includes screenshots or logs proving each hop, not just a narrative description.
How do you handle Pass the Hash and Pass the Ticket testing specifically? Do you test Kerberos ticket lifetime and NTLM relay exposure, or only password-based authentication?
Why it matters: many engagements never touch hash or ticket-based attacks because they require deeper AD knowledge and more invasive testing. If they cannot describe their approach to either, they are not testing a major share of real-world lateral movement techniques.
What is your false positive rate on chained or multi-stage findings specifically, not just single vulnerabilities?
Why it matters: chained findings are harder to validate than single findings, so false positive rates on chains tend to be worse unless the vendor has purpose-built validation for them. Ask for a number, not an adjective.
If your engagement is scoped to a single web application, what is your process when you find a credential that could plausibly be reused elsewhere? Do you stop, or is there a defined escalation path to test further with client approval?
Why it matters: good vendors have a mid-engagement escalation process (a quick call, a scope amendment) for exactly this situation. If they say “we note it in the report and move on,” you are getting a vulnerability list, not a real adversarial test.
How do you test internal spearphishing and identity-trust abuse as part of a lateral movement assessment, separate from a generic phishing simulation?
Why it matters: internal spearphishing exploits the trust of an already-compromised identity, which is a different test than an external phishing campaign against untrained users. Vendors who conflate the two have not actually built this capability.
Do you test software deployment tooling (SCCM, Ansible, Jenkins, similar) as a lateral movement vector, or is that explicitly out of scope by default?
Why it matters: deployment tooling compromise is one of the highest-impact lateral movement paths because it grants fleet-wide access in one step. If it is excluded by default and the vendor does not flag that as a gap, you may have a blind spot you don’t know about.
How often can you realistically re-run a full chained attack path assessment, and what does that cost each time?
Why it matters: environments change weekly. A chain that existed six months ago may be closed, and a new one may have opened. If re-testing a full chain costs the same as the original engagement and takes the same lead time, you will not do it often enough to matter.
How do you handle production safety during lateral movement testing, specifically around domain controllers, Golden Ticket forgery, and deployment tool abuse?
Why it matters: some of the most realistic lateral movement techniques are also the most likely to cause outages if handled carelessly. A vendor with real experience here should be able to describe specific safeguards, not just “we’re careful.”
Will you provide the actual reproduction steps and exploit code for a chained finding, or only a narrative description in the report?
Why it matters: a narrative claim (“credentials could theoretically be reused to reach System B”) cannot be independently verified by your team. Reproducible steps and working exploit code can be re-run by your own engineers to confirm the finding is real before you spend remediation budget on it.
RFP Criteria for Lateral Movement Testing
Use this table directly in a formal RFP when evaluating any vendor for this capability. Each row is a requirement to state explicitly, not a nice-to-have.
| Criterion | What to require |
|---|---|
| Rules of engagement scope | Vendor must explicitly permit credential reuse testing and onward pivoting beyond the initially compromised asset, with a documented escalation process if new systems are discovered mid-engagement. |
| ATT&CK technique coverage | Vendor must map their methodology to specific TA0008 techniques tested (T1021 and sub-techniques, T1550.002, T1550.003, T1534, T1210, T1072) rather than a generic “lateral movement included” statement. |
| Proof of exploit standard | Every chained finding must include reproducible steps or working exploit code per stage of the chain, not a narrative theoretical description. |
| False positive rate disclosure | Vendor must disclose a measured false positive rate, ideally separated for single findings versus multi-stage chained findings. |
| Testing cadence and re-test cost | Vendor must state turnaround time and cost for a full re-test of a chained attack path, not just the initial engagement, since environments and credential exposure change continuously. |
| Credential handling and secure storage | Vendor must describe how discovered credentials are stored, encrypted, and destroyed after the engagement, given the sensitivity of what gets captured during lateral movement testing. |
| Production safety controls | Vendor must describe specific safeguards for high-risk actions (domain controller interaction, ticket forgery, deployment tool abuse) to prevent outages during testing. |
| Reporting granularity | Report must show the full chain as a connected path (step 1 to step N) with severity assigned to the chain’s ultimate impact, not just to each isolated step. |
| Coverage transparency | Vendor must state what percentage of the in-scope environment (hosts, identities, network segments) was actually reachable and tested for lateral movement, not assumed covered. |
Vendor Evaluation Criteria (Scoring Rubric)
Use this rubric to score and differentiate competing vendors on lateral movement testing specifically. Score each criterion independently before totaling.
| Criterion | What Good Looks Like | Red Flag |
|---|---|---|
| Scope authorization | Standard contract language explicitly permits credential reuse and onward pivoting, with a fast escalation path for newly discovered systems. | Scope is hard-locked to a single asset with no mechanism to test further even when a credential is found. |
| Technique-level methodology | Vendor names specific ATT&CK techniques tested and can describe their approach to each (Pass the Hash, Pass the Ticket, T1021 sub-techniques individually). | Vendor says “we test lateral movement” with no technique-level detail when pressed. |
| Evidence quality | Findings include screenshots, session captures, or working exploit code proving each hop in the chain. | Findings are narrative only (“this could potentially lead to access on System B”). |
| False positive discipline | Vendor discloses a specific, low false positive rate and can explain how chained findings are validated before reporting. | No false positive rate offered, or vague reassurance without a number. |
| Re-test economics | Re-testing a chain costs meaningfully less and takes meaningfully less time than the original engagement, enabling frequent re-validation. | Full re-test costs the same and takes the same lead time as the original engagement every time. |
| Deployment tooling coverage | Vendor proactively tests software deployment platforms (SCCM, Ansible, Jenkins, similar) as a lateral movement vector. | Deployment tooling is silently excluded and only surfaces as a gap when you ask directly. |
| Safety engineering | Vendor describes specific technical safeguards for high-risk actions near domain controllers and identity infrastructure. | Vendor’s answer to production safety is “our testers are experienced,” with no technical control described. |
| Report actionability | Chain is reported as a connected path with a single business-impact severity, plus per-stage remediation guidance. | Chain is broken into disconnected line items, each scored independently, obscuring the real end-to-end risk. |
Frequently Asked Questions
Is lateral movement the same thing as privilege escalation?
No. Privilege escalation (MITRE ATT&CK TA0004) means gaining higher permissions on the system you already have access to. Lateral movement means moving to a different system entirely. In practice, real attack chains alternate between the two: escalate privilege on host A, use that privilege to move to host B, escalate again there.
Can a vulnerability scanner detect lateral movement risk?
Not in any meaningful way. Scanners assess individual hosts and applications against known signatures. They do not extract a credential from one system and attempt to reuse it against another, which is the core behavior that defines lateral movement. This is a fundamental architectural limitation, not a feature gap that will be patched in a future scanner release.
Does network segmentation alone solve lateral movement risk?
It reduces the blast radius significantly but does not eliminate the risk. Identity-based lateral movement, Pass the Hash, Pass the Ticket, can still succeed within a segment or across segments where trust relationships exist for legitimate business reasons (shared authentication, cross-segment service accounts). Segmentation and identity controls need to work together.
Why do annual pentests so rarely catch lateral movement paths?
Two reasons. First, scoping: most annual engagements are priced and scoped per application, and testing onward pivoting requires broader rules of engagement that cost more and take longer to negotiate. Second, timing: annual testing covers a single point in time against an attack surface and credential landscape that changes continuously, so even a thorough test can miss a lateral path that opened up the following month.
What is the difference between Pass the Hash and Pass the Ticket?
Pass the Hash (T1550.002) abuses NTLM authentication by replaying a captured password hash instead of a plaintext password. Pass the Ticket (T1550.003) abuses Kerberos by replaying a stolen ticket (TGT or service ticket) instead of any password material at all. Both let an attacker authenticate as another user without cracking a password, but they target different authentication protocols and require different detections.
Is internal spearphishing really a lateral movement technique?
Yes, under MITRE ATT&CK T1534. It uses a compromised internal identity’s trust to phish other internal users, which is fundamentally different from external phishing because the target’s guard is down for anything that appears to come from inside the organization.
What is a honeytoken and how does it help detect lateral movement specifically?
A honeytoken is a fake credential, connection string, or account planted specifically to be discovered by an attacker moving through an environment, never used by any legitimate process. Any use of it is a definitive compromise signal with effectively zero false positives, which makes it well suited to catching the exact credential-harvesting-and-reuse behavior that defines lateral movement.
See What an Attacker Could Actually Reach From Your Web App
Most pentest reports stop at the first compromise. FireCompass runs autonomous, agentic testing that follows credential reuse and internal pivots the way a real attacker would, with proof of exploit at every stage, not a theoretical severity score. Start with a free scan of your actual attack surface.
Free AI Pen Test