Using the Automotive Threat Matrix to threat model a telematics control unit

The Automotive Threat Matrix is ATT&CK for cars. How to scope it to a single ECU, a telematics control unit, and where it helps versus where it stops short.

The Automotive Threat Matrix (ATM) is ATT&CK for cars: an Auto-ISAC knowledge base of the tactics and techniques adversaries use against vehicles, organized the way MITRE organizes enterprise attacker behavior. The useful way to read it is not front to back. It’s to scope it to one component at a time. This post walks the matrix from the defender’s seat against a single ECU, the telematics control unit, and shows where the matrix earns its keep and where it stops short.

What you’ll walk away with: a repeatable way to point ATM at one box, an example attack-surface decomposition for a TCU mapped to real technique IDs, and a clear sense of why the matrix is an enumeration aid and not a risk assessment.

My take up front, so you know what you’re reading: ATM’s value is breadth and a shared vocabulary, not depth. Treat it as a checklist of what to consider, then run the result through a real TARA to decide what to fix, and you’ll get a lot out of it. Read it cover to cover hoping it tells you what to do, and you’ll be disappointed.

What the Automotive Threat Matrix is

Auto-ISAC launched ATM publicly on March 27, 2024, after roughly four years of development by a member working group. Per Auto-ISAC, the matrix is “modeled after the acclaimed MITRE ATT&CK framework” and exists to give the industry a common taxonomy for automotive-specific adversary behavior. It’s a living document. Submissions are reviewed on a monthly cadence and approved quarterly, so anything you pull from it should be timestamped.

The structure will be familiar if you’ve used ATT&CK. Tactics are the columns, the adversary’s goals in order from reconnaissance through impact. Techniques are the cells, the ways an adversary achieves each goal. Real-world attacks are catalogued as example “procedures” and mapped onto the techniques they used. ATM uses its own identifiers, not ATT&CK’s: tactics are ATM-TA0000 through ATM-TA0013, techniques are ATM-T0xxx, and procedures are ATM-Pxxxx. Two of the tactics have no enterprise equivalent because they only make sense for a vehicle: Manipulate Environment (ATM-TA0001), which covers things like jamming and relaying RF, and Affect Vehicle Function (ATM-TA0013), ATM’s version of ATT&CK’s Impact column.

On size, the current matrix carries fourteen tactics, 77 techniques (no sub-techniques), and 151 catalogued procedures (real-world attacks mapped to the techniques they used), with procedure IDs running up to ATM-P0198.

The wrong way to read it

Here’s the mistake I see people make with any of these matrices, ATT&CK included. They open the full grid, see a few hundred techniques, and either try to “cover” all of them or bounce off the size of it. Neither is useful. A matrix this wide is only tractable once you scope it to something concrete.

For a defender, the concrete thing is a component and its attack surfaces. You pick one box in the vehicle, enumerate how an adversary could touch it, then walk the tactic columns asking, for this box, what technique fits here. That turns a wall of cells into a short, specific list you can reason about and hand to the next stage. The commercial tools built on ATM (Upstream’s AutoThreat PRO, VicOne’s xAurient) do exactly this under the hood, associating each technique with the components and attack vectors it applies to. You can do the same by hand for one ECU.

Step one, decompose the TCU

A telematics control unit is a good first target because it has more attack surface than almost anything else in the vehicle. It’s the box that talks to the outside world and to the internal buses at the same time. Before touching the matrix, list what it exposes:

A cellular modem (anything from 2G through 5G depending on vintage), which is the remote attack surface.
GNSS/GPS for positioning.
Often Wi-Fi and Bluetooth, for hotspot and phone pairing.
An application processor running embedded Linux or an RTOS, with whatever services listen on those radios.
Links onto the in-vehicle networks: CAN and CAN-FD, increasingly automotive Ethernet.
An eSIM or SIM, and stored credentials: mutual-TLS client certificates, API keys, signing material.
An OTA update client.

Each of those is a way in or a thing worth stealing. Hold that list next to the tactic columns and the mapping mostly writes itself.

Walking the tactics against the TCU

Here’s a defender coverage map for the TCU, walking left to right across the matrix.

