Code Red Scenario: Historical University Crisis (2001)

Code Red Scenario: University Technology Services Crisis (2001)

University Technology Services: Major research university, 15,000 students, hundreds of IIS servers
• Code Red
STAKES
University operations + Student services + Academic reputation + Network stability
HOOK
It's July 2001. Your university's IT department manages hundreds of Windows servers running IIS web services for academic departments, student services, and research projects. A new automated attack is spreading across the internet, exploiting a buffer overflow vulnerability in Microsoft IIS. The attack is hitting university web servers, defacing academic websites with 'Hacked by Chinese!' messages, and consuming network bandwidth as infected servers scan for new targets.
PRESSURE
  • Summer session disruption and potential loss of academic credibility — university websites are the public face of the institution
FRONT • 90 minutes • Intermediate
University Technology Services: Major research university, 15,000 students, hundreds of IIS servers
• Code Red
NPCs
  • Dr. Patricia Williams (IT Director): Former Bell Labs engineer managing university technology infrastructure during early internet security crisis, trying to balance academic openness with security
  • Kevin Zhang (Network Administrator): Recent CS graduate discovering that automated attacks can spread faster than manual response, learning network security under fire
  • Professor Michael Johnson (Computer Science): Faculty member whose research web server was defaced, demanding explanations about university security practices
  • Lisa Rodriguez (Student Services Manager): Fielding calls from students unable to access online registration and course materials
SECRETS
  • University policy prioritizes accessibility over security — most servers run with default configurations
  • IT staff learned about buffer overflows from security mailing lists but haven't implemented patches consistently
  • Academic culture values open networks and shared resources over strict access controls

Planning Resources

Tip📋 Comprehensive Facilitation Guide Available

For detailed session preparation support, including game configuration templates, investigation timelines, response options matrix, and round-by-round facilitation guidance, see:

Code Red Historical University Planning Document

Planning documents provide 30-minute structured preparation for first-time IMs, or quick-reference support for experienced facilitators.

Note🎬 Interactive Scenario Slides

Ready-to-present RevealJS slides with player-safe mode, session tracking, and IM facilitation notes:

Code Red Historical Scenario Slides

Press ‘P’ to toggle player-safe mode • Built-in session state tracking • Dark/light theme support

Scenario Details for IMs

Hook

“It’s July 19th, 2001 at University Technology Services, and your IT department manages hundreds of Windows IIS web servers supporting 15,000 students and hundreds of academic departments. Kevin has just noticed unusual network traffic patterns – your servers are generating massive scanning activity on port 80. Within hours, academic department websites start displaying ‘HELLO! Welcome to http://www.worm.com! Hacked By Chinese!’ messages instead of course materials and research information. Unknown to your team, you’re witnessing the first major automated worm attack in internet history, and your university servers are both victims and unwilling participants in a global attack network.”

Initial Symptoms to Present:

Warning🚨 Initial User Reports
  • “University web servers generating unusual outbound scanning traffic to random internet addresses”
  • “Academic department websites displaying ‘Hacked by Chinese!’ defacement messages”
  • “Student services and course registration systems showing unexpected error messages”
  • “Network bandwidth consumption affecting all campus internet connectivity”

Key Discovery Paths:

Detective Investigation Leads:

  • Web server forensics reveal buffer overflow exploitation of IIS indexing service (idq.dll)
  • Log analysis shows automated scanning and exploitation without human intervention
  • Timeline indicates simultaneous infection of multiple servers across campus network

Protector System Analysis:

  • Network monitoring reveals memory-resident worm propagation through IIS vulnerability
  • Server security assessment shows default configurations with unpatched systems
  • Academic network architecture evaluation reveals flat topology enabling rapid worm spread

Tracker Network Investigation:

  • Internet traffic analysis shows university servers participating in global scanning activity
  • External security community reports coordinated attack patterns across academic networks worldwide
  • Evidence of university infrastructure being used for attacks against other institutions

Communicator Stakeholder Interviews:

  • Faculty communications regarding defaced research websites and academic reputation impact
  • Student service concerns about online registration and course material accessibility
  • Academic community coordination with other universities experiencing similar attacks

Mid-Scenario Pressure Points:

  • Hour 1: Computer Science professor discovers his research project website defaced, questions IT security practices
  • Hour 2: Network administrator reports university servers are attacking other academic institutions globally
  • Hour 3: Student registration system becomes unavailable as worm consumes network bandwidth
  • Hour 4: University administration demands explanation as national media reports widespread internet attack

