Large Group Artifacts: Stuxnet – Manufacturing Deadline

Team-specific evidence cards for Multi-Team Coordination format (12-15+ players). Print all cards, sort by team and tier, and keep face-down until the release point for each round. One set per team – do not mix teams.

Organization: TechCore Semiconductors (US defense contractor).

Tier 1 – Initial Indicators

Release at start of Round 1

Alpha x2 – Bravo x2 – Charlie x2

ALPHA – Initial Indicator 1: USB-Origin Malware on SCADA Workstation

Type: Antivirus detection + USB device log Source: Endpoint AV, MFG-WS-001, Wednesday 08:15 UTC

AV Alert -- MFG-WS-001 -- 08:15 UTC
File detected : ~WTR4132.tmp (USB staging file)
Location      : C:\Windows\Temp\
Classification: Stuxnet-derived ICS malware (Siemens WinCC target)
Action        : File quarantined -- but DLL injection to Step 7 may have already occurred

USB device history (MFG-WS-001):
  2026-02-17 07:44 UTC  USB mass storage inserted -- VID_0781 (SanDisk)
  2026-02-17 07:45 UTC  ~WTR4132.tmp written from USB to C:\Windows\Temp\
  2026-02-17 07:45 UTC  Autorun executed
  2026-02-17 07:46 UTC  USB removed
  Device serial: 4C530002120831101133 -- NOT in company device inventory

AV action: Quarantine of detected file completed at 08:15 UTC.
Note: Quarantine removes the USB dropper. DLL injection into running Step 7
      processes occurs in memory -- AV cannot reverse that post-execution.

The USB drive serial number does not appear in the company’s approved device inventory. engineer.r (Ryan Cho, production engineer) has confirmed he found a USB drive in the parking lot on Monday morning and plugged it into MFG-WS-001 to see what was on it.

Analysis direction: This is the original Stuxnet propagation method – a USB drive in a facility parking lot, designed to be found and plugged in. The drive was not random. It was targeted at this facility specifically. ~WTR4132.tmp is the classic Stuxnet staging filename. The payload was already delivered before AV detection.

ALPHA – Initial Indicator 2: Step 7 Project File Modification – PLC Code Changed

Type: Siemens Step 7 project audit Source: MFG-WS-001 Step 7 project file system, 08:45 UTC

Siemens Step 7 project files -- modification timestamps:

  LineA_Production.s7p
    Last modified : 2026-02-17 07:46 UTC  [ALERT: same minute as USB autorun event]
    Previous save : 2026-01-08 14:22 UTC  [legitimate engineer save -- 40 days prior]
    Modified by   : SYSTEM process (not engineer account)

  LineB_Production.s7p
    Last modified : 2026-02-17 07:47 UTC
    Previous save : 2026-01-09 09:15 UTC  [legitimate engineer save]
    Modified by   : SYSTEM process (not engineer account)

Change management system: NO entries for either file on 2026-02-17
Step 7 IDE audit log : NO engineer session open at 07:46--07:47 UTC
Engineer.r session  : Explorer.exe only -- no Step 7 IDE activity at that time

Two Step 7 project files were modified at 07:46 and 07:47 UTC. No engineer had the Step 7 IDE open. No change management record exists. The modifications were attributed to a SYSTEM process, not any user account.

Analysis direction: The PLC code for Line A and Line B has been running modified logic since February 17 – 18 days ago. Any component produced on those lines since February 18 may be defective. The question is not just “what changed” but “how much was produced under modified conditions.”

BRAVO – Initial Indicator 1: SCADA Readings vs. Physical Reality

Type: SCADA telemetry comparison

Source: QC Manager James Liu trigger + OT team investigation, 08:20 UTC

Automated SCADA display (Line A, 08:10 UTC reading):
  Spindle RPM    : 4,200 RPM     (within spec: 4,100 -- 4,300)
  Machining pass : 98.7%         (spec: >97%)
  Temperature    : 62°C          (within spec: 55 -- 70°C)
  Coolant flow   : 14.2 L/min    (within spec: 13 -- 15 L/min)

