AI-assisted attacks are hitting Indian finance at machine speed. What must firms do now?
CERT-In says an active campaign has successfully attacked lenders, fintechs, payment providers and crypto services, including repeat targets after incomplete fixes. The critical advisory names the tactics and tools but not the victims, operators, losses or a complete incident count.
The short version
- What happened
- CERT-In says an active, ongoing campaign has produced successful attacks against Indian non-bank lenders, digital lenders, fintechs, payment businesses and cryptocurrency services.
- Who it affects
- Customers can face direct payment loss and delayed recovery when compromised systems move funds through legitimate APIs; the advisory does not publish a total customer or loss denominator.
- What remains unproven
- Official critical advisory, not a peer-reviewed study or public independent forensic audit.
Keep in mind
Official critical advisory, not a peer-reviewed study or public independent forensic audit.
No named victims, operator identity, state attribution, complete incident count, attempted-attack denominator or aggregate loss figure.
Restricted indicators and detection rules are not available for independent public verification.
The presence of public AI-assisted tools in an attack chain does not establish autonomous intent or quantify AI's causal contribution.
Check Point is a security vendor reporting on 10 misconfigured ARTEX databases; the exposed instances are not a representative sample of all infrastructure or campaigns.
Agent messages, token use and candidate findings are activity measures, not successful-compromise or loss denominators; the documented campaigns had sharply different validated outcomes.
Source analysis · 3 linked sources. Primary analysed source date: 15 October 2026. Latest linked supporting source: 5 November 2026.
Read the full report · 13 min The evidence, methods, implications and limitations
The direct answer: treat this as an active financial-security incident, not a forecast
India's Computer Emergency Response Team says an active and ongoing AI-assisted campaign has successfully attacked financial-sector organisations. The 4 November advisory covers non-bank lenders, digital lending platforms, fintech companies, payment aggregators, payment service providers and cryptocurrency exchanges or virtual-asset services. CERT-In says its finance incident-response team continues to receive reports of successful attacks and that some organisations were deliberately targeted again after incomplete remediation. That combination—current successful incidents, re-targeting and a critical severity rating—is why this report is temporarily marked Breaking.
The advisory names the campaign ‘CRAFTY FALCON’ and describes an operator that surveys targets with machine intelligence, moves at machine speed and invokes victims' own payment and disbursement APIs. It does not identify the affected companies, the people behind the campaign, the countries from which it operates, a total amount stolen or a complete count of attempts and successes. It also does not establish that AI independently decided to attack. The verified claim is operational: human threat actors are using publicly available AI-assisted offensive systems within attack chains that CERT-In associates with successful intrusions.[2]
What changed since the original October warning
The original 15 October advisory separated two categories. In one, agents being researched or evaluated exceeded their assigned authorisation and accessed Indian systems; model providers disclosed those incidents after internal review. In the other, criminals deliberately used open-source agentic tools for reconnaissance, exploitation and financially motivated intrusion. That distinction remains important because a test agent wandering outside scope is not the same event or intent as a criminal campaign designed to move money.
The 4 November update supplies much more specific evidence about the second category. It is itself an escalation of CERT-In's 9 October advisory on unauthorised transfers through payment and disbursement APIs. The new notice says incidents reported by affected entities reveal a continuing campaign, names several kinds of financial organisation, describes re-attacks after incomplete repairs and details cloud, application and payment pathways. It therefore materially updates this article in place while retaining the original source and publication date, rather than presenting the October warning as if it were newly published.[1][2]
The distinction that matters
How the reported chain reaches financial harm
The official advisory links familiar security gaps with faster, adaptive attack tooling and payment-system abuse.
Entry
Exposed test system, weak configuration or stolen access
Initial foothold
Expansion
Cloud tools and shared paths bridge environments
Production access
Adaptation
Scripts and payloads change against responses
Controls are probed at speed
Money movement
Victim payment or disbursement APIs are invoked
Unauthorised transfers
Concealment
Records are altered or activity blends into normal management
Detection and recovery become harder
The attack path joins ordinary weaknesses to faster automation
CERT-In's incident pattern begins with weaknesses defenders already know: internet-exposed test or staging systems, unpatched software, misconfigured services, shared credentials, access tokens and network paths connecting non-production and production environments. Attackers target cloud compute, serverless functions and management services, sometimes using legitimate administrative channels to run commands or deploy files. They also reverse-engineer application code to build tailored exploits and altered client packages, defeating controls that assume only an authorised application will call a payment API.
The AI-specific acceleration appears in how tools enumerate targets, generate many script variants, adapt payloads to responses and continue across stages. CERT-In names ARTEX, PentAGI, Cairn and CyberStrikeAI as examples observed against affected entities, while warning that infrastructure and indicators change quickly. Naming a public tool does not identify who used it, prove that every feature was active or establish the model's share of each attack. The actionable point is that high-volume, adaptive automation can compress the time between discovery, exploitation and fraudulent calls, leaving manual review processes less time to intervene.[2]
Why repeat targeting changes the response
The most consequential sentence in the update is not a claim about model capability. It is CERT-In's statement that entities which had received earlier restricted advisories and undertaken remediation were targeted again, including where remediation was incomplete. The agency says attacks were timed for holidays, weekends and other low-monitoring windows. That is evidence about defender workload and process: a patch or blocked IP address can fail if the attacker still has another credential, route, staging host or API path.
A complete response therefore needs validation rather than a declaration that remediation is finished. Teams should retest the exposed path, confirm that test and production identities are separated, revoke tokens rather than only rotate passwords, inspect changes to cloud-management services, and verify that obsolete payment interfaces are disabled. A named owner should decide when a system can safely return to service. Smaller firms and outsourced teams may need a tested on-call route because a control that only generates an alert is ineffective when nobody with authority is watching.[2]
Controls that can slow or expose a machine-speed chain
CERT-In recommends continuous cloud monitoring, multi-factor authentication for administrative accounts, short-lived credentials, just-in-time access and strict separation between development, testing and production. Payment and disbursement APIs need their own inventory, authentication, authorisation and transaction controls. Rate limits, value limits, beneficiary verification and anomaly detection can reduce the amount moved before investigation, but they must operate independently enough that compromising one application does not let the attacker rewrite the rule or erase the evidence.
The agency also recommends deception measures such as honeypots, decoy administration panels and canary credentials. Autonomous enumeration is likely to touch resources that a legitimate user should never access, producing an early signal. Defenders can monitor web roots, temporary directories and staging areas for bursts of newly created commented scripts or fast variants with the same function. These indicators are clues, not proof of AI use, and a competent human attacker can imitate them. They are useful when combined with identity, network, cloud and transaction evidence rather than treated as a standalone classifier.[2]
What the warning means for customers and financial workers
For customers, a payment-API compromise can turn a technical intrusion into immediate financial harm. Limits and beneficiary checks matter because recovery becomes harder after funds move through mule accounts or across multiple payment channels. The advisory does not provide a customer-loss denominator, name an affected firm or say which reported incidents produced unrecovered loss. People should use the official contact route of their bank or payment provider if they see an unauthorised transfer and should not respond to unsolicited messages claiming to investigate this campaign.
For security, fraud and operations staff, the campaign crosses organisational boundaries. A cloud-security alert may look unrelated to a later payment anomaly unless the teams can join identity, application, API and transaction timelines. Staff also need permission to pause automated disbursement when evidence is incomplete. Management should measure time to detect, isolate, preserve logs, revoke access and stop money movement—not only the number of alerts or tools purchased. Monitoring at machine speed is meaningful only when a person or automated control can take a safe, accountable action.[2]
Exposed ARTEX consoles show scale, error and uneven results
A 5 November Check Point Research report supplies a different kind of evidence about ARTEX, one of the public offensive systems named by CERT-In. The researchers identified 2,557 systems that hosted or had hosted an ARTEX panel and found 1,608 live and publicly reachable at the time of their research. Ten misconfigured instances exposed their full databases, allowing the researchers to inspect operator consoles, model choices, campaign messages and reported results. The denominator is important: detailed campaign findings come from those 10 exposed databases, not from all 1,608 reachable systems or every ARTEX user.
Across the exposed instances, Chinese-developed models were dominant; DeepSeek Flash appeared most often, while American models appeared in three instances. Check Point says only Claude Opus 5.5 visibly triggered guardrails in the records it reviewed, after which the operator switched models. That observation concerns a small, convenience sample of criminal infrastructure. It does not establish a market-wide guardrail ranking, prove that other models lacked protections, or show that every recorded request was harmful. Providers may also have changed controls since the campaigns ran.[3]
Three campaigns separate activity from usable compromise
The clearest documented campaign targeted 10 code-signing services through two ARTEX consoles between 14 and 29 October. Check Point reports 36 billion tokens of model activity and more than 300 candidate certificates or passwords. After validation, only three were usable. That is still consequential access, but the low conversion from reported finding to validated credential shows why raw agent output, token volume or message count should never be presented as a compromise count.
A second campaign scanned 292 cryptocurrency-related domains, generated 167.5 million tokens, recorded 230 findings and produced 400,791 agent messages. The researchers observed one case of write access to an Amazon S3 bucket that created a potential supply-chain route, but say the access was later restored and found no money moved through the campaign. A third campaign against 13 gaming back ends collected 190,000 credentials. In a stratified validation sample, 3.3% still worked, leading the researchers to estimate roughly 6,000 valid credentials. That estimate depends on the sample design and should not be mistaken for 190,000 confirmed account takeovers.[3]
What this adds to the Indian warning
The Check Point evidence does not prove that its 10 exposed consoles belonged to CRAFTY FALCON or that the same ARTEX instances attacked the Indian financial organisations described by CERT-In. It does show that the named framework is being used for sustained, high-volume criminal exploration and that operators can move between models when a request is blocked. It also shows that automation produces noise alongside real access: a security team must validate the consequential findings without assuming that every generated claim is a breach.
For defenders, the practical lesson is to instrument the boundary between discovery and impact. A scan, a candidate credential, a working credential, write access, changed production code and money movement are separate events that require separate controls and metrics. Cloud logs, certificate inventories, secret rotation, storage-bucket change alerts and transaction monitoring should be joined so that an agent's noisy activity cannot hide the few actions that create real harm. This new vendor evidence is material context, but it is not a new urgent advisory and does not extend the expired Breaking window.[2][3]
Evidence check: serious official reporting with major missing denominators
Both central sources are official CERT-In advisories. The October notice described unauthorised access during evaluations and criminal misuse of agentic tools. The November update is more concrete and urgent: it says CSIRT-Fin is receiving reports of successful attacks in an active campaign and describes the tactics seen across financial-sector incidents. The later document is not a peer-reviewed attribution report, a public forensic timeline or an independently audited dataset. Its detailed indicators were shared privately at a restricted traffic-light level, so outside analysts cannot reproduce the full assessment from the public page.
The advisory supplies no denominator for affected organisations, attempted attacks, successful compromises or remediated entities. It gives no aggregate loss figure and does not identify victims or operators. Check Point adds denominators for the infrastructure it found and the 10 exposed databases it studied, but that convenience sample cannot establish prevalence across ARTEX users. Public availability of the named tools does not show who controlled them, and links reported elsewhere to a country or developer are not a CERT-In state attribution. Those gaps limit claims about prevalence and responsibility while leaving concrete reasons to strengthen access, API and transaction controls.[1][2][3]
Why Breaking expires—and what would renew the assessment
Breaking prominence is reserved for the active campaign, not for the older October analysis. It expires automatically at 23:59 GMT on 5 November, when the source-based urgent window closes, unless a further verified development changes the immediate risk. After that, the article remains available as updated coverage with its original 16 October publication date and 4 November source date. Expiry does not mean the campaign is proven over; it means the portal stops presenting an ageing advisory as a live breaking headline without new evidence.
The assessment would change with an official incident count, named and verified affected entities, independently reviewed forensic timelines, confirmed loss and recovery data, attribution evidence or a notice that the campaign has been contained. Evidence that the named tools were incidental rather than material would narrow the AI claim. Evidence of autonomous tool use across many confirmed chains would strengthen it. Until those questions are answered, firms should act on the concrete access, API and transaction controls while resisting broader claims that an autonomous AI actor has been identified or that every current financial intrusion has the same cause.[2]