The CERT-In Crafty Falcon advisory is a Critical warning for anyone who runs payout or disbursement APIs in India. On 4 Nov 2026 CERT-In and CSIRT-Fin published CIAD-2026-0058, last updated 5 Nov 2026.
Short answer: CERT-In’s Crafty Falcon advisory (CIAD-2026-0058, 4 Nov 2026) warns that an AI-assisted attacker is breaking into Indian NBFCs, fintechs, payment aggregators and crypto exchanges, then calling their own payment and disbursement APIs to move money. CERT-In calls the threat “active and ongoing” and lists controls to put in place now.
Based on the public CERT-In and I4C advisories, checked 5 Nov 2026.
What CERT-In found
Crafty Falcon, as CSIRT-Fin describes it, “surveys its targets with machine intelligence, operates at machine speed and strikes by invoking the victim’s own payment and disbursement APIs.”
Attackers get in through unprotected test or staging systems, then move into live systems using shared credentials. They reverse-engineer or alter apps so those copies call the APIs directly. They slip past IP allow-lists through shared third-party fetcher services. They send Rs 1 test payments to a new beneficiary, then large transfers. They misuse payment aggregator settlement APIs, and they move quickly on newly disclosed PHP and Node.js flaws. Many scripts look AI-written, and attacks are timed for holidays and weekends. Firms that had cleaned up were “deliberately re-targeted.”
The AI part, without the hype
CERT-In says the attacker uses “publicly available AI-driven offensive security tools,” and names ARTEX, PentAGI, Cairn and CyberStrikeAI. That is the full list; we are not describing each one.
These tools run whole attack chains “at machine speed,” so controls that wait for a person to notice are too slow. You need checks that hold money by default.
Who it applies to, and the separate I4C advisory
The Crafty Falcon advisory names NBFCs, digital lending platforms, fintechs, payment aggregators, payment service providers, and crypto exchanges and VDA providers. If you have a payout or disbursement API, read it as written for you.
A day earlier, on 3 Nov 2026, I4C’s NCTAU and CERT-In issued a separate advisory, TAU/ADV/020, about the same kind of attack. It does not use the Crafty Falcon name. It adds banks, repeats the 6-hour reporting reminders, notes “multi-crore unauthorized transaction” losses in individual cases, and describes mule accounts fed over IMPS and NEFT. Crafty Falcon is CERT-In’s; the 3 Nov note is the joint I4C item.
What the advisory asks you to fix
Fix these first (Bluelupin’s suggestion): three controls, because they stop money leaving even when an attacker gets in. Check every transaction on the server (do not trust your own app). Flag a Rs 1 test payment to a new beneficiary followed by a large one, and hold that flow. Require maker-checker approval for every fund movement. The One-Sheet above carries the full mapped checklist.
Lock down who and what can call your payment APIs
Payment API security starts with treating your own client apps as untrusted. Sign every API request with a one-time value and a timestamp, and use app attestation and certificate pinning so a tampered copy is detected (CIAD-2026-0058). Replace IP allow-lists for shared third-party services with identity checks such as mutual TLS or scoped API keys. Inventory payment APIs and switch off old or test ones (CIAD-2026-0046). Put multi-factor authentication on payment platforms and admin portals, use short-lived scoped tokens, and keep keys out of code (agent tool access without the keys).
Watch the money as closely as the servers
Flag tiny test payments to new beneficiaries followed by large ones. Set per-transaction and daily ceilings, a cooling period for new beneficiaries, and velocity rules. Check beneficiaries with penny-drop and name-to-account matching. Require maker-checker approval for every fund movement (approval gates for AI agents that touch money), and reconcile with bank and aggregator statements so unmatched payouts are rejected.
Close the doors attackers used to get in
Separate test, staging and live systems, with no shared credentials or network paths. Patch internet-facing apps quickly, especially PHP and Node.js flaws. Watch cloud audit logs in real time, and restrict who can use cloud management services (such as AWS Systems Manager and Lambda). Block open outbound traffic from servers (cloud app security practices). Staff monitoring 24×7 on holidays and weekends. After an incident, assume the attacker is still inside. Keep logs for at least 180 days, and govern your own AI tools (AI agent sandboxing).
Reporting: who to tell, and how fast
Under the CERT-In Directions of 28 Apr 2022, covered entities must report cyber incidents to CERT-In within 6 hours of noticing them, and keep logs for a rolling 180 days. NBFCs also report on RBI’s DAKSH within six hours of detection (RBI NBFC Cybersecurity Directions, 31 Jul 2026); check which chapter applies. Report fraudulent transactions in bulk to I4C on the CFCFRMS portal. Suspicious activity goes to incident@cert-in.org.in. Breaches can also raise DPDP duties, and retained logs help with proof packs for auditors and boards. This is a plain summary of the public rules, not legal advice. Check with your counsel which rules apply.
What to do next
If you run payment or disbursement APIs, we can run a payment API security review against this advisory. Book a consultation, or write to sales@bluelupin.com.