Introduction

Imagine you’re cruising down the highway in your brand-new electric car. All of a sudden, the massive multimedia display fills with Doom, the iconic 3D shooter game. It completely replaces the navigation map or the controls menu, and you realize someone is playing it remotely right now. This is not a dream or an overactive imagination – we’ve demonstrated that it’s a perfectly realistic scenario in today’s world.

The internet of things now plays a significant role in the modern world. Not only are smartphones and laptops connected to the network, but also factories, cars, trains, and even airplanes. Most of the time, connectivity is provided via 3G/4G/5G mobile data networks using modems installed in these vehicles and devices. These modems are increasingly integrated into a System-on-Chip (SoC), which uses a Communication Processor (CP) and an Application Processor (AP) to perform multiple functions simultaneously. A general-purpose operating system such as Android can run on the AP, while the CP, which handles communication with the mobile network, typically runs on a dedicated OS. The interaction between the AP, CP, and RAM within the SoC at the microarchitecture level is a “black box” known only to the manufacturer – even though the security of the entire SoC depends on it.

Bypassing 3G/LTE security mechanisms is generally considered a purely academic challenge because a secure communication channel is established when a user device (User Equipment, UE) connects to a cellular base station (Evolved Node B, eNB). Even if someone can bypass its security mechanisms, discover a vulnerability in the modem, and execute their own code on it, this is unlikely to compromise the device’s business logic. This logic (for example, user applications, browser history, calls, and SMS on a smartphone) resides on the AP and is presumably not accessible from the modem.

To find out, if that is true, we conducted a security assessment of a modern SoC, Unisoc UIS7862A, which features an integrated 2G/3G/4G modem. This SoC can be found in various mobile devices by multiple vendors or, more interestingly, in the head units of modern Chinese vehicles, which are becoming increasingly common on the roads. The head unit is one of a car’s key components, and a breach of its information security poses a threat to road safety, as well as the confidentiality of user data.

During our research, we identified several critical vulnerabilities at various levels of the Unisoc UIS7862A modem’s cellular protocol stack. This article discusses a stack-based buffer overflow vulnerability in the 3G RLC protocol implementation (CVE-2024-39432). The vulnerability can be exploited to achieve remote code execution at the early stages of connection, before any protection mechanisms are activated.

Importantly, gaining the ability to execute code on the modem is only the entry point for a complete remote compromise of the entire SoC. Our subsequent efforts were focused on gaining access to the AP. We discovered several ways to do so, including leveraging a hardware vulnerability in the form of a hidden peripheral Direct Memory Access (DMA) device to perform lateral movement within the SoC. This enabled us to install our own patch into the running Android kernel and execute arbitrary code on the AP with the highest privileges. Details are provided in the relevant sections.

Acquiring the modem firmware

The modem at the center of our research was found on the circuit board of the head unit in a Chinese car.

Description of the circuit board components:

Number in the board photo	Component
1	Realtek RTL8761ATV 802.11b/g/n 2.4G controller with wireless LAN (WLAN) and USB interfaces (USB 1.0/1.1/2.0 standards)
2	SPRD UMW2652 BGA WiFi chip
3	55966 TYADZ 21086 chip
4	SPRD SR3595D (Unisoc) radio frequency transceiver
5	Techpoint TP9950 video decoder
6	UNISOC UIS7862A
7	BIWIN BWSRGX32H2A-48G-X internal storage, Package200-FBGA, ROM Type – Discrete, ROM Size – LPDDR4X, 48G
8	SCY E128CYNT2ABE00 EMMC 128G/JEDEC memory card
9	SPREADTRUM UMP510G5 power controller
10	FEI.1s LE330315 USB2.0 shunt chip
11	SCT2432STER synchronous step-down DC-DC converter with internal compensation

Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.

Remote access to the modem (CVE-2024-39431)

The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).

We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.

The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).

Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.

As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.

In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).

Gaining persistence in the system

The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.

We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.

Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.

Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!

Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.

The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.

All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.

As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.

However, being able to execute our own code on the modem does not give us access to user data. Or does it?

The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.

