CERT-In advierte que CRAFTY FALCON reataca APIs de desembolso en el sector financiero

El 4 de noviembre de 2026, el equipo financiero de CERT-In actualizó una alerta sobre intrusiones dirigidas a entidades bancarias y financieras, con énfasis en empresas de crédito no bancario, prestamistas digitales, fintech, agregadores y proveedores de pagos. La autoridad india denominó CRAFTY FALCON al actor que atribuye a la campaña y la calificó como asistida por IA y activa. El aviso amplía una alerta previa del 9 de octubre; no describe un incidente aislado ni afirma que todas las organizaciones del sector hayan sido afectadas.

El elemento central es el uso de APIs de desembolso y transferencia que pertenecen a las propias víctimas. Según el análisis de incidentes recibido por CERT-In, los atacantes buscan crear transacciones no autorizadas invocando interfaces legítimas desde infraestructura que puede estar permitida por controles de red. La agencia indica que algunos destinatarios de la advertencia previa fueron atacados nuevamente pese a haber iniciado remediaciones, lo que sitúa la completitud y validación de los cambios como un problema operativo importante.

La alerta enumera varias rutas observadas: abusar servicios de administración de nube para ejecutar comandos o instalar archivos; entrar por entornos de prueba expuestos a internet y moverse hacia producción con credenciales, tokens o rutas compartidas; analizar aplicaciones para modificar paquetes cliente y emitir llamadas API que aparentan legítimas; y aprovechar listas de permitidos construidas sobre direcciones de terceros que realizan búsquedas o entregas de contenido. CERT-In advierte también de transacciones de prueba de valor muy bajo, usadas para confirmar que un flujo ilícito funciona antes de mover montos mayores, y del uso de APIs de liquidación de comercios.

La autoridad relaciona la campaña con herramientas disponibles públicamente para pruebas ofensivas asistidas por IA, entre ellas ARTEX, PentAGI, Cairn y CyberStrikeAI. El riesgo descrito no depende de una nueva vulnerabilidad única: combina fallas de diseño, credenciales expuestas, ambientes de prueba mal aislados y controles de autorización que confían demasiado en la aplicación móvil o en el origen de red. La infraestructura de apoyo cambia de dirección IP en periodos de horas o días, por lo que una lista fija de bloqueo puede quedar obsoleta rápidamente.

Cuando una API de pagos acepta una instrucción de desembolso porque el dispositivo de origen parece confiable, pero no vuelve a aplicar reglas de negocio, la intrusión puede saltarse validaciones que normalmente ocurren en la interfaz: identidad del beneficiario, aprobación del préstamo, límites por transacción o suficiencia de saldo. El atacante puede manipular el canal entre aplicación y servicio, reutilizar tokens o llamar endpoints directos después de entender el código cliente. En ese caso, las capas de red tradicionales y los controles de pantalla no ofrecen por sí solos una garantía de autorización.

El aviso también amplía el riesgo a operaciones financieras relacionadas con criptoactivos y servicios de pago, según las categorías de entidades nombradas por CERT-In. Su alcance legal directo es India y los destinatarios formales de la alerta reciben información restringida con huellas de infraestructura y reglas de detección. Para organizaciones de Ecuador y otros países, la nota no crea una obligación regulatoria local; sí sirve como inteligencia técnica para revisar arquitecturas API que comparten patrones similares, especialmente en banca digital, cooperativas, pasarelas de pago y crédito en línea.

La fuente primaria es el aviso de CERT-In, que informa que CSIRT-Fin sigue recibiendo reportes de ataques exitosos y describe las técnicas observadas. La cobertura independiente de Times of India, publicada el 5 de noviembre, confirma la emisión de la alerta sobre ataques asistidos por IA a entidades financieras. Los indicadores detallados y las reglas específicas no aparecen públicamente en la página abierta; la agencia señala que los distribuye mediante avisos restringidos TLP:AMBER.

Por ello no se puede cuantificar a partir de la información pública cuántas entidades fueron comprometidas, qué montos fueron sustraídos, qué países fuera de India están afectados ni qué infraestructura específica debe bloquearse. CRAFTY FALCON es el nombre que la autoridad asigna al actor dentro de su investigación; no constituye por sí solo una atribución pública a una organización o país. Tampoco debe interpretarse el término “IA” como prueba de que un modelo autónomo condujo toda intrusión: la agencia identifica herramientas y automatización dentro de una cadena de ataque más amplia.

Las áreas de seguridad y pagos deberían revisar la autorización en el servidor para cada operación sensible, con verificación del usuario, beneficiario, estado de la cuenta, límites y contexto de riesgo; no confiar solo en que la solicitud procede de una aplicación oficial, una IP permitida o un token técnicamente válido. En particular, deben inspeccionar rutas de desembolso, liquidación de comercios y transferencias directas, registrar las decisiones de negocio y probar que un cliente alterado no pueda saltarse los pasos de aprobación.

También conviene separar pruebas y producción con credenciales, redes, secretos y cuentas distintas; limitar quién puede administrar recursos de nube; rotar credenciales compartidas; e inventariar APIs no documentadas o de uso interno. Una prueba de valor mínimo seguida de transferencias repetidas o solicitudes desde infraestructura de terceros puede ser una señal, pero las reglas deben combinar comportamiento de usuario, volumen, destino, dispositivo y secuencia de negocio para evitar bloqueos indiscriminados. Las pruebas de respuesta deben incluir fines de semana y feriados, que el aviso identifica como ventanas elegidas para demorar la detección.

CERT-In recomienda a las entidades financieras tratar la campaña como una amenaza inmediata y persistente. Para las instituciones fuera de India, la acción prudente es tomar este patrón como una guía de revisión, no como una instrucción legal de CERT-In aplicable a cualquier jurisdicción. Bancos, cooperativas y fintech ecuatorianas deben contrastar sus medidas con sus propios reguladores y políticas internas, y compartir información de incidentes con las autoridades locales correspondientes según las reglas aplicables.

La remediación debería cerrarse con evidencia: pruebas negativas de endpoints, verificación de permisos efectivos en nube, búsqueda de llamadas atípicas a APIs, revisión de transacciones mínimas y de cambios de beneficiario, y análisis de credenciales o tokens expuestos. Si los hallazgos sugieren acceso no autorizado, los equipos deben preservar registros de nube y aplicación, congelar flujos sospechosos de forma controlada y coordinar fraude, operaciones, seguridad, privacidad y atención a clientes. La alerta demuestra que corregir una parte del sistema sin probar todas las rutas de invocación puede dejar abierta la campaña.