CERT-In’s BFSI Advisory: How CRAFTY FALCON’s AI-Driven Attacks Put Banking APIs Under Pressure

TL;DR

• AI has changed the economics of financial cyberattacks. Offensive AI tools now automate reconnaissance, exploit development and execution, giving attackers speed, scale and autonomy that once required skilled human teams.
• Banking APIs are the new target. Attackers increasingly skip the data breach and call legitimate payment, disbursement and settlement APIs to move money directly.
• Valid requests can still be fraudulent. Authentication, IP allowlisting, WAFs and API gateways confirm who is calling and from where. They cannot confirm whether a transaction belongs in the business workflow.
• The threat is documented. CERT-In’s November 2026 advisory on the CRAFTY FALCON actor shows AI-assisted attackers testing payment APIs with ₹1 transfers before scaling up, and re-attacking institutions after incomplete fixes.
• Business logic is the missing control. BFSI teams need continuous API discovery, continuous red-teaming and runtime protection, connected by business logic security that validates every API action in context.

AI Is Changing the Economics of Financial Cyberattacks

AI-driven API attacks are attacks in which offensive AI tools automate reconnaissance, exploit development and execution against application programming interfaces, at a speed and volume no human team can match. For every bank, NBFC, fintech and payment company that exposes a banking API, they have moved from forecast to incident report in a single year.

The shift is visible in the numbers. The Digital Threat Report 2025-26, published CERT-In and CSIRT-Fin, found that cyberattacks on India’s BFSI sector run at 1.6 times the global average, and that incidents more than doubled from 1.4 million in 2021 to 2.9 million in 2025. The report warns that frontier AI models can now attack financial institutions with minimal human help, and that the zero-day exploit window has shrunk from weeks to hours.

Three changes explain why banking APIs sit at the center of this shift:

• Attack labor is now automated. Open-source, LLM-driven pentest frameworks run complete attack chains on their own. In the GTG-1002 campaign disclosed in November 2025, AI reportedly carried out 80 to 90 percent of the work against around 30 organizations, including financial institutions.
• The money moves through APIs. Payments, disbursements, beneficiary management and merchant settlement all run on APIs. An attacker who can call those APIs does not need to steal data and sell it.
• Attackers now abuse legitimate functionality. In its November 2026 advisory on the CRAFTY FALCON actor, CERT-In documented AI-assisted attackers moving funds by calling victims’ own payment and disbursement APIs. The requests looked valid at the gateway.

That last change redefines what banking API security has to do. Finding and patching vulnerabilities remains essential. It no longer covers the full risk, because a well-formed, authenticated API call can still be fraud.

Every API action that moves money must be validated against its business context, continuously and at machine speed. The sections below explain how AI-driven attacks target banking APIs, use the CRAFTY FALCON campaign as a case in point, examine why common controls fall short, and set out what BFSI security leaders should evaluate in an API security platform.

How AI-Driven Attacks Are Targeting Banking APIs

AI-driven attacks on banking APIs follow a repeatable chain: automate discovery, enter through the weakest environment, impersonate the legitimate client, slip past network trust, then test and scale fraudulent transactions. Each step below is documented in 2026 incident reporting on financial-sector attacks.

Automated reconnaissance and exploitation

Offensive AI frameworks such as ARTEX, PentAGI and CyberStrikeAI run complete attack chains autonomously. They generate tailored attack scripts in rapid succession, refine payloads based on each application response and rotate infrastructure within hours. Newly published vulnerabilities are exploited as soon as they become public.

These tools are widely available. The Hacker News reported that 1,645 hosts were serving the ARTEX console as of November 4, 2026, and that a backdoored copy of its Docker image was downloaded about 9,000 times. What once took a skilled team weeks now runs unattended overnight.

Exploiting non-production and peripheral environments

AI agents enumerate targets exhaustively, so they find the APIs security teams forgot. Internet-exposed UAT, staging and test environments are common entry points, with attackers moving into production through shared credentials, tokens or network paths. According to the Cloud Security Alliance, ARTEX-driven intrusions against South Korean banks in late 2026 also began at peripheral services, including a broker-facing loan inquiry service, before reaching customer data.

This is the unmanaged API problem at machine speed. Every shadow endpoint, forgotten test API and zombie API is now found and probed automatically.

Manipulating legitimate API access

Attackers reverse-engineer mobile and web application code, then send API calls from altered or repackaged application clients. This defeats any control that assumes only the genuine app can call the backend. To the server, the request carries the right structure, headers and session.