Statistics across all threats

In Q2 2025, the percentage of ICS computers on which malicious objects were blocked decreased by 1.4 pp from the previous quarter to 20.5%.

Compared to Q2 2024, the rate decreased by 3.0 pp.

Regionally, the percentage of ICS computers on which malicious objects were blocked ranged from 11.2% in Northern Europe to 27.8% in Africa.

In most of the regions surveyed in this report, the figures decreased from the previous quarter. They increased only in Australia and New Zealand, as well as Northern Europe.

Selected industries

The biometrics sector led the ranking of the industries and OT infrastructures surveyed in this report in terms of the percentage of ICS computers on which malicious objects were blocked.

In Q2 2025, the percentage of ICS computers on which malicious objects were blocked decreased across all industries.

Diversity of detected malicious objects

In Q2 2025, Kaspersky security solutions blocked malware from 10,408 different malware families from various categories on industrial automation systems.

The only increases were in the percentages of ICS computers on which denylisted internet resources (1.2 times more than in the previous quarter) and malicious documents (1.1 times more) were blocked.

Main threat sources

Depending on the threat detection and blocking scenario, it is not always possible to reliably identify the source. The circumstantial evidence for a specific source can be the blocked threat’s type (category).

The internet (visiting malicious or compromised internet resources; malicious content distributed via messengers; cloud data storage and processing services and CDNs), email clients (phishing emails), and removable storage devices remain the primary sources of threats to computers in an organization’s technology infrastructure.

In Q2 2025, the percentage of ICS computers on which threats from email clients were blocked continued to increase. The main categories of threats from email clients blocked on ICS computers are malicious documents, spyware, malicious scripts and phishing pages. The indicator increased in all regions except Russia. By contrast, the global average for other threat sources decreased. Moreover, the rates reached their lowest levels since Q2 2022.

The same computer can be attacked by several categories of malware from the same source during a quarter. That computer is counted when calculating the percentage of attacked computers for each threat category, but is only counted once for the threat source (we count unique attacked computers). In addition, it is not always possible to accurately determine the initial infection attempt. Therefore, the total percentage of ICS computers on which various categories of threats from a certain source were blocked exceeds the percentage of threats from the source itself.

The rates for all threat sources varied across the monitored regions.

• The percentage of ICS computers on which threats from the internet were blocked ranged from 6.35% in East Asia to 11.88% in Africa
• The percentage of ICS computers on which threats from email clients were blocked ranged from 0.80% in Russia to 7.23% in Southern Europe
• The percentage of ICS computers on which threats from removable media were blocked ranged from 0.04% in Australia and New Zealand to 1.77% in Africa
• The percentage of ICS computers on which threats from network folders were blocked ranged from 0.01% in Northern Europe to 0.25% in East Asia

Threat categories

A typical attack blocked within an OT network is a multi-stage process, where each subsequent step by the attackers is aimed at increasing privileges and gaining access to other systems by exploiting the security problems of industrial enterprises, including technological infrastructures.

It is worth noting that during the attack, intruders often repeat the same steps (TTPs), especially when they use malicious scripts and established communication channels with the management and control infrastructure (C2) to move laterally within the network and advance the attack.

Malicious objects used for initial infection

In Q2 2025, the percentage of ICS computers on which denylisted internet resources were blocked increased to 5.91%.

The percentage of ICS computers on which denylisted internet resources were blocked ranged from 3.28% in East Asia to 6.98% in Africa. Russia and Eastern Europe were also among the top three regions for this indicator. It increased in all regions and this growth is associated with the addition of direct links to malicious code hosted on popular public websites and file-sharing services.

The percentage of ICS computers on which malicious documents were blocked has grown for two consecutive quarters. The rate reached 1.97% (up 0.12 pp) and returned to the level seen in Q3 2024. The percentage increased in all regions except Latin America.
The percentage of ICS computers on which malicious scripts and phishing pages were blocked decreased to 6.49% (down 0.67 pp).

Next-stage malware

