09 — Network Attacks
Level: Intermediate · Time: ~20 min · Prerequisites: Lesson 8 — The Attack Taxonomy — Every Major Class in One Place
Why this matters
Most attacks are not against a network protocol; they use one. A phishing page is HTTP, credential theft is often SMB, exfiltration is DNS or HTTPS. But a smaller, older family targets the network itself: the traffic, the addresses, the name resolution, the switches and the routers that carry everything else. These attacks matter because they sit underneath every other control. If an attacker is on-path, your logs record a conversation they fully control; if they have poisoned DNS, your users are on their site while your monitoring believes they used yours. They are also the attacks a small network is least prepared for, because they exploit defaults nobody changed: ARP has no authentication, DNS was designed for trust, and BGP believes what it is told.
The mental model: four places an attacker can stand
Place the attacker before naming the technique. The position determines what is possible and which defence applies.
| Position | What they can do | What they cannot easily do | Relevant control |
|---|---|---|---|
| Off-path, remote | scan you, flood you, exploit an exposed service | read or modify existing traffic | firewall, patching, rate limiting, upstream filtering |
| On the local segment | sniff, spoof ARP, answer DHCP, poison DNS for neighbours | see traffic on other segments | switch hardening, segmentation, encryption, 802.1X |
| On-path (in the flow) | read, modify, inject, terminate sessions | very little — they own the conversation | TLS with certificate validation, HSTS, Dynamic ARP Inspection |
| On a host inside | everything the host's permissions allow, plus network fan-out | reach what segmentation denies | least privilege, egress control, segmentation, EDR |
A passive attack only listens: sniffing changes nothing, so it is nearly invisible to monitoring. An active attack sends something — forged replies, resets, redirected traffic — and leaves traces. Sniffing is passive, and still dangerous for three reasons: cleartext credentials and data on any protocol not inside TLS (some internal tools, FTP, Telnet, SNMP v1/v2c, POP3, IMAP); metadata, where source, destination, sizes, timings and the server name in a TLS handshake map your estate even when content is encrypted; and free topology discovery from the ARP, DNS and DHCP traffic that crosses the segment.
Where you can sniff depends entirely on the medium. A hub repeats everything to everyone. A switch forwards only to the port owning the destination MAC — not a wall, but a lock, and typical LAN attacks are about picking it. WiFi is a shared medium, so on an open or shared-passphrase network anyone with the key captures your frames; that is why client isolation and WPA3 matter. A compromised router or gateway is the worst case, because every segment behind it is reachable and all flows pass the chokepoint.
ARP and DNS: the trust that redirects traffic
ARP spoofing, step by step
ARP answers one question — "who has 192.168.1.1? Tell me your MAC" — as a shout to the whole segment, with no authentication and no memory of who answered first. Hosts believe the most recent reply.
- The attacker joins the same broadcast domain: an office port, the staff WiFi, or a guest network that is not isolated from the staff network.
- They send gratuitous ARP replies — unsolicited "192.168.1.1 is at my MAC" — often enough to stay in every cache.
- Each victim's ARP cache now maps the gateway's address to the attacker's MAC, so internet-bound traffic arrives at the attacker.
- The same is done in reverse to the router, so return traffic also flows through them.
- Traffic is relayed to keep everything working. It is a genuine man-in-the-middle, not an outage — which is why it can run for weeks unnoticed.
What it enables: credential capture on unencrypted protocols, session-token theft on HTTP sites, content injection into plain responses (a fake download, a fake login banner), and a complete internal view of who talks to what. What stops it:
| Control | What it does |
|---|---|
| Dynamic ARP Inspection | the switch validates ARP packets against its DHCP-snooping binding table and drops lies |
| Static ARP entries | pin the gateway's MAC on critical hosts, so a forged reply changes nothing |
| Port security and 802.1X | unknown devices cannot join the segment in the first place |
| Segmentation | a compromised laptop cannot reach the finance VLAN, the servers or the cameras |
| Encryption (TLS, SSH) | capture becomes worthless — the strongest control, because it does not depend on the network behaving |
[!TIP] Small networks rarely deploy Dynamic ARP Inspection. The realistic combination is segmentation, encryption, static ARP on the gateway for a few critical machines, and monitoring for a host that suddenly answers ARP for another host's address.
DNS: the protocol everyone trusts and nobody watches
| Attack | How it works | The control |
|---|---|---|
| Cache poisoning | a forged answer races the real one into a recursive resolver, so the wrong address is cached and served to everyone using it | DNSSEC validation, trusted resolvers, encrypted DNS, resolution monitoring |
| Kaminsky-style racing | in 2008 Dan Kaminsky showed how to make a resolver ask predictable new questions, guess the transaction ID and source port, and win the race reliably; the fix was to randomise both, which is why cache poisoning stopped being routine | patched resolvers, DNSSEC, and never running an open resolver |
| Local DNS spoofing | on the same segment the first answer wins, so ARP spoofing plus a forged reply sends users to a hostile page | DHCP snooping, port security, encrypted DNS, DNSSEC |
| DNS rebinding | a hostile page serves a domain that resolves first to the attacker's server and then to an address inside your network, turning the browser into a proxy for internal services | browser protections, do not expose internal services by plain name, egress control on application servers |
| DNS tunnelling and exfiltration | data is encoded into query labels sent to an attacker-controlled domain, with answers encoded in the replies; queries are small and look unremarkable | DNS logging, resolver allowlisting, detection of long high-entropy labels and volume anomalies |
| DNS over HTTPS / TLS abuse | encrypted DNS is pointed at a hostile resolver the attacker controls, hiding command and control in the channel you encouraged for privacy | centralise and log encrypted DNS, block third-party resolvers at the firewall, record which client uses which resolver |
The reason DNS carries intrusion traffic so well: DNS is almost never blocked. Blocking port 53 breaks everything, so it stays open at nearly every egress point. An attacker who can get one query to their own authoritative server has a command-and-control channel that survives most firewall policy reviews. The practical response, in order: log every query with the client that asked it; alert on very long labels, high-entropy names and unusual query volume from one host; force outbound port 53 to your own resolvers only; and treat a switch to an unfamiliar encrypted DNS provider as a finding, not a preference.
Denial of service: three shapes and one amplifier
| Shape | Mechanism | Typical signature | Mitigation |
|---|---|---|---|
| Volumetric | traffic exceeds your link capacity | inbound bandwidth saturates; the router, not the server, is the victim | provider-side scrubbing, CDN absorption, blackhole routing as a last resort |
| Protocol-state | state is exhausted — for example a SYN flood filling the half-open connection queue so real connections cannot complete | connection table full, many half-open connections, server alive but unreachable | SYN cookies and queue tuning, connection limits, upstream filtering |
| Application-layer | requests that are individually valid but expensive are sent in volume | high CPU or a slow database, normal-looking requests, low bandwidth | caching, request-cost limits, bot detection, login throttling, autoscaling |
Reflection and amplification, the mechanism behind the largest floods ever seen:
- The attacker sends a small request to a third-party service that will reply with something much larger.
- The attacker spoofs the source address to be the victim's IP.
- The service sends the large reply to the victim. The attacker never sees it and does not need to.
- Multiply across every service willing to answer, and the victim's link fills with replies to requests they never made.
The ratio between request size and reply size is the amplification factor. UDP protocols designed to reply with more than they were asked are the raw material: DNS, NTP monitoring queries, and misconfigured memcached servers on UDP port 11211, which produced some of the largest recorded floods in 2018 because a tiny request could elicit a reply tens of thousands of times larger. You do not need to memorise factors. You need to know that a misconfigured service you run can be used to attack someone else, and that the fix is to close open resolvers, disable unused UDP services, and filter spoofed source addresses at the network edge.
Ransom denial of service wraps this in extortion: a short real attack to prove capability, an email demanding payment, a threat to return — the economics mirror ransomware.
What mitigation actually looks like
You cannot solve this from a single server, and pretending otherwise costs money and credibility. Instead: upstream scrubbing or a scrubbing service (traffic is diverted by your provider or CDN, cleaned and forwarded — the only control that works against a volumetric flood, and it must be arranged before you need it); CDN absorption, so the flood hits infrastructure built to tolerate it; rate and connection limiting, cheap, effective against application and protocol-state attacks, and worth having even without an attacker; autoscaling, which converts a capacity attack into a bill — better than an outage, but not free; and a named contact at your hosting or transit provider, because on the day you will not be filling in a web form.
Layer 2, routing, session and reconnaissance attacks
| Attack | How it works | The control |
|---|---|---|
| VLAN hopping by double tagging | a frame carries two 802.1Q headers; the first switch strips the outer tag and the inner tag delivers the frame into another VLAN — it needs the attacker's port configured as a trunk | keep user traffic off the native VLAN, tag the native VLAN and leave it unused, never leave auto-trunking on access ports |
| VLAN hopping by switch spoofing | the attacker speaks the switch-to-switch negotiation protocol and asks to become a trunk port | disable trunk negotiation on access ports and configure them explicitly as access |
| MAC flooding | frames with thousands of forged source MAC addresses overflow the switch's MAC table until it floods every port, becoming a hub | port security with a MAC limit per port, ARP inspection, monitoring for address-table exhaustion |
| Rogue DHCP server | a device answers DHCP first and hands out itself as gateway and DNS server, putting every trusting client on the attacker's path | DHCP snooping on access ports, port security, 802.1X |
| Spanning-tree attacks | a device claims to be the root bridge and becomes the topology's centre, or floods topology-change messages | BPDU guard and root guard on access ports |
| Session hijacking | a session is taken over by stealing its token on a plaintext connection, or historically by predicting TCP sequence numbers, which modern stacks now randomise | TLS everywhere, HSTS, encrypted session tokens, re-authentication on sensitive actions |
| TCP reset injection | a forged reset with the right sequence number drops an existing connection | encryption limits tampering but not resets; segment hardening and monitoring for repeated teardowns |
| BGP hijacking and route leaks | a network announces address space it does not own, or leaks routes learned from a peer, so traffic is drawn towards it | route filtering and origin validation (RPKI) at your transit provider, multi-provider diversity, routing monitors |
[!WARNING] BGP hijacking is usually not theft. More often it is a route leak — a large network's misconfiguration accidentally attracting a chunk of the internet's traffic. It can happen to you because of a mistake at a company you have never heard of.
You do not fix BGP yourself. Your prefixes are advertised by your providers, so what protects them is their filtering plus public routing monitors. What you can do: buy from more than one provider, ask in writing what filtering they apply to your prefixes, and subscribe to alerts when your address space appears somewhere unexpected.
Reconnaissance, and what scanning looks like in logs
| Technique | What it does | Typical tooling |
|---|---|---|
| Ping sweep (host discovery) | finds which addresses answer at all | nmap -sn 192.168.1.0/24, ARP scans on a local segment |
| TCP connect scan | completes a full handshake per port; reliable and visible, no special privilege needed | nmap -sT |
| SYN (half-open) scan | sends a SYN and never completes the handshake; faster and quieter, needs elevated privilege | nmap -sS |
| UDP scan | probes UDP services; slow and unreliable because UDP gives little feedback | nmap -sU |
| Service and version detection | works out what is listening and which version, to match known flaws | nmap -sV |
| Operating-system detection | infers the platform from TCP/IP behaviour | nmap -O |
A scan has a shape, and the shape is what you detect: many distinct destination ports from one source, often ascending; many connection attempts in seconds, hundreds of SYNs to one host; one source touching many hosts (a sweep) or many sources touching one host (distributed probing); connections that open and close with no data transferred; and machine-like timing, a fixed interval that is not human behaviour.
The same shape appears in legitimate monitoring and vulnerability scanning, which is why "alert on scans" is the wrong rule. The right rule is: know which internal systems may scan, from which addresses, at what times — and alert on everything else. That allowlist is what turns noise into signal. Run nmap against your own external range and one internal subnet, and you learn two things worth the afternoon: what you actually expose, and how it looks in your own logs.
Lateral movement, pivoting and egress control
Once inside, moving between hosts is mostly a small set of remote-execution protocols. Lesson 13 covers the credential side; this is the network behaviour.
| Protocol | Port | Legitimate use | Why it is used to move |
|---|---|---|---|
| SMB | 445 | file shares, printing, remote administration | authenticated access with whatever credential is held, plus execution via administrative shares |
| RDP | 3389 | interactive remote desktop | a full graphical session — anything a logged-in user can do |
| WinRM | 5985 (HTTP), 5986 (HTTPS) | remote management and scripting | remote command execution with a valid account |
| WMI and remote procedure calls | dynamic ports | management and inventory queries | remote process creation that looks like administration |
| Remote deployment helpers | varies | pushing software and commands to many hosts at once | built for IT, and indistinguishable from IT when abused |
The behaviours that reveal it: internal fan-out, where one host opens authenticated sessions to many others in minutes, because workstations normally talk to servers rather than to each other; new SMB or RDP flows between workstations, which is almost always a finding and can usually be prohibited outright; authentication from unusual hosts, such as a user account logging in from a machine that user never uses; administrative shares accessed by non-administrative accounts; and a sudden widening in the set of hosts one account touches. Lesson 44 covers the detection engineering and Lesson 22 the logging.
Pivoting turns one owned host into a stepping stone. The concepts to know: SSH local forwarding (ssh -L) makes a remote service appear on a local port, exposing an internal system to the outside; SSH remote forwarding (ssh -R) does the reverse, publishing a service into a remote network, which is how a compromised host offers a route inward; SSH dynamic forwarding (ssh -D) turns the connection into a SOCKS proxy for arbitrary traffic; and application-level tunnelling wraps one protocol inside another that is already permitted, such as command and control inside DNS or HTTPS. All four are legitimate tools used legitimately daily — which is precisely why you detect them by behaviour, not by name.
The counter-measure is egress control: a firewall policy that describes not only what may come in, but what may go out, from which system, to which destinations. Most networks have never written that policy, which is why a foothold becomes a breach. Outbound allowlists for servers, blocking direct internet access from internal systems, and logging every denied connection are the highest-value network controls most small organisations are still missing.
What to fix first, and what it costs
| Attack family | Concrete control | Cost |
|---|---|---|
| Sniffing on a shared segment | segmentation, guest WiFi isolated from staff, no open WiFi for internal work | configuration only |
| ARP spoofing | static gateway ARP entries on critical hosts, DHCP snooping, segmentation | free to low |
| Rogue DHCP or rogue access point | DHCP snooping and port security on access ports | free (switch feature) |
| DNS poisoning and tunnelling | log every query with its client, force all clients to your own resolvers, block outbound port 53 to third parties | free |
| Scanning | a documented scanning allowlist, alerting on everything else | free |
| Volumetric denial of service | CDN or scrubbing in front of public services, provider contact known in advance | paid, cheap at the small end |
| Application-layer denial of service | rate limiting on login and search endpoints, caching | free to low |
| Session hijacking | TLS everywhere, HSTS, no plaintext protocols internally — certificates are free | free |
| MAC flooding and VLAN hopping | disable unused ports, no trunk negotiation on access ports, port security | free |
| Lateral movement | no workstation-to-workstation SMB, administrative protocols restricted to jump hosts | free |
| Pivoting and exfiltration | outbound allowlist per system, log all denied egress | free |
| BGP hijacking or route leak | multi-provider diversity, written filtering requirements, routing-monitor alerts | paid |
Read the last column: almost everything that matters most in a small network is free. The constraint is not budget — it is that somebody has to write the policy down and apply it.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Sniffing on a flat LAN | capturing frames that reach your port on a shared medium | encryption everywhere, switched segmentation, isolated guest WiFi, WPA3 |
| ARP spoofing | unauthenticated ARP replies redirect traffic through the attacker | Dynamic ARP Inspection, static ARP for gateways, 802.1X, segmentation |
| Rogue DHCP server | a first-answer DHCP server hands out itself as gateway and resolver | DHCP snooping, port security, 802.1X |
| DNS cache poisoning or local spoofing | a forged answer beats the real one, locally or at a resolver | DNSSEC validation, patched resolvers, DHCP snooping, encrypted DNS |
| DNS exfiltration | data encoded into query labels to an attacker-controlled domain | query logging with client attribution, entropy and volume detection, resolver allowlisting |
| Reflection and amplification | spoofed requests make third-party services flood the victim | close open resolvers and unused UDP services, ingress filtering, provider scrubbing |
| VLAN hopping or MAC flooding | trunk abuse or MAC-table overflow crosses a boundary | native VLAN hygiene, no trunk negotiation on access ports, port security |
| Session hijacking | a session token is stolen or a connection is reset | TLS with HSTS, short-lived tokens, encrypted sessions, monitoring for resets |
| BGP hijack or route leak | false route announcements draw your traffic elsewhere | transit-provider filtering and RPKI, multi-provider diversity, routing monitors |
| Internal lateral movement | stolen credentials drive SMB, RDP or WinRM between hosts | segmentation, jump hosts, no workstation-to-workstation file sharing, egress control |
Key takeaways
- Place the attacker before naming the attack. Off-path, on-segment, on-path or on-host determines what is possible and what defence applies.
- ARP and DNS are unauthenticated by design, so they are the classic toolkit for redirecting a network. Fix them at the switch, at the resolver, and by encrypting what is on the wire.
- Every organisation leaves DNS open, and attackers know it. Per-client query logging is one of the cheapest detections available.
- You cannot out-scale a volumetric flood from one server. Scrubbing, CDN absorption and a provider contact arranged in advance are the answer.
- Egress control is the most underrated network control in small organisations. Most networks describe what may come in and nothing about what may go out.
Check yourself
- Which network attack can only be performed from the same broadcast domain as the victim, and which control removes the attacker's ability to do it at all?
- Explain in two sentences why reflection lets an attacker with a small connection cause a very large flood.
- One internal workstation makes 400 connection attempts in 30 seconds across sequential ports on another workstation. What are the two most likely explanations, and how would you tell them apart?
- Why does DNS make such a good exfiltration channel, and which log would detect it?
- Name three controls from the "what to fix first" table that cost nothing but configuration — and say why each is still often missing.