Una conversación real sobre cómo desplegar una VPN empresarial en una subscripción compartida de IA acumuló el suficiente material criptográfico como para orquestar un ciberataque. Este artículo reconstruye el caso con datos anonimizados y señala las posibles consecuencias del mal uso de estas suscripciones compartidas de IA. Cabe destacar que en ningún momento se comprometió la infraestructura expuesta.
Como se expuso en un artículo previo, el acceso suscripciones compartidas de inteligencia se ha convertido en una alternativa económica a las suscripciones individuales por unos pocos euros al mes. En ese, se hizo especial hincapié en el peligro de ser incapaz de acceder y eliminar datos personales sensibles en dichos chats. No obstante, en este nuevo artículo —que ya abre una pequeña vía de investigación— se expondrá el peligro instantáneo de la filtración de datos de carácter técnico-empresarial a través de un caso real.
Como parte de nuestra investigación, tras acceder a una de las cuentas auditadas, observamos que un usuario estaban utilizando sus suscripciones compartidas para resolver incidencias relacionadas con infraestructuras empresariales reales, introduciendo información y datos críticos de sus empresas.
Tras revisar los chats, conversaciones en la que un directivo trataba de configurar una VPN para permitir que varios trabajadores de su empresa pudieran acceder desde casa a un servidor situado en la oficina, se considero que compartir este caso serviría para alertar de este peligro.
Los hechos
El chat nos permite recuperar que la primera idea de nuestro ‘sujeto X’ fue utilizar un router MikroTik, pero que a medida que la configuración planteaba dificultades y surgían nuevas necesidades, el diseño fue evolucionando hasta terminar utilizando un TP-Link ER605 como gateway de la red y punto de terminación de una VPN WireGuard.
Su conversación terminó reuniendo el modelo y firmware del gateway, información sobre el router del operador, estructura de la LAN, direccionamiento, DHCP, datos sobre un servidor Windows, el endpoint de la VPN, las redes que debía alcanzar el cliente y material criptográfico de WireGuard. El historial permitía comprender cómo estaba construida la infraestructura y como veremos más adelante, como acceder a ella ‘por la puerta grande’.
De investigar privacidad a encontrar una red empresarial
La información encontrada en el historial del chat nos permitió reconstruir parte de la configuración de la VPN. Entre esos datos aparecieron elementos propios de WireGuard, como las claves utilizadas para identificar a los peers, es decir, los dispositivos que participan en la conexión, y el parámetro AllowedIPs, que forma parte de su modelo de cryptokey routing y relaciona esos dispositivos con las direcciones que pueden utilizar a través del túnel.
Por separado, estos datos podían parecer simples fragmentos de configuración. Sin embargo, al leer la conversación completa, era posible relacionarlos entre sí y obtener una imagen mucho más clara de la infraestructura. Pudimos identificar qué tecnología VPN utilizaba la empresa, qué dispositivo gestionaba la conexión, a qué dirección debía conectarse el cliente y qué parte de la red interna se quería alcanzar.
Esto no significa que disponer de esos datos permitiera acceder automáticamente a toda la red. En la conversación también aparecía un ER605, un dispositivo compatible con WireGuard que permite aplicar reglas de firewall y controlar qué conexiones están autorizadas. Por tanto, aunque alguien consiguiera conectarse a la VPN, el acceso a la red interna podía seguir estando limitado por esas reglas de seguridad.
La clave privada permite la conexion
Durante la conversación se encontró la clave privada de uno de los peers de WireGuard. Este dato es especialmente sensible porque permite identificarse ante la VPN como ese dispositivo y podría facilitar un intento de acceso a la red empresarial. También aparecieron claves correspondientes a ambos extremos de la conexión.
Aun así, encontrar la clave no significa que se directamente hubiesemos podido acceder a la empresa. El dispositivo podía haber sido eliminado, la configuración podía haber cambiado o el firewall podía impedir la conexión. Nunca lo sabremos ya que durante la investigación no se comprobó ninguna de estas posibilidades.
Cabe recordar que, aunque el artículo se centra en la clave del cliente por ser el vector más relevante a la hora de establecer un posible acceso indebido, cualquier clave privada expuesta debería considerarse comprometida y sustituirse.
Escenario simulado: de ChatGPT al acceso inicial
A partir de este punto entramos en una simulación técnica. Supongamos que la configuración sigue vigente, que el peer encontrado continúa autorizado y que las políticas del ER605 permiten a esa identidad alcanzar al menos una parte de la LAN indicada durante la configuración.
En estas condiciones, el primer objetivo de un atacante sería intentar reproducir la identidad del cliente legítimo y establecer el túnel. No estaría explotando una vulnerabilidad de WireGuard ni un fallo del TP-Link. Estaría abusando de una identidad que nunca debería haber quedado expuesta desde el chat de la IA.
Si el gateway aceptase esa identidad, se produciría el cambio realmente importante. Antes, el atacante estaba en Internet y solo podía interactuar con aquello que la organización hubiera publicado hacia el exterior; ahora, en posición de red distinta, dispondría de conectividad hacia los recursos que el routing y las políticas del gateway permitieran alcanzar desde ese peer.
¿Qué aparece al otro lado del túnel?
Aquí es importante distinguir entre conectividad y privilegios. Conseguir establecer una conexión mediante WireGuard no convierte al atacante en administrador, no desactiva el firewall ni implica que toda la red local (LAN) sea accesible.
El cliente VPN se encuentra dentro de una red enrutada y es el ER605 el que decide, mediante sus reglas, qué tráfico puede circular hacia otros segmentos. Del mismo modo, que una red aparezca dentro de AllowedIPs significa que el cliente espera poder alcanzarla a través del túnel, pero no garantiza que todos los equipos de esa red acepten conexiones.
Si existiera conectividad, comenzaría entonces una fase de reconocimiento interno. El objetivo sería identificar qué recursos pueden alcanzarse desde esa nueva posición: estaciones de trabajo, servidores, sistemas de almacenamiento, impresoras, aplicaciones internas, servicios administrativos o infraestructura de autenticación. Incluso sin comprometer ningún otro sistema, esta fase podría revelar nombres de equipos, servicios internos, sistemas operativos, nomenclatura corporativa, recursos compartidos o relaciones entre distintos dispositivos.
El segundo punto de apoyo
La VPN sería el primer punto de apoyo dentro de la infraestructura. Para avanzar desde ahí, el atacante necesitaría encontrar una segunda debilidad en alguno de los sistemas accesibles, como una vulnerabilidad, credenciales débiles o una configuración insegura.
Si lograra comprometer otro equipo, podría iniciar un movimiento lateral por la red o incluso una escalada de privilegios. WireGuard no proporciona por sí mismo ninguna de estas capacidades: únicamente facilita la conectividad inicial.
Definimos el segundo foothold como un nuevo punto de apoyo dentro de la intrusión. En este caso, el atacante ya habría conseguido acceder a un equipo de la red interna, al que denominamos host comprometido.
Ese host puede ofrecer capacidades que el peer original de WireGuard no tenía: acceso legítimo a otros recursos, rutas diferentes, credenciales disponibles para usuarios o servicios y relaciones de confianza con otros sistemas.
A partir de este momento comienza una nueva fase de la intrusión.
Movimiento lateral y pivoting
El movimiento lateral y el pivoting están relacionados, pero no significan exactamente lo mismo. El movimiento lateral consiste en aprovechar el acceso conseguido para intentar alcanzar otros sistemas de la organización. El pivoting, en cambio, utiliza un equipo ya comprometido como puente para acceder a recursos o segmentos de red que no eran directamente alcanzables desde la posición inicial.
Imaginemos que el peer WireGuard puede alcanzar únicamente una primera red, pero no un segmento utilizado para administración. Si posteriormente se compromete un servidor que sí dispone de comunicación autorizada hacia ese segundo entorno, el servidor puede convertirse en el pivote que modifica el alcance de la intrusión.
Aquí la arquitectura defensiva se vuelve decisiva. Una VPN limitada, firewalls entre segmentos, privilegio mínimo y redes de administración correctamente separadas pueden contener el daño aunque una identidad remota se vea comprometida. Una red plana o con reglas excesivamente permisivas facilita esta progresión en la intrusión.
¿Qué información podría terminar capturándose?
En los escenarios habituales pueden quedar expuestas distintos tipos de datos:
- Infraestructura: nombres de equipos, DNS interno, rutas, configuraciones, servicios o inventario de sistemas.
- Identidades: usuarios, grupos, permisos y relaciones de confianza.
- Secretos: tokens, certificados, claves o credenciales almacenadas por sistemas comprometidos para poder realizar sus funciones.
- Información empresarial: documentos, recursos compartidos, aplicaciones internas o datos a los que las cuentas comprometidas tengan acceso.
- Metadatos de comunicaciones: qué sistemas contactan entre sí, cuándo y mediante qué protocolos, siempre dependiendo de la posición conseguida (existe una diferencia importante entre conocer esos metadatos y poder leer el contenido de las comunicaciones).
Estar dentro no significa poder escuchar toda la red
Estar conectado a la VPN no significa poder observar todo lo que ocurre dentro de la red de la empresa. Un peer de WireGuard no pasa a formar parte automáticamente de la misma red local que todos los equipos de la oficina.
WireGuard proporciona conectividad mediante routing, por lo que el cliente solo recibe el tráfico que la red le permite alcanzar. El tráfico entre otros equipos no se copia automáticamente hacia la VPN y mecanismos de red local como ARP no atraviesan el router. Por tanto, un atacante no podría simplemente abrir un capturador de tráfico y empezar a observar las comunicaciones del ordenador del director.
Para llegar a una posición desde la que pudiera interceptar ese tráfico tendría que comprometer algún elemento adicional, como el propio equipo, un gateway o algún sistema situado en el recorrido de esas comunicaciones. Incluso en ese caso, protocolos cifrados como HTTPS, TLS o SSH seguirían protegiendo buena parte del contenido.
Conclusión
Lo más relevante de este caso no es únicamente que una conversación contuviera datos técnicos sensibles, sino la facilidad con la que esos datos fueron acumulándose hasta ofrecer una imagen bastante completa de una infraestructura real.
Para un administrador de sistemas, recurrir a una IA puede resultar especialmente útil. Cuanto más contexto se aporta, más fácil es que el modelo comprenda la arquitectura, detecte errores o proponga una solución concreta. Sin embargo, esa misma lógica obliga a plantearse una segunda pregunta: ¿qué información estamos entregando para obtener esa ayuda?
Cuando se trabaja con infraestructuras de clientes o de una empresa, ya no se trata únicamente de proteger datos personales. También deben considerarse sensibles las configuraciones de red, direcciones IP, nombres de equipos, rutas, credenciales, claves privadas, tokens o cualquier otro dato que pueda ayudar a reconstruir cómo funciona la infraestructura. Información que para un administrador puede parecer rutinaria puede tener un valor muy distinto para alguien que intenta analizar o atacar esa red.
Por eso, antes de copiar una configuración o una incidencia completa en un asistente de IA, debería aplicarse el mismo criterio que se utilizaría al compartir información con cualquier tercero: eliminar aquello que no sea necesario, anonimizar los datos del cliente y sustituir cualquier secreto o identificador sensible. La utilidad de la herramienta no debería hacer olvidar quién puede terminar teniendo acceso a la información introducida.
En este caso, la IA no rompió WireGuard ni explotó una vulnerabilidad del TP-Link ER605, si no que la vulnerabilidad fue la profesionalidad de un individuo. En esta historial real, un atacante no habría necesitado buscar siquiera una vulnerabilidad técnica, habría empezado leyendo una conversación.
Metodología y límites de la investigación
ARAINTEL no utilizó ninguna de las claves, direcciones o configuraciones encontradas para intentar conectarse a la infraestructura. Tampoco comprobó si las claves continuaban vigentes ni interactuó con los sistemas identificados.
Todas las direcciones, dominios y secretos mostrados en este artículo son sintéticos o están censurados. El escenario de intrusión se utiliza para explicar de forma teórica y didáctica qué consecuencias técnicas podría tener la exposición si las condiciones descritas se cumplieran.
Nada de lo anterior demuestra que la organización haya sido comprometida ni que el movimiento lateral o el pivoting fueran posibles en su entorno real.
Fuentes
-Documentación oficial de WireGuard, incluyendo el modelo de «Cryptokey routing» y la gestión de claves. WireGuard — documentación oficial
-Especificaciones oficiales del TP-Link ER605 V2, incluidas sus capacidades WireGuard y funciones de control de acceso. TP-Link — ER605 V2
-Análisis del National Cyber Security Centre sobre los riesgos derivados del «Shadow AI» y el tratamiento de información empresarial mediante servicios no controlados. NCSC — The hidden risks of shadow AI
