El hombre en el medio: cómo un atacante invisible robó 340.000 € sin tocar un solo servidor

Todo empezó con una decisión que Nexalia tomó en 2023 y que en ese momento pareció perfectamente razonable: instalar un punto de acceso WiFi en la sala de reuniones del cliente para que los consultores pudieran trabajar cómodamente durante las visitas. El router era un modelo doméstico de gama media. La contraseña era el nombre de la empresa seguido de cuatro números. Nadie la había cambiado en dos años.

El atacante —al que los forenses identificarían más tarde como un individuo con conocimientos técnicos medios-altos, probablemente actuando en solitario— llevaba semanas estudiando a Nexalia. Había revisado su web, su LinkedIn, los perfiles de sus consultores, los comunicados de prensa de sus clientes. Sabía que Nexalia tenía un proyecto activo con Industrias Ferrán, un fabricante de componentes de automoción con sede en Castellón. Sabía que ese proyecto estaba en fase de cierre. Y sabía que en los cierres de proyecto se emiten facturas grandes.

El 12 de octubre de 2025, el atacante se conectó a la red WiFi de la sala de reuniones de Nexalia desde el aparcamiento del edificio. Con una antena direccional de largo alcance —el tipo que se vende en Amazon por menos de 40 euros— y una distribución Linux especializada en auditorías de red, tardó menos de cuatro minutos en obtener la contraseña por fuerza bruta. A las 11:47 de la mañana, estaba dentro de la red interna de Nexalia.

Lo que hizo a continuación no fue instalar nada. No tocó ningún servidor. No descargó ningún archivo. Simplemente ejecutó un ataque de ARP spoofing: envió mensajes falsos a la red local para que todos los dispositivos creyeran que su dirección MAC era la del router. A partir de ese momento, todo el tráfico de red de la oficina pasaba primero por su portátil antes de llegar a internet. Era el hombre en el medio. Y nadie lo sabía.

«Lo más perturbador del análisis forense no fue lo que encontramos. Fue lo que no encontramos. No había rastro de intrusión en ningún servidor. No había malware. No había archivos modificados. El atacante no dejó nada porque no necesitó entrar en nada. Solo escuchó.»

Durante las tres semanas siguientes, el atacante no hizo nada visible. Volvía cada dos o tres días al aparcamiento, se conectaba a la red y descargaba el tráfico interceptado. Era paciente. Metódico. Sabía exactamente qué estaba buscando.

El tráfico HTTPS —que representa la mayoría de las comunicaciones web modernas— estaba cifrado y era ilegible. Pero no todo el tráfico de Nexalia era HTTPS. El servidor de correo interno usaba una configuración SMTP sin cifrado forzado. Algunas aplicaciones de gestión interna se comunicaban por HTTP plano. Y lo más crítico: el cliente de email de escritorio de varios empleados tenía desactivada la verificación estricta de certificados SSL, una configuración heredada de una migración de servidor dos años atrás que nadie había revisado.

Con toda esa información, el atacante tenía algo más valioso que cualquier contraseña: tenía contexto. Sabía cómo hablaban entre sí Nexalia y Ferrán. Sabía quién firmaba los emails. Sabía qué palabras usaban, qué tono tenían, qué nivel de formalidad. Podía escribir un email de Nexalia que Ferrán no distinguiría del original aunque lo comparara con los anteriores.

El 3 de noviembre, Nexalia envió la factura final a Industrias Ferrán. El email salió del servidor de Nexalia, llegó al atacante, que lo leyó, lo dejó pasar sin modificar y lo reenvió a Ferrán. Era el ensayo general. Al día siguiente, el atacante envió su propio email.

El 4 de noviembre a las 9:14 de la mañana, el director financiero de Industrias Ferrán recibió un email de Nexalia. O al menos eso creyó. El remitente era facturacion@nexalia-consulting.es. La firma era idéntica a la de todos los emails anteriores. El tono era el de siempre. El asunto: «RE: Factura final Proyecto Transformación — Actualización datos bancarios».

Roberto Mas, el director financiero de Ferrán, leyó el email a las 9:31. Lo encontró completamente normal. Había recibido decenas de emails de Elena Vidal en los últimos meses. El tono era el mismo. La firma era la misma. El cambio de banco era inusual, sí, pero no insólito: su propia empresa había cambiado de banco el año anterior. Reenvió el email a su asistente con una nota: «Actualiza los datos de Nexalia en el sistema y procesa el pago de la factura 2025-0847».

A las 14:23 del mismo día, Industrias Ferrán transfirió 342.800 euros a la cuenta del atacante.

Nexalia no recibió ninguna notificación. El atacante había bloqueado selectivamente los emails de confirmación de pago que Ferrán envió automáticamente. Para cuando Nexalia llamó a Ferrán tres días después para preguntar por el estado del pago, el dinero llevaba 72 horas en una cuenta en un banco de Europa del Este. Desde allí, había sido fragmentado en 23 transferencias menores y distribuido a través de una red de cuentas mula en seis países diferentes.

El 7 de noviembre, Elena Vidal llamó a Roberto Mas para hacer seguimiento del pago. La conversación duró cuatro minutos y cambió la vida de mucha gente.

Ferrán llamó a su banco a las 11:23. La transferencia había salido el martes a las 14:23. Habían pasado 73 horas. El banco confirmó lo que todos temían: el dinero había abandonado el sistema bancario español en menos de dos horas. La orden de recuperación internacional —el llamado recall bancario— se activó de inmediato, pero con 73 horas de ventaja y una red de cuentas mula en seis países, las posibilidades de recuperación eran mínimas.

Recuperaron 18.400 euros. El resto desapareció.

En los ataques de este tipo, el daño económico directo es solo la punta del iceberg. Lo que viene después —la investigación, los litigios, la pérdida de confianza, la parálisis operativa— suele costar tanto o más que el robo inicial.

Un ataque Man-in-the-Middle de esta sofisticación no requiere vulnerabilidades de día cero ni recursos de Estado. Requiere que la empresa víctima tenga una combinación de descuidos técnicos y procedimentales que, por separado, parecen menores. Juntos, son letales.

Ninguna de las medidas que habrían evitado este ataque era cara ni compleja. La mayoría son configuraciones o procedimientos que cualquier empresa puede implementar en días. El problema no era la falta de recursos: era la falta de conciencia de que el riesgo existía.

El caso de Nexalia es un ejemplo de MITM combinado con Business Email Compromise (BEC). Pero los ataques Man-in-the-Middle tienen muchas variantes, y entender cómo funcionan es el primer paso para protegerse.

Preguntas frecuentes sobre ataques MITM