8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns

8.4 DNS Poisoning, ARP Spoofing, Exfiltration, and C2 Traffic Patterns

After scanning and floods, SAL1 Network Attacks work asks analysts to recognize poisoned name or MAC bindings, data leaving the network, and command-and-control (C2) channels. A later chapter treats C2 frameworks and shell types in more depth. Here the job is traffic: what is odd on the wire, and how you tell malware beaconing apart from boring enterprise hygiene.

DNS poisoning versus cache problems versus DGA and fast-flux

DNS poisoning (cache poisoning) is an integrity failure: a resolver stores an answer that does not come from the real authoritative owner of the name. Users type a real hostname and land on an attacker IP. Analysts rarely watch an injection live. They watch the outcome:

• A standard name (vpn.company.example, mail.company.example) resolves to an IP that is not in the known range and is not the content-delivery network (CDN) the change-management ticket listed.
• Multiple clients share the same wrong A record for the same time-to-live (TTL) window because they share a recursive cache.
• Passive DNS history, if you have a threat-intelligence platform, shows the name never used that IP before.

Contrast operational cache issues: stale records after a legitimate migration, split-horizon DNS mis-pointing internal names, a secondary that did not transfer, or a client that still uses a public resolver with an old answer. Those produce wrong IPs too, but change tickets, serial numbers on start of authority (SOA) records, and "did anyone else using a public resolver see this?" distinguish accident from attack. When in doubt, query the authoritative server from a trusted network and compare it with what the recursive resolver returned.

Two malware naming patterns are not poisoning of your cache; they are how attackers avoid stable names:

• Domain generation algorithms (DGA): malware computes many candidate domains per day; the operator registers one. Traffic shows NXDOMAIN bursts, high-entropy labels (kdj29sma-x.example), and short-lived successes. The local resolver is working; the names are disposable.
• Fast-flux: a name (or its name-server set) maps to a rapidly changing pool of A records with very short TTL, often rotating botnet hosts. The observation is churn: the same query five minutes later yields a different IP, plus hosting that does not match the brand.

ARP spoofing symptoms

Address Resolution Protocol (ARP) maps IPv4 addresses to media access control (MAC) addresses on a broadcast segment. ARP spoofing (ARP cache poisoning) is the usual LAN MitM from section 8.3: a host claims to own the gateway's IP, or claims to own a victim IP, so frames go to the attacker's network interface.

Analyst symptoms — still not a how-to:

• Duplicate IP alerts from the OS or network access control: two MACs claiming 192.0.2.1.
• Gateway MAC change: the default gateway IP suddenly maps to a workstation vendor organizationally unique identifier (OUI) instead of the switch or firewall OUI that it mapped to yesterday. Compare ARP tables across several hosts; if they all flipped to the same strange MAC, the LAN is in the middle of a spoof.
• Dynamic Host Configuration Protocol (DHCP) or 802.1X logs showing a port that should be a PC emitting gratuitous ARP for the gateway.
• Switch content-addressable memory (CAM) tables: the gateway MAC appearing on an access port.

Wireless and cloud virtual networks may not use classic ARP the same way; still, "who owns this IP at layer 2?" is the question. Section 8.3's TLS-intercept story can combine with ARP MitM: once frames are diverted, an attacker can present a fake certificate. On managed laptops, certificate errors are the user-visible half.

Data exfiltration as traffic

Exfiltration is unauthorized data leaving the trust boundary. You rarely see the file name in netflow. You see shape.

• Volume: a workstation that usually sends 50 MB per day to the internet suddenly pushes 8 GB to a single foreign IP. Baseline matters.
• Unusual ports: large outbound on 22, 4443, 8443, 53, or high ephemeral ports when corporate policy says proxy 443 only. Port 443 can still exfiltrate (HTTPS to object storage); then you need Server Name Indication (SNI) or domain, not just the port.
• Timing: a transfer at 02:15 from a finance PC that is not a backup node.
• DNS tunneling (conceptual): data stuffed into DNS labels or TXT queries so that the only allowed protocol (DNS to a resolver) becomes a covert channel. Observations: extremely long subdomain labels, high query rates from one host, query types the site barely uses (TXT, NULL, repeated TXT), and a domain that is not a real software-update service. You do not need to build a tunnel to recognize that this host's DNS profile looks like a pipe.

Pair with host telemetry when you have it: a user copying a file to a personal cloud is a policy incident; a service account doing the same without a change ticket is worse. This section stays on the network view.

C2 beaconing, including a worked comparison

Command and control (C2) is how malware receives instructions and sometimes how it returns output. Beaconing is periodic check-in. Many implants add jitter (randomized delay) so the period is not a perfect metronome.

Typical beacon observations:

• Connections to the same destination (IP or domain) at a roughly constant interval, for example every 60 seconds plus or minus 20 percent jitter.
• Small, similar byte counts (a few hundred to a few thousand bytes) unless a tasking download occurs.
• Long lifetime: hours to weeks.
• Destination is rare in the enterprise, newly registered, or categorized as unknown.
• TLS may be used; SNI and certificate may not match a known vendor.

Worked example: beacon versus a five-minute software update check

Fictional host ws-014.northwind.example (user workstation). Two hypotheses arrive from a SIEM "periodic outbound" correlation.

Hypothesis A — update agent. Every five minutes the host connects to updates.vendor-cdn.example (known software vendor). SNI matches. The certificate chains to a public CA the vendor has used all year. Byte counts are usually about 2 KB (a nothing-to-install poll). Once a week the same conversation jumps to about 15 MB when a patch is published, and dozens of other workstations do the same within an hour. The interval is exact (300 seconds) because the vendor agent uses a simple timer with no jitter. Firewall policy already allowlists the CDN. Endpoint inventory says the agent is installed. The line chart in this section is that story: small polls, then a 15,000,000-byte spike at 00:15, then small polls again.

Hypothesis B — C2 beacon. Every about 300 seconds plus or minus 40 seconds the host connects to cdn-media-93.example (domain created 11 days ago, no vendor relationship). Byte counts cluster at 1.7–2.1 KB every time; there is never a large patch payload. No other workstation talks to that domain. The TLS certificate is a generic cheap cert for a different name. The interval histogram is a bump around 300 seconds with spread — jitter — not a spike on exact 300. After three hours a single 80 KB POST appears (possible tasking).

Decision: Hypothesis A is a software update check. Hypothesis B is beacon-like and deserves isolation plus host forensics. The discriminating features were destination identity, fleet-wide peers, payload variance, and jitter, not the mere fact of a five-minute timer.

Write the case as periodic small flows, jitter present or absent, destination reputation, and whether a control channel could be hiding in DNS or in oversized ICMP echo (same idea: protocol abuse). Escalate when the pattern is persistent, rare, and inconsistent with inventory. Named C2 frameworks and reverse shells belong in later study; this section's pass bar is that you can tell a metronome to a stranger from a vendor's five-minute "still alive, no patch" poll.