Why Nigerian startups are prime targets
Nigeria's fintech sector processes billions of Naira daily across mobile money, lending, payments, and digital banking. NIBSS recorded 586,130 attacks on financial institutions in just the first half of 2024, with confirmed fraud losses reaching ₦53.4 billion across the sector. Check Point Research documented 4,718 attacks per week targeting finance-sector organizations - a 153% increase from 2020 to 2024.
The attackers targeting Nigerian fintechs are not lone hackers in basements. They are organized groups with sophisticated tools, patient reconnaissance, and deep understanding of payment system architectures. Here are seven documented patterns from real incidents, each one a blueprint that other attackers can - and will - replicate.
Attack 1: unpatched server leading to mass data exfiltration - Sterling Bank/Remita
What happened: In early 2024, threat actors exploited an unpatched vulnerability in Sterling Bank's infrastructure connected to the Remita payment platform. The attackers gained initial access through the vulnerability, established persistence, and exfiltrated approximately 3 terabytes of data over a nine-day period before detection.
The attack vector: Unpatched server software with a known vulnerability. The patch was available but had not been applied. Initial access led to lateral movement through the network, eventually reaching systems containing customer records.
The damage: Approximately 900,000 customer records were compromised, including personal information, financial data, and transaction histories. The 3TB data exfiltration represents a massive data breach by any standard. Beyond the direct data exposure, the reputational damage to both Sterling Bank and SystemSpecs (Remita's parent company) was significant.
What would have prevented it:
- Patch management: A systematic process for identifying and applying security patches within defined SLAs - critical patches within 48 hours, high within one week.
- Network segmentation: Isolating sensitive data stores from internet-facing servers would have limited lateral movement after initial access.
- Data loss prevention (DLP): Monitoring for unusual outbound data transfers - 3TB of data leaving the network over nine days should trigger alerts.
- Intrusion detection: Active monitoring for the specific indicators of compromise associated with the exploited vulnerability.
For a deeper analysis, see our article on lessons from the Sterling Bank/Remita breach.
Attack 2: insider access combined with API key compromise - Patricia
What happened: Patricia, a Nigerian cryptocurrency exchange platform, suffered a security breach in 2023 where customer funds were stolen. The attack involved a combination of insider access and compromised API keys, enabling unauthorized transactions from customer wallets.
The attack vector: The incident combined insider knowledge of system architecture with compromised API credentials. The attackers understood the internal workflow well enough to execute transactions that bypassed normal validation controls. Patricia CEO Hanu Fejiro Agbodje later confirmed the incident involved "ichie" (insider) elements.
The damage: Customer funds were directly stolen from the platform. The exact amount was disputed, but users reported inability to withdraw funds for extended periods. Patricia's credibility as an exchange was severely damaged, and the platform's operations were significantly disrupted. The SEC Nigeria subsequently increased scrutiny of cryptocurrency platforms.
What would have prevented it:
- Segregation of duties: No single individual should have sufficient access to both initiate and approve transactions. Multi-signature requirements for fund movements above defined thresholds.
- API key management: Keys scoped to minimum required permissions, rotated regularly, and monitored for anomalous usage patterns. See our guide on API key storage and management.
- Transaction monitoring: Real-time alerts for unusual transaction patterns, volume spikes, or transfers to new destination addresses.
- Background checks and access reviews: Periodic review of who has access to what, with immediate revocation when access is no longer justified.
Attack 3: workflow vulnerabilities and weak access segregation - Flutterwave
What happened: Flutterwave experienced unauthorized transaction activity in 2023 (approximately ₦2.9 billion) and again in 2024 (approximately ₦11 billion). The incidents involved exploitation of workflow vulnerabilities and weaknesses in access segregation that allowed unauthorized fund movements through the platform.
The attack vector: The attackers exploited weaknesses in the transaction processing workflow - the sequence of validation steps between transaction initiation and settlement. Gaps in access segregation meant that controls designed to prevent unauthorized transactions could be circumvented. This is a business logic flaw - the kind of vulnerability that automated scanners cannot detect.
The damage: ₦2.9 billion in unauthorized transactions in 2023. Approximately ₦11 billion in 2024. These are among the largest documented fraud losses in Nigerian fintech history. The incidents prompted regulatory scrutiny and raised questions about the adequacy of internal controls at scale.
What would have prevented it:
- Business logic penetration testing: Manual testing of transaction workflows specifically targeting race conditions, sequence bypasses, and authorization gaps between processing steps.
- Multi-layer authorization: Independent validation at each step of the transaction workflow, with each layer using different credentials and approval mechanisms.
- Real-time transaction monitoring: Pattern detection for unusual transaction volumes, velocities, or destination patterns - with automated circuit breakers that halt processing when anomalies are detected.
- Access control audits: Regular review of who can initiate, approve, and settle transactions, with strict enforcement of separation between these roles.
Is your platform vulnerable to the same attack patterns?
Request a Security AssessmentAttack 4: system glitch exploitation for chargeback fraud - Interswitch
What happened: Interswitch, one of Nigeria's largest payment infrastructure providers, experienced a system glitch that was exploited for approximately ₦30 billion in fraudulent chargebacks. The glitch created a window where chargeback requests could be processed without proper validation, and organized groups exploited this window systematically.
The attack vector: A technical glitch in the chargeback processing system - the mechanism that reverses completed transactions when a customer disputes a charge. Under normal conditions, chargebacks require verification and approval. The glitch bypassed these checks, allowing fraudulent chargeback requests to be processed automatically.
The damage: Approximately ₦30 billion in fraudulent chargebacks - one of the largest single-incident fraud losses in Nigerian financial services. The incident exposed systemic weaknesses in transaction reversal controls and chargeback validation processes.
What would have prevented it:
- Reversal flow testing: Penetration testing specifically targeting payment reversal, chargeback, and refund workflows - these are consistently among the weakest points in payment platforms.
- Circuit breakers: Automated limits on chargeback volumes and values. When chargeback activity exceeds normal baselines by a defined threshold, processing halts and requires manual review.
- Reconciliation monitoring: Real-time comparison of chargebacks against original transactions to detect anomalous patterns before settlement.
- Chaos engineering: Deliberately testing how the system behaves under failure conditions, including what happens when validation services are unavailable or degraded.
Attack 5: third-party vendor compromise - MTN Nigeria
What happened: MTN Nigeria experienced a data incident where subscriber data was exposed through a compromise at a third-party vendor. The vendor had access to subscriber information as part of a service integration, and a security failure at the vendor level exposed that data.
The attack vector: Third-party supply chain compromise. The attacker did not breach MTN directly - they compromised a vendor that MTN shared data with. The vendor's security controls were weaker than MTN's, making them an easier target for accessing the same data.
The damage: Subscriber data exposure including phone numbers and associated account information. The exact scope was not fully disclosed, but MTN Nigeria has over 76 million subscribers. Even a partial exposure represents a significant data breach under NDPA regulations.
What would have prevented it:
- Vendor security assessment: Security evaluation of third-party vendors before granting data access, including review of their security controls, testing practices, and incident response capabilities.
- Data minimization: Sharing only the minimum data required for the vendor to perform their function. If the vendor does not need phone numbers to provide their service, they should not receive them.
- API-based data access: Instead of bulk data transfers, providing vendors with API access that enforces rate limiting, logging, and real-time access controls. See our guide on securing fintech APIs.
- Contractual security requirements: Including specific security testing requirements, breach notification obligations, and audit rights in vendor contracts.
For mobile-specific vendor risks, see our article on third-party SDK security in mobile fintechs.
Attack 6: race condition in loan disbursement API - anonymized Simpa Labs engagement
What happened: During a penetration test for a Nigerian lending platform, Simpa Labs discovered a race condition in the loan disbursement API that allowed an attacker to receive duplicate loan payouts from a single approved application.
The attack vector: The loan disbursement endpoint processed payout requests asynchronously. When multiple identical requests were sent simultaneously (within the same millisecond window), each request passed the "loan not yet disbursed" check independently before any of them updated the disbursement status. The result: a single approved loan of ₦500,000 could generate two, three, or more separate disbursements of ₦500,000 each to the borrower's bank account.
How we found it: During business logic testing of the loan lifecycle, we sent 10 concurrent POST requests to the disbursement endpoint for a single approved loan. Three of the ten requests were processed successfully, resulting in three separate payouts of the loan amount. The total disbursed was ₦1.5 million against a ₦500,000 approved loan.
Potential damage: At the platform's loan volume of approximately 200 disbursements per day, a systematic exploitation could generate millions of Naira in excess disbursements daily. The fraud would not be immediately visible in the platform's UI - each individual disbursement appeared legitimate, and the duplicate detection required cross-referencing the payment processor's records against the lending platform's loan records.
What would have prevented it:
- Idempotency keys: Requiring a unique idempotency key for each disbursement request, with the database enforcing uniqueness - duplicate requests with the same key are rejected.
- Database-level locking: Using pessimistic locking (SELECT FOR UPDATE) on the loan record during disbursement processing, ensuring only one transaction can modify the disbursement status at a time.
- Post-disbursement reconciliation: Automated comparison of total disbursed amounts against approved loan amounts, with alerts for any discrepancy.
Attack 7: missing webhook validation enabling fake payment confirmations - anonymized Simpa Labs engagement
What happened: During a penetration test for a Nigerian payment processor, Simpa Labs discovered that the webhook endpoint used to receive payment confirmations from upstream providers did not validate the authenticity of incoming webhook requests.
The attack vector: The platform received payment confirmations via HTTP POST requests to a webhook endpoint. The endpoint processed any incoming request that matched the expected JSON structure - it did not verify the webhook signature, check the source IP, or validate the request against the payment provider's signing key. An attacker could send a fabricated webhook request confirming a payment that never occurred.
How we found it: We crafted a webhook payload matching the expected format, sent it directly to the endpoint from our testing infrastructure (not from the payment provider's IP range), and observed the platform mark the corresponding transaction as "paid." The customer received a "payment successful" notification despite no money actually changing hands. See our detailed analysis in webhook security for payment platforms.
Potential damage: An attacker could confirm any pending payment on the platform without actually paying. For an e-commerce integration processing 5,000 transactions daily with an average value of ₦15,000, this vulnerability could enable ₦75 million in daily fraud - goods and services delivered against fabricated payment confirmations.
What would have prevented it:
- Webhook signature verification: Validating the HMAC signature on every incoming webhook request using the signing key provided by the payment processor. Reject any request with an invalid or missing signature.
- IP whitelisting: Restricting webhook endpoint access to the known IP addresses of the payment provider, as documented in their API specifications.
- Server-side payment verification: After receiving a webhook, making a server-to-server API call to the payment provider to independently confirm the transaction status before updating the local database.
- Replay protection: Tracking webhook event IDs and rejecting duplicate deliveries.
The same weaknesses repeat across every incident
Look at what connects these seven attacks: unpatched infrastructure, weak access controls, missing validation on critical workflows, absent monitoring, and untested business logic. These are not exotic zero-day exploits. They are basic security controls that were either not implemented or not tested. A single penetration test would have identified the vulnerability exploited in every case listed above.
What this means for your startup
If you are a Nigerian fintech founder reading this, the question is not whether these attack patterns apply to you. It is which ones apply. Chances are, at least two or three of the vulnerability categories described above exist in your system right now. Not because your engineers are incompetent - because security testing was not prioritised during the build phase, and no one has specifically looked for these issues.
Every attack above was preventable with controls that are well-understood and implementable. The gap is not knowledge - it is testing. You do not know which of these vulnerabilities exist in your system until someone specifically looks for them. That is what a penetration test does.
See how a Simpa Labs pentest works for the full engagement process, or read our guide on defending your Nigerian business against cyber threats for a broader defensive strategy.
Find out which of these attack patterns your startup is vulnerable to.
Get Your AssessmentRelated reading
Blog: Sterling Bank/Remita breach lessons · How hackers steal money from Nigerian fintechs · Business logic flaws in payment platforms · Cost of a data breach in 2026
Guides: Fintech breach risk in Nigeria · What to do after a breach · Fintech security checklist
Services: Penetration testing · API security testing · Payment gateway security
Frequently asked questions
What is the most common way Nigerian startups get hacked?
Based on documented incidents and our engagement data, the most common attack vectors are API vulnerabilities (particularly broken object-level authorization and business logic flaws), followed by compromised credentials (weak access controls and insider threats), and unpatched or misconfigured infrastructure. Phishing remains the most common initial access vector at 42% of attacks on Nigerian financial institutions.
Are small startups really targeted by hackers?
Yes. Attackers increasingly use automated scanning tools that identify vulnerable systems regardless of company size. A startup with an exposed MongoDB database or a publicly readable S3 bucket will be discovered by automated scanners within hours of deployment. Small startups are often easier targets because they lack dedicated security teams and have less mature security controls than larger organizations.
How long does it take to detect a breach in Nigeria?
The average dwell time - the period between initial compromise and detection - varies widely. The Sterling Bank/Remita breach persisted for nine days before detection. Many smaller breaches go undetected for months because the affected organizations lack adequate logging and monitoring. NIBSS data suggests that many fraud incidents are only detected when customers report unauthorized transactions.
What should I do if I think my startup has been hacked?
Isolate affected systems immediately to prevent further data exfiltration. Preserve all logs and evidence - do not restart servers or clear logs. Engage a digital forensics team to determine the scope and method of the breach. Notify your legal team and prepare for regulatory disclosure under the NDPA, which requires breach notification to the NDPC. Document everything for both regulatory compliance and insurance claims.