India’s national cyber agency, CERT-In, and its finance unit CSIRT-Fin warn of several active
campaigns against non-banking lenders, fintechs, payment service providers, and wallet operators.
Attackers break into internet-facing systems, steal the API credentials these firms use to move money,
and then call the fund-transfer interfaces directly from the firm’s own trusted servers. Doing so skips the
usual checks on identity, beneficiary, balance, and transaction limits, so money goes straight to mule
accounts across many banks. The fix is to lock down exposed systems and credentials and to add
independent checks on every payout.
1. What CERT-In Observed
CERT-In and CSIRT-Fin report multiple campaigns against non-banking financial companies (NBFCs), digital lenders,
fintechs, payment service providers, and wallet operators. Attackers compromise internet-facing applications and
exposed APIs, steal payment aggregator, gateway, and partner-bank API credentials, then call disbursal and fund
transfer APIs directly from the entity’s own whitelisted infrastructure. This skips every application-level control: loan
creation, Know Your Customer (KYC), sanctions screening, beneficiary verification, balance checks, and per-transaction
limits. Fraudulent transfers carry dummy reference identifiers, breach limits, and move funds over IMPS and NEFT rails
to mule accounts across many banks, with immediate withdrawal.
2. How The Attack Unfolds
Initial access comes through exposed applications and middleware flaws, deprecated or unauthenticated APIs with
unrestricted file upload, stolen long-lived static tokens hard-coded in source, forged-commit compromise of code
repositories, plaintext credentials in config or databases, and services without multi-factor authentication. After entry,
attackers plant web shells and backdoors, map payment databases and API integrations, steal the money-movement
credentials, and run the fraud. They delete or truncate logs and tamper with endpoint protection to hide the activity.
CERT-In notes the likely use of AI-assisted offensive tooling, and the time from first compromise to fraud is getting
shorter.
- Exposed apps and middleware: Internet-facing applications and application-server middleware left unpatched or misconfigured.
- Forgotten and open APIs: Deprecated, unauthenticated, or unused APIs, some with unrestricted file-upload functionality.
- Hard-coded static tokens: Long-lived API tokens embedded in source code and reused by attackers.
- Repository compromise: Supply-chain compromise of source-code repositories through forged commits.
- Plaintext credentials: Credentials stored in clear text in configuration files, source code, or databases.
- Missing MFA: Applications and remote services reachable without multi-factor authentication.
3. Recommendations
- Enforce MFA on payment platforms, admin portals, payment and bank APIs, and remote access; store all keys and credentials in a secrets manager or HSM and rotate them on a schedule.
- Keep a complete API inventory and formally decommission deprecated or unused APIs; enforce per-session authentication on every API and remove long-lived static tokens.
- Require maker-checker or second-level approval for all fund movement, validate every payout againstapproved records, reject reference IDs with no matching record, and enforce per-transaction and per-day limits at the API layer.
- Apply beneficiary validation (penny-drop, name-to-account matching) and velocity limits on all disbursement paths, and bind multi-stage transaction flows so a debit step cannot run without its preceding validation steps.
- Monitor fund transfers in real time for velocity, amount bands, and new beneficiaries with automatic holds, run near-real-time reconciliation against bank and aggregator statements, and allow-list outbound traffic from production servers.
- Centralise logging with at least 180 days retention, deploy tamper-protected EDR, isolate development, testing, and production, and on suspicious activity disable compromised accounts, suspend affected APIs, preserve evidence, rotate all credentials, and report to CERT-In/CSIRT-Fin at incident@cert-in.org.in.
4. Sources
https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0046
Enjoyed reading this Threat Intelligence Advisory? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn
No related posts found.