CERT-In on CRAFTY FALCON: What Should a Fintech Change Now?

CERT-In published advisory CIAD-2026-0058 on 4 November, rated Critical, about a threat actor its financial sector team has named CRAFTY FALCON. It updates an advisory of 9 October on payment and disbursement APIs being used to move money out of BFSI entities. The campaign is "active and ongoing", and firms that had already acted on the earlier warning were "deliberately re-targeted".

The recommended actions run to twenty-seven bullets, which is the trouble with a thorough advisory. It arrives as a programme of work and gets filed as one, behind whatever the quarter already promised.

So here is the position. Four of those bullets are this week's work, and the first is the least interesting thing in the document. Not the AI tooling it names. The staging environment.

What does the CRAFTY FALCON advisory actually describe?

An actor CERT-In's financial sector team calls "an AI-assisted financial threat actor that surveys its targets with machine intelligence", one that "operates at machine speed and strikes by invoking the victim's own payment and disbursement APIs". The scope is NBFCs, digital lending platforms, fintechs, payment aggregators and virtual digital asset providers. If you run a disbursement API, you are inside it.

Two details change how you respond. The infrastructure "rotates IP addresses within hours to days", and the advisory says plainly that "Indicators may change while adversary techniques often remain consistent", so the indicator list is not the control. And the attacks "have been timed to coincide with holidays, weekends and other low-monitoring windows". Look at your on-call roster for the rest of November.

The way in is not exotic. CERT-In lists "file-upload and deserialization exploit chains leading to web shells in PHP and Node.js applications", the same shape as the two October stories we wrote up: which PHP versions are still exposed on AWS and the Brotli bug that patching the host does not fix in your images. Newly published, exploited immediately.

Why is the staging environment the first thing to fix?

Because it sits near the top of the advisory's own account of how the actor gets in: "Internet-exposed non-production environments (UAT/staging/testing) used as entry points", then a pivot to production over shared credentials, tokens or network paths. The matching recommendation is specific about what isolation means, which is "no shared credentials, tokens, API keys, databases or direct network paths".

Every regulated account we have taken over has had a UAT that fails that test. A public load balancer with basic auth. The same Secrets Manager entry as production, because reusing it was quicker. A peered VPC. And a production snapshot restored into it in March so somebody could reproduce a bug, which is a post of its own. Nothing about it is visibly broken, which is why the isolation ticket has slipped three quarters running. We have written that ticket and watched it slip.

If full separation is a quarter of work, there is a cheaper half-measure in the advisory, and it is detection rather than prevention: "Alert on and investigate any access from non-production systems to production systems, credentials or data." A rule over your production flow logs for any source in the non-production CIDR is an afternoon, and it answers the question that matters. Is the path you believe is closed closed?

What is a one rupee transaction telling you?

That somebody is testing the plumbing before they use it. CERT-In describes "micro-value test transactions (such as Rs. 1)" used to validate fund flows ahead of large transfers, and calls the sequence "a strong precursor of unauthorized fund transfer": a tiny payment to a new beneficiary, then a big one, held or reviewed.

This bullet is harder than it reads, and not for technical reasons. It is not a security control. It lives in the payments service or the fraud rules engine, owned by a team whose quarter is measured in conversion, and the three controls beside it have the same owner: "transaction velocity rules, new-beneficiary cooling periods and amount-band anomaly detection".

A cooling period on a new beneficiary costs real money in abandoned first transfers, and the product team is not wrong to say so. So price it: a cooling period above a threshold amount rather than on every beneficiary, with the micro-then-macro rule underneath for everything else. Ask for all four unconditionally and you will get none of them.

Does the maker-checker you already have cover the settlement API?

Probably not, and this is the gap worth checking today. The advisory wants "server-side validation, maker-checker approval and reconciliation" on merchant settlement instructions sent through payment aggregator APIs. Maker-checker itself is not news: the RBI's NBFC cybersecurity directions of 31 July 2026 require at paragraph 21(6) that transactions "are completed only after independent verification and approval by at least two individuals". Our read of it is in what the 2026 directions change for an NBFC on AWS.

