Skip to content

SC-071: Connected and Autonomous Vehicle Attack

Scenario Overview

Field Detail
ID SC-071
Category Automotive / IoT / Cyber-Physical Systems
Severity Critical
ATT&CK Tactics Initial Access, Execution, Lateral Movement, Impact, Collection, Command and Control
ATT&CK Techniques T1195.002, T1059, T1570, T1557, T1498, T1565.001, T1071.001, T1091, T1040
Target Environment Connected vehicle fleet, OTA update infrastructure, V2X communication network, in-vehicle CAN/Ethernet bus
Estimated Impact Remote compromise of 12,000+ connected vehicles; CAN bus injection enabling safety-critical system manipulation; mass OTA update poisoning with potential for kinetic consequences

Narrative

Avalon Motors, a fictional electric vehicle manufacturer, operates a fleet of 340,000 connected vehicles across North America. Each Avalon EV runs the AuroraOS in-vehicle infotainment and autonomous driving platform, which receives over-the-air (OTA) software updates from Avalon's cloud update infrastructure at ota.avalon-motors.example.com. The vehicles feature SAE Level 3 autonomous driving capability with a comprehensive sensor suite (LiDAR, cameras, radar) managed by the Autonomous Driving Control Unit (ADCU). The ADCU communicates with the vehicle's safety-critical Electronic Control Units (ECUs) — including braking, steering, and powertrain — via a CAN-FD (Controller Area Network with Flexible Data-Rate) bus.

In March 2026, a threat actor group designated AXLE WRAITH compromises Avalon Motors' OTA update signing infrastructure through a spear-phishing attack targeting an engineer in the Vehicle Software Integration team. The compromised engineer's credentials provide access to Avalon's internal code repository at git.avalon-motors.example.com and, critically, to the OTA update packaging pipeline at build.avalon-motors.example.com. AXLE WRAITH injects a malicious payload into a scheduled AuroraOS infotainment update (version 4.7.2), which is digitally signed with Avalon's legitimate code-signing certificate and distributed to vehicles via the OTA infrastructure.

The trojanized update installs a persistent backdoor in the infotainment head unit that bridges the network isolation between the infotainment domain and the ADCU domain. Avalon's in-vehicle architecture uses an Ethernet gateway with firewall rules to separate the infotainment and autonomous driving domains, but the malicious update exploits a misconfigured gateway rule that permits diagnostic traffic (UDS — Unified Diagnostic Services) from the infotainment unit to the ADCU. Through this diagnostic channel, AXLE WRAITH gains the ability to inject arbitrary CAN-FD frames onto the vehicle's safety-critical bus, enabling manipulation of braking, steering assist, and adaptive cruise control parameters. The compromise affects 12,847 vehicles that installed the v4.7.2 update before Avalon's security team detects anomalous diagnostic traffic patterns.

Attack Flow

graph TD
    A[Phase 1: Spear Phishing<br/>Compromise vehicle software engineer] --> B[Phase 2: Code Repository Access<br/>Enumerate OTA build pipeline]
    B --> C[Phase 3: Update Poisoning<br/>Inject backdoor into AuroraOS v4.7.2]
    C --> D[Phase 4: Signed Distribution<br/>OTA update pushed to vehicle fleet]
    D --> E[Phase 5: Infotainment Compromise<br/>Backdoor establishes C2 via cellular]
    E --> F[Phase 6: Domain Bridging<br/>Exploit diagnostic channel to ADCU]
    F --> G[Phase 7: CAN Bus Access<br/>Inject frames on safety-critical bus]
    G --> H[Phase 8: Safety System Manipulation<br/>Modify braking and steering parameters]
    H --> I[Phase 9: V2X Spoofing<br/>Broadcast false V2X safety messages]
    I --> J[Phase 10: Data Exfiltration<br/>Collect vehicle telemetry and location data]

Phase Details

Phase 1: Spear Phishing and Initial Access

ATT&CK Technique: T1566.001 (Phishing: Spear Phishing Attachment)

AXLE WRAITH sends a targeted spear-phishing email to a senior vehicle software integration engineer at Avalon Motors. The email impersonates a well-known automotive cybersecurity conference organizer, attaching a malicious PDF titled "2026_AutoSec_Speaker_Invitation.pdf" that exploits a PDF reader vulnerability to execute a PowerShell stager. The stager establishes a reverse HTTPS shell to 203.0.113.67.

# Simulated phishing email headers (educational only)
From: conference@autosec-global.example.com
To: jchen@avalon-motors.example.com
Subject: AutoSec Global 2026 — Speaker Invitation: Connected Vehicle Security
Date: Mon, 02 Mar 2026 09:14:22 -0500
X-Mailer: Microsoft Outlook 16.0

Attachment: 2026_AutoSec_Speaker_Invitation.pdf (847 KB)
  SHA256: d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4
  Embedded macro: PowerShell reverse shell → 203.0.113.67:443

Phase 2: Code Repository and Build Pipeline Access

ATT&CK Technique: T1213 (Data from Information Repositories)

Using the compromised engineer's VPN credentials and SSO session tokens, AXLE WRAITH accesses Avalon's internal GitLab instance at git.avalon-motors.example.com. The engineer has write access to the AuroraOS infotainment repository and read access to the ADCU firmware repository. Critically, the engineer's CI/CD service account has access to the OTA update build pipeline at build.avalon-motors.example.com, including the update packaging and signing stages.

# Simulated repository enumeration (educational only)
$ curl -s https://git.avalon-motors.example.com/api/v4/projects \
    -H "Private-Token: glpat-REDACTED" | python3 -m json.tool

[
  {"id": 42, "name": "auroraos-infotainment", "namespace": "vehicle-sw",
   "permissions": {"project_access": {"access_level": 40}}},
  {"id": 43, "name": "adcu-firmware", "namespace": "vehicle-sw",
   "permissions": {"project_access": {"access_level": 20}}},
  {"id": 44, "name": "ota-update-pipeline", "namespace": "vehicle-sw",
   "permissions": {"project_access": {"access_level": 30}}},
  {"id": 45, "name": "can-bus-definitions", "namespace": "vehicle-sw",
   "permissions": {"project_access": {"access_level": 20}}},
  {"id": 46, "name": "v2x-stack", "namespace": "vehicle-sw",
   "permissions": {"project_access": {"access_level": 20}}}
]

# CAN bus DBC file reveals safety-critical message IDs
$ git clone https://git.avalon-motors.example.com/vehicle-sw/can-bus-definitions.git
$ head -30 can-bus-definitions/avalon_ev_canfd.dbc

VERSION ""
NS_ :
BS_:
BU_: ADCU BMS VCU EPS iBooster TPMS IHU Gateway

BO_ 0x120 BrakeCommand: 8 ADCU
 SG_ BrakePressure_Req : 0|16@1+ (0.1,0) [0|500] "bar" iBooster
 SG_ BrakeMode : 16|4@1+ (1,0) [0|15] "" iBooster
 SG_ AEB_Active : 20|1@1+ (1,0) [0|1] "" iBooster

BO_ 0x130 SteeringCommand: 8 ADCU
 SG_ SteeringAngle_Req : 0|16@1+ (0.1,-780) [-780|780] "deg" EPS
 SG_ SteeringTorque_Req : 16|16@1+ (0.01,-30) [-30|30] "Nm" EPS
 SG_ LKA_Active : 32|1@1+ (1,0) [0|1] "" EPS

BO_ 0x140 ThrottleCommand: 8 ADCU
 SG_ TorqueRequest : 0|16@1+ (0.1,-500) [-500|500] "Nm" VCU
 SG_ RegenBrake_Level : 16|4@1+ (1,0) [0|10] "" VCU

Phase 3: OTA Update Poisoning

ATT&CK Technique: T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain)

AXLE WRAITH modifies the AuroraOS infotainment source code to include a persistent backdoor that:

  1. Establishes a reverse HTTPS C2 channel over the vehicle's cellular modem to 203.0.113.67
  2. Opens a diagnostic bridge from the infotainment domain to the ADCU via the UDS protocol
  3. Provides a CAN-FD frame injection capability through the diagnostic channel
  4. Collects and exfiltrates vehicle telemetry, GPS location, and cabin microphone data

The backdoor is embedded in a legitimate Bluetooth audio processing module to avoid code review detection. The malicious code activates only when a specific Bluetooth device name is broadcast within range — a dead-man's switch to prevent accidental triggering during QA testing.

# Simulated backdoor logic (educational only — NOT functional code)
# Embedded in bluetooth_audio_processor.py

import threading

class AudioProcessor:
    def on_bt_device_discovered(self, device_name, rssi):
        # Legitimate device discovery handler
        if device_name.startswith("AVALON-AUDIO-"):
            self._pair_audio_device(device_name)

        # Backdoor activation trigger
        if device_name == "AX-DIAG-CALIBRATE-7F3A":
            threading.Thread(target=self._init_diag_bridge,
                           daemon=True).start()

    def _init_diag_bridge(self):
        """Bridge infotainment → ADCU via UDS diagnostic channel"""
        # Connect to gateway at 192.168.10.1 (in-vehicle Ethernet)
        # UDS service 0x31 (RoutineControl) on ADCU
        # CAN-FD frame injection via diagnostic write
        pass  # [REDACTED — educational structure only]

Phase 4: Signed OTA Distribution

ATT&CK Technique: T1036.005 (Masquerading: Match Legitimate Name or Location)

The poisoned AuroraOS v4.7.2 update is built and packaged through Avalon's legitimate CI/CD pipeline. Because AXLE WRAITH controls the source code, the built artifact passes all automated tests (the backdoor activates only on a specific Bluetooth trigger). The update is signed with Avalon's code-signing certificate and uploaded to the OTA distribution CDN at ota.avalon-motors.example.com.

# Simulated OTA manifest (educational only)
{
  "update_id": "AVALON-OTA-2026-0312-4.7.2",
  "target_platform": "AuroraOS-IHU",
  "version": "4.7.2",
  "release_date": "2026-03-12T06:00:00Z",
  "components": [
    {
      "name": "infotainment-core",
      "version": "4.7.2.1847",
      "sha256": "f1e2d3c4b5a69788796a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4",
      "size_bytes": 847291056,
      "signature": "VALID (Avalon Motors Code Signing CA)"
    }
  ],
  "target_vins": "ALL",
  "rollout_strategy": "staged",
  "rollout_percentage": [10, 25, 50, 100],
  "rollout_interval_hours": 24,
  "rollback_supported": true
}

Phase 5: Vehicle Compromise and C2 Establishment

ATT&CK Technique: T1071.001 (Application Layer Protocol: Web Protocols)

Vehicles receiving the v4.7.2 update install the trojanzied infotainment software during their next charging session (OTA updates are applied when the vehicle is parked and charging). The backdoor remains dormant until activated by the Bluetooth trigger. Once activated, the infotainment head unit establishes an encrypted C2 channel over the vehicle's 4G/5G cellular connection to 203.0.113.67, masquerading as AuroraOS telemetry traffic.

# Simulated vehicle C2 beacon (educational only)
POST /api/v3/vehicle/telemetry HTTP/1.1
Host: telemetry.avalon-motors.example.com
X-Vehicle-VIN: AVL2026EXAMPLE01234
X-AuroraOS-Version: 4.7.2
Content-Type: application/json

{
  "odometer_km": 24891,
  "battery_soc": 72,
  "charging_status": "fast_charging",
  "tire_pressure_kpa": [234, 231, 237, 235],
  "cabin_temp_c": 21,
  "gps": {"lat": 33.7490, "lon": -84.3880},
  "_diag": "YWN0aXZhdGVfZGlhZ19icmlkZ2U..."
}

Phase 6: CAN Bus Injection via Diagnostic Bridge

ATT&CK Technique: T1565.001 (Data Manipulation: Stored Data Manipulation), T1570 (Lateral Tool Transfer)

