Pivoting: Reaching Beyond the First Foothold

Real networks are rarely flat: a machine reachable from the internet is often deliberately separated from the more sensitive systems behind it. Pivoting is the principle of using a compromised machine as a stepping stone to reach parts of a network that were not directly reachable before. This lesson introduces the idea and its professional limits, without any working technique against a real target.

Why networks are segmented in the first place

You studied network segmentation as a defensive measure in the second course of this track: splitting a network into zones so that compromising one machine does not automatically expose everything else. A typical pattern places an internet-facing web server in one zone, with a database or internal administrative systems in a separate, more restricted zone that the web server can reach, but that is not directly reachable from the internet.

What pivoting demonstrates

From a tester's point of view, having a foothold on that internet-facing web server raises an important audit question: from this position, what else can actually be reached that a pure internet-based attacker could not have reached directly? Demonstrating this, carefully and only within the authorised scope, shows the client the real-world consequence of segmentation choices: is the sensitive internal zone genuinely isolated, or does the compromised machine effectively open a path into it?

The general principle, without implementation detail

Conceptually, pivoting uses the compromised machine's own network position: since that machine can reach the internal zone (because, in a well-designed network, it needs to, say, to query a database), a tester's traffic can sometimes be routed through it to reach systems the tester's own machine cannot contact directly. This is often described as using the compromised host as a relay or a tunnel. The exact mechanisms vary widely depending on the environment, and are beyond the scope of this introductory course; what matters here is the concept and its implications, which is what a beginner moving towards professional practice needs first.

Why this step is particularly sensitive

Pivoting almost always means your actions can reach systems well beyond the one you directly tested, which raises the stakes considerably:

• The internal systems reached through a pivot may not have been individually listed in the original scope, since the client may not have anticipated this specific path.
• Internal systems are sometimes older, more fragile, or less monitored than the hardened, internet-facing perimeter, making them more sensitive to disruption.
• The impact of demonstrating reachability into a sensitive zone (for example, a zone holding financial or health data) can be significant enough that it deserves an explicit conversation with the client before going further, even if the scope technically allows it.

A measured, professional approach

A disciplined tester who discovers a pivoting opportunity follows a cautious sequence:

1. Identify what appears reachable from the compromised machine, using safe, low-impact checks (for example, observing what the machine itself seems able to contact, rather than aggressively scanning from it).
2. Compare this list against the authorised scope.
3. Pause and confirm with the client contact before testing anything newly discovered that was not explicitly in scope, exactly the "ask when in doubt" principle from chapter 1.
4. Proceed carefully only once confirmed, applying the same disciplined, one-step-at-a-time approach from the earlier lessons of this chapter.

Pivoting as a defensive lesson too

From the defender's side, the existence of pivoting is a strong argument for the principle of least privilege applied to network connections: a web server should typically be able to reach only the specific internal systems and ports it genuinely needs, nothing more. When you eventually write your report (chapter 7), a pivoting finding should always come with a clear, constructive recommendation along these lines, not just a demonstration of "look what I could reach".

Your fil rouge: a pivoting thought experiment for Lighthouse Labs

Since setting up a full multi-zone lab network is a significant undertaking beyond this course, complete this as a thought experiment: imagine your compromised Lighthouse Labs lab machine from earlier lessons sits in a zone that can also reach a second, internal-only zone containing a fictional payroll database server, which was not explicitly named in your original scope document from chapter 1. Write, in your journal, exactly what you would do next, step by step, following the four-step sequence above, and draft the one or two sentences you would send to your (fictional) client contact to ask about extending the scope.

Your turn: evaluate a decision

A tester, mid-engagement, notices that the compromised machine they have access to can reach an internal address that was not listed in the scope document. Excited, they immediately run a full port scan against that internal address to see what is there, intending to mention it in the report afterwards. What should they have done instead, and why?

See a solution

They should have paused before scanning the new internal address, documented that it appears reachable from the compromised machine, and contacted the client to confirm whether this address could be added to the scope before testing it further. Running a full port scan against an address outside the authorised scope, even with good intentions and even if it is only "to see what is there", is exactly the scope-creep problem described in chapter 1, and in a real engagement it could constitute unauthorised access to a system the client never agreed to have tested, regardless of how the tester intended to describe it afterwards.

Chapter 4 is complete: you have gone from hypothesis to confirmed, documented, carefully scoped exploitation. Chapter 5 turns to a related and equally sensitive topic: passwords, hashes, and how access is gained and defended.