#FactCheck-AI-generated video falsely shared as real footage of Assam floods

Executive Summary:

CVE 2024-3094 is a backdoor vulnerability recently found in Kali Linux installations that happened between March 26th to 29th. This vulnerability was found in XZ package version 5.6.0 to 5.6.1. It could allow the malicious actor to compromise SSHD authentication, and grant unauthorized access to the entire system remotely. The users who have installed or updated Kali Linux during the said time are advised to update their system to safeguard against this vulnerability. 

The Dangerous Backdoor

The use of the malicious implant found in XZ Utils as a remote code execution tool makes it more dangerous, because of its ability to compromise the affected systems. Initially, researchers believed the vulnerability enabled an authentication bypass for the OpenSSH server (SSHD) process. However, further analysis revealed it is better characterized as a remote code execution (RCE) vulnerability.

The backdoor intercepts the RSA_public_decrypt function, verifies the host's signature using a fixed Ed448 key, and if successful, executes malicious code passed by the attacker via the system() function. This leaves no trace in SSHD logs and makes it difficult to detect the vulnerability. 

Impacted Linux Distributions

The compromised versions of XZ Utils have been found in the following Linux distributions released in March 2024:

• Kali Linux (between March 26 and March 29)
• openSUSE Tumbleweed and openSUSE MicroOS (March 7 to March 28)
• Fedora 41, Fedora Rawhide, and Fedora Linux 40 beta
• Debian (testing, unstable, and experimental distributions only)
• Arch Linux container images (February 29 to March 29)
• Meanwhile, distributions such as Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise, openSUSE Leap, and Debian Stable are not believed to be affected.

How Did This Happen?

The malicious code appears to have been inserted by taking advantage of a typical control transfer vulnerability. The original maintainer of the XZ Libs project on GitHub handed over control of the repository to an account that had been contributing to various data compression-related projects for several years. It was at this point that the backdoor was implanted in the project code.

Fortunately, the Potential Disaster Was Averted

As per Igor Kuznetsov, head of Kaspersky's Global Research and Analysis Team (GReAT), the vulnerability CVE-2024-3094 is considered as the largest scale attack that has happened in the Linux ecosystem history. Because it targeted the primary remote management tool for Linux servers on the internet which is  SSH servers.  

As this vulnerability was detected in the testing and rolling distributions in the short period of time, where the latest software packages are used. This results to the minimum damage to the linux users and so far no case of CVE-2024-3094 being actively exploited have been detected.

Staying Safe

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) advises that users who installed or updated the affected operating systems in March immediately roll back to XZ Utils 5.4.6 version and be on alert for any malicious activity. It is recommended to change the passwords in the case of a distribution where a weak version of XZ Utils has been installed. 

The Yara rule has been released to detect any infected systems by CVE-2024-3094 Vulnerability. 

Conclusion

The discovery of the XZ Utils backdoor provides a reminder to be vigilant in the open source software environment. This supply chain attack highlights the importance of strong security measures, elaborate code reviews, and regular distribution of security updates to provide shield against such vulnerabilities. Always staying informed and taking the necessary precautions, Linux users can mitigate the potential impact of this vulnerability to keep their systems safe.

References : 

• https://thehackernews.com/2024/03/urgent-secret-backdoor-found-in-xz.html 
• https://www.helpnetsecurity.com/2024/03/29/cve-2024-3094-linux-backdoor/ 
• https://www.kali.org/blog/about-the-xz-backdoor/ 
• https://www.kaspersky.com/blog/cve-2024-3094-vulnerability-backdoor/50873/ 
• https://www.rapid7.com/blog/post/2024/04/01/etr-backdoored-xz-utils-cve-2024-3094/ 

‍

Introduction

India is operating on digital rails today. Even as UPI is set to hit over 130 billion transactions by 2025, it already makes up around 80% of retail payments flow by volume. That volume is really what it is all about: a single extra transaction is simply another attack surface, and fraud has correspondingly scaled up. FY 2024-25 alone saw an estimated 485 crore in losses to UPI-related fraud through 632,000 reported frauds.  The response from the RBI has not been a single rulebook but a layered and dynamic regulatory infrastructure that currently spans banks, NBFCs, payment aggregators, card networks, and, by extension, the fintechs that connect into all of these components. Knowing why the infrastructure is shaped the way it is and what actual enforcement looks like is far more crucial than having a checklist in mind. This write-up moves beyond summarising the rules to outlining the thinking behind them, the latest trends shaping the segment and the reality of an implementation roadmap.

Why Has RBI Cybersecurity Compliance Become Non-Negotiable?

Three forces are converging on regulated entities at once:

