#FactCheck -AI-Altered Clip Falsely Attributes Taliban Comments to General Upendra Dwivedi
Executive Summary
A video clip of Indian Army Chief Upendra Dwivedi is being widely shared across social media platforms with the claim that he criticised the Indian government's policy towards Taliban-ruled Afghanistan. In the viral clip, the Army Chief is allegedly heard saying that India is doing nothing except sending money to the Taliban government due to the Centre’s failed policies.
However, CyberPeace Research Wing research found the claim to be false. The viral video is a deepfake. In the original footage, General Upendra Dwivedi was speaking about Operation Sindoor and the preparedness of the Indian Armed Forces for a possible “Operation Sindoor 2.0.” He made no remarks regarding the Taliban or the government’s Afghanistan policy.
Claim
An X user named “XaQil” shared the viral video on May 31, 2026, with the caption:“Due to failed policies of the Central Government, India is doing nothing except sending Money to Taliban government. How can money alone do everything?” — Army Chief General Upendra Dwivedi.
Fact Check
In the viral video, General Dwivedi is purportedly heard making remarks about India’s Afghanistan policy, the Taliban, Pakistan, Iran, and India’s diplomatic position. To verify the claim, we searched for the original source of the video. A reverse image search of key frames led us to the authentic footage posted by news agency ANI on its official X account on May 30, 2026.
In the original video, General Dwivedi was responding to a question about Operation Sindoor. He stated that the operation was still ongoing, hostilities had only paused temporarily, and that the Indian Armed Forces were fully prepared if “Operation Sindoor 2.0” became necessary.
He also spoke about enhancing coordination among the three services and maintaining operational readiness.”
No part of his statement mentioned the Taliban, Afghanistan, Pakistan, Iran, or criticism of the Central Government.
Further corroboration came from media reports covering the same event. According to a report published by Navbharat Times on May 30, 2026, General Dwivedi made the remarks during the passing-out parade of the 150th course of the National Defence Academy (NDA), where he attended as the chief guest. He reiterated that the armed forces were fully prepared for “Operation Sindoor 2.0” if required.
Since the content of the viral clip did not match the original statement, we examined it using InVID’s MeVer Deepfake Detector. The tool flagged signs of AI manipulation and indicated that the video had likely been altered.
Conclusion
Cyber Peace Foundation found that the viral video purportedly showing Army Chief General Upendra Dwivedi criticising the Indian government’s policy towards the Taliban is a deepfake. The Army Chief made no such remarks. The original video was recorded during an NDA event, where he spoke about Operation Sindoor and the preparedness of the Indian Armed Forces for a possible future operation. The viral clip has been manipulated using AI to spread a false narrative.
Related Blogs
Executive Summary
As West Bengal heads for vote counting on May 4, 2026, following the second phase of Assembly polling held on April 29, a video is being widely shared on social media. The clip shows security personnel baton-charging civilians, with users claiming it depicts force being used during the West Bengal Assembly Elections 2026. Research by CyberPeace Research Wing found that the viral claim is misleading. The video is actually from Bangladesh and is being falsely linked to the West Bengal elections to spread confusion.
Claim
A Facebook user named “Adv Mohd Salman” shared the clip on April 29, 2026, using Bengal-related hashtags and claiming that voters standing in line were beaten to influence the election outcome. The post alleged that free and fair voting rights were being suppressed.
Fact Check
To verify the claim, we closely examined the viral video. A vehicle visible in the footage had a registration number written in a non-Hindi script. Using Google Lens reverse image search, we found a matching image uploaded on Alamy on December 30, 2018. The image showed a military vehicle with the same script and registration style seen in the viral clip.
According to the description on the platform, the image was taken in Dhaka during Bangladesh’s national elections and showed Bangladeshi army personnel moving through a street near a polling station. This confirms that the viral footage is not related to the 2026 West Bengal Assembly elections.
Conclusion
Our research confirms that the video showing security personnel baton-charging civilians is from Bangladesh, not West Bengal. It is being falsely shared as footage from the 2026 West Bengal Assembly elections to mislead users.
Introduction
Over the past few months, cybercriminals have upped the ante with highly complex methods targeting innocent users. One such scam is a new one that exploits WhatsApp users in India and globally. A seemingly harmless picture message is the entry point to stealing money and data. Downloading seemingly harmless images via WhatsApp can unknowingly install malware on your smartphone. This malicious software can compromise your banking applications, steal passwords, and expose your personal identity. With such malware-laced instant messages now making headlines, it is advised for netizens to exercise extreme caution while handling media received on messaging platforms.
How Does the WhatsApp Photo Scam Work?
Cybercriminals began embedding malicious code in images being shared on WhatsApp. Here is how the attack typically works:
- The user receives a WhatsApp message from an unknown number with an image.
- The image may appear harmless—a greeting, meme, or holiday card—but it's packed with hidden malware.
- When the user taps to download the image, the malware gets installed on the phone in silent mode.
- Once installed, the malware is able to capture keystrokes, read messages, swipe banking applications, swipe credentials, and even hijack device functionality.
- Allegedly, in its advanced versions, it can exploit two-factor authentication (2FA) and make unauthorised transactions.
Who Is Being Targeted?
This scam targets both Android and iPhone users, with a focus on vulnerable groups like senior citizens, busy workers during peak seasons, and members of WhatsApp groups flooded with forwarded messages. Experts warn that a single careless click is enough to compromise an entire device.
What Can the Malware Do?
Upon installation, the malware grants hackers a terrifying level of access:
- Track user activity via keylogging or screen capture.
- Pilfer banking credentials and initiate fund transfers automatically.
- Obtain SMS or app-based 2FA codes, evading security layers.
- Clone identity information, such as Aadhaar details, digital wallets, and email access.
- Control device operations, including the camera and microphone.
This level of intrusion can result in not just financial loss but long-term digital impersonation or blackmail.
Safety Measures for WhatsApp Users
- Never Download Media from Suspicious Numbers
Do not download any files or pictures, even if the content appears to be familiar, unless you have faith in the source. Spread this advice among family members, particularly the older generation.
- Turn off Auto-Download in WhatsApp Settings
Navigate to Settings > Storage and Data > Media Auto-Download. Switch off auto-download for mobile data, Wi-Fi, and roaming.
- Install and Update Mobile Security Apps
Ensure your phone is equipped with a good antivirus or mobile security app that is updated from time to time.
- Block and Report Potential Scammers
WhatsApp offers the ability to block and report senders in a straightforward manner. This ensures that it notifies the platform and others as well.
- Educate Your Community
Share your knowledge on cyber hygiene with family, friends, and colleagues. Many people fall victim simply because they aren't aware of the risks, staying informed and spreading the word can make a big difference.
Advisories and Response
The Indian Cybercrime Coordination Centre (I4C) and other state cyber cells have released several alerts on increasing fraud via messaging platforms. Law enforcement agencies are appealing to the public not only to be vigilant but also to report any incident at once through the National Cybercrime Reporting Portal (cybercrime.gov.in).
Conclusion
The WhatsApp photo scam is a stark reminder that not all dangers come with a warning. A picture can now be a Trojan horse, propagating silently from device to device and draining personal money. Do not engage with unwanted media, refresh and update your privacy and security settings. Cyber criminals survive on neglect and ignorance, but through digital hygiene and vigilance, we can fight against these types of emerging threats.
References
- https://www.opswat.com/blog/how-emerging-image-based-malware-attacks-threaten-enterprise-defenses
- https://www.indiatvnews.com/technology/news/whatsapp-photo-scam-alert-downloading-random-images-could-cost-you-big-2025-05-06-988855
- https://www.hindustantimes.com/india-news/what-is-the-whatsapp-image-scam-and-how-can-you-stay-safe-from-it-101744353412848.html
- https://faq.whatsapp.com/898107234497196/?helpref=uf_share
- https://www.welivesecurity.com/en/malware/malware-hiding-in-pictures-more-likely-than-you-think/
- https://faq.whatsapp.com/573786218075805
- https://www.reversinglabs.com/blog/malware-in-images
Introduction
For years, Indian companies could get away with vague privacy promises. That window closed on 13 November 2025, when the government notified the Digital Personal Data Protection Rules, giving teeth to the broad principles Parliament had passed back in 2023 under the DPDP Act. The Rules turned soft commitments into specific, auditable duties, and a lot of organisations are only now realising how much that actually changes.
Start with Section 8(4). It requires every Data Fiduciary to put "appropriate technical and organisational measures" in place. Most readers skim past "organisational" and focus on the technical half, but that's a mistake, because the word is doing real work. It's asking for defined roles, written policies, staff training, and someone actually watching whether any of it holds up over time, not just firewalls and encryption keys. Section 8(5) goes further, demanding reasonable security safeguards against breaches, and Rule 6 spells out exactly what that phrase means in practice: encrypt data at rest and in transit, restrict access on a need to know basis, require multi factor authentication, log and monitor activity, run regular vulnerability checks, bind your data processors contractually to the same standard, and keep relevant logs for at least a year.
Then there's Rule 7, and this is where the clock starts running. Once a Data Fiduciary becomes aware of a breach, the Data Protection Board must be told without delay, and a full report has to follow within 72 hours covering what happened, when, why, what's being done about it, and confirmation that affected individuals were notified. Unlike GDPR, there's no minimum severity threshold here. A breach affecting ten people triggers the same obligation as one affecting ten million. And CERT-In's existing six hour reporting window under its 2022 Directions still applies separately, which means a serious incident can trigger two overlapping regulatory clocks running side by side.
Put all of this together and a pattern emerges. The law assumes an organisation already knows what it's protecting, has actually protected it, kept usable records the whole way through, and can explain clearly what happened the moment something breaks. That coordination job belongs to Governance, Risk and Compliance, or GRC for short. GRC decides who's accountable, which risks actually matter, which controls address them, and how anyone checks whether compliance is real rather than assumed. Skip that structure and security work tends to splinter into a pile of disconnected tasks nobody truly owns.
GRC gives a legal duty somewhere to live. Forensic readiness is what lets an organisation prove, months or years later, that the duty was actually being met.
The Role of Governance, Risk and Compliance
On paper, most cybersecurity programmes look fine. There's an incident response plan somewhere, access control rules exist, logging is "in place," and someone has a title that says they're responsible for security. None of that gets tested until something actually breaks. A phishing compromise, a ransomware infection, a leaked database, a hijacked admin account, whatever the trigger, the questions that follow are always the same, and they're not comfortable ones. What happened, exactly, and when did it start? Which systems, which data, were actually touched? Were the controls the organisation claims to run genuinely functioning at that moment, or just described in a slide deck somewhere? And can anyone produce records solid enough to answer those questions with confidence rather than a shrug?
This is the exact seam where GRC and digital forensics meet. GRC lays out what's expected, who's responsible, and what evidence a control should be generating in the background. Digital forensics is the craft of taking whatever technical traces actually exist and turning them into an account of events that will hold up to scrutiny. Passing an audit was never really the point. Being able to stand in front of a regulator, mid incident, and show that the processes described on paper were real, active, and generating trustworthy evidence, that's the actual bar.
Why Compliance Alone Falls Short
Compliance, in the narrow sense, just means meeting whatever legal, contractual, or internal requirement applies. But a policy sitting in a document repository proves nothing about what actually happens on a Tuesday afternoon when someone requests admin access. A written incident response plan says nothing about whether the team can actually execute it under real pressure, at 2am, with a ransomware note on every screen. A logging policy is close to worthless if the logs it promises were switched off somewhere along the way, or overwritten, or scattered across systems that were never synchronised to the same clock.
NIST's Cybersecurity Framework 2.0 essentially built this concern into its core structure, placing "Govern" alongside Identify, Protect, Detect, Respond, and Recover as one of five equal functions rather than background paperwork sitting off to the side. India's own regulatory posture pushes in the same direction. CERT-In's 2022 Directions require certain incidents to be reported within six hours of discovery, and its guidance for government entities leans heavily on documented incident handling and disciplined evidence practices. The underlying message from both is identical: figure out, before anything goes wrong, whether the evidence you'll eventually need is actually going to exist when someone asks for it.
Where GRC and Forensics Actually Connect
A good GRC programme spells out what's supposed to happen. Forensic readiness is what lets you later prove what actually did.
Access control is a useful example here. On the GRC side, an organisation might require least privilege access, multi factor authentication, periodic reviews of who holds privileged accounts, and prompt removal of access once someone leaves or changes roles. On the forensic side, none of that means anything without the underlying records that let investigators actually test it, authentication logs, MFA usage history, privilege change records, and account activity trails. The table below lines up a few common GRC controls against the specific evidence needed to show they were genuinely operating.
A Practical Scenario: After a Ransomware Incident
Picture a mid-sized company waking up to find half its file servers encrypted. There's an incident response plan somewhere in the shared drive, technically, but nobody's actually run through it in over a year. The security team isolates the obviously compromised endpoint and starts escalating. Now the forensic side of the house has to reconstruct what happened, working backward through endpoint telemetry, authentication logs, firewall events, email traffic, and file activity, hunting for the original point of entry, how the attacker escalated privileges, how they moved sideways through the network, what data they actually touched, and finally how the ransomware got deployed.
This is where the quality of everything collected beforehand suddenly matters a great deal. If server clocks were never properly synchronised, the timeline investigators build might not line up cleanly enough to trust. If logs only ever lived locally on individual machines rather than being pulled centrally, some of them are probably gone by now. If nobody ever bothered logging administrator actions, there are going to be real, unexplained gaps in the story. And if whatever evidence does exist wasn't collected the right way, its integrity can be challenged later, sometimes fatally, in a legal or regulatory proceeding. CERT-In actually ran a programme on exactly this in July 2026, "Inside the Breach," covering system artefacts, investigative technique, and chain of custody requirements, precisely because this is where real investigations tend to succeed or quietly fall apart.
Building a Forensic Ready GRC Programme
For an organisation starting more or less from scratch, forensic readiness doesn't need to be bolted on as some separate initiative. It can be built straight into the GRC programme that already exists. Start by identifying the systems, applications, cloud services, and privileged accounts that actually matter. Map the real risks and regulatory requirements onto the controls meant to address them. Then get specific about what evidence each control should be generating, and how that evidence gets protected and kept over time. Time synchronisation, centralised logging, tightly controlled access to security records, and clear ownership of preservation, escalation, and investigation all need to exist well before an incident, not be improvised during one. And none of it means much until it's actually been tested, through tabletop exercises and simulated incidents rather than assumed to work because it's written down somewhere. NIST SP 800-61 Revision 3 frames incident response as one continuous loop of preparation, detection, response, recovery, and improvement, rather than a series of separate boxes to check.
There's one question worth asking of every important control an organisation runs: could you actually prove this was working at the moment an incident happened? If the honest answer is no, what you have is a compliance process on paper, and a forensic readiness gap sitting quietly underneath it.
Conclusion
Cyber readiness was never really about how many policies sit in a binder or how many boxes get ticked in an audit. It shows up, or doesn't, in the hours right after something breaks, when an organisation has to move fast, preserve evidence that can actually stand up to scrutiny, explain clearly what happened, and prove that governance and technical controls were genuinely working together rather than just coexisting on paper. GRC sets the direction, the accountability, the risk priorities, and the compliance expectations. Digital forensics does the work of preserving and interpreting the technical evidence once something actually happens. Forensic readiness sits in between the two, making sure they're actually talking to each other long before an incident forces the conversation. The practical task for most organisations comes down to something simple to say, if not always simple to build: design controls that hold up under real incident response, not just an auditor's checklist. The strongest compliance posture was never the one with the thickest binder. It's the one that can back every document up with evidence, on the day it actually matters.
References
- Digital Personal Data Protection Act, 2023, Sections 8(4), 8(5), 8(6). https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf
- Digital Personal Data Protection Rules, 2025, Rules 6 and 7, notified 13 November 2025. https://www.meity.gov.in
- National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, 2024. https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
- Indian Computer Emergency Response Team (CERT-In), Directions under Section 70B of the Information Technology Act, 2000, dated 28 April 2022. https://www.cert-in.org.in/Directions70B.jsp
- Indian Computer Emergency Response Team (CERT-In), Guidelines on Information Security Practices for Government Entities. https://www.cert-in.org.in/Downloader?fileName=CIPS-2026-0014.pdf&pageid=5&type=2
- National Institute of Standards and Technology, SP 800-86: Guide to Integrating Forensic Techniques into Incident Response, 2006. https://csrc.nist.gov/pubs/sp/800/86/final
- International Organization for Standardization, ISO/IEC 27037:2012, Guidelines for identification, collection, acquisition and preservation of digital evidence. CERT-In, "Inside the Breach: Advanced Cyber Forensics & Incident Investigation," 31 July 2026. https://www.cert-in.org.in/s2cMainServlet?pageid=PRSTNVIEW03&reCode=CIWS-2026-3569
- National Institute of Standards and Technology, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025. https://csrc.nist.gov/pubs/sp/800/61/r3/final
- Matters.ai, "DPDP Breach Notification: 72-Hour Rule & ₹200 Cr Penalty." https://www.matters.ai/article/dpdp-breach-notification MediaNama, "Data Breach Reporting Timeline of DPDP Rules 2025 Explained." https://www.medianama.com/2025/11/223-data-breach-reporting-timeline-of-dpdp-rules-2025-explained/
