Command and Control on Four Wheels

A modern vehicle already contains the power, radios, compute, storage, identity, and mobility a command network needs. Compromise changes who those systems serve. The criminal economy already sells or rents compromised devices, proxy capacity, botnet access, hosting, and entry into victim networks. A vehicle based node could fit that same business model.

Cyber criminals do not always build the infrastructure they use. Compromised devices are packaged and sold. The customer pays for capability, location, connectivity, uptime, proximity, or concealment. Most of the time not knowing what physical device is providing it.

Check out Kaspersky’s report on Android car head units being drawn into proxy botnets. The criminal service model already exists, car-mounted computers have entered proxy botnet territory and connected vehicles possess characteristics that could make mobile nodes valuable. Believe it or not, I know the group, in Oklahoma City, responsible for doing just this to a few vehicles in this area.

We still tend to picture command-and-control infrastructure sitting in a rack somewhere: a rented server, a hijacked router, a cloud instance, or a domain quietly waiting for infected machines to call home. But infrastructure does not have to stay put.

A connected vehicle carries persistent electrical power, embedded computers, storage, cellular service, Wi-Fi, Bluetooth, GPS, microphones, sensors, and internal networks linking multiple electronic control units. It moves between homes, businesses, hospitals, schools, parking structures, and public roads. It can communicate over distance while also getting physically close to devices and networks that a remote server cannot reach.

That combination gives a compromised or deliberately modified vehicle something conventional C2 infrastructure does not have: mobility plus proximity.

This does not make every connected vehicle malicious. It means many vehicles already contain the architectural building blocks needed to participate in a command-and-control system. The security question is who is authorized to use them, what the vehicle can reach, and whether anyone outside the manufacturer can see the difference.

C2 Is a Role, Not a Box

MITRE ATT&CK defines command and control as the methods an adversary uses to communicate with compromised systems and control them. That definition matters because C2 is a function, not a particular type of server.

A vehicle that merely receives an unauthorized remote-start or door-unlock command is a compromised endpoint. The command infrastructure still exists somewhere upstream.

A vehicle crosses into C2 infrastructure when it performs a broader role: relaying traffic, brokering access, storing and forwarding instructions, distributing tasks to other compromised systems, or collecting their results for delivery upstream. It may be the main controller, but it does not have to be. Modern operations commonly use proxies, fallback paths, and multiple stages specifically to keep the real controller separated from the systems being managed. MITRE classifies proxying as a C2 technique because an intermediary can carry command traffic while concealing or insulating the infrastructure behind it.

So the useful question is not, “Is the car the server?” It is, “What job is the car performing in the command chain?”

Why a Vehicle Fits the Role

At a high level, C2 needs four things: a way to receive instructions, something capable of interpreting them, a path to the controlled system, and a way to return results. A connected vehicle may already have all four.

The telematics unit provides wide-area cellular communication and location services. The infotainment system provides general-purpose processing, storage, media handling, Bluetooth, and Wi-Fi. A central gateway links different in-vehicle network segments. The diagnostic interface gives service equipment access to vehicle data and functions. Cloud services exchange information with the car and, on supported vehicles, deliver remote commands or software updates.

The vehicle also supplies stable power and a chassis large enough to conceal an added computer or communications device without requiring the factory systems to be compromised at all. None of those components alone creates C2. Together, however, they form a platform that can receive, process, route, store, and transmit data while moving through the physical world.

2017 Cadillac CTS Maps Cleanly

The 2017 Cadillac CTS is a useful real-world example because its documented factory features expose the architecture without requiring speculation.

The 2017 CTS/CTS-V owner manual describes an OnStar system dependent on the vehicle’s electrical system, cellular service, and GPS. It documents a built-in 4G LTE Wi-Fi hotspot capable of connecting multiple devices, Bluetooth integration through Cadillac CUE, remote diagnostics, vehicle location, and RemoteLink functions that could start or stop the vehicle, lock or unlock the doors, activate the horn and lights, send directions, return vehicle-status information, and manage the hotspot.

