Chapter 13: Exercises — Network-Based Attacks

⚖️ Legal Note: All exercises must be performed in isolated lab environments that you own. Network-based attacks affect all devices on the targeted network segment and can cause service disruptions. Never perform these techniques on production networks without explicit written authorization and coordination with network administrators.

Exercise 13.1: ARP Cache Analysis

Objective: Understand normal ARP behavior before learning to exploit it.

Instructions: 1. On your lab machine, display the current ARP cache (arp -a on Windows, arp -n on Linux). 2. Ping a neighboring host on your lab network that is not yet in the cache. 3. Display the ARP cache again and identify the new entry. 4. Use Wireshark to capture the ARP request and reply. Identify: - The broadcast ARP request (who-has) - The unicast ARP reply (is-at) - The MAC addresses involved 5. Document the complete ARP resolution process with screenshots.

Expected Deliverable: Annotated Wireshark captures showing normal ARP operation with explanations of each field.

Exercise 13.2: ARP Spoofing in a Lab Environment

Objective: Perform ARP spoofing to understand the attack and its indicators.

Prerequisites: Three VMs on the same virtual network segment (attacker, victim, gateway/router).

Instructions: 1. Enable IP forwarding on the attacker machine: echo 1 > /proc/sys/net/ipv4/ip_forward. 2. Use arpspoof to poison the victim's ARP cache, making the victim believe you are the gateway. 3. Simultaneously poison the gateway's ARP cache. 4. On the victim, verify that the ARP cache now shows the attacker's MAC for the gateway IP. 5. On the attacker, use tcpdump or Wireshark to confirm you can see the victim's traffic. 6. Stop the attack and verify that ARP caches return to normal.

Expected Deliverable: Before/after ARP cache screenshots, Wireshark capture showing intercepted traffic, and documentation of the complete attack and cleanup process.

Exercise 13.3: Detecting ARP Spoofing

Objective: Identify indicators of ARP spoofing from a defender's perspective.

Instructions: 1. Install arpwatch on a Linux machine in your lab. 2. Start arpwatch monitoring on the network interface. 3. Have a partner (or second VM) perform ARP spoofing on the network. 4. Examine the arpwatch logs for alerts about MAC address changes. 5. In Wireshark, create a display filter to identify duplicate IP-to-MAC mappings. 6. Write a brief report describing the detection indicators you observed.

Expected Deliverable: Arpwatch alerts, Wireshark analysis, and a detection strategy document.

Exercise 13.4: MITM with Bettercap

Objective: Use Bettercap for a comprehensive MITM attack demonstration.

Instructions: 1. Install Bettercap on your Kali machine. 2. Use net.probe to discover hosts on your lab network. 3. Enable ARP spoofing against a specific target. 4. Enable the HTTP proxy to intercept HTTP traffic. 5. Browse to an HTTP website from the victim and observe the intercepted credentials or data on the attacker. 6. Attempt SSL stripping against an HTTPS site and document the result. 7. Test against a site with HSTS enabled and document the difference.

Expected Deliverable: Bettercap command log, intercepted data samples, and analysis of HSTS effectiveness.

Exercise 13.5: DNS Spoofing Lab

Objective: Redirect DNS resolution to demonstrate the impact of DNS attacks.

Instructions: 1. Configure a DNS spoofing rule in Ettercap's etter.dns file to redirect a specific domain to your attacker IP. 2. Set up a simple web server on your attacker machine serving a "You've been hacked" page. 3. From a MITM position (using ARP spoofing), activate the DNS spoofing plugin. 4. On the victim, navigate to the target domain and observe the redirect. 5. Document the complete attack chain. 6. Research and implement one defensive measure (e.g., configure the victim to use DNS-over-HTTPS).

Expected Deliverable: Screenshots of the DNS redirect, Wireshark captures of the spoofed DNS responses, and defensive implementation documentation.

Exercise 13.6: DNS Tunneling Detection

Objective: Understand DNS tunneling by setting it up and then detecting it.

