Handout B: Network Traffic Analysis Report

Campus network bandwidth monitoring from July 13-20, 2001. Code Red worm scanning and DDoS attack generated unprecedented traffic volumes, paralyzing university networks.

Daily Network Traffic Statistics

Date Time Period Inbound (Mbps) Outbound (Mbps) Peak Scanning Activity Incident Status
July 12 Normal 45 38 None BASELINE
July 13 14:00-15:00 52 480 Initial Scanning INFECTION BEGINS
July 13 15:00-22:00 68 850 Rapid Growth Exponential Spread
July 14 00:00-06:00 94 1,200 Peak Scanning WORM SPREADING RAPIDLY
July 14 06:00-12:00 105 2,100 Massive Activity Campus Networks Degraded
July 14 12:00-18:00 78 3,400 Peak Bandwidth NETWORK USABILITY: 5%
July 14 18:00-23:59 120 2,850 Continued Scanning Emergency Response Mode
July 19 00:00-12:00 480 4,200 DDoS Attack Phase WHITEHOUSE.GOV TARGETED
July 19 12:00-18:00 560 3,900 Peak DDoS Traffic Sustained Attack
July 20 00:00-06:00 320 1,400 Attack Continuing Patch Deployment Underway
July 20 06:00-23:59 95 180 Declining Traffic Recovery Phase

IM NOTES (Do Not Show to Players): Key observations:

  1. Exponential Growth: Outbound traffic grows from 480 Mbps to 4,200 Mbps in 6 days. This is exponential infection – each infected server helps scan and infect more servers.

  2. Network Saturation: July 14 peak of 3,400 Mbps outbound on a university link that typically used 38 Mbps. Assuming 100 Mbps link capacity, the university network becomes completely unusable. Every scan request is a new HTTP GET request consuming bandwidth.

  3. DDoS Phase (July 19+): When the hardcoded trigger date (00:00 UTC July 19) arrives, all infected servers begin attacking 198.137.240.91 (the original White House IP address). The shift to 4,200 Mbps outbound is a sustained, coordinated attack from thousands of servers globally.

  4. Scanning Pattern: Infected servers use a pseudo-random number generator seeded with their own IP address to generate target IPs to scan. This means each server scans different targets, so scanning is distributed across the entire IPv4 address space.

Detailed Scanning Pattern Analysis

Code Red Scanning Algorithm Reconstruction:

Random IP Generation Pattern (July 13-19):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Each infected server (PRNG seeded with local IP):

  Infected Server 1 (IP: 192.168.1.X) generates:
    Target 1: 203.145.67.89  [HTTP GET /default.ida?exploit...]
    Target 2: 45.123.78.90   [HTTP GET /default.ida?exploit...]
    Target 3: 167.44.55.220  [HTTP GET /default.ida?exploit...]
    ... (random targets across IPv4 space)

  Infected Server 2 (IP: 203.100.50.X) generates:
    Target 1: 198.55.123.45  [HTTP GET /default.ida?exploit...]
    Target 2: 152.78.90.12   [HTTP GET /default.ida?exploit...]
    Target 3: 61.234.167.8   [HTTP GET /default.ida?exploit...]
    ... (different random targets)

Result: Globally distributed scanning from 300,000+ infected servers
        = Each server scanning 400+ targets per minute
        = Distributed scanning of entire IPv4 space in days
        = Impossible to block from single location

Traffic Profile per Infected Server:
  - Scanning: 40-80 HTTP GET requests/minute to random IPs
  - Infection attempts: 60-100 HTTP GET requests/minute to vulnerable targets
  - Defacement: Continuous file modification to web directory
  - Overall: Each server generating 150-300 Mbps of scanning traffic

IM NOTES (Do Not Show to Players): The scanning algorithm was the genius of Code Red:

  1. Decentralized Scanning: Unlike traditional malware C&C where a central server commands attacks, each infected server independently scanned random targets. This made it impossible to shut down by shutting down central infrastructure.

  2. Pseudo-Random but Deterministic: The PRNG was seeded based on local IP and date. This meant researchers could predict which servers would attack which targets, but couldn’t predict which servers would become infected.

  3. Birthday Paradox: With 300,000+ servers randomly scanning the IP address space, the probability of hitting vulnerable IIS servers became very high very quickly.

  4. No Network Defense: Pre-2001 network security didn’t have DDoS protection, rate limiting, or behavioral detection. Firewalls were stateless and couldn’t handle the scanning volume.

DDoS Attack Target Analysis (July 19, 2001)

Coordinated DDoS Attack on United States Government Infrastructure

Primary Target: 198.137.240.91 (White House website - www.whitehouse.gov)
Attack Duration: 19 July 00:00 UTC through 20 July 10:00 UTC
Participating Servers: ~359,000 infected IIS servers globally

Attack Pattern:
  Time Window (UTC)  | Attack Traffic | Sustained Duration | Target Status
  ───────────────────┼────────────────┼───────────────────┼────────────────
  July 19 00:00-06   | 2.4 Gbps       | 6 hours            | OFFLINE
  July 19 06:00-12   | 2.8 Gbps       | 6 hours            | OFFLINE
  July 19 12:00-18   | 1.9 Gbps       | 6 hours            | OFFLINE
  July 19 18:00-24   | 2.1 Gbps       | 6 hours            | OFFLINE
  July 20 00:00-06   | 1.6 Gbps       | 6 hours            | OFFLINE/RECOVERED

White House Response:
  - Original IP (198.137.240.91) changed within 6 hours
  - New IP (199.182.123.50) assigned by ISP
  - Attack continued against old IP (ineffective)
  - Site restored on new IP by 20 July 10:00 UTC

IM NOTES (Do Not Show to Players): Historical context:

  1. Actual DDoS Success: This is documented as one of the first successful large-scale DDoS attacks against a government site. 2.8 Gbps in 2001 was unprecedented. Modern DDoS attacks are in the 100+ Gbps range, but this was shocking at the time.

  2. IP Change Mitigation: The White House had their ISP change their IP address, which was an effective (if crude) mitigation. The malware was hardcoded to attack the old IP, so new attacks against the new IP required the worm to evolve (it didn’t).

  3. Time-Based Trigger: The hardcoded trigger date was genius for stealth. The worm spread quietly for 6 days (July 13-19), then revealed its destructive intent. This meant defenders initially had no way to predict the DDoS attack.

  4. Attribution Confusion: The attack against the White House fueled false attribution to China and β€œChinese hackers,” despite no credible evidence.

Key Discovery Questions

  • Why would infected servers attack a single IP address (the White House) starting on July 19?

The trigger date was hardcoded in the worm’s binary. The authors wanted maximum spread before launching the attack. This suggests the attack was purposeful and deliberate, not a random byproduct of the worm’s scanning behavior.

  • How did the White House respond to a 2.8 Gbps attack in 2001?

IP address change was the primary mitigation. Modern DDoS mitigation uses traffic scrubbing, rate limiting, geographic blocking, and other sophisticated techniques. In 2001, simply changing IPs was effective because the attack was hardcoded to a specific IP.

IM Facilitation Notes

This handout shows the transition from infection/scanning phase to the deliberate attack phase, helping players understand:

  • Exponential growth in worm-based attacks
  • Time-based triggers for staged attacks
  • Impact of coordinated DDoS from distributed sources
  • Government-level incident response to internet attacks