#FactCheck-AI-Generated Video Falsely Attributed to Baba Ramdev, Claiming He Called for PM Modi’s Resignation

Executive Summary:

In late 2024 an Indian healthcare provider experienced a severe cybersecurity attack that demonstrated how powerful AI ransomware is. This blog discusses the background to the attack, how it took place and the effects it caused (both medical and financial), how organisations reacted, and the final result of it all, stressing on possible dangers in the healthcare industry with a lack of sufficiently adequate cybersecurity measures in place. The incident also interrupted the normal functioning of business and explained the possible economic and image losses from cyber threats. Other technical results of the study also provide more evidence and analysis of the advanced AI malware and best practices for defending against them. 

1. Introduction

The integration of artificial intelligence (AI) in cybersecurity has revolutionised both defence mechanisms and the strategies employed by cybercriminals. AI-powered attacks, particularly ransomware, have become increasingly sophisticated, posing significant threats to various sectors, including healthcare. This report delves into a case study of an AI-powered ransomware attack on a prominent Indian healthcare provider in 2024, analysing the attack's execution, impact, and the subsequent response, along with key technical findings.

2. Background 

 In late 2024, a leading healthcare organisation in India which is involved in the research and development of AI techniques fell prey to a ransomware attack that was AI driven to get the most out of it. With many businesses today relying on data especially in the healthcare industry that requires real-time operations, health care has become the favourite of cyber criminals. AI aided attackers were able to cause far more detailed and damaging attack that severely affected the operation of the provider whilst jeopardising the safety of the patient information.  

 3. Attack Execution 

The attack began with the launch of a phishing email designed to target a hospital administrator. They received an email with an infected attachment which when clicked in some cases injected the AI enabled ransomware into the hospitals network. AI incorporated ransomware was not as blasé as traditional ransomware, which sends copies to anyone, this studied the hospital’s IT network. First, it focused and targeted important systems which involved implementation of encryption such as the electronic health records and the billing departments. 

The fact that the malware had an AI feature allowed it to learn and adjust its way of propagation in the network, and prioritise the encryption of most valuable data. This accuracy did not only increase the possibility of the potential ransom demand but also it allowed reducing the risks of the possibility of early discovery. 

 4. Impact 

•  The consequences of the attack were immediate and severe: The consequences of the attack were immediate and severe.
•  Operational Disruption: The centralization of important systems made the hospital cease its functionality through the acts of encrypting the respective components. Operations such as surgeries, routine medical procedures and admitting of patients were slowed or in some cases referred to other hospitals. 
•  Data Security: Electronic patient records and associated billing data became off-limit because of the vulnerability of patient confidentiality. The danger of data loss was on the verge of becoming permanent, much to the concern of both the healthcare provider and its patients. 
•  Financial Loss: The attackers asked for 100 crore Indian rupees (approximately 12 USD million) for the decryption key. Despite the hospital not paying for it, there were certain losses that include the operational loss due to the server being down, loss incurred by the patients who were affected in one way or the other, loss incurred in responding to such an incident and the loss due to bad reputation. 

5. Response

As soon as the hotel’s management was informed about the presence of ransomware, its IT department joined forces with cybersecurity professionals and local police. The team decided not to pay the ransom and instead recover the systems from backup. Despite the fact that this was an ethically and strategically correct decision, it was not without some challenges. Reconstruction was gradual, and certain elements of the patients’ records were permanently erased. 

 In order to avoid such attacks in the future, the healthcare provider put into force several organisational and technical actions such as network isolation and increase of cybersecurity measures. Even so, the attack revealed serious breaches in the provider’s IT systems security measures and protocols. 

6. Outcome

The attack had far-reaching consequences:

• Financial Impact: A healthcare provider suffers a lot of crashes in its reckoning due to substantial service disruption as well as bolstering cybersecurity and compensating patients. 
•  Reputational Damage: The leakage of the data had a potential of causing a complete loss of confidence from patients and the public this affecting the reputation of the provider. This, of course, had an effect on patient care, and ultimately resulted in long-term effects on revenue as patients were retained. 
•  Industry Awareness: The breakthrough fed discussions across the country on how to improve cybersecurity provisions in the healthcare industry. It woke up the other care providers to review and improve their cyber defence status. 

7. Technical Findings

The AI-powered ransomware attack on the healthcare provider revealed several technical vulnerabilities and provided insights into the sophisticated mechanisms employed by the attackers. These findings highlight the evolving threat landscape and the importance of advanced cybersecurity measures.

7.1 Phishing Vector and Initial Penetration