Instructions: 1. Set up a dnscat2 server on your external (simulated Internet) machine. 2. Configure a dnscat2 client on a machine inside your lab network. 3. Establish a DNS tunnel and transfer a small file through it. 4. On the DNS server or a network monitoring point, capture the DNS traffic. 5. Analyze the captured traffic for DNS tunneling indicators: - Query length statistics - Subdomain entropy analysis - Query volume per domain - Record type distribution 6. Write detection rules that could identify this tunneling activity.

Expected Deliverable: Working DNS tunnel demonstration, traffic analysis with statistics, and detection rule pseudocode.

Exercise 13.7: VLAN Hopping Simulation

Objective: Understand VLAN hopping attacks and their defenses.

Instructions: 1. Set up a GNS3 or EVE-NG lab with a managed switch and two VLANs. 2. Configure one port as an access port on VLAN 10 and another on VLAN 20. 3. Attempt to communicate between VLANs directly (should fail). 4. Use Yersinia or a custom DTP frame to attempt switch spoofing on a port configured with default settings. 5. If successful, send tagged frames to access the other VLAN. 6. Implement defenses: set all ports to switchport mode access and switchport nonegotiate. 7. Verify that the attack no longer works.

Expected Deliverable: Network topology diagram, successful and defended attack documentation, and switch configuration files.

Exercise 13.8: Lateral Movement with Impacket

Objective: Practice lateral movement techniques in a Windows Active Directory lab.

Prerequisites: Windows AD lab with at least a domain controller and one member server.

Instructions: 1. From a compromised position (having obtained admin credentials), use psexec.py to gain a shell on a second system. 2. Use wmiexec.py to execute commands on a third system. 3. Use smbexec.py for a stealthier approach and compare the artifacts left by each tool. 4. Attempt pass-the-hash lateral movement using an NTLM hash instead of a plaintext password. 5. For each technique, document: - Windows Event Log entries generated - Service creation artifacts - Network traffic patterns - Detection opportunities

Expected Deliverable: Comparison matrix of lateral movement techniques with detection artifacts.

Exercise 13.9: Responder and NTLM Hash Capture

Objective: Capture NTLM hashes using Responder and understand LLMNR/NBT-NS poisoning.

Instructions: 1. Run Responder on your attacker machine in analyze mode first (-A) to observe name resolution requests without poisoning. 2. Document the LLMNR and NBT-NS requests you see. 3. Switch to active mode and capture NTLMv2 hashes. 4. Attempt to crack the captured hashes using Hashcat. 5. Research and implement defenses: - Disable LLMNR via Group Policy - Disable NBT-NS via network adapter settings 6. Verify that Responder can no longer capture hashes.

Expected Deliverable: Captured hashes, cracking results, Group Policy configuration screenshots, and before/after testing documentation.

Exercise 13.10: Layer 2 Security Hardening

Objective: Configure comprehensive Layer 2 security on a managed switch.

Instructions: Using a managed switch (physical or virtual in GNS3/EVE-NG), configure the following security features:

1. Port Security — Limit each access port to 2 MAC addresses with shutdown violation mode.
2. DHCP Snooping — Enable DHCP snooping on all VLANs and trust only the uplink port.
3. Dynamic ARP Inspection — Enable DAI with validation of source MAC, destination MAC, and IP.
4. BPDU Guard — Enable on all access ports.
5. DTP Disable — Set switchport nonegotiate on all ports.
6. Unused Port Shutdown — Administratively disable all unused ports.
7. Native VLAN — Change the native VLAN to an unused VLAN (e.g., 999).

Test each control by attempting the corresponding attack and verifying it is blocked.

Expected Deliverable: Complete switch configuration file with comments explaining each security feature.

Exercise 13.11: Wireless MITM with Evil Twin

Objective: Set up a rogue access point to understand wireless MITM attacks.

Prerequisites: USB wireless adapter supporting monitor mode and packet injection.

Instructions: 1. Use airmon-ng to put your wireless adapter in monitor mode. 2. Use airodump-ng to identify wireless networks in your lab. 3. Set up an evil twin AP using hostapd that mimics your lab's Wi-Fi network. 4. Use a DHCP server (dnsmasq) to provide network configuration to connecting clients. 5. Connect a test device to the evil twin and verify you can intercept traffic. 6. Document the detection indicators that would reveal the evil twin (BSSID analysis, signal strength anomalies).

