16.2.5 Check Your Understanding - Network Attacks

You're staring at a screen full of red alerts. Your SIEM is screaming. The network team is on Slack asking if this is "normal." Your coffee is cold.

Sound familiar? If you've spent any time in a SOC or managing network infrastructure, you know that feeling. And network attacks don't announce themselves with polite knocks. They slip in through misconfigured ports, exploited trust relationships, and protocols that were never designed with security in mind.

Let's talk about what's actually happening on the wire — and how to spot it before it becomes a breach It's one of those things that adds up..

What Is a Network Attack

At its core, a network attack is any malicious action that targets the confidentiality, integrity, or availability of data in transit or the infrastructure carrying it. That's the textbook definition. In practice? It's someone abusing the very protocols that make the internet work.

TCP/IP wasn't built for security. This leads to it was built for resilience. Now, aRP assumes everyone on the local segment is trustworthy. DNS assumes the server you're talking to is the one you asked for. BGP assumes the route announcement is legitimate. Attackers don't break these protocols — they use them exactly as designed.

Not obvious, but once you see it — you'll see it everywhere.

The Three Categories That Matter

Most frameworks sort attacks into buckets. I prefer thinking in terms of what the attacker is trying to achieve:

Disruption attacks want to break availability. DDoS floods. SYN floods. Amplification attacks using open NTP or DNS servers. The goal isn't stealth — it's noise. Maximum impact, minimum effort Worth keeping that in mind..

Interception attacks want to see what they shouldn't. MITM. ARP poisoning. DNS hijacking. BGP route hijacking. These are quieter. The traffic keeps flowing — it just takes a detour through the attacker first.

Injection attacks want to change what's in flight. Session hijacking. TCP sequence prediction. DNS cache poisoning. The data arrives, but it's not the data you sent It's one of those things that adds up..

Why It Matters / Why People Care

Here's the uncomfortable truth: most organizations don't detect network attacks until something breaks or data shows up on a paste site. The 2023 Verizon DBIR put the median time to discover a breach at months for certain attack vectors. Months Small thing, real impact..

And network attacks are often the first stage of something bigger. That weird DNS traffic? Could be command-and-control. The ARP anomalies? Someone pivoting laterally. In practice, the SYN flood? A smokescreen while they exfiltrate from a different vector.

Real-World Impact

• SolarWinds (2020): Started with a supply chain compromise, but the network-level C2 traffic used legitimate domains and encrypted channels. Hard to spot without behavioral baselines.
• GitHub DDoS (2018): 1.35 Tbps via memcached amplification. Largest at the time. Took them offline for minutes — but minutes matter at that scale.
• BGP hijack of Amazon Route 53 (2018): Attackers announced Amazon's prefixes, redirected DNS for MyEtherWallet, stole $150K in crypto. BGP has no native authentication. Still doesn't.

These aren't theoretical. They're Tuesday.

How Network Attacks Work

Let's break down the mechanics. Not every variant — just the ones that actually show up in logs Not complicated — just consistent..

Layer 2 Attacks: The Local Segment

ARP Poisoning / Spoofing

ARP has no verification. You ask "Who has 192.168.1.1?" and anyone can answer. An attacker sends gratuitous ARP replies mapping the gateway's IP to their MAC. Here's the thing — traffic flows through them. They forward it to the real gateway. Nobody notices.

Detection tip: Watch for MAC-IP flapping. Multiple IPs on one MAC. One IP on multiple MACs. Dynamic ARP Inspection (DAI) on switches helps — if you've enabled it.

MAC Flooding

Switches have finite CAM tables. Which means flood them with frames from thousands of fake source MACs. Practically speaking, the table fills. On top of that, the switch fails open — starts flooding all traffic out all ports. Now the attacker sees everything on that VLAN Small thing, real impact..

Mitigation: Port security. Limit MACs per port. Sticky MACs. Shutdown violations That's the part that actually makes a difference..

VLAN Hopping

