In-memory fileless attacks can still trigger malicious CAN commands

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Karamba Security's blog post: In-memory fileless attacks can still drive malicious CAN commands on connected vehicles even when persistent footholds are hardened.

Why it matters: This matters because automotive security teams need controls that protect runtime integrity, not just network exposure, when vehicles depend on external connectivity and software-defined functions.

Context

Fileless attacks are malicious actions that execute in memory rather than by writing obvious files to disk. In connected vehicles, that matters because an attacker who reaches an ECU can issue commands without relying on a persistent implant, which weakens the value of controls focused only on boot integrity and network perimeter reduction.

The governance gap is not whether vehicle architectures are hardened, but whether they can detect and contain runtime abuse once an attacker is already executing inside the system. That is a classic integrity problem, and it becomes more acute as automotive platforms add RF, DSRC and C-V2X connectivity.

Key questions

Q: How do fileless attacks affect connected vehicle security?

A: Fileless attacks target the vehicle’s live memory, processes, scripts, or diagnostic interfaces rather than writing obvious malware to flash storage. In connected vehicles, that can mean abusing a telematics unit, infotainment stack, or ECU session to issue commands, manipulate data, or persist only in RAM. Controls such as secure boot and signed firmware do not block runtime abuse on a trusted process.

Q: Why do secure boot and read-only file systems not stop runtime abuse?

A: Secure boot verifies firmware at start-up, and read-only file systems prevent easy tampering with stored files, but neither stops malicious code already running from abusing memory, APIs, or inter-process calls. An attacker can hijack a legitimate process, load code into RAM, or misuse authorised diagnostics after boot. Runtime controls such as memory protection and control flow integrity are needed to limit that abuse.

Q: How does control flow integrity reduce exploitation inside ECUs?

A: Control flow integrity is a runtime defence that checks whether a program’s jumps, calls, and returns follow the paths its developer intended. Inside ECUs, it helps block code-reuse attacks and function-pointer hijacking by preventing execution from being redirected to unexpected locations. It reduces exploitation after memory corruption, but it does not replace memory safety or firmware signing.

Q: What signs suggest an ECU may be under in-memory attack?

A: Signs of in-memory attack on an ECU include unusual command sequences, unexpected diagnostic responses, abnormal timing, unexplained CPU or memory usage, and behaviour that does not match the flashed firmware. A common clue is valid-looking traffic that produces unsafe or inconsistent state changes without any visible file modification. Monitoring runtime telemetry and message integrity helps detect it.

Technical breakdown

Why fileless attacks evade persistence controls

Fileless attacks execute from memory, so they do not need to drop a binary or modify a file system to achieve effect. That changes the defensive problem from hunting artefacts on disk to controlling code execution paths, memory behaviour and inter-process actions. In an ECU context, the attacker’s value comes from transient execution that can send control messages and then disappear, which makes traditional persistence-focused detection incomplete. See the Fileless Malware Guide.

Practical implication: Instrument runtime execution paths so memory-resident behaviour is visible before an ECU command reaches the vehicle network.

How control flow integrity protects in-memory execution

Control flow integrity, or CFI, constrains which execution paths a program can take so that injected or hijacked code cannot freely redirect control. When binaries are instrumented with CFI, an attacker who gains code execution has a harder time chaining that execution into arbitrary actions inside the process. On connected devices, this is especially relevant because runtime abuse may occur without a file write, a reboot, or any obvious persistence marker.

Practical implication: Apply CFI to high-value ECU software so runtime hijacking is blocked even when the device remains reachable.

Why vehicle connectivity expands the attack surface

The more interfaces a vehicle exposes, the more likely it is that a compromise can be translated into control of in-vehicle functions. External links such as cellular, RF, DSRC and C-V2X are useful capabilities, but each one enlarges the trust boundary that defenders have to govern. The issue is not connectivity by itself, but the absence of a strong runtime trust model that can survive compromise of one reachable component. See the Security Programme Building Guide.

Practical implication: Treat every new external interface as part of the runtime trust boundary and validate it with the same discipline as core driving software.

Threat narrative

Attacker objective: The attacker wants to issue vehicle commands from inside the runtime environment and affect safety-critical behaviour without needing a durable foothold.

1. Entry occurs through an externally reachable vehicle component or interface that an attacker can access over connectivity paths.
2. Credential or persistence is not required because the attack lives in memory and executes without dropping a lasting file on the system.
3. Escalation happens when malicious execution issues CAN commands across the vehicle network from the compromised ECU or process.
4. Impact is the ability to alter vehicle behaviour and create safety consequences without leaving a persistent implant behind.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