• Sophisticated Phishing Tactics: The phishing email was crafted with precision, utilising AI to mimic the communication style of trusted contacts within the organisation. The email bypassed standard email filters, indicating a high level of customization and adaptation, likely due to AI-driven analysis of previous successful phishing attempts.
• Exploitation of Human Error: The phishing email targeted an administrative user with access to critical systems, exploiting the lack of stringent access controls and user awareness. The successful penetration into the network highlighted the need for multi-factor authentication (MFA) and continuous training on identifying phishing attempts.

7.2 AI-Driven Malware Behavior

• Dynamic Network Mapping: Once inside the network, the AI-powered malware executed a sophisticated mapping of the hospital's IT infrastructure. Using machine learning algorithms, the malware identified the most critical systems—such as Electronic Health Records (EHR) and the billing system—prioritising them for encryption. This dynamic mapping capability allowed the malware to maximise damage while minimising its footprint, delaying detection.
• Adaptive Encryption Techniques: The malware employed adaptive encryption techniques, adjusting its encryption strategy based on the system's response. For instance, if it detected attempts to isolate the network or initiate backup protocols, it accelerated the encryption process or targeted backup systems directly, demonstrating an ability to anticipate and counteract defensive measures.
• Evasive Tactics: The ransomware utilised advanced evasion tactics, such as polymorphic code and anti-forensic features, to avoid detection by traditional antivirus software and security monitoring tools. The AI component allowed the malware to alter its code and behaviour in real time, making signature-based detection methods ineffective.

7.3 Vulnerability Exploitation

• Weaknesses in Network Segmentation: The hospital’s network was insufficiently segmented, allowing the ransomware to spread rapidly across various departments. The malware exploited this lack of segmentation to access critical systems that should have been isolated from each other, indicating the need for stronger network architecture and micro-segmentation.
• Inadequate Patch Management: The attackers exploited unpatched vulnerabilities in the hospital’s IT infrastructure, particularly within outdated software used for managing patient records and billing. The failure to apply timely patches allowed the ransomware to penetrate and escalate privileges within the network, underlining the importance of rigorous patch management policies.

7.4 Data Recovery and Backup Failures

• Inaccessible Backups: The malware specifically targeted backup servers, encrypting them alongside primary systems. This revealed weaknesses in the backup strategy, including the lack of offline or immutable backups that could have been used for recovery. The healthcare provider’s reliance on connected backups left them vulnerable to such targeted attacks.
• Slow Recovery Process: The restoration of systems from backups was hindered by the sheer volume of encrypted data and the complexity of the hospital’s IT environment. The investigation found that the backups were not regularly tested for integrity and completeness, resulting in partial data loss and extended downtime during recovery.

7.5 Incident Response and Containment

• Delayed Detection and Response: The initial response was delayed due to the sophisticated nature of the attack, with traditional security measures failing to identify the ransomware until significant damage had occurred. The AI-powered malware’s ability to adapt and camouflage its activities contributed to this delay, highlighting the need for AI-enhanced detection and response tools.
• Forensic Analysis Challenges: The anti-forensic capabilities of the malware, including log wiping and data obfuscation, complicated the post-incident forensic analysis. Investigators had to rely on advanced techniques, such as memory forensics and machine learning-based anomaly detection, to trace the malware’s activities and identify the attack vector.

8. Recommendations Based on Technical Findings

To prevent similar incidents, the following measures are recommended:

1. AI-Powered Threat Detection: Implement AI-driven threat detection systems capable of identifying and responding to AI-powered attacks in real time. These systems should include behavioural analysis, anomaly detection, and machine learning models trained on diverse datasets.
2. Enhanced Backup Strategies: Develop a more resilient backup strategy that includes offline, air-gapped, or immutable backups. Regularly test backup systems to ensure they can be restored quickly and effectively in the event of a ransomware attack.
3. Strengthened Network Segmentation: Re-architect the network with robust segmentation and micro-segmentation to limit the spread of malware. Critical systems should be isolated, and access should be tightly controlled and monitored.
4. Regular Vulnerability Assessments: Conduct frequent vulnerability assessments and patch management audits to ensure all systems are up to date. Implement automated patch management tools where possible to reduce the window of exposure to known vulnerabilities.
5. Advanced Phishing Defences: Deploy AI-powered anti-phishing tools that can detect and block sophisticated phishing attempts. Train staff regularly on the latest phishing tactics, including how to recognize AI-generated phishing emails.

9. Conclusion

The AI empowered ransomware attack on the Indian healthcare provider in 2024 makes it clear that the threat of advanced cyber attacks has grown in the healthcare facilities. Sophisticated technical brief outlines the steps used by hackers hence underlining the importance of ongoing active and strong security. This event is a stark message to all about the importance of not only remaining alert and implementing strong investments in cybersecurity but also embarking on the formulation of measures on how best to counter such incidents with limited harm. AI is now being used by cybercriminals to increase the effectiveness of the attacks they make and it is now high time all healthcare organisations ensure that their crucial systems and data are well protected from such attacks.