Evolution Triggers:

  • If response is delayed beyond 24 hours, university servers may participate in coordinated DDoS attacks
  • If containment fails, academic reputation suffers as defaced websites remain visible publicly
  • If patch deployment is inadequate, reinfection occurs as worm continues scanning campus networks

Resolution Pathways:

Technical Success Indicators:

  • Manual patch deployment stops worm propagation across university IIS servers
  • Network traffic monitoring identifies and isolates infected systems preventing further spread
  • Academic website restoration maintains summer session operations and student services

Business Success Indicators:

  • University reputation protected through rapid response and transparent communication
  • Student services maintained with minimal disruption to summer registration and course access
  • Academic operations continued demonstrating institutional technology resilience

Learning Success Indicators:

  • Team understands automated attack evolution from manual hacking to worm-based propagation
  • Participants recognize importance of patch management and security monitoring in academic environments
  • Group demonstrates incident response adaptation during early internet security crisis

Common IM Facilitation Challenges:

If Manual Patch Complexity Is Underestimated:

“Kevin needs to manually download, test, and deploy MS01-033 patches to 300+ servers without automated tools. How do you coordinate manual patch deployment across distributed academic departments?”

If Internet Attack Participation Is Ignored:

“While investigating local defacements, Patricia discovers your university servers are attacking MIT, Stanford, Berkeley, and the White House. How does this change your response priorities?”

If Academic Culture Conflict Is Missed:

“A Computer Science professor insists their research server needs public internet access without ‘restrictive’ firewalls. How do you balance academic openness with security requirements during active attack?”

Success Metrics for Session:

Understanding 2001 Technology Context

This scenario represents the actual Code Red worm attack from July 2001. Key historical elements to understand:

  • Internet Infrastructure: Much smaller, primarily academic and corporate networks
  • Security Awareness: Buffer overflow vulnerabilities were poorly understood outside expert circles
  • Patch Management: No automated update systems – all patches applied manually
  • Network Architecture: Flat networks with minimal segmentation or access controls
  • Response Capabilities: No dedicated incident response teams at most organizations

Collaborative Modernization Questions for Players

Present these questions after initial investigation to guide modernization:

  1. “How would this attack work in today’s cloud infrastructure?”
    • Guide toward: API vulnerabilities, container security, multi-tenant isolation
  2. “What would be the equivalent of ‘website defacement’ for modern applications?”
    • Guide toward: Data manipulation, service disruption, customer-facing impact
  3. “How has automated scanning and exploitation evolved since 2001?”
    • Guide toward: Modern vulnerability scanners, exploit kits, automated toolchains
  4. “What would university IT infrastructure look like today?”
    • Guide toward: SaaS services, cloud providers, mobile applications, remote learning
  5. “How would incident response be different with modern tools and practices?”
    • Guide toward: Automated detection, centralized logging, threat intelligence, coordination

Modernization Discovery Process

After historical investigation, facilitate modernization discussion:

  1. Technology Translation: Help players identify modern equivalents to 2001 technology
  2. Attack Vector Evolution: Explore how automated exploitation has advanced
  3. Impact Amplification: Discuss how interconnected systems change incident scope
  4. Response Evolution: Compare 2001 manual response to modern automated capabilities
  5. Scenario Adaptation: Collaboratively develop contemporary version

Learning Objectives

  • Historical Perspective: Understanding how cybersecurity threats have evolved
  • Technology Evolution: Recognizing parallels between historical and modern vulnerabilities
  • Incident Response Development: Appreciating advances in security practices and tools
  • Collaborative Learning: Working together to modernize historical threats for current relevance

IM Facilitation Notes

  • Start Historical: Present the 2001 scenario authentically without modern context
  • Guide Discovery: Use questions to help players discover modern parallels
  • Encourage Creativity: Support player ideas for modernization even if unconventional
  • Maintain Learning Focus: Emphasize what the historical context teaches about current threats
  • Document Evolution: Capture player modernization ideas for future scenario development
Important“Hacked By Chinese!” – Attribution Note for IMs

The defacement message “HELLO! Welcome to http://www.worm.com! Hacked By Chinese!” was hardcoded directly into the worm’s binary by its authors. It was not a real attribution to China or to Chinese state actors. Security researchers at the time found no credible evidence of Chinese government involvement. The message was widely understood in the security community as either a boast or deliberate misdirection.