1. The threat surface has outgrown legacy controls: Core banking systems were never designed for an ecosystem of APIs, third-party payment gateways, and unregulated fintech partners sitting on top of them. Every integration is a potential entry point, and attackers know it.

2. Financial stability is now a cyber question, not just a credit question: a prolonged outage at a large payment system operator doesn't just hurt one bank's balance sheet; it can freeze retail payments for hundreds of millions of people. RBI treats this as systemic risk, which is why its post-2020 directions lean so heavily on resilience (the ability to keep operating through an attack) rather than just prevention.

3. Enforcement has escalated: The RBI's May 2025 single order penalised five different banks, including levying a 97.80 lakh penalty on ICICI Bank with one part attributable to its late reporting of a cybersecurity incident and another to a lapse in account alert systems; this demonstrates this rise in intensity. Remember, under Sections 46 and 47A of the Banking Regulation Act 1949, the RBI has the power to levy penalties irrespective of the occurrence of an actual breach if an individual fails to comply with procedures like not properly assessing vendor access or reporting incidents late or failing to update crisis plans or timely reports. Now this is a significant development, an issue even in the absence of a full-scale 'hack'.

The Regulatory Architecture: What Actually Applies to Whom

Rather than one framework, regulated entities are governed by several overlapping directions depending on their category:

• Banks: The original RBI Cyber Security Framework requires board-approved cybersecurity policies, 24x7 Security Operations Centres, and defined incident reporting timelines.
• NBFCs: NBFCs were initially governed under the Master Direction on IT Framework for NBFC Sector, which escalates accordingly as per size of asset – the framework underwent substantial change in shape with the RBI notifying Cybersecurity, Technology Risk, Resilience and Assurance Framework directions, 2026 for NBFCs, which lays specific obligations based on tier level (NBFC-Base Layer, Middle Layer, Upper Layer & Top Layer entities) on issues like MIS reporting, fraud analytics & impact of incident reporting. 
• PSOs: Non-bank Payment system Operators PSOs have been regulated under the Master Direction on Cyber Resilience and Digital Payment Security Controls, 2024 (July 2024). Card networks, payment aggregators, PPI issuers and other PSOs come under its umbrella, with staged compliance based on the volume/business size (large – NPCI, card networks and the largest PPI issuers will meet requirements on April 1, 2025; medium ones by April 1, 2026; and small ones by April 1, 2028).
• Other Bodies: IT Governance (on all regulated entities broadly) The Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices, 2023, became effective on April 1, 2024, and has set basic benchmarks for information technology (IT) strategy committees, IT risk management processes & IT assurance functions.

Overall trends' information across all these is clear:  escalating tier requirements as per size and board-led controls are mandatory; a conscious acceptance that there will inevitably be data breaches in the future; and increasing emphasis on response and recovery.

Governance: Where RBI Compliance Actually Starts

A recurring theme across every RBI direction is that cybersecurity cannot be delegated entirely to the IT department. The Board of Directors is expected to own information security risk, with oversight typically delegated to a board subcommittee that meets at least quarterly. A board-approved information security policy, reviewed annually, must define the following:

• Roles and responsibilities across the Board, senior management, and the CISO
• Processes to identify, assess, monitor, and manage cyber risk
• Employee and stakeholder training and awareness programs

RBI's own 2022 thematic review of IT governance across 20 banks found unmanaged third-party vendor access, with vendors retaining privileged access to core systems long after a project ended at more than half the institutions reviewed. That kind of gap is a governance failure as much as a technical one: it happens because nobody owns the review cycle, not because the firewall is misconfigured.

Key Technical and Operational Controls

Once governance is in place, RBI's expectations translate into concrete control domains:

Infrastructure and access hardening: Network segmentation, endpoint protection, server hardening baselines, and multi-factor authentication for privileged access. Access reviews should be continuous or, at minimum, periodic, enforcing least privilege and separation of duties, not a one-time onboarding checkbox.

Vulnerability and patch management: Regular vulnerability scanning, risk-prioritised remediation, and a documented process for feeding vulnerability data into risk decisions, not just a scanner report sitting in an inbox.

Data security and localisation: Encryption at rest, in transit, and during processing; sound key management; data classification and masking; and adherence to the RBI's data localisation requirements for payment data.

Vendor and third-party risk: This has become one of the sharpest areas of regulatory focus. The 2024 PSO Master Directions explicitly require oversight of "unregulated entities" in the payment chain like payment gateways, third-party service providers, and vendors with due diligence, contractual security clauses, and ongoing monitoring baked in. For a bank or fintech, this means your compliance posture is only as strong as your weakest vendor's; the RBI increasingly holds the regulated entity accountable for its partners' failures, not just its own.

