CERT-In Flags AI-Driven Attacks as Backdoored ARTEX Exposes 62 Consoles to Root Access

Summary

The Hacker News reports that CERT-In has identified an active, ongoing AI-assisted threat actor, Crafty Falcon, targeting India's banking, financial services and insurance sectors. The activity reportedly uses ARTEX, PentAGI, Cairn and CyberStrikeAI to accelerate offensive operations. The agency also describes attacks on cryptocurrency exchanges and digital asset service providers that resulted in stolen keys and funds.^[0]

The financial-sector reporting centers on compromise of applications, APIs and credentials, followed by direct abuse of payment interfaces from victims' own allow-listed infrastructure. Reported techniques include obtaining secrets from exposed or non-production systems, validating unauthorized payment flows with micro-value transactions, transferring larger amounts to mule accounts, and deleting logs or tampering with endpoint security. The article also references an earlier October 2026 alert covering multiple campaigns; it does not establish that every technique in that broader reporting belongs exclusively to Crafty Falcon.^[0]

Separately, researcher Badbyte identified a backdoored ARTEX Docker build distributed through a copycat repository. A compose-file change selected tomicdd/artex, whose login handler reportedly executes commands as root when an unauthenticated request supplies a secret prefix in the CAPTCHA field. The article identifies congdonglinux/artex as an identical backdoored image. It reports 62 internet-facing consoles serving the malicious build during November 2–4, 2026, against a broader inventory of 1,645 ARTEX-serving hosts as of November 4.^[0]

The immediate defensive concerns are unauthorized financial API use and compromise of sensitive material held by affected ARTEX installations. These are related operational risks, not an established single intrusion chain: the article does not link Crafty Falcon to creation or operation of the backdoor, nor does the exposure count prove that the backdoor was exercised. All findings in this dossier rest on one supplied secondary report; the underlying CERT-In advisories and researcher analysis were not independently supplied.^[0]

Attack chain

1. 1. Application compromise and credential acquisition: In CERT-In's described financial-sector activity, attackers exploit internet-facing applications, exposed APIs and privileged endpoints to obtain payment aggregator, gateway and partner-bank API credentials. Reported alternative access paths include stolen long-lived tokens, plaintext credentials, forged repository commits and applications or remote services without MFA. These are reported alternatives, not mandatory steps in one intrusion.^[0]
2. 2. Unauthorized payment API access: Attackers use the stolen credentials to invoke fund-transfer APIs directly from the compromised entity's own allow-listed infrastructure. CERT-In says this approach bypasses application-level workflows and controls, including loan creation, KYC, beneficiary verification, balance sufficiency and transaction limits.^[0]
3. 3. Validation of unauthorized fund flows: The operators reportedly execute micro-value transactions, such as Rs. 1, to validate unauthorized fund flows before attempting large-value transfers.^[0]
4. 4. Larger fraudulent transfers: Following validation, attackers execute larger transfers designed to move funds into attacker-controlled mule accounts across multiple banks. Abuse of payment aggregators' merchant settlement APIs is also reported as a means of moving funds.^[0]

Disclosure timeline

Actor profile

Crafty Falcon

CERT-In's tracking name for an AI-assisted threat actor reportedly conducting active, ongoing attacks against India's BFSI sector. The report associates the activity with publicly available offensive tools including ARTEX, PentAGI, Cairn and CyberStrikeAI. CERT-In describes rapid generation and refinement of tailored scripts, payload adaptation to target responses and infrastructure IP rotation within hours to days. The supplied evidence does not establish the actor's nationality, organizational affiliation or responsibility for the ARTEX backdoor; the broader October multi-campaign reporting should not be treated as an exclusive Crafty Falcon profile.^[0]

How it works

The ARTEX distribution issue is a malicious image substitution rather than a documented vulnerability in every ARTEX release. A copycat repository reportedly changed one line in docker-compose.yml to select tomicdd/artex from Docker Hub. The executable backdoor was concealed in the distributed image, so review of the repository alone would not reveal the altered login-handler implementation.^[0]