If players raise the “Chinese hacking” angle, guide them to recognize it as unverified worm code – an early example of false-flag messaging embedded in malware. This is historically significant: it foreshadowed a long tradition of attribution confusion in cyber incidents, and it created real diplomatic tension despite having no verified state backing.

This historical foundation approach allows teams to learn from cybersecurity history while developing skills to analyze how threats evolve and adapt to changing technology landscapes.

Template Compatibility

Quick Demo (35-40 min)

  • Rounds: 1
  • Actions per Player: 1
  • Investigation: Guided
  • Response: Pre-defined
  • Focus: Use the “Hook” and “Initial Symptoms” to quickly establish the 2001 university crisis. Present the “Guided Investigation Clues” at 5-minute intervals. Offer the “Pre-Defined Response Options” for the team to choose from. Quick debrief should focus on recognizing first automated worm attack and manual patch management challenges.

Lunch & Learn (75-90 min)

  • Rounds: 2
  • Actions per Player: 2
  • Investigation: Guided
  • Response: Pre-defined
  • Focus: This template allows for deeper exploration of early internet security challenges. Use the full set of NPCs to create realistic academic pressure and manual response limitations. The two rounds allow worm spread across campus, raising stakes. Debrief can explore balance between academic openness and security, plus brief modernization discussion.

Full Game (120-140 min)

  • Rounds: 3
  • Actions per Player: 2
  • Investigation: Open
  • Response: Creative
  • Focus: Players have freedom to investigate using the “Key Discovery Paths” as IM guidance. They must develop response strategies balancing academic operations, manual patch deployment, network security, and internet attack participation responsibility. The three rounds allow for full narrative arc including historical context and comprehensive modernization discussion exploring how the 2001 worm evolved into contemporary threats.

Advanced Challenge (150-170 min)

  • Rounds: 3
  • Actions per Player: 2
  • Investigation: Open
  • Response: Creative
  • Complexity: Add red herrings (e.g., legitimate academic research traffic causing false positives). Make containment ambiguous, requiring players to justify manual patch decisions with incomplete vulnerability information. Remove access to reference materials to test knowledge recall of worm behavior. Include deep modernization discussion comparing 2001 manual response to contemporary automated capabilities.

Quick Demo Materials (35-40 min)

Guided Investigation Clues

Clue 1 (Minute 5): “Web server forensics reveal Code Red worm exploiting IIS buffer overflow vulnerability (idq.dll) in the university’s servers during July 2001. Network analysis shows significant increase in outbound port 80 scanning traffic from infected IIS web servers targeting random internet addresses. Academic department websites display ‘HELLO! Welcome to http://www.worm.com! Hacked By Chinese!’ defacement messages.”

Clue 2 (Minute 10): “Log analysis shows automated exploitation without human intervention – this is the first major self-propagating worm attack in internet history. Timeline indicates simultaneous infection of multiple campus servers through unpatched IIS systems. Security assessment reveals university delayed MS01-033 patch deployment due to concerns about disrupting summer academic operations.”

Clue 3 (Minute 15): “External security community reports university servers participating in global scanning activity and attacking MIT, Stanford, Berkeley, and other academic institutions. Student registration systems becoming unavailable as worm consumes network bandwidth. A Computer Science professor’s research server is defaced, demanding explanations about university security practices while insisting on maintaining open internet access without firewalls.”

Pre-Defined Response Options

Option A: Manual Patch Deployment & Server Restoration

  • Action: Download and manually apply Microsoft Security Bulletin MS01-033 patch to all 300+ affected IIS servers, coordinate physical server access across academic departments, reboot systems to clear memory-resident worm, restore defaced websites from backups.
  • Pros: Directly addresses IIS indexing service vulnerability preventing reinfection; demonstrates responsible patch management establishing security foundation for future threats.
  • Cons: Manual patch deployment extremely time-consuming requiring days for distributed academic infrastructure; server reboots disrupt summer academic operations; coordination complexity across autonomous departments.
  • Type Effectiveness: Super effective against Worm type malmons like Code Red; memory-only worm eliminated through reboot after patching prevents reinfection.

