Detecting ARP Spoofing

ARP (Address Resolution Protocol) maps IP addresses to MAC addresses in a local network. When a device wants to send data to another IP, it first asks: "Who has this IP?” The correct device replies with its MAC address.

In ARP spoofing, an attacker sends fake ARP replies to trick devices into associating the attacker’s MAC address with a legitimate IP, usually the default gateway. This allows the attacker to intercept, modify, or redirect traffic.

• Why ARP Spoofing Works
  • ARP has no authentication. Any device can send unsolicited is-at messages. An attacker exploits this vulnerability by sending fake ARP replies to victims and gateways:
    • Example: 192.16.10.100 is at 02:fe:BB:cd:55:55 attacker claims to be the gateway.
    • Results:
      • The Victim's ARP cache becomes poisoned.
      • All traffic intended for the gateway flows through the attacker first (MITM).
• Indicators of the Attack
  • Duplicate MAC-to-IP Mappings: Multiple MAC addresses claiming the same IP address. Indicates impersonation.
  • Unsolicited ARP Replies: High number of ARP replies without matching requests ("gratuitous ARP").
  • Abnormal ARP Traffic Volume: A Large number of ARP packets in short intervals.
  • Unusual Traffic Routing: Traffic rerouted through the attacker’s MAC.
  • Gateway Redirection Patterns: Multiple destination MACs for the same gateway IP.
  • ARP Probe / Reply Loops: Many ARP requests with Who has 192.168.1.x? Tell 192.168.1.y patterns.
• Network Traffic Analysis
  • arp - You’ll see requests and replies (who-has and is-at) pointing to both ARP requests and responses. We can examine the results for any abnormal and repeated requests or responses. Important Note: Press CTRL + ALT + 1 to fix the time displayed.
  • arp.opcode == 1 - This shows all the ARP requests captured from different hosts.
  • arp.opcode == 2 - Forged ARP poisoning typically uses unsolicited is-at replies (gratuitous/unasked replies). These are strong indicators. Let's look at the ARP response
  • arp.isgratuitous - A suspicious host sends many unsolicited (gratuitous) ARP replies, especially to multiple destinations. Repeated gratuitous ARPs can indicate an attacker maintaining their poison state.
  • ARP traffic associated with the Gateway
    • arp && arp.src.proto_ipv4 == 192.168.10.1 && eth.src == 02:aa:bb:cc:00:01 - We have the information about the IP and the MAC address associated with the gateway. Let's apply the following filter to examine the ARP traffic associated with the gateway
    • arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1 - we can see some ARP replies pointing the Gateway's IP to the suspicious MAC address. The frequency of these ARP replies indicates that this is indeed an ARP spoofing.
    • arp.opcode ==2 && _ws.col.info contains "192.168.10.1 is at" - Confirm the same result (come il filtro precedente)
  • Examining the suspicious MAC address
    • arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.10.1 && eth.src == 02:fe[REDACTED] - The result clearly confirms that the attacker spoofs ARP
    • arp.duplicate-address-detected || arp.duplicate-address-frame - This result indicates that the attacker successfully performed ARP spoofing and positioned himself between the victim and the gateway.

Unmasking DNS Spoofing

DNS Spoofing (or DNS Cache Poisoning) è una tecnica di attacco informatico che mira a ingannare il sistema DNS per reindirizzare gli utenti verso siti falsi o controllati dall’attaccante, invece che verso quelli legittimi. Il DNS cache poisoning avviene quando un attaccante riesce a inserire informazioni DNS false nella cache di un server DNS.

• How it works
  • The Victim tries to visit their bank at my-real-bank.com.
  • The Attacker, who is already on the local network (perhaps via ARP spoofing), intercepts the victim's DNS query.
  • The Spoof: The attacker quickly sends a fake DNS response to the victim. This fake response says, my-real-bank.com is at my IP address
  • The Interception: The victim's computer trusts this fake response and saves it in its DNS cache. When the victim tries to connect to their bank, they unknowingly connect directly to the attacker's server, which might host a perfect replica of the real banking site.
  • The attacker is now in the middle, capturing everything the victim types, including their username and password.
