Security Operations

CERT-In’s Crafty Falcon alert: AI fraud crew targets weekend gaps

CERT-In’s critical CRAFTY FALCON advisory shows AI-assisted fraudsters re-hitting payment firms at weekends. Lessons for UK SOCs and fintechs.

Radar graphic with the headline AI fraud crew waits for the weekend

India’s CERT-In has issued a critical advisory on CRAFTY FALCON, an AI-assisted fraud crew that keeps returning to payment firms that thought they had cleaned up and deliberately strikes when security teams are thinnest. Its tradecraft maps neatly onto gaps common in UK payments estates.

What happened

CERT-In, India’s national computer emergency response team, first published advisory CIAD-2026-0058 on 4 November 2026 and the page shows a last update on 7 November, without saying what changed. It is rated critical. The advisory comes from CSIRT-Fin, the team’s finance-sector unit, and builds on CIAD-2026-0046, an earlier warning from 9 October about criminals abusing payment and disbursement APIs to move money out of lenders and fintechs.

The new document gives the actor a name, CRAFTY FALCON, and describes the campaign as “active and ongoing”. The detail that should worry defenders is not the AI angle but the persistence. According to CERT-In, organisations that had already received restricted TLP:AMBER warnings and carried out remediation were hit again, some after an incomplete clean-up. CERT-In also says the crew picks its moments, favouring weekends, public holidays and other quiet spells when fewer analysts are watching.

Those named as targets include non-bank lenders, digital lending platforms, fintechs, aggregators, PSPs and crypto exchanges. CERT-In says the crew relies on publicly available AI offensive tooling, listing the ARTEX family, the PentAGI multi-agent testing system, CyberStrikeAI and the Cairn attack search engine. What matters for a SOC is what the actor does with them.

The technical picture

Combining the advisory with reporting from The Register and MediaNama gives this pattern.

  • Way in through non-production. The crew hunts for user acceptance testing, staging and test environments left reachable from the internet. Those systems often hold credentials, tokens or network routes that also work in production, so a weak test box becomes the bridge to live payment systems.
  • Cloud control planes as a launch pad. CERT-In says AWS Systems Manager and Lambda have been misused to run commands and drop files.
  • Your own app, turned against you. The actor reverse-engineers client applications and ships modified packages that make unauthorised calls to the victim’s payment APIs. Controls that trust the app do not fire.
  • Allow-lists defeated by shared infrastructure. Where partners restrict API access by source IP, the crew routes traffic through shared third-party fetcher pools, such as content acceleration and app-store review services, whose addresses are already trusted.
  • Penny tests, then the real thing. Transfers of around Rs 1, roughly a penny, confirm that a fraudulent flow works before larger sums are moved. Merchant settlement APIs at payment aggregators are also abused, and at crypto platforms the goal is wallet keys.
  • Speed and churn. Newly disclosed file-upload and deserialisation flaws are used to plant PHP and Node.js web shells, infrastructure IPs rotate within hours to days, and scripts are churned out in near-identical waves that CERT-In says are consistent with AI-assisted development.
Flow diagram of the CRAFTY FALCON attack chain from exposed staging systems to Rs 1 test payments and weekend timing

Why it matters for UK organisations

No UK victim has been reported, but nothing in this playbook is specific to India. The UK has one of the densest fintech and payments sectors in the world, with open banking APIs, embedded finance partners and a long tail of smaller payment institutions and e-money firms that run lean security teams. Many rely on the same patterns: IP allow-listing for partners, mobile apps trusted as the client, and staging boxes that drifted onto the internet and stayed there.

The timing point is the one that should prompt a conversation at board level. Plenty of UK mid-market firms buy out-of-hours monitoring from an MSSP on a contract that covers alert triage but not active response, or run an in-house team with a single on-call engineer over the weekend. An actor that deliberately waits for Saturday night, a bank holiday or the Christmas shutdown is exploiting a staffing model, not a vulnerability.

Regulators will take an interest too. Operational resilience rules from the FCA and PRA expect firms to remain within impact tolerances for important business services, and an attack that disrupts payment services through a compromised API could test those tolerances.

Expert view

When we test payment platforms, the staging environment is often the softest target in scope, and it frequently shares secrets with production because it was cloned from it. CRAFTY FALCON is simply industrialising a route that experienced testers have used for years. AI lowers the effort; it does not invent new weaknesses, it just finds old ones faster.

The re-targeting after remediation is, in my experience, the most common failure in incident response. Teams patch the entry point, reset a few passwords and declare victory, while a web shell, a rogue serverless function or a stolen token survives. CERT-In’s instruction to assume persistence and verify eradication forensically is exactly right.

I also like that the advisory treats fraud signals as security telemetry. The penny test is a gift to defenders: a tiny payment to a brand-new beneficiary followed quickly by a large one is a pattern that fraud and SOC teams can catch together if they share data. Too often they sit in separate silos.

The allow-list bypass deserves attention as well. IP allow-listing feels like a strong control, yet when the trusted range belongs to a shared service used by thousands of customers, it authenticates nobody. Cryptographic identity, such as mutual TLS or signed requests, is the fix.

What to do now

  1. Close the weekend gap. Check exactly what your SOC or MSSP does between Friday evening and Monday morning, and over bank holidays. Agree in writing who can isolate a host or revoke a key without waiting for approval. Lower alert thresholds in quiet periods, as CERT-In advises.
  2. Find and fence non-production. Run an external attack-surface sweep for test, UAT and staging hosts. Remove them from the internet or put them behind strong authentication, and rotate any credential that exists in both test and production (Cyber Essentials: firewalls, secure configuration).
  3. Detect the penny test. Build a joint fraud and SOC rule that flags a tiny payment to a fresh payee followed soon after by a large one, backed by holds, velocity limits and cooling-off periods.
  4. Replace IP trust with cryptographic trust. For partner and fetcher integrations, move to mutual TLS, signed requests or tightly scoped API keys. Validate every transaction server-side and add app attestation for mobile clients.
  5. Watch the cloud control plane. Centralise audit logs and alert on remote command execution and serverless changes by unexpected principals. Restrict egress from functions by default (Cyber Essentials: user access control).
  6. Patch internet-facing apps fast and watch for web shells. Set a short patching SLA, use WAF virtual patching in the gap, make deployment directories read-only and monitor file integrity (Cyber Essentials: security update management, malware protection).
  7. Verify eradication. After any incident, hunt for persistence, rotate every credential the attacker could have touched and keep watching for return visits.

Bottom line

The advisory concerns Indian victims, but the lesson travels: attackers with automated tooling will probe the weakest hours and the forgotten environments, and will come back if you only half finish the job. UK payment firms should test their weekend response, retire IP-based trust and make sure fraud and security teams are watching the same signals.

Sources