Tactic	ATM technique	TCU surface	What it looks like here
Manipulate Environment (`ATM-TA0001`)	`ATM-T0003` Manipulate Communications	cellular, GNSS, Wi-Fi/BT	spoofing GNSS, tampering with traffic to or from the modem
Manipulate Environment	`ATM-T0007` Relay Communications	RF	relaying a remote command or pairing exchange
Manipulate Environment	`ATM-T0009` Rogue Wi-Fi Access Point	Wi-Fi	a malicious AP the unit connects to, the fake-hotspot trick
Initial Access (`ATM-TA0002`)	`ATM-T0012` Exploit via Radio Interface	cellular, Wi-Fi/BT	a remote exploit over the modem or a short-range radio
Initial Access	`ATM-T0010` Aftermarket, Customer, or Dealer Equipment	bus	a dongle or aftermarket box on the same network
Initial Access	`ATM-T0013` Exploit via Removable Media	USB/SD	a malicious update image or media file
Initial Access	`ATM-T0016` Physical Modification	hardware	opening the unit, attaching to debug pads
Execution (`ATM-TA0003`)	`ATM-T0018` Command and Scripting Interpreter	app processor	a shell or interpreter reached through an exposed service
Execution	`ATM-T0019` Native API	app processor	abusing platform APIs to run code
Persistence (`ATM-TA0004`)	`ATM-T0021` Disable Software Update	OTA client	blocking updates so the foothold can’t be patched out
Persistence	`ATM-T0022` Modify OS Kernel, Boot Partition, or System Partition	flash/boot	reflashing to plant code that runs at boot
Privilege Escalation (`ATM-TA0005`)	`ATM-T0024` Abuse Elevation Control Mechanism	app processor	getting from a service account to root
Privilege Escalation	`ATM-T0026` Exploit OS Vulnerability	app processor	a kernel or OS bug to escape a sandbox or get root
Credential Access (`ATM-TA0007`)	`ATM-T0039` ECU Credential Dumping	key store	pulling stored keys and certs (mTLS client certs, SIM secrets) off the ECU
Discovery (`ATM-TA0008`)	`ATM-T0044` Network Service Scanning	in-vehicle network	enumerating reachable ECUs and services
Command and Control (`ATM-TA0011`)	`ATM-T0062` Cellular Communication	cellular	command and control over the modem’s data link
Command and Control	`ATM-T0065` Short Range Wireless Communication	Wi-Fi/BT	using a short-range radio as the control channel
Affect Vehicle Function (`ATM-TA0013`)	`ATM-T0067` Abuse Standard Diagnostic Protocol for Affecting Vehicle Function	CAN	diagnostic routines that actuate something (UDS, etc.)

That’s not every tactic. A complete pass also fills Reconnaissance, Defense Evasion, Lateral Movement, Collection, and Exfiltration. For the TCU those map to, respectively: fingerprinting the cellular-exposed services, hiding the modification from the app processor’s logging, pivoting from the TCU onto the CAN bus (the step that turns an infotainment-adjacent box into a safety problem), harvesting location and telemetry, and shipping data back out over the cellular link. For example, the CAN pivot is ATM-T0051 Bridge Vehicle Networks or ATM-T0052 Exploit ECU for Lateral Movement, and the location and telemetry harvest is ATM-T0043 Location Tracking under Collection.

The point of walking every column is that it forces you to think about classes of behavior you’d otherwise skip. Most people remember initial access and impact. Persistence and defense evasion on an embedded automotive target are the ones that get dropped, and they’re the difference between an attacker who needs physical access every time and one who owns the box across ignition cycles.

A real chain to anchor on, the Keen Lab Tesla work

None of this is hypothetical. Tencent Keen Security Lab remotely compromised a Tesla Model S in September 2016, written up by Sen Nie, Ling Liu, and Yuefeng Du in the Black Hat USA 2017 paper “Free-fall: Hacking Tesla from Wireless to CAN Bus.” ATM catalogues it as a procedure, split across more than a dozen ATM-P entries with the same name. It reads straight down the matrix.