Option B: Emergency Firewall Blocking & Traffic Control

  • Action: Configure perimeter firewalls to block all outbound port 80 traffic from IIS servers except known legitimate destinations, implement emergency traffic filtering preventing worm propagation, isolate infected systems while maintaining critical academic services.
  • Pros: Immediately stops worm spread and prevents university participation in global attacks; faster than manual patching enabling rapid containment.
  • Cons: May disrupt legitimate academic web services requiring careful whitelist configuration; doesn’t address underlying IIS vulnerability enabling reinfection after firewall changes; manual firewall rule management across flat academic network.
  • Type Effectiveness: Moderately effective against Worm threats; prevents propagation but doesn’t eliminate worm or fix vulnerability; temporary containment requiring subsequent patching.

Option C: IIS Indexing Service Disable & Temporary Mitigation

  • Action: Manually disable IIS Indexing Service on all campus web servers eliminating vulnerable component, maintain basic web functionality without search features, coordinate emergency configuration changes across academic departments.
  • Pros: Immediately stops attack vector without full patch deployment; faster workaround enabling rapid response; maintains most academic web services during remediation.
  • Cons: Disables search functionality affecting some academic applications; requires manual configuration on each server; temporary workaround still requiring eventual patching.
  • Type Effectiveness: Partially effective against Worm malmon type; removes attack surface but doesn’t eliminate existing infections; requires combination with server reboots for complete remediation.

Lunch & Learn Materials (75-90 min, 2 rounds)

Round 1: Discovery & Identification (30-35 min)

Investigation Clues:

  • Clue 1 (Minute 5): Network Administrator Kevin Zhang reports that faculty are seeing defacement messages on departmental websites. “The Computer Science homepage now says ‘HELLO! Welcome to http://www.worm.com! Hacked By Chinese!’ - and it’s spreading to other departments.”
  • Clue 2 (Minute 10): Server forensics reveal exploitation of Microsoft IIS Indexing Service buffer overflow (MS01-033). The attack uses a malformed HTTP GET request that’s spreading automatically between Windows 2000 IIS servers without human intervention – it’s a worm.
  • Clue 3 (Minute 15): Network monitoring shows 300+ campus IIS servers generating massive scanning traffic to random internet IP addresses. The university is participating in a global internet-wide attack that’s overwhelming networks worldwide.
  • Clue 4 (Minute 20): IT Director Dr. Patricia Williams reveals that Microsoft released security bulletin MS01-033 two weeks ago, but patching was delayed during summer semester to avoid disrupting faculty research web servers. “We couldn’t coordinate patch deployment across 50 autonomous departments during active research projects.”

Response Options:

  • Option A: Emergency Server Reboot - Immediately reboot all affected IIS servers to clear the memory-resident worm, restore defaced websites from tape backups, delay vulnerability patching until coordinated maintenance window.
    • Pros: Fastest path to website restoration; clears active worm infections; minimal summer semester disruption.
    • Cons: Doesn’t patch the IIS vulnerability; servers will be reinfected within hours from internet scanning; requires physical access to 300+ distributed servers.
    • Type Effectiveness: Partially effective – temporarily eliminates worm but leaves systems vulnerable to immediate reinfection.
  • Option B: Firewall Emergency Rules - Configure border firewalls to block all outbound port 80 traffic from academic network except approved destinations, stop university’s participation in global attacks.
    • Pros: Immediately stops university from attacking internet; faster than manual server patching; protects university reputation.
    • Cons: May break legitimate faculty research requiring outbound web access; doesn’t fix underlying IIS vulnerability; requires careful whitelist management.
    • Type Effectiveness: Moderately effective – contains propagation but doesn’t eliminate worm or vulnerability.
  • Option C: IIS Indexing Service Disable - Manually disable IIS Indexing Service on all campus web servers to remove attack vector, coordinate across academic departments for rapid deployment.
    • Pros: Removes vulnerability without full patching; faster than MS01-033 deployment; maintains most web functionality.
    • Cons: Disables search features on academic sites; requires manual server-by-server configuration; temporary workaround still needs patching eventually.
    • Type Effectiveness: Partially effective – removes attack surface but doesn’t clear existing infections; requires reboot combo.

Round 2: Scope Assessment & Response (30-35 min)