Bypassing IP-based restrictions

IP allowlisting is a common control for partner and vendor integrations. Attackers now route traffic through shared, allowlisted third-party fetcher IP pools, such as content-acceleration and app-store review services, that any internet user can trigger. An allowlisted IP then proves only that a request passed through a shared service.

Testing fraudulent transactions before scaling

Once attackers can call a payment API, they confirm the route works with a micro-value transaction, often ₹1, before moving larger sums. Merchant settlement APIs and disbursement endpoints are abused the same way. The test transaction is a business-level probe that no signature or vulnerability scanner will flag, because the request itself is valid.

What CERT-In’s CRAFTY FALCON Advisory Reveals

The clearest documented example of these patterns is the CRAFTY FALCON campaign. On November 4, 2026, CERT-In issued Advisory CIAD-2026-0058, rated Critical. Its financial-sector team, CSIRT-Fin, described CRAFTY FALCON as an AI-assisted financial threat actor that “strikes by invoking the victim’s own payment and disbursement APIs.”

Fact	Detail
Advisory	CERT-In Advisory CIAD-2026-0058, severity Critical, issued November 4, 2026; updates CIAD-2026-0046 of October 9, 2026
Targets	NBFCs, digital lending platforms, fintechs, payment aggregators, payment service providers, crypto exchanges and virtual digital asset providers
AI tools named	ARTEX, PentAGI, Cairn, CyberStrikeAI
Entry points	Internet-exposed UAT and staging environments; cloud management services such as AWS Systems Manager and Lambda
Signature technique	₹1 test transfer through the victim’s own payment or disbursement API, followed by large-value transfers
Reported losses	About $2 million across 700+ unauthorized transfers at two Mumbai-based non-bank lenders, per a police complaint cited by Reuters

Three details make the advisory a warning for every BFSI security team:

• Remediation did not end the attacks. CSIRT-Fin continued to receive reports of successful attacks from NBFCs and fintechs that had already received restricted TLP:AMBER advisories and acted on them. Several were deliberately re-targeted after incomplete fixes.
• The timing was deliberate. Attacks were scheduled for holidays, weekends and other low-monitoring windows to delay detection and response.
• The tooling has wider links. Reuters reported that security researchers have linked at least two of the four named tools to China, though CERT-In did not describe the attacks as state-sponsored.

CRAFTY FALCON is one actor. The techniques it used are available to anyone who downloads the same open-source frameworks, which is why the lessons apply well beyond this campaign.

Why Traditional Banking API Security Controls Fall Short

Most banking API controls answer two questions: is the caller authenticated, and is the request malformed? AI-driven attackers pass both. Their requests come from valid sessions, trusted IPs and clients that look genuine, and they ask the API to do exactly what it was built to do. The gap sits in a third question few controls ask: should this action happen, for this user, at this point in the workflow?

Control	What it verifies	How AI-driven attackers get past it
Authentication	The caller holds valid credentials or tokens	Stolen partner and staging credentials, tokens shared across environments
IP allowlisting	The request comes from an approved address	Traffic routed through allowlisted third-party fetcher pools
Client-side checks	The request comes from the official app	Reverse-engineered, repackaged application packages
WAF and API gateway rules	The payload is not malicious and within rate limits	Well-formed payment calls with no attack signature
Periodic security testing	Known weaknesses at a point in time	Agents that exploit new vulnerabilities as soon as they are public
Partial API inventory	Documented APIs are monitored	Shadow, staging and zombie APIs left exposed

• Authentication without business-context validation. Valid credentials prove identity. They say nothing about whether a ₹1 transfer to a new beneficiary, followed by a large one, is a legitimate customer action.
• IP allowlisting. A trusted IP is a network fact. Shared fetcher pools turn it into a door anyone on the internet can walk through.
• Periodic security testing. Quarterly scans and annual penetration tests run on a human calendar. Autonomous attack agents run around the clock, which is the core argument for continuous red-teaming.
• Client-side security assumptions. Once an app is repackaged, every control enforced only in the client disappears. CERT-In’s guidance is explicit: treat client applications and packages as untrusted.
• Perimeter-focused security. A WAF or API gateway inspects traffic for known bad patterns and enforces quotas. A well-formed disbursement call has neither problem.
• Fragmented API visibility. Security teams cannot protect endpoints they do not know about, and exposed non-production APIs are a recurring entry point.

