The evolution of Nigerian threat actors
The Nigerian threat landscape has shifted. Throughout the early 2010s, activity centered on advance fee fraud and romance scams. Later, threat groups turned to Business Email Compromise (BEC). These early vectors targeted human vulnerabilities. By the mid-2010s, threat groups focused on cellular networks. They ran SIM-swapping operations and targeted USSD codes to take over bank accounts.
Since 2020, threat actors have moved to automated, scripted attacks against fintech APIs. Standardized banking-as-a-service (BaaS) platforms and public open API formats lowered the technical barrier. The financial return is high. An automated script attacking a vulnerable loan disbursement endpoint can process fraud profiles and trigger payouts at ₦150,000 per second. The risk has shifted from social engineering to code-level automation.
The tooling of the modern API attacker
Threat groups do not use custom malware. They use standard developer tools and interception proxies:
- Python requests: Scripts perform high-concurrency HTTP requests. They parse SQLite databases of leaked BVN details and associated credentials obtained from historical data leaks.
- Burp Suite: Attackers run Burp to capture traffic between mobile apps and APIs. They extract authorization headers and API signatures. They also capture payload structures. They then copy these elements into automated scripts.
- Custom Android emulators: Emulators run on customized system images. Attackers use Frida on these devices to hook SSL pinning checks and bypass client-side verification controls.
- Telegram bots: Attacker groups use Telegram channels for command-and-control. Node scripts call Telegram APIs to notify the group when a payout is processed.
- Rotating residential proxies: To bypass IP filters, attackers use proxy networks containing IP ranges from Nigerian telecommunication companies like MTN and Airtel. Because these networks use Carrier-Grade NAT (CGNAT), blocking these IPs blocks hundreds of genuine users.
Attack target 1: Loan application endpoints
Scripted loan fraud executes in a series of steps. First, the script registers accounts using stolen identities and burner SIM cards. Next, the script sends a POST request containing fabricated employment records to the application endpoint.
POST /api/v2/loans/apply
Host: api.targetfintech.com
Authorization: Bearer eyJhbGciOiJIUzI1Ni...
Content-Type: application/json
{
"bvn": "22219485730",
"monthly_income": 950000,
"employer": "Shell Petroleum Development Company",
"job_title": "Lead Drilling Engineer",
"requested_amount": 150000,
"bank_code": "058",
"account_number": "0123456789"
} The risk engine reviews the parameters. If it processes client-supplied values (like salary and employer name) without validating them against third-party sources (like tax databases or bank statement aggregators), it approves the application. The system sends the credit payout to a mule account, where a script immediately transfers the funds to external wallets.
Attack target 2: Referral and rewards endpoints
Referral loops are exploited through automated registration sequences. The attacker registers a seed account to obtain a referral code: REF-99281. A Python script then iterates through hundreds of registration requests. Every request uses a stolen BVN and references REF-99281 as the parent account.
POST /api/v1/auth/register
Host: api.targetfintech.com
Content-Type: application/json
{
"phone": "+2348039827162",
"bvn": "22201938475",
"referral_code": "REF-99281",
"first_name": "Tunde",
"last_name": "Bello"
} If the wallet system credits the referral bonus (such as ₦1,000) immediately upon account registration, the script drains funds rapidly. Within minutes, the attacker collects large sums in the seed account and transfers the cash before operations teams spot the activity.
Attack target 3: Onboarding and account creation floods
Virtual account exhaustion attacks flood onboarding endpoints to disrupt service. Threat actors use script loops to target APIs connected to virtual account providers like Wema Bank or Providus Bank.
The script issues thousands of account creation requests using synthetic identity structures. The backend API automatically requests Wema or Providus to generate a virtual account for each registration. This creates two problems. First, it exhausts the fintech's pre-purchased pool of virtual accounts, preventing genuine users from signing up. Second, it populates the database with active Tier 1 accounts that are subsequently used to channel stolen funds.
The detection fingerprint of API-driven fraud
Security teams can find automated attacks by looking for these patterns in their server logs:
- Time-based spikes: Unusually high account creation volumes between 2 AM and 5 AM.
- Sequential identities: Batches of signups using sequential BVN series from leaked databases.
- Device fingerprint replication: Multiple distinct accounts registering from the exact same hardware ID or MAC address.
- Uniform string patterns: Form inputs (like employment fields) having identical lengths or matching formatting structures.
- Immediate cashouts: Accounts that claim and withdraw referral rewards within seconds of database insertion.
The fix
Securing these endpoints requires logic adjustments and backend validation:
- Challenge-response at registration: Require a client-side JavaScript challenge or CAPTCHA during signup to verify that the client is a real browser or mobile client, not a headless script.
- Exponential backoff: Implement rate limiting based on IP blocks and device identifiers. When thresholds are breached, return HTTP 429 and block requests for increasing intervals. Read our article on rate limiting anti-fraud payment APIs for implementation details.
- Server-side BVN deduplication: Block duplicate identity mappings. Query the database to confirm the BVN is not linked to any other active profile:
const existingUser = await db.user.findFirst({ where: { bvn: payload.bvn } }); if (existingUser) { throw new BadRequestError('Identity number already registered'); } - Milestone-based referrals: Do not credit bonuses immediately. Delay payouts until the referred user completes a minimum transaction volume:
async function processReferral(referredUserId: string, referrerId: string) { const transactionCount = await db.transaction.count({ where: { userId: referredUserId, amount: { gte: 2500 }, status: 'SUCCESS' } }); if (transactionCount === 0) { throw new Error('Milestone requirement not met'); } await db.$transaction([ db.wallet.update({ where: { userId: referrerId }, data: { balance: { increment: 1000 } } }), db.referral.update({ where: { referredUserId }, data: { status: 'COMPLETED' } }) ]); } - Identity validation: Query identity verifiers like Dojah or Smile Identity directly to confirm the phone number linked to the BVN matches the phone number used for signup. Check our guide on BVN spoofing and liveness bypass.
- Volume alerts: Configure monitoring systems to flag anomalies, such as more than three loan requests within a minute from a single IP block.
Format checking only during BVN verification
During a security assessment of a lending platform, we ran a synthetic load test with random BVN strings against their loan application endpoint. 34% of our randomly generated BVNs passed their KYC check because their BVN validation was only checking format (11 digits), not querying NIBSS for existence. Fix priority: critical.
Are your core onboarding and loan endpoints vulnerable to scripted attacks?
Get a security reviewAutomated scanners cannot simulate multi-step fraud flows. Detecting these API-driven fraud patterns requires manual reviews to inspect rate limiting logic and verify KYC validation depth.
Frequently asked questions
Are Nigerian threat actors using AI tools for these attacks?
Increasingly yes. LLM tools are used to generate realistic employment histories.
Can we block Nigerian residential IPs to stop these attacks?
No. Blocking CGNAT ranges from MTN/Airtel would block a large portion of your legitimate user base.
How do we respond when we detect an active scripted attack in progress?
Enable stricter rate limiting. You must also require CAPTCHA validation. Any accounts created during the attack window must be quarantined.
Related reading
Blog: Rate Limiting and Anti-Fraud Payment APIs · BVN Spoofing and Liveness Bypass
Services: API security testing · Lending platform security