Double-tagging (if the attacker's port is in the native VLAN of a trunk). Or switch spoofing — negotiate a trunk with DTP, then access all VLANs Worth keeping that in mind..

Fix: Disable DTP everywhere. Explicit trunk config. Never use VLAN 1 for anything. Prune unused VLANs from trunks.

Layer 3/4 Attacks: Routing and Transport

IP Spoofing

Forge the source IP. That's why easy with raw sockets. Still, used in reflection/amplification attacks — send a tiny request to an open resolver with the victim's IP as source. The resolver sends a large response to the victim.

BCP 38 (ingress filtering) stops this at the ISP level. But adoption is incomplete. So naturally, you can't fix the internet — but you can filter your egress. Don't let spoofed packets leave your network Which is the point..

SYN Flood

TCP three-way handshake: SYN → SYN-ACK → ACK. Attacker sends SYN, never completes. Server holds state in the backlog queue. Queue fills. Legitimate connections dropped It's one of those things that adds up. Took long enough..

Defenses: SYN cookies (stateless handshake). Increase backlog. Rate-limit SYN per source. Anycast/load balancers absorb volume.

TCP Session Hijacking

Predict the sequence number. Inject a packet that looks like it came from the legitimate host. If you're on-path (MITM), you don't even need to predict — you see the numbers Worth knowing..

Modern stacks randomize ISNs (RFC 6528). IoT? But old devices? Still vulnerable Most people skip this — try not to..

ICMP Attacks

Redirect messages can rewrite host routing tables. Practically speaking, address mask requests reveal subnet info. Timestamp requests leak uptime. Smurf attacks (amplification via broadcast ping) are mostly dead — but ICMP tunnels for C2 are very alive That's the part that actually makes a difference..

Policy: Rate-limit ICMP. Block redirects. Allow only what you need (echo request/reply, destination unreachable, time exceeded).

Layer 7 Attacks: Application Abuse

DNS Attacks

• Cache poisoning: Forge a response before the legitimate one arrives. Kaminsky's 2008 attack exploited predictable TXIDs and port numbers. DNSSEC fixes this — if you deploy it.
• Tunneling: Encode data in subdomains. exfiltrated-data.attacker.com. Legitimate recursive resolvers carry it happily.
• DGA domains: Malware generates thousands of domains daily. Fast flux. Hard to blocklist.

Detection: Entropy analysis on domain names. Query volume per client. NXDOMAIN rates. DNSSEC validation.

HTTP/HTTPS Attacks

• Slowloris: Hold connections open with partial headers. Exhaust server threads.
• HTTP/2 Rapid Reset: Cancel streams immediately after request. CVE-2023-44487. Massive amplification.
• Credential stuffing: Not a "network" attack per se — but it rides the network. Rate limiting, WAF, bot detection.

TLS/SSL Abuse

Encrypted traffic hides payloads. On top of that, malware uses valid certs (Let's Encrypt, self-signed with custom CA). So naturally, attackers know this. Legitimate services use TLS 1.

TLS/SSL Abuse (continued)
Encrypted traffic hides payloads. Attackers know this. Malware uses valid certs (Let's Encrypt, self‑signed with a custom CA). Legitimate services use TLS 1.3 with encrypted SNI (ESNI) to conceal the hostname being visited, but several abuse vectors remain:

• Version‑downgrade attacks – By tampering with the ClientHello, an attacker can force a fallback to TLS 1.0/1.1 or even SSL 3.0, enabling known vulnerabilities (POODLE, BEAST). Modern browsers and servers mitigate this with TLS_FALLBACK_SCSV and by refusing insecure protocol versions, but misconfigured appliances often still allow them.
• Cipher‑suite manipulation – If a server prefers weak ciphers (RC4, 3DES, or export‑grade suites), an active MITM can steer the handshake toward them. Disabling weak suites and prioritizing AEAD ciphers (AES‑GCM, ChaCha20‑Poly1305) eliminates the risk.
• Certificate validation bypasses – Some IoT devices ship with hard‑coded trust anchors or disable revocation checks. Attackers can present a self‑signed certificate that chains to a trusted root, or abuse OCSP stapling failures to accept expired certs. Enforcing strict certificate pinning, requiring OCSP/Must‑Staple, and disabling legacy trust stores close these gaps.
• Session‑ticket and key‑share attacks – TLS 1.3 session tickets encrypted with a server‑side key can be replayed if the key is rotated infrequently or leaked. Regular key rotation, short ticket lifetimes, and using zero‑RTT only with replay‑safe mitigations (e.g., server‑side replay caches) reduce exposure.
• Side‑channel leakage – Encrypted SNI hides the hostname, but timing or size side‑channels can still reveal visited sites. Deploying constant‑time implementations and padding records (as in TLS 1.3’s record size limit) mitigates these channels.

Defensive checklist for TLS

1. Enforce TLS 1.2 + TLS 1.3 only; disable SSLv2/3, TLS 1.0/1.1.
2. Configure a strong cipher suite list prioritizing AEAD ciphers; drop RSA key exchange in favor of (EC)DHE.
3. Activate HSTS with a long max‑age and includeSubDomains flag.
4. Deploy OCSP Must‑Staple or use CRLite‑style revocation checking.
5. Enable encrypted SNI (ECH) where supported, or use ESNI/ECH‑compatible resolvers.
6. Limit session ticket lifetime (e.g., 4–8 h) and rotate ticket keys regularly.
7. Monitor for anomalous TLS handshakes (failed version negotiations, unexpected cipher suites, excessive renegotiations).

Other Layer 7 Vectors Worth Noting

• API Abuse – Over‑provisioned REST/GraphQL endpoints expose excessive data or allow costly queries (e.g., deep nesting, batching). Implement strict schema validation, depth/rate limits, and query cost analysis.
• Web‑Socket Exploitation – Persistent full‑duplex connections can be abused for resource exhaustion or as covert channels. Validate origin headers, enforce subprotocol whitelisting, and apply idle‑timeout policies.
• Server‑Side Request Forgery (SSRF) – Abusing trusted outbound fetches to reach internal services. Use allow‑lists for outbound destinations, disable unnecessary URL schemes (file://, gopher://), and sandbox fetcher processes.
• Credential‑Stuffing & Brute‑Force – Though not purely network‑level, they ride HTTP/S traffic. Deploy adaptive rate‑limiting, CAPTCHA or proof‑of‑work challenges, and credential‑leak monitoring.

Conclusion

Network‑level attacks have evolved from simple packet spoofing to sophisticated application‑layer abuse that leverages encryption, protocol features, and legitimate service functionality. A strong defense therefore requires a layered strategy: