Penetration Testing Connected Vehicles: A Structured Methodology

A modern connected vehicle presents an attack surface unlike anything in traditional IT. It combines wireless radios operating across multiple frequency bands, real-time safety-critical control networks, legacy diagnostic interfaces designed before security was a consideration, cloud backend services processing fleet telemetry, mobile companion applications with stored credentials, and over-the-air update channels that can reflash millions of ECUs simultaneously. Penetration testing a connected vehicle requires a methodology that spans all of these domains systematically, operates within strict safety constraints, and produces results that map directly to regulatory compliance requirements.

This guide presents a structured methodology for penetration testing connected vehicles: from scoping and reconnaissance through interface-specific testing techniques to reporting and remediation tracking. It covers every major attack surface, the unique safety considerations that distinguish automotive penetration testing from IT penetration testing, the relationship between penetration testing and fuzz testing, and how findings align with ISO/SAE 21434 verification requirements and UNECE R155 type approval evidence.

Scoping and Rules of Engagement

Automotive penetration testing requires more rigorous scoping than IT penetration testing because of safety implications. Before any testing begins, the engagement scope must explicitly address several critical questions:

Target Definition

The scope must precisely define what is being tested: a specific ECU on a bench, a complete vehicle on a dynamometer, a cloud backend environment, a mobile application, or some combination. For ECU-level testing, the scope should specify the exact part number, firmware version, and hardware revision. For vehicle-level testing, the VIN, model year, trim level (which determines which optional ECUs are present), and current software version must be documented. Ambiguity in target definition leads to incomplete testing and disputes about coverage.

Safety Boundaries

The rules of engagement must define explicit safety boundaries. Which ECUs are in scope for active exploitation versus passive observation only? Are safety-critical domains (powertrain, braking, steering) included? If so, under what physical conditions — vehicle stationary, wheels off ground on a lift, or on a dynamometer with controlled speed? Can the tester inject CAN messages on safety-critical bus segments, or only on infotainment and body control buses? What is the procedure if testing causes an unintended vehicle state (limp mode, engine shutdown, airbag deployment)? These boundaries must be agreed in writing before the engagement begins.

Legal and Regulatory Considerations

Vehicle penetration testing intersects with regulations beyond cybersecurity. In many jurisdictions, accessing vehicle ECU firmware may implicate reverse engineering restrictions in software licensing agreements. Cellular modem testing may require carrier authorization. RF testing on V2X frequencies may require spectrum authorization. OBD-II diagnostic access is regulated differently across markets. The engagement contract must address intellectual property handling, data destruction requirements for captured firmware images, and the tester’s liability limitations for any physical damage to the test vehicle or surrounding equipment.

A well-scoped automotive penetration test spends 20–30% of the total engagement time on reconnaissance and attack surface mapping before any active exploitation begins. This investment pays dividends in test coverage and finding quality.

Reconnaissance and Attack Surface Mapping

Reconnaissance in automotive penetration testing combines traditional IT reconnaissance techniques with hardware-specific analysis. The goal is to build a comprehensive map of every external interface, internal network, and data flow that an attacker could target.

External Interface Inventory

The first step is inventorying every physical and wireless interface that provides a path into the vehicle. This includes OBD-II diagnostic port (physical access, typically under the dashboard), USB ports (media, charging, and diagnostic), SD card slots, Bluetooth (Classic and BLE), Wi-Fi (client and access point modes), cellular modem (4G/5G), GNSS/GPS receiver, V2X radio (DSRC or C-V2X), NFC (for key card or phone key), UWB (for digital key ranging), tire pressure monitoring system (TPMS at 315 or 433 MHz), remote keyless entry (RKE at 315 or 433 MHz), and any manufacturer-specific wireless interfaces. Each interface is documented with its protocol, frequency, range, authentication mechanism, and the ECU that terminates it.

Internal Network Mapping

Once external interfaces are inventoried, the next step is mapping the internal vehicle network architecture. This involves identifying all CAN bus segments (typically 2–6 separate buses for powertrain, chassis, body, infotainment, diagnostics, and ADAS), Ethernet backbone segments, LIN sub-networks, and any gateway ECUs that bridge between domains. The gateway configuration is particularly important because it determines which messages can flow between bus segments and therefore which attack paths can reach safety-critical ECUs from externally accessible entry points. Network mapping uses a combination of OBD-II diagnostic scans, CAN bus traffic capture and analysis, and physical inspection of wiring harness connectors.

