STATUS: PUBLISHED
THE OFFENSE GOT CHEAP AND THE DEFENSE GOT EXPENSIVE
Imagine this failure mode: your fraud detection system is working exactly as designed, your API gateway is enforcing every rule, and your allowlist contains only trusted partners—yet an attacker moves money through your payment infrastructure anyway.
That is no longer a hypothetical edge case.
This week, two seemingly unrelated stories—one involving a bank robbery and the other a Linux kernel patch queue—illustrated the same shift in cybersecurity. Offensive tooling is becoming cheaper, faster, and easier to scale. Defending against it increasingly requires coordinated investment across applications, infrastructure, identity systems, software supply chains, and operating systems.
The robbery
On 4 November, CERT-In, India’s national cybersecurity agency, published advisory CIAD-2026-0058 with a critical severity rating.
CSIRT-Fin, the financial-sector incident response team inside CERT-In, identified the threat actor behind an ongoing campaign against Indian banks, non-banking financial companies, digital lenders, fintechs, payment aggregators, payment service providers, and crypto exchanges as “CRAFTY FALCON.”
CERT-In described CRAFTY FALCON as:
“An AI-assisted financial threat actor that surveys its targets with machine intelligence, operates at machine speed and strikes by invoking the victim’s own payment and disbursement APIs.”
That description captures the real problem.
First, reconnaissance has become automated. Instead of manually browsing applications, collecting endpoints, and testing business logic, an attacker can use machine intelligence to survey a target systematically.
Second, the campaign runs at machine speed. It does not observe normal working hours or wait for weekends. It can test many attack paths, generate variations, and adapt based on responses.
Third—and most importantly—the attacker strikes through legitimate APIs. The requests may be well-formed and technically valid. They may originate from trusted infrastructure and follow the exact process the application was designed to use.
This is not necessarily a breach in the traditional sense of an intruder exploiting a broken perimeter. It is an unauthorized actor using your business process correctly enough to defeat the assumptions underneath it.
The tooling
CERT-In named the tools involved in the campaign. They include the ARTEX family of LLM-based tools, PentAGI, an autonomous multi-agent penetration-testing system; the Cairn attack search engine; and the CyberStrikeAI framework.
According to the advisory, these tools are publicly available and can execute complete attack chains autonomously at machine speed. They can generate and refine large numbers of tailored attack scripts in quick succession and modify payloads based on how a target responds.
That combination changes the economics of an attack.
A smaller team no longer needs to build every capability from scratch. It can assemble existing tools, automate reconnaissance, and let AI systems produce and test variations while human operators focus on selecting targets and approving consequential actions.
The operational techniques are just as important as the AI label.
Internet-exposed UAT, staging, and test environments are being used as entry points, with attackers moving into production through shared credentials, tokens, or network paths.
Application codebases are reverse-engineered to produce targeted exploits. Unauthorized API calls are then issued from modified application packages, undermining controls that assumed only the legitimate client application would call those APIs.
IP allowlisting is another weak boundary. The advisory says attackers bypass it by originating traffic from whitelisted third-party fetcher IP pools, including content-acceleration services and app-store review fetchers. These services can be induced to fetch arbitrary URLs, making the allowlist appear trustworthy without proving that the actual requester is trusted.
New vulnerabilities are also exploited quickly after disclosure. File-upload and deserialization chains can be used to place web shells in PHP and Node.js applications.
Finally, attackers use micro-value transactions, including transactions of Rs. 1, to validate unauthorized fund flows before attempting larger transfers. This is a simple but effective way to separate environment probing from high-value extraction.
The Linux kernel connection
At the other end of this week’s stories is the Linux kernel patch queue.
On the surface, a discussion about kernel patches has little to do with bank fraud. Underneath, both stories are about the growing mismatch between offensive speed and defensive capacity.
Attackers can now assemble automated workflows that survey, exploit, adapt, and scale. Defenders, meanwhile, must coordinate changes across application code, identity and access management, secrets, network controls, deployment pipelines, runtime behavior, monitoring, and foundational software.
A single patch rarely addresses the full attack path.
Blocking a known payload does not stop an attacker from generating another. Restricting an IP address does not establish intent. Validating an API request does not prove that the caller is authorized. Protecting production while leaving a test environment exposed may simply move the attacker to the weakest available entrance.
That is why kernel maintenance matters even to teams that never deploy Linux themselves. Modern applications inherit layers of behavior from operating systems, containers, language runtimes, and third-party components. When a vulnerability appears deep in that stack, the defensive work extends beyond installing an update. Teams must identify affected systems, understand exploitability, patch safely, verify deployment, and watch for attempts that occurred before the patch landed.
The offense gets cheaper because tooling turns individual techniques into repeatable workflows. The defense gets expensive because those workflows exploit the seams between systems.
The practical lesson is not that every application should be redesigned around AI attacks. It is that security controls need to stop assuming that valid requests, trusted networks, known clients, and unpatched staging systems are harmless.
Treat test environments as production. Replace implicit trust with authorization. Assume application packages can be modified. Monitor business logic, not just malicious payloads. Keep the dependency and patching pipeline moving. And design detection around complete attack sequences rather than isolated indicators.
The next eighteen months of AI security will not be defined only by better models or larger datasets. It will be defined by whether defenders can match the speed, scale, and adaptability of automated attackers without recreating the same complexity on the offensive side.
The tools may be public, but the advantage will come from how quickly your organization can turn them into useful defensive feedback.
This was first published on Sol AI — https://thesolai.github.io
Top comments (0)