Caso real: cómo demostramos un fraude online por valor de 80.000€

Una pyme del sector industrial recibió un correo aparentemente del director financiero solicitando una transferencia urgente de 80.000€ a un proveedor “habitual”. El email tenía la firma corporativa, el tono coincidía con el del directivo y mencionaba un proyecto que la empresa realmente tenía en marcha. La transferencia se ejecutó. Tres horas después se descubrió que el correo era falso y el dinero ya estaba fuera de la cuenta.

Este artículo cuenta cómo Forenlab —con consentimiento del cliente y los datos anonimizados— investigó el caso, qué evidencias forenses fueron determinantes y cómo el informe pericial se convirtió en la base de la denuncia y la posterior reclamación al banco.

La situación inicial

El cliente nos contactó 48 horas después del fraude. La cuenta de destino ya había sido vaciada en parte y el banco se negaba a asumir responsabilidad alegando “negligencia del cliente al no verificar”. El abogado nos pidió un informe pericial que demostrara dos cosas:

1. Que el fraude era de alta sofisticación — no una negligencia básica del empleado.
2. Que existían fallos de seguridad razonablemente atribuibles al banco en la detección de patrones sospechosos.

Fase 1 — Aseguramiento de evidencias

Lo primero fue detener cualquier alteración del estado del sistema. Nuestro equipo se desplazó a las oficinas con material de cadena de custodia y procedió a:

• Clonado bit a bit de los discos duros de las dos personas implicadas (la asistente que ejecutó la transferencia y el director financiero suplantado).
• Adquisición de los logs del servidor de correo corporativo (Microsoft 365) en el rango de fechas del incidente.
• Captura del estado de la red y firewall: conexiones, NAT, políticas de filtrado.
• Firma de acta de cadena de custodia con los hashes MD5 y SHA-256 de cada evidencia.

Para profundizar en este paso, ver: cadena de custodia digital.

Fase 2 — Análisis del email fraudulento

El correo recibido tenía remitente director.financiero@empresa.com. Sin embargo, al analizar las cabeceras descubrimos:

Received: from mail.servidor-falso.ru ([195.X.X.X])
    by smtp.cliente.com with ESMTPS
    via Microsoft 365 inbound relay;
    Mon, 14 Apr 2026 09:12:38 +0200
From: "Director Financiero" <director.financiero@empresa.com>
Reply-To: director.financiero@empresa-falsa-mx.com

Tres elementos clave:

1. El Received real apuntaba a un servidor en Rusia, no al servidor corporativo de la empresa.
2. La cabecera From estaba suplantada (técnica de email spoofing común).
3. El Reply-To (campo invisible para el usuario) redirigía a un dominio diferente — uno que se había registrado 17 días antes del fraude.

Este último dato es decisivo. Un atacante registró un dominio similar al corporativo, configuró infraestructura de email y esperó tres semanas antes de lanzar el ataque. No es phishing oportunista — es phishing dirigido (spear phishing) preparado contra la empresa específica.

Si quieres profundizar en cómo se analiza un email, lee: cómo identificar al autor de un correo electrónico anónimo.

Fase 3 — La cuenta de destino

El banco facilitó (mediante orden judicial) los datos de la cuenta de destino. Era una cuenta abierta 22 días antes del fraude, en una sucursal ubicada en una ciudad lejana al domicilio del titular, con documentación que el peritaje notarial posterior demostró manipulada.

Los movimientos eran reveladores:

• 80.000€ entran el día del fraude.
• A las 4 horas, la cuenta inicia una cascada de traspasos a 7 cuentas distintas (3 nacionales + 4 extranjeras).
• Cada operación está bajo el umbral de detección antiblanqueo (los famosos 9.999€).
• En 18 horas la cuenta queda con saldo cero.

Esta operativa es tan típica de redes organizadas de blanqueo que el informe pericial pudo afirmar, con respaldo bibliográfico, que el patrón de movimientos era incompatible con un titular legítimo de la cuenta.

Fase 4 — Los fallos de seguridad del banco

Aquí es donde el peritaje resultó decisivo para la reclamación. Documentamos:

• El banco no validó SPF/DMARC sobre el dominio de origen del correo (el dominio del atacante no tenía DMARC y eso debería haber lanzado una alerta de antifraude).
• El patrón de transferencia (importe alto, beneficiario nuevo, cuenta de reciente creación) cumplía tres de los cinco criterios del propio manual antifraude del banco — y aun así no se generó alerta.
• Los traspasos posteriores fueron procesados sin ninguna intervención humana pese a coincidir con un patrón de blanqueo de manual.

Fase 5 — Informe pericial y resultado

El informe pericial entregado al juzgado tenía 74 páginas, 12 anexos con evidencias técnicas y una conclusión clara:

El fraude no fue resultado de una negligencia básica del empleado, sino de un ataque de spear phishing planificado durante semanas. Existen indicios técnicos, documentados con cadena de custodia, de que el banco omitió controles antifraude que su propio manual interno establece como obligatorios para operaciones de este perfil.

Resultado del caso

• Denuncia penal: admitida a trámite por estafa informática y falsedad documental. La policía judicial está investigando la red de blanqueo en colaboración con Europol.
• Reclamación bancaria: el banco aceptó devolver el 70% del importe (56.000€) en mediación extrajudicial tras leer el informe pericial. La reclamación judicial sigue su curso por el 30% restante.
• Mejoras internas: la pyme implementó un protocolo de doble validación para transferencias por encima de 5.000€.

Lecciones aprendidas

Este caso, lejos de ser excepcional, es cada vez más frecuente en pymes españolas. Lo que lo distingue de otros similares no es el ataque en sí —que es de manual— sino la velocidad de respuesta:

• Las 48 horas entre el fraude y nuestro contacto fueron clave: si hubieran pasado 7 días, varios de los logs del banco ya no estarían disponibles bajo política de retención.
• El clonado inmediato de los equipos preservó los archivos del navegador y caché de DNS que ayudaron a reconstruir la cronología.
• La denuncia simultánea a la reclamación civil multiplicó la presión sobre el banco para llegar a acuerdo.

Si tu empresa quiere prevenirlo

Tres medidas, en orden de impacto:

1. Doble validación humana en transferencias por encima de un umbral (recomendado: 3.000€ para pymes).
2. DMARC con política reject en tu dominio corporativo. Esto bloquea físicamente que tu propio dominio pueda ser suplantado en correos.
3. Formación trimestral al personal con simulacros reales de phishing dirigido — no genéricos, sino con datos de tu empresa.

Si quieres que evaluemos el riesgo de tu pyme antes de que pase algo, podemos hacer una auditoría preliminar que incluye análisis del estado DMARC, exposición del personal en redes (vector clásico para spear phishing) y revisión del protocolo financiero. Ver más en servicios periciales o contacta directamente para una valoración inicial sin compromiso.