Attack Surface Mapping Table

Wireless Interface Testing

Wireless interfaces represent the highest-risk entry points because they can be exploited remotely without physical access to the vehicle. Each wireless interface has its own protocol stack, attack tooling, and vulnerability patterns.

Bluetooth Testing

Bluetooth testing covers both Classic Bluetooth (BR/EDR) and Bluetooth Low Energy (BLE). For Classic Bluetooth, the tester enumerates discoverable services using sdptool or bluetoothctl, checks for insecure pairing modes (legacy PIN pairing, Just Works), tests for BlueBorne-class vulnerabilities in the Bluetooth stack, and attempts to access profiles that should require authentication (HFP for phone, OBEX for file transfer, SPP for serial data). For BLE, the tester enumerates GATT services and characteristics, checks for unencrypted characteristics that expose sensitive data, tests for replay attacks on BLE authentication, and examines custom GATT services for diagnostic or debug functionality that was not intended for production exposure.

A critical finding pattern in automotive Bluetooth testing is the presence of debug or engineering serial port profiles (SPP) that provide direct access to diagnostic commands or even a Linux shell on the infotainment processor. These are commonly left enabled in production firmware because they were needed during development and nobody explicitly removed them.

Wi-Fi Testing

Most modern vehicles operate as Wi-Fi access points to provide passenger hotspot functionality, and many also connect as Wi-Fi clients to access points for OTA updates or diagnostics. Testing the vehicle as an access point involves scanning for the SSID and encryption configuration, testing WPA2/WPA3 passphrase strength (many vehicles use predictable passphrases derived from VIN or serial number), checking for WPS PIN vulnerabilities, and once associated, scanning internal services exposed on the access point network (HTTP interfaces, SSH, Telnet, UPnP, mDNS). Testing the vehicle as a Wi-Fi client involves setting up a rogue access point with the SSID the vehicle is known to connect to and testing for evil twin attacks, certificate validation bypass in TLS connections initiated over Wi-Fi, and captive portal handling that may expose the browser engine to web-based exploits.

Cellular Testing

Cellular testing targets the telematics control unit (TCU) and its connection to backend services. Using a software-defined radio (SDR) base station or a commercial small cell, the tester can intercept and modify cellular traffic, test downgrade attacks from 4G/5G to 2G (which lacks mutual authentication), and inject traffic into the vehicle’s cellular data session. On the application layer, the tester examines the TLS configuration of connections from the TCU to cloud backends, tests certificate pinning implementation, captures and analyzes the MQTT or proprietary telemetry protocol, and attempts to replay or modify command-and-control messages (remote lock/unlock, remote start, geofence alerts). Cellular interface testing often yields the most critical findings because the TCU typically has the highest privilege level of any externally accessible component, with direct access to CAN gateway routing and OTA update channels.

V2X Testing

V2X penetration testing requires specialized equipment: a V2X-capable SDR or commercial V2X OBU (On-Board Unit) that can transmit and receive on the 5.9 GHz ITS band. Testing involves sending malformed CAM/BSM messages to test message parsing robustness, injecting spoofed position data to test plausibility validation, generating Sybil attack patterns (multiple pseudonymous identities from a single source), testing certificate validation by sending messages with expired, revoked, or malformed certificates, and attempting replay attacks with captured legitimate messages. V2X testing must be conducted in an RF-shielded environment or at a test track with regulatory authorization to avoid interfering with production V2X deployments.

Wired Interface Testing

Wired interfaces require physical access but often provide deeper access to vehicle internals than wireless interfaces.

OBD-II Testing

The OBD-II diagnostic port is the most direct wired entry point into the vehicle network. Testing begins with enumerating all ECUs reachable via diagnostic routing (UDS service 0x22 ReadDataByIdentifier scans across all arbitration IDs). The tester then attempts to enter extended diagnostic sessions and unlock SecurityAccess on each ECU, testing for weak seed-key algorithms (static seeds, predictable random number generators, algorithmic weaknesses that allow key computation from the seed), timing attacks on security access attempt counters, and session management flaws that allow bypassing access control. Once diagnostic access is achieved, the tester attempts to read and write ECU memory, download firmware images, execute diagnostic routines, and modify calibration data. Findings from OBD-II testing are particularly impactful because aftermarket OBD-II dongles (insurance trackers, fleet management devices) provide permanent physical access to this interface.