Cadillac also announced vehicle-to-vehicle safety technology as standard on 2017 CTS sedans. Feature availability on one specific car should still be confirmed through its VIN, build sheet, and installed modules, but the model line itself demonstrates the point.

The CTS could receive authorized instructions from outside the car, return data to remote services, exchange data with a paired phone, provide a local wireless network, determine its location, and—when V2V-equipped—communicate locally with compatible vehicles.

Those are legitimate features, not evidence of compromise. They are also the same basic communications primitives found in a remote-management architecture: identity, tasking, telemetry, local connectivity, and a path back to a back end. What changes in a malicious C2 scenario is not the existence of those capabilities. It is the trust relationship governing them.

How a Connected Car Becomes Part of a Command Chain

There is no single vehicle-C2 design. Several different architectures can produce the same broad result without requiring the car to behave abnormally on the road.

Malicious or unauthorized code running on a telematics unit, infotainment system, gateway, or another capable module could use the vehicle’s existing communications path to contact infrastructure outside the car. It could receive tasking, collect local information, and send results back.

This is not a hypothetical leap from “cars have Bluetooth” to “cars can be remotely controlled.” Automotive researchers established the underlying chain years ago. A 2011 USENIX study of automotive attack surfaces demonstrated remote exploitation paths involving Bluetooth, cellular radio, media, and service tools, along with long-distance control, location tracking, and in-cabin audio exfiltration on the researchers’ test platform.

In 2015, Charlie Miller and Chris Valasek documented remote exploitation of an unaltered Jeep Cherokee, showing how an internet-reachable infotainment system could become an entry point and how compromise could progress toward the vehicle’s internal networks. The specific vulnerabilities were patched, but the research established a durable architectural lesson: an externally connected component can become a bridge to systems deeper inside the vehicle when segmentation and access controls fail.

Abuse of the Legitimate Cloud Path

The software inside the vehicle does not always need to be altered. An attacker who compromises an owner account, dealer system, manufacturer API, or back end service may be able to send commands through the same path used by an authorized mobile app.

In that arrangement, the manufacturer’s cloud path—or the system abusing it—is the C2 layer, while the vehicle remains the controlled endpoint. The distinction changes only if the vehicle then relays those instructions or provides access to other systems.

This is more than a theoretical concern. In 2024, researchers documented Kia web-platform vulnerabilities that allowed their proof of concept to issue remote vehicle commands and retrieve personal information. Kia fixed the vulnerabilities, the researchers did not release the tool, and Kia reported no known malicious exploitation. The case is valuable here because it demonstrates that the route into a connected car may begin in web identity and back end authorization—not in the car itself.

An Added Communications Node

A vehicle can host C2 infrastructure without compromising any factory software. An added device can draw power from the vehicle and supply its own processor, storage, and radio. Depending on where it is connected, it might operate as a completely separate mobile relay or interact with the vehicle through a diagnostic or internal-network connection.

NHTSA’s 2022 vehicle cybersecurity guidance specifically identifies cellular, Wi-Fi, Bluetooth, USB, and OBD-II as interfaces through which user-owned or aftermarket equipment may connect. It also warns that a poorly protected aftermarket telematics device could act as a proxy capable of influencing safety-critical systems, depending on the vehicle architecture.

That word—proxy—is important. The device does not need to look like a traditional server. It only needs to pass communications between systems that could not otherwise reach one another.

A Mobile Bridge

A connected car can occupy two network environments at once: a wide-area cellular connection on one side and short-range Wi-Fi or Bluetooth on the other. A compromised component with access to both can, in principle, receive traffic over one interface and relay it over another.

The same logic applies to a separately installed device riding inside the vehicle. Mobility allows that bridge to appear near one network, leave, and later synchronize elsewhere. The car becomes valuable not because it is faster than a cloud server, but because it can get close.

This is a threat-model inference from documented vehicle capabilities and established proxy behavior—not evidence that ordinary connected cars are routinely being used this way.

Store-and-forward C2

C2 does not require a constant live session. A node can retrieve tasking, go offline, collect or deliver data, and reconnect later. It can also switch between primary and fallback channels.