‍

Introduction

Picture a pickup truck moving at around 30 kilometres an hour down a straight country road outside Canberra. A journalist is driving it. Somewhere nearby, a researcher sits with a laptop, and without touching the vehicle, he switches the headlights off while it is still moving, in the dark, turns them back on, activates the wipers at full speed, sprays the windscreen washer, and plays sound through the cabin speakers. That scene, broadcast in September 2026 as part of an ABC Four Corners investigation into connected car security, is the starting point for a conversation that extends well beyond the one vehicle involved. (It was a commissioned cybersecurity demonstration, authorised and arranged by ABC's Four Corners as part of their journalistic investigation titled "Asleep at the Wheel.").

What the test actually found

The vehicle at the centre of the investigation was a BYD Shark 6, a plug-in hybrid pickup, which ABC's Four Corners programme provided to automotive cybersecurity researcher Dan Hreszczuk, co-founder of Canberra based Fortify Labs, for a two week authorised assessment. Hreszczuk later described the access point he found in notably simple terms: it did not require a password at all.

Over the course of the test, Hreszczuk demonstrated remote interaction with the vehicle's headlights, windscreen wipers, door locks, cabin speakers and infotainment display. He also tracked the vehicle's real time location and accessed its cabin microphone, which raised concerns beyond vehicle control and into personal surveillance, since a compromised in car microphone can expose private conversations rather than just dashboard functions. It is worth being precise about what the test did not reach. Hreszczuk said he could not access the brakes or the vehicle's cameras, describing those systems as well protected, and the demonstration did not amount to complete remote control of the vehicle.

Following the broadcast, BYD ran its own internal investigation and confirmed a software defect in the Shark 6's infotainment system. The company's engineers reproduced the access path and traced it to Android Debug Bridge, a standard Android development tool that is meant to be disabled in production vehicles but had been left reachable through the defect, alongside a separate route through the vehicle's CAN bus network. BYD has said it will issue an over the air software update to close the gap. Fortify Labs, for its part, stated its objective had been to simulate the kind of remote access a vehicle manufacturer itself typically holds over a connected car, and to demonstrate how that same level of access could be misused if it fell into the wrong hands.

This context matters because it distinguishes a controlled, authorised research exercise, conducted over two weeks with extended physical access to a single vehicle, from an active criminal compromise. No malware was involved, and no evidence has emerged of this technique being used against vehicles outside the test. The finding is nonetheless significant precisely because it shows what becomes possible once a single weak point in a vehicle's software stack is identified and deliberately explored.

The questions this raises, beyond one vehicle

The useful questions are structural ones. How is authentication actually enforced across every vehicle facing service, not just the ones a manufacturer assumes a researcher might look at? Are a vehicle's internal networks and external facing services properly segmented, so that compromising an infotainment system does not create an unobstructed path toward a vehicle's core control units? Are commands subject to strong authorisation and validation at every layer, rather than relying on obscurity or an assumption that a particular access route would be too obscure to find? Is the principle of least privilege consistently applied, so that a development tool left active in a production vehicle, as appears to have happened here, does not carry the same level of access a factory engineer would have? How are unusual remote behaviours actually detected and investigated in real time, rather than discovered after the fact through an external test? And how are vulnerabilities tracked and patched across a vehicle's entire operational lifecycle, given that a car, unlike a phone, is expected to remain in active use for well over a decade after it leaves the factory floor.

A rulebook already exists. The gap is enforcement, not ignorance

None of this had to be worked out from scratch after the Four Corners broadcast. The industry has had a binding answer to most of these questions sitting on the books since 2021, when the World Forum for Harmonization of Vehicle Regulations adopted UN Regulation No. 155, known in the industry simply as R155. It requires any manufacturer seeking vehicle type approval to run a certified Cybersecurity Management System covering the car's entire life, from the drawing board through production and all the way to the vehicle still being driven a decade later, and to pass a dedicated cybersecurity assessment before that vehicle type can legally go on sale. Since July 2024 the rule has applied not just to new vehicle designs but to every new vehicle rolling off the line, across more than sixty countries that are party to the underlying 1958 UNECE agreement, a list that includes the European Union, Japan, South Korea, and Australia itself.

That last detail is where the picture gets genuinely interesting, and where a simple story stops being quite so simple. Australia sits among the countries that have signed on to the UNECE framework R155 belongs to, yet coverage of the Four Corners investigation reported something that sounds contradictory at first glance: that Australia has no minimum cybersecurity standard actually governing cars sold in the country. Both things can be true at once. Being a party to the 1958 Agreement establishes that a country participates in the broader regulatory architecture; it does not automatically mean every regulation born out of that architecture has been separately adopted into domestic law and is being actively enforced at the point of sale. R155's own companion standard, ISO/SAE 21434, is the detailed engineering playbook manufacturers actually use to meet the regulation's requirements, walking through how to assess threats, design around them, and keep monitoring for new ones long after a vehicle has left the factory. A framework that comprehensive existing on paper is only as useful as a given market's willingness to actually require manufacturers to follow it before a car reaches a driveway, and that gap between a regulation existing globally and a regulation being enforced locally is arguably the more unsettling finding buried inside this story than the hack itself.

The broader lesson

The real takeaway from this test has very little to do with the particular badge on the vehicle involved. It is a demonstration of what happens when any one interface in a complex, connected system is left weaker than the rest of the architecture around it. As vehicles continue absorbing more software, more connectivity and more remote functionality, security boundaries cannot be treated as a feature added once at launch. They need to be designed deliberately, enforced consistently, and monitored continuously across the entire lifecycle of the vehicle and the ecosystem of backend services it depends on, because the cost of getting that wrong is no longer confined to a screen or a server. It now extends to the physical vehicle itself, and the people inside it.

References

1. https://www.pakwheels.com/blog/byd-shark-6-hacked-during-cybersecurity-test-in-australia/
2. https://securityaffairs.com/199460/hacking/a-byd-shark-6-hack-shows-the-risks-of-connected-cars.html
3. https://autotalk.co.nz/byd-confirms-shark-6-software-defect-after-four-corners-hack-ota-fix-coming/
4. https://www.carexpert.com.au/car-news/byds-own-shark-6-hacking-investigation-reveals-software-defect
5. https://yourlifechoices.com.au/technology/the-connected-car-warning-behind-byds-shark-6-software-fix
6. https://arnav.au/2026/09/22/byd-got-hacked-what-really-happened/
7. https://pakobserver.net/byd-shark-6-hacked-in-security-test-as-researcher-gains-access-to-car-systems/
8. https://www.femalefirst.co.uk/motoring/byd-issue-security-update-shark-6-after-hacking-concerns-1451532.html
9. https://finitestate.io/blog/buckle-up-for-security-a-look-at-the-un-r155-regulation-for-connected-vehicles
10. https://www.arteris.com/learn/un-r155-2/

‍

Executive Summary:

‍

A video is going viral on social media with the claim that President Droupadi Murmu has allegedly demanded an independent inquiry into the loss of Rafale jets. In the video clip, Murmu can allegedly be heard saying that India should investigate the reasons behind the loss of the aircraft and learn from its mistakes. A research by the research wing of the CyberPeace revealed that the viral video has been tampered with. President Droupadi Murmu had made no such statement.

Claim:

‍

A video being shared on social media claims that President Droupadi Murmu has demanded the formation of an independent commission to investigate the causes behind the loss of India’s Rafale aircraft. In the viral video, Murmu can allegedly be heard stating that such an inquiry would help India avoid similar failures in the future.

https://archive.ph/UbLYj#selection-295.0-295.214

https://x.com/InsiderWB/status/2088669027258552509 

‍

‍

Fact Check

‍

During the research, we first conducted a customized keyword search using terms like "President Murmu", "Rafale jets", and "inquiry". During this search, we found no reliable media reports or official statements confirming the claim that President Droupadi Murmu had demanded an independent probe into the loss of Rafale aircraft. Upon performing a reverse image search on keyframes of the viral video, we found the original video of President Droupadi Murmu’s address to the nation uploaded on the official YouTube channel of the President of India on August 14, 2026. This address was delivered on the eve of India's 80th Independence Day. In the original video, President Murmu can be seen speaking in the exact same outfit and against the same background as visible in the viral clip. However, a review of the complete speech revealed no mention of Rafale aircraft or any demand for an independent inquiry into their alleged loss.

https://www.youtube.com/watch?v=BggdVYCyH6c

‍

‍

Following this, we analyzed the viral clip using several AI detection tools. Hive Moderation indicated a high probability that the video contained AI-generated or deepfake content.

‍

‍

Meanwhile, Resemble AI flagged the audio as fake.  

‍

‍

Conclusion

The statement regarding an independent probe into the alleged loss of Rafale aircraft in the viral video has been falsely attributed to President Droupadi Murmu. The clip appears to be manipulated using AI-generated video and audio. There is no such statement in the President's original Independence Day address.

‍