Threat actors are using an open-source, AI-native attack framework to move from an initial foothold to unauthorized disbursements through a bank’s own payment APIs. For India’s financial sector, the defence must shift from blocking addresses to detecting behaviour – and from trusting the network to verifying every transaction.

Only days ago, CERT-In warned that financially motivated threat actors were deploying publicly available agentic AI tools to compromise Indian organizations, compressing the time between initial access and impact from days to hours.

The warning now has a name and a target.

CSIRT-Fin has identified active exploitation campaigns against financial institutions, digital lending platforms and payment service providers in which attackers are deploying CyberStrikeAI, an open-source, AI-native offensive security framework that couples large language model (LLM) orchestration with an autonomous command-and-control (C2) infrastructure.

The end point of these campaigns is not stolen records or encrypted servers. It is money leaving the institution – disbursed through internal payment APIs that the organization itself trusts.

That end point should change how the sector thinks about this threat.

What the advisory reveals: An attack framework built for autonomy

CyberStrikeAI connects offensive tooling pipelines to public and private LLM backends, with Alibaba DashScope and DeepSeek among those observed. Autonomous agents parse target responses in real time, make contextual decisions, execute privilege escalation scripts, deploy web shells and orchestrate API abuse from within network perimeters that are already whitelisted.

The result is an attack chain – reconnaissance, privilege escalation, lateral movement and, finally, fraudulent fund disbursement – coordinated largely by software rather than by a human operator deciding each next step.

The supporting tooling is engineered for reach and stealth. Its implants are compiled Go binaries that run on both Linux and Windows. They beacon over HTTP/HTTPS, raw TCP and WebSockets, predominantly on TCP port 8080, with payloads protected by AES-256-GCM encryption. Initial execution frequently leaves little on disk, relying on Bash reverse shells, netcat one-liners and PowerShell download cradles.

The C2 infrastructure is also built to resist scrutiny. Listeners answer unauthorized probes with deceptive "method not allowed" and "404 Not Found" responses, and management panels present self-signed certificates that impersonate legitimate services such as update.microsoft.com.

The indicator set accompanying SISA’s advisory runs to nearly 400 C2 IP addresses, alongside malicious file hashes and a dedicated C2 domain. That scale is itself a signal: this is infrastructure that can be stood up, abandoned and replaced quickly.

SISA’s perspective: The perimeter has become the attacker’s cover

CyberStrikeAI is not significant because it uses novel exploits. Much of its delivery relies on familiar techniques. It is significant because it combines autonomy, speed and a direct financial objective – and because it exploits an assumption that many financial institutions still make about their internal environments.

This creates four challenges for defenders.

First, network trust is being turned against the institution. In many organizations, internal payment and disbursement APIs are protected primarily by where a request comes from. If it originates from an approved server or a whitelisted segment, it is trusted. CyberStrikeAI orchestrates API abuse from inside those perimeters. Once an agent controls a trusted host, its call to a disbursement endpoint can be indistinguishable from a legitimate one.

Second, the attack chain moves faster than sequential response. When agents interpret results and choose their next action in real time, the gap between a first suspicious event and a completed fraudulent transfer can shrink to hours. A security operation that depends on manual triage, ticket-based escalation and next-day investigation may discover the intrusion only after the money has moved.

Third, static indicators are decaying faster than ever. Blocking known C2 addresses remains necessary, but it is a lagging defence against infrastructure that rotates cheaply. What does not change as easily is how the tool behaves: its protocol headers, fixed communication paths, beaconing patterns, TLS fingerprints and its dependence on outbound AI services.

Fourth, the attacker’s AI leaves a trail – if anyone is looking. Because the agents depend on external LLM backends, compromised systems may communicate with public AI APIs. For a payment server or a core banking host, there is rarely a legitimate business reason to call DashScope or DeepSeek. Outbound LLM traffic from a server enclave is therefore a high-value detection signal that few organizations currently monitor.

For India’s financial sector, the consequence is direct and often irreversible financial loss.

Digital lending platforms and payment service providers are built to disburse funds quickly, and real-time payment rails mean that money can move beyond recovery within minutes. An attacker who reaches a disbursement API does not need to exfiltrate data or negotiate a ransom. The fraud is the attack.

This also blurs a line that many institutions still draw between cybersecurity and fraud management. A fraudulent disbursement executed through an abused API is both a security incident and a payment fraud event, and it must be detected, contained and investigated as both.

From blocking indicators to breaking the kill chain: What organizations must do now

The advisory’s recommendations provide a strong starting point. From SISA’s perspective, they are most effective when organized around a single objective: denying the attacker every stage between initial footprint and the transfer of funds.

1. Contain the known threat immediately

Ingest the indicators and hunt backwards.

The C2 IP addresses and domains in the advisory should be loaded into firewalls, web application firewalls, secure web gateways and enterprise DNS resolvers without delay.

