Lateral Movement: Spreading Across a Network

A single compromised machine is rarely the whole story in a real network. Lateral movement describes how access can spread from that first machine to others, often using legitimate administrative mechanisms rather than new weaknesses. This final lesson of the chapter ties together pivoting, privilege escalation, and credential reuse into a single, coherent picture, and connects it directly to what you will need for reporting in chapter 7.

What lateral movement actually means

Lateral movement is the process of using access on one system to reach and operate on other systems within the same network, typically at a similar or sometimes escalating level of access each time. It commonly combines several ideas you already know from this course:

• Pivoting (chapter 4) provides the network path to reach other machines.
• Credential reuse (chapter 5, including pass-the-hash concepts) often provides the means of authenticating to those other machines without needing a fresh exploit for each one.
• Privilege escalation (earlier in this chapter) may be needed again on each newly reached machine, since access gained there might again start out limited.

Put together, these three ideas explain why a single initial weakness, in a worst case, can sometimes cascade into access across a large part of a network, which is exactly the kind of real-world impact a thorough penetration test is meant to reveal.

Why legitimate administrative tools matter here

A particularly important and sometimes underappreciated point: much of real-world lateral movement does not rely on exploiting new technical weaknesses at all. It often uses the very same legitimate remote administration tools and protocols that system administrators themselves use every day to manage machines across a network, simply with credentials or access that should not have been available to the attacker, or the tester, in the first place. This has a crucial consequence for defenders: traditional antivirus-style detection, which looks for known malicious programs, is often far less effective here than monitoring for unusual patterns of legitimate tool usage, such as an account that normally never performs remote administration suddenly doing so, at an unusual time, from an unusual machine.

Thinking in terms of a map, not a single path

A disciplined tester approaching lateral movement, within an authorised and appropriately scoped engagement, keeps a running, written map rather than simply chasing the next machine opportunistically:

• Which machines have been reached, and at what privilege level on each.
• Which credentials or trust relationships enabled each step, referencing the specific finding from earlier in the engagement.
• Which newly reached machines appear to fall outside the original scope (exactly the scope-creep caution from the pivoting lesson in chapter 4), requiring a pause to confirm with the client before proceeding further.

This map becomes one of the most valuable and persuasive pieces of evidence in the final report: a simple diagram showing "weakness on machine A led to credentials enabling access to machine B, where a misconfiguration led to administrative access on machine C" communicates real-world business risk far more clearly to a non-technical reader than a long list of individual technical findings ever could.

The concept of a target, or "crown jewels"

In more mature engagements, especially red team exercises (chapter 1), lateral movement is often guided by a specific objective agreed with the client in advance, commonly called identifying and reaching the organisation's most critical, high-value systems or data, sometimes informally called the "crown jewels" (for example, the system holding financial records, health data, or core intellectual property). Demonstrating a realistic path from an initial, perhaps minor-looking weakness to one of these critical systems is often the single most impactful outcome of an entire engagement, and connects directly back to the prioritisation principles of chapter 3: business value matters as much as technical severity.

Your fil rouge: drawing the Lighthouse Labs attack path

Looking back across this entire chapter and the previous one, draw (on paper, or with simple boxes and arrows in a text file) the fictional attack path for Project Lighthouse: the initial weakness from chapter 4, any credential or privilege escalation finding from chapter 5 and this chapter, and an imagined final "crown jewels" system it could plausibly have led towards, had this been a real engagement. Save this diagram description in 04-post/attack-path.md, since this is exactly the kind of visual your chapter 7 report will need to include.

Your turn: explain the business risk

A client's technical team already knows that an outdated service was running on a low-value internal test server (the initial finding), and does not consider it urgent to fix, since the server itself holds no sensitive data. Using the concepts of this chapter, explain in two or three sentences, as if writing directly to a non-technical business owner, why this seemingly minor finding might still deserve urgent attention.

Chapter 6 is complete: you now understand the full technical journey from initial access to broader impact across a network. The final chapter turns all of this into the deliverable that actually matters to a client: a clear, professional, actionable report.