USB Testing

USB ports on infotainment systems accept multiple device classes and media formats, each of which presents a parsing attack surface. Testing involves connecting USB devices that enumerate as unexpected device classes (HID keyboard, network adapter, serial port), providing media files in supported formats (MP3, AAC, FLAC, MP4, JPEG) with malformed headers and metadata to test parser robustness, testing filesystem handling with crafted FAT32/exFAT/NTFS images containing pathological directory structures, and testing Apple CarPlay and Android Auto protocol implementations for authentication bypass and data exfiltration. USB fuzzing of media parsers is one of the most productive areas for finding memory corruption vulnerabilities in infotainment systems.

Ethernet Testing

Direct Ethernet access, when available through diagnostic ports or by tapping into the vehicle’s Ethernet backbone, exposes the full IP-based service landscape of the vehicle. The tester performs network scanning to discover all IP endpoints, identifies running services (HTTP, SSH, Telnet, SOME/IP, DoIP, MQTT), tests each service for authentication requirements and known vulnerabilities, examines VLAN segmentation and attempts cross-VLAN access, and tests SOME/IP service discovery for information disclosure and service hijacking opportunities. Ethernet-based testing often reveals debug web interfaces, unprotected SSH access with default credentials, and SOME/IP services that accept unauthorized method calls.

Infotainment and Telematics Testing

The infotainment unit (IVI) and telematics control unit (TCU) are the two ECUs with the largest attack surface because they handle the most external interfaces and run the most complex software stacks (typically Linux or Android-based operating systems with millions of lines of code).

Infotainment System Testing

Infotainment testing combines embedded system techniques with traditional Linux/Android penetration testing. The tester examines the boot process for secure boot implementation (or lack thereof), attempts to gain shell access through debug interfaces (UART, ADB, SSH), analyzes the installed software packages for known CVEs, tests inter-process communication for privilege escalation, examines D-Bus services for unauthorized access, tests browser engine security (if a built-in browser is available), and attempts to escape from the infotainment sandbox to reach CAN bus gateway interfaces. Filesystem analysis of the infotainment image often reveals hardcoded credentials, API keys, private certificates, and debug configurations that were not removed from production builds.

Telematics Control Unit Testing

TCU testing focuses on the cellular communication stack and the TCU’s role as a gateway between the external network and the vehicle’s internal buses. Key test areas include TLS implementation and certificate validation for connections to backend servers, the command-and-control protocol (typically MQTT or a proprietary binary protocol over TLS), firmware update integrity verification, SIM card provisioning and authentication, and the TCU’s access to CAN bus segments through the gateway. A compromised TCU is typically the most dangerous finding in a vehicle penetration test because it combines remote network reachability with direct access to vehicle control networks.

Backend Cloud Services Testing

Connected vehicle backends handle authentication, command routing, telemetry storage, and OTA update distribution. They present a traditional web application attack surface with automotive-specific risks.

Backend testing covers API endpoint enumeration and authentication testing, authorization bypass (can user A send remote commands to user B’s vehicle?), IDOR vulnerabilities in vehicle-specific endpoints (using VIN or vehicle ID as the sole authorization check), telemetry data access controls (can an attacker access another vehicle’s location history, driving data, or diagnostic information?), OTA update server security (can an attacker upload a malicious firmware package?), certificate management (how are vehicle-to-cloud certificates provisioned, rotated, and revoked?), and rate limiting on vehicle command APIs (can an attacker send thousands of unlock commands per second to denial-of-service the vehicle or overwhelm the backend?).

The most critical backend findings typically involve authorization bypass: the ability to send remote commands (unlock, start, locate) to vehicles belonging to other users by manipulating API parameters such as VIN or vehicle ID. These findings are highly impactful because they affect the entire fleet, not just a single vehicle.

OTA Update Channel Testing

Over-the-air update channels are high-value targets because compromise of the OTA system enables remote code execution on every ECU in the fleet that accepts updates. Testing covers the complete update delivery chain: CDN security (can the update package URL be predicted or enumerated?), package integrity (code signing algorithm strength, certificate chain validation, rollback protection), transport security (TLS configuration, certificate pinning), on-vehicle verification (does the ECU verify the signature before or after writing to flash?), delta update handling (can a crafted delta patch produce a malicious full image?), and update staging (where is the update stored before installation, and is it accessible to other processes?). The tester should also attempt downgrade attacks: delivering a legitimately signed but older firmware version that contains known vulnerabilities.

