Sterling Bank & Remita: How a Global Hacker Walked Through Nigeria’s Banking Sector and Took Everything
Prologue
On April 1, 2026, a post appeared on spear.cx — a cybercrime forum — titled: NG Remita Payments Full Data. The actor behind it went by ByteToBreach. The post claimed access to approximately 3TB of data from Remita, Nigeria’s primary government payment infrastructure, the system through which the federal government runs its Treasury Single Account, disburses civil service salary payments, collects government revenue from over a thousand ministries, departments, and agencies, and moves financial instructions between public institutions and the Central Bank of Nigeria.
Near the bottom of the post, the actor included a line that connected this breach to one that had come before it: “All of this is happening, thanks to Sterling Bank of nigg*land. Their servers were very helpful in conducting the attacks on Remita.”
The VPS address listed in the post 206.217.216.145 was the same IP address used fourteen days earlier as the command-and-control server in the Sterling Bank breach.
One IP address. Two institutions. One chain.
This is the full story of how it all happened.
ACT ONE: THE BANK
Early Evening, March 18
At 5:49 pm GMT+1 on March 18, 2026, early evening in Lagos, a server answered a connection it should have refused.
The server belonged to Sterling Bank Plc, one of Nigeria’s licensed commercial banks, headquartered at 20 Marina, Lagos Island. The connection came from outside. The server was running a web application exposed to the public internet as part of the bank’s testing environment, and it had a flaw in it. A known flaw. One that security researchers had documented, written about, and issued a patch for. The flaw, catalogued as CVE-2025-55182, allowed anyone who knew about it to send a specially crafted request and receive, in return, the ability to run commands on the server as if they were sitting at the keyboard themselves.
A hacker who goes by the name ByteToBreach sent that request. The server accepted it. A command shell opened. ByteToBreach was now inside Sterling Bank’s infrastructure.
Nobody at the bank noticed.
Who Is ByteToBreach
ByteToBreach first appeared on underground cybercrime forums in June 2025.
Intelligence published by multiple threat research firms links the actor to over 40 confirmed incidents across commercial enterprises, government agencies, banks, law enforcement systems, and healthcare organisations in more than 26 countries.
The weeks immediately before Sterling Bank establish the pace of this operation. On March 9, ByteToBreach claimed a breach of CZ Slavia Pojistovna, a major Czech insurance company. On March 12, the actor published the complete source code of Sweden’s e-government platform after compromising CGI Sverige AB, the firm managing digital infrastructure for the Swedish government. Swedish authorities immediately opened a national investigation.
Six days after Sweden, ByteToBreach was inside Sterling Bank.
What nobody knew then, and what would only become clear two weeks later, was that Sterling Bank was not the destination. It was the corridor.
The Door That Was Left Open
To understand how ByteToBreach got in, you need to understand the concept of a CVE.
CVE stands for Common Vulnerabilities and Exposures. It is the global system through which security researchers formally document software flaws.
When a vulnerability is assigned a CVE number, it means the flaw has been identified, described, and, in most cases, a fix has been issued. The expectation is that organisations running the affected software will apply the fix promptly.
CVE-2025-55182 is a vulnerability in a web application framework built on React, a widely used technology for building modern websites and internal software platforms.
The flaw is severe as it allows an attacker to execute commands on the server without any authentication, without a username, without a password, without any credentials at all. You simply send the right kind of request, and the server gives you access.
The vulnerability had been publicly documented. Security researchers had written about it. A patch existed.
Sterling Bank was running unpatched software on a server called enf-pilot.sterling.ng, a pilot environment, meaning an internal testing ground for new systems before they go fully live.
Pilot environments are often treated as lower priority than production systems. They frequently receive less scrutiny. They are sometimes forgotten about entirely. They are also, by definition, connected enough to the real infrastructure to be useful for testing, which means a foothold in a pilot environment is a foothold in the bank.
At 5:49 pm on March 18, 2026, ByteToBreach used the Metasploit Framework, a widely available security testing tool, to fire the CVE-2025-55182 exploit at enf-pilot.sterling.ng. The server was vulnerable. A command shell opened. The actor was in.
Nine Days, No Alarm
This was not a smash-and-grab. ByteToBreach settled in.
They deployed Sliver, a sophisticated persistence framework that establishes an encrypted communication channel between the attacker and the compromised system and checked in for the first time on March 22, four days after the initial breach, still without any apparent detection by Sterling Bank’s security team.
From inside Sterling Bank’s Kubernetes cluster, the platform the bank uses to run its applications at scale, the actor ran a network scan and found 168 open internal services.
Among them was something that pointed to a fundamental gap in Sterling Bank’s software deployment discipline: development servers running inside the same environment as live customer systems.
In software, there is a fundamental distinction between the tools developers use to build an application and the finished, hardened product that serves real customers.
Development tools are deliberately open and unsecured. They are designed for a builder’s workshop, not a customer-facing institution. They serve up application source code, configuration details, and internal system logic that a properly built production environment would keep hidden entirely.
Sterling Bank had left them running. For an attacker already inside the network, they turned what might have been a slow, difficult reconnaissance process into a readable map.
The most consequential discovery came not from the network scan, but from reading the bank’s own code.
Modern web applications are built in layers. The layer that users interact with, like buttons, screens, interfaces, etc., is typically written in JavaScript and runs in the browser.
The layers underneath, where sensitive operations actually occur, are supposed to run on servers, out of reach. Between those layers sits the build process, the moment when developers package their code into the finished application that gets deployed to production.
The problem is that in the rush of software development, secrets sometimes get bundled into the wrong layer at the wrong moment.
The actor found Sterling Bank’s encryption keys sitting inside a JavaScript file in plaintext, accessible to any process running inside the compromised environment.
They found them by searching for obvious keywords like password, secret, encrypt.
The keys appeared immediately. With them, ByteToBreach could decrypt any encrypted data moving through Sterling Bank’s systems inlcuding financial transactions.
Over nine days, ByteToBreach enumerated every employee in the organisation, over 3,009 records including names, emails, phone numbers, staff IDs, departments, supervisor chains, and internal application access permissions.
They queried Sterling Bank’s Temenos T24 core banking system for customer account data, pulling full account details, transaction histories, and loan portfolios for any customer they chose.
They accessed Nigeria’s Credit Risk Central bureau through Sterling Bank’s integration, querying consumer credit profiles using BVN numbers.
They pivoted into Cardinal Stone Partners’ (Sterling Bank’s largest shareholder) investment database, finding full administrative access to investor records, shareholder data, and pension custodian information.
On March 27, they posted the results publicly.
Sterling Bank’s approximately 900,000 customers potentially had their data, BVN, transaction history, credit profiles, identity documents, etc., in criminal hands.
Till today, the bank has issued no statement.
The breach only became known to the public because ByteToBreach chose to post about it. Not because Sterling Bank found it.
But March 27 was not the end of the story. It was the intermission.
ACT TWO: THE INFRASTRUCTURE
The Corridor
While the Sterling Bank story was making its way through Nigerian cybersecurity circles on social media, ByteToBreach had already moved on.
Sterling Bank’s compromised infrastructure, its internal network, its service accounts, and its trusted connections to partner systems had given the actor a position inside Nigeria’s financial ecosystem.
From that position, they looked outward. And they found Remita.
Remita is not a name that appears in most conversations about Nigerian banking.
It operates in the background, largely invisible to the individuals whose financial lives it touches. But its role in Nigeria’s financial architecture is foundational.
Remita, operated by SystemSpecs, is the payment infrastructure through which the Nigerian federal government pays its workers, collects its revenue, and moves money between institutions.
The Integrated Payroll and Personnel Information System — IPPIS — which processes salaries for federal civil servants, runs through Remita.
The Government Integrated Financial Management Information System — GIFMIS — connects to it.
The CBN’s payment instructions flow through it. Universities, hospitals, ministries, parastatals, agencies: if they receive or remit money to the federal government, they do it through Remita.
ByteToBreach got in.
What They Found Inside Remita
The artefacts published by ByteToBreach in the Remita breach post tell a story of access so deep and so broad that it is difficult to overstate its implications.
The actor began with Remita’s Git repository, the complete source code of the payment platform, obtained by browsing through production configuration files using GitKraken.
Security scanning tools run against the repository returned what any security engineer would dread: hardcoded secrets throughout production configuration files. AWS access keys. Azure AD client secrets. Database connection strings with embedded credentials. Generic API keys.
All sitting in files committed to the repository by SystemSpecs engineers whose email addresses are visible in the commit history.
The repository itself was posted publicly for download.
The source code of Nigeria’s government payment infrastructure, including the logic for OTP verification, virtual wallet settlement, inter-bank transfer processing, and the PAPSS Pan-African Payment and Settlement System integration, is now in the possession of anyone who downloaded it.
The S3 storage was next.
Remita maintains multiple AWS S3 buckets for different services. The actor accessed them using the credentials extracted from the repository. The KYC bucket alone contained 657,242 files totalling 588GB of Know Your Customer (KYC) documents submitted by users of Remita’s services.
These are the identity verification documents that Nigerians submit when registering for financial services: passports, driver’s licences, voter cards, bank statements, utility bills, and photographs. The full bucket list was approximately over 3TB.
The databases were taken wholesale.
Three database dumps were posted for public download.
These contain the transactional records, user accounts, business owner registrations, and payment histories of Remita’s platform. The actor released 35,000+ password hashes freely alongside the database files.
The database tables visible in the published screenshots confirm the categories of data accessed, including business owner records with BVN and NIN numbers, inter-banking transaction records with destination bank codes and payment references, system administrator accounts with roles and access levels, and personal information tables containing KYC data and authentication tokens.
The Keys to Every Nigerian Bank
Of everything ByteToBreach published from the Remita breach, one image stands above the rest in terms of systemic threat.
A directory of cryptographic key files. 46 files, 23.4KB total. Named for every major bank in Nigeria.
These are Hardware Security Module keys.
HSMs are the physical and logical devices that financial institutions use to generate, store, and protect the cryptographic material that authenticates inter-bank payment instructions.
When a bank sends a payment through NIBSS, the Nigeria Inter-Bank Settlement System, the instruction is signed with an HSM-backed key. That signature is what tells the receiving institution that the instruction is legitimate, that it came from who it claims to have come from, and that it has not been tampered with in transit.
The presence of keys labelled for GTB, Zenith, UBA, First Bank, Access, FCMB, Fidelity, Sterling, Stanbic, Ecobank, and more than a dozen other institutions in a single directory on a compromised machine represents a threat to the integrity of Nigeria’s inter-bank settlement infrastructure.
If these keys are authentic and have not been rotated, and there is no public indication that they have been, the theoretical capability to forge payment instructions exists.
I am in no position to independently verify the authenticity or current validity of these keys from the published materials alone.
What can be said with certainty is that files with these names, from this source, require immediate verification by NIBSS, the CBN, and every named institution. The question of whether these keys are genuine is one that Nigeria’s financial regulators and settlement infrastructure operators must answer as a matter of urgency.
The CBN Connection
Among the source code and infrastructure visible in the Remita breach artefacts is something that goes beyond payment processing data.
Remita communicates with the Central Bank of Nigeria through an encrypted SFTP channel, a secure file transfer protocol used to transmit payment instructions between Remita’s systems and the CBN’s.
This is the channel through which official payment instructions move at the highest level of Nigeria’s financial architecture.
The actor accessed Remita’s source code for this integration. The configuration details, the connection parameters, and the cryptographic material used to authenticate to this channel were present in the repository that ByteToBreach extracted and published.
Whether the actor used this access to inject, modify, or observe any payment instructions in transit is not established by the published artefacts. What is established is that they had access to the infrastructure that makes this channel function.
The PAPSS integration is a second dimension of the same concern. PAPSS — the Pan African Payment and Settlement System — is the African Union’s continental payment infrastructure, designed to enable intra-African trade without routing through correspondent banks outside the continent. Remita is among its Nigerian integration points. Source code for the PAPSS integration was in the repository ByteToBreach obtained.
The implications of this extend beyond Nigeria’s borders. A compromised integration point in PAPSS is a potential threat to the continental payment infrastructure that 54 African nations are building toward.
Why Sterling Bank Made This Possible
The actor’s own statement establishes the causal link that Sterling Bank’s servers were used to conduct the attacks on Remita.
The precise technical mechanism of that pivot is not fully documented in the published artefacts.
Sterling Bank’s compromised infrastructure, its internal network, its service accounts, and its trusted connections provided ByteToBreach with a position inside Nigeria’s financial ecosystem that could not have been obtained by attacking Remita directly from outside.
A threat actor operating from within a trusted Nigerian financial institution has a different attack surface than one approaching from the public internet.
Firewall rules, IP allowlisting, and network trust relationships that would block an external attacker may not block traffic that appears to originate from a trusted peer institution.
This is the systemic lesson that extends beyond both Sterling Bank and Remita individually. Nigerian financial institutions are interconnected.
Payment flows, data sharing agreements, API integrations, and network peering relationships create chains of implicit trust between entities that each have their own security posture. A breach at any point in that chain creates lateral movement opportunities that extend far beyond the original victim.
Sterling Bank’s failure to patch CVE-2025-55182, a publicly known, publicly available fix, on an internet-facing server did not just expose Sterling Bank’s customers. It created a pivot point into Nigeria’s payment infrastructure that no amount of security investment at Remita could have defended against, because the attack did not come from outside Remita’s perimeter. It came from inside Nigeria’s financial network.
The security of Nigeria’s financial infrastructure is only as strong as its weakest connected institution. On March 18, 2026, that institution was Sterling Bank.
Institutional Response
On April 5, 2026, the Nigeria Data Protection Commission broke the institutional silence that had held since March 27.
In a press release signed by Babatunde Bamigboye, Head of Legal, Enforcement and Regulations, the NDPC confirmed it is “carrying out an investigation into an alleged data breach involving Remita Payment Services Ltd., Sterling Bank and other entities.”
The Commission stated that a Notice of Investigation was served on April 1, 2026, five days after the Sterling Bank forum post and the same day the Remita breach was published and that relevant parties have been providing information.
The NDPC’s National Commissioner and CEO, Dr Vincent Olatunji, went further. He directed that organisations “that employ digital payment systems without putting in place appropriate technical and organisational measures as mandated under the Nigeria Data Protection Act, 2023” will also be examined as part of a wider effort to ensure the integrity of the ecosystem.
This is a signal that the investigation extends beyond Sterling Bank and Remita to any institution whose security posture falls short of the NDPA’s requirements.
The NDPC’s response is a necessary step, but it is not sufficient on its own.
Sterling Bank Plc, which received a formal Notice of Investigation from the NDPC on April 1 and whose customers’ data has been in criminal hands since March 27, has still not issued a public statement or notified its customers.
SystemSpecs, the operator of Remita, whose source code, databases, and KYC data are in public download links, has not issued a public statement.
As of the publication of this report, the Central Bank of Nigeria has made no public statement about the compromise of Remita’s CBN payment channel integration or about the HSM keys published for institutions under its regulatory oversight.
As of the publication of this report, NIBSS, the Nigeria Inter-Bank Settlement System, has made no public statement about the published HSM keys bearing the names of member institutions.
As of the publication of this report, NITDA, the National Information Technology Development Agency, which has jurisdiction over critical national information infrastructure, has made no public statement.
As of the publication of this report, the National Security Adviser’s office has made no public statement.
The hundreds of thousands of Nigerians whose identity documents are now in the hands of a criminal do not know their documents are there. Federal government employees whose salary payment infrastructure has been compromised do not know. Every Nigerian who has transacted through Remita, paid a government fee, received a government payment, used a university portal, or processed a tax payment has had the infrastructure underlying that transaction compromised.