Packet Crafting Explained: Protocol Testing and Detection for CySA+

Packet crafting means constructing network packets field by field rather than letting the operating system build them. Tools such as Scapy make it programmable. It matters on the exams for two reasons: it is how several attacks and tests work, and understanding it explains what defenders should be watching for.

Why craft packets at all

A normal application hands data to the operating system, which fills in the headers according to the rules. Crafting bypasses that, letting you set any field to any value — including combinations the standards do not permit.

That has legitimate uses. Firewall rule verification: send traffic with specific characteristics and observe what gets through, which tests the rule set rather than trusting the configuration. Protocol stack testing, to see how a device handles malformed input. Detection validation, generating traffic that should trigger an IDS rule to confirm the rule works. Network troubleshooting, such as sending packets of a specific size with the Don't Fragment bit set to find the real path MTU.

That last one is genuinely useful day to day, and it is how you confirm an MTU problem rather than inferring it.

What crafted packets reveal

Firewall behaviour. The response to an unexpected packet tells you about the filtering. A TCP RST means something actively refused the connection; silence usually means a firewall dropped it; an ICMP unreachable may name the device that blocked it. The distinction between rejected and dropped is itself information, and it is why firewalls are often configured to drop silently.

Operating system fingerprinting. Implementations differ in how they handle unusual flag combinations, initial TTL values, window sizes and options ordering. Those differences form a fingerprint that identifies the OS without any banner.

Filtering rules. Varying one field at a time across a series of probes maps out which characteristics are permitted.

Spoofing, and its limits

Crafting allows arbitrary source addresses, and understanding why that is less powerful than it sounds is worth knowing.

A spoofed source means responses go to the spoofed address, not to you. That makes spoofing useless for anything requiring a reply — you cannot complete a TCP handshake or receive data.

So spoofing is useful for one-way attacks: amplification and reflection, where a small spoofed request to a third party produces a large response aimed at the victim; and flooding, where no response is wanted.

It is also why BCP 38 egress filtering matters. If every network dropped outbound packets whose source addresses do not belong to it, reflection attacks would largely stop working. The reason they persist is that many networks do not implement it — a point CompTIA raises under DDoS mitigation.

Attacks built on crafting

Recognising these by name is the exam expectation.

SYN flood — many SYNs with no completing ACK, exhausting the connection table. SYN cookies are the defence.
Reflection and amplification — spoofed requests to DNS, NTP, SNMP or memcached servers, whose larger responses hit the victim.
Fragmentation attacks — overlapping or malformed fragments to evade inspection or crash a stack.
ARP spoofing — crafted ARP replies poisoning a neighbour's cache to redirect traffic.
Christmas tree scan — a packet with unusual flags set, used for fingerprinting and occasionally for evasion.

Detecting crafted traffic

The defensive half, and what CySA+ asks.

Look for impossible or illogical flag combinations — SYN and FIN together, or no flags at all. Look for protocol violations, such as a TTL that does not match the apparent distance, or header values inconsistent with the payload. Watch for inbound packets with internal source addresses, which is a clear spoofing indicator and should be dropped at the perimeter as a matter of course. Watch for fragmentation that serves no purpose, particularly overlapping fragments. And look for rate and pattern anomalies — crafted traffic is often machine-regular in a way human-driven traffic is not.

The controls are ingress and egress filtering, anti-spoofing rules, IDS signatures for known malformed patterns, and rate limiting.

Authorisation

Sending crafted traffic to systems you do not own is unauthorised activity, whatever the intention. It is active, it appears in logs, and several of the techniques above can crash the target rather than merely probing it.

So it stays inside an authorised engagement with the target explicitly in scope, or in a lab you own. Testing your own firewall from inside your own network is fine; testing someone else's is not.

What to remember

Packet crafting constructs headers directly, which allows combinations the standards forbid. It is used legitimately to verify firewall rules, validate detections and find path MTU. Spoofing prevents you receiving replies, which is why it suits reflection and flooding but nothing interactive — and egress filtering is the structural fix. Detection looks for impossible flag combinations, internal source addresses arriving from outside, and pointless fragmentation.

Related reading: DRDoS · NTP amplification attacks · Protocol and packet analyzers