On April 20, 2026, the Everest Ransomware Group posted the names of two banks on its dark web leak site.
Both were major banks. Both appeared on the same day. Both had their customer and document data offered for sale to the highest bidder in criminal markets.
The two banks had not been breached separately by two separate attacks. They had been breached simultaneously through a single shared vendor, a document production and processing company that both banks used. One vendor relationship. Two institutions. One coordinated exposure.
When investigators confirmed the breach origin, both banks issued the same statement in slightly different words: The breach did not originate in our own network.
That statement is accurate. It is also beside the point.
The vendor was their vendor. The data was their customers’ data. The liability was entirely theirs. The fact that the attack entered through a third party does not change who is accountable for the outcome.
This pattern is not new; one compromised vendor, multiple simultaneous victims. What is new is the scale, the coordination, and the speed. And for Indian banks, NBFCs, and payment companies operating under the RBI’s IT Governance framework, it is no longer a risk to monitor. It is a compliance obligation to address.
Why This Is Directly Relevant to Your NBFC or Bank Today
Before discussing what went wrong in that incident, consider your own vendor environment for a moment.
How many third-party companies currently have access to your systems, your customer data, or your internal network? Not how many you have signed contracts with. How many actually have live, operational access right now?
For a mid-size NBFC, that number is typically between 25 and 60. Core banking software providers. Loan management system vendors. KYC and CKYC service providers. Credit bureau integration partners. Fintech co-lending partners. Payment aggregators. IT support companies. Cloud management vendors. Payroll processors. Background verification agencies.
Each of those relationships involves a connection between their systems and yours. A login credential, an API endpoint, a remote access session, or a device that connects to your network for support or maintenance. Every one of those connections is a potential entry point.
The cyberattack was dominated by supply chain compromises. Attackers are no longer breaking down the front door. They are walking in through trusted third parties. People Matters
The two banks compromised through the Everest group’s attack did not have a security failure in their own infrastructure. They had a governance failure in how they managed what their vendors could access and when. That distinction matters. It is the same governance failure that exists, in some form, at nearly every Indian financial institution operating today.
What Happened and How the Attack Actually Worked
The Everest ransomware group is a financially motivated criminal organisation that specialises in data exfiltration before encryption. This is a double extortion model designed to maximise pressure on victims. They steal the data first, then encrypt the systems, then threaten to publish both unless a ransom is paid.
The attack on the two banks followed a pattern that cybersecurity researchers have documented across dozens of similar incidents in 2025 and 2026.
Step 1: The vendor was the target, not the banks.
Attackers identified a document production and processing vendor that served multiple financial institution clients. That vendor was the actual point of compromise. Its security posture was weaker than the banks it served. Its staff had privileged access to client data as part of their normal operational role. Breaching the vendor gave access to multiple clients simultaneously. This multiplication effect that makes shared vendors uniquely valuable targets.
Step 2: The breach was not detected until data appeared on the Dark Web leak site.
Neither bank detected the breach through its own monitoring systems. The first confirmation came when Everest posted the data publicly. This is the VeriSource pattern replaying at a financial institution level. Organisations discovering their data was compromised not through their own controls but through external notification, after the fact.
Step 3: Both banks confirmed origin, but neither had independent visibility.
The post-breach investigation confirmed the vendor as the origin. But neither bank had independent, real-time visibility into what their vendor was doing with their data, which systems the vendor was accessing, or when unusual access patterns began. The investigation relied on the vendor’s own logs. The same infrastructure that the attacker had already compromised.
Step 4: The shared vendor created simultaneous exposure.
Because the same vendor served both banks, both institutions were exposed in a single operation. The attacker did not need to run two separate campaigns. One breach, two victims. In 2025, the average downstream impact per third-party breach reached 5.28 companies. This is the highest level ever recorded, reflecting a sharp increase in attackers targeting shared platforms and high-dependency vendors. The April 2026 incident is this pattern operating exactly as designed. Cimcor
What RBI Already Requires Indian Banks and NBFCs to Do About This
This is where the incident stops being an American banking story and becomes a compliance obligation for every RBI-regulated entity in India.
RBI’s Master Directions on IT Governance mandate that banks and NBFCs establish comprehensive vendor risk assessment processes and controls, including third-party IT and cybersecurity arrangements. The same directions require service-level management processes, segregation of duties in IT operations, and documented data migration policies with audit provisions at every stage. Bitdefender
The IT Outsourcing Master Direction goes further. It requires that regulated entities:
- Maintain a register of all third-party IT service providers with a documented scope of access.
- Conduct risk assessments of vendors before engagement and at defined periodic intervals.
- Ensure that vendor contracts include the right to audit data security practices.
- Establish controls over what data vendors can access, export, or process.
- Monitor vendor compliance with agreed security standards on an ongoing basis, and not just at contract signing.
Most Indian NBFCs and banks have the contracts. They do not have the monitoring. Those two banks had contracts with their shared vendor. The contracts did not stop the breach. They did not detect it. They did not limit the damage.
A contract is a legal instrument. It does not monitor a network connection in real time.
The Specific Gap That Let This Happen
At the operational level, the breach succeeded because of a specific technical and governance failure that is replicated across thousands of Indian financial institutions today.
The vendor had access. Nobody was watching what that access looked like in real time.
When a vendor’s support engineer connects to your network for maintenance, that connection should be logged, time-limited, and monitored. The device they bring should be registered and verified before it touches anything inside your perimeter. If that device or that session begins accessing systems or data outside the defined scope of the engagement, an alert should fire. It should not fire after the breach is discovered, but at the moment the anomaly begins.
What most Indian NBFCs and banks have instead is a VPN credential issued to a vendor, valid indefinitely, with no monitoring of what happens after it is used.
This is the gap that EasyNAC addresses at the network level. Network Access Control identifies every device attempting to connect to your network and enforces policy-based access from the moment of connection. A vendor device that has not been registered is flagged immediately. A registered device that begins accessing network segments outside its defined scope triggers an alert. A session that extends beyond its authorised time window is automatically terminated.
Critically, EasyNAC does this without requiring any changes to your existing switch infrastructure or network reconfiguration. For an NBFC that needs to demonstrate active vendor access monitoring to an RBI auditor, this is the operational evidence that a contract clause cannot provide.
The attack worked because both banks had no mechanism to see what their vendor’s access looked like from inside their own network. If either bank had NAC deployed, the document production vendor’s connection would have been operating within a defined, monitored, and logged access perimeter. An anomalous data export, the kind that precedes the encryption phase of a double extortion attack, would have generated an alert before 13 million records were on their way to a criminal forum.
As our earlier blog on unverified devices established, you cannot protect what you cannot see. The vendor access problem is the device visibility problem at scale.
6 Steps Every Indian NBFC Must Take Before the Next Shared Vendor Breach
1. Build a complete vendor access inventory
Not a contract register. An access inventory. List every third party that has live, operational access to your systems or network right now. Include login credentials, API integrations, remote access sessions, and physical device connections. For each document: what they can access, what they are authorised to access, and when that access was last reviewed. Most NBFCs will find that these two lists do not match.
2. Segment your network so vendor access is isolated
A vendor who needs access to your loan management system should not have network-level access to your core banking infrastructure. Segmentation ensures that a compromise originating in a vendor’s session cannot spread laterally into systems beyond their defined scope. This is a foundational security architecture requirement. It is one that NAC enforces automatically at the device level without manual intervention.
3. Time-limit all vendor access sessions
Permanent credentials issued to vendors are permanent attack surfaces. Every vendor access credential should have a defined expiry period, require re-authorisation for renewal, and be revoked immediately when the engagement ends. The support engineer who helped with a system upgrade six months ago should not still have valid credentials today. Audit your current active vendor credentials against the list of current active engagements.
4. Conduct a security posture assessment of your top 10 vendors
RBI’s IT Outsourcing Direction requires periodic vendor risk assessment. Most NBFCs interpret this as reviewing a vendor’s ISO certification or a self-completed questionnaire. A genuine assessment covers the vendor’s own network security controls, their incident response capability, and their ability to detect and notify you of a breach affecting your data within the required timeline. If a vendor cannot answer basic questions about their own security architecture, they should not have privileged access to yours.
5. Build an independent breach detection capability for vendor sessions
The ability to detect a breach in vendor-managed data should not depend on the vendor’s own monitoring systems. Those systems are the ones that were compromised. Independent network monitoring that logs vendor session behaviour gives you a detection capability that survives a vendor breach.
6. Update your incident response plan to include vendor-originated breach scenarios
Most Indian financial institutions’ incident response plans cover direct attacks against their own infrastructure. Few have a specific playbook for: vendor notifies us of a breach affecting our customer data. Who is notified internally? Who contacts the Data Protection Board under DPDP? Who contacts RBI under the six-hour CERT-In reporting requirement? Who communicates with affected customers? The DPDP Act’s 72-hour notification requirement applies regardless of whether the breach originated in your own systems or a vendor’s.
A Comparison: What Controlled Vendor Access Looks Like vs. What Most NBFCs Have
| Most Indian NBFCs Today | With NAC and Vendor Access Controls | |
|---|---|---|
| Vendor device verification | Unverified, access granted on credential alone | Device registered and verified before network access |
| Access scope | Open network access post-authentication | Policy-enforced, vendor accesses only defined segments |
| Session monitoring | None or manual log review | Real-time alerting on anomalous behaviour |
| Credential management | Permanent credentials, manual revocation | Time-limited, auto-expiry, logged re-authorisation |
| Breach detection | External notification (vendor, dark web) | Internal alert triggered before data leaves the network |
| RBI audit evidence | Signed contracts and policy documents | Live access logs, device registry, session records |
The difference between the left column and the right column is not a large infrastructure project. It is a governance decision implemented through the right technical controls.
The Broader Pattern
The incident is the latest in a sequence that has been building since 2023. In 2025, third-party breaches reached record scale. 136 major events affecting 719 named companies and an estimated 26,000 additional downstream victims. The average of 5.28 downstream victims per breach was the highest ever recorded. Cimcor
Attackers have understood for several years that shared vendors are multipliers. One investment in compromising a single vendor yields access to every client that vendor serves. The more clients the vendor has, the higher the return on the attack. Financial institutions are disproportionately targeted because the data they hold and the data their vendors process on their behalf are disproportionately valuable.
Only about 10% of Indian companies that suffered a third-party breach in 2024 actually made it public. The recent incident involved US banks whose disclosure obligations and public visibility made concealment impossible. Indian companies operating under weaker disclosure norms are suffering the same breaches with less visibility and, until the DPDP Act’s full enforcement in May 2027, with less regulatory consequence. Workplaceprivacyreport
Final Thought
The CISO at an Indian NBFC, reading this, has vendors. Those vendors have access. Some of that access has not been reviewed since the contract was signed. Some of it extends further than the contract specifies. And none of it is being monitored in real time in a way that would generate an alert before the data is already gone.
The two American banks that appeared on Everest’s leak site had legal teams, compliance departments, and cybersecurity budgets. What they did not have was operational visibility into what their shared vendor was doing with their data.
That is not a budget problem. It is a governance problem. And it is a problem that the RBI’s IT Governance directions, the DPDP Act, and the next ransomware group operating in your vendor ecosystem will all, in different ways, eventually force you to address.
The only question is whether you address it before or after your customers’ data is on a leak site.
At Skeletos IT Services, we help Indian banks, NBFCs, and financial institutions deploy EasyNAC, a plug-and-protect Network Access Control solution that gives IT teams real-time visibility and control over every device on their network, including vendor and third-party connections, without any switch changes or network reconfiguration. If you want to understand what your vendor access environment actually looks like right now, we can show you in a 30-minute demo.