Physical measurement of morning production run (08:10 UTC):
  Inner diameter : 12.003"       (spec: 12.000" +/- 0.001")
  Out-of-tolerance: YES          (exceeds +/-0.001" spec)
  Sample size    : 23 of 30 parts out of spec (77% failure rate)

SCADA verdict : PASS
Physical gauge: FAIL

The SCADA system is reporting normal production parameters and a 98.7% pass rate. The physical parts are failing at 77%.

Analysis direction: The SCADA is lying. Something between the PLC and the SCADA monitoring system is intercepting sensor readings and substituting nominal values. The physical parts are the ground truth. Everything SCADA reports about Line A since February 17 should be treated as falsified.

BRAVO – Initial Indicator 2: OT Network Architecture – Air Gap Status

Type: OT/IT network topology assessment

Source: Security Officer Maria Rodriguez + IT team, 09:00 UTC

Network topology summary:

Corporate IT network  10.20.10.0/24
  Contains: TCS-DC-01, corporate workstations, email, ERP system
  Status: No Siemens software installed -- not targeted by this malware variant

OT / Manufacturing floor  10.20.30.0/24
  Contains: MFG-WS-001, MFG-WS-002 (SCADA), PLC-LINE-A1, PLC-LINE-A2, PLC-LINE-B1
  Air gap status: PARTIAL -- not a true air gap

IT <-> OT boundary:
  Firewall  : YES
  Exception : Port 4840 (OPC-UA) permitted -- IT to OT and OT to IT
  Purpose   : ERP production data sync (added 2023-11-14)
  Auth      : Anonymous session -- no credential requirement
  Encryption: None (OPC-UA Classic, unencrypted)
  Audit log : NOT ENABLED on OPC-UA server

USB attack path (confirmed used):
  Physical: USB drive inserted at MFG-WS-001 keyboard -- bypasses all network controls

A port 4840 OPC-UA path connects the corporate IT network to the manufacturing OT network, added 2023-11-14, with no authentication and no audit logging. The USB attack vector did not traverse this path.

Analysis direction: The air gap is not an air gap. USB was the actual attack vector, but the architecture assumption of “we’re air-gapped so OT is safe” was already false before this incident. The unauthenticated OPC-UA path is a live vulnerability that needs immediate assessment.

CHARLIE – Initial Indicator 1: Production Halt – Defense Delivery Deadline

Type: Manufacturing and contract status

Source: Manufacturing Director Sarah Park + Contract Officer Colonel Michael Kim, 09:15 UTC

Production status (Wednesday morning):

Line A: HALTED – pending investigation of defective components
Line B: HALTED – SCADA data for Line B also under suspicion
Line C: Running (different PLC family, not affected)

Contract: TechCore Semiconductors holds a $50M DoD contract to deliver 2,400 precision navigation component housings. Delivery status:

Batch	Quantity	Shipped	Status
Batch 1	800 units	✓ Delivered Jan 15	Under review
Batch 2	800 units	✓ Delivered Feb 10	Under review
Batch 3	800 units	In production	HALTED

Contract delivery deadline: Friday 17:00 UTC

Colonel Michael Kim has been notified. He is requesting a preliminary assessment by Wednesday 14:00 UTC on whether Batches 1 and 2 meet spec.

Analysis direction: 1,600 units have already been shipped. If the PLC modification has been running since February 17, Batch 2 was almost entirely produced under compromised conditions. Batch 1 (January 15 delivery) may be clean – it predates the February 17 USB incident. Production date correlation is the most urgent analytical task.

CHARLIE – Initial Indicator 2: Regulatory Notification Obligations

Type: Compliance and legal brief

Source: Contract Officer Colonel Michael Kim (DoD) + TechCore Legal, 09:30 UTC

TechCore Semiconductors is subject to:

ITAR (International Traffic in Arms Regulations): TC-2200 navigation housings are on the US Munitions List. Any compromise requires notification to State Department DDTC (Directorate of Defense Trade Controls).
DFARS 252.204-7012: Defense contractor cybersecurity clause – breach notification to DoD within 72 hours of discovery via DIBNet portal.
NIST 800-171: Required controls for Controlled Unclassified Information (CUI) – incident documentation required.

DFARS clock: Incident discovered Wednesday 08:10 UTC. Notification due Saturday 08:10 UTC.

Colonel Kim’s preliminary statement: “If the affected components were installed in navigation systems and perform out of spec, this is a safety-of-flight and mission-reliability issue. We need a definitive answer on Batches 1 and 2 before I can advise my program office.”

Analysis direction: The 72-hour notification window is running. Filing a preliminary notification today – even without complete findings – is the legally correct and strategically sound choice. It protects cleared contractor status. Waiting for complete forensics before notifying risks a compliance violation on top of the technical incident.

Tier 2 – Deep Analysis

Release at start of Rounds 2 and 3 (3 cards per team)

Alpha x3 – Bravo x3 – Charlie x3

ALPHA – Deep Analysis 1: PLC Modification – What the Malware Actually Changed

Type: Step 7 project file diff analysis Source: ICS security specialist (external, brought in at 10:00 UTC), 12:30 UTC

Comparison of Line A PLC programming (PLC-LINE-A1) – before and after February 17:

MODIFIED FUNCTION BLOCK: FB_SpindleControl
File: LineA_Production.s7p

Original logic (January 8 save):
  Setpoint_RPM    := Process_RPM_Target    // Use operator setpoint directly
  Motor_Drive_CMD := Setpoint_RPM          // Send setpoint to motor drive

Modified logic (February 17, injected by malware):
  IF Production_Active THEN
    Setpoint_RPM    := Process_RPM_Target * 1.07  // Run 7% FASTER than setpoint
    Motor_Drive_CMD := Setpoint_RPM
    SCADA_RPM_Feedback := Process_RPM_Target      // REPORT nominal value, not actual
  ELSE
    Setpoint_RPM    := Process_RPM_Target          // Normal when idle
  END_IF

LineB_Production.s7p modification (PLC-LINE-B1):
  Coolant_Flow_CMD := Coolant_Setpoint * 0.88      // Run 12% LESS coolant
  SCADA_Coolant_Feedback := Coolant_Setpoint       // REPORT nominal value

SCADA operator view: 4,200 RPM / 14.2 L/min  (both within spec)
Physical reality:    4,494 RPM / 12.5 L/min  (over-speed + under-cooled)

Spindle motors run 7% above target RPM during active production. Coolant flow on Line B is reduced to 12.5 L/min. SCADA masking reports nominal values for both parameters.

Analysis direction: The modifications are precise and surgical. This is not opportunistic malware – someone understood the manufacturing process parameters well enough to know that 7% over-speed and 12% coolant reduction would produce out-of-tolerance parts while staying within automated QC noise. This was designed by someone with knowledge of the specific production specs.

ALPHA – Deep Analysis 2: Batch 1 vs. Batch 2 – Production Date Forensics

Type: Production log correlation Source: ERP production records + Step 7 modification timestamp, 13:00 UTC

PLC modification event: 2026-02-17 07:46 UTC

Batch 1 -- production history:
  Line A active dates : 2025-12-14 through 2026-01-12
  Shipped             : 2026-01-15
  PLC modified        : NOT at time of production (modification 2026-02-17)

Batch 2 -- production history:
  Line A active dates : 2026-01-20 through 2026-02-08
  Shipped             : 2026-02-10
  PLC modified        : NOT at time of production (modification 2026-02-17)

Batch 3 -- current production:
  Line A started      : 2026-02-18 (day after USB event)
  PLC modified        : ACTIVE since 2026-02-17
  All production since Feb 18 is under modified logic
  Quantity produced   : ~480 units (not yet shipped)
  Physical QC sample  : 23 of 30 units out of spec (77% failure rate)

ERP production log integrity: Verified against backup -- no evidence of log tampering.

Both shipped batches were produced before the PLC modification date of 2026-02-17. The approximately 480 units of Batch 3 are still in the facility.

Analysis direction: Both shipped batches predate the PLC modification. The compromise arrived on February 17 – Batch 2 was delivered on February 10. The defective production is limited to Batch 3, which is still in the facility. This is the most important finding of the investigation – the 1,600 components at DoD are very likely clean.

ALPHA – Deep Analysis 3: Malware Attribution and Scope of Infection

Type: Malware forensics + threat intelligence correlation Source: ICS security specialist + external threat intelligence, 13:00 UTC

Malware sample (extracted from MFG-WS-001 memory):
  Hash           : 1635d0d4b02c5f6a23bab95fe7803f4e
  Classification : Stuxnet B -- modified ICS sabotage toolkit
  Original 2010  : Targeted Siemens S7-315 (uranium enrichment centrifuge RPM)
  This variant   : Modified for S7-315 in precision machining -- RPM + coolant
  Dropper name   : ~WTR4132.tmp (unchanged from original Stuxnet)
  Complexity     : 4 zero-day exploits in original; this variant uses 2

Scope of infection within facility:
  MFG-WS-001 (SCADA #1, Line A + B) : INFECTED -- Step 7 modified, active
  MFG-WS-002 (SCADA #2, Line C)     : Infected -- but S7-417 not targeted
  TCS-DC-01 (domain controller)     : NOT infected (no Siemens software)
  Corporate workstations             : NOT infected (no WinCC/Step 7)

PLC status:
  PLC-LINE-A1 : MODIFIED (spindle RPM +7%, SCADA masking active)
  PLC-LINE-A2 : MODIFIED (same pattern as A1)
  PLC-LINE-B1 : MODIFIED (coolant -12%, SCADA masking active)
  PLC-LINE-C1 : NOT TARGETED (Siemens S7-417 model -- different architecture)

Attribution: Parking lot USB delivery + precision manufacturing targeting +
             nation-state capability required. CISA notification recommended.

Infection is present on MFG-WS-001, MFG-WS-002, and the three Siemens S7-315 PLCs. TCS-DC-01 and corporate workstations are not infected (no WinCC or Step 7 installed). PLC-LINE-C1 uses a Siemens S7-417 and is not targeted by this variant.

Analysis direction: The compromise is contained to the Siemens S7-315 PLCs and their SCADA workstations. Line C is unaffected and can continue production. The domain controller and corporate network are clean. Scope is narrow – but the attacker’s prior knowledge is deeply concerning.

BRAVO – Deep Analysis 1: PLC Reprogramming – What Recovery Requires

Type: OT recovery assessment Source: ICS security specialist + Siemens technical support, 13:30 UTC

To restore safe production, three sequential steps are required:

Step 1 -- Restore original PLC programs
  Source    : Step 7 project archive, TCS-BAK-01 (January 8 backup -- hash verified)
  Method    : Upload original .s7p files to each PLC via clean engineering workstation
  Constraint: CANNOT use MFG-WS-001 or MFG-WS-002 (both infected)
              Need a clean laptop with Step 7 licensed -- Siemens support can provide
  Time      : ~45 minutes per PLC (3 PLCs = ~2.5 hours total)

Step 2 -- Verify PLC firmware integrity
  Risk      : Stuxnet variants can modify PLC firmware in addition to project code
  Method    : Compare PLC firmware hash against Siemens reference hash table
  Requires  : Siemens technical support (on-call, available within 1 hour)
  Time      : ~30 minutes per PLC

Step 3 -- Physical production verification
  Run test batch of 10 units under restored PLC logic
  Physically measure each unit -- confirm dimensions match SCADA reading
  No discrepancy = cleared for production restart
  Time      : ~4 hours (production run + measurement)

Total estimated time: 8--10 hours from start to verified production

Contract deadline: Friday 17:00 UTC. Current time: Wednesday 13:30 UTC. Available window: ~51 hours.

Analysis direction: Recovery is feasible before the Friday deadline – if it starts now. The constraint is the clean engineering workstation. MFG-WS-001 and MFG-WS-002 are both compromised and cannot be used to reprogram the PLCs. A clean laptop with Step 7 installed is needed immediately.

BRAVO – Deep Analysis 2: IT/OT Boundary – OPC-UA Path Analysis

Type: Network forensic review Source: IT Infrastructure team, 14:00 UTC

OPC-UA firewall rule (added 2023-11-14):
  PERMIT tcp  10.20.10.0/24 → 10.20.30.0/24  port 4840 (OPC-UA request)
  PERMIT tcp  10.20.30.0/24 → 10.20.10.0/24  port 4840 (OPC-UA response)
  Purpose   : ERP (corporate IT) reads production counts from SCADA (OT)
  Auth      : Anonymous session (no credential required)
  Encryption: None -- OPC-UA Classic protocol, cleartext
  Audit log : NOT ENABLED on OPC-UA server

30-day traffic review (corporate IT → OT via port 4840):
  ERP server (10.20.10.011) → SCADA:    Normal production sync (expected)

  ADMIN-WS-012 (10.20.10.044) → MFG-WS-001:4840:
    2026-02-11  19:44 UTC  Duration: 2 min
    2026-02-14  20:12 UTC  Duration: 4 min
    2026-02-16  19:58 UTC  Duration: 1 min
    Source: Not the ERP server -- this is an admin workstation

  No other anomalous connections identified in 30-day window.

Three after-hours OPC-UA sessions from ADMIN-WS-012 (not the ERP server) to MFG-WS-001. The sessions span three consecutive business days ending one day before the USB event. The OPC-UA server had no audit logging enabled.

Analysis direction: The USB vector got the malware in. But someone was also using the OPC-UA path to connect to the OT network from a corporate workstation, after hours. This may be unrelated (misconfigured scheduled task) or a second access path. It needs investigation before it can be ruled out.

BRAVO – Deep Analysis 3: Line C – Only Unaffected Production Line

Type: Production capability assessment

Source: Manufacturing Director Sarah Park + OT team, 14:30 UTC

Line C status assessment:

PLC model  : Siemens S7-417 (higher series -- not targeted by this Stuxnet variant)
SCADA host : MFG-WS-003 (separate from MFG-WS-001/002 -- not infected)
Products   : TC-4400 series precision housings (different geometry from TC-2200)
Contract   : TC-4400 series is NOT part of the defense contract
Production : Running normally -- physical QC measurements MATCH SCADA readings
Verification: 15 of 15 sample units within spec, physical vs. SCADA agreement confirmed

MFG-WS-003 AV scan: Clean (Siemens WinCC not installed -- not a target)
MFG-WS-003 USB log: No unauthorized USB insertions in 90-day history

Recovery path for Lines A and B:
  1. Source: TCS-BAK-01 Step 7 archive (January 8 backup -- verified clean)
  2. Tool  : Clean laptop with Step 7 (Siemens support: remote license provision confirmed)
  3. Verify: Physical run of 10 units before production restart
  4. OPC-UA: Restrict port 4840 to ERP server IP only (immediate firewall change)

Line C is running. TC-4400 components have different geometric tolerances from TC-2200 defense contract units and are not interchangeable. TCS-BAK-01 has no Siemens software installed and is confirmed uninfected.

Analysis direction: Line C continuing to run is a minor business continuity positive but does not help with the defense contract. The full recovery path runs through the Step 7 archive on TCS-BAK-01 and a clean engineering workstation. Both are available – the constraint is time, not capability.

CHARLIE – Deep Analysis 1: Batch Integrity – Shipped Component Safety Assessment

Type: Quality engineering analysis

Source: QC Manager James Liu, 14:00 UTC

Component specification: TC-2200 precision navigation housing, inner diameter 12.000” ± 0.001”

Based on PLC modification timeline (February 17 – present) and batch production dates:

Batch	Quantity	Production period	PLC modified during production?	Physical QC result
Batch 1	800 units	Dec 14 – Jan 12	No	Not yet re-inspected
Batch 2	800 units	Jan 20 – Feb 8	No	Not yet re-inspected
Batch 3 (partial)	~480 units	Feb 18 – present	Yes	23/30 samples out of spec (77%)

Physical re-inspection of 30 Batch 3 samples: 23 of 30 (77%) out of spec by 0.002–0.004” on inner diameter.

Batch 3 is entirely within the facility – none shipped to DoD yet. All 480 suspect units have been quarantined pending full re-inspection.

Retained test samples from Batches 1 and 2 are available per QC protocol (10% of each batch).

Analysis direction: The key message for the contract officer: the 1,600 already-delivered units are very likely clean, and there is physical evidence to support that (retained samples + production dates). The defective production (480 units) is still on-site. This is the best possible outcome for the customer relationship.

CHARLIE – Deep Analysis 2: Regulatory Notification Strategy

Type: Compliance and legal strategy

Source: TechCore General Counsel + External ITAR Counsel, 14:30 UTC

DFARS 252.204-7012 – Preliminary notification (file immediately):

Submit via DIBNet portal within 72-hour window
Content: “TechCore Semiconductors experienced a cybersecurity incident affecting operational technology systems. Investigation ongoing. Production impact identified. No CUI exfiltration confirmed at this time.”
This filing satisfies the DFARS clock without requiring complete findings

DDTC (ITAR) notification:

Required within 72 hours if defense articles or ITAR-controlled technical data were involved
TC-2200 manufacturing specifications are ITAR-controlled technical data
File via DECCS (Defense Export Control and Compliance System)
Preliminary notification accepted – full report follows within 30 days

DoD DCSA (Defense Counterintelligence and Security Agency):

Voluntary notification (not mandatory)
Nation-state sabotage indicators present

14:00 UTC briefing with Colonel Kim is scheduled.

Analysis direction: Filing the preliminary notification today – even without complete findings – is the legally correct and strategically sound choice. It protects cleared contractor status, which is worth far more than any single contract. Waiting to “have all the answers” before notifying is the most common mistake in defence contractor incidents.

CHARLIE – Deep Analysis 3: Contract Recovery Path and Customer Relationship

Type: Contract and business continuity assessment

Source: Manufacturing Director Sarah Park + Colonel Michael Kim (14:00 UTC meeting)

Colonel Kim’s position after preliminary briefing:

“If Batches 1 and 2 are confirmed clean through retained sample inspection, and if Batch 3 defectives are quarantined and replaced with verified production, DoD can accept contract completion on a modified schedule. The 72-hour reporting and your transparent communication today are noted. If Batch 3 replacement production begins Thursday morning and physical QC verification is provided, I am prepared to recommend a 5-business-day delivery extension.”

Modified delivery: Wednesday of next week (with 5-day extension)

Analysis direction: The company has a viable path to contract completion. The transparent, fast communication with the contract officer is what preserved the option. The technical recovery is feasible in the available time – but it requires starting PLC restoration tonight.

Tier 3 – Developments

Release at start of Rounds 4 and 5 (2 cards per team)

Alpha x2 – Bravo x2 – Charlie x2

ALPHA – Development 1: ADMIN-WS-012 After-Hours OPC-UA Sessions Investigated

Type: Forensic follow-up Source: IT Security team, ADMIN-WS-012 investigation, 16:00 UTC

ADMIN-WS-012 investigation results:
  Host user   : it.support.d (David Reyes, IT support technician)
  OPC-UA tool : Siemens OPC-UA client -- downloaded from legitimate Siemens site
  Install date: 2026-02-11 (same day as first anomalous session)

OPC-UA session activity (reviewed via endpoint log):
  2026-02-11  19:44 UTC  → MFG-WS-001:4840  (2 min)  Tag browser only -- READ
  2026-02-14  20:12 UTC  → MFG-WS-001:4840  (4 min)  Tag browser only -- READ
  2026-02-16  19:58 UTC  → MFG-WS-001:4840  (1 min)  Tag browse only -- READ

All three sessions: OPC-UA tag browsing only. No write commands.
No malicious files on ADMIN-WS-012. No anomalous network or system activity indicators found.

David Reyes explanation (interview, 15:30 UTC):
  "I was testing OPC-UA connectivity for a production visualization dashboard
   I'm building for the operations team. I used MFG-WS-001 as a test target
   because it was the easiest IP to reach from my workstation. I wasn't
   aware the sessions were being logged anywhere."

All three sessions show OPC-UA tag browsing only – no write commands. No malicious files found on ADMIN-WS-012.

Analysis direction: This is a red herring that should have been investigated – and was. Unauthorized OPC-UA browsing from an IT workstation is still a finding: David Reyes had no need for OPC-UA access, and this access was unlogged, unapproved, and from an uncontrolled workstation. It needs a process fix, even if it was benign here.

ALPHA – Development 2: USB Placement – Physical Security Investigation

Type: Physical security investigation

Source: Security Officer Maria Rodriguez + building access logs, 16:30 UTC

Parking lot CCTV review (February 17, 06:30 -- 07:45 UTC):
  Coverage: West lot only -- engineering entrance
  06:47 UTC  Unidentified individual (dark jacket, cap obscuring face)
             -- Standing near Vehicle Row C (engineer.r's known parking spot)
  06:51 UTC  Individual leaves west lot without entering building
  07:21 UTC  engineer.r (Ryan Cho) arrives, parks in Row C
  07:44 UTC  engineer.r enters building, plugs USB into MFG-WS-001

Vendor access log (February 16--17):
  2026-02-16  Siemens service engineer (badge SIE-2847) -- PLC firmware check on Line C
  2026-02-17  No external vendor access logged

Building perimeter:
  West parking lot: Public access -- no badge, no vehicle barrier, no CCTV coverage
                    of approach path from street
  East entrance (IT wing): Badge-controlled -- not used by engineering staff

The individual was observed near engineer.r’s regular parking spot (Row C) at 06:47 UTC – 34 minutes before his arrival at 07:21 UTC. The west parking lot has no badge control, no vehicle barrier, and no CCTV coverage of the street approach. The Siemens engineer’s badge entry the previous day has been verified with Siemens as a scheduled maintenance visit.

Analysis direction: This was a targeted, surveilled operation. Someone researched the facility’s personnel, identified an engineer with access to the SCADA workstations, found his parking spot, and placed the USB the morning before he arrived. The sophistication strongly implies state-sponsored or well-funded adversary.

BRAVO – Development 1: PLC Restoration Complete – Production Verified

Type: OT recovery confirmation

Source: ICS security specialist + Manufacturing Director Sarah Park, Thursday 06:30 UTC

PLC restoration summary:
  Clean engineering laptop : ICS specialist's own (Step 7 v5.6, licensed)
  Step 7 archive source    : TCS-BAK-01, January 8 backup (SHA-256 verified)

  PLC-LINE-A1 : Restored 22:15 UTC Wed | Firmware verified clean | Test run: PASS
  PLC-LINE-A2 : Restored 23:00 UTC Wed | Firmware verified clean | Test run: PASS
  PLC-LINE-B1 : Restored 23:45 UTC Wed | Firmware verified clean | Test run: PASS

Physical verification batch (Thursday 05:00 -- 06:30 UTC):
  25 units produced under restored PLC logic
  Dimensional measurement: 25 of 25 within spec (12.000" +/- 0.0008")
  SCADA reading vs. physical: MATCH confirmed -- no discrepancy
  Authorization to restart: Manufacturing Director, Thursday 06:30 UTC

Replacement Batch 3 production starts: Thursday 06:30 UTC
Units needed to complete order : 280 units (480 defective quarantined)
Estimated completion           : Friday 00:30 UTC (~18 hours production)

All three PLCs restored and independently verified. Physical production measurements match SCADA telemetry readings.

Analysis direction: Production is restored and verified. The Friday delivery timeline is achievable. The investigation found no collateral damage to other systems – scope was contained to the three Siemens S7-315 PLCs. The remaining work is incident closure and long-term security improvements.

BRAVO – Development 2: Permanent OT Security Architecture Recommendations

Type: ICS security architecture brief Source: ICS security specialist (final report), Thursday 08:00 UTC

Root causes and remediation:

Root cause	Remediation	Priority
No USB port control on SCADA workstations	USB lockdown via Group Policy on `MFG-WS-001`, `MFG-WS-002`	Immediate
OPC-UA unauthenticated, unrestricted	Restrict port 4840 to ERP server IP; enable OPC-UA Security (cert auth)	Immediate
Step 7 project files not integrity-monitored	Deploy file integrity monitoring on `MFG-WS-001`, `MFG-WS-002`	High
PLC firmware not version-controlled	Quarterly firmware hash audit against Siemens reference	High
Physical security (parking lot USB delivery)	Badge control for employee parking area	Medium
No OT intrusion detection	Deploy Claroty or Dragos OT monitoring platform	Medium

Estimated cost: $180,000 for immediate controls + $340,000 for OT monitoring platform.

Analysis direction: The $520,000 security investment context: the company holds a multi-million defense contract. A successful sabotage event that delivered defective navigation components would likely terminate that contract and remove cleared contractor status. The math strongly favors investment.

CHARLIE – Development 1: Regulatory Authority Review – Cleared Status Preserved

Type: Government liaison update

Source: Security Officer Maria Rodriguez + DCSA representative, Thursday 10:00 UTC

DCSA (Defense Counterintelligence and Security Agency) outcome after initial assessment:

“TechCore’s timely notification, transparent communication, and rapid containment response are consistent with expected behavior for cleared contractors facing a sophisticated state-sponsored attack. We note: (1) No CUI was exfiltrated. (2) No defective components reached DoD. (3) DFARS notification was timely. Based on current findings, we do not recommend facility security clearance action at this time.”

DCSA requirements before case closure:

Full forensic report within 30 days
OT security remediation plan with implementation timeline
USB access control policy formalized and documented
Evidence of ITAR DDTC preliminary notification filed

Cleared contractor status: Maintained. Current contract: Active.

Analysis direction: TechCore/Precision Defence’s rapid, transparent response directly preserved their cleared status. The most common mistake in similar incidents is delayed reporting while trying to “solve it first.” Reporting fast – even before full investigation – was the right call.

CHARLIE – Development 2: Executive Debrief – What Prevented Disaster

Type: Post-incident executive summary

Source: CISO + Manufacturing Director Sarah Park, Thursday 14:00 UTC board briefing

Detection: QC manager identified a 0.003” discrepancy during physical gauge inspection. SCADA reported pass.

Automated system gaps identified:

Modified PLCs reported false nominal values to SCADA
No file integrity monitoring on Step 7 project files
No OT intrusion detection comparing commanded vs. reported values

Contributing factors to contract preservation:

Physical QC inspection (human gauge measurement)
Clean PLC program backup dated January 8
Production dates placing Batches 1 and 2 before the compromise date
Preliminary DFARS/DEFCON 658 notification filed within 72 hours

Investment decisions approved by board:

USB lockdown + OPC-UA security: $180,000 (approved immediately)
OT monitoring platform (Claroty/Dragos): $340,000 (approved, 90-day procurement)
Physical security upgrade (parking lot): $45,000 (approved)

Analysis direction: The central learning: a manufacturing sabotage attack designed to deceive automated systems was defeated by a human doing a physical check with a gauge. Every security architecture that removes human verification points from physical production is more vulnerable to this class of attack.

IM Distribution Guide

Card	Release round	Hand to
All Tier 1 cards (6 total)	Start of Round 1	Alpha x2, Bravo x2, Charlie x2
Alpha Deep 1-2, Bravo Deep 1-2, Charlie Deep 1-2	Start of Round 2	Respective teams
Alpha Deep 3, Bravo Deep 3, Charlie Deep 3	Start of Round 3	Respective teams
All Development cards (6 total)	Start of Round 4	Respective teams
Alpha Dev 2, Bravo Dev 2, Charlie Dev 2 (extended)	Start of Round 5	Respective teams

IC note: The IC receives no artifacts directly. Teams brief the IC based on their findings. IC pressure comes from cross-team coordination, not IM-distributed materials.

Key coordination moment: The production date forensics in Alpha Deep 2 (Batches 1 and 2 predate the compromise) is the central relief finding. It should surface in the Round 3 IC briefing and directly drives the Charlie team’s contract officer communication strategy. If Alpha and Charlie are not coordinating on this, prompt the IC: “What do we actually know about the components already shipped?”

Link to scenario card: Stuxnet Manufacturing Deadline | Prep worksheet: Large Group Prep Worksheet