Crafty Falcon: Weaponized Pentest Agents Hit the Financial Sector

Key Takeaways

On November 4, 2026, India’s Computer Emergency Response Team (CERT-In), working through its financial-sector unit CSIRT-Fin, issued a critical advisory naming an AI-assisted, financially motivated threat actor “CRAFTY FALCON” [1][2][4]. The advisory reports that the actor attacks non-banking financial companies, digital lenders, fintech platforms, payment aggregators, payment service providers, and cryptocurrency exchanges, and that it steals money by invoking the victims’ own payment and disbursement APIs from inside their trusted infrastructure [1][3]. CERT-In attributes the activity to the use of four open-source AI offensive frameworks, one of which is now available only through unofficial mirrors: the ARTEX family of LLM-based tools, the PentAGI autonomous multi-agent penetration testing system, the Cairn “attack search engine,” and the CyberStrikeAI framework [1][2][3].

The advisory is significant less for any single technique than for what it adds to an existing record. Open-source agentic penetration testing frameworks, built for authorized security work, had already been documented outside authorized testing, including in state-aligned espionage using ARTEX [5][6] and in earlier financially motivated or criminal campaigns using CyberStrikeAI and Cairn [7][10]; CERT-In’s own October advisory had likewise flagged financially motivated intrusions using publicly available agentic tools [2]. What is distinctive about CRAFTY FALCON is the direct monetization of regulated financial institutions’ own payment APIs. CERT-In reports that the tools let the actor run attack chains autonomously, rapidly generate and refine custom scripts, adapt payloads to target responses, and rotate infrastructure within hours to days [2][3]. The interval between initial compromise and fraudulent transfer has also shortened, according to CERT-In, which treats its October advisory as covering the same activity [1].

Several conclusions follow for security leaders. Payment and disbursement APIs that trust requests based on network origin are the primary monetization path, so controls that verify the transaction itself matter more than perimeter allow-lists. Non-production environments, cloud management planes, and long-lived static API credentials are the recurring entry and pivot points. Organizations that remediated after earlier advisories have been re-targeted, which public reporting attributes at least in part to incomplete eradication [2][3][4]. Finally, the tools themselves are now a supply-chain hazard: a widely forked copy of ARTEX was found to ship a Docker image containing an unauthenticated root backdoor, putting any team that deployed it at risk [3].

Background

The CERT-In Advisories

CERT-In’s November 4 advisory updates an earlier warning dated October 9, 2026, that addressed intrusions against non-banking financial companies, digital lenders, fintechs, payment service providers, and wallet operators [1][3]. The October advisory described compromise of internet-facing applications, theft of payment-gateway and partner-bank credentials, and fund-transfer API calls made from allow-listed infrastructure, which allowed the attacker to bypass know-your-customer checks, beneficiary verification, and transaction limits [1]. It also documented log deletion, tampering with endpoint detection and response tools, and anti-forensic cleanup [1]. The November update gave the actor a name, raised the severity to critical, and explicitly tied the campaign to AI tooling [1][2].

The public versions of these advisories are limited in detail. They do not name affected institutions, state the number of incidents, quantify losses, or attribute CRAFTY FALCON to any nation or known group. CERT-In states that infrastructure fingerprints, indicators of compromise, and detection rules were distributed to financial entities at restricted handling levels [2]. This research note was prepared from public reporting on the advisory rather than the restricted text. All CERT-In details in this note are therefore as reported by the cited outlets ([1]–[4]), which agree on the details checked during preparation, and readers with access to the restricted version should treat it as authoritative where the two differ.

The Four Frameworks

Each of the tools named by CERT-In has a public history that predates CRAFTY FALCON, and three of the four had already been documented in malicious use. The table below summarizes what public reporting establishes about each.

What these frameworks share is a design that converts a target and an objective into a self-directed sequence of reconnaissance, exploitation, and post-exploitation steps. They reduce the specialized skill required to execute multi-stage intrusions and allow a small number of operators to run many concurrent operations. CrowdStrike reported that in a single VAPOR PANDA intrusion the planning agents consumed on the order of 1.4 billion input tokens, which illustrates both the scale of autonomous reasoning involved and a potential detection signal for model providers [5]. NorForge’s analysis of the Cairn campaign, as reported by The Hacker News, estimated roughly five dollars per task including failures and an overall success rate near 10 percent, while researcher Fagerland separately told Reuters that the campaign’s model spend came to approximately fifty dollars per successful break-in [7]. These economics suggest that low per-attempt success rates constrain attackers far less when attempts are cheap and parallel.

Security Analysis

How CRAFTY FALCON Converts Access into Money