That makes a vehicle naturally suited to a courier or dead-drop role. It can carry encrypted commands or collected data between places without maintaining a continuous connection. Its changing location is not an obstacle; it may be the feature.

Criminals Do Not Need Control of the Car

Remote steering and braking receive most of the attention because they are visually dramatic. They are not necessary for a vehicle to be useful as C2 infrastructure.

A vehicle-based node could be limited to communications, collection, routing, or proximity access while the car itself drives normally. It may never inject a single command onto a safety-critical bus. In fact, avoiding interaction with driving systems would reduce the chance of creating obvious faults, warning lights, or safety events.

The most operationally useful vehicle-C2 node may be the one that never affects vehicle behavior at all.

There are also two different command planes to keep separate. The external plane carries instructions between an operator, a back end, and the compromised component. The internal plane carries messages among vehicle modules over networks such as CAN or automotive Ethernet. Reaching the first does not automatically grant access to the second. Gateways, segmentation, authentication, firmware protections, and model-specific architecture determine whether that pivot is possible.

That is why broad claims such as “it has cellular, therefore it can control the brakes” are technically weak. Connectivity establishes a possible path into one component. It does not prove privileges beyond it.

What Would Actually Prove It?

A radio signal is not proof of C2. Neither is a Bluetooth identifier, ordinary telematics traffic, a vehicle waking while parked, or an unfamiliar module viewed without context. Connected cars perform legitimate background communications, and many systems remain active or wake periodically after the ignition is turned off.

Evidence of vehicle-based C2 would need to form a chain across layers.

Physical evidence might include an undocumented device with both power and data connections, non-factory wiring into a communications or diagnostic path, or hardware that does not match the vehicle’s build records.

Host evidence might include unauthorized firmware, unexpected executables or services, persistence outside the approved software image, enabled debugging access, altered trust stores, or a software rollback to a vulnerable version.

Network evidence might include recurring connections to infrastructure unrelated to expected manufacturer services, unusual timing or beacon-like regularity, unexplained data transfer, or routing between interfaces that should be isolated.

Back end evidence might include unknown account sessions, newly authorized users, remote commands the owner did not request, abnormal API activity, or cloud records that conflict with what the vehicle was doing at the same time.

The strongest evidence would correlate those layers: an external communication reaches the vehicle, a process or added device handles it, an internal or nearby system responds, and results leave through a traceable path.

Proof is not the presence of hardware. Proof is demonstrated behavior.

The Visibility Problem

Vehicle owners generally do not have the equivalent of endpoint detection and response for a car. They cannot easily inspect processes on a telematics unit, review every outbound connection, validate each ECU image, or obtain complete cloud-command histories. Service scanners are built primarily for diagnostics and repair, not full digital forensics.

NHTSA recommends that vehicles maintain event logs sufficient to reveal attacks and support reconstruction. It also recommends segmentation between wireless-connected components and safety-critical systems, strict gateway filtering, protection of diagnostic functions, signed firmware, secure back end communications, and safeguards against unauthorized software rollback.

Those recommendations reveal the exact evidence domains that matter: vehicle logs, gateway decisions, firmware state, diagnostic access, wireless interfaces, back end authentication, and update history. The problem is that much of this information remains controlled by manufacturers, suppliers, service platforms, and cellular providers rather than exposed to the owner.

That gap makes vehicle compromise unusually difficult to confirm or eliminate. The platform can be deeply connected while the person holding the title has very little visibility into what it is saying.

The Defensive Question Has Changed

The automotive industry already treats modern vehicles as cyber-physical systems. ISO/SAE 21434 applies cybersecurity risk management across the full lifecycle of vehicle electrical and electronic systems, while NHTSA’s guidance assumes that some components may eventually be compromised and calls for layered containment.

The next step is to widen the threat model. Defenders should not look only for someone trying to control the vehicle. They should also ask whether the vehicle is being used to control, reach, observe, or communicate with something else.

A modern car does not need to become a weapon to become infrastructure. It only needs to be trusted, connected, mobile, and poorly observed.

The question is no longer whether a vehicle has the ingredients to participate in command and control. It is which role the vehicle is playing, who authorized it, and whether anyone outside the system’s owner can see the difference.