El Equipo de Respuesta a Emergencias Informáticas de India (CERT-In) ha informado que un actor de amenazas asistido por inteligencia artificial (IA), al que rastrea como Crafty Falcon, está dirigiendo sus ataques contra organizaciones de los sectores bancario, financiero y de seguros (BFSI) del país.
La agencia describe la amenaza como activa y en curso, e indica que la actividad emplea herramientas ofensivas de seguridad impulsadas por IA disponibles públicamente, como ARTEX, PentAGI, Cairn y CyberStrikeAI.
"Estas herramientas ejecutan cadenas de ataque completas de forma autónoma a velocidad de máquina, generan y refinan grandes cantidades de scripts de ataque personalizados en rápida sucesión, y adaptan sus cargas útiles según las respuestas del objetivo", señaló CERT-In. "La infraestructura de ataque de soporte rota las direcciones IP en cuestión de horas o días".
Según la agencia, los ataques también han tenido como objetivo intercambios de criptomonedas y proveedores de servicios de activos digitales, lo que ha resultado en el robo de claves y fondos.
Esta actualización sigue a una alerta emitida por CERT-In en octubre de 2026, que advertía sobre múltiples campañas de ciberataques dirigidas a compañías financieras no bancarias (NBFC), plataformas de préstamos digitales, entidades fintech, proveedores de servicios de pago y operadores de carteras de criptomonedas.
Se ha observado que los actores de amenazas explotan aplicaciones accesibles desde internet, así como API y puntos finales privilegiados expuestos, para robar credenciales de API de agregadores/pasarelas de pago y bancos asociados, y luego invocar API de transferencia de fondos directamente desde la infraestructura propia de las entidades incluida en listas de permitidos.
Algunos de los otros vectores de acceso inicial destacados son los siguientes:
- – Uso de tokens de API estáticos y codificados de forma rígida robados y de larga duración
- – Compromiso de la cadena de suministro de repositorios de código fuente mediante commits falsificados
- – Explotación de credenciales en texto plano en archivos de configuración, código fuente o bases de datos
- – Acceso a aplicaciones y servicios remotos que carecen de autenticación multifactor (MFA)
CERT-In añadió que este enfoque elude controles a nivel de aplicación como la creación de préstamos, KYC, sanción, verificación de beneficiarios, suficiencia de saldo y límites por transacción.
Las transacciones fraudulentas, ejecutadas rápidamente, están diseñadas para mover fondos a cuentas mula controladas por los atacantes en múltiples bancos. Además, los ataques incluyen medidas de los operadores para eliminar registros y manipular herramientas de seguridad de endpoints con el fin de dificultar la detección y la respuesta a incidentes.
CERT-In también advirtió que los atacantes están atacando infraestructura en la nube para ejecutar comandos y desplegar cargas útiles maliciosas, así como entornos de no producción accesibles públicamente para obtener credenciales compartidas, tokens o rutas de red, y luego usarlos para pivotar hacia sistemas de producción.
Otras acciones notables posteriores a la explotación llevadas a cabo por el adversario son las siguientes:
- – Ingeniería inversa de bases de código de aplicaciones para desarrollar exploits personalizados
- – Inicio de llamadas API no autorizadas utilizando paquetes de aplicación modificados, socavando los controles que "asumían que solo la aplicación cliente legítima llamaría a las API"
- – Ejecución de transacciones de prueba de microvalor (como 1 rupia) para validar flujos de fondos no autorizados antes de ejecutar transferencias de gran valor
- – Abuso de API de liquidación de comerciantes de agregadores de pago para mover fondos
- – Explotación de vulnerabilidades recién divulgadas, incluidas cadenas de exploits de carga de archivos y deserialización que conducen a web shells en aplicaciones PHP y Node.js
- – Creación de una gran cantidad de scripts personalizados sobre la marcha y su mejora iterativa en rápida sucesión, un patrón consistente con el desarrollo asistido por IA
Este desarrollo coincide con la publicación por parte de CERT-In de las Directrices de Auditoría de Seguridad de Inteligencia Artificial, que establecen requisitos específicos para garantizar la "gobernanza, seguridad, privacidad, equidad, transparencia, resiliencia y auditabilidad de los sistemas de IA".
El marco exige probar las identidades documentadas de un agente de IA, los objetivos autorizados, el uso aprobado de herramientas, los límites de permisos y su adherencia al principio de mínimo privilegio (PoLP). También requiere que los agentes de IA necesiten aprobación humana para acciones consecuentes, y que los sistemas de IA de alto riesgo incorporen interrupción de emergencia, revocación de credenciales y controles para prevenir reinicios automáticos.
"Una garantía efectiva requiere responsabilidad organizativa, pruebas técnicas, gobernanza de datos y modelos, monitoreo continuo, supervisión humana, respuesta a incidentes y garantía de terceros", dijo la agencia. "En consecuencia, el marco proporciona requisitos auditables proporcionales a la naturaleza, escala, autonomía e impacto potencial de cada sistema de IA".
Una versión copia de ARTEX otorga un shell root
El abuso de herramientas de pruebas de penetración de código abierto como ARTEX en intrusiones del mundo real llevó a su desarrollador a retirar el repositorio de GitHub. Sin embargo, han surgido múltiples copias en la plataforma de alojamiento de código propiedad de Microsoft para llenar el vacío:
- – github[.]com/trhhubsd/ARTEXX
- – github[.]com/mhtsec/ARTEX ("mianhuatang11/artex" en Docker Hub)
- – github[.]com/RuoJi6/ARTEX
Los dos primeros repositorios de GitHub ya no están disponibles para su descarga. Según un investigador de ciberseguridad independiente conocido con el alias en línea Badbyte, el repositorio "trhhubsd/ARTEX" recibió 2.449 estrellas y más de 600 bifurcaciones.
Lo notable de la copia de GitHub es que modificó una sola línea en "docker-compose.yml" para extraer la imagen "tomicdd/artex" de Docker Hub. La versión modificada oculta una nueva rutina que otorga un shell root durante una solicitud no autenticada al endpoint de inicio de sesión. Según las estadísticas compartidas por Docker Hub, la imagen se ha descargado 9.000 veces.
"Agrega una función oculta verifyCaptcha() al controlador de inicio de sesión: si el campo CAPTCHA comienza con un marcador secreto, el resto se ejecuta a través de sh -c como root y se devuelve la salida, antes de cualquier verificación de credenciales", dijo el investigador en un comunicado compartido con The Hacker News por correo electrónico. "Eso es un shell root no autenticado en cada instalación, y nunca aparece en una revisión de código".
"Una instancia comprometida de ARTEX contiene los hallazgos no parcheados de sus objetivos, credenciales activas, sesiones capturadas y posición en la red. Quien tenga la puerta trasera también puede cambiar silenciosamente lo que hacen los agentes en la próxima ejecución".
Se ha descubierto que hasta 62 consolas ARTEX en internet sirven la compilación con puerta trasera entre el 2 y el 4 de noviembre de 2026, y la primera instancia apareció el 20 de octubre de 2026, doce días después de que se publicara la imagen de Docker. De estas, 26 consolas se encuentran en Estados Unidos, seguidas de 17 en Hong Kong y siete en China.
En total, se han encontrado 1.645 hosts que sirven la consola ARTEX hasta el 4 de noviembre de 2026. Además de "tomicdd/artex", se han identificado varios espacios de nombres de Docker Hub que publican imágenes llamadas "artex". Algunos de ellos se enumeran a continuación:
- – congdonglinux/artex (también con puerta trasera e idéntica a "tomicdd/artex")
- – mianhuatang11/artex
- – autumn26/artex
- – andy1099zz/artex
- – dgddw/artex
- – trhhubsd/ARTEX
- – ylh440104/artex
"El autor de la puerta trasera no necesitaba nada más. Las personas a las que buscaban ya habían elegido ejecutar una herramienta de ataque no verificada como root en un puerto abierto", dijo Badbyte. "Sabemos que ARTEX se ha utilizado maliciosamente en el mundo real, y seguirá usándose así. También sabemos que muchas personas legítimas y curiosas lo instalaron para ver de qué se trataba. No se inscribieron para tener un shell root en su propio servidor".
Deja una respuesta