Mobile Companion Application Testing

Virtually every connected vehicle has an accompanying mobile application that provides remote lock/unlock, remote start, vehicle location, trip history, and service scheduling. The mobile application is tested using standard mobile application penetration testing techniques augmented with automotive-specific checks. Testing includes static analysis of the application binary for hardcoded secrets (API keys, certificates, encryption keys), TLS certificate pinning implementation and bypass, local data storage security (keychain/keystore usage, database encryption), authentication flow analysis (OAuth implementation, session management, token handling), deep link and intent handling for injection vulnerabilities, and the BLE communication channel between the app and the vehicle (if used for proximity features like digital key or walk-up unlock). Mobile application findings frequently include stored credentials that provide direct API access to vehicle commands, bypassing multi-factor authentication that only protects the mobile UI layer.

Penetration Testing vs. Fuzz Testing

Penetration testing and fuzz testing are complementary but distinct disciplines. Understanding their differences is essential for planning a comprehensive security verification program.

Penetration testing is goal-oriented: the tester attempts to achieve specific objectives (gain root shell, read firmware, unlock vehicle, send CAN messages to safety ECU) by chaining together vulnerabilities and misconfigurations across multiple components and interfaces. Fuzz testing is coverage-oriented: the fuzzer aims to exercise as many code paths as possible in a specific target by generating massive volumes of malformed inputs, without a predetermined exploitation goal.

Penetration testing excels at finding logical vulnerabilities: authentication bypass, authorization flaws, insecure default configurations, cryptographic weaknesses, and multi-step attack chains that require human creativity to discover. Fuzz testing excels at finding implementation vulnerabilities: buffer overflows, null pointer dereferences, integer overflows, and parsing bugs that result from incorrect code rather than incorrect design.

A comprehensive automotive security verification program includes both: fuzz testing for systematic coverage of input-handling code across all protocols, and penetration testing for creative, adversarial evaluation of the complete system’s security posture. Fuzz testing results often provide penetration testers with useful entry points: a crash found by fuzzing a SOME/IP parser may be developed into a working remote code execution exploit during penetration testing.

Safety Constraints in Automotive Penetration Testing

Automotive penetration testing operates under safety constraints that have no parallel in IT penetration testing. These constraints must be integrated into the methodology rather than treated as afterthoughts:

1. Never test safety-critical functions on a running vehicle without physical containment. If powertrain, braking, or steering ECUs are in scope, the vehicle must be on a lift, on a dynamometer, or in a controlled test track environment. CAN injection into safety-critical bus segments must never occur on a vehicle that is on public roads.
2. Maintain a known-good state recovery capability. Before any testing that modifies ECU firmware, calibration data, or configuration, ensure that a factory restore procedure is available and tested. Document the complete vehicle software version before the engagement begins.
3. Monitor vehicle health during testing. Connect diagnostic monitoring tools to observe DTC (Diagnostic Trouble Code) generation, safety system status, and ECU operational state during active testing. If a safety system enters a degraded mode, pause testing and assess before continuing.
4. Isolate RF testing. Wireless attacks (Bluetooth, Wi-Fi, cellular, V2X) that involve transmission must be conducted in an RF-shielded enclosure or with appropriate regulatory authorization to prevent interference with other vehicles or infrastructure.
5. Coordinate with vehicle engineering. The OEM’s vehicle engineering team should be available during testing to provide technical guidance on safety implications of specific tests, to monitor vehicle health from the engineering perspective, and to provide factory recovery support if needed.

Reporting and ISO/SAE 21434 Alignment

Penetration testing reports for automotive engagements must serve multiple audiences: security engineers who will remediate findings, management who will allocate budget, and regulatory bodies who may review the report as part of type approval evidence.

Finding Classification

Each finding should be classified with a severity rating that accounts for both the technical exploitability and the automotive-specific impact. A standard CVSS score is useful but insufficient for automotive context — it does not capture safety impact. The report should augment CVSS with an automotive impact assessment: Can the vulnerability lead to unintended vehicle movement? Can it disable a safety system? Can it affect multiple vehicles simultaneously (fleet-wide impact)? Can it be exploited remotely, or does it require physical access to the vehicle? The combination of CVSS base score and automotive impact context provides a severity rating that resonates with both cybersecurity and vehicle safety stakeholders.

ISO/SAE 21434 Mapping

