Los ciberataques contra bancos surcoreanos exponen una nueva brecha de seguridad de la IA
Los ciberataques contra bancos surcoreanos expusieron datos de aproximadamente 25.000 clientes de Shinhan Bank, pese a años de sólidas evaluaciones de seguridad. Los atacantes no necesitaron penetrar la principal plataforma bancaria de Shinhan. Según los informes, eludieron la autenticación de un servicio de consulta de préstamos utilizado por corredores.
Posteriormente se produjeron otras intrusiones o intentos de intrusión en KB Kookmin Bank, Hana Bank, BNK Busan Bank, Woori Bank y NH Nonghyup Bank. El conjunto de incidentes llevó a las autoridades surcoreanas a celebrar reuniones de emergencia e iniciar una investigación nacional.
La lección incómoda no es simplemente que los delincuentes puedan usar inteligencia artificial. Estos incidentes muestran cómo la automatización asistida por IA puede convertir servicios web desatendidos en una superficie de ataque eficiente. Los bancos construyeron defensas formidables alrededor de los sistemas de transacciones, pero las aplicaciones de apoyo expuestas siguieron siendo accesibles.
Más tarde, CrowdStrike encontró pruebas que vinculan parte de la campaña con ARTEX, una herramienta de pruebas de penetración agéntica de código abierto. Sin embargo, las pruebas disponibles no demuestran que ARTEX haya comprometido a todas las instituciones afectadas. Tampoco muestran que un modelo de IA planificara y completara los ataques de forma independiente.
Esa distinción es importante. Las pruebas más sólidas respaldan una conclusión más acotada, pero aún relevante. La IA ayudó a un operador humano a trabajar con mayor rapidez contra múltiples objetivos, mientras fallos convencionales de autenticación y control de acceso crearon las brechas.
Qué ocurrió en el sector financiero de Corea del Sur
Los incidentes conformaron una campaña concentrada contra sistemas empresariales accesibles desde el exterior, no un compromiso confirmado de las redes bancarias centrales.
Shinhan Bank detectó un aumento repentino de consultas a su servicio M-Shinhan el 29 de septiembre de 2026. Los corredores de préstamos utilizaban ese servicio web móvil para comprobar el progreso de las solicitudes de los clientes.
Según informes locales, una parte no autorizada eludió el proceso de autenticación del servicio. El atacante envió repetidamente valores como números de recibo, recopiló identificadores de clientes y consultó otros servicios simplificados.
La información expuesta variaba entre los clientes. Según los informes, incluía nombres, números de teléfono, ingresos anuales, importes de solicitud de préstamo, límites calculados y otros detalles de las solicitudes.
En el caso de algunos clientes, los registros comprometidos también incluían números de registro de residente e información de identidad vinculada. Shinhan determinó que aproximadamente 25.000 personas se vieron afectadas e informó del incidente el 30 de septiembre.
KB Kookmin Bank reveló una filtración independiente que afectó a 119 clientes. Un atacante obtuvo acceso externo anómalo a un sistema móvil de soporte laboral utilizado por empleados.
La información expuesta incluía nombres, números de teléfono, direcciones y números de registro de residente cifrados. KB indicó que el sistema afectado era independiente de la banca por internet, la banca móvil y la infraestructura de transacciones de clientes.
Hana Bank informó de la exposición de información perteneciente a 89 clientes. BNK Busan Bank descubrió que información personal relativa a 11 trabajadores de desarrollo subcontratados había sido accesible a través de páginas web.
Woori Bank y NH Nonghyup Bank también detectaron intentos de ataque similares. Según los informes oficiales de incidentes, esas instituciones bloquearon el acceso no autorizado antes de confirmar la exposición de datos de clientes.
Estas cifras contradicen un informe inicial que afirmaba que KB Kookmin Bank había expuesto los datos de tarjetas de crédito de 119.000 clientes. Informes coreanos más detallados y la divulgación del banco identifican de forma consistente a 119 clientes afectados, no a 119.000.
Esa corrección cambia sustancialmente el total. Las cifras públicas verificadas respaldan más de 25.000 personas afectadas en las instituciones mencionadas, en lugar de un total confirmado superior a 140.000.
Incluso la cifra menor representa una filtración grave. La información robada sobre préstamos e identidad puede ayudar a los delincuentes a crear estafas convincentes sin obtener contraseñas ni credenciales de pago.
Los incidentes también trascendieron a un banco o una página vulnerable. La Comisión de Servicios Financieros de Corea del Sur convocó una reunión de respuesta de emergencia el 2 de octubre con reguladores, grupos sectoriales, bancos y compañías de tarjetas.
La reunión de emergencia ordenó a las instituciones financieras inspeccionar los sistemas y servicios expuestos externamente. Se indicó a los participantes que revisaran los controles de autenticación, bloquearan la exposición innecesaria de información y compartieran indicadores de infraestructura hostil.
El presidente Lee Jae Myung ordenó posteriormente una investigación exhaustiva. La Oficina Nacional de Investigación comenzó a examinar posibles infracciones y las relaciones entre los incidentes individuales.
La cuestión central ya no era si un banco había operado una página web vulnerable. Las autoridades necesitaban determinar si un único operador había industrializado el descubrimiento y la explotación de debilidades similares en todo el sector financiero.
Los ciberataques contra bancos surcoreanos encontraron el perímetro desatendido
Los atacantes tuvieron éxito en la frontera entre los sistemas financieros reforzados y los servicios más pequeños construidos a su alrededor.
Los bancos dedican recursos considerables a proteger sistemas de pago, aplicaciones de clientes y redes internas de transacciones. Estas plataformas suelen utilizar autenticación por capas, supervisión continua y controles operativos estrictos.
Los sistemas de apoyo a menudo reciben menos escrutinio. Las páginas de consulta de préstamos, los portales de empleados, las herramientas de ventas, las interfaces de contratistas y los servicios web más antiguos siguen procesando información sensible. Sin embargo, pueden usar una autenticación más débil o permanecer expuestos directamente a internet.
El servicio vulnerado de Shinhan ilustra esa brecha. Existía para facilitar a los corredores las comprobaciones rutinarias del estado de los préstamos. Esa comodidad se volvió peligrosa cuando los identificadores recopilados de un servicio, según los informes, funcionaban en otras consultas sencillas.
La filtración no requirió que un atacante derrotara la aplicación móvil principal de Shinhan. Según los informes, dependió de consultas anómalas, límites de autenticación débiles y controles insuficientes contra solicitudes automatizadas repetidas.
El incidente de KB Kookmin siguió el mismo patrón arquitectónico. El sistema móvil de soporte comprometido atendía a empleados, en lugar de clientes minoristas, pero aun así contenía información crediticia personal.
Esta es la principal inversión que revela el incidente. Los bancos surcoreanos no parecían indefensos en su punto más fuerte. Quedaron expuestos a través de sistemas secundarios que seguían conectados a registros valiosos.
Shinhan había recibido la calificación más alta en evaluaciones de protección de información crediticia personal durante cinco años consecutivos. También contaba con certificaciones reconocidas de seguridad de la información.
Esas credenciales no evitaron la filtración del servicio de consulta de préstamos. Un programa de seguridad puede cumplir requisitos amplios de evaluación y, aun así, pasar por alto un flujo de trabajo expuesto a internet con controles de acceso débiles.
El problema va más allá de la banca. Las grandes organizaciones acumulan pequeñas aplicaciones mediante subcontratación, fusiones, proyectos temporales y compras departamentales.
Cada aplicación puede convertirse en una vía no documentada hacia datos sensibles. Un sistema no necesita procesar pagos para crear un riesgo financiero material.
La IA cambia la economía de encontrar esas vías. Antes, un atacante humano tenía que enumerar servicios, interpretar respuestas, ajustar la lógica de escaneo y repetir el trabajo entre distintos objetivos.
Un agente puede ayudar de forma continua con varios de esos pasos. El software agéntico está diseñado para perseguir un objetivo mediante el uso repetido de herramientas, la observación y la adaptación con una intervención humana limitada.
Eso no convierte al modelo en un delincuente autónomo. Le proporciona al operador un método más rápido para probar muchos sistemas expuestos y organizar los resultados.
Por lo tanto, los ciberataques contra bancos surcoreanos presionan a los responsables de seguridad para redefinir la infraestructura crítica. El perímetro relevante incluye todos los servicios que pueden recuperar información sensible, no solo los sistemas que mueven dinero.
Las organizaciones también necesitan mapear cómo viajan los identificadores entre aplicaciones. Un número de cliente obtenido de una página de bajo riesgo se vuelve peligroso si otro servicio lo considera prueba suficiente de autorización.
Los límites de tasa, la autenticación sólida, la minimización estricta de datos y la supervisión del comportamiento deben seguir los datos. Aplicarlos solo a plataformas de transacciones orientadas al cliente deja una brecha explotable.
Cómo el hackeo con IA de ARTEX aceleró el ritmo de los atacantes
ARTEX parece haber coordinado tareas ofensivas conocidas, mientras los modelos de lenguaje ayudaron al operador a mantener la actividad contra varios objetivos financieros.
CrowdStrike publicó su investigación el 7 de octubre tras examinar infraestructura asociada con la campaña. Los investigadores encontraron directorios abiertos que contenían archivos de configuración de ARTEX, historiales de Claude Code y archivos de memoria de Claude.
ARTEX es un marco de pruebas de penetración agéntico de código abierto desarrollado en China. Puede automatizar la recopilación de información, el descubrimiento de vulnerabilidades, la planificación de explotación y tareas de seguridad relacionadas.
Estas funciones tienen usos legítimos. Los equipos de seguridad emplean pruebas automatizadas para identificar debilidades antes de que las encuentren los delincuentes.
El riesgo cambia cuando el mismo marco se conecta a los objetivos elegidos por un operador y a infraestructura ofensiva. La automatización puede comprimir el tiempo entre el descubrimiento, la experimentación y la extracción de datos.
CrowdStrike vinculó un servidor con una instancia de ARTEX que probablemente estuvo involucrada en la actividad coreana. Un segundo servidor en Hong Kong parecía funcionar como la infraestructura principal del operador.
El análisis de infraestructura de ARTEX encontró instrucciones en chino que describían cómo un modelo debía realizar pruebas de penetración. También reveló una pila de varios servicios de IA.
Según CrowdStrike, la instancia de ARTEX utilizaba DeepSeek v4.1-flash como su backend principal de modelo de lenguaje. El operador también utilizó GLM-5.3 y Grok 4.6 en sesiones adicionales de Claude Code.
El punto importante no es qué modelo apareció en cada registro. El entorno combinado dio a un operador varias formas de generar código, interpretar resultados técnicos y continuar una investigación.
CrowdStrike observó una intensa actividad desde finales de septiembre hasta principios de octubre. Las organizaciones objetivo coincidían con instituciones identificadas en informes públicos sobre las filtraciones surcoreanas.
Las sesiones expuestas también revelaron posibles motivaciones financieras. El operador preguntó a Claude dónde suelen vender los delincuentes datos de filtraciones coreanas y solicitó ayuda para encontrar grupos relevantes de Telegram.
En otra sesión, el usuario pidió a Claude que creara un currículum de investigación de seguridad que hiciera referencia a la actividad de ARTEX. El prompt incluía un nombre, número de teléfono, ubicación, detalles de educación y una cuenta de Telegram.
CrowdStrike evaluó que los datos personales probablemente pertenecían a la persona que llevaba a cabo la actividad. Sin embargo, no pudo asociar definitivamente esa identidad con el atacante.
Este inusual error operativo pone de relieve una segunda cara de los delitos asistidos por IA. Las mismas herramientas que aceleran una intrusión pueden conservar conversaciones, prompts, archivos de memoria y registros de configuración.
Un atacante que centraliza su trabajo dentro de agentes de programación crea un detallado rastro de actividad. Una infraestructura de IA mal protegida puede exponer tanto el método de ataque como los errores del operador.
Eso no significa que los defensores puedan confiar en que los delincuentes dejarán los directorios abiertos. Los actores experimentados aprenderán a aislar sesiones, eliminar historiales y evitar introducir información identificativa.
La importancia duradera del hacking con ARTEX AI radica en su efecto sobre el ritmo operativo. Una persona con motivación financiera puede usar la automatización para realizar un trabajo que antes exigía un equipo más grande o una preparación más prolongada.
Los investigadores de seguridad llegaron a una conclusión similar antes de que CrowdStrike publicara sus hallazgos. Los especialistas que examinaron el incidente advirtieron que la IA puede automatizar una parte considerable de la preparación de ataques y la operación de herramientas.
Un operador sigue necesitando intención, infraestructura, selección de objetivos y suficiente criterio técnico para interpretar los fallos. La IA reduce la fricción, pero no elimina esos requisitos.
Esa distinción debería orientar el gasto defensivo. Los bancos necesitan controles que detengan el sondeo automatizado rápido, en lugar de productos que simplemente etiqueten todo el tráfico hostil como generado por IA.
Entre las medidas eficaces se incluyen inventarios de servicios, monitorización de la superficie de ataque, análisis de tasas de solicitudes, autenticación más sólida y aislamiento automático de rutas de acceso anómalas.
La etiqueta tecnológica importa menos que la velocidad y el alcance del comportamiento. Los defensores deben detectar a un operador que actúa con persistencia a escala de máquina.
Lo que la evidencia sobre IA no demuestra
La campaña demuestra actividad de intrusión asistida por IA, pero no establece un hacking plenamente autónomo ni una causa única para todas las brechas.
La cobertura inicial describió con frecuencia los incidentes como ataques bancarios impulsados por IA. Esa expresión recoge las herramientas sospechadas, pero puede exagerar lo que los investigadores han verificado.
CrowdStrike encontró evidencia directa de que un operador utilizó ARTEX y varios modelos de lenguaje. También vinculó esa infraestructura con objetivos que se solapaban con las organizaciones financieras afectadas.
La empresa no confirmó el número total de instituciones comprometidas. Su informe afirma que la cifra seguía sin confirmarse cuando se publicó el análisis.
Las autoridades también evitaron atribuir cada incidente a ARTEX. El regulador financiero de Corea del Sur reconoció un posible uso de IA, pero continuó investigando las causas y los métodos de los ataques.
Las distintas instituciones también expusieron sistemas diferentes. El incidente de Shinhan afectó a un servicio de consultas de corredores, mientras que la brecha de KB Kookmin afectó a una plataforma de apoyo a empleados.
Hana y BNK Busan informaron de otros entornos afectados. Woori y NH Nonghyup identificaron intentos sin confirmar pérdidas de datos comparables.
La coincidencia temporal y de infraestructura puede respaldar la hipótesis de una campaña. No prueba automáticamente que el mismo exploit, agente o individuo vulnerara todos los objetivos.
La expresión hacking con ARTEX AI también puede crear la falsa impresión de que un modelo seleccionó bancos de forma independiente y derrotó sus defensas. La evidencia disponible describe, en cambio, un entorno dirigido por una persona.
El operador proporcionó prompts, mantuvo servidores, seleccionó herramientas y buscó información financiera coreana. La IA parece haber respaldado la ejecución y el análisis dentro de ese flujo de trabajo.
Las vulnerabilidades tradicionales siguieron siendo esenciales. La autenticación débil, la exposición excesiva de datos, los servicios accesibles desde internet y los identificadores reutilizables dieron a las herramientas algo que explotar.
Sin esas condiciones, un escáner más rápido produciría más solicitudes fallidas en lugar de una brecha de datos. Por tanto, calificar los incidentes como un fallo de IA puede distraer de las carencias básicas de control.
La atribución también sigue siendo incierta. CrowdStrike evaluó con confianza moderada que el operador probablemente hablaba chino y tenía motivación financiera.
Ese juicio se basó en prompts en chino, herramientas desarrolladas en China y actividad orientada a buscar mercados para información robada. No estableció patrocinio estatal ni una organización criminal identificada.
Ningún análisis responsable debería convertir pistas lingüísticas en atribución nacional. Los delincuentes pueden usar herramientas en idiomas extranjeros, prompts copiados, servidores proxy y artefactos deliberadamente engañosos.
El incidente también generó cifras contradictorias de víctimas. Un artículo informó de 119.000 clientes de KB Kookmin, mientras que el banco y varios medios locales informaron de 119.
Esta discrepancia demuestra por qué los totales de las brechas exigen fuentes cuidadosas. Un error numérico repetido puede transformar un incidente grave en un evento sustancialmente distinto.
Por tanto, la versión más defendible es más acotada. Al menos varias instituciones financieras sufrieron ataques con una sincronización estrecha, las brechas confirmadas expusieron información personal sensible y una infraestructura habilitada por IA respaldó parte de la actividad.
Este hallazgo es significativo sin describir el evento como una ciberguerra autónoma. La precisión ayuda a los defensores a centrarse en técnicas observables en lugar de una narrativa no verificada.
Los reguladores pasan de los perímetros a la defensa compartida
La respuesta de Corea del Sur reconoce que un servicio expuesto puede crear riesgos en todo un sector financiero interconectado.
La Comisión de Servicios Financieros indicó a las instituciones que comenzaran inspecciones inmediatas de los sistemas y servicios expuestos externamente. La orden hizo especial hincapié en las debilidades de autenticación, los controles de acceso, las entradas no autorizadas y la exposición innecesaria de información.
El regulador también ordenó a las empresas compartir direcciones IP maliciosas y otra inteligencia sobre amenazas. Los indicadores compartidos pueden ayudar a las instituciones a bloquear infraestructura ya observada contra otro banco.
Sin embargo, las listas de bloqueo tienen una durabilidad limitada. Los atacantes pueden rotar servidores y direcciones proxy más rápido de lo que las organizaciones completan reuniones de emergencia.
La respuesta más duradera consiste en comparar los comportamientos de ataque. Las consultas repetidas de identificadores, el descubrimiento automatizado de endpoints, las secuencias anómalas de solicitudes y el movimiento rápido entre servicios relacionados pueden revelar una campaña.
Los reguladores también deben examinar si las evaluaciones existentes premian los resultados adecuados. Las máximas calificaciones de protección de Shinhan no revelaron la debilidad que, según los informes, permitió la brecha.
Las revisiones de cumplimiento suelen evaluar la gobernanza, las políticas y una amplia cobertura de controles. Los atacantes se centran en la única ruta ignorada que produce datos.
Las futuras evaluaciones necesitarán una validación técnica más profunda. Esto incluye probar servicios externos reales, verificar la autenticación en cada endpoint y comprobar si un identificador desbloquea información en otro lugar.
Los funcionarios surcoreanos también advirtieron sobre el fraude secundario. No se informó de contraseñas ni códigos de un solo uso entre los datos expuestos, pero eso no hace que los registros sean inocuos.
Los nombres, números de teléfono, cifras de ingresos y límites de préstamo pueden hacer más creíble la suplantación de identidad. Un estafador puede referirse a circunstancias financieras reales al ofrecer una refinanciación o un programa de compensación fraudulento.
El 6 de octubre, los reguladores abrieron un período especial de respuesta de un mes, con opción de prorrogarlo. Se instruyó a las compañías financieras para que operaran canales de apoyo dedicados para los clientes afectados.
La alerta de fraude al consumidor advirtió que los delincuentes podrían hacerse pasar por empleados bancarios y ofrecer préstamos favorables, refinanciación o compensación por brechas. También advirtió contra las solicitudes de pagos por adelantado o instalación de aplicaciones.
Las autoridades pidieron a las instituciones reforzar los sistemas de detección de fraude usando los datos filtrados. También planearon utilizar una plataforma basada en IA para compartir y analizar información sobre phishing de voz.
Esto plantea una competencia reveladora. Los atacantes pueden usar IA para escalar el reconocimiento y la explotación, mientras que los bancos pueden usar IA para conectar señales de fraude e identificar comportamientos sospechosos.
La diferencia decisiva vendrá de la velocidad de implementación y la calidad de los datos. Un modelo defensivo no puede proteger un servicio web olvidado que nadie ha incluido en el programa de monitorización.
Las instituciones financieras necesitan un inventario actualizado de endpoints públicos y de la información a la que puede acceder cada endpoint. También necesitan registros de propiedad que indiquen quién mantiene cada servicio.
La respuesta a incidentes depende de un conocimiento interno igualmente accesible. Los equipos de ingeniería y seguridad se benefician de una base de conocimiento con capacidad de búsqueda que conecte la documentación de los servicios, su propiedad y las decisiones de incidentes anteriores.
Ese registro resulta valioso durante una campaña que avanza con rapidez. Los equipos de respuesta pueden identificar a los equipos y las dependencias afectados sin reconstruir el sistema a partir de documentos dispersos.
Los ciberataques contra bancos surcoreanos también sugieren que los sistemas de terceros y contratistas merecen el mismo escrutinio que las aplicaciones principales. El desarrollo externalizado no transfiere la responsabilidad sobre la información de los clientes.
Los bancos deben verificar a qué datos pueden acceder los proveedores, cómo autentican sus sistemas las solicitudes y si los servicios temporales permanecen en línea después de que termine un proyecto.
La respuesta regulatoria solo tendrá éxito si estas inspecciones generan cambios duraderos. Los escaneos de emergencia pueden encontrar exposiciones evidentes, pero la proliferación de aplicaciones recreará el problema sin una propiedad continua.
Tres señales mostrarán si la respuesta funciona
La siguiente fase se medirá por los hallazgos técnicos, el fraude secundario y los cambios permanentes en la supervisión del sector financiero.
La primera señal es el relato de la investigación oficial sobre la infraestructura común y los métodos de ataque. Los investigadores deben determinar qué incidentes comparten servidores, identificadores, rutas de explotación o comportamiento del operador.
Un vínculo confirmado entre varios bancos reforzaría la conclusión de que la automatización asistida por IA permitió a un operador atacar rápidamente a varias instituciones.
Un hallazgo de que las brechas no estaban relacionadas acotaría la historia de ARTEX. También revelaría un problema más amplio de servicios financieros vulnerables de forma independiente.
La segunda señal es la magnitud del daño secundario. Los reguladores han advertido que los datos expuestos sobre ingresos, préstamos e identidad podrían facilitar el phishing de voz personalizado o enfoques de préstamos fraudulentos.
Un fraude confirmado demostraría que el impacto de la brecha fue más allá de la confidencialidad. También pondría a prueba la rapidez con la que los bancos pueden conectar los registros expuestos con transacciones sospechosas e informes de clientes.
La ausencia de fraude confirmado sería bienvenida, pero no eliminaría el riesgo a largo plazo. La información personal puede seguir siendo útil después de que el incidente original desaparezca de los titulares.
La tercera señal es si los reguladores cambian la forma en que se prueba la seguridad financiera. Las inspecciones únicas de sistemas expuestos externamente son una medida inmediata de contención, no una reforma duradera.
Una respuesta más sólida requeriría el descubrimiento continuo de servicios públicos, pruebas repetidas de autenticación y una propiedad clara para cada aplicación que acceda a información personal.
Los reguladores también deberían examinar si las calificaciones de seguridad reflejan una resistencia real a los ataques. El sólido historial de evaluaciones de Shinhan hace difícil evitar esa pregunta.
La campaña ofrece otra advertencia para las organizaciones fuera de Corea del Sur. Los ataques bancarios impulsados por IA no dependen de una pila tecnológica exclusivamente coreana.
Todas las grandes empresas operan portales secundarios, servicios de contratistas, API antiguas y herramientas de conveniencia. Cualquiera de ellos puede exponer información sensible sin tocar el sistema más protegido.
Los equipos de seguridad deberían comenzar planteando una pregunta práctica: ¿Qué servicio accesible desde internet puede recuperar datos de clientes o empleados sin los controles aplicados a la aplicación principal?
Después deberían probar ese servicio frente a intentos sostenidos y automatizados de descubrimiento, enumeración y acceso. El ejercicio debería medir si el comportamiento anómalo se bloquea antes de que los registros salgan del sistema.
Los ciberataques contra bancos surcoreanos no prueban que los agentes autónomos puedan derrotar sin esfuerzo las redes financieras modernas. Muestran algo más inmediato y accionable.
Según se informa, un operador combinó herramientas agénticas, modelos de lenguaje e infraestructura convencional para desplazarse rápidamente entre servicios expuestos. Una autenticación débil hizo el resto.
Los bancos no necesitan predecir cada modelo que utilizará un atacante. Deben eliminar las vías desatendidas que hacen rentable una automatización más rápida y, después, observar si reguladores e investigadores confirman que esas vías se están cerrando.
