CERT-In CRAFTY FALCON Advisory: What BFSI Teams Should Test

CERT-In says the payout-API campaign has escalated and has re-hit firms that already remediated. Six assumptions it breaks, and how to test each one safely.

On 4 November 2026 CERT-In’s financial-sector team issued a Critical advisory, CIAD-2026-0058, naming the actor behind the payout-API fraud campaign “CRAFTY FALCON” and describing how it has escalated. The new detail is less about AI tooling than about the assumptions it breaks: that test environments do not matter, that only your app calls your API, and that an allow-listed IP address means a trusted caller. Here is what changed, and how to test those assumptions.

The short version

What: CERT-In Advisory CIAD-2026-0058 (4 November 2026, Critical) updates CIAD-2026-0046 of 9 October on attackers abusing payment and disbursement APIs for unauthorised fund transfers. CSIRT-Fin now tracks the actor as “CRAFTY FALCON”.
Who is affected: NBFCs, digital lenders, fintechs, payment aggregators and service providers, and crypto exchanges.
What is new: abuse of cloud management and serverless services, entry through internet-exposed UAT and staging systems, modified app packages calling APIs directly, IP allow-lists bypassed through shared third-party “fetcher” services, ₹1 test transactions before large transfers, and abuse of merchant settlement APIs.
The warning that matters most: CERT-In says entities that had already remediated after earlier restricted advisories were deliberately re-targeted, sometimes after incomplete clean-up, and often on weekends and holidays.
Do now: assume persistence after any incident, isolate non-production from production, stop treating shared IP ranges as identity, and alert on micro-value payments to new beneficiaries followed by large ones.

What the advisory says

CIAD-2026-0058 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”. CERT-In says the threat is active and ongoing, and that CSIRT-Fin continues to receive reports of successful attacks.

The advisory names publicly available AI-driven offensive tools seen against affected entities, including the “ARTEX” family, “PentAGI”, the “Cairn” attack search engine and “CyberStrikeAI”. It says they run complete attack chains, generate and refine tailored scripts quickly and adapt to the target’s responses, while the supporting infrastructure rotates IP addresses within hours to days. Indicators, infrastructure fingerprints and detection rules have gone to BFSI entities in a restricted version. CERT-In’s public text adds that indicators change while techniques tend not to, so blocking indicators is not enough.

Reporting by the Hindustan Times adds that a separate advisory on 3 November from I4C’s National Cybercrime Threat Analysis Unit, issued with CERT-In, described attackers exploiting unpatched software and misconfigured internet-facing servers, then moving money to mule accounts that are quickly emptied through IMPS and NEFT. It also notes the six-hour deadline for reporting incidents to CERT-In, and that banks and NBFCs must report to the Reserve Bank of India through its DAKSH portal in the same period.

What changed since CIAD-2026-0046

Our earlier note on CIAD-2026-0046 focused on one design problem: payout services that forward whatever they are given, so a stolen gateway credential skips every upstream check. That advice stands. CIAD-2026-0058 adds new routes in and around controls. In CERT-In’s terms:

Cloud management channels: cloud management services such as AWS Systems Manager and Lambda abused to run commands and deploy malicious files, “blending malicious activity into legitimate cloud management channels”.
Non-production as the front door: internet-exposed UAT, staging and test environments used as entry points, followed by movement to production “using shared credentials, tokens or network paths”.
Modified clients: application codebases reverse-engineered, then unauthorised API calls made using altered or repackaged app packages, “defeating controls that assumed only the legitimate client application would call the APIs”.
Allow-list bypass: traffic originated from whitelisted third-party fetcher IP pools, such as content-acceleration and app-store review fetchers. CERT-In notes that any internet user can cause such shared services to fetch arbitrary URLs.
Test transactions: micro-value transfers, such as ₹1, to confirm an unauthorised fund flow works before large-value transfers.
Settlement APIs: merchant settlement APIs of payment aggregators exploited or abused to move funds.
Speed on new flaws: newly published vulnerabilities, including file-upload and deserialisation chains, exploited as soon as they are public, leading to web shells in PHP and Node.js applications.

Six assumptions to test

None of these techniques needs a novel exploit. Each works because a control rests on an untested assumption, which makes them a practical scope for an authorised assessment. These are the questions PoCForge would ask, mapped to CERT-In’s recommendations.

1. “UAT is not production, so it can wait”

CERT-In asks entities to isolate UAT, staging and test from production with “no shared credentials, tokens, API keys, databases or direct network paths”, to harden and monitor internet-facing non-production environments to production standard, and to alert on any access from non-production to production systems, credentials or data. To test this, enumerate every internet-reachable non-production host, including forgotten ones; then, from an agreed foothold in UAT, check which production secrets, databases, queues or network routes are reachable. Copied .env files and one CI token deploying to both environments are typical of what to look for.

2. “Only our app can call our API”

