On-path attacks

Objective 4.1 in this course covers network attacks — VLAN hopping, on-path attacks and service exploitation. This is the second of the three. Everything here runs between two machines you own, in the lab from lesson 2.

Why this matters

An on-path attack — the position formerly described as man-in-the-middle — puts you between two parties who believe they are talking directly. It is the foundation under a great deal of Domain 4: credential capture for lesson 26, session theft, and the relay attacks that make lesson 25's material work.

It is also the technique where the gap between the classic teaching and current reality is widest, and the exam tests whether you know where that line now sits.

The lesson

Getting into the path: ARP, DHCP and rogue services

Several routes to the same position, all on your own lab segment:

• ARP spoofing. Address resolution has no authentication, so a host on the same segment can claim another host's address and receive its traffic. Simple, effective, and noisy — it disrupts the real mapping and is visible to anyone watching for it.
• Rogue DHCP. Answer a DHCP request faster than the real server and you set the client's default gateway and DNS. Cleaner than ARP spoofing because the client is configured to route through you deliberately.
• Name resolution poisoning. When a name does not resolve normally, many systems fall back to broadcast-based protocols that ask the local segment. Anything can answer. This is lesson 8's "protocols that answer strangers" turned into an attack, and it is the usual route into lesson 26's material.
• Rogue wireless access points, where the client associates with you believing you are the network.
• Physical insertion, which needs access but needs no protocol weakness.

All of these are local to a segment, which is the important limit: they are post-foothold techniques, which is why they sit in Domain 4 rather than Domain 2.

What is readable, and what TLS still protects

This is where careful thinking matters, because both the "everything is readable" and "TLS makes this pointless" positions are wrong.

In the path, without breaking encryption, you see: every endpoint a host talks to, the timing and volume of each conversation, the server name requested during TLS negotiation, certificate details, DNS queries unless encrypted, and the full content of anything not encrypted at all.

That last category is larger than clients expect on an internal network: management protocols, legacy applications, printing, some directory traffic, and plenty of internal web applications that never got TLS because "it's internal".

TLS still protects the content of properly-validated connections. You cannot read them by being in the path; you would have to make the client accept a certificate you control, which means either a trusted certificate authority (which you do not have) or a client that does not validate (which is itself the finding).

The examinable summary: being in the path gives you metadata about everything and content of whatever is unencrypted. The metadata alone is often enough to map an environment.

Downgrade and stripping, and where they fail today

Classic techniques worth knowing, along with why they work less well now.

Stripping sits between a client and server, keeping an encrypted connection to the server and an unencrypted one to the client, so the user's traffic is readable while the server sees normal TLS. It worked when users typed bare hostnames and were redirected to the secure site.

What broke it:

• Strict transport security, which instructs a client to use encryption for a domain in future, so there is no plaintext first request to intercept.
• Preload lists shipped with browsers, which apply that from the first ever visit.
• Clear browser warnings that users are far less willing to click through than they were.

Protocol downgrade negotiates a weaker version or cipher. Modern stacks refuse the weak options, and negotiation protections detect tampering.

Where they still work: internal applications without transport security, non-browser clients that validate poorly, embedded devices, and anything using a protocol that starts in plaintext and upgrades. Which is why they remain worth testing on an internal engagement even though the internet-facing case has largely closed.

Detection: what this looks like to the defender

This belongs in every Domain 4 lesson, because Domain 5 asks you to explain what the client's defences saw — and because knowing the signal is how you write a remediation worth acting on.

An on-path attack is noisy:

• ARP spoofing produces conflicting mappings and a burst of gratuitous replies; monitoring and dynamic inspection detect it directly.
• Rogue DHCP produces two servers answering, which is trivially detectable and is what DHCP snooping exists to stop.
• Name resolution poisoning appears as a host answering broadcast queries for names it has no business owning.
• Certificate mismatches generate client-side errors and, where certificate monitoring exists, alerts.

So the report writes itself in two halves: here is what I did, and here is what your monitoring did and did not show. If nothing fired, the detection gap is a finding at least as important as the network one.

Running it only between two machines you own

The rule for this lesson, and the reason it is stated plainly rather than assumed.

On-path attacks are indiscriminate by nature. ARP spoofing a segment affects every host on it. A rogue DHCP server answers whoever asks, not whoever you intended. Poisoning name resolution catches every query that misses. There is no careful version that touches only your target.

Which means:

• In the lab, both endpoints are machines you built. The segment is the isolated one from lesson 2 with no route anywhere real.
• On an engagement, these techniques need explicit scope permission naming them, because they will affect hosts that are not your target and can disrupt service for real users. This is exactly the category lesson 3 says must be written down in advance.
• Never on a network you do not own, including shared ones — a café, a conference, an office you are visiting. There is no read-only version.

The honest framing for a client: this technique demonstrates a real risk and it is disruptive to demonstrate, so we agree the window and the blast radius before it happens, or we report the conditions that make it possible without running it. The second option is often the right one, and a finding that the segment permits it is defensible without the demonstration.

What to take into the exam

• ARP spoofing, rogue DHCP, name-resolution poisoning, rogue access points and physical insertion all reach the same position, and all are segment-local.
• In the path you get metadata about everything and content of whatever is unencrypted; TLS content stays protected unless the client fails to validate.
• Stripping and downgrade are largely closed on the internet by strict transport security and preload lists, and remain live internally.
• These attacks are noisy and detectable; if nothing fired, the detection gap is a finding.
• They are indiscriminate, so they need explicit scope permission or should be reported as a condition rather than demonstrated.