For findings to support the ISO/SAE 21434 cybersecurity case, each finding should be mapped to the relevant cybersecurity goal and requirement from the TARA. If the TARA identified “unauthorized access to diagnostic services” as a threat and specified “diagnostic services shall require authentication” as a requirement, then a penetration test finding that demonstrates unauthenticated UDS access directly validates that the requirement is not met. This bidirectional traceability — from TARA threat through cybersecurity requirement to penetration test finding — is the most valuable deliverable of an automotive penetration test from a compliance perspective.

Remediation Recommendations

Remediation recommendations must be practical in the automotive context. Recommendations to “apply the latest security patch” are meaningless for embedded ECUs that cannot be patched without an OTA campaign or dealer visit. Effective recommendations specify the exact change needed (e.g., “add bounds checking to the UDS ReadMemoryByAddress handler to validate that the requested address range falls within the readable memory region”), the affected component and its supplier, the validation approach (how to confirm the fix is effective), and the deployment mechanism (OTA update, dealer campaign, or next model year).

Tooling Recommendations

Automotive penetration testing requires a specialized toolkit that bridges the gap between IT security tools and automotive engineering tools:

• CAN interface hardware: PEAK PCAN-USB FD, Kvaser Leaf Pro, Vector VN1610/VN1630, or Intrepid neoVI FIRE for CAN bus access and injection.
• CAN analysis software: SavvyCAN, CANoe (Vector), CANalyzer, or python-can with custom scripts for CAN traffic capture, decoding, and injection.
• UDS tools: UDS Scanner, Caring Caribou, or custom python-udsoncan scripts for diagnostic service enumeration and security access testing.
• Bluetooth: Ubertooth One for Bluetooth sniffing, hcitool/gatttool for BLE enumeration, and BTLEJuice for BLE man-in-the-middle.
• Wi-Fi: Alfa AWUS036ACH for monitor mode, hostapd for evil twin, Wireshark for traffic analysis.
• Cellular: srsRAN or OpenBTS with USRP B200/B210 for cellular base station, mitmproxy for TLS interception.
• Automotive Ethernet: Technica Engineering Ethernet capture tools, Wireshark with SOME/IP dissectors, python-someip for SOME/IP testing.
• Firmware analysis: Binwalk for firmware extraction, Ghidra or IDA Pro for disassembly, EMBA for automated firmware analysis.
• Mobile app testing: Frida for runtime instrumentation, objection for iOS/Android, MobSF for static analysis, Burp Suite for API proxy.

How ThreatZ Supports Penetration Testing Programs

ThreatZ connects penetration testing to the broader cybersecurity engineering lifecycle. The threat scenarios and attack paths identified during TARA become the test objectives for penetration testing engagements. ThreatZ generates scoping documents that map TARA attack paths to specific interfaces and ECUs, ensuring that penetration tests target the highest-risk areas identified by risk assessment rather than following a generic checklist.

When penetration test findings are imported into ThreatZ, they are automatically linked to the corresponding TARA threats, cybersecurity requirements, and components. This traceability demonstrates to type approval authorities that the organization has conducted targeted security testing based on systematic risk assessment, which is precisely what ISO/SAE 21434 and UNECE R155 require. Findings that invalidate existing risk ratings trigger automatic reassessment workflows, ensuring that the TARA remains current as new vulnerabilities are discovered.

Key Takeaways

• Connected vehicle penetration testing spans wireless interfaces, wired interfaces, infotainment systems, telematics units, cloud backends, mobile applications, and OTA update channels — all must be tested systematically.
• Scoping and rules of engagement must explicitly address safety boundaries, legal constraints, and target definition before testing begins.
• Reconnaissance and attack surface mapping should consume 20–30% of the engagement to ensure comprehensive coverage.
• Wireless interfaces (Bluetooth, Wi-Fi, cellular, V2X) represent the highest-risk attack surfaces because they enable remote exploitation without physical access.
• Backend authorization bypass and OTA update channel compromise are typically the highest-impact findings because they affect the entire fleet.
• Penetration testing and fuzz testing are complementary: pentest finds logical vulnerabilities and multi-step attack chains, fuzzing finds implementation bugs in parsing code.
• Safety constraints are non-negotiable — physical containment, health monitoring, and engineering support are mandatory for safety-critical domain testing.
• Findings must be mapped to TARA threats and ISO/SAE 21434 requirements to provide regulatory compliance value beyond the vulnerability report itself.