Description
CRAFTY FALCON is the designation given by CERT-In's Computer Security Incident Response Team – Finance (CSIRT-Fin) to an AI-assisted financial threat actor associated with attacks against financial institutions and payment infrastructure.
Unlike attacks that primarily depend on manual reconnaissance and individually developed exploits, this campaign reportedly uses machine intelligence to examine target environments, generate customized attack scripts, and adapt its techniques based on responses from the targeted systems.
The attackers are particularly focused on exploiting the business logic and API infrastructure responsible for processing payments, disbursements, and merchant settlements.
A significant concern is that the campaign does not always require attackers to compromise the core payment application directly. Instead, they can abuse legitimate application interfaces and cloud management capabilities to perform actions that appear similar to normal operational activity.
CERT-In has also warned that the campaign continues to evolve, with attackers deliberately revisiting previously targeted organizations when remediation is incomplete.
Technical Description
CERT-In identified several AI-driven offensive tools associated with the campaign:
ARTEX: A family of large language model (LLM)-based offensive security tools.
PentAGI: An autonomous, multi-agent AI penetration-testing system.
Cairn: An attack search engine.
CyberStrikeAI: An AI-assisted offensive security framework.
According to the advisory, these tools can support automated attack chains, generate and refine large numbers of customized scripts, and adapt payloads based on target responses.
The campaign reportedly combines these capabilities with weaknesses in application security, cloud infrastructure, identity management, and financial transaction controls.
Major attack techniques observed
1. Abuse of cloud management services
Attackers targeted cloud infrastructure, including compute resources, serverless services, and management platforms. Services such as AWS Systems Manager and AWS Lambda were reportedly abused to execute commands and deploy malicious files.
By operating through legitimate cloud management channels, malicious activity can become harder to distinguish from normal administrative operations.
2. Exploitation of non-production environments
Internet-exposed development, testing, staging, and User Acceptance Testing (UAT) environments were used as initial entry points.
Attackers subsequently moved toward production environments by abusing shared credentials, access tokens, and network connections between environments.
3. Application reverse engineering and API abuse
The threat actor reportedly reverse-engineered application codebases to understand application functionality and develop tailored exploits.
Attackers then initiated unauthorized API requests using modified or repackaged application packages. This approach can defeat security controls that assume API requests originate only from the legitimate application.
4. IP allow-listing bypass
CERT-In observed attackers using whitelisted third-party fetcher IP pools, including content-acceleration and app-store review fetcher services.
Because these shared services can fetch URLs on behalf of external users, attackers may abuse them to make malicious requests appear to originate from an approved IP address.
5. Automated financial transaction testing
Attackers reportedly performed micro-value transactions, such as ₹1 transfers, to validate unauthorized fund-transfer paths before attempting larger transactions.
These small transactions can serve as an early indication that attackers are testing payment workflows before attempting financial theft.
6. Exploitation of web application vulnerabilities
Newly disclosed vulnerabilities were reportedly exploited soon after becoming public. CERT-In specifically identified file-upload and deserialization exploit chains affecting PHP and Node.js applications, which could lead to web shell deployment.
7. Cryptocurrency wallet targeting
Cryptocurrency exchanges and virtual digital asset service providers were also targeted. The advisory reports incidents involving wallet-key theft and funds being siphoned from cryptocurrency wallets.
Attack Overview
The following sequence summarizes the attack pattern described by CERT-In. Individual incidents may involve different entry points and techniques.
Stage 1 – Automated Reconnaissance
The attackers use AI-assisted tools to survey target organizations, identify exposed services, examine application functionality, and discover potential weaknesses.
Stage 2 – Initial Access
Internet-facing UAT, staging, testing environments, or vulnerable applications may be used as entry points. Attackers may also exploit newly disclosed vulnerabilities in PHP and Node.js applications.
Stage 3 – Cloud and Environment Abuse
After gaining access, attackers may abuse cloud management services, serverless functions, credentials, tokens, or shared network paths to execute commands and move toward sensitive systems.
Stage 4 – API Manipulation
Attackers reverse-engineer application packages and develop customized scripts to interact with payment, disbursement, and merchant settlement APIs.
Modified application packages and unauthorized API requests may be used to bypass controls that rely heavily on the legitimacy of the client application.
Stage 5 – Transaction Validation
Small-value transactions may be initiated to verify whether unauthorized financial transfers can successfully pass through the targeted payment workflow.
Stage 6 – Financial Theft
After validating the transaction path, attackers may attempt larger unauthorized transfers, abuse merchant settlement processes, or steal cryptocurrency wallet keys.
Stage 7 – Persistence and Re-targeting
CERT-In has reported that organizations previously targeted by the campaign were attacked again after incomplete remediation. This highlights the importance of complete eradication, forensic verification, and continuous threat hunting following an incident.
Technical Analysis
1. AI-Assisted Autonomous Attack Execution
One of the most significant aspects of this campaign is the use of AI-driven offensive security frameworks.
CERT-In reports that the identified tools can execute complete attack chains autonomously, generate customized scripts rapidly, and refine their payloads based on target responses.
This changes the operational scale of an attack. Instead of relying entirely on manual analysis and script development, attackers can automate repetitive tasks and conduct multiple attack activities in parallel.
The advisory also identifies rapidly generated scripts with functionally similar variations, a pattern consistent with AI-assisted code generation and iterative refinement.
2. Cloud Infrastructure as an Attack Surface
The campaign demonstrates how legitimate cloud administration capabilities can become an attack path when credentials or permissions are compromised.
AWS Systems Manager and AWS Lambda were specifically identified in the advisory.
Attackers may abuse these services to execute commands, deploy files, or modify serverless function code. Since these activities can resemble authorized administration, inadequate cloud audit monitoring may delay detection.
Security teams should pay particular attention to unexpected remote-management sessions, serverless code modifications, and unauthorized creation of cloud roles, users, and access keys.
3. UAT-to-Production Lateral Movement
The use of non-production environments as initial entry points highlights a common architectural weakness: insufficient separation between testing and production infrastructure.
If development or testing environments share credentials, API keys, databases, or network access with production systems, a compromise in one environment can create opportunities to access another.
CERT-In specifically recommends isolating UAT, staging, and testing environments from production, with no shared credentials or direct network paths.
4. API Trust and Business Logic Abuse
A particularly important feature of this campaign is the abuse of legitimate payment and disbursement APIs.
Many applications rely on client-side controls or assumptions that requests will originate from an approved mobile or web application. However, an attacker who reverse-engineers an application may attempt to reproduce its API requests independently.
This makes server-side validation essential.
Financial organizations must independently verify transaction ownership, authorization, beneficiary details, transaction limits, and business rules on the server. A request should never be trusted simply because it appears to originate from a legitimate application.
5. Abuse of Shared Third-Party Infrastructure
CERT-In observed attackers using IP addresses associated with whitelisted third-party fetcher services to bypass IP-based restrictions.
This highlights a limitation of relying only on source IP addresses for authentication or authorization.
A request originating from an approved IP does not necessarily prove that it was initiated by an authorized user or application.
Identity-based controls, mutual TLS, cryptographically signed requests, and scoped API keys provide stronger protection than IP allow-listing alone.
6. Financial Fraud Detection Evasion
The reported use of ₹1 test transactions demonstrates how attackers may validate unauthorized transaction flows before attempting larger transfers.
This makes transaction monitoring particularly important.
Security teams should correlate small transactions to newly added beneficiaries with subsequent high-value transfers, unusual transaction velocity, and activity outside normal business hours.
A low-value transaction should not automatically be treated as harmless when it is followed by suspicious financial activity.
7. Repeated Attacks After Incomplete Remediation
CERT-In has reported that previously affected organizations were deliberately targeted again, including entities that had already attempted remediation.
This suggests that incident response cannot end with blocking an IP address, removing a malicious file, or resetting one compromised account.
Organizations must investigate the initial entry point, remove persistence mechanisms, rotate affected credentials, review cloud permissions, validate production systems, and conduct follow-up threat hunting.
Potential Impact
The CRAFTY FALCON campaign presents serious risks to financial institutions and their customers.
1. Unauthorized Financial Transfers
Abuse of payment and disbursement APIs could allow attackers to initiate unauthorized transfers and manipulate financial workflows.
2. Cloud Infrastructure Compromise
Misuse of cloud management services could expose sensitive workloads, application environments, and administrative capabilities.
3. Customer and Financial Data Exposure
Compromised applications, databases, or cloud environments could expose sensitive customer information and business records.
4. Cryptocurrency Asset Theft
Compromise of wallet keys could enable unauthorized access to cryptocurrency assets and potentially irreversible financial losses.
5. Production Environment Compromise
Movement from exposed testing environments into production could affect critical business applications and payment infrastructure.
6. Operational Disruption
Repeated attacks, incident containment, credential rotation, and infrastructure recovery could disrupt financial services and business operations.
7. Regulatory and Reputational Consequences
Financial organizations may face regulatory scrutiny, customer trust issues, and additional incident response obligations following successful compromise.
Recommendations
CERT-In has issued extensive defensive recommendations. The following measures are particularly important for BFSI organizations.
Immediate Actions
Maintain 24×7 security monitoring: Treat the campaign as an active threat. Increase monitoring coverage during weekends, holidays, and other periods when security staffing may be reduced.
Monitor cloud audit logs: Centralize and continuously review cloud audit logs. Alert on remote command execution, serverless function code updates, and unexpected creation of roles, users, or access keys.
Secure cloud management services: Restrict AWS Systems Manager and serverless execution to approved principals and accounts. Investigate unexpected interactive management sessions and production function changes.
Isolate non-production environments: Separate UAT, staging, testing, and development environments from production. Eliminate shared credentials, API keys, databases, and direct network paths.
Review payment and disbursement APIs: Enforce server-side validation of every transaction and business rule. Investigate unauthorized API calls and suspicious beneficiary activity.
Strengthen transaction monitoring: Flag small-value transactions to new beneficiaries when followed by high-value transfers. Implement transaction velocity rules, cooling periods, and anomaly detection.
Patch exposed applications: Prioritize internet-facing PHP and Node.js applications, particularly file-upload and deserialization vulnerabilities. Use WAF virtual patching as an interim measure where necessary.
Protect credentials and tokens: Remove hardcoded credentials from source code and build pipelines. Rotate affected build and deployment tokens and use short-lived, fine-grained access tokens.
Protect cryptocurrency wallets: Store wallet keys in hardware security modules or cold custody, require multi-signature approval for withdrawals, and monitor withdrawal patterns.
Preserve evidence after detection: Isolate affected systems, preserve forensic evidence and logs, rotate credentials, and report suspicious activity to CERT-In/CSIRT-Fin.
Preventive Measures
Cloud Security
Enforce least-privilege access for cloud instances, users, and serverless functions.
Enable instance metadata service protections.
Apply default-deny outbound network policies and restrict unrestricted HTTPS egress.
Alert on unusual cloud administration activity and unauthorized serverless deployments.
Application and API Security
Use API request signing with nonces and timestamps.
Adopt application attestation services and certificate pinning to help identify altered or repackaged applications.
Use mutual TLS, cryptographically signed requests, or scoped API keys instead of relying solely on shared third-party IP allow-lists.
Make application deployment directories read-only for application runtime users.
Deploy file-integrity monitoring to identify unauthorized changes and web shells.
Identity and Access Management
Enforce identity-based access controls for users and services.
Rotate compromised credentials and restrict token permissions.
Monitor token usage from unusual IP addresses, user agents, and geographical locations.
Implement branch protection, commit signing, and mandatory code review for production deployment branches.
Network and Endpoint Security
Enforce default-deny egress policies through approved proxies.
Monitor suspicious outbound connections and possible command-and-control or data-exfiltration activity.
Use TLS inspection and investigate self-signed certificates presented over non-standard ports.
Adopt zero-trust architecture and micro-segmentation to restrict lateral movement.
SIEM and Threat Detection
Tune SIEM correlation rules to detect machine-speed attack patterns, parallel attack activity, and repeated payload variations.
Monitor unauthorized AI security tools and suspicious AI coding-agent processes on corporate systems.
Govern LLM API usage and investigate unusual LLM API traffic originating from production servers.
Deploy deception technologies such as honeypots, decoy administrative panels, and canary credentials.
Integrate automated containment through SOAR where appropriate.
Incident Response
Assume possible persistence after an incident until forensic verification confirms eradication.
Conduct periodic threat hunting after remediation.
Require written approval, defined scope, and a specific time window for authorized penetration testing.
Maintain a process for reporting suspicious activity to CERT-In and relevant financial cybercrime authorities.
Conclusion
The CRAFTY FALCON campaign highlights a significant shift in the threat landscape facing India's financial sector. AI-assisted offensive tools are reportedly being used to automate reconnaissance, develop customized attack scripts, exploit application weaknesses, and abuse legitimate payment infrastructure at machine speed.
The most concerning aspect is not limited to the use of AI. It is the combination of automated attacks with weaknesses in cloud permissions, API authorization, environment separation, and financial transaction validation.
CERT-In's warning that previously targeted organizations have been attacked again after incomplete remediation demonstrates why incident response must go beyond initial containment.
For BFSI organizations, security must extend across cloud infrastructure, application APIs, identity systems, payment workflows, and cryptocurrency custody. Continuous monitoring, strong server-side validation, transaction anomaly detection, and verified eradication are essential to reducing the risk of financial compromise.
The campaign reinforces a critical lesson: when attackers can automate attacks at machine speed, financial institutions must be prepared to detect, contain, and respond at the same pace.