Cyber attacks on corporations and businesses have become routine. Auto and its associated industry is not immune to such attacks. This article explores the how and what of the cyberattack on Jaguar Land Rover Automotive PLC (JLR) in 2025 and maps the lessons learned from it.
INTRODUCTION
Cyberattacks against automotive manufacturers have evolved from isolated IT incidents into events capable of disrupting national-scale industrial operations. Jaguar Land Rover Automotive PLC (JLR), a UK-based multinational manufacturer of luxury vehicles and SUVs under the Jaguar and Land Rover marques, is a prominent example of this risk due to its large workforce, complex production infrastructure, and supply-chain dependencies. JLR’s principal activities include the design, development, manufacturing, and sale of Jaguar and Land Rover vehicles, and it employed approximately 33,000 personnel as of September 2025. The company has operated as a subsidiary of Tata Motors since 2008.
The automotive sector is an attractive target for ransomware groups and financially motivated threat actors, as operational disruption can directly translate into financial losses and reduced production throughput. Modern attacks frequently affect production systems, enterprise services, and supplier-facing infrastructure, resulting in halted manufacturing processes, delayed deliveries, and downstream supply chain impacts.
In September 2025, JLR reportedly suffered a major cyber incident, resulting in an estimated financial impact of approximately £1.9 billion [1]. The Cyber Monitoring Centre (CMC) described it as the single most financially damaging cyber event ever to hit the UK [2]. This paper leverages the incident as motivation for constructing a controlled proof-of-concept environment to evaluate the detection and investigation of ransomware-style attack behaviours using host-based monitoring and centralised event correlation. This aligns with guidance emphasising layered controls, limiting lateral movement and ransomware impact [3].
THE ATTACK
JLR was struck by a supply-chain attack in September 2025, allegedly carried out by the hacking group known as “Scattered Lapsus Hunters” [4]. This is a hacker collective comprising three black–hat hacking groups: Scattered Spider, Lapsus, and ShinyHunters. JLR was first targeted and hacked on 31st August 2025. Production was shut down on 2nd September and remained down for a full month, until JLR resumed production in October; however, the pause in manufacturing was costly, resulting in about £196 million in losses from the cyberattack alone.
Its impact was also felt well beyond JLR itself. According to the Office for National Statistics, the drop in production of some 27,000 vehicles knocked 0.17% off economic output in September. The company sits at the top of a large and complex supply chain involving thousands of businesses worldwide, including hundreds in the UK, many of whom are heavily reliant on orders from the car maker. The stoppage meant that a large number of them, including small and medium-sized businesses, were forced to shut down some or all of their operations, prompting warnings of potential bankruptcies.
The financial crisis became so severe that the government had to step in and provide JLR with £1.5 billion in funding to help its supply chain get back on its feet. Separately, the company began setting up a financing scheme, funded by a separate loan, that allowed suppliers to obtain early payment for new orders to ease their cash flow. JLR’s chief executive Adrian Mardell [5] described the cyber-attack and subsequent shutdown as an “incredibly difficult period” but said operations were continuing to “recover at pace”. He added that “the company is doing what we do best–produced luxury British cars”.
Things were going well; the storm had passed, and the company returned to production as if nothing had ever happened. They were about to take their first steps and progress in the wrong direction. Turns out that on 16th December, a single sophisticated social engineering interaction with a company’s employee would rip the scab off their wound.
AFTERMATH
This revelation came on 16th December 2025. It all started with an email which landed in the inboxes of roughly 38,000 JLR employees. The email informed employees that the cyberattack, which began in late August, had resulted in the exfiltration of payroll and human resources data from current and former staff and contractors. JLR believed that certain data related to current and former JLR employees and contractors had been affected by the cyber incident.
We are committed to supporting all current and former employees and contractors through this period, and we have set up a help line and arranged for access to credit and/or identity monitoring services, they said. What happened inside JLR was not a single system failure. Understanding how the attackers got in, how the damage spread and why the costs keep rising is now essential to understanding the company’s future.
ATTACK ARCHITECTURE AND ANATOMY
The JLR breach breakdown reveals that the intrusion was not the result of a sophisticated zero-day exploit, but rather the execution of well-known tactics: social engineering, credential abuse, weak segmentation, and inadequate detection.
Step 1: Phishing
Social Engineering was the heart of the attack. The hacker collective responsible has a long history of using phishing and vishing (voice phishing) to impersonate insiders. It is said that the hackers impersonated internal staff, tricking employees into disclosing credentials.
This social engineering attack was run by ShinyHunters. The group began its activities by targeting known vulnerabilities across cloud applications and restricted-use databases, but then changed course when it realised its efforts were not yielding the results it sought.
Armed with a valid username and password, in some cases with administrator rights, the attackers could log in through normal authentication flows. This meant they didn’t need to brute-force systems or exploit unknown flaws; they simply walked in with stolen keys.
Step 2: Vulnerability Exploitation
It was reported that the vulnerability exploited after the social engineering was an unpatched “SAP Netweaver” Vulnerability [6] (CVE-2025-31324 and CVE-2025-42999), which enabled remote code execution (RCE). They could use this vulnerability to upload web shells, lightweight command runners, and possibly reconnaissance scripts to further map the attack surface.
They also used infostealer malware outside the core JLR infrastructure, which may have harvested cookies (browser–stored credentials) or Atlassian Jira credentials. Now, some of these credentials were valid; there is a strong possibility they belonged to much older accounts that were still active. This infostealer malware was run on a third-party source–an LG employee.
Step 3: Lateral Movement
After breaching the perimeter, attackers expanded their access through lateral movement. They escalated privileges, navigated through JLR’s IT environment, and eventually reached core infrastructure. Reports indicate that once entrenched, they deployed ransomware or destructive malware, crippling servers and halting factory operations.
Step 4: Exfiltration and Encryption
The attackers exfiltrated large volumes of data, including an additional 350 GB dump, without being detected immediately. This indicates weaknesses in monitoring and anomaly detection across user activity and network behaviour.
Indicators such as unusually high data retrieval by a single account, Tor-based tunnelling, and sudden traffic spikes from uncommon IP ranges should have triggered alerts. Log tampering further delayed detection until the systems were compromised.
(The figure on the right shows the entire attack flow of the JLR cyber attack mapped to appropriate MITRE ATT&CK tactics:)
ATTACK MITIGATION AND LESSONS LEARNT
The JLR breach breakdown highlights systemic issues: stolen credentials went undetected, exfiltration of hundreds of gigabytes raised no alarms, and a lack of real-time visibility left the company blind until it was too late. However, with the correct measures, the attack could have been easily mitigated.
If an organisation can’t see, let alone understand, the routine behaviour of every programmable logic controller (PLC), human-machine interface (HMI), and other cyber-physical systems (CPS), they won’t be able to protect them. In some cases, those devices might run outdated software or have not been patched for long periods. That’s why it’s important to implement a solution tailored to operational technology (OT) environments, ideally with monitoring that automatically flags anomalous network activity before it becomes a threat.
In the JLR attack, attackers breached the network and moved laterally across it, causing greater damage to individual layers. By segmenting the network into isolated zones, system administrators can limit the extent of potential damage by containing breaches more effectively. An even better way to do this is to use a solution that automatically recommends network zones based on the organisation’s existing security infrastructure.
With a supply chain as vast and complex as JLR’s, the ripple effects of the breach may also have affected third parties with access to its network, including vendors and contractors. With the right secure remote access solution, organisations can isolate vendor connections, enforce a least-privilege access policy, and strengthen multi-factor authentication (MFA) for any external party attempting to access the network.
For OT networks, it’s long past time to move beyond traditional perimeter security. A zero-trust architecture requires each user to independently verify their identity with each login attempt and assumes an attacker is already inside the network. Implementing zero trust should be the very backbone of a robust cybersecurity strategy, especially as OT and IT become increasingly interconnected.
When recovering from a cyberattack, a good metric to keep in mind is mean time to repair (MTTR). This is the average time to complete a repair or other maintenance on a cyber-physical system, from the moment the engineer connects to it until the repair is finalised and the engineer disconnects. MTTR is a key metric for measuring resilience and reinforces the need for defined, rehearsed incident response plans. Conduct regular exercises that simulate an attack that causes a full production halt, and ensure the restoration process is documented and easy to reference in the event of an actual security incident.
RELATED WORK
A recent IEEE paper [7] investigated the deployment and practical applications of Wazuh as a security monitoring and threat detection platform. For example, Moiz et al. presented a Cloud-based Wazuh deployment framework that integrates host-based intrusion detection capabilities with customizable rules to secure small-business infrastructure, demonstrating how Wazuh components can be configured to detect network and system anomalies, such as port scanning and denial-of-service attacks.
However, this work primarily focuses on deployment procedures and usability rather than on analysing attack-phase behaviours or correlating multi-stage intrusion events. In contrast, this work evaluates Wazuhs’ effectiveness in detecting a multi-stage, ransomware-style enterprise intrusion, emphasising behavioural indicators, attack progression, and ethical simulation aligned with real-world incidents.
By mapping the complete attack flow to the MITRE ATT&CK framework [9], this approach emphasises the interaction between third-party compromise, application-layer exploitation, and post-exploitation activities, providing defenders and cybersecurity analysts with a unified view of detection and mitigation opportunities.
TECHNOLOGICAL LIMITATIONS
Since this paper was written, we have seen an exponential leap in technology, with Artificial Intelligence becoming the new normal. Despite these major breakthroughs, I have faced a few technological roadblocks and limitations that have prevented me from investigating this case to its full potential.
The first limitation was the lack of publicly available documents and sources. A large portion of the information about the attack has been redacted or simply not discovered by the media and press. Also, most sources did not dive into the technical depth required to fully comprehend the attack. If the infostealer’s source code was perhaps made open source by some of the cybersecurity organisations involved in the attack, it could have been to facilitate reverse engineering, which would prove useful in the long run.
The granularity of the MITRE ATT&CK framework also limits my work, as I cannot go into the details of each attack, which prevents me from providing a detailed account of what actually happened. Although even the basic attack flow, which has been constructed, shall suffice.
Certain assumptions have been made throughout this analysis, which may differ from the actual attack but are based on realistic environmental conditions, such as Enterprise-specific configurations, SAP deployment variations, and Cloud vs on-premises differences.
PROOF OF CONCEPT (POC)
This work presents a proof-of-concept (PoC) that emulates a JLR-inspired cyberattack using the open-source Security Event and Incident Management (SEIM) platform Wazuh [8], with an Ubuntu 22.04 (Jammy Jellyfish) system instrumented as a Wazuh agent serving as the victim endpoint. The main purpose here is to simulate the attack to show how easily it can be mitigated with open–source cybersecurity solutions like Wazuh.
All attack simulations were performed in an isolated laboratory environment using benign system actions. No real malware or exploitation tools were used, and no production or third-party systems were affected. This proof of concept focuses solely on the defensive side of this attack. The victim endpoint is virtualised to ensure successful simulation.
Given below is a diagram which clearly describes the attack surface as viewed by the offensive and defensive sides:
Here, a dummy setup is curated to simulate the attack surface, using Ubuntu 22.04 as the victim endpoint, which symbolises JLR. This is placed within the monitored zone with Wazuh as the SIEM. The Ubuntu machine (native OS) acts as the Wazuh Manager and also provides access to the Wazuh dashboard.
As shown in Figure 3, this is what the Wazuh dashboard looks like:
Next, the Ubuntu virtual machine is configured as a monitored endpoint by registering it with the Wazuh manager through the installation and activation of the Wazuh agent services by the following command:
This installs the Wazuh agent, which can be enabled by using the following commands:
sudo systemctl enable wazuh-agent.
sudo systemctl start wazuh-agent.
On the Wazuh manager machine, with the command:
sudo /var/ossec/bin/manage_agents
Press “A” to add an agent and specify its name and IP address, and then press “E” to extract the key, which is then copied and pasted. On the Wazuh agent machine, run the same command, then press the “I” key to import and paste the key. Now the machine is a Wazuh agent and is accepted by the Wazuh manager.
We are now ready to simulate the attack on this machine. We can start credential abuse by deliberately logging in to the Wazuh agent via. SSH and abusing this until the SIEM detects us. We can do this as follows: (Remember to set your virtual box adapter to a Bridged adapter to maintain connectivity between the attacker and the victim machine.)
Now, by using the command:
sudo /var/ossec/bin/manage_agents.
Here, “vboxuser” is the victim username on the machine, and 192.168.1.7 is the IP address. When prompted for a password, we will enter the wrong password multiple times, which will trigger Wazuh to detect us.
As expected, Wazuh detects this and labels it as an intrusive attempt under various attack categories, as defined by the ATT&CK framework. This proves it could have successfully alerted JLR when hackers were logging into its network.
However, we can take this a step further by embedding a backdoor into the network. We can do this safely by using the following command:
This is a backdoor account often used by hackers to establish persistence within the system, making it easier for them to access the machine later without being detected. But Wazuh detects this again, refer to Figure 6.
Notice how the “Defence Evasion” and the “Privilege Escalation” categories jump from 14 to 22 immediately after the backdoor was established. This highlights exactly how accurate and sensitive Wazuh is towards cyberattacks.
Now, for the final test, we will simulate how the ransomware group tried to encrypt the file. We can do this by using the following command and, at the end, stopping the SSH service itself to prevent further detection and escape the network altogether:
mkdir ~/test_files
for i in {1..20}; do echo "test" >> ~/test_files/file$i.txt; done
sudo systemctl stop ssh
But once again, Wazuh catches this.
Figure 8 presents the complete attack sequence, automatically summarised by Wazuh, which includes a built-in report-generation feature that facilitates efficient analysis and documentation of security events.
Conclusion
It can be concluded that cyberattacks remain common among big tech giants and automotive manufacturers such as Jaguar Land Rover. The JLR attack teaches us that even the most unexpected signs can be a warning of large–scale cyber heists pulled off by cunning masterminds around the world.
There is a famous quote in the realm of cybersecurity, and it goes as follows:
“The greatest vulnerability within a network is the people.”
This quote will always hold true, and that is why it is essential to make people cyber-aware. Awareness among people about such cyberattacks, phishing attempts, and the techniques hackers use can go a long way and be beneficial in the long run, both for the cybersecurity of individuals and companies.
Another important lesson we learn is that one does not need high–tech, expensive cybersecurity solutions for one’s company. Cyber–awareness and powerful open–source solutions can be just as impactful, if not more. People are encouraged to refer to open–source solutions not just because they are free but also for their surprising effectiveness, which is almost on par with certain closed-source, expensive software.
Companies should be open to hiring ethical hackers and penetration testers; they are among the most important assets for any company during this hour. Cybersecurity is blooming, security is expanding, and every day, new vulnerabilities are exposed. Enterprises are advised not to ignore even the smallest of vulnerabilities, as they have been the root of some of the biggest cyberattacks in history.
The analysis of a JLR-inspired ransomware scenario also demonstrates that early-stage behavioural indicators, such as anomalous authentication events, privilege escalation attempts, lateral movement and file encryption, are easily detectable through host-based security monitoring.
The study confirms that timely visibility and correlation of these indicators can significantly reduce the potential impact of ransomware incidents. Consequently, enterprise defences should prioritise identity monitoring, internal activity visibility, and configuration integrity as core components of cyber resilience strategies because the next industrial shutdown may not begin with a strike or a shortage–but with a line of malicious code.
References
[1] Finerva, Reports: Strategies and trends, Oct. 23, 2025 [Online]. Available: https://finerva.com/report/the-jaguar-land-rover-cyber-attac k-a-1-9bn-case-study-in-systemic-risk/
[2] G. Topham and J. Jolly, “Jaguar Land Rover slides to loss of almost cˇ500m after cyber-attack,” The Guardian, Nov. 14, 2025. [Online].
Available: https://www.theguardian.com/business/2025/nov/14/jaguar-land-rover-loss-cyber-attack
[3] UK National Cyber Security Centre (NCSC), “Mitigating malware and ransomware attacks,” [Online]. Available: https://www.ncsc.gov.u k/guidance/mitigating-malware-and-ransomware-attacks [Accessed: Jan. 13, 2026].
[4] Trinity of Chaos: The LAPSUS$, ShinyHunters, Resecurity, Sep. 25, 2025. [Online]. Available: https://www.resecurity.com/blog/article/ trinity-of-chaos-the-lapsus-shinyhunters-and-scattered-spider-alliance-embarks-on-global-cybercrime-spree
[5] CloudGuard, Jaguar Land Rover, Nov, 21 2025. [Online]. Available: https://www.linkedin.com/pulse/issue-92-jlrs-485m-cyber-hit-cloud flare-outage-broke-web-sjp9e/
[6] NIST, National Vulnerability Database, 2025. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2025-31324
[7] M. Moiz, S. Ahmed, and M. A. Khan, “Security and Threat Detection through Cloud-Based Wazuh Deployment,” in Proc. IEEE 1st Karachi Section Humanitarian Technology Conf. (KHTC), 2024, pp. 1–6.
[8] Wazuh Inc., “Wazuh: Open Source Security Platform,” 2024. [Online]. Available: https://wazuh.com
[9] The MITRE Corporation, MITRE–ATT&CK, [Online]. Available: https://attack.mitre.org/
[10] Treblle, Treblle: API Intelligence, Oct. 03, 2025. [Online]. Available: https://treblle.com/blog/jlr-breach-breakdown-analysis
