Trick 1: "HTTPS encryption prevents on-path attacks — an attacker positioned between a client and a web server cannot read the traffic because it's encrypted." True or False?
FALSE — HTTPS prevents a network-layer on-path attacker from reading data in transit, but it does not prevent all on-path attacks, and it provides no protection against on-path browser attacks.
This is one of the most tested nuances in this chapter. The statement contains a half-truth that makes it sound completely true.
What HTTPS does protect against:
If an attacker performs ARP poisoning and positions themselves at the network layer between a client and a server, the traffic flowing through them is TLS-encrypted ciphertext. Without the session keys, the attacker sees random bytes. HTTPS does make network-layer interception of the content impractical, which is a real and important protection.
What HTTPS does NOT protect against:
An on-path browser attack operates entirely inside the victim's device — above the TLS layer. The malware intercepts data before TLS encrypts it (outbound) and after TLS decrypts it (inbound). From the network's perspective, the HTTPS traffic is perfectly normal. The certificate is valid. The connection is genuine. The attacker (the malware) sees plaintext because it's sitting on the inside of the encrypted tunnel, not the outside.
Additionally, SSL stripping attacks can be used to downgrade HTTPS to HTTP in some scenarios, undermining the protection if HSTS is not implemented.
Exam tip: When a question says "the user's traffic was encrypted with HTTPS — was this a defense against the attack?", the correct answer depends on which attack. For a network-layer ARP poisoning attack targeting content: yes, HTTPS limits what the attacker sees. For an on-path browser attack: no, HTTPS is irrelevant because the attack happens before the encryption layer.
This is one of the most tested nuances in this chapter. The statement contains a half-truth that makes it sound completely true.
What HTTPS does protect against:
If an attacker performs ARP poisoning and positions themselves at the network layer between a client and a server, the traffic flowing through them is TLS-encrypted ciphertext. Without the session keys, the attacker sees random bytes. HTTPS does make network-layer interception of the content impractical, which is a real and important protection.
What HTTPS does NOT protect against:
An on-path browser attack operates entirely inside the victim's device — above the TLS layer. The malware intercepts data before TLS encrypts it (outbound) and after TLS decrypts it (inbound). From the network's perspective, the HTTPS traffic is perfectly normal. The certificate is valid. The connection is genuine. The attacker (the malware) sees plaintext because it's sitting on the inside of the encrypted tunnel, not the outside.
Additionally, SSL stripping attacks can be used to downgrade HTTPS to HTTP in some scenarios, undermining the protection if HSTS is not implemented.
Exam tip: When a question says "the user's traffic was encrypted with HTTPS — was this a defense against the attack?", the correct answer depends on which attack. For a network-layer ARP poisoning attack targeting content: yes, HTTPS limits what the attacker sees. For an on-path browser attack: no, HTTPS is irrelevant because the attack happens before the encryption layer.
Trick 2: "ARP poisoning can be performed from anywhere on the internet — an attacker does not need to be physically on the same network as the targets." True or False?
FALSE — ARP poisoning requires the attacker to be on the same Layer 2 subnet as both victims. ARP frames cannot cross router boundaries.
This misconception often comes from conflating on-path attacks in general (which can sometimes be conducted remotely) with ARP poisoning specifically (which is a local network attack).
Why ARP is local-only:
ARP is a Layer 2 protocol. ARP frames — like all Layer 2 frames — are not routable. Routers forward IP packets; they do not forward ARP frames. An ARP broadcast sent on the 192.168.1.0/24 subnet will be received by every device on that subnet and by no device outside it. A router terminates the Layer 2 domain — the ARP frame stops at the router interface.
An attacker on 10.0.0.5 cannot send an ARP reply to a device on 192.168.1.9. The frame has nowhere to go — the intermediate router won't pass it. The attacker must have an IP on the target subnet to reach those devices at Layer 2.
Implication for defense:
This is why network segmentation is such an effective defense against ARP poisoning. By dividing the network into separate VLANs and subnets, you ensure that an attacker who compromises or places a device in one segment cannot reach (and therefore cannot ARP-poison) devices in other segments. A flat network where everything shares the same subnet gives every device the ability to ARP-poison every other device.
Exam tip: Any answer choice that says ARP poisoning "can be conducted from a remote network" or "does not require local access" is wrong. ARP poisoning is always a local subnet attack.
This misconception often comes from conflating on-path attacks in general (which can sometimes be conducted remotely) with ARP poisoning specifically (which is a local network attack).
Why ARP is local-only:
ARP is a Layer 2 protocol. ARP frames — like all Layer 2 frames — are not routable. Routers forward IP packets; they do not forward ARP frames. An ARP broadcast sent on the 192.168.1.0/24 subnet will be received by every device on that subnet and by no device outside it. A router terminates the Layer 2 domain — the ARP frame stops at the router interface.
An attacker on 10.0.0.5 cannot send an ARP reply to a device on 192.168.1.9. The frame has nowhere to go — the intermediate router won't pass it. The attacker must have an IP on the target subnet to reach those devices at Layer 2.
Implication for defense:
This is why network segmentation is such an effective defense against ARP poisoning. By dividing the network into separate VLANs and subnets, you ensure that an attacker who compromises or places a device in one segment cannot reach (and therefore cannot ARP-poison) devices in other segments. A flat network where everything shares the same subnet gives every device the ability to ARP-poison every other device.
Exam tip: Any answer choice that says ARP poisoning "can be conducted from a remote network" or "does not require local access" is wrong. ARP poisoning is always a local subnet attack.
Trick 3: "If a network analyst runs 'arp -a' on a device and sees some duplicate MAC addresses — two different IP addresses mapped to the same MAC — this is definitive proof of an ARP poisoning attack in progress." True or False?
FALSE (mostly) — duplicate MACs in an ARP table are strong indicators of ARP poisoning but are not definitive proof by themselves, because some legitimate configurations produce the same pattern.
This is a precision question. The exam may ask you to interpret ARP cache evidence correctly without overclaiming certainty.
Why duplicate MACs strongly suggest ARP poisoning:
Under normal network operation, each IP address corresponds to exactly one physical device with its own unique MAC. If 192.168.1.1 (the router) and 192.168.1.14 (some other device) both show the same MAC in your ARP cache, one of them has been poisoned — either the gateway entry was overwritten with the attacker's MAC, or vice versa.
Legitimate scenarios that produce duplicate MACs:
(1) Virtual machines and containers — a hypervisor host may serve traffic for multiple VMs using shared MAC addresses or MAC aliases; (2) Load balancers — some load balancers use the same virtual MAC across multiple IP addresses in a cluster; (3) VRRP/HSRP (router redundancy protocols) — a virtual IP shared between two physical routers may create what appears to be a duplicate MAC situation. These are unusual configurations but not attack scenarios.
Correct exam framing:
Duplicate MACs in an ARP table are a red flag that warrants investigation. Combined with other evidence (unexpected ARP traffic in a packet capture, unexplained access to sensitive data, devices appearing on the network without authorization), it's strong evidence of ARP poisoning. By itself, it's an indicator to investigate, not a confirmed verdict.
Exam tip: If a question presents duplicate MACs and asks "what does this indicate?", the correct answer is "possible ARP poisoning warranting investigation" rather than "confirmed ARP poisoning attack." Watch for answer choices that assert certainty versus those that indicate a likely concern.
This is a precision question. The exam may ask you to interpret ARP cache evidence correctly without overclaiming certainty.
Why duplicate MACs strongly suggest ARP poisoning:
Under normal network operation, each IP address corresponds to exactly one physical device with its own unique MAC. If 192.168.1.1 (the router) and 192.168.1.14 (some other device) both show the same MAC in your ARP cache, one of them has been poisoned — either the gateway entry was overwritten with the attacker's MAC, or vice versa.
Legitimate scenarios that produce duplicate MACs:
(1) Virtual machines and containers — a hypervisor host may serve traffic for multiple VMs using shared MAC addresses or MAC aliases; (2) Load balancers — some load balancers use the same virtual MAC across multiple IP addresses in a cluster; (3) VRRP/HSRP (router redundancy protocols) — a virtual IP shared between two physical routers may create what appears to be a duplicate MAC situation. These are unusual configurations but not attack scenarios.
Correct exam framing:
Duplicate MACs in an ARP table are a red flag that warrants investigation. Combined with other evidence (unexpected ARP traffic in a packet capture, unexplained access to sensitive data, devices appearing on the network without authorization), it's strong evidence of ARP poisoning. By itself, it's an indicator to investigate, not a confirmed verdict.
Exam tip: If a question presents duplicate MACs and asks "what does this indicate?", the correct answer is "possible ARP poisoning warranting investigation" rather than "confirmed ARP poisoning attack." Watch for answer choices that assert certainty versus those that indicate a likely concern.
Trick 4: "An on-path browser attack and a traditional on-path (ARP poisoning) attack both require the attacker to be on the same network as the victim." True or False?
FALSE — ARP poisoning requires the attacker to be on the same local subnet, but an on-path browser attack requires no physical network proximity at all.
This trick exploits the naming similarity between the two attacks to confuse their operational requirements.
ARP poisoning — local subnet required:
ARP poisoning is a Layer 2 attack. The attacker must be on the same subnet as both victims because ARP frames don't cross routers. The attacker needs physical or logical local network access. They connect a device to the target network (via a physical port, Wi-Fi, or compromised internal device).
On-path browser attack — no proximity required:
The on-path browser attack is a malware delivery problem. The attacker distributes the browser-hooking Trojan via phishing emails, drive-by downloads, or fake software updates — any remote delivery mechanism that reaches the victim's device. The attacker never needs to be on the victim's network. The victim can be anywhere in the world — on a corporate network, home network, coffee shop Wi-Fi — and the attack works identically because it operates inside the victim's browser, not at the network layer.
Different attack surfaces, different defenses:
ARP poisoning → defend at the network layer (DAI, segmentation, 802.1X). On-path browser attack → defend at the endpoint layer (endpoint protection, patching, user education). Mixing up which defense addresses which attack is exactly what the exam tests.
Exam tip: When a question describes an attacker who is "on the victim's network" performing an on-path attack, that's likely ARP poisoning. When a question describes an attacker using HTTPS and the attack originates from within the victim's own device, that's the browser variant. The key differentiator is where the attacker is physically located relative to the victim.
This trick exploits the naming similarity between the two attacks to confuse their operational requirements.
ARP poisoning — local subnet required:
ARP poisoning is a Layer 2 attack. The attacker must be on the same subnet as both victims because ARP frames don't cross routers. The attacker needs physical or logical local network access. They connect a device to the target network (via a physical port, Wi-Fi, or compromised internal device).
On-path browser attack — no proximity required:
The on-path browser attack is a malware delivery problem. The attacker distributes the browser-hooking Trojan via phishing emails, drive-by downloads, or fake software updates — any remote delivery mechanism that reaches the victim's device. The attacker never needs to be on the victim's network. The victim can be anywhere in the world — on a corporate network, home network, coffee shop Wi-Fi — and the attack works identically because it operates inside the victim's browser, not at the network layer.
Different attack surfaces, different defenses:
ARP poisoning → defend at the network layer (DAI, segmentation, 802.1X). On-path browser attack → defend at the endpoint layer (endpoint protection, patching, user education). Mixing up which defense addresses which attack is exactly what the exam tests.
Exam tip: When a question describes an attacker who is "on the victim's network" performing an on-path attack, that's likely ARP poisoning. When a question describes an attacker using HTTPS and the attack originates from within the victim's own device, that's the browser variant. The key differentiator is where the attacker is physically located relative to the victim.
Performance Task: You are a security consultant for a mid-sized financial services firm. The firm reports that three employees in the same open-plan office area have experienced unauthorized transactions on their corporate expense accounts over the past two weeks. All three accounts used two-factor authentication. IT has confirmed the accounts were accessed using valid session tokens from the employees' own workstation IP addresses. Network monitoring shows only normal HTTPS traffic. The employees share the same floor, same VLAN, and are all connected to the same managed switch. No endpoint protection alerts have fired. Describe your investigation methodology, how you would distinguish between an ARP poisoning attack, an on-path browser attack, and a social engineering/credential theft scenario, and your remediation for each possible finding.
Model Answer:
Initial Observation — What the Evidence Already Tells You:
The pattern has critical diagnostic clues before any investigation begins: (1) valid session tokens from the victims' own IPs — rules out simple credential theft with replay from an external IP; the attacker is using active sessions on the victims' machines or devices on their IP; (2) 2FA was in place — rules out simple password theft; the attacker had access after 2FA, meaning either the active session was stolen post-authentication or the device itself was compromised; (3) all three victims are on the same VLAN/switch — same subnet, making local network attacks possible; (4) normal HTTPS traffic — no obvious network anomalies.
Scenario A Investigation — ARP Poisoning:
Check the ARP caches on all three workstations:
Run a packet capture on the switch's span/mirror port during a test window. Apply filter
Check the managed switch's DAI logs (if DAI is enabled — and if it isn't enabled on a financial services network, that itself is a finding). DAI drop logs showing rejected ARP packets from a specific port would pinpoint the attacking device's switch port immediately.
What would rule out ARP poisoning: Clean ARP caches with correct MAC for the gateway on all three machines; no anomalous ARP traffic in the packet capture; sessions were stolen after HTTPS connection was established (attacker would see only ciphertext even if on-path at the network layer).
Scenario B Investigation — On-Path Browser Attack:
Perform endpoint analysis on all three workstations: (1) Check installed browser extensions — any unrecognized, recently installed, or unusually privileged extension is a red flag; (2) Check running processes for known browser-hooking malware signatures; (3) Review browser history and session logs for evidence of background requests the user didn't initiate; (4) Check system startup items and scheduled tasks for persistence mechanisms; (5) Run an updated endpoint security scan with behavioral detection enabled (not just signature-based — browser-hooking malware may evade signature detection).
Key indicator: all three machines being compromised suggests a common delivery mechanism — likely a phishing email sent to the team, or a shared internal resource that was compromised. Review email logs for a common phishing email received by all three in the past 2–3 weeks.
What would rule out browser attack: Clean endpoint analysis with no malware, unrecognized extensions, or suspicious processes. Browser attacks leave artifacts inside the browser process and filesystem.
Scenario C — Social Engineering / Insider Threat:
If both network-layer and endpoint analysis come back clean: review whether the victims shared their screen or credentials during this period; check CCTV or physical access logs for whether an unauthorized person had physical access to the workstations; review whether the firm's expense platform had a session replay vulnerability allowing session tokens to be captured through a different vector; investigate whether one of the three employees may themselves be the threat actor submitting expense fraud.
Remediation by Scenario:
If ARP Poisoning:
(1) Enable Dynamic ARP Inspection on the managed switch immediately — this is the direct technical fix; (2) Configure DHCP snooping to build the binding table DAI requires; (3) Identify and isolate the switch port the attacking device was connected to; (4) If the attacker was a connected employee device, initiate HR/legal process; (5) Consider 802.1X port authentication to prevent unauthorized devices from connecting; (6) Review whether sessions captured through the on-path position were used — if the expense system transmits session tokens in cookies, those tokens should be invalidated.
If On-Path Browser Attack:
(1) Isolate and reimage all three affected workstations; (2) Revoke and reissue all authentication tokens for affected accounts; (3) Enable out-of-band transaction approval (SMS or separate app confirmation) for expense submissions; (4) Identify the phishing email or delivery mechanism and block it at the email gateway; (5) Implement application allowlisting to prevent unauthorized browser extensions from running; (6) Conduct user awareness training focused on phishing recognition for the affected team.
On the 2FA question:
2FA protected against password theft but not against session token theft. Once the user has authenticated (including 2FA), the session token represents a valid authenticated session. An on-path attacker — whether at the network layer or inside the browser — who captures that session token can reuse it without knowing the password or 2FA code. 2FA is essential but is not a defense against post-authentication session token theft. The correct countermeasure is short session token lifetimes, binding session tokens to the originating IP, and out-of-band transaction confirmation.
Initial Observation — What the Evidence Already Tells You:
The pattern has critical diagnostic clues before any investigation begins: (1) valid session tokens from the victims' own IPs — rules out simple credential theft with replay from an external IP; the attacker is using active sessions on the victims' machines or devices on their IP; (2) 2FA was in place — rules out simple password theft; the attacker had access after 2FA, meaning either the active session was stolen post-authentication or the device itself was compromised; (3) all three victims are on the same VLAN/switch — same subnet, making local network attacks possible; (4) normal HTTPS traffic — no obvious network anomalies.
Scenario A Investigation — ARP Poisoning:
Check the ARP caches on all three workstations:
arp -a (Windows) or ip neigh (Linux). Look for duplicate MAC addresses — specifically, whether the gateway IP (default router) maps to an unexpected MAC. Compare across all three machines; they should all show the same gateway MAC. If one machine shows a different MAC for the gateway, or if all three show a MAC that doesn't belong to the router, ARP poisoning is indicated.Run a packet capture on the switch's span/mirror port during a test window. Apply filter
arp in Wireshark. Look for: gratuitous ARP replies arriving without corresponding requests; high-volume ARP traffic; a single MAC address claiming to be the gateway; ARP replies that change the gateway's MAC address from the legitimate value.Check the managed switch's DAI logs (if DAI is enabled — and if it isn't enabled on a financial services network, that itself is a finding). DAI drop logs showing rejected ARP packets from a specific port would pinpoint the attacking device's switch port immediately.
What would rule out ARP poisoning: Clean ARP caches with correct MAC for the gateway on all three machines; no anomalous ARP traffic in the packet capture; sessions were stolen after HTTPS connection was established (attacker would see only ciphertext even if on-path at the network layer).
Scenario B Investigation — On-Path Browser Attack:
Perform endpoint analysis on all three workstations: (1) Check installed browser extensions — any unrecognized, recently installed, or unusually privileged extension is a red flag; (2) Check running processes for known browser-hooking malware signatures; (3) Review browser history and session logs for evidence of background requests the user didn't initiate; (4) Check system startup items and scheduled tasks for persistence mechanisms; (5) Run an updated endpoint security scan with behavioral detection enabled (not just signature-based — browser-hooking malware may evade signature detection).
Key indicator: all three machines being compromised suggests a common delivery mechanism — likely a phishing email sent to the team, or a shared internal resource that was compromised. Review email logs for a common phishing email received by all three in the past 2–3 weeks.
What would rule out browser attack: Clean endpoint analysis with no malware, unrecognized extensions, or suspicious processes. Browser attacks leave artifacts inside the browser process and filesystem.
Scenario C — Social Engineering / Insider Threat:
If both network-layer and endpoint analysis come back clean: review whether the victims shared their screen or credentials during this period; check CCTV or physical access logs for whether an unauthorized person had physical access to the workstations; review whether the firm's expense platform had a session replay vulnerability allowing session tokens to be captured through a different vector; investigate whether one of the three employees may themselves be the threat actor submitting expense fraud.
Remediation by Scenario:
If ARP Poisoning:
(1) Enable Dynamic ARP Inspection on the managed switch immediately — this is the direct technical fix; (2) Configure DHCP snooping to build the binding table DAI requires; (3) Identify and isolate the switch port the attacking device was connected to; (4) If the attacker was a connected employee device, initiate HR/legal process; (5) Consider 802.1X port authentication to prevent unauthorized devices from connecting; (6) Review whether sessions captured through the on-path position were used — if the expense system transmits session tokens in cookies, those tokens should be invalidated.
If On-Path Browser Attack:
(1) Isolate and reimage all three affected workstations; (2) Revoke and reissue all authentication tokens for affected accounts; (3) Enable out-of-band transaction approval (SMS or separate app confirmation) for expense submissions; (4) Identify the phishing email or delivery mechanism and block it at the email gateway; (5) Implement application allowlisting to prevent unauthorized browser extensions from running; (6) Conduct user awareness training focused on phishing recognition for the affected team.
On the 2FA question:
2FA protected against password theft but not against session token theft. Once the user has authenticated (including 2FA), the session token represents a valid authenticated session. An on-path attacker — whether at the network layer or inside the browser — who captures that session token can reuse it without knowing the password or 2FA code. 2FA is essential but is not a defense against post-authentication session token theft. The correct countermeasure is short session token lifetimes, binding session tokens to the originating IP, and out-of-band transaction confirmation.