Malicious objects used to initially infect computers deliver next-stage malware (spyware, ransomware, and miners) to victims’ computers. As a rule, the higher the percentage of ICS computers on which the initial infection malware is blocked, the higher the percentage for next-stage malware.

In Q2 2025, the percentage of ICS computers on which malicious objects from all categories were blocked decreased. The rates are:

• Spyware: 3.84% (down 0.36 pp);
• Ransomware: 0.14% (down 0.02 pp);
• Miners in the form of executable files for Windows: 0.63% (down 0.15 pp);
• Web miners: 0.30% (down 0.23 pp), its lowest level since Q2 2022.

Self-propagating malware

Self-propagating malware (worms and viruses) is a category unto itself. Worms and virus-infected files were originally used for initial infection, but as botnet functionality evolved, they took on next-stage characteristics.

To spread across ICS networks, viruses and worms rely on removable media, network folders, infected files including backups, and network attacks on outdated software such as Radmin2.

In Q2 2025, the percentage of ICS computers on which worms and viruses were blocked decreased to 1.22% (down 0.09 pp) and 1.29% (down 0.24 pp). Both are the lowest values since Q2 2022.

AutoCAD malware

This category of malware can spread in a variety of ways, so it does not belong to a specific group.

In Q2 2025, the percentage of ICS computers on which AutoCAD malware was blocked continued to decrease to 0.29% (down 0.05 pp) and reached its lowest level since Q2 2022.

For more information on industrial threats see the full version of the report.

Modern vehicles are transforming into full-fledged digital devices that offer a multitude of features, from common smartphone-like conveniences to complex intelligent systems and services designed to keep everyone on the road safe. However, this digitalization, while aimed at improving comfort and safety, is simultaneously expanding the vehicle’s attack surface.

In simple terms, a modern vehicle is a collection of computers networked together. If a malicious actor gains remote control of a vehicle, they could be able not only steal user data but also create a dangerous situation on the road. While intentional attacks targeting a vehicle’s functional safety have not become a widespread reality yet, that does not mean the situation will not change in the foreseeable future.

The digital evolution of the automobile

The modern vehicle is a relatively recent invention. While digital systems like the electronic control unit and onboard computer began appearing in vehicles back in the 1970s, they did not become standard until the 1990s. This technological advancement led to a proliferation of narrowly specialized electronic devices, each with a specific task, such as measuring wheel speed, controlling headlight modes, or monitoring door status. As the number of sensors and controllers grew, local automotive networks based on LIN and CAN buses were introduced to synchronize and coordinate them. Fast forward about 35 years, and modern vehicle is a complex technical device with extensive remote communication capabilities that include support for 5G, V2I, V2V, Wi-Fi, Bluetooth, GPS, and RDS.

Components like the head unit and telecommunication unit are standard entry points into the vehicle’s internal infrastructure, which makes them frequent objects for security research.

From a functional and architectural standpoint, we can categorize vehicles into three groups. The lines between these categories are blurred, as many vehicles could fit into more than one, depending on their features.

Obsolete vehicles do not support remote interaction with external information systems (other than diagnostic tools) via digital channels and have a simple internal architecture. These vehicles are often retrofitted with modern head units, but those components are typically isolated within a closed information environment because they are integrated into an older architecture. This means that even if an attacker successfully compromises one of these components, they cannot pivot to other parts of the vehicle.

Legacy vehicles are a sort of transitional phase. Unlike simpler vehicles from the past, they are equipped with a telematics unit, which is primarily used for data collection rather than remote control – though two-way communication is not impossible. They also feature a head unit with more extensive functionality, which allows changing settings and controlling systems. The internal architecture of these vehicles is predominantly digital, with intelligent driver assistance systems. The numerous electronic control units are connected in an information network that either has flat structure or is only partially segmented into security domains. The stock head unit in these vehicles is often replaced with a modern unit from a third-party vendor. From a cybersecurity perspective, legacy vehicles represent the most complex problem. Serious physical consequences, including life-threatening situations, can easily result from cyberattacks on these vehicles. This was made clear 10 years ago when Charlie Miller and Chris Valasek conducted their famous remote Jeep Cherokee hack.