What we find on audit is that the two approvals live in the operations console, where a person clicks them, and not on the API path the same instruction can travel. The control was built where the auditor looked. So trace one settlement instruction from the endpoint that accepts it to the ledger that records it, counting approvals. If the count is zero, you have a screen rather than a rule.

Those directions also start a clock: paragraph 28 requires a cyber incident to be reported on the RBI's DAKSH platform "within six hours of detection". Whether six hours is achievable is the question we asked in September, and the answer turns on work done long before the incident.

Who can change a Lambda function, and would you see it?

The cloud bullets are the ones a platform team can close alone. The advisory describes management services "such as AWS Systems Manager and Lambda" used to run commands and drop files, "blending malicious activity into legitimate cloud management channels", and asks for alerts on "remote command execution, serverless function code updates and creation of roles, users or access keys".

Two of those are easy. A rule over CreateAccessKey, CreateRole and UpdateFunctionCode sits on management events you already collect, and a production function whose code changes outside a pipeline is not a judgement call. It is a page.

The remote session is the awkward one. Session Manager is still the right way in, and we have argued for it as how an outside team should reach your account. But AWS's own documentation on session logging says it "logs the commands you enter and their output during a session depending on your session preferences", and that "Logging isn't available for Session Manager sessions that connect through port forwarding or SSH". So a session happening is in CloudTrail. What was typed inside it is nowhere unless somebody switched a log group on, and if your engineers tunnel SSH through it, there is nothing to switch on.

Then egress. The recommendations ask you to "enforce default-deny egress from server segments through allow-listed proxies" and wants serverless functions to have "no Internet egress by default". Most fintech VPCs we open have a 0.0.0.0/0 egress rule on every application security group, inherited from the first Terraform module anybody wrote.

What can you run on Monday?

Two commands and one conversation. Start with whether the events you are about to alert on have already happened:

for e in UpdateFunctionCode CreateAccessKey CreateRole StartSession; do
  echo "== $e"
  aws cloudtrail lookup-events \
    --lookup-attributes AttributeKey=EventName,AttributeValue=$e \
    --start-time "$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
    --query 'Events[].[EventTime,Username]' --output text
  sleep 1
done

Three limits explain the shape of that. Event history holds "the past 90 days of management events in an AWS Region", so run it in every region anyone has launched anything in. It "cannot query multiple attributes", hence the loop. And lookups are "limited to two per second, per account, per Region", hence the sleep.

Then whether a session would leave a transcript at all:

aws ssm get-document --name SSM-SessionManagerRunShell \
  --document-version '$LATEST' --query Content --output text

If cloudWatchLogGroupName and s3BucketName come back empty, no session output is being kept anywhere in that region.

The conversation is with whoever owns the payments service, and it is one rule, not four: a micro-value transfer to a beneficiary created in the last day, followed by a transfer above a threshold you pick, held for review.

When is this advisory not your problem?

If you do not operate a payment or disbursement API and you do not custody wallet keys, most of the twenty-seven bullets are generic hardening you either have or have deliberately deferred, and treating this as an emergency costs you a sprint for nothing. The isolation and the egress default are worth doing regardless. The rest belongs to the firms it names.

And if you already run fraud operations with velocity rules and beneficiary cooling periods, the transaction half of this tells them nothing they have not built. Their gap is on the cloud side, where nobody is alerting on a function's code changing at 2am on a Sunday. Hand them that rule and leave the rest alone.

We sell this work, so read the ordering with that in mind. It is the order we would use ourselves.

The short version

Read the advisory. It is short and it names your sector.

This week: an alert on any access from a non-production source to production, a rule on serverless code changes and credential creation in the production accounts, and the Session Manager log group switched on. Then run the CloudTrail loop in every region and find out whether any of it already happened.

This month: one isolation ticket for the internet-facing UAT, a default deny outbound on the application security groups, and one transaction rule for the micro-then-macro sequence. Then trace a settlement instruction from the API to the ledger, counting approvals. If you do one thing on this list, do the trace. It is the control the advisory assumes you already have.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.