ByteToBreach did not use sophisticated zero-day exploits. They used sequential user IDs. Plaintext credentials in a Git repository. An unauthenticated file download endpoint on a public subdomain. Open doors.
Around the same time, KasTech Network Limited was completing a forensic investigation and full security audit of a Nigerian fintech platform that had experienced unexplained financial losses. What we found was deeply familiar.
What was Found
The platform had committed a live Firebase private key directly to its Git repository. The full RSA private key, project ID, and client credentials were in version control, accessible to every developer who had ever cloned the repository, past or present.
Nine sets of production credentials were hardcoded in source code: payment provider API keys, KYC service keys, SMS gateway credentials, encryption passwords, and bank integration secrets. Not in environment variables. In the actual PHP files, committed to the repository.
Webhook endpoints handling real money movement had no cryptographic signature verification. Any person who knew the URL could POST arbitrary data and trigger wallet credits. One endpoint took the user ID and credit amount directly from the incoming request body with no authentication of any kind. You could credit any user’s wallet with any amount by sending a single HTTP request.
Transaction limits existed in the database but the enforcement code was commented out in production. Fraud alerts were being generated but routing to nobody due to a database role name mismatch. Suspended accounts could still make transactions because the middleware only checked for the string “inactive.”
A race condition in the FX swap execution path allowed concurrent requests to each pass a balance check before any of them had debited the wallet – the classic TOCTOU vulnerability that allowed money to be created from nothing.
And 412 financial transaction records had been permanently deleted from the production database, with the most suspicious deletions concentrated around the period when the FX exploit occurred.
The Pattern
ByteToBreach described their methodology as opportunistic. They find an open door, document what is inside, and publish. The doors they found were not obscure. An unpatched CVE on a pilot server. A Git repository with production credentials. A JWT endpoint using sequential integers.
These are not the failures of underfunded startups operating in ignorance. Sterling Bank is one of Nigeria’s established commercial banks. Remita processes payments for the Federal Government. The CAC is the legal foundation of corporate identity in Nigeria. These institutions have compliance frameworks, IT departments, and regulatory obligations.
The gap ByteToBreach exploited is the gap between paperwork compliance and actual technical reality. An institution can pass a compliance audit and still have a publicly accessible Git repository with plaintext database passwords. An institution can have a security policy document and still be running a pilot server with an unpatched maximum-severity CVE exposed to the internet.
The same gap exists in the fintech platform we audited. The platform had passed onboarding checks with its payment provider. It had completed KYC processes. It was operating legally. And it had nine sets of live production credentials sitting in source code that anyone with repository access could read.
The Specific Risks for Nigerian Fintech
Nigerian fintech platforms face a specific set of pressures that create security debt quickly. The race to go live. The pressure to integrate multiple payment providers simultaneously. Small development teams working across complex stacks. The temptation to hardcode credentials “temporarily” and never remove them.
Webhook security is particularly weak across the industry. Every payment provider integration introduces a webhook endpoint: a publicly accessible URL that receives notifications about transactions. If that endpoint does not cryptographically verify that the request came from the provider, it is an open door. We found this pattern across multiple webhook handlers on the same platform: Maplerad, Fincra, WEMA Bank, and Korapay integrations all had varying degrees of signature verification failure.
Git repository hygiene is equally weak. The development pattern of hardcoding credentials for speed, intending to move them to environment variables later, and then forgetting (or committing .env files directly) is widespread. Unlike a misconfigured endpoint, a committed credential in a Git repository cannot be fixed by a code change alone. The credential exists permanently in the commit history. Every developer who has ever cloned the repository has it. The only remediation is to revoke the credential with the provider and purge the git history using BFG Repo Cleaner or git filter-repo.
What ByteToBreach Said About Responsibility
When asked about the human consequences of the data now circulating, ByteToBreach replied: “Protecting Nigerians is not my responsibility. That’s the duty of the government.”
This is technically true and completely beside the point. The responsibility for building secure systems lies with the organisations that build them. The government’s role is regulation and enforcement. But the moment a developer commits a production API key to a Git repository, or an institution leaves a pilot server unpatched for months, or a webhook endpoint processes any incoming request without verification: they have created an open door. The question of who walks through it is secondary.
The fintech platform we audited did not intend to be insecure. The developers who hardcoded credentials were moving fast under pressure. The developer who commented out the withdrawal limit enforcement probably had a reason at the time. The fraud alert system that was routing to nobody had been that way long enough that no one had noticed. These are failures of process and culture, not of malice.
But the outcome is the same as if they had been malicious. Money left the platform. Records were deleted. Credentials were exposed. An insider exploited a race condition. And the fraud detection system that should have flagged it all was silently firing into the void.
What Should Happen Now
For platforms already in production:
Audit your Git history for secrets. Run truffleHog or git-secrets across your entire commit history. Do not assume your current codebase is clean – look at the history. If you find credentials, revoke them with the provider immediately, then purge the history.
Test every webhook endpoint. Send a POST request with no signature header and with an invalid signature. If the endpoint processes it or returns anything other than 401, it is vulnerable.
Enable database audit logging. Every UPDATE and DELETE on financial tables should be logged with timestamp, user, and old and new values. The ability to permanently delete transaction records without a trace is a forensic nightmare and a compliance failure.
Check your middleware. List every middleware applied to every money-movement route. Confirm that authentication, PIN verification, and rate limiting are applied consistently. Gaps between v1 and v2 API routes are common.
Run a wallet balance reconciliation. Compare every stored wallet balance against its transaction history. Discrepancies indicate either a software bug or evidence of manipulation. On a platform we recently audited, 100 out of 1,591 wallets showed mismatches on the first run of a reconciliation command.
For organisations that have not yet experienced an incident, the ByteToBreach campaign and the incidents we documented during our forensic work should be a clear signal. The threat actors targeting Nigerian infrastructure are not sophisticated. They are patient, methodical, and looking for open doors. The question is not whether those doors exist in your platform. The question is whether you find them before someone else does.