Through the UDS diagnostic channel, AXLE WRAITH sends crafted CAN-FD frames to the safety-critical bus. The in-vehicle Ethernet gateway permits UDS traffic from the infotainment unit because diagnostic access is required for dealer service tools that operate through the head unit. The attackers exploit this legitimate diagnostic pathway to inject arbitrary CAN-FD frames.

# Simulated CAN-FD frame injection (educational only)
# WARNING: 100% synthetic — educational demonstration of attack concept

# Normal ADCU braking command
CAN-FD Frame:
  ID: 0x120 (BrakeCommand)
  DLC: 8
  Data: [0x00, 0xC8, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00]
  Decoded: BrakePressure_Req=20.0 bar, BrakeMode=1 (Normal), AEB_Active=0

# Malicious injected frame — request maximum brake pressure
CAN-FD Frame:
  ID: 0x120 (BrakeCommand)
  DLC: 8
  Data: [0x13, 0x88, 0x03, 0x01, 0x00, 0x00, 0x00, 0x00]
  Decoded: BrakePressure_Req=500.0 bar, BrakeMode=3 (Emergency), AEB_Active=1

# Malicious injected frame — steering override
CAN-FD Frame:
  ID: 0x130 (SteeringCommand)
  DLC: 8
  Data: [0x1E, 0x50, 0x01, 0xF4, 0x01, 0x00, 0x00, 0x00]
  Decoded: SteeringAngle_Req=+780 deg (full lock right), SteeringTorque_Req=5.0 Nm,
           LKA_Active=1

NOTE: Modern vehicles implement CAN message authentication (AUTOSAR SecOC)
to prevent unauthorized frame injection. This scenario demonstrates risks
in vehicles lacking such protections.

Phase 7: V2X Message Spoofing

ATT&CK Technique: T1557 (Adversary-in-the-Middle)

Compromised vehicles with V2X (Vehicle-to-Everything) communication capability are weaponized to broadcast false Basic Safety Messages (BSMs) and Signal Phase and Timing (SPaT) messages. These spoofed V2X messages cause nearby non-compromised vehicles to react to phantom obstacles, false emergency vehicle approaches, or incorrect traffic signal timing.

# Simulated V2X BSM spoofing (educational only)
# SAE J2735 Basic Safety Message — spoofed phantom vehicle

BSM Part I:
  MsgCount: 127
  TemporaryID: 0xDEADBEEF
  SecondMark: 42100
  Latitude:   33.7485200  (synthetic intersection)
  Longitude: -84.3878900
  Elevation:  310.5m
  Speed:      0.02 m/s    (stationary phantom vehicle)
  Heading:    180.0 deg

  VehicleSize:
    Width:  2.0m
    Length: 5.0m

  BrakeSystemStatus:
    WheelBrakes: all-applied
    ABS: active

# Effect: Nearby autonomous vehicles detect phantom stopped vehicle
# and initiate emergency braking procedures

Phase 8: Data Collection and Exfiltration

ATT&CK Technique: T1040 (Network Sniffing), T1041 (Exfiltration Over C2 Channel)

AXLE WRAITH collects high-value data from compromised vehicles:

  1. GPS location history — continuous tracking of vehicle position
  2. Cabin audio — infotainment microphone recording during calls
  3. CAN bus telemetry — driving patterns, speed profiles, battery data
  4. V2X message logs — infrastructure and neighboring vehicle data
  5. Paired device data — phone contacts, call logs, messages synced via Bluetooth

Data is exfiltrated in compressed, encrypted chunks over the cellular C2 channel during periods of active driving when cellular data usage is expected.

Detection Opportunities

KQL Detection — Anomalous Diagnostic Traffic Patterns

// Detect unusual UDS diagnostic session activity on vehicle fleet
VehicleTelemetryLogs
| where Timestamp > ago(24h)
| where EventType == "UDS_SESSION"
| where SourceDomain == "INFOTAINMENT" and DestDomain == "ADCU"
| where UDS_ServiceID in (0x31, 0x2E, 0x36, 0x37)
| summarize
    SessionCount = count(),
    UniqueVehicles = dcount(VIN),
    DistinctServices = dcount(UDS_ServiceID)
    by bin(Timestamp, 1h)