The modified login handler adds a hidden verifyCaptcha() function. When the CAPTCHA field begins with a secret marker, the function passes the remaining content to sh -c, executes it as root and returns the output before any credential check. The mechanism therefore bypasses authentication rather than depending on a valid login. The article does not disclose the marker or an exact endpoint path.^[0]

The reported execution privilege is root in the affected ARTEX installation. The article does not document a container-escape mechanism or establish host-root compromise, so root command execution should not be expanded into a claim that every deployment's underlying host was taken over.^[0]

Badbyte's stated impact extends beyond control of the console: ARTEX can hold unpatched target findings, live credentials, captured sessions and a useful network position. Control of the instance could also allow changes to subsequent agent behavior. These are described exposure and follow-on risks, not evidence that those assets were stolen from every identified console.^[0]

Affected versions and patch status

Indicators of Compromise

Key takeaways

• Keep attribution separate: Crafty Falcon is a reported financial-sector actor, while the ARTEX backdoor's author and operator are not identified in the supplied evidence.^[0]
• The reported payment attacks exploit trusted execution context: valid credentials and allow-listed victim infrastructure enable API calls that bypass controls assumed to exist in the normal application workflow.^[0]
• An apparently small deployment change can redirect a security tool to a malicious runtime image. Reviewing repository code without checking the selected image can miss the implementation that actually runs.^[0]
• Do not conflate exposure metrics: 62 consoles reportedly served the backdoored build, 1,645 hosts served ARTEX generally, and 9,000 image downloads are not a count of unique compromised systems.^[0]
• The evidence supports urgent investigation of identified backdoored deployments, but not claims of confirmed exploitation across all exposed consoles, universal host-root compromise or a known fixed release.^[0]

Defensive actions

• Inventory deployed ARTEX image references and runtime images for tomicdd/artex and congdonglinux/artex; inspect docker-compose.yml rather than relying only on repository source review.: The reported delivery mechanism was a one-line compose-file substitution that selected a malicious image whose backdoor was not visible in the repository's apparent application source. The two image identifiers are explicitly identified as backdoored; other namespaces merely listed in the article should not automatically receive the same verdict.^[0]
• Isolate installations confirmed to be running the identified backdoored build and remove their public console exposure while determining a trusted replacement.: The login backdoor executes commands before credential checking, so ordinary console authentication is not a sufficient containment boundary. The evidence supplies no fixed image or patch to recommend, and reports dozens of publicly reachable affected consoles.^[0]
• For affected ARTEX deployments, assess and revoke or replace exposed credentials and captured sessions, and review the downstream systems reachable from the instance.: The researcher identifies live credentials, captured sessions, target findings and network position as assets available through a compromised ARTEX instance. Scope this response to what the installation actually held or could access rather than assuming every downstream target was compromised.^[0]
• Review authorization and business-control enforcement at fund-transfer and merchant-settlement APIs; do not treat allow-listed source infrastructure or a supposedly legitimate client application as sufficient authorization.: CERT-In describes direct API invocation from victims' own allow-listed systems and modified client packages that undermine assumptions about who can call an API. The reported abuse bypasses application-level verification and transaction controls.^[0]
• Remove shared production credentials, tokens and unnecessary production network paths from publicly accessible non-production environments.: The reported operators obtain shared secrets or network paths from exposed non-production systems and use them to pivot into production.^[0]
• Hunt for micro-value payment tests followed by larger unauthorized transfers, including merchant-settlement activity, and investigate accompanying log deletion or endpoint-security tampering.: CERT-In specifically reports Rs. 1-style validation transactions before larger transfers to mule accounts, alongside attempts to impair detection and incident response through log and security-tool manipulation.^[0]
• Prioritize removal of exposed long-lived or hard-coded API tokens and plaintext credentials, and require MFA on the applications and remote services implicated by the access-path review.: Stolen static tokens, plaintext secrets and services without MFA are explicitly listed as access methods in the financial-sector reporting.^[0]
• For AI agents used in offensive testing, enforce approved tool use and permission boundaries, least privilege, human approval for consequential actions, and tested interruption and credential-revocation controls.: These controls are specifically described in CERT-In's AI auditing guidelines summarized by the article. They are particularly relevant to an ARTEX deployment that can retain sensitive access material and execute agent-directed actions.^[0]