The distinguishing feature of this campaign is its monetization path. Rather than deploying ransomware or exfiltrating data for resale, CRAFTY FALCON uses the financial institution’s own transaction machinery against it. Public reporting on the advisories describes an operational pattern in which the actor obtains credentials for payment-aggregator or partner-bank APIs, then calls fund-transfer endpoints from infrastructure the institution already trusts [1][3]. Because many lending and payment architectures enforce business controls in upstream application layers and treat calls from allow-listed hosts as pre-validated, invoking the API directly can skip loan creation, KYC, sanctions screening, beneficiary verification, balance checks, and per-transaction limits [3]. The actor reportedly validates each new fund flow with micro-value test transfers, sometimes as small as one rupee, before moving larger sums to mule accounts spread across multiple banks [1][3]. Merchant settlement APIs at payment aggregators are a second documented target [1].

This pattern exposes an architectural assumption common in financial services: that network location is a proxy for authorization. CERT-In also reports that the actor bypasses IP allow-lists by routing traffic through shared third-party fetcher pools, such as content-acceleration and app-store review services, whose address ranges institutions had permitted [1]. Where trust is anchored to IP ranges shared with other tenants, an attacker who can originate traffic from those ranges inherits the trust. The broader implication is that controls designed for a world of manual fraud, where each attempt carried meaningful cost to the attacker, may not hold when an agent can probe settlement logic continuously and at low marginal cost.

Entry and Pivot Points

The intrusion techniques reported by CERT-In are individually familiar. This suggests that, in this campaign, the frameworks’ value lay in chaining known weaknesses quickly rather than in discovering novel ones. Reported initial access vectors include vulnerable internet-facing applications and exposed APIs, long-lived static or hard-coded API tokens, plaintext credentials in configuration files and source code, remote services without multi-factor authentication, and forged commits to source repositories [3]. The actor also reverse-engineers mobile and client application packages to craft unauthorized API calls through modified clients [1][3], and exploits newly disclosed file-upload and deserialization flaws in PHP and Node.js applications to plant web shells [1][3].

Two pivot patterns deserve particular attention. First, the actor uses publicly reachable user-acceptance, staging, and test environments to harvest credentials, tokens, or network paths shared with production [1][3]. Non-production environments in many organizations receive weaker monitoring and patching while holding real secrets, which makes them attractive starting points for an autonomous agent that enumerates everything reachable. Second, the actor abuses cloud management services, specifically AWS Systems Manager and AWS Lambda, to execute commands and deploy malicious files [1]. Control-plane abuse of this kind blends with legitimate automation and may not be visible to host-based tools, which the actor reportedly tampers with in any case [1].

Speed, Persistence, and Timing

CERT-In’s reporting points to three operational characteristics that compound the risk. The interval between compromise and fraudulent transfer has decreased [1], a trend consistent with Microsoft’s observation that ARTEX-driven attacks by Storm-0940, in an unrelated campaign, achieved privileged cloud access in some cases less than three hours after initial targeting [6]. The actor times operations for holidays, weekends, and other low-monitoring periods [1][2]. And it has continued to target institutions that had already received restricted advisories and performed remediation, which public reporting attributes in part to incomplete cleanup [2]. Taken together, these behaviors suggest that a detection-and-response model built on business-hours triage and declared-closed incidents will lag an attacker operating at machine speed.

The rapid iteration of many similar custom scripts, which CERT-In treats as consistent with AI-assisted development [3], also affects detection engineering. Signature-based indicators tied to specific script hashes or infrastructure are likely to decay quickly; CERT-In itself notes that indicators rotate while techniques remain consistent [3]. Behavioral detection anchored to the transaction layer and the cloud control plane is likely to be more durable than detection anchored to artifacts.

The Tools as a Supply-Chain Hazard

The ARTEX ecosystem illustrates a second-order risk. After the developer removed the original repository, mirrors proliferated on GitHub and Docker Hub [3]. Independent researcher Badbyte found that one copy with 2,449 stars and more than 600 forks altered a single line in its docker-compose file to pull a Docker Hub image containing a hidden function in the login handler; if the CAPTCHA field begins with a secret marker, the remainder is executed through sh -c as root and returned before any credential check [3]. The image had been downloaded about 9,000 times, and 62 consoles were observed serving the backdoored build between November 2 and 4, 2026, out of 1,645 hosts serving an ARTEX console at that time [3]. NorForge separately reported that open Cairn panels exposed victims’ credentials and keys, and that one cluster exposed its operators’ own SSH logins to their staging servers [7].

