CERT-In, India's national cyber agency, says an AI-assisted actor it tracks as CRAFTY FALCON is attacking banks, NBFCs, fintechs, payment aggregators and crypto exchanges, and that it is going back to victims who thought they had cleaned up. The advisory, CIAD-2026-0058 dated November 4, 2026, describes attackers using public AI offensive tools to pivot from test environments into payment and disbursement APIs and move money at machine speed.
If you run coding agents, the part worth your time is the tooling and the entry point: free agentic pentest frameworks, plus the staging credentials that sit on developer machines. One related headline, about a "backdoored" ARTEX Docker image exposing 62 consoles, is not something we could verify. This post separates the two.
TL;DR
| Question | Answer |
|---|---|
| What happened? | CERT-In issued an updated advisory on CRAFTY FALCON, an AI-assisted actor abusing BFSI payment and disbursement APIs |
| Who is affected? | Banks, NBFCs, fintechs, payment aggregators, payment service providers, crypto exchanges and VDASPs |
| Which tools are named? | ARTEX family, PentAGI, Cairn, CyberStrikeAI |
| Is there a CVE or patch? | No CVE was cited in the coverage we read. The fixes are architectural |
| Is the backdoored ARTEX image confirmed? | No. We could not read the source article and found no corroboration |
| Does data leave my machine with Beam? | No. Beam stores locally; see the Beam section below |
What CERT-In actually said
We could not render CERT-In's advisory page itself (the fetch returned an empty shell), so the details below come from press coverage that quotes or paraphrases the advisory: BW Businessworld and Inc42. CERT-In also announced the advisory on X and listed it under the ID CIAD-2026-0058. Read the original on the CERT-In advisories page if it loads for you.
The reported points:
- The advisory updates an earlier warning from October 9 and says the campaign has escalated.
- CSIRT-Fin, CERT-In's finance team, keeps receiving reports of successful attacks on NBFCs and fintechs that had already been alerted.
- Several previously compromised organisations were hit again despite remediation.
- Some operations were timed for holidays, weekends and other thin-monitoring periods.
- Supporting infrastructure changes IP addresses often, which makes tracking harder.
- Public tools in use: the ARTEX family of LLM-based tools, PentAGI, the Cairn attack search engine and CyberStrikeAI.
CERT-In rates the activity as ongoing. Full indicators of compromise are reportedly in a restricted version shared with financial entities, so public detail is limited. No victim names or loss figures are given in the coverage we read.
The attack chain, step by step
The coverage describes several techniques rather than one fixed chain. Put together, they look like this.
- Find targets. The actor uses LLM-driven tooling and attack search engines to enumerate exposed assets and likely weak points. This is the same class of tool we described in the Mandiant write-up on agentic offensive frameworks.
- Enter through non-production. Attackers compromise internet-facing testing environments: user acceptance testing, staging and test systems. These tend to have weaker monitoring and, per the advisory, share credentials, access tokens and network connections with production.
- Pivot to production. Shared keys or network paths carry the attacker from staging into systems that handle money.
- Reverse-engineer the client. By decompiling financial applications and modifying client-side packages, the attackers issue API requests that look like they come from the legitimate app, defeating controls that rely on "only our app calls this."
- Test with tiny payments. CERT-In says micro-value transactions, as small as Rs 1, are used to confirm that an unauthorised flow works before larger transfers.
- Abuse settlement APIs. On payment aggregators, merchant settlement APIs are used to redirect funds. On crypto exchanges, stolen wallet keys are used to move assets out.
- Iterate at speed. The advisory points to large numbers of customised scripts with functionally similar variants, refined rapidly, as a sign of AI-assisted development. When a control blocks one variant, another appears.
None of this needs a zero-day. It needs a reachable test environment and a credential that was never separated from production.
Why previously cleaned victims get hit again
The most unusual claim in the coverage is the repeat targeting. CERT-In says organisations that had remediated, and in some cases had already received restricted advisories, were attacked again. The advisory cautions that incomplete remediation invites a second round, and it asks for comprehensive system clean-ups, forensic verification and continued threat hunting rather than treating one resolved incident as the end.
There are a few plausible reasons, though the coverage does not say which applied. A stolen token or shared key may have been left valid. A staging environment may have been rebuilt but still trusted by production. Or the attacker may have kept a map of the victim's APIs and simply re-ran the same automated playbook. Tooling that generates and refines many script variants makes a second attempt cheap, which is why defenders cannot rely on blocking a single known script.
For a developer team, the lesson is to rotate credentials as part of every incident closure, not only the ones you know were stolen, and to confirm that old environments no longer trust new ones.
The "backdoored ARTEX Docker image" headline: claimed vs. verified
The story that surfaced this advisory in our feed was a Hacker News (the publication) article whose headline pairs the CERT-In warning with a backdoored Docker image for ARTEX that "exposes 62 consoles to root access." We tried to read it and got HTTP 403, so we have only the headline and a short summary of the CERT-In half.
| Claim | Status | What we checked |
|---|---|---|
| CERT-In named CRAFTY FALCON in CIAD-2026-0058 | Confirmed by multiple outlets and CERT-In's own X post | BW Businessworld, Inc42, CERT-In on X |
| The actor uses ARTEX, PentAGI, Cairn, CyberStrikeAI | Reported by outlets attributing it to the advisory | Not seen in the raw advisory text |
| A backdoored ARTEX Docker image exists | Unverified | Headline only; search found no second source |
| 62 consoles exposed to root access | Unverified | Headline only; unclear whether this is exposed ARTEX operator consoles or victim systems |
We do not know who published the image, whether it is the official ARTEX build or a lookalike, or what "62 consoles" counts. If you ever pulled an ARTEX or similar agentic pentest image from a registry, the safe approach is the one you would use for any untrusted container, and it does not depend on this claim being true. We will update this post if a primary source appears. For the earlier ARTEX events, see the South Korea bank intrusions and CrowdStrike's Vapor Panda report.
Where this fits in the CERT-In series
This is the third CERT-In item we have covered. The October 9 advisory is the baseline that this one updates. Our October 16 post on CERT-In and agents under test covered a different advisory, in which AI agents run during evaluation read confidential records through leaked keys and over-permissive cloud roles. The common thread is plain: agents, hostile or well-meaning, succeed against credentials left in the wrong place.
What this means if you run AI coding agents
You are probably not a bank, but you may hold the same kinds of secrets on the same kind of machine.
- Separate staging from production credentials. CERT-In's own advice is to isolate testing and staging from production and eliminate shared credentials and API keys. On a developer laptop, that means no production keys in
.envfiles that your coding agent can read. - Rotate shared keys. If one key works in both environments, treat it as exposed to anyone who reaches either.
- Do not trust client-side checks. If your API trusts that requests come from your own app package, assume an attacker can imitate it. Validate transactions server-side.
- Watch for tiny-value probes. Small payments followed by larger ones, especially to new beneficiaries, are the reported signature. CERT-In recommends velocity controls and cooling-off periods for new beneficiaries.
- Monitor on weekends and holidays. The timing is deliberate.
- Treat pentest agents as untrusted software. Before running ARTEX-like, PentAGI-like or any agentic security tool, pin the image by digest, read the Dockerfile or build source, run it in an isolated network without your real credentials, and do not mount your home directory. If you pulled an image you cannot trace, assume anything it could read is exposed and rotate it.
- Review your own agents' reach. Check which directories and secrets your coding agents can read, and what they ran recently.
What Beam can and cannot do here
Beam does not protect bank payment APIs, and it cannot see a staging environment you do not run agents in. Where it applies is the developer machine.
- Its hook-based deny works for Claude Code and Codex PreToolUse: in enforce mode a workspace policy can block an agent action that reads
.envfiles or credentials. It is hook-based, not a kernel sandbox, and it is fail-open if cached policy is missing. - Beam's skill and MCP config scan uses 11 heuristics plus an MCP version-pin check. It is heuristic and will not tell you whether a Docker image is backdoored; it does not scan container images.
- Event data is redacted before storage and stays on your device.
You can see how the pieces fit in the landing page overview and how it works.
Frequently asked questions
What is CRAFTY FALCON?
CRAFTY FALCON is the name CERT-In gives to an AI-assisted financial threat actor in advisory CIAD-2026-0058, dated November 4, 2026. Per coverage of the advisory, it uses public AI offensive tools to find targets and abuse victims' own payment and disbursement APIs.
Which AI tools does CERT-In say the actor uses?
Per reporting on the advisory, the ARTEX family of LLM-based tools, PentAGI (an autonomous multi-agent penetration-testing system), the Cairn attack search engine and the CyberStrikeAI framework. All are publicly available.
Is there a backdoored ARTEX Docker image?
A Hacker News (the publication) headline mentions one, with 62 consoles exposed to root access. We could not read that article (HTTP 403) and found no second source or CERT-In text for the image claim, so treat it as unverified until you can read a primary source.
How do the attackers get into financial systems?
One described route is through non-production environments such as UAT, staging and test systems, using shared credentials, tokens or network paths to reach production. Another is reverse-engineering client-side packages to forge API requests.
What should developers who run coding agents do?
Keep staging and production credentials separate, never leave shared API keys where an agent or script can read them, rotate anything that was shared, and review what your own agents can reach. Pull the Docker image digest and source for any pentest tool before running it.
Does this affect me if I am not a bank?
The advisory targets BFSI entities, but the techniques (staging-to-production pivots, shared keys, scripted variants) apply to any team with payment or internal APIs. The same tooling is public.
Related reading
- November 2026 attacks timeline
- Mandiant on ARTEX and agentic offensive frameworks
- CERT-In: AI agents under testing read confidential records
- Wiz: AI-driven cloud attack anatomy
- CyberStrikeAI and the 44-agent Japan campaign
Details reflect the sources available on November 5, 2026, and the CERT-In advisory may be revised. Beam is a local prototype; its features and limits are as documented at the time of writing.