Expected Deliverable: Evil twin configuration files, intercepted traffic samples, and detection indicator analysis.

Exercise 13.12: Network Segmentation Assessment

Objective: Evaluate network segmentation effectiveness in a lab environment.

Instructions: Design and implement a network segmentation test plan for the MedSecure lab scenario:

1. Create a network diagram with at least four VLANs (Clinical, Admin, Server, Guest).
2. For each VLAN pair, attempt the following: - Direct ping between VLANs - Port scanning across VLAN boundaries - ARP spoofing across VLAN boundaries - Service access (SMB, RDP, HTTP) across VLANs
3. Document which cross-VLAN communications succeed and which are blocked.
4. Identify segmentation weaknesses and recommend improvements.

Expected Deliverable: Network diagram, segmentation test matrix, and remediation recommendations.

Exercise 13.13: Traffic Manipulation and Injection

Objective: Modify network traffic in transit to understand the impact of MITM attacks.

Instructions: 1. Establish a MITM position using ARP spoofing. 2. Use Bettercap's HTTP proxy to inject a JavaScript alert into HTTP web pages viewed by the victim. 3. Modify the proxy script to inject a simulated keylogger (JavaScript that logs keypresses to the console, not an actual malicious keylogger). 4. Attempt the same injection against HTTPS traffic and document the result. 5. Analyze the defensive implications: why does HTTPS prevent this attack?

Expected Deliverable: Working injection demonstration, before/after screenshots, and security analysis.

Exercise 13.14: Network Intrusion Detection

Objective: Configure and test network-based intrusion detection for the attacks covered in this chapter.

Instructions: 1. Install Snort or Suricata on a network monitoring point in your lab. 2. Configure rules to detect: - ARP spoofing (duplicate MAC address alerts) - DNS tunneling (long DNS queries) - SMB-based lateral movement (PsExec service creation) - LLMNR/NBT-NS poisoning 3. Perform each attack and verify that the IDS generates alerts. 4. Tune the rules to reduce false positives while maintaining detection.

Expected Deliverable: IDS configuration, custom rules, alert samples, and tuning documentation.

🧪 Exercise 13.15: MedSecure Network Attack Simulation

Objective: Conduct a comprehensive network-based attack simulation against the MedSecure lab.

Lab Setup: - Three VLANs: Clinical (10), Admin (20), Server (40) - Domain controller, file server, and at least two workstations - A router/firewall between VLANs (can use pfSense)

Instructions: 1. Starting from the Admin VLAN, perform ARP spoofing to intercept traffic between a workstation and the gateway. 2. Capture any credentials transmitted in cleartext. 3. Use Responder to capture NTLM hashes. 4. Crack captured hashes using Hashcat. 5. Use cracked credentials for lateral movement to the Server VLAN. 6. Attempt to pivot from the Server VLAN to the Clinical VLAN. 7. Document the complete attack chain with timestamps. 8. Write a defensive recommendation report addressing each attack vector.

Expected Deliverable: Complete attack chain documentation and defensive recommendation report.

Exercise 13.16: Ethical Scenario Analysis

Objective: Practice ethical decision-making in network attack scenarios.

Instructions: Consider this scenario and write a 500-word analysis:

During the MedSecure penetration test, you are authorized to perform network-based attacks on the Admin VLAN only. While conducting ARP spoofing, you inadvertently intercept traffic from the Clinical VLAN due to a misconfigured switch that has both VLANs on the same physical segment. In the intercepted traffic, you notice unencrypted HL7 messages containing patient names, diagnoses, and medication orders.

Address: 1. What are your immediate obligations? 2. How do you handle the inadvertently captured clinical data? 3. Should this be reported as a finding even though the Clinical VLAN was out of scope? 4. What are the HIPAA implications for MedSecure? 5. How might this change the scope of the engagement going forward?

Expected Deliverable: Written ethical analysis with specific recommendations.