Investigation Clues:

  • Clue 5 (Minute 30): If Option A (reboot only) was chosen: Within 90 minutes, campus servers are reinfected from internet scanning. eEye Digital Security reports university is part of 359,000 compromised systems globally. “We’re back to attacking the internet again.”

  • Clue 5 (Minute 30): If Option B or C was chosen: Faculty researchers report broken web applications due to firewall restrictions or missing search functionality. “Our genomics research portal needs to query external databases – the firewall is blocking critical research.”

  • Clue 6 (Minute 40): CERT/CC advisory reveals Code Red will trigger mass DDoS attack against www.whitehouse.gov on July 19th. University’s 300+ infected servers will participate in coordinated attack against U.S. government website unless patched.
  • Clue 7 (Minute 50): University President receives call from federal agencies about academic institution participation in attacks. “NSA and FBI are contacting universities nationwide. We need to demonstrate responsible internet citizenship.”
  • Clue 8 (Minute 55): IT analysis reveals that manual MS01-033 patch deployment to 300+ servers across 50 autonomous departments will require 5-7 days of coordinated effort during summer research season. July 19th DDoS trigger is 4 days away.

Response Options:

  • Option A: Emergency Coordinated Patching - Mobilize all IT staff for 24/7 manual MS01-033 patch deployment across entire campus, coordinate with academic departments for emergency server access, reboot all systems after patching to clear worm.
    • Pros: Completely eliminates vulnerability; prevents university participation in July 19th DDoS; demonstrates academic cybersecurity leadership to federal agencies.
    • Cons: Requires extensive disruption to summer research; 24/7 IT staff mobilization; coordination complexity across autonomous academic departments.
    • Type Effectiveness: Super effective against Worm type – eliminates vulnerability and infection preventing reinfection and DDoS participation.
  • Option B: Phased Departmental Patching - Prioritize patching of high-visibility department servers (main websites, student services), maintain containment measures (firewall/indexing disable) for remaining systems, complete full patching post-DDoS date.
    • Pros: Balances security with research continuity; protects highest-visibility systems; reduces coordination burden.
    • Cons: University still participates in DDoS with some servers; differential treatment creates vulnerability gaps; extended remediation timeline.
    • Type Effectiveness: Moderately effective – progressive improvement but partial DDoS participation remains.
  • Option C: External Academic Consortium Support - Coordinate with Internet2 and other research universities for shared response, request federal assistance through EDUCAUSE, collaborate on academic sector patching strategies and technical resources.
  • Pros: Leverages academic community resources; federal expertise accelerates response; builds higher education cybersecurity collaboration.
  • Cons: Coordination complexity across institutions; potential delays in external resource availability; admission that single institution lacks sufficient capability.
  • Type Effectiveness: Moderately effective – improves response quality through collaboration but extends timeline.

Round Transition Narrative

After Round 1 → Round 2:

The team’s initial response determines whether the university quickly returns to vulnerable operation (reboot approach) or maintains containment with research impact (firewall/indexing disable). Either way, the situation escalates dramatically when CERT/CC reveals that Code Red will trigger a coordinated DDoS attack against www.whitehouse.gov on July 19th – just days away. Federal agencies are contacting universities nationwide about their participation in this upcoming attack on U.S. government infrastructure. The team must now balance comprehensive security remediation with summer research continuity, while facing the reality that manual patch deployment to 300+ distributed servers may not be completable before the DDoS trigger date. The incident transforms from a local website defacement problem into a national security issue requiring inter-agency coordination and academic community collaboration.

Debrief Focus:

  • Recognition of first major automated worm vs manual hacking
  • Balance between academic openness and security requirements
  • Manual patch management challenges in distributed infrastructure
  • Brief discussion of modern equivalents (ransomworms, IoT botnets)

Full Game Materials (120-140 min, 3 rounds)

NoteHow Full Game Differs from Lunch & Learn

The Full Game expands the scenario from 2 guided rounds to 3 open-ended rounds. Players drive their own investigation using the Key Discovery Paths above rather than receiving timed clues. Round 3 shifts from immediate crisis response to long-term strategic recovery, and includes a collaborative modernization exercise connecting 2001 lessons to contemporary threats. Rounds run 30-35 minutes each. Use the Resolution Pathways section to guide your assessment of team progress.

Round 1: Initial Worm Discovery – July 2001 (30 min)

It’s Friday afternoon, July 13, 2001 at University Technology Services. Network Administrator Kevin Zhang notices massive outbound traffic spikes on port 80 – multiple servers scanning random internet addresses. Within minutes, calls flood in: the Computer Science department website displays ‘HELLO! Welcome to http://www.worm.com! Hacked By Chinese!’ instead of summer course information. More departmental websites follow. IT Director Dr. Patricia Williams assembles her team: ‘We’re managing hundreds of Windows IIS servers across 50 autonomous departments. And something is very wrong.’