• Indicators of the Attack
  • Multiple DNS responses for the same query: A legitimate resolver and a forged responder reply to the same query. This is the single most reliable indicator.
  • DNS response from an unexpected source: A DNS reply arrives from an IP address that does not match any configured resolver (like 8.8.8.8 or your DNS server).
  • Suspiciously short TTL (Time-To-Live) values: Attackers use very low TTLs (1 - 30s) to keep poisoned entries short-lived and reassert control.
  • Unsolicited DNS responses: A DNS reply appears without a corresponding DNS request from the victim.
• Network Traffic Analysis
  • dns - This will allow us to inspect requests/replies and notice abnormal volume or patterns.
  • dns.flags.response == 1 && ip.src == 8.8.8.8 - Legitimate DNS servers (like Google’s 8.8.8.8) respond from a known external IP address. By filtering responses from this IP, we can see what normal answers look like for comparison.
  • dns.flags.response==1 - we can hunt for responses from IP addresses other than the usual DNS server
  • dns && dns.qry.name == "corp-login.esempio-corp.local" - Let's now take a curious look at the DNS traffic for our domain of interest
  • dns.flags.response == 1 && ip.src == 8.8.8.8 && dns.qry.name == "corp-login.esempio-corp.local" - The output also looks very much normal, as expected.
  • dns.flags.response == 1 && ip.src != 8.8.8.8 && dns.qry.name == "corp-login.esempio-corp.local" - This is what DNS spoofing looks like. It shows a system within the network acts as a rogue DNS server, sending spoofed DNS responses.

Spotting SSL Stripping in Action

SSL stripping is a man-in-the-middle technique in which an attacker intercepts and modifies traffic to remove or prevent TLS encryption between a client and a server. This causes the client to communicate over HTTP instead of HTTPS. The attacker retains a secure (HTTPS) session with the server while relaying plain HTTP to the victim, enabling eavesdropping and credential capture.

• How It Works
• The victim initiates an HTTPS request to a website.
• The attacker intercepts the request using ARP spoofing or a rogue access point.
• The attacker connects to the website over HTTPS but relays the response to the victim through HTTP.
• The victim unknowingly interacts over HTTP, exposing sensitive data in plaintext.
• Indicators of SSL stripping
  • Initial Request vs. Response: The user's initial request may be for HTTPS (port 443), but the subsequent packets immediately shift to unencrypted HTTP (port 80) for the same domain.
  • Redirects/Link Rewriting: Monitoring for redirects (HTTP Status Codes 301, 302) that persistently direct an HTTPS request to an HTTP resource.
  • Certificate Errors: Although the attacker usually tries to hide this, the initial TLS/SSL Handshake may fail or display a self-signed certificate if the attacker uses a more direct proxying technique.
• Network Traffic Analysis
  • tls || ssl - We start by isolating it using the following filter. This will allow us to inspect SSL requests and notice abnormal volumes or patterns.
  • tls.handshake.type == 1 && tls.handshake.extensions_server_name == "corp-login.esempio-corp.local" - Let's apply the following filter to show the established TLS handshakes to our server, which proves the site normally uses TLS for communication.
  • dns.flags.response == 1 && ip.src == 192.168.10.55 && dns.qry.name == "corp-login.esempio-corp.local" - Let's isolate DNS responses from the attacker to show the victim was pointed to the attacker's IP"
  • http && ip.src == 192.168.10.10 && ip.dst == 192.168.10.55 - One of the main indicators of SSL stripping is that, after the spoof, the domain no longer performs TLS handshakes to the legitimate server, which validates the absence of TLS traffic from the victim to the real server. Let's apply the following filter on the server IP and the attacker IP
  • We can also identify the user's credentials in plaintext, which confirms that the attacker was able to obtain the victim's credentials. Though there are other SSL stripping indicators as well that we should be looking at. In this scenario, we only observed one indicator, where HTTPS traffic of our portal was stripped down to HTTP.

Summary:

1. ARP Spoofing (cache poisoning)
2. DNS Spoofing (forged DNS responses)
3. SSL Stripping (TLS downgrade / credential capture)