Por qué una VPN de 50 años fue el eslabón débil en el ataque a Paru Group
Cuando la VPN heredada de mantenimiento de Paru Group fue víctima de ransomware, esto se propagó por Active Directory y dejó sin operación a 100 servidores. La recuperación, completada en solo 50 días con un traslado a AWS, revela la fragilidad oculta de la infraestructura empresarial japonesa envejecida y lo que esto significa para la resiliencia global de TI.
El vector de ataque que nadie vigilaba
El 16 de junio de 2024, alrededor de 100 servidores de Paru Group se apagaron al mismo tiempo. El correo electrónico dejó de funcionar. El sistema de gestión de ventas se desplomó. Los terminales Punto de Venta en cientos de tiendas perdieron la conexión con la sede central. La compañía ya no podía realizar pedidos ni mover inventarios. Para un grupo minorista que opera marcas como 3COINS, CIAOPANIC y un dix cors en aproximadamente 1.000 tiendas, esto no fue una interrupción: fue un cierre total.
Lo que hizo notable el incidente no fue la magnitud del daño, sino el punto de entrada. La investigación forense reveló que los atacantes no vulneraron primero los sistemas principales del negocio. Entraron a través de una VPN remota dedicada al mantenimiento, un sistema que había envejecido y permanecía sin supervisión. Desde allí, pasaron a un servidor de gestión de asistencia obsoleto, y desde ese servidor comprometieron el controlador de dominio de Active Directory. Una vez que AD cayó, todos los dispositivos bajo su control quedaron accesibles. Todo el centro de datos se vino abajo con él.
Esta secuencia cuenta una historia que se repite en las TI empresariales japonesas y que el análisis en inglés rara vez enmarca con claridad: el ataque no apuntaba a las joyas de la corona. Apuntaba a la infraestructura que nadie consideraba necesaria proteger porque no formaba parte de la capa de negocio.
Quién es dueño de la brecha entre sistemas antiguos y amenazas nuevas
Paru Group es una sociedad holding de moda y mercadería general, que administra alrededor de 50 marcas. Su arquitectura de TI antes del ataque seguía un patrón común en corporaciones japonesas de mediano a gran tamaño: un centro de datos centralizado con aproximadamente 100 servidores físicos, todos conectados a través de herramientas heredadas de acceso remoto que precedían al pensamiento moderno de zero-trust. La VPN de mantenimiento, el sistema de asistencia, la infraestructura de Active Directory: eran más antiguas que las estrategias en la nube que la compañía había comenzado a discutir en privado.
La consecuencia de esa brecha de antigüedad no fue meramente técnica. Fue organizacional. Las decisiones de seguridad sobre esos sistemas habían sido postergadas durante años. La VPN aún estaba en uso porque nadie había construido un reemplazo. El servidor de asistencia permanecía on-premise porque la migración nunca se priorizó. Cuando los atacantes encontraron ese camino, encontraron un pasillo que se había dejado desbloqueado.
守山宗行 de Paru Group, líder de la división de coordinación de TI, describió el postataque como un período de casi silencio en la sede central y una avalancha de llamadas de emergencia desde las tiendas. La compañía tuvo que tomar decisiones inmediatas bajo extrema incertidumbre. La primera fue cortar la conectividad a Internet por completo, lo que detuvo la propagación pero también detuvo las operaciones. La segunda fue reconstruir la conectividad para las tiendas sin reexponer la red comprometida.
El recurso que mantuvo abiertas las tiendas
La respuesta a incidentes de Paru Group reveló una verdad práctica sobre las TI del retail: la sede puede caer y el piso de venta debe seguir operando. La compañía ya había separado su plataforma de comercio electrónico, PAL CLOSET, y su infraestructura de redes sociales de la red principal, una decisión que puede haberse tomado por razones de rendimiento más que de seguridad, pero que resultó decisiva. Esos sistemas sobrevivieron ilesos.
Para las restantes 1.000 tiendas, la compañía distribuyó aproximadamente 900 unidades de pocket Wi-Fi. La sede reemplazó las PCs infectadas y utilizó el circuito aislado de SNS para restaurar el acceso a Internet. Esta no era una estrategia de recuperación. Era triaje. Pero compró el tiempo necesario para ejecutarla.
El giro de 50 días hacia la nube
El elemento más llamativo de la respuesta de Paru Group no fue el containment inicial, sino la velocidad de la reconstrucción. Se evaluaron tres opciones: reconstruir en un entorno separado dentro del centro de datos existente, contratar una nueva instalación con TOKAI Communications, o migrar a AWS.
La adopción de la nube había enfrentado previamente resistencia ejecutiva de quienes preferían el control on-premise. El ataque cambió ese cálculo casi instantáneamente. La migración a AWS fue aprobada, y la meta se fijó para finales de septiembre de 2024.
Luego apareció una restricción adicional. Paru Group estaba adquiriendo la marca de moda femenina w closet, con el cierre de la transacción a finales de agosto. El sistema de gestión de ventas debía estar operativo antes de que la adquisición pudiera proceeder sin contratiempos. La fecha límite avanzó. El proyecto se comprimio de lo que habría sido una transformación anual a un sprint de 50 días.
La migración a AWS se completó el 5 de agosto. La adquisición de w closet siguió a finales de mes sin demora. TOKAI Communications proporcionó el soporte de integración que hizo viable el cronograma, una firma que opera una de las redes privadas MPLS más grandes de Japón con aproximadamente 2.300 líneas de red cerrada conectadas a AWS, según sus representantes.
Cómo se ve la nueva arquitectura
La infraestructura posterior al ataque es notablemente más sencilla que la versión anterior. La antigua red privada estrecha fue reemplazada por el servicio de carrier BroadLine de TOKAI Communications, y la conexión a AWS se reconstruyó utilizando AWS Direct Connect con redundancia. El despliegue de SD-WAN en aproximadamente 1.000 ubicaciones de tiendas se completó en aproximadamente una semana, reemplazando la topología más antigua de IP-VPN.
Los controles de seguridad se fortalecieron sustancialmente. El tráfico a Internet se consolidó a través de un dispositivo UTM unificado con todos los logs alimentando una plataforma SIEM. La autenticación pasó de solo login en AD a autenticación basada en certificados con autenticación multifactor agregada. Amazon GuardDuty y AWS Security Hub se desplegaron junto con agentes EDR en cada instancia EC2.
El ejercicio de recuperación ante desastres realizado después de la restauración demostró la magnitud de la mejora: un proceso que anteriormente requería aproximadamente dos meses para recuperarse se completó en unas seis horas.
Por qué esto importa más allá de Japón
La experiencia de Paru Group no es una excepción. Es un modelo. El patrón —VPN heredada, servidor antiguo, compromiso de AD, falla en cascada— es cada vez más común mientras las empresas posponen los ciclos de renovación de infraestructura y las amenazas cibernéticas evolucionan más rápido que los procesos de adquisición. Lo que distingue el caso de Paru Group es la velocidad y claridad de la respuesta, y la disposición a usar una crisis como palanca para una migración que ya estaba planeada pero estancada.
La señal más amplia es que las organizaciones deberían dejar de tratar a los sistemas internos antiguos como de bajo riesgo. La VPN de mantenimiento no es infraestructura benigna. A menudo es el punto más débil de la red porque fue diseñada para la conveniencia, no para la defensa, y frecuentemente se olvida hasta que es explotada.
守山 de Paru Group afirmó que la compañía ahora opera bajo la suposición de que la prevención al 100% es imposible. La estrategia ha cambiado hacia la detección temprana y la limitación del daño. Esa es una postura realista para una industria que ha pasado décadas construyendo muros de seguridad alrededor de las cosas equivocadas.
Qué sigue
Paru Group continuará revisiones operativas semanales con TOKAI Communications y se espera que expanda las capacidades de AWS más allá del alcance inicial de recuperación. Los resultados de las pruebas de DR sugieren que la compañía ahora tiene una posición de respaldo creíble que no existía antes del ataque.
Para la comunidad más amplia de TI empresarial, la lección es concreta: revise sus caminos de acceso heredados este trimestre. La VPN que heredó de un proveedor anterior, el sistema de asistencia corriendo en un servidor que nadie puede fechar, el bosque de AD que ha crecido sin gestión: no son ruido de fondo. Son el punto de entrada más probable para el próximo incidente.
Paru Group sobrevivió porque actuó rápido y porque tenía al menos un sistema —PAL CLOSET— que estaba aislado del resto. Las compañías que no tengan esa suerte aprenderán la misma lección de una manera más difícil.