For defenders, this has two implications. Any red team, managed security provider, or internal researcher who deployed an unofficial ARTEX build may have handed a root shell, and whatever credentials and target data the console holds, to an unknown party. More generally, offensive AI consoles concentrate high-value secrets, including model API keys, harvested target credentials, and discovered vulnerabilities, which makes them attractive targets in their own right. The NorForge finding that hundreds of secrets were stored in exposed Cairn panels, 11 percent of which were still valid, reinforces this point [7].

Limits of the Public Record

Several uncertainties should shape how organizations act on this advisory. CRAFTY FALCON’s identity, location, and relationship to other actors are not stated publicly [1]. It is not clear from public reporting whether the actor uses all four frameworks in combination or whether CERT-In observed different tools in different intrusions. No public evidence links CRAFTY FALCON to VAPOR PANDA, Storm-0940, or the Cairn clusters described by NorForge, and none should be inferred from shared tooling, since the frameworks are openly available. The scale of losses has not been disclosed. These gaps do not reduce the urgency of the guidance, but they do mean that organizations outside India should treat the advisory as evidence of a transferable technique rather than as a geographically bounded threat.

Recommendations

Immediate Actions

Financial institutions, payment providers, and fintechs, particularly those operating in or connected to the Indian payments ecosystem, should treat the campaign as active. Security teams should review fund-transfer, disbursement, and merchant-settlement API logs for calls that lack a corresponding upstream business event such as a loan creation or approved payout, and for micro-value transfers followed by larger transfers to new beneficiaries [1]. Static and long-lived API credentials for payment aggregators and partner banks should be rotated, with priority given to any credential that has ever been stored in source code, configuration files, or a non-production environment [3]. Cloud audit logs should be reviewed for unexpected AWS Systems Manager command execution and Lambda function creation or modification, and those capabilities restricted to approved principals [1].

Organizations that remediated after the October advisory should not assume eradication. CERT-In recommends forensic verification after incidents and real-time monitoring of cloud audit logs [1]. Staffing and alert thresholds should be adjusted for weekends and holidays [1][2]. Any team that has deployed ARTEX from a mirror or third-party Docker image should isolate the host, treat it as compromised, and rotate every credential and model API key it held [3]. Indicators and detection rules distributed in CERT-In’s restricted advisories should be applied by entities that received them, and suspicious activity reported to CERT-In and CSIRT-Fin [1][2].

Short-Term Mitigations

Over the following weeks, the priority should be moving trust from network location to verified transactions. CERT-In recommends server-side validation of transactions, API request signing, app attestation, and certificate pinning [1]. Beyond CERT-In’s recommendations, where IP allow-lists protect payment APIs, organizations should determine whether any permitted range is shared with other tenants and replace such allow-listing with identity-bound controls such as mutual TLS and short-lived, scoped credentials. Payment controls should include beneficiary cooling periods, velocity rules, maker-checker approval for merchant settlements, and multi-signature approval for cryptocurrency withdrawals [1].

Non-production environments should be removed from the public internet where possible and isolated from production, with no shared credentials, databases, or network paths [1]. Patching of internet-facing applications should be accelerated, with emphasis on file-upload and deserialization flaws in PHP and Node.js stacks [1]. Detection teams should add behavioral analytics that are less sensitive to rapidly rotating indicators, including unusual volumes of failed or enumerating API calls and execution of known offensive framework containers. CERT-In also advises monitoring LLM API usage, noting that such traffic from servers or non-development hosts may signal an attack rig or planted operator console [4]; this signal is relevant where agent components run on compromised hosts rather than on attacker infrastructure. In addition to CERT-In’s guidance, deception assets such as canary credentials planted in non-production configuration files can provide early warning of agent-driven credential harvesting.

Strategic Considerations

Over the longer term, the CRAFTY FALCON campaign argues for treating autonomous offensive AI as a baseline assumption in threat models for financial infrastructure. Controls that relied on attacker cost and effort, such as business logic that does not limit or flag high request volumes and trust in pre-approved network paths, should be re-evaluated against adversaries that, as the VAPOR PANDA and Cairn cases show, can run large numbers of low-cost attempts in parallel [5][7]. Institutions should test their own payment and settlement APIs with authorized agentic tooling under controlled conditions so that they find logic gaps before attackers do, while sourcing that tooling from verified upstream repositories, pinning image digests, and running consoles in isolated environments with no exposure to the internet.

Governance of offensive AI tools inside the enterprise also deserves attention. Security testing programs, managed service providers, and third-party assessors should be asked which agentic frameworks they use, where those tools obtain their models and images, and how harvested credentials are stored and destroyed. Regulators and industry bodies may wish to consider whether incident reporting should capture AI tool involvement in a structured way, since the current public record makes it difficult to measure how much of the observed acceleration is attributable to automation. Finally, information sharing across jurisdictions is warranted. These frameworks have been documented in campaigns spanning many jurisdictions: ARTEX against organizations in at least 14 countries [5], Cairn primarily against targets in the United States, Japan, and Australia [7], and CyberStrikeAI-linked FortiGate exploitation across 55 countries [8][10]. The techniques CERT-In describes are not specific to Indian payment rails.