In-memory compromise is a runtime integrity problem, not a persistence problem. A vehicle can be architecturally hardened and still be vulnerable if attackers can execute malicious logic entirely in memory. That shifts the governance question from whether the system boots cleanly to whether it can resist and detect active misuse during normal operation. Automotive security programmes should therefore treat runtime integrity as a first-class control objective.

CFI changes the debate from perimeter hardening to execution control. Network reduction and secure boot reduce exposure, but they do not stop a living process from being steered into unsafe behaviour once code execution is achieved. CFI is valuable because it limits what hijacked code can do inside the process boundary, which is why it fits connected ECU protection better than controls aimed only at startup assurance. That makes runtime enforcement the more realistic control path for vehicle security architecture.

Software-defined vehicles need a stronger trust model than “harder to reach”. As vehicles gain RF, DSRC and C-V2X links, the security conversation moves from limiting ingress to governing execution after ingress. The meaningful failure mode is not simply exposure, but exposed software that can still manipulate safety-relevant functions once reachable. Practitioners should frame this as a control-flow assurance issue across the vehicle stack.

Attack surface reduction is necessary, but it does not close the exploitation window. Removing Bluetooth or Wi-Fi, using read-only filesystems and locking down outbound channels all help, yet none of them fully address a memory-resident attacker already inside the system. That is the central lesson for automotive governance: runtime abuse has to be treated as a design assumption, not an edge case. Security teams should build controls that remain effective after initial compromise.

Read next: AI Security Architecture Reference Guide

What this signals

Runtime integrity is the missing control plane for connected vehicles. As vehicles accumulate external interfaces, the relevant question is no longer only how to keep attackers out, but how to stop compromised code from issuing dangerous actions once inside. That means security engineering has to move closer to execution-time enforcement and away from relying on startup checks alone.

Memory-resident attack paths will matter more as vehicle software becomes more connected. The more services and links an OEM adds, the more likely it is that an adversary will try to exploit a reachable component without planting a persistent file. Automotive teams should prepare for controls that inspect behaviour at runtime, because post-boot compromise is the scenario that perimeter logic misses.

For practitioners

• Instrument ECU binaries with runtime control enforcement Apply control flow integrity to high-value ECU software so memory-resident code cannot redirect execution into unsafe paths.
• Harden high-risk connectivity paths separately Place RF, DSRC and C-V2X functions on segmented networks with tightly scoped privileges so one reachable component does not expose the whole vehicle.
• Validate software integrity at runtime, not only boot time Add monitoring that can detect malicious command generation after startup, because secure boot alone does not stop in-memory abuse.
• Remove unnecessary attackable interfaces Disable Bluetooth, Wi-Fi or other externally reachable services where the vehicle design does not require them, and isolate any that remain.

Key takeaways

• In-memory fileless attacks expose a gap in vehicle security programmes that focus on persistence and perimeter controls rather than runtime behaviour.
• The evidence in the source points to malicious CAN command execution as the key safety risk, which means ECUs need execution-time protection.
• Control flow integrity is the most direct compensating control because it limits what hijacked code can do after an attacker reaches the running system.

Related NHI Mgmt Group resources: AI Security Architecture Reference Guide · Security Programme Building Guide · Sisense breach 2024

Key terms

• CAN Commands: CAN Commands are control messages sent over a Controller Area Network to request actions from vehicle ECUs. They carry identifiers and data fields rather than file-based payloads, so abuse often means sending crafted frames that trigger unintended functions, state changes, or diagnostic behaviour if access controls are weak.
• Fileless Attack: A fileless attack is an intrusion that relies on memory, scripts, or trusted system utilities instead of dropping a traditional malicious file on disk. These attacks are harder to spot with antivirus because the behaviour is often temporary, fragmented, and blended into normal administration activity.
• Control-flow integrity: Control-flow integrity means an agent follows its intended sequence of actions even when it encounters hostile or misleading input. In LLM systems, it reduces the chance that prompt injection can redirect tool choice or execution order, but it does not automatically protect the values carried through those actions.
• Secure Boot: A device startup process that verifies each code stage before execution continues. It ensures the firmware, bootloader, kernel, and operating system have valid signatures, so unauthorised code is blocked before it can control the platform.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity. It helps security and IAM practitioners connect runtime trust decisions to broader access and control design.