Open investigation guidance: All four Key Discovery Paths are available. Teams typically uncover the IIS Indexing Service buffer overflow (MS01-033, patched by Microsoft two weeks ago but not deployed), the worm’s automated propagation across the university’s flat network, and the discovery that campus servers are attacking MIT, Stanford, Berkeley, and government institutions.

If the team stalls: “Professor Michael Johnson from Computer Science analyzes the malicious code: ‘This is memory-resident – running entirely in RAM without files on disk. It exploits the IIS buffer overflow to spread automatically. Our servers are scanning the entire internet for vulnerable targets. We’re the first wave of an automated attack.’”

Facilitation questions:

  • “This is 2001 – there are no automated patch deployment tools, no SIEM, no centralized logging. Every server requires manual access for patching. How does that constraint shape your response?”
  • “The university values academic openness and departmental autonomy. How do you coordinate an emergency response across autonomous units?”
  • “Campus servers are attacking other universities and government institutions – what does responsible internet citizenship look like in 2001?”

Round 1→2 Transition

CERT/CC issues emergency advisory: the Code Red worm contains a hardcoded DDoS trigger date of July 19th targeting www.whitehouse.gov. Every infected server worldwide – including the university’s 300+ compromised systems – will launch a coordinated attack against the White House website. The trigger date is 4 days away. Kevin Zhang calculates: manual patch deployment to 300+ servers across 50 departments will require 5-7 days.

Round 2: Pressure & DDoS Countdown (35 min)

If teams chose aggressive 24/7 patching: Staff mobilized around the clock for manual patch deployment. 60-70% of servers patched, but 3 departments (Computer Science, Engineering, Physics) refuse emergency access during active summer research. NSA acknowledges the effort but notes remaining unpatched servers still pose risk.

If teams chose network isolation: Campus internet connectivity severed – worm propagation stopped immediately. But all summer research requiring internet access is blocked. Faculty backlash intensifying. A Computer Science professor escalates to the Dean of Engineering: “IT is destroying academic research with excessive security paranoia.”

New developments beyond Round 1: NSA calls Dr. Williams: “We’re tracking internet-wide attack preparations. Your university has significant infected infrastructure. What’s your remediation timeline?” Student newspaper runs story about university cybersecurity failures and participation in global internet attack. Federal intelligence suggests Code Red variant may have additional capabilities beyond current understanding. 3 departments actively refuse emergency server access during grant-funded research.

Facilitation questions:

  • “The DDoS trigger is in 4 days, manual patching takes 5-7 days, and departments are blocking access – what’s your triage strategy for an impossible timeline?”

  • “Faculty see security restrictions as an attack on academic freedom – how do you frame emergency patching as protecting rather than threatening the academic mission?”

  • “Federal agencies are watching. The university’s response to this incident will define its cybersecurity reputation. What message do you want to send?”

Round 2→3 Transition

July 19th arrives. The DDoS trigger activates worldwide. Depending on remediation progress, the university either largely prevented participation or contributed to the attack. Either way, the incident exposed fundamental infrastructure weaknesses: distributed servers with no central management, manual processes that don’t scale, and academic culture resisting security controls.

Round 3: Resolution & Modernization Discussion (35 min)

The Code Red crisis resolves – but the lessons are historic. This is the first major automated worm attack in internet history, and it revealed that the entire internet infrastructure was vulnerable to automated exploitation at scale. Dr. Williams addresses her team: “We’ve navigated something unprecedented. Now we need to learn from it – both for this university and for the future.”

Part 1 – Immediate aftermath (15 min): Teams assess their response outcomes, address remaining stakeholder concerns (faculty, students, administration, federal agencies), and document lessons learned from the 2001 worm response.

Part 2 – Collaborative modernization (20 min): The IM facilitates group discussion connecting 2001 lessons to contemporary threats:

  • “How would this attack work in today’s cloud infrastructure?” → Container vulnerabilities, API exploitation, serverless security, multi-cloud complexity
  • “What’s the modern equivalent of website defacement?” → Data manipulation, service disruption, cloud resource hijacking, ransomware deployment
  • “How has automated exploitation evolved since 2001?” → Shodan and internet scanning platforms, automated exploit frameworks, zero-day markets, nation-state capabilities
  • “What would incident response look like today versus 2001?” → Automated patching, SIEM and centralized logging, threat intelligence feeds, incident response platforms

