AP Cybersecurity 3.2: Network Attacks
Topic 3.2: Network Attacks
How attackers exploit protocol weaknesses to deny service, intercept communications, poison address resolution, and redirect traffic — and exactly which OSI layer and CIA property each attack targets.
- 3.2.1 — Learning Objectives(3 min)
- 3.2.2 — Attack Taxonomy: Classifying Network Attacks(7 min)
- 3.2.3 — Essential Vocabulary & Exam Tips(10 min)
- 3.2.4 — DoS and DDoS In Depth(12 min)
- 3.2.5 — Man-in-the-Middle Attacks In Depth(10 min)
- 3.2.6 — ARP Poisoning & DNS Spoofing In Depth(10 min)
- 3.2.7 — Real-World Case Studies(8 min)
- 3.2.8 — Defense Strategies(6 min)
- 3.2.9 — Worked Examples: Predict First(5 min)
- 3.2.10 — AP Exam Strategy(5 min)
- 3.2.11 — Frequently Asked Questions(3 min)
13.2.1 — Learning Objectives
By the end of this lesson, you will be able to:
- Classify network attacks by their goal (Availability, Confidentiality, or Integrity violation) and the OSI layer at which they primarily operate
- Distinguish between DoS and DDoS attacks, explain the mechanism of SYN floods, UDP floods, and volumetric attacks, and identify the defenses for each
- Explain how a man-in-the-middle attack works, describe the two phases (interception and optional modification), and identify the attacks that enable MitM positioning
- Describe ARP poisoning in detail — how it works, what it enables, which OSI layer it operates at, and how Dynamic ARP Inspection prevents it
- Explain DNS spoofing and DNS cache poisoning, describe how they redirect traffic, and identify DNSSEC as the primary mitigation
- Define replay attacks, explain why they require timestamping or nonces to prevent, and distinguish them from real-time interception attacks
- Apply network attack knowledge to Vantex Financial Group scenarios in exercises and labs throughout Unit 3
- Recognize and avoid the four most common AP exam traps on network attack questions
23.2.2 — Attack Taxonomy: Classifying Network Attacks
Every network attack has three classifiable dimensions: the goal (which CIA property it violates), the mechanism (what protocol weakness it exploits), and the OSI layer (where it operates). Classifying an attack along all three dimensions tells you which control is needed and where to place it.
| Attack | OSI Layer | CIA Primary | Mechanism | Primary Defense |
|---|---|---|---|---|
| SYN FloodL4 | Transport | Availability | Sends thousands of TCP SYN packets without completing the handshake, filling the server’s half-open connection table until legitimate connections are refused. | SYN cookies (server generates no state until handshake completes); rate limiting; firewall SYN flood protection |
| UDP FloodL4 | Transport | Availability | Floods target with high-volume UDP packets on random ports, overwhelming bandwidth and processing. Target spends resources sending “Destination Unreachable” ICMP replies. | Rate limiting; ingress filtering blocking spoofed source IPs; DDoS mitigation services |
| DNS AmplificationL3/L7 | Network/App | Availability | Attacker sends small DNS queries with spoofed source IP (victim’s address) to open DNS resolvers. Large DNS responses flood the victim from many distributed resolvers. | Disable open DNS resolvers; DNS response rate limiting (RRL); BCP38 ingress filtering to block spoofed IPs |
| ARP PoisoningL2 | Data Link | Confidentiality Integrity | Sends forged ARP replies associating attacker’s MAC with another device’s IP. Traffic meant for that device is redirected to attacker (enables MitM). | Dynamic ARP Inspection (DAI); static ARP entries for critical devices; 802.1X port-based authentication |
| DNS SpoofingL7 | Application | Confidentiality Integrity | Forges DNS responses to redirect users to attacker-controlled IP addresses. Victims believe they are visiting a legitimate site. Enables phishing and credential harvesting. | DNSSEC (cryptographic validation of DNS records); DNS-over-HTTPS (DoH); client-side certificate validation |
| Man-in-the-MiddleL2–7 | Multiple | Confidentiality Integrity | Attacker positions themselves between two communicating parties, intercepting and potentially modifying traffic. Enabled by ARP poisoning, rogue AP, or DNS spoofing. | TLS/HTTPS (encrypts data in transit); certificate pinning; MFA (prevents credential reuse after capture) |
| Replay AttackL4–7 | Transport/App | Confidentiality Integrity | Captures a valid authentication token or transaction and retransmits it later to impersonate the original sender or duplicate the transaction. | Timestamps with short expiry windows; nonces (single-use random values); sequence numbers; TLS session tokens |
| IP SpoofingL3 | Network | Confidentiality Availability | Crafts packets with a forged source IP address. Used to hide attacker identity, amplify DoS traffic, or bypass IP-based access controls. | BCP38 ingress filtering (ISP-level); stateful firewalls that validate source IPs; uRPF (Unicast Reverse Path Forwarding) |
This technique is called:
• Identify the four CED network attack types: ARP poisoning (on-path/MitM), MAC flooding (eavesdropping/sniffing), DNS poisoning (credential harvesting), Smurf attack (DoS/DDoS)
• Classify each attack by CIA property violated: ARP = Confidentiality + Integrity; MAC flooding = Confidentiality; DNS poisoning = Integrity + Confidentiality; Smurf = Availability
• Explain rogue access points: adversary plugs WAP into open network port, bypassing all firewalls, gaining LAN access from outside physical space
• Recognize that port security prevents MAC flooding by limiting MAC addresses per switch port
• Explain DoS vs. DDoS distinction and why ICMP-based smurf attacks are a broadcast amplification attack
Topic 3.2 / CED 3.1 Attacks — What Is Testable
| CED Ref | Essential Knowledge | Covered In |
|---|---|---|
| 3.1.A.1 | ARP poisoning: adversary sends falsified ARP packets to link target’s IP to adversary’s MAC address → adversary receives target’s traffic. This is an on-path (MitM) attack. MAC spoofing = faking a MAC address. | Section 2 — ARP Poisoning |
| 3.1.A.2 | MAC flooding: adversary sends many Ethernet frames with different MACs to a switch, forcing it into broadcast mode → adversary collects all frames. This is eavesdropping/sniffing. | Section 3 — MAC Flooding |
| 3.1.A.3 | DNS poisoning: adversary pretends to be authoritative NS and plants fake DNS record → redirects traffic to malicious credential-harvesting site (fake login page that captures real credentials) | Section 4 — DNS Poisoning |
| 3.1.A.4 | Smurf attack: adversary sends ICMP requests with victim’s address to broadcast address → all network devices reply to victim, creating traffic flood (DoS). Multiple attacking devices = DDoS. | Section 5 — Smurf / DoS / DDoS |
| 3.1.B.3 | Port security prevents adversaries from gaining LAN access by plugging into exposed data ports | Section 3 — Port Security Defense |
| 3.1.B.6 | Open network port → adversary can plug in a rogue WAP, gaining wireless LAN access that bypasses firewalls from outside the physical space | Section 6 — Rogue Access Points |
| 3.1.B.7 | Adversaries can attempt to break wireless encryption and intercept, steal, or compromise data on a network | Section 6 — Wireless Attacks |
Source: AP Cybersecurity CED Effective Fall 2026. AP Skills: 1.A Identify threats • 1.C Evaluate risk • 1.D Document risks
Answer independently. No notes.
- A network administrator notices the ARP table on the default gateway shows the same IP address mapped to two different MAC addresses. What attack does this indicate, how does it work, and which OSI layer does it target?
- Users report that the company website is redirecting them to a fake login page that looks identical to the real one. After logging in, their credentials are compromised. What network attack is this, and what did the adversary do to the network?
- A smurf attack is underway. Describe exactly what the adversary does and why it causes a flood of traffic at the victim’s address. Why is this classified as a DoS attack?
Answers: (1) ARP poisoning (3.1.A.1) — adversary sent falsified ARP packets linking the victim’s IP to their own MAC, so they receive the victim’s traffic. Data link layer (Layer 2). (2) DNS poisoning (3.1.A.3) — adversary planted a fake DNS record redirecting the domain to a credential-harvesting site. (3) Adversary sends ICMP requests with victim’s spoofed source address to the network broadcast address → all devices on the network reply to victim, flooding it. DoS because it makes the network resource unavailable to authorized users.
33.2.3 — Essential Vocabulary & Exam Tips
| Term | Definition | Exam Trap / Critical Distinction |
|---|---|---|
| DoS (Denial of Service) | An attack that makes a system, service, or network unavailable to authorized users. Originates from a single source. Easier to defend because blocking one IP address stops the attack. | TRAP DoS = one source. DDoS = many sources. When the exam describes an attack from a single compromised host, it is DoS. When it describes a botnet or “thousands of sources,” it is DDoS. The CIA violation is Availability in both cases. |
| DDoS (Distributed DoS) | A DoS attack using many distributed sources — typically a botnet of compromised machines. The distributed nature makes source-IP blocking ineffective since there are thousands of attacker IPs. | KEY DDoS requires a botnet or coordination across multiple systems. The difficulty of defending against DDoS (vs. DoS) lies specifically in the distributed nature: blocking one source does nothing when 10,000 others continue the attack. |
| Botnet | A network of internet-connected devices (computers, IoT devices, routers) infected with malware and controlled by an attacker without the device owners’ knowledge. Used to execute DDoS attacks, send spam, and mine cryptocurrency. | NOTE Botnet devices are typically compromised through malware, not through the attacker’s own systems. The device owners are unwitting participants. The Mirai botnet (used in the 2016 Dyn attack) specifically targeted IoT devices with default credentials. |
| SYN Flood | A DoS/DDoS attack that exploits the TCP three-way handshake. Attacker sends many TCP SYN packets but never sends the final ACK. Server allocates resources for each half-open connection until the connection table is full and it can no longer accept legitimate connections. | KEY SYN flood targets Layer 4 (Transport) by exploiting TCP’s connection-oriented design. Defense: SYN cookies allow the server to avoid allocating state until the handshake completes, rendering the attack ineffective. |
| Man-in-the-Middle (MitM) | An attack where the attacker secretly intercepts communications between two parties, who believe they are communicating directly. Can be passive (eavesdrop only) or active (modify traffic). Requires first achieving a position between the two parties. | KEY MitM is a two-phase attack: (1) interception — getting traffic to flow through the attacker; (2) active manipulation (optional). ARP poisoning and rogue APs are the most common interception methods. MitM primarily violates Confidentiality (eavesdropping) and potentially Integrity (modification). |
| ARP Poisoning / Spoofing | Sending forged ARP reply packets that associate the attacker’s MAC address with a legitimate IP address (e.g., the default gateway). Devices update their ARP caches with the false mapping and begin sending traffic to the attacker. | KEY ARP poisoning is a Layer 2 attack (ARP operates on the Data Link layer). It is confined to the local network segment (same subnet). Defense: Dynamic ARP Inspection (DAI) validates ARP packets against a DHCP snooping table. |
| DNS Spoofing / Cache Poisoning | Inserting forged DNS records into a resolver’s cache, causing it to return incorrect IP addresses for legitimate domain names. Users are redirected to attacker-controlled servers while believing they are visiting legitimate sites. | KEY DNS spoofing targets Layer 7 (Application). The attack is invisible to the user — the URL in their browser looks correct. Defense: DNSSEC adds cryptographic signatures that allow resolvers to verify DNS responses have not been tampered with. |
| Replay Attack | Capturing a valid data transmission (authentication token, session cookie, signed message) and retransmitting it at a later time to impersonate the original sender or repeat the original action. | KEY Replay attacks are prevented by making captured tokens time-limited or single-use: timestamps (token is only valid for 30 seconds), nonces (a random number used only once), or sequence numbers. TLS session tokens change with every session to prevent replay. |
| SSL Stripping | A MitM attack where the attacker intercepts an HTTPS connection attempt and downgrades it to HTTP, then maintains an encrypted connection with the server while presenting unencrypted HTTP to the victim. The victim sees HTTP in their browser but believes the connection is secure. | KEY SSL stripping is prevented by HTTP Strict Transport Security (HSTS), which tells browsers to always use HTTPS for a domain regardless of any protocol downgrade attempts. Browsers that have previously seen an HSTS header will refuse to connect over HTTP. |
| Smurf Attack | A DDoS amplification attack that sends ICMP echo-request (ping) packets with the victim’s spoofed IP to a network broadcast address. All devices on that network reply to the victim, amplifying the attack traffic. | NOTE Smurf attacks are largely mitigated by modern routers that ignore directed broadcast requests. However, the concept (amplification via broadcast/multicast) still appears on AP exams to test understanding of IP spoofing and amplification mechanics. |
Match each attack to Disruption, Interception, or Manipulation.
43.2.4 — DoS and DDoS In Depth
Denial of Service attacks are the most straightforward in concept — overwhelm a target with traffic or requests until legitimate users cannot be served — but the most challenging in practice, because the attacker’s resources for generating attack traffic can vastly exceed a target’s capacity to absorb it. A botnet of 100,000 compromised IoT devices can generate terabytes of traffic per second; very few organizations can absorb that at their perimeter.
3.2.4a — DoS Attack Taxonomy
| Attack Type | Mechanism | Target | Key Characteristic |
|---|---|---|---|
| Volumetric Attack | Floods network bandwidth with massive traffic volumes. Target’s internet pipe is saturated — legitimate traffic cannot get through even if the servers are fine. | Network bandwidth (L3/L4) | Measured in gigabits or terabits per second. Amplification attacks (DNS, NTP, memcached) multiply small attack traffic into massive volumetric floods. Defense requires upstream scrubbing. |
| Protocol Attack (SYN Flood) | Exploits weaknesses in network protocol implementation. SYN flood consumes server connection table resources, not bandwidth. A relatively modest attack can take down a large server. | Server connection tables, firewall state tables (L4) | Does not require large bandwidth. Even a single attacker with a modest connection can execute a SYN flood. Defense: SYN cookies; reducing TCP backlog queue timeout; rate limiting SYN packets. |
| Application Layer Attack | Targets application-layer resources. HTTP flood sends legitimate-looking HTTP GET or POST requests at high volume, exhausting web server threads, database connections, or application processing capacity. | Web servers, application servers (L7) | Traffic looks legitimate to network-layer defenses (it is real HTTP requests). Requires application-aware inspection to distinguish attack traffic from legitimate user requests. WAF rules and rate limiting help. |
3.2.4b — SYN Flood: The TCP Handshake Exploit
SYN Flood Attack Anatomy
3.2.4c — Amplification Attacks: Turning Small Packets into Floods
Amplification attacks are a particularly powerful DDoS technique that uses publicly accessible services with high response-to-query ratios to amplify small attacker traffic into massive victim floods. The attacker spoofs the victim’s IP as the source, causing all amplified responses to flood the victim.
| Protocol | Port | Amplification Factor | Mechanism |
|---|---|---|---|
| DNS | UDP/53 | 28–54x (up to 179x with DNSSEC records) | Small DNS ANY query (~60 bytes) returns large response with all record types (~3,300 bytes). Attacker sends query with victim’s spoofed IP; large response floods victim. |
| NTP | UDP/123 | Up to 556x | NTP monlist command returns the last 600 clients that queried the server. Small monlist request (~40 bytes) returns large list response (~48,000 bytes). Used in the 2014 Cloudflare attack (400 Gbps). |
| Memcached | UDP/11211 | Up to 51,000x | In-memory caching system. An attacker stores large data in a public memcached server, then queries it with the victim’s spoofed IP. Tiny query (15 bytes) returns enormous cached payload. Used in the 2018 GitHub attack (1.3 Tbps — largest DDoS recorded at the time). |
This attack is called:
53.2.5 — Man-in-the-Middle Attacks In Depth
A man-in-the-middle attack is one of the most powerful network attack classes because it can simultaneously violate both Confidentiality (the attacker reads all traffic) and Integrity (the attacker can modify traffic in transit). Unlike DoS attacks which are noisy and immediately visible, a well-executed passive MitM attack may go undetected for months.
3.2.5a — The Two-Phase MitM Attack
Phase 1 — Interception: The attacker must first position themselves between the two communicating parties. This requires one of several techniques:
- ARP Poisoning (Layer 2): On a shared LAN, forge ARP replies so other devices send their traffic to the attacker’s MAC address. Attacker forwards traffic to the real destination, maintaining normal connectivity while secretly reading everything.
- Rogue Access Point (Layer 2): Set up a Wi-Fi access point with a name matching a legitimate network (e.g., “Vantex-Guest”). Victims connect to the attacker’s AP instead of the real one. All their traffic flows through the attacker. Coffee shops and airports are common venues for rogue AP attacks.
- DNS Spoofing (Layer 7): Redirect a victim’s DNS queries so that a legitimate domain name resolves to the attacker’s IP. The victim’s browser connects to the attacker’s server instead of the real one. The attacker proxies the real site while capturing all credentials.
- BGP Hijacking (Layer 3): Announce false BGP routes to redirect internet traffic at a regional or global scale. Used by nation-state actors to intercept traffic between countries or corporations. The 2018 BGP hijack of Amazon Route 53 redirected cryptocurrency wallet traffic to an attacker-controlled server, stealing approximately $152,000 in Ethereum.
Phase 2 — Active Manipulation (optional): Once positioned, the attacker can:
to Vantex Bank
modifies all traffic
to the real client
- Passive eavesdropping: Simply read all traffic. Captures credentials, session tokens, and sensitive data transmitted in plaintext or after decryption (if the attacker terminates TLS on their end and re-encrypts toward the server).
- Content modification: Alter traffic in transit. Change account numbers in wire transfer requests, inject malicious JavaScript into web pages, or modify file downloads to include malware.
- Session hijacking: Extract session cookies from captured HTTP traffic and use them to take over authenticated sessions without needing the victim’s credentials.
- SSL stripping: Downgrade HTTPS connections to HTTP by intercepting the initial HTTPS request and serving the victim an HTTP connection. The attacker maintains a valid HTTPS connection to the server while the victim communicates in plaintext.
3.2.5b — Why TLS Does Not Always Stop MitM
A common misconception is that TLS (HTTPS) completely prevents MitM attacks. This is only true when TLS is implemented correctly and the client validates the server’s certificate properly. Three scenarios where TLS fails to stop MitM:
1. Certificate forgery with a rogue CA: TLS depends on the client trusting a Certificate Authority (CA). If an attacker can install a rogue CA certificate on the victim’s device (possible through malware or a corporate MDM), they can issue valid-looking certificates for any domain. The browser shows a padlock icon while the attacker reads all traffic.
2. SSL stripping: Before the TLS connection is established, the victim sends an HTTP request (or the browser attempts to upgrade to HTTPS). If the attacker intercepts this first request and presents an HTTP connection to the victim, the victim may not notice the missing HTTPS. Defense: HTTP Strict Transport Security (HSTS) prevents this by pre-loading “always use HTTPS for this domain” in browsers.
3. User acceptance of invalid certificates: When a MitM uses a self-signed or expired certificate, browsers show a certificate warning. If users click “proceed anyway,” TLS encryption is maintained but the attacker controls one end of it. Security awareness training teaches users to never bypass certificate warnings.
Complete the SYN flood attack description.
TCP connections begin with a handshake: SYN, SYN-ACK, ACK.
In a SYN flood, the attacker sends thousands of packets to the server.
The server responds with SYN-ACK and waits for the final that never arrives.
This creates thousands of connections that consume server memory and connection table entries.
SYN floods are a type of of service (DoS) attack.
63.2.6 — ARP Poisoning and DNS Spoofing In Depth
3.2.6a — ARP Poisoning: The Layer 2 Foundation for LAN MitM
ARP (Address Resolution Protocol) was designed with no authentication. Any device on a network segment can send an ARP reply claiming to be any IP address. ARP poisoning exploits this design to position the attacker as the man-in-the-middle on a shared local area network.
ARP Poisoning Attack Anatomy
3.2.6b — DNS Spoofing and Cache Poisoning
While ARP poisoning works on the local network segment (Layer 2), DNS spoofing can redirect victims anywhere on the internet (Layer 7). A successful DNS cache poisoning attack inserts false records into a DNS resolver’s cache, affecting every user who queries that resolver for the poisoned domain.
DNS Cache Poisoning Attack Anatomy (Kaminsky Attack, 2008)
3.2.6c — Replay Attacks: Time Is the Defense
A replay attack captures a valid, authenticated transmission and retransmits it at a later time. The attacker does not need to know the actual credentials or decrypt the content — they simply record and replay the captured stream. This is particularly dangerous for authentication systems where the same token is valid for extended periods.
Classic example — network authentication replay: A Vantex employee authenticates to the VPN using a Kerberos ticket. An attacker on the same network segment captures the authentication exchange (the Kerberos ticket). Even though the content is encrypted, the attacker retransmits the captured ticket to the VPN server. If the VPN server has no replay protection, it accepts the ticket and grants VPN access without the attacker needing the employee’s password.
Prevention mechanisms:
- Timestamps: Each authentication token includes a timestamp and is only valid within a defined window (e.g., ±5 minutes of the current time). A replayed token from 2 hours ago is rejected as expired. Kerberos uses this approach.
- Nonces (Number Used Once): A random value included in the authentication exchange, valid only for a single use. The server maintains a list of recently used nonces and rejects any authentication using a nonce it has already seen. OAuth 2.0 and OpenID Connect use nonces.
- TLS session tokens: TLS generates unique session keys for every connection. A captured TLS session from yesterday cannot be replayed for a new session because the session keys change with each handshake.
When the MAC table is full, the switch:
73.2.7 — Real-World Case Studies: Network Attacks at Scale
What happened: On February 28, 2018, GitHub was hit with what was then the largest DDoS attack ever recorded: 1.35 terabits per second of inbound traffic. The attack lasted approximately 20 minutes before Akamai’s DDoS mitigation service rerouted the traffic and scrubbed it clean.
The mechanism — memcached amplification: Attackers used memcached servers (a distributed memory caching system used by websites for performance) that were exposed to the internet with UDP enabled. A request to a memcached server for a large stored value triggers a response up to 51,000 times larger than the request. Attackers sent tiny requests with GitHub’s spoofed IP to thousands of exposed memcached servers. The massive cached responses flooded GitHub from all directions simultaneously.
Why it worked: At the time, there were approximately 100,000 memcached servers exposed to the internet with UDP enabled. Memcached was designed as an internal caching layer; operators who accidentally exposed it to the internet did not realize it could be weaponized. The amplification factor (up to 51,000x) meant the attacker needed only about 26 Mbps of outbound traffic to generate 1.35 Tbps of attack traffic — within reach of a small number of compromised servers or even a single high-bandwidth server.
Defense and recovery: GitHub used Akamai Prolexic, a cloud-based DDoS mitigation service, to reroute all traffic through Akamai’s scrubbing infrastructure. Within 8 minutes of the peak, traffic was rerouted; within 20 minutes, the attack subsided. GitHub was unreachable for approximately 10 minutes at peak. The incident prompted mass patching of exposed memcached servers and ISPs implementing BCP38 to block spoofed UDP packets.
What happened: Cisco Talos and other researchers identified a sustained DNS hijacking campaign attributed to a nation-state actor (likely Iran-based), dubbed “Sea Turtle.” The attackers targeted DNS registrars and internet infrastructure providers rather than the end targets directly. By compromising registrar accounts, they modified the authoritative nameserver records for targeted organizations (government agencies, ISPs, telecoms) to point to attacker-controlled infrastructure.
How it worked: Once the DNS records were changed, all traffic to the targeted domains (email, VPN, web portals) flowed through attacker-controlled servers before being forwarded to the real destination. The attackers obtained valid TLS certificates for the targeted domains (using the attacker-controlled nameservers to pass the domain validation challenge). Victims saw valid HTTPS connections and no certificate errors — the MitM was essentially invisible.
What was captured: VPN credentials, email credentials, and sensitive communications for dozens of organizations across 13 countries over an 18-month period. The campaign specifically targeted Middle Eastern and North African government entities and telecoms.
Network attack lesson: DNS hijacking at the registrar level bypasses all network-level defenses at the victim organization. DNSSEC would have partially mitigated this (attackers could not forge signed DNS records unless they also had the zone signing keys), but many organizations had not implemented DNSSEC on their zones. The lesson: DNS infrastructure is critical security infrastructure. Registrar account security, DNSSEC, and Certificate Transparency logs (which allow organizations to detect unexpected certificate issuances for their domains) are all essential layers.
Scenario: Vantex’s Kansas City branch office has a guest Wi-Fi network (“Vantex-Guest”) for visitors and a separate employee Wi-Fi (“Vantex-Employee”). A security researcher hired to test the branch visits, sets up a laptop with a rogue access point also broadcasting as “Vantex-Guest” with a stronger signal than the legitimate AP. Several visitor devices automatically connect to the rogue AP (their devices connected to “Vantex-Guest” previously and auto-connect to any network with that SSID).
Phase 1 results (passive eavesdropping, 45 minutes): The researcher captured HTTP login credentials for three visitors who accessed non-HTTPS websites; captured session cookies for two visitors who had previously logged into sites without HTTPS-only enforcement; and captured the full content of one visitor’s unencrypted email session (IMAP on port 143).
Why HTTPS-using visitors were safer: Visitors who accessed only HTTPS sites with valid certificates had their traffic captured but unreadable (encrypted). The researcher could see that a visitor accessed a banking site but could not read the credentials. HSTS-enabled sites prevented SSL stripping.
Defense recommendations: (1) Use 802.1X enterprise authentication for guest Wi-Fi instead of open PSK networks (prevents rogue AP auto-connection without separate credential prompt); (2) Rogue AP detection on the wireless infrastructure (monitors for SSIDs matching the organization’s names broadcasting from unauthorized BSSIDs); (3) Force all guest traffic through a VPN or HTTPS-only proxy; (4) Never provide guest Wi-Fi with the same SSID as previously used — use unique session-based SSIDs or require explicit portal authentication each visit.
Select ALL controls that help prevent or mitigate MitM attacks.
83.2.8 — Defense Strategies: Protecting Against Network Attacks
| Defense | What It Does | Vantex Implementation |
|---|---|---|
| DDoS Mitigation Service | Cloud-based traffic scrubbing that absorbs volumetric DDoS attacks before they reach the organization’s network. Routes all inbound traffic through the provider’s global scrubbing infrastructure, which filters attack traffic and passes clean traffic to the origin. | Cloudflare Magic Transit deployed on all Vantex internet-facing IP ranges. BGP routes advertised through Cloudflare during attacks. Can absorb terabit-scale volumetric attacks. Automatically activates when inbound traffic exceeds 5x the 30-day average baseline. |
| SYN Cookies | A TCP SYN flood defense that encodes connection state into the initial SYN-ACK sequence number, eliminating the need to allocate server resources for half-open connections. Only legitimate connections (that complete the handshake) result in resource allocation. | SYN cookies enabled on all Vantex web and application servers. Load balancers configured with SYN rate limiting as a first layer, with SYN cookies as the fallback when the rate limit is exceeded. |
| Dynamic ARP Inspection (DAI) | A switch security feature that validates ARP packets against a DHCP snooping binding table. ARP replies claiming mappings not in the binding table are dropped. Prevents ARP poisoning attacks on the local segment. | DAI enabled on all Vantex managed switches. DHCP snooping enabled on all VLANs. Trusted ports (uplinks to routers) configured as DAI-trusted; all access ports (user devices) are DAI-untrusted. |
| DNSSEC | Cryptographic signatures on DNS records allowing resolvers to verify responses have not been tampered with. Prevents DNS spoofing and cache poisoning by making forged responses computationally infeasible. | DNSSEC enabled and signed on all Vantex-owned DNS zones. Internal recursive resolvers configured to validate DNSSEC. Certificate Transparency logs monitored for any new certificates issued for vantex.com domains. |
| HTTPS + HSTS | TLS encrypts data in transit, preventing passive eavesdropping. HSTS (HTTP Strict Transport Security) prevents SSL stripping by instructing browsers to always use HTTPS for the domain, even for the initial request. | All Vantex customer-facing services use TLS 1.3. HSTS headers with 1-year max-age. Vantex domains pre-loaded in browser HSTS preload lists (prevents first-visit HTTP requests). |
| 802.1X Port Authentication | Requires devices to authenticate before being granted network access at the switch port level. Prevents unauthorized devices from connecting to the network and eliminates the rogue device ARP poisoning vector from unauthenticated ports. | 802.1X deployed on all employee network ports. Devices not authenticating via certificate are placed in a quarantine VLAN with limited access. Guest ports use Wi-Fi with captive portal rather than direct port access. |
| BCP38 Ingress Filtering | ISP-level filtering that drops packets with source IP addresses that cannot legitimately originate from the announced network (i.e., spoofed source IPs). Prevents IP spoofing-based amplification attacks by ensuring packets have valid source addresses. | Vantex requires its ISPs to implement BCP38 on all Vantex-facing interfaces. This ensures no traffic claiming to originate from Vantex’s IP ranges can enter from external sources, and no spoofed-source traffic leaves Vantex’s network. |
Match each defense to the attack it primarily counters.
93.2.9 — Worked Examples: Predict First, Then Classify
Identify the Attack Layers
ARP replies → Layer 2 (ARP poisoning, enables MitM positioning). TLS decryption/re-encryption → Layer 4-5 (TLS termination — active MitM). Certificate presentation to browsers → Layer 7 (application layer SSL interception).
Classify the CIA Violations
Confidentiality: all HTTPS traffic is being decrypted and read. Integrity: traffic could be modified in transit (the attacker controls the re-encryption). Availability is not directly targeted — connections are still forwarded.
Explain Why Employees See Warnings
The attacker’s device presents a self-signed certificate (not signed by a trusted CA). Browsers detect the certificate mismatch and show warnings. Employees who click “proceed anyway” have all their traffic decrypted. Employees who heed the warning and don’t connect are protected.
ARP poisoning (Layer 2) enabling active MitM with TLS interception (Layers 4–7). CIA violations: Confidentiality and Integrity. Defenses that would have prevented this: (1) Dynamic ARP Inspection on switches — would have blocked the forged ARP replies; (2) Certificate pinning for critical applications — would have detected the unexpected certificate; (3) Security awareness training — employees should never bypass certificate warnings. The warning is the last line of defense when ARP-level controls have failed.
Match Each Incident to Its Control
Incident A (SYN flood, connection table exhaustion): Defense = SYN cookies. Eliminates the resource allocation problem by encoding connection state in the sequence number rather than server memory. The SYN flood can continue but wastes only attacker bandwidth, not server resources.
Incident B (DNS cache poisoning): Defense = DNSSEC. Cryptographic signatures on DNS records prevent forged responses from being cached, regardless of how well the attacker guesses transaction IDs.
Incident C (1 Gbps volumetric UDP flood): Defense = DDoS mitigation service (Cloudflare/Akamai). The attack traffic exceeds Vantex’s internet link capacity — no on-premises control can stop traffic that saturates the upstream pipe. Only upstream scrubbing (absorbing the traffic before it reaches Vantex) is effective.
A → SYN Cookies; B → DNSSEC; C → Cloud DDoS mitigation service. Each attack requires a different control because each exploits a different protocol mechanism at a different layer. Incident A is a Layer 4 resource exhaustion attack; Incident B is a Layer 7 cache corruption attack; Incident C is a Layer 3/4 volumetric bandwidth attack. No single control addresses all three — this is why network security requires defense-in-depth at multiple layers.
Why is this response ineffective?
103.2.10 — AP Exam Strategy: Network Attack Questions
Strategy 1: Attack → Layer → CIA → Defense
Every network attack question should be analyzed in four steps:
- Name the attack type from the description
- Identify the OSI layer it operates at
- Identify the CIA property(ies) violated
- Name the correct defense for that layer and attack
Memorize the key mappings: ARP → L2 → C+I → DAI. DNS → L7 → C+I → DNSSEC. SYN flood → L4 → A → SYN cookies. DDoS → L3-4 → A → scrubbing service.
Strategy 2: DoS vs. DDoS
The exam always distinguishes these precisely. Key identifiers:
- One source = DoS. Blockable by IP filtering.
- Many sources = DDoS. Botnet, “thousands of IPs,” “distributed.”
- Both violate Availability. Both can use same attack types (SYN flood, UDP flood).
- DDoS: IP blocking is useless — too many sources.
- DDoS defense requires upstream scrubbing or anycast diffusion.
Strategy 3: The Four Fatal Traps
- Trap 1 — ARP is Layer 3: Wrong. ARP = Layer 2. It involves IPs but operates on the Data Link layer.
- Trap 2 — HTTPS prevents all MitM: Wrong. TLS fails against rogue CAs, SSL stripping, and user certificate acceptance.
- Trap 3 — Replay = real-time interception: Wrong. Replay uses previously captured tokens. Real-time interception is eavesdropping.
- Trap 4 — DNS spoofing violates only Availability: Wrong. DNS spoofing redirects traffic — it violates Confidentiality (credentials go to attacker) and Integrity (traffic is modified), not just Availability.
Strategy 4: MitM Sub-Attack Relationships
MitM is a result, not a technique. Remember what enables MitM:
- ARP poisoning → enables LAN MitM (Layer 2)
- Rogue AP → enables Wi-Fi MitM (Layer 2)
- DNS spoofing → enables redirect-based MitM (Layer 7)
- BGP hijacking → enables internet-scale MitM (Layer 3)
SSL stripping and session hijacking are what the attacker does once MitM positioned. DNSSEC/DAI/TLS are defenses at the layer that enables the MitM positioning.
If the API had used HTTPS, what would the attacker see?
?3.2.11 — Frequently Asked Questions
Q: Why is blocking attacker IP addresses ineffective against DDoS?
Two reasons: (1) Scale — a botnet with 50,000 nodes means 50,000 unique IP addresses. Blocking them individually requires 50,000 firewall rules, and new nodes continuously join the attack. Your firewall processing the rule lookups may itself become a bottleneck. (2) Spoofing — many DDoS attacks, particularly amplification attacks, use spoofed source IPs. The attacker’s real IP never appears in the traffic. You would be blocking legitimate IP addresses (the amplifying servers) rather than the attacker’s address. Effective DDoS defense requires upstream scrubbing (absorbing attack traffic before it reaches your link), anycast routing (distributing the attack across a global network), or rate limiting at the protocol level (SYN cookies for SYN floods).
Q: If HTTPS encrypts traffic, why is man-in-the-middle still possible?
HTTPS provides strong protection when implemented correctly, but has three exploitable weaknesses: (1) Certificate forgery — if an attacker can install a rogue Certificate Authority on your device (via malware or a corporate MDM), they can create certificates for any domain that your browser will trust. (2) SSL stripping — if a browser’s very first request for a site is HTTP (before the redirect to HTTPS), an attacker can intercept it and maintain an HTTP connection to the victim while maintaining HTTPS with the real server. HSTS prevents this. (3) User bypassing certificate warnings — when browsers show “Your connection is not private” warnings, clicking proceed gives up HTTPS’s protection. Security culture matters as much as technical controls.
Q: How is a replay attack different from real-time eavesdropping?
Real-time eavesdropping reads traffic as it flows. Replay attacks capture and save traffic for later use. The key difference: real-time eavesdropping requires the attacker to be present on the network at the moment of transmission. Replay attacks allow the attacker to capture authentication data once and reuse it hours or days later. A replay attack against a Kerberos authentication system would capture the authentication ticket, go offline, and then later replay the ticket to gain access — no need to be on the network when the attack happens. Prevention: timestamps make replayed tokens expired; nonces make them single-use. TLS session keys change per session, so a captured TLS handshake from yesterday cannot be replayed today.
Q: What is the difference between DNS spoofing and DNS cache poisoning?
They are closely related and often used interchangeably, but there is a technical distinction. DNS spoofing is the general term for forging DNS responses to return false IP addresses. DNS cache poisoning is a specific attack technique where the false record is inserted into a DNS resolver’s cache, affecting not just one user but every user who queries that resolver. A direct DNS spoofing attack might forge responses to a single user; cache poisoning attacks a resolver, affecting potentially thousands of users who rely on that resolver. From a defense perspective, DNSSEC addresses both because it validates the integrity of DNS responses regardless of whether the forgery is targeted at one user or a resolver’s cache.
Q: Why does amplification work better with UDP than TCP?
Amplification attacks require IP spoofing: the attacker sends a small request with the victim’s IP as the source, causing large responses to be sent to the victim. UDP is connectionless — there is no handshake, and no mechanism to verify the source IP before sending a response. A DNS server that receives a UDP query simply sends its response to whatever source IP is in the packet, no questions asked. TCP, by contrast, requires a three-way handshake before any data is exchanged. To spoof a TCP source IP, the attacker would need to complete the handshake from the victim’s IP — which they cannot do, since the SYN-ACK goes to the victim, not the attacker. TCP’s handshake effectively prevents IP spoofing (and therefore amplification) at the transport layer.
Q: How does Dynamic ARP Inspection actually prevent ARP poisoning?
Dynamic ARP Inspection (DAI) works in conjunction with DHCP snooping. When DHCP snooping is enabled, the switch builds a binding table: “MAC address AA:BB:CC:11:22:33 was assigned IP 192.168.1.10 on port GigabitEthernet0/5.” When DAI is enabled, every ARP packet on an untrusted port is checked against this table. If an ARP reply claims “192.168.1.1 is at AA:BB:CC:DD:EE:FF” but the binding table shows 192.168.1.1 was assigned to a different MAC address (or 192.168.1.1 is the gateway, which is a static entry, not a DHCP assignment), the switch drops the ARP packet and logs the violation. The attacker’s forged ARP replies never reach the victim devices. The key: DAI requires reliable binding data (from DHCP snooping or static entries for devices with static IPs) and must be enabled on all untrusted ports.
Select ALL correct attack-to-defense pairings.
!Common AP Exam Mistakes — Topic 3.2
| Mistake | Why It’s Wrong | What to Do Instead |
|---|---|---|
| Confusing ARP poisoning with DNS poisoning | ARP poisoning modifies the MAC-to-IP mapping at Layer 2 to redirect LAN traffic. DNS poisoning plants a fake DNS record to redirect browser traffic to a credential-harvesting site. Different layers, different mechanisms, different defenses. | ARP = Layer 2, MAC table, on-path attack. DNS = application layer, name resolution, credential harvesting. |
| Saying MAC flooding intercepts individual targeted traffic | MAC flooding forces the switch into broadcast mode, so the adversary receives ALL frames, not targeted traffic. This is eavesdropping/sniffing, not a targeted on-path attack. | MAC flooding = broadcast-everything eavesdropping. ARP poisoning = targeted on-path interception. |
| Classifying smurf attack as a confidentiality attack | A smurf attack overwhelms the victim with ICMP replies, making their network unavailable. It is a DoS attack — Availability violation. No data is stolen. | Smurf = DoS = Availability. Data theft attacks = Confidentiality. |
| Forgetting that credential harvesting requires a fake site | DNS poisoning alone doesn’t steal credentials. The CED (3.1.A.3) specifies the adversary creates a fake login site that looks identical to the real one. Both pieces are required. | DNS poisoning redirects; the fake credential-harvesting site actually captures the credentials. |
| Thinking HTTPS prevents DNS poisoning | HTTPS encrypts traffic in transit but doesn’t verify that DNS resolved to the correct IP. A poisoned DNS record can redirect you to a fraudulent HTTPS site with a valid certificate from a different domain. | DNS poisoning targets name resolution before the connection. HTTPS protects the connection itself, not the resolution. |
Students submit before leaving.
- For each of the four CED network attacks, state: (a) the mechanism, (b) the attack classification term, (c) the CIA property violated. (AP Skill: Analyze Risk)
- An adversary is on the same LAN as their target. Explain step-by-step how ARP poisoning allows them to intercept all traffic between the target and the default gateway without the target knowing. (AP Skill: Analyze Risk)
- Users report that after entering their credentials on the company website, their accounts are immediately compromised. Network logs show the web server received no unusual traffic. What attack type most likely occurred, and what did the adversary do? (AP Skill: Analyze Risk)
- Why is a smurf attack classified as DDoS when only one adversary sends the initial ICMP packets? (AP Skill: Analyze Risk)
- Port security is enabled on all switch ports with a maximum of 3 MAC addresses. An adversary physically plugs into an open conference room port and attempts MAC flooding. Explain why this attack fails and what the adversary cannot accomplish. (AP Skill: Mitigate Risk)
Tanner has taught AP Computer Science for 11+ years and built APCSExamPrep.com to give every student access to the same resources his own students use. He holds 2,067+ verified tutoring hours on Wyzant with a 5.0 rating from 499+ reviews. His AP CSA students score 5s at more than double the national average (54.5% vs. 25.5% nationally).
+Continue Learning
Practice what you learned, then move to the next topic in Unit 1:
Lesson → Exercise 1 → Exercise 2 → Lab → Quiz
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]