On the morning of March 29, 2025, members of five major Australian superannuation funds woke up to find their retirement accounts had been accessed overnight.
Not by a single attacker hitting a single fund with a sophisticated exploit. By a coordinated campaign that hit AustralianSuper, Rest Super, Hostplus, Australian Retirement Trust, and Insignia Financial simultaneously. Attackers compromised over 20,000 accounts across the five funds. Four AustralianSuper members alone lost a combined AUD 500,000. Mondaq
The technical method used was not impressive. It did not require zero-day vulnerabilities or nation-state resources. The attackers used combolists from prior unrelated breaches, replaying stolen username-password pairs at scale against login portals that lacked multi-factor authentication enforcement. Mondaq
They did not hack anything. They logged in.
They used credentials that real people had created, forgotten about, and never been prompted to change. Credentials that the organisations never confirmed were still in the hands of the people to whom they were issued. Credentials that had simply been left open.
Five of Australia’s largest financial institutions were compromised in a single night, not because their security was weak, but because their access lifecycle was not managed. Valid logins existed for accounts that should have been locked, changed, or deleted months before the attack.
This is not a story about exotic malware. It is a story about what happens when the people responsible for human resources and the people responsible for IT security operate in separate worlds, with no shared system connecting an employment event to an access event.
In India’s financial sector, that separation is nearly universal.
The Indian Credential Problem Is Already Here
The Australian superannuation attack made international headlines because it was coordinated, simultaneous, and the funds were named publicly. The same attack vector was used against India’s financial sector in the same period.
In January 2025, a major Indian private sector bank’s vendor portal was targeted by the Bashe ransomware group, also identified as APT73. The group claimed responsibility on the dark web, set a ransom deadline, and threatened to release sensitive customer data publicly. The claimed entry point was not a firewall breach or a network intrusion. It was credential harvesting through a compromised vendor access point. A login that existed. A login that worked. A login that should not have been available. India Briefing
The bank did not confirm the breach scope. But the pattern the Bashe group exploited is well-documented across dozens of incidents in 2024 and 2025. Compromised credentials are now the most common initial access vector for the third consecutive year, accounting for 22% of all confirmed data breaches globally. Mondaq
They are the most common entry point because they are the cheapest to acquire and the easiest to use. Infostealer malware alone stole 1.8 billion credentials in 2025. Those credentials circulate in dark web markets for months or years after they are harvested. If the organisation that issued them has not revoked them, they remain valid entry points long after the employee left, the vendor engagement ended, or the original device was compromised. S.S. Rana & Co.
In June 2025, researchers discovered what may be the largest credential exposure in history: roughly 16 billion login credentials compiled from infostealer logs, phishing kits, and prior data breaches. Somewhere in that database are credentials from Indian companies. Some of them belong to people who left those organisations months ago. Some of them still work. Mondaq
Where Stale Credentials Come From in Indian Organisations
The credential problem in Indian NBFCs, banks, and financial services companies is not primarily a technology failure. It is a process failure. Specifically, it is the failure to connect two processes that happen in different departments and almost never talk to each other.
The HR process records that an employee has resigned, been terminated, or transferred to a different role. The exit interview happens. The final salary is processed. The experience letter is issued. The HR manager marks the person as inactive in whatever system they use to track headcount.
The IT process is supposed to deactivate that person’s system access. Email. VPN credentials. Core banking portal login. Loan management system access. CRM login. Any vendor portal the person was registered on. Any shared credentials they knew.
Between those two processes, in most Indian organisations, there is no automatic link. HR completes its work. IT is notified, if someone remembers to notify them, by email or a phone call or a message on WhatsApp. The IT team then manually works through a revocation checklist that may or may not exist, may or may not be complete, and may take anywhere from a few hours to several weeks depending on how busy the team is.
In that gap, the credential sits live.
Over one-third of ex-employees still have access to company email or work files after leaving. Nearly 75% of organisations have been harmed by a former employee’s access misuse. These are not numbers from poorly run startups. They reflect the standard operational reality of organisations with no automated linkage between HR events and IT access events. Prophaze
For an NBFC with 300 employees across five branches, manual offboarding coordination creates dozens of gaps every year. A field loan officer leaves. Their mobile app credentials, their branch login, and their access to the loan origination system all remain active until IT is told, verifies the information, and works through the revocation manually. That process rarely completes the same day the person walks out.
For a vendor relationship, the gap is often permanent. A software implementation partner’s engineer was given VPN access during a three-month project. The project ended. The vendor was paid. Nobody told IT to revoke the credential. The engineer’s login still works eighteen months later.
How Attackers Use Stale Credentials
Understanding what happens after a credential is harvested helps explain why the problem is so serious for India’s financial sector specifically.
Attackers who acquire credentials through infostealer malware, phishing, or dark web purchase do not always use them immediately. They validate them first. They test whether the credential is still active. If it is, it goes into a higher-value category and is either used directly or sold at a premium.
The attack against the Australian funds used combolists, bulk lists of credentials tested against multiple targets simultaneously. Around 76% of leaked password login attempts succeed, meaning that when attackers try a harvested credential, it works nearly four times out of five. Credentials that survive this test are exceptionally valuable because they require no additional exploitation. The attacker is authenticated. They are inside. Tsaaro
Once inside through a valid credential, the attacker behaves like a legitimate user. They move through systems the credential was authorised to access. They explore quietly. They do not trigger alerts designed to detect intrusions because they are not intruding. They are logged in.
This is what makes stale credential attacks so dangerous and so difficult to detect. The security tools that protect most Indian financial institutions are designed to detect malicious behaviour by unauthorised entities. They are not designed to detect a legitimate session being used by an unauthorised person. The log shows a login from a known username at a plausible time. Nothing flags.
The Bashe group’s claimed vendor portal attack followed this pattern precisely. A vendor credential, harvested at some point through malware or phishing, used to access a portal that the vendor relationship had long since justified. The access looked legitimate because the credential was legitimate. The problem was that the person or session the credential was issued to was no longer active in any relationship with the bank.
Why This Is Specifically an HR-IT Governance Failure
Every conversation I have with IT heads at Indian NBFCs and banks about credential security ends up at the same place. The technology to manage access exists. The policies to mandate revocation exist in most compliance documents. The failure is in the operational connection between the event that should trigger revocation and the system that performs it.
That connection lives between HR and IT. And in most organisations it is managed by memory, by email, and by goodwill. None of those are reliable at scale.
Consider what a structured employee lifecycle actually requires for security purposes.
When someone joins: their access should be provisioned based on their role, not on what they ask for or what their predecessor had. Over-provisioning at onboarding is how junior employees end up with access to systems they never needed, access that persists if their role changes and nobody reassesses it.
When someone changes roles: their previous access should be revoked immediately and new access provisioned for the new role. Role changes are one of the most consistently missed revocation events in Indian organisations. The person moves from a branch credit role to a head office analytics role. Their branch credit system access stays active. Nobody thinks to remove it because the focus is on giving them new access, not removing old access.
When someone exits: every system they could access must be revoked, not on a best-efforts basis, but as a governed, documented, timestamped process that completes within a defined window. For RBI-regulated entities, this is not optional. RBI’s Master Directions on IT Governance require documented access management processes including timely revocation on exit.
When a vendor engagement ends: the credentials issued for that engagement must be deactivated on the day the engagement closes, not when someone gets around to it.
In every one of these scenarios, the revocation event is triggered by an HR or procurement record, not by an IT event. If the IT team does not receive a reliable, real-time signal from the HR or vendor management system, the revocation does not happen on time.
Eight Steps to Stop Stale Credentials Becoming Your Entry Point
These steps are specific. Each one addresses a documented failure in the credential lifecycle at Indian financial institutions. They are ordered by the speed at which they close the most dangerous gaps.
Step 1: Connect your HR system directly to your access management process
The link between an employment event and an access event must be automated, not manual. When an employee exit is recorded in your HR system, that event should automatically trigger an access revocation workflow in IT. No email. No WhatsApp notification. No dependency on someone remembering to tell IT. The HR record creates the IT action.
This is the foundational change. Everything else is secondary to this connection. OfficeSIA is built with this link as a core function. The moment an exit date is recorded in OfficeSIA’s employee lifecycle module, a structured revocation workflow initiates automatically. IT receives a time-stamped task list with every system the departing employee accessed. The workflow tracks completion and logs every action. Nothing falls through a gap because the gap does not exist.
Step 2: Audit every active credential in your organisation this week
Run a full audit of every active login across every system. Match active credentials against your current active employee and vendor roster. Any credential that belongs to a person no longer employed or a vendor no longer engaged should be treated as a compromised credential and revoked immediately. In most Indian organisations, this audit will surface dozens of stale credentials. Some will have been active for months or years.
Step 3: Set a maximum credential lifetime for every external access point
Vendor VPN credentials, portal logins for third-party implementers, and temporary access for contractors should carry automatic expiry dates. A credential that was issued for a three-month implementation project should expire in three months. Not when someone thinks to revoke it. The expiry should be set at the time of creation and enforced automatically.
Step 4: Implement role-based access provisioning at onboarding
Every new joiner’s access should be provisioned according to their role profile, not according to what they request or what their predecessor had. Define access templates for each role in your organisation. A loan processing officer’s template includes access to the loan origination system. It does not include access to the risk analytics platform or the HR payroll module. Provisioning from a template prevents over-provisioning at the start and creates a clean baseline for what needs to be revoked when the role changes or ends.
Step 5: Make role change trigger an access review, not just new provisioning
Internal role transfers are among the most consistently missed revocation events. Build a rule into your HR system: every role change generates an access review task as well as a new access provisioning task. The previous role’s access permissions are reviewed and removed before or alongside the new permissions being granted. OfficeSIA’s role management module handles this within the same workflow, so a lateral transfer creates both a new access record and a revocation task for the previous role’s permissions automatically.
Step 6: Enforce multi-factor authentication on every external-facing access point
The Australian superannuation funds offered MFA. They did not enforce it. Regulators identified the failure to enforce MFA as the primary enabling factor in the attack. Offering MFA as optional is the same as not having it. Every VPN login, every vendor portal, every remote access session to internal systems must require MFA with no bypass option. If a user has not enrolled in MFA, they cannot access the system until they do. Mondaq
Step 7: Log and review authentication events for inactive accounts monthly
Your IT monitoring system should flag any login attempt from a credential that belongs to an employee who has left or a vendor whose engagement has ended. This is a one-time configuration task in most SIEM or identity management systems. Running a monthly report of authentication attempts from inactive accounts will catch stale credentials that were missed in step 2 and any new gaps that have opened since. If you find a login event from a credential that should have been revoked, you have found an active security gap. Treat it as an incident.
Step 8: Make offboarding a signed, documented process with a completion deadline
The exit process at most Indian companies is treated as an administrative formality. Under the DPDP Act and RBI’s IT Governance Master Directions, it is a compliance obligation. Build a formal offboarding checklist that includes: IT access revocation confirmation, return of company devices, revocation of any vendor portal credentials the employee may have shared, and a sign-off from both HR and IT confirming completion. Set a completion deadline of 24 hours for voluntary exits and same-day for terminations. OfficeSIA’s exit workflow generates this checklist automatically, assigns tasks to the relevant owners, sends reminders when tasks are overdue, and logs completion with timestamps. The signed record exists for audit purposes without anyone having to maintain it manually.
What Changes When the Process Is Automated
The organisations that got hit in the Australian superannuation attack were not negligent. They had security teams, compliance frameworks, and monitoring tools. What they did not have was a reliable, automated link between the event of a credential becoming inactive and the act of that credential being revoked.
When that link exists, the attack surface contracts immediately and measurably. A departing employee’s credentials are gone within hours, not weeks. A completed vendor engagement closes every access point that engagement created. A role change triggers a review that catches permissions that no longer apply.
The attackers who used combolists to hit five funds simultaneously were relying on a statistical certainty: across a large enough population of credentials, some percentage would still be active. Their success rate was high because they were right. The credential pool they tested against was full of logins that should have been expired but were not.
When your organisation automates the link between HR events and access events, you remove your credentials from that pool. The attacker still has the username and password. The credential no longer works. The attack fails at the point of entry.
The Broader Pattern
The credential harvesting problem is growing in India for a structural reason. The digital footprint of every employee is expanding. Five years ago, a branch banking employee might have had two or three system logins. Today, that same employee may have access to a core banking platform, a CRM, a loan origination tool, a document management system, a compliance reporting portal, a video conferencing tool, and a payroll self-service portal. Each of those is a credential. Each of those must be revoked on exit.
Manual offboarding processes were designed for a three-login world. They do not scale to a fifteen-login world. And they have no mechanism to catch the vendor credentials, the shared logins, and the temporary access grants that accumulate over the course of an employment relationship.
The Bashe group that targeted India’s financial sector in January 2025 did not need to be technically sophisticated. They needed a valid credential and a portal that accepted it. Both were available because the process connecting HR records to IT access records had a gap.
That gap exists in most Indian financial institutions operating today. It is not a secret. Attackers know it. Dark web markets price Indian financial sector credentials accordingly.
The question is not whether a stale credential from your organisation is circulating somewhere it should not be. The question is whether the credential still works when an attacker tries it.
Final Thought
I have visited branch offices at NBFCs across Pune and Mumbai where the IT team learned about an employee’s resignation from the HR manager two weeks after the person left. In those two weeks, the former employee’s system access was live, their email account was receiving customer correspondence, and their login to the loan origination system was valid.
Nobody did anything wrong intentionally. HR completed its process. IT was waiting to be told. The system that should connect those two departments did not exist.
That is not a security gap that a firewall closes. It is not a gap that better antivirus software addresses. It is a gap in the operational architecture that connects the life of an employee to the life of their credentials.
The organisations that will avoid the next credential-based attack on India’s financial sector are not the ones with the most security tools. They are the ones where the moment an employment relationship ends, the access that came with it ends too. Automatically. Completely. Without anyone having to remember.
That is a solvable problem. And it is a problem that belongs to HR and IT together, not to either department alone.
At Skeletos IT Services, we help Indian NBFCs, banks, and financial institutions deploy OfficeSIA, an HRMS built for the Indian compliance environment that connects employee lifecycle events directly to IT access management. When an employee exits, OfficeSIA’s automated offboarding workflow revokes system access, generates a compliance-ready audit log, and ensures nothing is missed. If you want to understand how many stale credentials exist in your organisation right now, we can help you find out in a 30-minute conversation.