CSA Resource Alignment

CSA’s research report Using AI for Offensive Security [13] examined the same capabilities now observed in misuse. It examined how LLMs and AI agents can automate reconnaissance, scanning, vulnerability analysis, exploitation, and reporting, and it emphasized human oversight, governance, and ethical guardrails for organizations adopting such tools. The CRAFTY FALCON and ARTEX cases show the same capability operating without those guardrails, and they extend the report’s governance concerns to the integrity of the tools themselves, as the backdoored ARTEX image demonstrates. Organizations building internal AI-assisted testing programs should apply the report’s guidance alongside the supply-chain precautions described above.

The Agentic AI Red Teaming Guide [14] provides structured methods for testing agent systems across categories including critical system interaction, impact chain and blast radius, multi-agent exploitation, and supply chain and dependency attacks. Financial institutions that deploy their own agents for payments or lending operations should use these procedures to verify that an agent, or an attacker who controls one, cannot reach fund-transfer functions without independent transaction-level authorization. The guide’s emphasis on untraceability and forensic readiness also addresses the log deletion and anti-forensic behavior that CERT-In reports.

CSA’s State of Cloud and AI for Financial Services 2026 [15] survey identifies third-party risk and the governance of non-human identities among the sector’s pressing challenges as AI agent and cloud adoption accelerates. CRAFTY FALCON’s reliance on stolen partner-bank and aggregator API credentials and on cloud control-plane abuse is a concrete instance of those risks being exploited.

For control implementation, the AI Controls Matrix (AICM) v1.1 [16] can be used to map the relevant controls. Its Identity and Access Management domain addresses the static credentials and network-anchored trust exploited in this campaign; its Threat and Vulnerability Management and Application and Interface Security domains address the internet-facing application and API weaknesses used for entry; and its Logging and Monitoring and Security Incident Management domains address detection, log integrity, and verified eradication. Threat modeling teams can use MAESTRO [17], CSA’s layered agentic AI threat modeling framework, to reason about both sides of this problem: the attacker’s agent stack and the institution’s own agentic payment workflows.

References

[1] MediaNama. “CERT-In: AI threat actor targeting payment APIs for fund transfer.” MediaNama, November 5, 2026.

[2] Inc42. “CERT-In Flags AI-Driven Cyberattacks On Indian BFSI.” Inc42, November 5, 2026.

[3] The Hacker News. “CERT-In Flags AI-Driven Attacks as Backdoored ARTEX Exposes 62 Consoles to Root Access.” The Hacker News, November 5, 2026.

[4] Elets BFSI. “CERT-In warns Indian fintech firms of active AI-driven Crafty Falcon campaign.” Elets BFSI, November 5, 2026.

[5] CrowdStrike. “VAPOR PANDA Uses AI-Driven ARTEX to Grow Global Espionage Campaign.” CrowdStrike Blog, October 29, 2026.

[6] Microsoft Threat Intelligence. “AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise.” Microsoft Security Blog, October 21, 2026.

[7] The Hacker News. “Hackers Use Autonomous AI Agents to Breach Company Websites, Target Over 1,200 Sites.” The Hacker News, October 20, 2026.

[8] The Hacker News. “Open-Source CyberStrikeAI Deployed in AI-Driven FortiGate Attacks Across 55 Countries.” The Hacker News, March 3, 2026.

[9] Team Cymru. “Tracking CyberStrikeAI: AI-Native Offensive Tools & MSS Ties.” Team Cymru, March 2, 2026.

[10] The Hacker News. “AI-Assisted Threat Actor Compromises 600+ FortiGate Devices in 55 Countries.” The Hacker News, February 21, 2026.

[11] VXControl. “PentAGI.” GitHub, accessed November 5, 2026.

[12] Help Net Security. “PentAGI: Open-source autonomous AI penetration testing system.” Help Net Security, April 22, 2026.

[13] Cloud Security Alliance. “Using AI for Offensive Security.” CSA, August 2024.

[14] Cloud Security Alliance. “Agentic AI Red Teaming Guide.” CSA, May 2025.

[15] Cloud Security Alliance. “The State of Cloud and AI for Financial Services 2026.” CSA, June 2026.

[16] Cloud Security Alliance. “AI Controls Matrix v1.1.” CSA, June 2026.

[17] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” CSA Blog, February 6, 2025.