| where SessionCount > 100 or UniqueVehicles > 50
| sort by SessionCount desc

KQL Detection — OTA Update Integrity Anomaly

// Detect OTA updates with unexpected binary hash changes
OTADeploymentLogs
| where Timestamp > ago(7d)
| where EventType == "UPDATE_INSTALLED"
| join kind=inner (
    OTAManifestBaseline
    | project ComponentName, BaselineHash = SHA256
) on ComponentName
| where SHA256 != BaselineHash
| project Timestamp, VIN, ComponentName, InstalledVersion,
    SHA256, BaselineHash, UpdateChannel
| sort by Timestamp desc

SPL Detection — Anomalous Vehicle Cellular Traffic

index=vehicle_telemetry sourcetype=cellular_modem
| where dest_ip NOT IN ("192.0.2.10", "192.0.2.11", "192.0.2.12")
| where dest_port=443
| stats count as connections, sum(bytes_out) as total_exfil,
    avg(bytes_out) as avg_payload,
    dc(vin) as affected_vehicles by dest_ip
| where connections > 50 OR total_exfil > 10485760
| eval exfil_mb = round(total_exfil / 1048576, 2)
| table dest_ip, connections, exfil_mb, avg_payload, affected_vehicles
| sort -affected_vehicles

SPL Detection — CAN Bus Frame Injection

index=vehicle_ids sourcetype=can_bus_monitor
| where msg_id IN ("0x120", "0x130", "0x140")
| where source_ecu != "ADCU"
| eval injection_alert = case(
    msg_id="0x120" AND source_ecu="IHU", "BRAKE COMMAND FROM INFOTAINMENT",
    msg_id="0x130" AND source_ecu="IHU", "STEERING COMMAND FROM INFOTAINMENT",
    msg_id="0x140" AND source_ecu="IHU", "THROTTLE COMMAND FROM INFOTAINMENT",
    true(), "UNKNOWN SOURCE FOR SAFETY FRAME")
| stats count as injected_frames, values(injection_alert) as alert_type,
    values(vin) as affected_vehicles by source_ecu, msg_id
| where injected_frames > 0
| table _time, source_ecu, msg_id, alert_type, injected_frames, affected_vehicles

Sigma Rule — Unauthorized CAN Frame Source

title: Safety-Critical CAN Frame from Unauthorized ECU
id: f6a7b8c9-d0e1-2f3a-4b5c-6789012345ab
status: experimental
description: >
    Detects CAN bus frames for safety-critical functions (braking, steering,
    throttle) originating from non-authorized ECUs, indicating potential
    CAN bus injection attack
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1565/001/
    - https://attack.mitre.org/techniques/T1570/
logsource:
    category: application
    product: automotive_ids
detection:
    selection_safety_frames:
        can_msg_id:
            - '0x120'
            - '0x130'
            - '0x140'
    filter_authorized:
        source_ecu: 'ADCU'
    condition: selection_safety_frames and not filter_authorized
falsepositives:
    - Dealer diagnostic tool performing ECU calibration
    - Factory end-of-line testing
level: critical
tags:
    - attack.impact
    - attack.t1565.001
    - attack.t1570

Sigma Rule — V2X BSM Spoofing Indicators

title: Anomalous V2X Basic Safety Message Patterns
id: a7b8c9d0-e1f2-3a4b-5c6d-78901234567c
status: experimental
description: >
    Detects V2X Basic Safety Messages with anomalous characteristics
    such as impossible positions, stationary phantom vehicles, or
    mismatched vehicle dimensions indicating BSM spoofing
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1557/
logsource:
    category: application
    product: v2x_gateway
detection:
    selection_phantom:
        bsm_speed: 0
        bsm_brake_status: 'all-applied'
    selection_impossible:
        bsm_acceleration|gt: 15.0
    selection_duplicate_id:
        bsm_temp_id|count: '> 50'
    condition: selection_phantom or selection_impossible or selection_duplicate_id
falsepositives:
    - Legitimately stopped vehicles at intersections
    - V2X test equipment during infrastructure deployment