They got in over Wi-Fi by faking a hotspot the car would auto-connect to, and exploited the in-car browser to run code on the head unit (initial access and execution). A kernel bug got them root and out of the browser sandbox (privilege escalation). From there they pivoted to the gateway, protected only by a static token in firmware (lateral movement), and flashed modified gateway firmware to open a CAN backdoor (persistence). With that, they injected CAN messages and actuated physical functions like the door locks while the car was moving (affect vehicle function). Tesla responded within ten days with an OTA update and code signing for ECU firmware. The value of the matrix here is that it lets you describe this whole chain, and the next remote-to-CAN attack, in one shared vocabulary.

From techniques to coverage

Once you have the technique list, the next thing you pull from each technique page is its Mitigations and Data Sources fields. That’s the defender payoff: for every way in, what reduces it and what would let you see it. Open each technique in the table above and read those two fields off the live matrix.

Two caveats. First, the matrix is a single-page app and the mitigation and detection fields don’t come out cleanly with automated tooling, so plan to read them in a browser or use the machine-readable JSON on the Auto-ISAC website. Second, and more important, the mitigation coverage is uneven. So for some techniques you’ll find a solid mitigation and for others very little.

Where ATM is thin, fill it from engineering judgment. The following are my controls for a generic TCU, not ATM’s, and you should map them back to whatever mitigation IDs the matrix does list once you’ve read them.

A verified boot chain, so a reflashed partition doesn’t run; that directly addresses the persistence techniques. Signed firmware with rollback protection on the OTA path, aligned to UN R156. That one is concrete here: Keen Lab walked straight through unsigned gateway firmware whose integrity check was a CRC they could recompute, and code signing is the control Tesla added in response. Client identity (the mTLS certs) held in a secure element or HSM rather than readable flash, so credential access gets an attacker nothing useful. Least privilege and sandboxing on the application processor; in the Keen Lab chain, AppArmor and iptables meant a browser shell couldn’t reach the bus on its own, and the attackers needed a separate kernel bug to escalate, which is the entire point of the control. A gateway that isolates the TCU from safety-critical CAN segments, so a compromised telematics box can’t freely address powertrain frames. CAN intrusion detection or message authentication on the segments that matter. Network-side controls at the carrier or APN level, so the modem’s services aren’t reachable from the public internet to begin with. And treat the OTA channel as a defense in itself: Tesla’s ten-day fleet fix shows your update path is sometimes the fastest lever you have once a hole is known.

On the detection side, the data sources you want are app-processor logs, CAN bus anomaly signals, modem and PDP-context anomalies, and GNSS plausibility checks against dead reckoning. Read what ATM lists, then close the gaps.

Where the matrix stops being useful

A few limits worth stating plainly, because the matrix doesn’t state them for you.

It tells you coverage, not risk. ATM enumerates what adversaries do. It doesn’t tell you which of those things is likely against your architecture, how bad it would be, or what to fix first. For that you still need a TARA per ISO/SAE 21434, or some rating method, on top of the enumeration. I think the cleanest workflow is ATM for breadth, then a TARA for prioritization. The matrix keeps you honest about what you might have missed; it won’t do the risk math.

It’s generic to the industry, not specific to your vehicle. Every technique in that table “applies” to a TCU in the abstract. Whether it matters depends entirely on your design. A TCU sitting behind a hardware gateway with no route to powertrain CAN has a completely different exposure than one whose connectivity processor can address those segments directly. A gateway isn’t a guarantee, and Keen Lab got root on Tesla’s and rewrote its firmware, but it raises the bar a lot. The matrix gives you the candidate list. Your architecture decides which candidates are real.

The mitigation and detection depth, as above, is still maturing, so don’t treat ATM as a controls catalog yet. The export doesn’t cross-reference CWE or MITRE EMB3D either: the tactics note they’re adapted from ATT&CK, but the technique objects carry no structured CWE, CAPEC, or EMB3D links. If you want a CWE bridge for your weakness tracking, you’re building it yourself.

The takeaway

The lesson generalizes past ATM. Any adversary-behavior matrix, whether it’s ATT&CK, ATM, or EMB3D, is an enumeration and communication tool. It isn’t a risk assessment and it isn’t a list of controls. The way to get value out of one is the same every time. Scope it to a single component. Decompose that component’s real attack surfaces. Walk every tactic column so you don’t skip a class of behavior. Pull the mitigations and detections it does offer. Then hand the whole thing to your risk process to decide what gets fixed. Do that for a TCU and the matrix turns from an intimidating wall into a one-page coverage map you can defend in a review.