The attackers came back. Was the repair ever finished?

There is a moment after an incident when everyone wants the answer to be “fixed.” The services are back, the customers are waiting and the next report is due. That is precisely when a reassuring status can become dangerous. India’s CERT-In reports an ongoing AI-assisted campaign against financial businesses and repeat attacks after incomplete remediation. Its November 4 advisory names the activity CRAFTY FALCON. That is an agency account of incidents, not AIImpactLab’s independent reconstruction of the affected systems. The public advisory does not establish the attackers’ nationality or state sponsorship, and it supplies no aggregate loss figure we can responsibly attach to this story. The practical lesson is about recovery, not an exotic nationality label. A repaired public-facing service may coexist with a compromised credential or an unchecked route elsewhere. These are general examples of why restoration and eradication are different tasks, not claims about an identified victim in this campaign. Faster attacker tooling makes the distinction more urgent; it does not prove the software selected its own victims without human direction. An organization should be able to explain who tested the repair, what access was checked, which exceptions remain and when it will look again. Those answers do not need to expose sensitive architecture to the public. They do need to reach the people accepting the residual risk. A team may reasonably restore an essential service before every question is answered. It should say that is a controlled, incomplete recovery rather than silently turning uncertainty into a green tick.