Each of these controls still matters. Their shared weakness is that none understands the business flow the API serves, so none can tell a legitimate payout from an abusive one.

What BFSI Organizations Need to Evaluate in an API Security Platform

An API security platform built for AI-driven attacks must do four things: find every API, test it the way an autonomous attacker would, enforce controls on live traffic, and judge every request against the business flow it belongs to. The questions below form a practical evaluation checklist for CISOs and application security leaders. For a broader version, see the API Security Buyer’s Checklist and 7 API Security Requirements for Payment Transactions.

Continuous API discovery and posture management

AI agents find forgotten APIs first. Discovery is the precondition for every other control.

• Discover known, unknown, shadow and undocumented APIs. Inventory should come from live traffic as well as specs and gateway configs, and should include UAT, staging and partner-facing endpoints.
• Identify exposure and misconfiguration. Flag internet-facing non-production APIs, endpoints that share credentials with production, and responses that leak account or beneficiary data. Sensitive data discovery at the API layer also supports DPDP obligations, covered in our DPDP whitepaper.
• Map dependencies to business-critical flows. Know which APIs take part in onboarding, beneficiary addition, disbursement and settlement, so risk is ranked by what an endpoint can move as well as by its CVSS score.

Automated API red-teaming

When attackers use autonomous pentest agents, annual manual testing leaves months of exposure. Defensive testing has to run at a similar cadence and depth.

• Test authentication and authorization continuously. Run on every release and on a schedule throughout the year.
• Cover the OWASP API Top 10 categories that matter most for payments. These include Broken Object Level Authorization (BOLA), Broken Function Level Authorization (BFLA), privilege escalation and unrestricted access to sensitive business flows. The hidden cost of BOLA/BFLA vulnerabilities is often far higher than their severity scores suggest.
• Simulate transaction abuse. Test scenarios such as replaying a disbursement call, swapping a beneficiary ID, changing an amount after approval, or skipping a maker-checker step.
• Validate controls under adaptive attack. Confirm that rate limits, velocity rules and step-up checks hold when payloads mutate between attempts. See the enterprise API testing capabilities worth requiring.

Runtime API protection

AI-driven attackers return after remediation and time attacks for weekends. Protection has to be live and automatic, whoever is on shift.

• Inspect requests and responses in real time. Analyze full API transactions, including response data, to see what an attacker actually obtained.
• Detect abnormal usage and suspicious sequences. Flag patterns such as a ₹1 transfer to a new beneficiary followed by a high-value transfer, bursts of settlement instructions, or calls from a repackaged client.
• Identify business logic abuse. Detect manipulation of payment, beneficiary and settlement workflows, even when every request is individually valid.
• Enforce and contain automatically. Block, throttle or hold suspicious flows in line, and feed evidence straight into incident response, so containment does not wait for an analyst on a holiday weekend.

Business logic security

Business logic security addresses the defining technique of AI-driven financial attacks: using legitimate API access to perform unauthorized business actions. It is also where most API security tools stop short, because it requires the platform to learn how the application is meant to behave. As the Lovable breach showed, a single missing line of logic can expose an entire platform.

• Understand the intended sequence of operations. A disbursement should follow loan approval, KYC and beneficiary verification, in that order, by users with the right roles.
• Validate each request in its business context. Judge whether this user, holding this object, should perform this action at this step.
• Detect deviations from expected flows. Catch skipped steps, unusual object access, permission drift and out-of-sequence settlement calls.
• Surface attacks that use legitimate access. Identify abuse that carries valid tokens, valid IPs and valid payloads.

AppSentinels builds this context through its Business Logic Graph (BLG), a continuously learned model of how each application’s APIs, users, objects and workflows relate. The BLG lets the platform recognize when a technically valid call breaks the business rules the application was built to enforce.

How to Build a Stronger Defense Against AI-Driven Banking API Attacks

The fastest way to reduce exposure to AI-driven API attacks is to act on CERT-In’s published recommendations, with API-layer controls first. This eight-point checklist condenses that guidance for payment and disbursement APIs.