Modern vehicles have a fundamentally different architecture. The network of electronic control units is now divided into security domains with the help of a firewall, which is typically integrated within a central gateway. The advent of native two-way communication channels with the manufacturer’s cloud infrastructure and increased system connectivity has fundamentally altered the attack surface. However, many automakers learned from the Jeep Cherokee research. They have since refined their network architecture, segmenting it with the help of a central gateway, configuring traffic filtering, and thus isolating critical systems from the components most susceptible to attacks, such as the head unit and the telecommunication module. This has significantly complicated the task of compromising functional safety through a cyberattack.

Possible future threat landscape

Modern vehicle architectures make it difficult to execute the most dangerous attacks, such as remotely deploying airbags at high speeds. However, it is often easier to block the engine from starting, lock doors, or access confidential data, as these functions are frequently accessible through the vendor’s cloud infrastructure. These and other automotive cybersecurity challenges are prompting automakers to engage specialized teams for realistic penetration testing. The results of these vehicle security assessments, which are often publicly disclosed, highlight an emerging trend.

Despite this, cyberattacks on modern vehicles have not become commonplace yet. This is due to the lack of malware specifically designed for this purpose and the absence of viable monetization strategies. Consequently, the barrier to entry for potential attackers is high. The scalability of these attacks is also poor, which means the guaranteed return on investment is low, while the risks of getting caught are very high.

However, this situation is slowly but surely changing. As vehicles become more like gadgets built on common technologies – including Linux and Android operating systems, open-source code, and common third-party components – they become vulnerable to traditional attacks. The integration of wireless communication technologies increases the risk of unauthorized remote control. Specialized tools like software-defined radio (SDR), as well as instructions for exploiting wireless networks (Wi-Fi, GSM, LTE, and Bluetooth) are becoming widely available. These factors, along with the potential decline in the profitability of traditional targets (for example, if victims stop paying ransoms), could lead attackers to pivot toward vehicles.

Which vehicles are at risk

Will attacks on vehicles become the logical evolution of attacks on classic IT systems? While attacks on remotely accessible head units, telecommunication modules, cloud services or mobile apps for extortion or data theft are technically more realistic, they require significant investment, tool development, and risk management. Success is not guaranteed to result in a ransom payment, so individual cars remain an unattractive target for now.

The real risk lies with fleet vehicles, such as those used by taxi and carsharing services, logistics companies, and government organizations. These vehicles are often equipped with aftermarket telematics and other standardized third-party hardware that typically has a lower security posture than factory-installed systems. They are also often integrated into the vehicle’s infrastructure in a less-than-secure way. Attacks on these systems could be highly scalable and pose significant financial and reputational threats to large fleet owners.

Another category of potential targets is represented by trucks, specialized machinery, and public transit vehicles, which are also equipped with aftermarket telematics systems. Architecturally, they are similar to passenger cars, which means they have similar security vulnerabilities. The potential damage from an attack on these vehicles can be severe, with just one day of downtime for a haul truck potentially resulting in hundreds of thousands of dollars in losses.

Investing in a secure future

Improving the current situation requires investment in automotive cybersecurity at every level, from the individual user to the government regulator. The driving forces behind this are consumers’ concern for their own safety and the government’s concern for the security of its citizens and national infrastructure.

Automotive cybersecurity is already a focus for researchers, cybersecurity service providers, government regulators, and major car manufacturers. Many automotive manufacturing corporations have established their own product security or product CERT teams, implemented processes for responding to new vulnerability reports, and made penetration testing a mandatory part of the development cycle. They have also begun to leverage cyberthreat intelligence and are adopting secure development methodologies and security by design. This is a growing trend, and this approach is expected to become standard practice for most automakers 10 years from now.

Simultaneously, specialized security operations centers (SOCs) for vehicles are being established. The underlying approach is remote data collection from vehicles for subsequent analysis of cybersecurity events. In theory, this data can be used to identify cyberattacks on cars’ systems and build a database of threat information. The industry is actively moving toward deploying these centers.

For more on trends in automotive security, read our article on the Kaspersky ICS CERT website.