FAQ
Will you exploit CAN bus during a pentest, or only document the path?
It depends on the engagement target and the safety-of-life implications. On bench rigs with separated safety-critical actuators we exploit fully. On instrumented test vehicles we exploit with documented safety controls. On production vehicles we typically stop at proof-of-access and document the exploitation path rather than execute commands that could affect driver safety.
Short answer
It depends on the engagement target and the safety-of-life implications. On bench rigs with separated safety-critical actuators we exploit fully. On instrumented test vehicles we exploit with documented safety controls. On production vehicles we typically stop at proof-of-access and document the exploitation path rather than execute commands that could affect driver safety.
Long answer
CAN bus exploitation has three escalating depths: (1) bus access — establishing read/write capability on the target network segment; (2) command injection — sending arbitrary messages that the target ECU accepts; (3) functional manipulation — using the injected commands to change vehicle behavior (acceleration, braking, steering, lighting, infotainment, telematics).
For each engagement we agree the depth in the scope-of-work document before testing starts. The decision is driven by three factors: the vehicle state during testing (bench rig with no driver, instrumented test vehicle with safety driver, production vehicle), the target ECU's role in safety-of-life functions (an infotainment ECU exploitation can be fully executed; a powertrain ECU exploitation typically stops at command-injection capability rather than functional manipulation), and the client's incident-response readiness if a test vehicle becomes inoperable mid-engagement.
In our experience, OEM and Tier-1 clients ask us to go to depth 2 on instrumented test vehicles for safety-critical ECUs and to depth 3 for non-safety-critical ECUs (infotainment, telematics, body control). For aftermarket dongle assessments — where the dongle is a separate product attached to a production vehicle — we typically test the dongle on a bench setup and validate the documented exploitation path in a controlled test-vehicle environment with the client's safety team present.
We document the chain of evidence required for the client to reproduce findings without the safety risk of re-exploiting on the vehicle: full message-capture logs, exploit-script source, ECU response captures, and a written reproduction guide.
Related
- Automotive cybersecurity service - Rules of engagement - CAN bus - OBD-II
---