1. Maintain continuous visibility into all internet-facing APIs. Include UAT, staging and partner endpoints, and re-run discovery after every release.
2. Isolate UAT, staging and production. CERT-In calls for no shared credentials, tokens, API keys, databases or direct network paths, and for production-grade hardening of any internet-facing non-production system.
3. Enforce server-side validation of every transaction and business rule. Treat client applications as untrusted, sign API requests with a nonce and timestamp, and use app attestation and certificate pinning to detect repackaged apps.
4. Replace IP-only trust with identity-based API controls. CERT-In recommends mutual TLS, cryptographically signed requests or scoped API keys on dedicated vendor endpoints in place of allowlisted shared fetcher pools.
5. Implement transaction velocity checks, new-beneficiary cooling periods and anomaly detection. Apply amount-band rules across every payment and disbursement path, and require maker-checker approval and reconciliation for merchant settlement instructions.
6. Monitor micro-value transactions followed by high-value transfers. CERT-In describes this pattern as a strong precursor of unauthorized fund transfer and advises holding or reviewing such flows.
7. Continuously test APIs and prioritize newly disclosed vulnerabilities. Set a rapid patching SLA for internet-facing applications, with file-upload and deserialization flaws first, and use virtual patching as an interim measure.
8. Implement real-time monitoring and automated incident containment. Tune detection for machine-speed, multi-technique activity, adopt automated containment, and raise staffing and lower alert thresholds over weekends and holidays.

One principle from the advisory applies to all eight: indicators change while adversary techniques stay consistent, so blocking known IPs and hashes is never enough on its own.

Why API Discovery, Red-Teaming, and Runtime Protection Must Work Together

No single API security control covers the full AI-driven attack chain. Discovery without enforcement leaves known gaps open. Testing without runtime protection finds problems after attackers have. Runtime protection without business context blocks noise and misses valid-looking fraud. The four capabilities work as one system, with business logic security as the layer that connects them.

• API discovery establishes the attack surface. It finds the exposed staging API before an autonomous agent does.
• API red-teaming finds exploitable weaknesses first. It proves whether a beneficiary swap or a skipped approval step actually works against your APIs.
• Runtime protection stops attacks as they happen. It holds the ₹1-then-large-transfer sequence at 2 a.m. without waiting for a human.
• Business logic security connects all three. It gives discovery a map of which APIs move money, gives red-teaming real workflows to attack, and gives runtime protection the context to separate a customer from an attacker holding that customer’s session.

AI-driven attack technique	Discovery	Red-teaming	Runtime protection	Business logic security
Entry through exposed UAT and staging	Finds exposed non-production APIs	Tests shared credentials and paths	Flags non-production-to-production access	Maps which staging APIs mirror payment flows
Repackaged application clients	Inventories every API the app calls	Tests server-side enforcement of rules	Detects anomalous client behavior	Rejects actions outside the expected flow
Allowlisted fetcher-pool traffic	Identifies endpoints relying on IP trust	Tests reliance on IP allowlists	Detects identity and behavior mismatch	Validates the action whatever its source IP
₹1 test, then large transfer	Maps beneficiary and payout APIs	Simulates the test-and-scale pattern	Holds the sequence in real time	Recognizes the sequence as abuse
Merchant settlement API abuse	Finds every settlement endpoint	Tests BOLA and BFLA on settlement objects	Blocks abnormal settlement bursts	Enforces maker-checker order

This is the case for an integrated platform in BFSI. When AI-driven attackers chain techniques at machine speed, defenses that live in separate tools, with separate data and separate owners, leave gaps at every handoff. A shared model of the business flow closes them.

AppSentinels was built on that model. API discovery, automated API red-teaming and runtime protection all draw on the same Business Logic Graph, so a finding in one layer informs the others. That is how a platform can tell whether a legitimate API is being used legitimately. See how this works for a nation’s real-time payment rails.

Why Banking API Security Must Move at the Speed of the Attack

AI-driven API attacks have changed the tempo of financial fraud. Reconnaissance, exploitation and transaction testing now run autonomously, around the clock, and return to the same target after every incomplete fix. Banking APIs need security that matches that tempo: continuous discovery, continuous testing and runtime enforcement that acts without waiting for a human. The same shift is now reaching AI agents inside financial institutions, which is why agentic AI is finance’s next security blind spot.

The deeper lesson is about what security is protecting. Closing vulnerabilities remains essential, and it covers only half the risk. The other half is the payment, disbursement and settlement functionality that works exactly as designed and can still be turned against the institution. Financial institutions that validate every API action against its business context will be the ones that stop the ₹1 test before it becomes a ₹1 crore loss.

Book a demo to find out whether your API security strategy is prepared for machine-speed attacks or not.

Frequently Asked Questions