Security operations and incident response: 24x7 SOC capability, threat intelligence integration, and tested incident response plans via tabletop exercises and simulated attacks. A Cyber Crisis Management Plan (CCMP) drafted once and never rehearsed is, in practice, treated by RBI examiners as functionally absent.

Incident Reporting

This is where two separate regulatory clocks run in parallel, and conflating them is a common compliance mistake:

• RBI requirements: Regulated entities will normally have around 2-6 hours of detection to report most security incidents to the RBI with follow-up notifications as and when the nature of the incident unfolds.
• CERT-In's 6-hour rule: The CERT-In Directions dated April 2022 stipulate that every body corporate, which includes any bank, NBFC or payment aggregator, is obligated to report specified categories of cyber incidents to CERT-In within 6 hours of noticing them and not after fully confirming details at an additional 6 hours after noticing them. CERT-In directions also mandated that ICT system clocks are to be synced to NIC/NPL time servers, and system logs are to be maintained for a rolling 180 days within India.
• The Digital Personal Data Protection Act overlay: In the case of a data breach involving personal data, there will additionally be a 72-hour notification obligation from the data fiduciary to the Data Protection Board under the Digital Personal Data Protection Act, 2023, which runs in parallel to, and not in substitution of, the CERT-In time.

The practical consequences: If an SOP for incident response only maps one regime, then it would fail in an actual incident. We need a single intake process whereby multiple notification tracks are automatically triggered at the precise time an incident is detected, given that the inability to report "because we were still figuring it out" does not constitute an acceptable justification for a late notification under either regime.

Why Penetration Testing Sits at the Center of Compliance

RBI's VAPT (Vulnerability Assessment and Penetration Testing) mandate isn't a box-ticking annual scan. It's meant to validate, under real attack conditions, whether the governance and technical controls described above actually hold up. Automated scanning finds known vulnerabilities; penetration testing, ideally combining automated coverage with manual, business-context-aware testing, finds the logic flaws, chained exploits, and privilege escalation paths that scanners miss and that attackers actually use.

For most regulated entities, a realistic testing cadence looks like:

1. Semi-annual vulnerability assessments across critical systems
2. Annual (at minimum) penetration testing of applications, networks, and infrastructure supporting payment and customer-data systems
3. Testing triggered by events before go-live, after major changes, and post-deployment.
4. Documented remediation cycles and rescans, with reports mapped directly to the relevant compliance clauses for audit purposes

The Cost of Getting It Wrong

RBI's enforcement history grounds the financial impact of enforcement actions. In addition to the May 2025 fines levied on ICICI, Axis, IDBI, Bank of Baroda and Bank of Maharashtra, the RBI's published Enforcement Guidelines differentiate three levels of severity; procedural breaches such as delayed policy review or late incident notifications usually warrant 10 lakh to 1 crore fines plus formal reprimands and remediation orders with deadlines. Recurring governance breaches go farther than fines, resulting in restrictions on business activities and more stringent supervisory reporting, with egregious breaches leading to inclusion under the RBI's Prompt Corrective Action regime. Penalty orders are also publicly available, and the resulting toll on customer trust, partner trust, and investor confidence often dwarfs the fines.

A Practical Implementation Roadmap

For an organisation building or maturing its RBI compliance programme, a sensible sequence looks like this:

1. Establish board-level ownership first: Form or formalise the Board IT/Risk sub-committee, appoint or empower a CISO with real authority, and get the information security policy formally approved, and this is the foundation every RBI examiner checks first.
2. Mapping: A mid-sized NBFC, a large payment aggregator, and a scheduled commercial bank face different, overlapping obligations. Get this scoping wrong and you'll either over-engineer or leave gaps.
3. Secure third-party access: Audit every vendor with system access, revoke stale privileges, and build vendor security clauses into contracts going forward, not retroactively.
4. Build one incident response SOP: Run one compiled playbook that satisfies RBI, Cert-In and DPDP.
5. Schedule and actually rehearse tabletop exercises: not just write a CCMP and file it away.
6. Institutionalise VAPT as a continuous, risk-triggered programme rather than an annual compliance event, and ensure reports are structured to map directly onto RBI's compliance clauses for audit readiness.
7. Track the regulatory calendar actively: 2024–2026 has brought new NBFC directions, PSO phase-ins, and ITG-RC&AP obligations in quick succession, and the pace shows no sign of slowing.

Conclusion

