Unlike the ping of death or a teardrop, a Christmas tree attack is not trying to crash a host with one deformed packet; it makes each packet expensive to process and relies on rate. It is a Layer 4 (transport) attack vector, and one of the classes a thorough DDoS test is built to exercise. The attack floods a target with TCP packets that have an unusual set of header flags turned on at once, classically FIN, PSH, and URG, sometimes every flag, so the header "lights up" like a string of Christmas lights.
The lit-up header
A normal TCP packet carries a small, sensible set of flags: a SYN to open, an ACK to acknowledge, a FIN to close. The flags describe where the packet sits in the life of a connection, and the common combinations are few. A Christmas tree packet sets flags that contradict each other, a FIN that says "closing" alongside a PSH and URG that say "here is urgent data," a combination that fits no point in a real handshake.
Because the combination is outside the normal state machine, many operating-system stacks and inline devices cannot dispatch it on the fast path. They fall back to a slower branch to parse the header and decide what the packet even means, and that branch spends several times the CPU of an ordinary packet. That per-packet cost is the whole attack. Sent at a high enough rate, the target and any stateful devices in front of it exhaust their processing capacity on packets that were never going to carry useful data, and the measure of the pressure is packets per second rather than bandwidth.
Why it matters under attack
The same crafted packets have a second, older use that explains why they are well understood: fingerprinting. The TCP RFCs never fully specify how a stack should answer contradictory flags, so different operating systems answer differently. A closed port on one stack sends a reset, an open port stays silent, and a scanner can read the operating system from that pattern. The nmap "Xmas scan" is exactly this technique, which means the packet shape is documented, easy to generate, and familiar to defenders long before it is used as a flood.
As a denial-of-service vector the danger is that it targets the wrong metric. A defense sized only for link volume can miss it entirely, because a Christmas tree flood is light on the wire and heavy on the CPU. The device that fails first is usually the stateful firewall or inline appliance doing per-packet inspection, since inspecting these packets is precisely the expensive work, and when that box saturates it takes everything behind it down with it.
What a DDoS test measures
A test for this vector is not a bandwidth test but a per-packet-cost test. It measures how many malformed-flag packets per second the stack and the inline devices absorb before latency climbs or legitimate connections start to fail, and which device in the path gives way first. That packet-rate ceiling, not a throughput figure, is the resilience result.
It then checks the cheap defense. Contradictory flag combinations can be dropped by stateless filtering at the edge, before they ever reach the expensive slow path, because a packet with FIN, PSH, and URG all set is invalid by inspection and needs no connection context to reject. A good test confirms that such a filter is in place, that it drops the malformed combinations under load, and that it does so without catching the unusual-but-legitimate flag patterns real traffic occasionally carries.
For where this sits among the network-layer classes, see Understanding DDoS Attack Vectors.