Blocking alone, however, does not answer the more important question: has this activity already occurred? Organizations should run a 90-day retrospective hunt across SIEM and NetFlow archives for historical connections to the listed C2 addresses, periodic beacons to external destinations on port 8080, and URI requests matching /check_in, /tasks and /upload.

Any asset showing corroborated indicators should be isolated immediately, its volatile memory preserved for forensic analysis, and the incident reported to CERT-In and the relevant sector response team within mandated timelines.

2. Detect the behaviour, not just the infrastructure

Build detections around what the tool cannot easily change.

Network sensors should carry signatures for the framework’s protocol anomalies: the CSB1 raw TCP marker, the X-Implant-Token and X-Session-Token headers, the hardcoded truncated user-agent string, and the known JA3S TLS fingerprint. These traits remain useful even when the underlying C2 addresses have changed.

Govern outbound AI traffic as a security control.

DNS and proxy telemetry should be monitored for unexpected traffic to public LLM endpoints, especially from servers. API keys for AI services should be issued only through designated internal AI gateways, so that any direct call from a production host stands out as an anomaly.

Correlate signals at machine speed.

An unusual outbound connection, a new binary in a temporary directory and an atypical call to a payment API may each appear minor in isolation. Agentic SOC capabilities that correlate network, endpoint, identity and application signals in real time can connect those events into a single incident while analysts retain oversight of containment decisions.

3. Take away the attacker’s room to operate

Make egress the exception, not the default.

Server enclaves should operate under default-deny egress policies. Outbound traffic on TCP port 8080 and non-standard high ports should be blocked, with server-initiated external connections restricted to explicitly approved destinations. This single control disrupts both C2 beaconing and the agent’s access to its LLM backend.

Prevent untrusted code from running.

Application allow-listing, such as Windows Defender Application Control or AppLocker, should prevent unauthorized binaries from executing out of /tmp/, /dev/shm/ or user temporary folders on critical servers. PowerShell Constrained Language Mode and ScriptBlock Logging should be enforced on Windows, while Linux process monitoring should flag interactive shell redirection and unexpected netcat execution.

Test the chain before an attacker does.

Traditional vulnerability assessments should be complemented with controlled, AI-assisted penetration testing and adversary simulations that replicate the path from initial access to payment API abuse. The question to answer is not only "what is vulnerable?" but "how far could an autonomous agent get from here?"

4. Stop trusting the network to authorize money movement

Re-authenticate every request to a payment API.

Internal payment and disbursement API gateways should enforce mutual TLS, strict IP allow-listing and velocity checks. Most importantly, disbursement endpoints should require step-up, out-of-band authorization for high-risk or anomalous transactions rather than relying on network-level trust alone.

Bring security and fraud operations together.

Transaction monitoring should look for anomalous disbursement volumes, new or unusual beneficiaries, off-hours activity and API calls from unexpected service identities. Those signals should flow into the same incident workflow as security alerts, so that a suspicious transfer and a suspicious beacon on the same host are recognized as one event.

Validate payment controls continuously, not periodically.

An API that was secured at the last audit may since have been exposed, and a service account may have accumulated excessive permissions. Financial institutions should maintain a current inventory of payment APIs and the non-human identities that call them, and continuously validate those controls against PCI DSS, RBI and CERT-In requirements throughout the year.

5. Be ready to investigate at forensic depth

When an AI-orchestrated intrusion results in fund loss, the questions that follow are precise and consequential: How did the attacker get in? Which hosts and identities were used? Which API calls were fraudulent? Which transactions and accounts were affected? Is the attacker still present?

Answering them requires preserving volatile memory, endpoint artefacts, API gateway and application logs, and network captures before they are lost. It also requires reconstructing an attack sequence that was decided, in part, by an AI agent rather than a human operator.

Forensic readiness – knowing what evidence exists, where it is stored and how quickly it can be secured – determines whether an institution can contain the incident, recover funds where possible, meet regulatory reporting obligations and prove that the threat has been removed.

The shift from intrusion to transaction

CyberStrikeAI is a clear signal that AI-orchestrated attacks have moved from theoretical risk to operational reality, and that in the financial sector their objective has moved from compromising data to moving money.

The lesson is not that the attacker is invincible. The framework has recognizable fingerprints, depends on outbound connectivity and relies on implicit trust inside the network. Each of those dependencies is an opportunity to break the chain.

What has changed is the cost of a missed signal. When attacks progress at machine speed, the distance between an unnoticed beacon and an irreversible transfer is shorter than it has ever been.

In an era of AI-orchestrated attacks, financial institutions will be judged not by how many indicators they block, but by whether a request to move money is ever trusted simply because of where it came from.

For India’s financial sector, closing the gap between the network and the transaction is now the frontline of cyber defence.