RBI's shift from perimeter-focused prevention to a risk-based, resilience-first model reflects a broader reality: in a digital payments ecosystem processing billions of transactions a month, breaches are not a hypothetical to plan around; they're an operational certainty to plan for. The frameworks discussed here, cyber resilience directions, IT governance mandates, CERT-In's reporting clock and the new NBFC cybersecurity directions aren't separate hurdles to clear individually. They're converging into a single expectation: that regulated entities can detect an incident quickly, contain it, recover fast, and prove with documentation, tested plans, and independent penetration test evidence that they were ready for it in the first place.

For banks, NBFCs, and fintechs operating in India today, that readiness is no longer just a regulatory requirement. It's the baseline cost of operating in the financial system at all.

References

• https://www.getastra.com/blog/compliance/rbi-cybersecurity-compliance-checklist/

‍

Sources

1. Astra Security — RBI Cybersecurity Compliance Checklist for Banks & NBFCs in 2026: https://www.getastra.com/blog/compliance/rbi-cybersecurity-compliance-checklist/ 
2. TaxGuru — RBI Issues NBFC Cybersecurity and Technology Risk Directions, 2026: https://taxguru.in/rbi/rbi-issues-nbfc-cybersecurity-technology-risk-directions-2026-governance-framework.html 
3. Mondaq — Cyber Resilience and Digital Payment Security Governance (Master Directions, 2024): https://www.mondaq.com/india/fin-tech/1527836/cyber-resilience-and-digital-payment-security-governance-a-step-towards-secured-payments-systems 
4. TaxGuru — Master Directions on Cyber Resilience & Digital Payment Security Controls for Non-bank PSOs: https://taxguru.in/rbi/master-directions-cyber-resilience-digital-payment-security-controls-non-bank-payment-system-operators.html 
5. CyberNX — Ultimate Guide on RBI Master Directions for Cyber Resilience: https://www.cybernx.com/rbi-master-directions-guide/ 
6. SIRI Law LLP — A Comprehensive Guide to India's CERT-In 6-Hour Cyber Incident Reporting Mandate: https://sirilawllp.com/a-comprehensive-guide-to-indias-cert-in-6-hour-cyber-incident-reporting-mandate/ 
7. CreativeCyber — CERT-In 6-Hour Incident Reporting SOP for Indian Banks & NBFCs: https://creativecyber.in/resources/cert-in-6-hour-incident-reporting/ 
8. BW Businessworld — RBI Slaps Penalties on ICICI, Axis and Three Others Over Compliance Failures (May 2025): https://www.businessworld.in/article/rbi-slaps-penalties-on-icici-axis-three-others-over-compliance-failures-555643 
9. FluxForce — RBI Cyber Framework: Banks' Requirements & Penalties: https://www.fluxforce.ai/regulations/rbi-cyber-security-framework-banks 
10. MYITMANAGER — RBI Cybersecurity Guidelines 2026: What Banks and NBFCs Must Do: https://myitmanager.in/rbi-cybersecurity-guidelines-2026-banks-nbfcs/

‍

Executive Summary

A letter circulating on social media falsely claims that Prime Minister Narendra Modi has resigned from his post. CyberPeace Research Wing's research found the claim to be false. Our research  confirmed that the viral letter is fabricated and is being shared with a misleading claim. AI detection tools also indicate that the document is highly likely to have been generated using artificial intelligence.

‍

Claim

‍

An Instagram user shared the viral letter on July 29, 2026, claiming that Prime Minister Narendra Modi had resigned from office.

The post link, archived link, and screenshot are provided below:

https://www.facebook.com/photo/?fbid=2108984893363522&set=a.785246212404070 

https://ghostarchive.org/archive/aHXTq 

‍

Fact Check

‍

To verify the claim, we conducted a keyword search on Google. However, we found no credible media reports supporting the claim that Prime Minister Modi had resigned.

We then visited the official website of the Prime Minister's Office (PMO India). The website contained no announcement, press release, or official information confirming the purported resignation.

https://www.pmindia.gov.in/en/ 

‍

‍

As part of our research , we also reviewed the official X (formerly Twitter) account of PMO India. We found no post or statement related to the viral claim.

‍

https://x.com/PMOIndia 

Finally, we analyzed the viral letter using the AI detection tool Sightengine AI. The analysis indicated that the document is 99% likely to be AI-generated.

‍

‍

To further verify the findings, we also scanned the letter using AI or Not. According to the tool's analysis, the document is 64% likely to be AI-generated.

‍

‍

Conclusion

‍

The claim that Prime Minister Narendra Modi has resigned is false. No credible media organization or official government source has reported such a development. Furthermore, AI detection tools strongly suggest that the viral resignation letter was generated using artificial intelligence and is being circulated with a false claim.

‍