Facilitation questions:

  • “What surprised you most about responding to an automated worm with 2001-era tools and processes?”
  • “How does the Code Red worm’s automated propagation compare to modern automated attacks like Mirai or WannaCry?”
  • “What fundamental lessons from 2001 still apply to today’s cybersecurity challenges?”

Victory Conditions

  • Worm propagation stopped and DDoS participation minimized through timeline-driven remediation
  • Academic services maintained with acceptable disruption to summer operations
  • University’s internet citizenship demonstrated through responsible federal coordination
  • Meaningful modernization discussion connecting 2001 lessons to contemporary threat landscape

Debrief Focus (Full Game)

  • How Code Red (July 2001) represented a paradigm shift from manual hacking to automated worm propagation
  • Why manual patch management across distributed infrastructure doesn’t scale – the case that started the automation conversation
  • The persistent tension between academic openness culture and security requirements (still relevant today)
  • How automated attacks evolved from Code Red through Conficker, Mirai, and WannaCry – each generation building on lessons from the last
  • Why understanding historical incidents provides essential context for modern cybersecurity decision-making

Advanced Challenge Materials (150-170 min, 3+ rounds)

Red Herrings & Misdirection

  • Authorized vulnerability research – Computer Science department running a legitimate vulnerability scanner for a research project creates false positive network traffic alongside actual worm scanning
  • Planned website redesign – Physics department website was legitimately being redesigned during the incident; defacement reports confused with planned maintenance
  • Administrative remote access – routine sysadmin access from home appears suspicious in manual log review without proper context about summer maintenance schedules
  • Faculty hardware complaints – Engineering professor reports “computer acting strange” but investigation reveals unrelated hardware failure, consuming limited investigation time

Removed Resources & Constraints

  • Summer Friday skeleton crew – only 3 IT staff available when attack detected; calling in vacation staff requires significant persuasion and overtime budget
  • No automation whatsoever – 2001 means no automated patch deployment, no centralized logging, no SIEM; every forensic analysis requires physically accessing each server
  • Departmental access barriers – 3 departments refuse emergency access during active NSF-funded research; forcing access has political consequences for IT leadership
  • Primitive monitoring tools – network analysis capabilities limited to basic packet capture and manual log review; no threat intelligence feeds or automated correlation

Enhanced Pressure

  • NSA direct engagement – federal agency monitoring university’s remediation progress, creating accountability pressure with potential consequences for federal research funding relationships
  • Faculty political escalation – A Computer Science professor mobilizes a Faculty Senate resolution opposing “centralized IT security overreach that threatens academic freedom and research autonomy”
  • Media coverage expansion – national news picks up the Code Red story; university administration demands messaging that protects institutional reputation while IT focuses on technical response
  • Research data jeopardy – emergency server reboots to clear worm cause data loss for faculty who didn’t follow backup procedures, creating additional stakeholder conflicts

Ethical Dilemmas

  • Research disruption versus internet citizenship – complete network isolation stops university’s participation in global attacks but destroys active summer research with grant deadline implications; what obligation do you have to stop attacking others versus supporting your own researchers?
  • Departmental autonomy during emergency – forcing emergency access to departmental servers violates longstanding governance norms that define academic culture; respecting autonomy means unpatched servers continue attacking the internet
  • Patch delay accountability – IT delayed MS01-033 patch deployment during summer registration to avoid service disruption (reasonable at the time); who bears responsibility when prudent decisions enable catastrophic outcomes?
  • Transparent reporting versus institutional reputation – disclosing the university’s role as an attacker demonstrates accountability to the internet community but damages recruitment, fundraising, and public trust in the institution

Advanced Debrief Topics

  • How the Code Red worm of 2001 established patterns (automated exploitation, internet-scale propagation, DDoS payloads) that recur in every major worm since
  • The persistent challenge of decentralized IT governance in organizations where autonomy is a core cultural value
  • Why the 2001 response constraints (manual patching, no automation, limited visibility) are directly analogous to resource-constrained environments today
  • How federal government expectations of academic institutions during cyber incidents have evolved from 2001 to the present day
  • The evolution of “internet citizenship” from an informal norm to a formal responsibility with regulatory and legal implications

Handouts for Players