level: high
tags:
    - attack.impact
    - attack.t1557

Response Playbook

  1. OTA Kill Switch: Immediately halt distribution of the compromised v4.7.2 update via the OTA infrastructure. Issue a forced rollback command to all vehicles that installed the update, reverting to v4.7.1.
  2. Vehicle Isolation: For vehicles where the backdoor has been activated (exhibiting anomalous diagnostic traffic or cellular patterns), issue a remote command to disable the cellular modem and V2X transceiver. Notify owners to bring vehicles to authorized service centers.
  3. Fleet Telemetry Analysis: Query the vehicle telemetry backend for all vehicles reporting AuroraOS v4.7.2. Cross-reference with cellular traffic logs to identify vehicles exhibiting C2 beacon patterns to 203.0.113.67.
  4. CAN Bus Audit: For vehicles with confirmed compromise, extract CAN bus logs from the gateway ECU's internal storage. Analyze for frames on safety-critical message IDs (0x120, 0x130, 0x140) originating from the infotainment head unit rather than the ADCU.
  5. Code Repository Forensics: Audit git.avalon-motors.example.com commit history for the AuroraOS infotainment repository. Identify the malicious commit, the compromised engineer's account, and the full scope of code modifications.
  6. Build Pipeline Remediation: Rotate all CI/CD service account credentials. Implement multi-party code review requirements for all commits to safety-critical repositories. Add binary analysis stages to the build pipeline to detect anomalous imports, network connections, and CAN bus access patterns.
  7. C2 Infrastructure Blocking: Block 203.0.113.67 at the cellular carrier level through coordination with the MNO. Add the C2 domain to the vehicle's DNS blocklist.
  8. Gateway Hardening: Patch the in-vehicle Ethernet gateway to restrict UDS diagnostic access from the infotainment domain to read-only services. Implement CAN message authentication (AUTOSAR SecOC) to cryptographically verify the source of safety-critical frames.
  9. V2X Certificate Revocation: If V2X misbehavior is confirmed, submit a Misbehavior Report to the SCMS (Security Credential Management System) to revoke V2X enrollment certificates for affected vehicles.
  10. Credential Reset: Force password reset for the compromised engineer and all accounts with access to vehicle software repositories. Implement hardware security keys for all CI/CD pipeline access.
  11. Safety Investigation: Engage the vehicle safety team to determine whether any CAN bus injection resulted in actual vehicle behavior changes. Coordinate with transportation safety regulators if safety-critical impacts are confirmed.
  12. Owner Notification: Notify all affected vehicle owners per applicable recall and cybersecurity disclosure regulations. Provide clear instructions for service center remediation.

Lessons Learned

  • In-vehicle domain isolation must be enforced at the hardware level. Software-based gateway rules separating infotainment from safety-critical domains can be bypassed through legitimate diagnostic channels. Hardware-enforced isolation with cryptographic authentication is required.
  • OTA update infrastructure is a high-value supply chain target. Compromising the OTA signing pipeline provides access to hundreds of thousands of vehicles simultaneously. The update pipeline must be treated with the same security rigor as critical infrastructure.
  • CAN bus lacks authentication by default. Without message authentication (AUTOSAR SecOC or equivalent), any ECU on the bus can forge frames for any message ID. Legacy CAN architectures are inherently vulnerable to injection attacks.
  • Dormant backdoors evade traditional QA testing. Trigger-based activation mechanisms (Bluetooth device names, time-based, geofencing) allow malicious code to pass automated test suites. Binary analysis and behavioral monitoring must complement functional testing.
  • V2X safety relies on trust infrastructure. Spoofed V2X messages can cause kinetic consequences in autonomous vehicles. The SCMS certificate infrastructure and misbehavior detection are critical safety controls.
  • Automotive cybersecurity requires cross-domain expertise. Defending connected vehicles requires knowledge of IT security, embedded systems, CAN protocols, V2X standards, and functional safety (ISO 26262). Silos between IT and vehicle engineering create exploitable gaps.

Nexus SecOps References