The advisory is direct: treat client applications and packages as untrusted, validate every transaction and business rule server-side, sign API requests with a nonce and timestamp, and use app attestation and certificate pinning to detect altered or repackaged apps. In a mobile or API test this means calling the API without the app: replaying and modifying requests, removing client-side checks, and confirming that limits, beneficiary rules and approval states are enforced by the server. Attestation and pinning raise the cost of tampering, but they are not authorisation.

3. “The request came from an allow-listed IP, so it is trusted”

If an API or admin endpoint allow-lists a shared range that belongs to a CDN, an app-store review service or any other fetcher anyone can direct, the allow-list admits anyone who can make that service fetch a URL. CERT-In’s recommendation is to replace IP allow-listing of shared third-party fetcher pools with identity-based controls: mutual TLS, cryptographically signed requests, or scoped API keys on dedicated vendor endpoints. The test is mostly a review: list every allow-list in front of sensitive endpoints, identify who owns each range, and flag any range that third parties share or can direct. Then confirm the endpoint also demands a credential that a shared service cannot hold.

4. “Cloud management activity is our own activity”

Remote command execution and serverless code changes look routine in audit logs unless someone is watching for them. CERT-In asks for real-time monitoring of cloud audit logs with alerts on remote command execution, serverless function code updates and creation of roles, users or access keys; for cloud management and serverless execution to be restricted to approved principals; for instance metadata protections and least-privilege roles; for no wildcard egress in security groups; and for serverless functions to have no internet egress by default. A cloud security assessment should trace which identities can start a remote session or update function code in production, starting from a low-privilege or workload identity, and should confirm the alerts actually fire during the test.

5. “We remediated, so we are clean”

This is the most important point in the advisory. CERT-In says entities that had already received the earlier restricted advisories and remediated were attacked again, including after incomplete remediation, and tells entities to “assume persistence”: full eradication with forensic verification, then periodic threat hunting. It also recommends making application deployment directories read-only for the runtime user, file-integrity monitoring for web shells, and rotating all build and deployment tokens. An assumed breach assessment starting from an application server, CI runner or developer token shows what an attacker who kept a foothold could still reach.

6. “A ₹1 transaction is noise”

CERT-In asks entities to flag micro-value test transactions to new beneficiaries followed by high-value transactions, treat that sequence as “a strong precursor” of fraud, and hold or review such flows. It also asks for velocity rules, new-beneficiary cooling periods and amount-band anomaly detection on every payment and disbursement path, and for server-side validation, maker-checker approval and reconciliation of merchant settlement instructions submitted through aggregator APIs. In a test environment with synthetic accounts, run the sequence and confirm that the rules trigger, that the hold actually stops the second transfer, and that settlement instructions cannot skip maker-checker through the API.

A note on penetration testing itself

Two of CERT-In’s recommendations are about testing tools directly. It asks entities to prohibit unauthorised security and attack tools, including publicly available AI-driven offensive frameworks, on corporate infrastructure, and to watch for AI coding-agent processes running with permission checks disabled and for LLM API traffic from servers that should not generate it. It also asks for a policy requiring written approval, defined scope and a time window for all penetration testing, noting that “the tools themselves do not validate authorization”.

That is a fair standard for any testing provider. Recommended conditions for this kind of work are written authorisation, an agreed scope with named targets and a test window, and money-movement tests that use non-production environments and synthetic accounts unless the platform owner approves otherwise in writing. Buyers should expect those conditions from any provider they engage.

Methodology notes and limits

This article is based on the public text of CIAD-2026-0058 on the CERT-In website and press coverage available on 9 November 2026. We have not seen the restricted version of the advisory or its indicators, we have no access to affected entities’ systems, and we do not attribute the campaign beyond CERT-In’s own naming. CERT-In has not published victim counts or loss figures in the public advisory. We deliberately do not describe how to abuse fetcher services or repackage apps; the tests above confirm whether controls hold, not how to defeat them. Testing should only be carried out on systems you own or are explicitly authorised to assess.

What this means for buyers

Put non-production in scope. If UAT or staging is internet-facing, it belongs in the same test as production, along with the paths between them.
Test the API without the app. Ask for API testing and mobile testing that show what the server accepts from a modified client, not only what the app allows.
List your allow-lists. Ask which IP-based controls guard payment, settlement and admin endpoints, and who else can send traffic from those ranges.
Retest for persistence, not just the patch. After an incident, scope an assumed breach exercise, not only a vulnerability re-check.
Prove the fraud rules fire. Ask for monitoring rules to be exercised in a test environment.

Key takeaways

CIAD-2026-0058 escalates the October payout-API campaign and names the actor CRAFTY FALCON.
The techniques are conventional: exposed UAT, trusted clients, shared-IP allow-lists, unwatched cloud management channels and unnoticed test payments.
Entities that remediated were re-targeted; assume persistence and verify eradication.
Replace IP trust with identity: mutual TLS, signed requests or scoped keys.

If you would like a scoped review of your payout, settlement or cloud paths against this advisory, talk to PoCForge.

CERT-In CIAD-2026-0058 and CRAFTY FALCON: Six Assumptions Indian BFSI Teams Should Test Now