CERT-In's 'Crafty Falcon' Advisory: AI-Assisted Attacks on Payment and Disbursement APIs, and What NBFCs and Fintechs Must Do Now
CERT-In's Crafty Falcon advisory describes an ongoing campaign in which AI-assisted attackers enter through exposed test environments and use financial firms' own payment APIs to move money out. What the advisory says, how the attack chain works, what CERT-In recommends, and a checklist for the next two weeks.
Threat Intelligence
On 4 November 2026, CERT-In's financial sector response team published a critical advisory about a threat actor it has named "Crafty Falcon": an attacker that uses AI tooling to find its way into lenders, payment companies and crypto exchanges, and then moves money out by calling the victims' own payment and disbursement APIs. The advisory updates a warning from 9 October and says the campaign is continuing, including against firms that had already been warned and had fixed what they thought was the problem. Here is what the advisory says, how the attack chain works, what CERT-In recommends, and what to do in the next two weeks.
In short. The attackers are not breaking the payment API. They get in through internet-exposed test and staging environments, reuse the credentials and network paths those environments share with production, and then call the disbursement API from inside the firm's own trusted infrastructure, where the application's checks no longer apply. They test the route with tiny transfers, strike at weekends and holidays, and come back after incomplete clean-ups. The fixes are specific: isolate non-production completely, remove shared credentials, validate and sign every transaction server-side, replace IP allow-listing of shared vendor pools with identity-based controls, add velocity and new-beneficiary rules, and hunt rather than only patch.
What CERT-In published, and what it did not
The advisory is CIAD-2026-0058, titled Escalation of AI-Driven Attacks on BFSI Entities by Threat Actor "CRAFTY FALCON", rated Critical, issued on 4 November 2026 by CSIRT-Fin, the Computer Security Incident Response Team for the financial sector that operates under CERT-In. It is explicitly "an update to CERT-In Advisory CIAD-2026-0046 dated 09 October 2026", which was titled Threat Actors Exploiting Payment and Disbursement APIs for Unauthorized Fund Transfers in BFSI Entities.
CSIRT-Fin describes Crafty Falcon as "an AI-assisted financial threat actor that surveys its targets with machine intelligence, operates at machine speed and strikes by invoking the victim's own payment and disbursement APIs." The entities it names are "non-banking financial companies (NBFCs), digital lending platforms, fintech entities, payment aggregators, payment service providers and cryptocurrency exchanges / virtual digital asset service providers."
Two things are worth being clear about. First, the public page is a summary. CERT-In states that "the detailed (restricted) version of this advisory, including the full indicators of compromise", infrastructure fingerprints and detection rules, has been shared with BFSI entities at the appropriate traffic light protocol level. If you are a regulated financial entity and have not received it, ask. Second, the advisory does not attribute the actor to any country, and neither CERT-In nor RBI has published a count of incidents or a loss figure. Press reports citing unnamed sources have put losses in the hundreds of crores of rupees; treat those as unconfirmed.
The most uncomfortable sentence in the advisory is this one: CSIRT-Fin "continues to receive reports of successful attacks, including from NBFCs and fintech entities that had already received the earlier restricted (TLP:AMBER) advisories and had undertaken remediation. The same entities have been deliberately re-targeted, including after incomplete remediation." Patching the hole you found is not the same as evicting the attacker.
The attack chain, step by step
Put the two advisories together and a consistent sequence emerges. None of it requires a new vulnerability class; what is new is the speed and scale that AI tooling gives to each step.
1. Survey
AI-driven tooling maps the target's internet-facing applications, exposed APIs and privileged endpoints. The October advisory describes attackers who "compromise internet-facing applications, exposed APIs and privileged endpoints"; the November one adds mass generation of "functionally identical variants" of attack scripts, so that blocking one does not block the next.
2. Enter through non-production
The advisory names "internet-exposed non-production environments (UAT/staging/testing) used as entry points". Test environments get less monitoring, older patches, weaker authentication and, often, real data. Other documented routes include file-upload and deserialisation flaws leading to web shells on PHP and Node.js applications, and modified copies of the firm's own mobile app packages making API calls.
3. Move to production
From there, "movement to production environments using shared credentials, tokens or network paths". A UAT server that holds a production API key, a token reused across environments, or a network route that was never closed is all it takes.
4. Call the API from inside
Attackers "invoke disbursal/fund-transfer APIs directly from within the entities' own whitelisted infrastructure", which, in the advisory's words, means "completely bypassing application-level controls such as loan creation, KYC, sanction, beneficiary verification, balance sufficiency and per-transaction limits." The controls live in the application; the attacker is talking to the API underneath it. Where firms rely on IP allow-lists for vendor integrations, the advisory describes bypassing them through the shared IP pools of third-party fetcher services.
5. Test, then strike
"Micro-value test transactions (such as Rs. 1) performed to validate unauthorized fund flows", then high-value transfers to "attacker-controlled mule accounts across multiple banks". Attacks "have been timed to coincide with holidays, weekends and other low-monitoring windows", including "continuous non-business-hours operation against a single target". Merchant settlement APIs and crypto wallet keys are also named as targets.
6. Return
If the response removed the web shell but not the credentials, or closed one path but not the shared network route, the attacker comes back, which is what the re-targeting sentence describes.
The tools, and why they matter
CERT-In identifies "the 'ARTEX' family of LLM-based" tooling, the "'PentAGI' autonomous multi-agent AI penetration testing system", the "'Cairn' attack search engine" and the "'CyberStrikeAI' framework". All are publicly available offensive-security projects: PentAGI and CyberStrikeAI are open source on GitHub with tens of thousands of stars between them; ARTEX was published as open source in mid-2026 and later withdrawn by its developer, though forks remain. Press reports in early November described a backdoored ARTEX Docker image on a public registry that gave an unauthenticated root shell on every installation, which, if accurate, means some operators of the attack tooling were themselves compromised.
The point is not the names. These are the same kinds of tools legitimate testers use, and the same kinds we wrote about when building our own AI-assisted testing agent. What they change is economics: reconnaissance that took a skilled person days now runs unattended overnight against hundreds of targets, and a script that is blocked is regenerated in a different form within minutes. CERT-In's advisory of 15 October, CIAD-2026-0049, had already warned that actors "abused publicly available AI-native offensive-security frameworks" against Indian systems and told BFSI entities to implement the payment API measures from the October advisory. For the defensive side of the same technology, see our guide to securing AI agents.
What CERT-In recommends
The public recommendations are specific, and they map almost one to one onto the attack chain. The table lists them in the order we most often find them missing.
| Recommendation (CERT-In wording) | What it breaks in the chain | What it means in practice |
|---|---|---|
| "Isolate UAT/staging/testing environments from production - no shared credentials, tokens, API keys" | Steps 2 and 3 | Separate accounts or subscriptions, separate secrets, no network route from test to production, no production data in test |
| "Treat client applications and packages as untrusted: enforce server-side validation of every transaction and business rule; implement API request signing with nonce and timestamp; adopt app attestation services and certificate pinning" | Step 4 | KYC, sanction, beneficiary and limit checks enforced by the server on every call, not by the app that calls it; signed requests that cannot be replayed |
| "Replace IP allow-listing of shared third-party fetcher pools with identity-based controls such as mutual TLS, cryptographically signed requests or scoped API keys on dedicated vendor endpoints" | Step 4 | An IP address shared by a thousand customers of a fetcher service is not an identity |
| "Prohibit hardcoded tokens and credentials in source and build code" | Step 3 | Secret scanning in repositories and pipelines; rotate anything found |
| "Implement transaction velocity rules, new-beneficiary cooling periods and amount-band anomaly detection across all payment and disbursement paths"; "flag micro-value test transactions to new beneficiaries followed by high-value transactions"; maker-checker for fund movement | Step 5 | The ₹1 test is the tell; a rule that catches it stops the transfer that follows |
| 24x7 monitoring with "lowered alert thresholds during holidays, weekends and other low-coverage windows" | Step 5 | If your SOC is thinner at the weekend, your thresholds should be tighter |
| "perform full eradication with forensic verification and continue periodic threat hunting" | Step 6 | Removing the artefact you found is not eradication; prove the attacker is gone, then keep looking |
| Enforce MFA for payment platforms, administrative portals and payment and bank APIs; per-transaction and per-day ceilings | Steps 3 to 5 | From the October advisory; still the baseline |
| Restrict cloud management and serverless execution and monitor cloud audit logs; default-deny egress; WAF virtual patching while fixes ship; honeypots and canary credentials; monitor LLM API usage from servers; keep wallet keys in HSMs or cold custody with multi-signature | Various | The long tail, each of which has featured in at least one reported case |
| Report incidents to [email protected] with logs | All | Within six hours of noticing, under the 2022 directions |
What the regulators have added
- I4C. The Ministry of Home Affairs' Indian Cyber Crime Coordination Centre issued its own caution in the first week of November, reported by the government's news service, asking banks, NBFCs and fintechs to "urgently implement the measures prescribed in the advisories issued by" CERT-In, to report incidents to CERT-In within six hours and to RBI through DAKSH.
- RBI. Press reports describe a confidential RBI advisory dated 3 November to banks that provide API-based fund transfers to NBFC and fintech clients, asking for additional safeguards on those integrations, including beneficiary whitelisting and maker-checker controls, on a short timetable. We have not seen the text, so treat the detail as reported. Separately, on 5 November RBI issued consolidated cybersecurity directions for non-bank payment system operators, with six-hour incident reporting and annual testing requirements, which are not specific to this campaign but land in the same fortnight.
- Existing directions already cover the basics. RBI's 2026 cybersecurity directions for commercial banks require that the bank "properly segregate the development, test, and production environments", mandate multi-factor authentication for privileged users of critical systems, and require incident reporting "within six hours of detection on DAKSH". The NBFC directions carry the same six-hour clock for Middle Layer and above and the same privileged-access requirement. Our guide to the NBFC directions by layer sets out what applies to whom.
Why the application's controls did not help
The sentence about "completely bypassing application-level controls" deserves a closer look, because it describes a design flaw that long predates AI. In many lending and payment platforms, the rules that matter, who may be paid, how much, after which approvals, are enforced in the application or the mobile app, and the API underneath simply executes what it is told. Anyone who can reach that API with a valid credential inherits none of the rules.
In the OWASP API Security Top 10, this is API6:2023, Unrestricted Access to Sensitive Business Flows, usually combined with API2:2023 Broken Authentication, where tokens are shared or long-lived, and API9:2023 Improper Inventory Management, where the UAT copy of the API is forgotten but still reachable. Our API penetration testing specifically looks for business rules that exist only in the client, and our article on testing authorisation in APIs explains how those tests work.
A two-week checklist
Days 1–2 — Find your exposure
List every internet-reachable non-production environment, every API endpoint that can move money, and every credential or token that works in more than one environment. Check whether vendor integrations rely on IP allow-lists. Pull the restricted advisory if you are eligible and load its indicators into your monitoring.
Days 3–5 — Hunt
Search API, cloud, identity and transaction logs for micro-value transfers to new beneficiaries, disbursement calls from unexpected sources, out-of-hours activity, new serverless functions or management sessions, and web shells on upload paths. Assume the question is "are they here", not "could they get in". A threat hunt scoped to this advisory is a few days of work.
Days 6–10 — Cut the paths
Take non-production offline from the internet or put it behind authentication, rotate every shared secret, close network routes between environments, enforce MFA on payment and admin interfaces, and put velocity, cooling-period and maker-checker rules on every disbursement path.
Days 11–14 — Test and tune
Have the payment APIs tested against this attack chain, with the business rules checked server-side. Lower alert thresholds for the coming weekend and confirm somebody is watching. Brief the board, because the next advisory may arrive during a holiday.
If something is found, the clock is already running: six hours to CERT-In, six hours to RBI through DAKSH for regulated entities, and, from May 2027, the DPDP breach notification duties as well. Our guide to incident response retainers covers how to have a response team ready before that call, and a managed SOC is the practical answer to the weekend problem.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is Crafty Falcon?
The name CSIRT-Fin, the financial sector incident response team under CERT-In, has given to a threat actor it describes as an AI-assisted financial attacker that surveys targets with machine intelligence, operates at machine speed and strikes by invoking victims' own payment and disbursement APIs. CERT-In has not attributed it to any country.
QWhat does CERT-In advisory CIAD-2026-0058 say?
Issued on 4 November 2026 and rated Critical, it updates the 9 October advisory CIAD-2026-0046 and reports a significant escalation of attacks on NBFCs, digital lending platforms, fintechs, payment aggregators, payment service providers and crypto exchanges. It describes entry through exposed non-production environments, movement to production through shared credentials, micro-value test transactions, attacks timed for weekends and holidays, and re-targeting of firms that had already remediated.
QWho is being targeted?
The advisory names non-banking financial companies, digital lending platforms, fintech entities, payment aggregators, payment service providers and cryptocurrency exchanges and virtual digital asset service providers. The October advisory also mentioned wallet operators. The title refers to BFSI entities generally.
QHow do the attackers get in?
The advisory names internet-exposed UAT, staging and testing environments as entry points, followed by movement to production using shared credentials, tokens or network paths. Other documented routes include file-upload and deserialisation flaws leading to web shells, and modified copies of the firm's own mobile app making API calls.
QWhy can attackers bypass KYC, limits and beneficiary checks?
Because those checks are often enforced in the application or mobile app rather than the API underneath. The advisory describes attackers invoking disbursal and fund-transfer APIs directly from within the firm's own whitelisted infrastructure, bypassing application-level controls such as loan creation, KYC, sanction, beneficiary verification, balance sufficiency and per-transaction limits.
QWhat is the significance of the Rs. 1 transactions?
CERT-In reports that attackers perform micro-value test transactions, such as Rs. 1, to validate that an unauthorised fund flow works before sending high-value transfers to mule accounts. A monitoring rule that flags a micro-value transfer to a new beneficiary followed by a large one is one of the advisory's specific recommendations.
QWhich AI tools are the attackers using?
CERT-In names the ARTEX family of LLM-based tooling, the PentAGI autonomous multi-agent penetration testing system, the Cairn attack search engine and the CyberStrikeAI framework. All are publicly available offensive-security projects; their use is what gives the campaign its speed and scale.
QWhat are the most important fixes?
Isolating non-production environments completely, with no shared credentials, tokens, keys or network paths; enforcing every transaction and business rule server-side with signed requests; replacing IP allow-listing of shared vendor pools with mutual TLS, signed requests or scoped API keys; velocity rules, new-beneficiary cooling periods and maker-checker on fund movement; MFA on payment and admin interfaces; and full eradication with forensic verification followed by continued threat hunting.
QDo we need to report if we find signs of this attack?
Yes. Under CERT-In's 2022 directions, specified cyber incidents must be reported within six hours of noticing them, to [email protected] with relevant logs. RBI-regulated banks and NBFCs in the Middle Layer and above must also report within six hours on DAKSH, and the I4C advisory of early November reiterated both duties.
QHow much money has been lost?
CERT-In and RBI have not published any figure for incidents, entities affected or losses. Press reports citing unnamed sources have put losses in the hundreds of crores of rupees; those figures are unconfirmed.
QDoes this affect banks?
The advisory's named targets are NBFCs, lending platforms, fintechs, payment aggregators, payment service providers and crypto exchanges, with BFSI entities in the title. Press reports describe a separate confidential RBI advisory to banks that provide API-based fund transfers to those clients, asking for additional safeguards on the integrations.
QIs a penetration test enough?
A test scoped to this attack chain finds the exposed environments, shared credentials and client-side-only business rules, which is essential. It is not sufficient on its own: the advisory stresses eradication with forensic verification and continued threat hunting, because firms that fixed what they found were re-targeted.
Related reading
For the wider regulatory frame, see RBI's 2026 cybersecurity directions and CERT-In's six-hour reporting rule. For the technique the attackers rely on, testing BOLA, BFLA and business-flow authorisation. For how AI changes offence more generally, the future of offensive security in the age of AI.
Sources
- CERT-In / CSIRT-Fin, Advisory CIAD-2026-0058: Escalation of AI-Driven Attacks on BFSI Entities by Threat Actor "CRAFTY FALCON" (4 November 2026).
- CERT-In / CSIRT-Fin, Advisory CIAD-2026-0046: Threat Actors Exploiting Payment and Disbursement APIs for Unauthorized Fund Transfers in BFSI Entities (9 October 2026).
- CERT-In, Advisory CIAD-2026-0049: AI Agents as Attack Vectors (15 October 2026).
- CERT-In, Directions under section 70B(6) of the IT Act, 2000 (28 April 2022).
- News On AIR, I4C cautions banks and fintech firms against AI-driven cyberattacks.
- MediaNama, CERT-In flags an AI threat actor targeting BFSI payment APIs for unauthorized fund transfers.
- MediaNama, RBI asks bankers to tighten API security after AI-driven attacks.
- Reserve Bank of India, Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026.
- Reserve Bank of India, Non-Bank Payment System Operators cybersecurity directions (5 November 2026).
- The Hacker News, Backdoored Docker image for ARTEX AI pentesting tool (5 November 2026).
- Cloud Security Alliance, Research note: agentic intrusion and financial API abuse, 2026.
- OWASP, API Security Top 10 2023.
Adayptus Consulting
Threat Intelligence, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, testing the APIs behind payment and lending products and hunting for the paths attackers are using this month.
