#FactCheck - Video Showing Sadhus in Ice Is Artificially Generated
Executive Summary
A video showing a group of Hindu ascetics (sadhus) allegedly performing intense penance while their bodies appear to be covered in ice is being widely shared on social media. Users are circulating the video as real and claiming that it represents an ancient tradition of Sanatan Dharma. CyberPeace research found the viral claim to be false.The research revealed that the video circulating on social media is not real but has been generated using artificial intelligence (AI).
Claim
On social media platform Facebook, a user shared the viral video on January 16, 2026. The video shows several ascetics engaged in penance, with their bodies seemingly covered in ice. Users shared the video while claiming that it depicts an authentic spiritual practice rooted in Sanatan Dharma.
Links to the post, archive link, and screenshots can be seen below.
Fact Check:
To verify the authenticity of the viral claim, CyberPeace searched relevant keywords on Google. However, no credible or reliable media reports supporting the claim were found. A close examination of the viral video raised suspicion that it may have been AI-generated. To verify this, the video was analysed using the AI detection tool Hive Moderation. According to the results, the video was found to be 99 percent AI-generated.
In the next step of the research, the same video was analysed using another AI detection tool, Sightengine. The results again indicated that the video was 99 percent AI-generated.
Conclusion
CyberPeace concludes that the video circulating on social media is not real. The viral video showing ascetics covered in ice was generated using artificial intelligence and does not depict an actual religious or spiritual practice.
Related Blogs
Introduction
Insurance companies hold a huge amount of sensitive data. Medical history, bank account numbers, identity proofs, years of claims records — all of it sits on insurer servers, waiting. That makes the sector an easy target. India saw close to 370 million malware attacks in a single recent year. Banking, financial services and insurance firms bore the brunt of it. That got the attention of the Insurance Regulatory and Development Authority of India (IRDAI). On 6 April 2026, it released a new set of Information and Cyber Security Guidelines. These replace the old 2023 rules and ask insurers to take much stronger responsibility for protecting their systems, and their customers' data.
Who Must Follow These New Rules
The updated guidelines are not limited to large insurance companies alone. They apply to life, general and health insurers. They also apply to foreign reinsurance branches operating in India, and to intermediaries such as brokers, corporate agents, web aggregators and third-party administrators. Insurance repositories and the Insurance Information Bureau of India fall within scope too. Individual insurance agents, point-of-sale persons and surveyors are not covered directly. But insurers must still make sure these people follow a basic security framework approved by their board. Foreign reinsurance branches get a little more room — they can depart from a specific rule, but only if they can justify it properly to the regulator. Why cast such a wide net in the first place? Because breaches rarely start at the big insurer with the well-staffed Information Technology (IT) team. They start with the small broker or corporate agent who never got around to updating a password policy.
A Stronger Role for the Boardroom
An Independent CISO (Chief Information Security Officer)
The clearest change sits right at the top. A Chief Information Security Officer (CISO) can no longer report to the Head of Information Technology (IT). Nor can the CISO (Chief Information Security Officer) be handed sales targets or any other business goal. Why does this matter so much? Picture a CISO (Chief Information Security Officer) who answers to the same person pushing hard for a product launch next week. Flagging a serious vulnerability suddenly becomes an awkward, career-risking conversation. The IRDAI (Insurance Regulatory and Development Authority of India) has simply removed that awkwardness by rule.
More Frequent Oversight
The Information Security Risk Management Committee used to meet only twice a year. Now it must meet at least once every quarter. A new Information Technology (IT) Steering Committee has also been set up to handle day-to-day technology decisions. This frees the risk committee to focus purely on oversight. There's also a new seat at the table: at least one outside cybersecurity expert must now join the Risk Management Committee. Someone with no stake in internal politics, no department to protect, just technical judgement.
Faster Action When Something Goes Wrong
A Six-Hour Reporting Deadline
No system is completely safe from attack. So the guidelines also focus heavily on how insurers respond once something goes wrong. Every cybersecurity incident now has to reach the Indian Computer Emergency Response Team within six hours of being spotted, with the IRDAI (Insurance Regulatory and Development Authority of India) and other regulators looped in at the same time. Six hours is a tight deadline. It means insurers need detection and escalation systems that work round the clock, not just during office hours.
Testing and Exceptions
Business continuity and disaster recovery plans must be tested at least once a year, and not through some comfortable, pre-planned shutdown either — the test has to feel like a real disaster. Exceptions to security policy are also handled with far more discipline now. A short exception of up to three months can be approved by the CISO (Chief Information Security Officer) alone. One lasting between three months and a year needs sign-off from the risk committee. Anything longer needs approval from the board itself. Gaps found during audits must be closed within twelve months, with the board tracking progress at every stage.
Looking Ahead to Tomorrow's Risks
The guidelines do not stop at today's threats. More insurers are moving their operations to the cloud. So the rules now demand stronger contracts with cloud vendors, and a clear plan for what happens to customer data once a vendor relationship ends. Third-party risk gets close attention too. Many security breaches in the financial sector start with a vendor, not with the insurer's own systems. Before hiring any vendor, insurers must now check their security properly. Every contract must include audit rights and a clause requiring the vendor to report incidents. One of the most forward-looking additions is early preparation for a post-quantum world. Insurers must keep a clear list of their cryptographic assets. In simple terms, this is a map of where and how encryption is used across their systems. It helps them get ready once stronger encryption standards become necessary. Quantum computers capable of breaking today's encryption are still some years away, by most estimates. Mapping out those cryptographic assets now is a lot cheaper than scrambling to do it after the threat has already landed.
Conclusion
Where does all this leave things? Cybersecurity in Indian insurance isn't a server-room problem anymore — it sits squarely in the boardroom now. Directors now own this risk, not just Information Technology (IT) managers tucked away in a basement office. Policyholders benefit too, since their data now sits behind stronger locks, watched more closely and reported on far more often than before. Insurers who treat this as a paperwork exercise will struggle to keep up. Those who actually build these habits into daily operations will likely spend less time firefighting breaches five years from now, and more time competing on service and price instead.
References
3. Medianama, 'IRDAI Updates Cybersecurity Rules, Mandates DPDP Compliance', April 2026.
4. DSCI, brief on IRDAI's Information and Cyber Security Guidelines, 2026, April 2026.
7. Deloitte India, 'IRDAI Tightens Cyber Net: Wake-up Call for Insurers'.
Executive Summary
Amid heightened tensions in West Asia, claims are circulating on social media alleging that Iran carried out missile and drone strikes on US military bases in Kuwait, particularly the Ali Al-Salem Air Base. The claim is being accompanied by a viral video showing massive explosions, fire, and thick plumes of smoke, which users say depicts the alleged Iranian attack. CyberPeace Research Wing research found that the viral video is from an explosion at a fireworks factory in Malta, a European country. It has no connection to the ongoing tensions in West Asia. However, Iran has claimed that it targeted US military bases in response to American strikes. Meanwhile, the United States has stated that it successfully intercepted and neutralized several Iranian missile and drone attacks.
Claim:
Instagram user ‘nitesh_nova’ posted a video on June 2, 2026 (archive link), stating: “Iran has carried out ballistic missile and drone attacks on US military bases in Kuwait, particularly the Ali Al-Salem Air Base. This action was taken in response to US airstrikes on Iranian positions, following which tensions in the Gulf region have significantly escalated.”
https://perma.cc/PQ7N-JYQS?type=standard
https://www.instagram.com/nitesh_nova/
Fact Check
A review of keyframes from the video using reverse image search tools led to reports identifying the footage as an industrial accident. The same visuals were found in news coverage published by France 24, which confirmed that the explosion occurred at a fireworks factory in Malta on June 1, 2026. The incident resulted in injuries to two individuals, although no workers were present inside the facility at the time of the blast.
https://www.youtube.com/watch?v=LTLGO-fu_QA
Further verification from 10 News Australia also supports the same context, showing the identical footage and reporting it as a fireworks factory explosion in Malta, posted on June 2, 2026.10 News Australia report
https://www.youtube.com/watch?v=8Lppvtdr50k
Conclusion:
The viral video being shared with claims of an Iranian missile strike on a US military base in Kuwait is misleading. The footage actually shows a fireworks factory explosion in Malta and has no connection to the ongoing geopolitical tensions in West Asia. Social media users are advised to verify such sensitive content before sharing, as misattributed visuals can significantly distort the understanding of real-world conflicts.
CyberPeace | Automotive Cybersecurity & Digital Forensics
Introduction
After a crash, the story usually comes from the driver, a witness or a police report. But a modern vehicle can leave another version behind - a digital one. An Event Data Recorder (EDR), commonly called a car's black box, can preserve selected information from the seconds around a crash. NHTSA describes EDRs as recording vehicle dynamics, driver inputs, crash characteristics, restraint status and some post-crash information.[1] The exact fields depend on the vehicle. A black box is not a magical device that records everything; it is one evidence source inside a much larger vehicle.
A modern vehicle can also contain safety controllers, diagnostic interfaces, ADAS, telematics and software-update systems. For an investigator, the question is what evidence can be linked to the EDR and what that combined record can actually support.
What Is Actually in the Black Box?
An EDR is best understood as a short event record, not a continuous driving diary. Depending on the vehicle and its configuration, forensic extraction may reveal items such as speed, acceleration, delta-V, engine RPM, throttle position, brake status, steering input, ABS or stability-control activity, seat-belt status and airbag or restraint events. NHTSA's published EDR material shows that data elements can include longitudinal and lateral acceleration, delta-V, vehicle speed, engine speed, throttle, service-brake status, roll/pitch/yaw information and steering input.[2] Do not overread the data: A field that exists in one model should not automatically be assumed to exist in another. A forensic report must identify exactly which module and fields were available and actually recovered.
What Can a Forensic Examination Recover?
A Brake Failure Example
Consider a driver who reports: “I pressed the brake, but nothing happened.” The statement should be preserved, but a forensic investigation should test it. Was brake status captured? What was the speed before the event? Did ABS activate? What were the acceleration and delta-V patterns? Were there relevant fault codes? Was the vehicle recently repaired or updated? Suppose the recovered records show a brake input, ABS activity and a change in vehicle speed before impact. That does not prove the brakes were mechanically perfect. It does, however, make the sentence “nothing happened” too simple. Conversely, a relevant fault appearing just before the event may give investigators a stronger lead. The important part is the comparison: human account, vehicle record, physical evidence and technical history should be examined together.
Smart Vehicles, Digital Evidence and Cybersecurity Investigation
A connected vehicle can communicate through cellular networks, Bluetooth, Wi-Fi, mobile applications, workshop tools and cloud services. If unusual activity appears around a safety-critical incident, investigators may need to look beyond the EDR. Useful questions include:
• Was there unusual diagnostic or service activity before the incident?
• Was a software update or configuration change recently applied?
• Do timestamps from different modules line up, or is there clock drift?
• Can the extracted record be tied back to the original vehicle and module?
• Is there a non-cyber explanation - such as a hardware fault or software defect - that fits the evidence better?
The mindset matters: A cyberattack should be a conclusion supported by evidence, not the default explanation for strange vehicle behaviour.
The Forensic View: From Data to Evidence
Automotive forensics is not simply plugging in a tool and exporting a report. The investigator should document the vehicle identity, module involved, extraction method, tool version, acquisition time and evidence-preservation steps. The goal is to make the work repeatable and defensible.
• Identify the relevant modules and evidence sources.
• Preserve the vehicle and extracted data against unnecessary alteration.
• Acquire data using a documented and appropriate method.
• Validate provenance, integrity, timestamps and completeness.
• Correlate EDR, diagnostics, software history, connected records and physical evidence.
• Report both findings and uncertainty.
A useful forensic rule: “Recorded” does not mean “proven.” Evidence becomes persuasive when its source, integrity and context are clear.
What the Law and Standards Are Changing
India is moving toward a more formal automotive cybersecurity lifecycle. IS-189 focuses on vehicle cybersecurity and the Cyber Security Management System (CSMS), while AIS-190 deals with software updates and the Software Update Management System (SUMS).[4][5] The wider statutory and type-approval framework is provided by the Motor Vehicles Act, 1988 and the Central Motor Vehicles Rules, 1989. For vehicle prototypes, Rule 126 provides for testing and approval by authorized testing agencies.[6][7]
In June 2026, the Ministry of Road Transport and Highways (MoRTH) came out with draft G.S.R. 503(E). The draft proposes new CMVR Rules 125-T and 125-U covering cybersecurity and software-update requirements. Since G.S.R. 503(E) is still a draft notification, its proposed requirements and the dates from which they may apply should be verified with the latest final notification before treating them as applicable law.[8]
At the international level, UN Regulation No. 155 addresses vehicle cybersecurity, while UN Regulation No. 156 covers software updates and their management.[9][10] This matters to forensics because lifecycle cybersecurity creates an expectation that manufacturers should be able to understand and manage security risks over time. In other words, logs, software-state information, vulnerability records and incident evidence can become part of the security story, not merely post-incident paperwork.
The Real Takeaway
The black box is valuable because it can reduce guesswork. It may tell us how fast the vehicle was moving, whether the driver applied the brake, how the vehicle responded, and what certain safety systems were doing around the event. But it rarely answers the whole case on its own. The strongest investigation is built by joining several pieces: EDR data, diagnostics, software context, connected-system evidence and what was found at the crash scene.
For cybersecurity professionals, the lesson is simple: a secure vehicle should not only resist attacks. It should also leave trustworthy evidence when something goes wrong. Good access controls, reliable timestamps and careful evidence handling help turn “something failed” into a defensible explanation.
Conclusion
The phrase “car black box” sounds simple, but the evidence behind it is not. An EDR can preserve a small but valuable window into a crash. During forensic examination, investigators may also be able to recover diagnostic, safety-system, software and connected-vehicle information, depending on the vehicle and what has been retained. The job is not to collect the largest possible amount of data. It is to collect the right data, preserve it properly and understand what each record can - and cannot - prove.
That is where automotive cybersecurity and digital forensics meet. As vehicles become more connected and software-driven, the ability to reconstruct an incident becomes part of security itself.
References
1. National Highway Traffic Safety Administration (NHTSA), Event Data Recorder (EDR) overview and research resources.
2. NHTSA, Use of Event Data Recorder (EDR) Technology for Highway Crash Data Analysis.
3. NHTSA, Light-Vehicle Event Data Recorder Technologies Update.
4. Automotive Research Association of India (ARAI), AIS-189, Approval of Vehicles with Regards to Cyber Security and Cyber Security Management System, April 2024.
5. Automotive Research Association of India (ARAI), AIS-190, Approval of Vehicles with Regards to Software Update and Software Update Management System, April 2024.
6. Government of India, Motor Vehicles Act, 1988.
7. Government of India, Central Motor Vehicles Rules, 1989, Rule 126.
8. Ministry of Road Transport and Highways, G.S.R. 503(E), 17 June 2026, draft Central Motor Vehicles (Amendment) Rules concerning cybersecurity and software updates.
9. UNECE, UN Regulation No. 155, Cyber Security and Cyber Security Management System.
10. UNECE, UN Regulation No. 156, Software Update and Software Update Management System.
11. NIST, SP 800-86, Guide to Integrating Forensic Techniques into Incident Response.
