In the previous article, you became better acquainted with your vehicle and the vulnerability of ECUs. You also read about the regulations and standards that automobile manufacturers and their supplies must follow, with their respective challenges.
Today’s article will take a deep dive into how we implement the incident response (IR) process, assisting OEMs to face the challenge of a greater attack surface given the increasing number of connected cars.
Many terms used in this article have already been defined and described in the previous one. They are important for your understanding, so if you haven’t had the chance to read the last article, here is a link to part 1.
Some people describe modern vehicles as computers on wheels, but with great power comes even greater responsibility and risks. In this rapidly developing industry, vehicle cyberattacks have happened, and are a very real concern. It’s only a matter of time until vehicles will face the next big cyberattack on a large scale. The next few sections describe a real cyberattack scenario, its impact, who is involved in the IR process, and how we handle it at CYMOTIVE.
What If (Attack Scenario)
Identification
Recently, our anomaly detection system was alerted of two suspicious anomalies from two different agents in one vehicle. The first anomaly was observed by the In-Vehicle Infotainment system (IVI) agent and the second anomaly was picked up by an Ethernet agent. This situation was a novel event that warranted a deeper investigation.
Vehicle Overview
Typically, the investigation process starts by looking at the vehicle status. We use unique dashboards to gather details about the vehicle in question such as, when the vehicle was active, how many events the vehicle sent, what other anomalies were observed, the vehicle model, and others.
Remote Investigation
After looking at the vehicle status on our dashboards, we moved to a deeper investigation of the alerts. The alert that we received from the IVI agent indicated potentially suspicious process behaviors. This could include many processes, like the “radio” and the “display manager” that had crashed and started again. The crashed processes could sometimes be classified as non-suspicious behavior, but the high number of crashes in combination with the repeated attempts to restart, made this behavior more suspicious.
The second alert was from the Ethernet agent (network traffic inspection), which had triggered prohibited outgoing traffic that was blocked by the firewall. The source IP address was the IP address of the IVI, and the destination IP address was unknown to us. It had a destination port of 2271.
At this stage of the investigation, we understood that the simultaneous alerts from the two agents may have led to a cyber incident. We decided to reach out to the security team (Vehicle-SOC) for the specific vehicle brand, involving them in the incident investigation.
Many car companies operate Vehicle-SOC teams to attend to these issues. Typically, a Vehicle-SOC team has many more details regarding each vehicle, such as the location, the last time in the garage, and the specific ECU models. We further investigated the alert from the Ethernet agent by looking at the destination IP address, and we figured out that the address was associated with a known CNC (Command and Control) server.
Once we noticed that it was a CNC server, the highest priority action were to make sure that the vehicle has no safety issues, and that there was no communication between the vehicle and the IP address.
We asked the Vehicle-SOC team for the model and version of the relevant ECUs to investigate using our Vulnerability Management system.
Vulnerability Management
Figure 1- Car Alert system – ECU’s vulnerabilities found by the vulnerability management system
One area of interest in the cybersecurity automotive industry is Asset Management – especially for the ECUs. With the variety of vendors and ECU models active in a single vehicle, an infinite war is constantly being waged to manage all the versions and the relevant vulnerabilities to accurately assess, minimize, and mitigate the risks. To effectively minimize risk, we use a continuous vulnerability management process. Vulnerability management is the process of identifying, evaluating, reporting, and mitigating security vulnerabilities in systems and in the embedded software. This process, implemented alongside other security tactics, is vital for organizations to prioritize possible threats and minimize their attack surface.
Once we had the IVI ECU version, we analyzed it using the vulnerability management system and found that the specific ECU was exposed to a USB vulnerability.
In addition, we looked at all the data traffic logs from the vehicle and determined that no other connection attempts to the CNC server had been established.
Dynamic Investigation
After revisiting the situation, we understood that a deeper investigation of the IVI ECU is required. We investigated all the logs from the IVI agent and noticed that an external drive was connected to the IVI system. In addition, an unknown ELF file (file format for executable files) was running and was deleted immediately after it had finished.
We searched the unknown ELF file with antivirus scan engines and discovered that the file was a known ransomware associated with the same CNC server inspected previously.
Based on an “online” ransomware analysis, we were able to understand the ransomware behavior. Ransomware behavior on an external device (such as USB stick) uses the USB exploit knowing that the IVI version is vulnerable. The ransomware disables the IVI system, thus preventing anyone from using it. It tries to send details about the vehicle and its owner to the attacking CNC server. Thanks to the firewall, this attempt was blocked.
The Entire Attack Flow
Let’s wrap this entire scenario up from top to bottom:
1. 2 anomalies were observed from 2 different agents at the same time.
a. 1 anomaly was from the Ethernet agent.
b. 1 anomaly was from the IVI agent.
2. The IVI was vulnerable to a USB exploit.
3. An external device was plugged-in to the IVI.
4. The external device dropped ransomware malware to the IVI.
5. Multiple crash and restart processes disabled the IVI system.
6. Traffic to malicious CNC addresses was blocked by the firewall.
7. No other connections were observed involving the suspicious IP address.
Mitigation & Restoration
The mitigation process was performed by two teams: the Vehicle-SOC team and the CYMOTIVE team.
On the CYMOTIVE side, we:
• Looked for other indications of the suspicious IP address on the entire vehicle fleet.
• Added the IP address and the malicious file to our blacklists on our anomaly detection systems.
• Collected all vulnerabilities from the ECUs’ software from the Vulnerability Management system, published it to the Vehicle-SOC team for further action, and updated the relevant ECUs.
The Vehicle-SOC team:
• An over-the-air update was sent to the targeted vehicle to fix the issue.
• Checked which ECUs have the vulnerable software and versions.
• Sent an over-the-air update to the relevant ECUs to patch the exploit.
• Reached out to the vehicle owner and let him know that he had an issue with his IVI system.
Summary
This article presented a cyberattack on a vehicle and described the IR process to handle it.
When there is a cyberattack in the automotive industry, many parties and processes are involved, such as the Analyst teams (CYMOTIVE side), the Vehicle-SOC (the OEMs side), the Vulnerability Management team, and the targeted vehicle.
The described scenario here is based on a real attack simulation at CYMOTIVE, and real-life technology and threats.
