Caso real: como demostramos unha fraude en liña de 80.000€

Unha peme do sector industrial recibiu un correo aparentemente do director financeiro que solicitaba unha transferencia urxente de 80.000€ a un provedor “habitual”. O email tiña a sinatura corporativa, o ton coincidía co do directivo e mencionaba un proxecto que a empresa realmente tiña en marcha. A transferencia executouse. Tres horas despois descubriuse que o correo era falso e o diñeiro xa estaba fóra da conta.

Este artigo conta como Forenlab —co consentimento do cliente e os datos anonimizados— investigou o caso, que evidencias forenses foron determinantes e como o informe pericial se converteu na base da denuncia e da posterior reclamación ao banco.

A situación inicial

O cliente contactou connosco 48 horas despois da fraude. A conta de destino xa fora baleirada en parte e o banco negábase a asumir responsabilidade alegando “neglixencia do cliente por non verificar”. O avogado pediunos un informe pericial que demostrase dúas cousas:

1. Que a fraude era de alta sofisticación — non unha neglixencia básica do empregado.
2. Que existían fallos de seguridade razoablemente atribuíbles ao banco na detección de patróns sospeitosos.

Fase 1 — Aseguramento de evidencias

O primeiro foi deter calquera alteración do estado do sistema. O noso equipo desprazouse ás oficinas con material de cadea de custodia e procedeu a:

• Clonado bit a bit dos discos duros das dúas persoas implicadas (a asistente que executou a transferencia e o director financeiro suplantado).
• Adquisición dos logs do servidor de correo corporativo (Microsoft 365) no intervalo de datas do incidente.
• Captura do estado da rede e do firewall: conexións, NAT, políticas de filtrado.
• Sinatura de acta de cadea de custodia cos hashes MD5 e SHA-256 de cada evidencia.

Para afondar neste paso, ver: cadea de custodia dixital.

Fase 2 — Análise do email fraudulento

O correo recibido tiña remitente [email protected]. Porén, ao analizar as cabeceiras 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" <[email protected]>
Reply-To: [email protected]

Tres elementos clave:

1. O Received real apuntaba a un servidor en Rusia, non ao servidor corporativo da empresa.
2. A cabeceira From estaba suplantada (técnica de email spoofing común).
3. O Reply-To (campo invisible para o usuario) redirixía a un dominio diferente — un que se rexistrara 17 días antes da fraude.

Este último dato é decisivo. Un atacante rexistrou un dominio similar ao corporativo, configurou infraestrutura de email e agardou tres semanas antes de lanzar o ataque. Non é phishing oportunista — é phishing dirixido (spear phishing) preparado contra a empresa específica.

Se queres afondar en como se analiza un email, le: como identificar o autor dun correo electrónico anónimo.

Fase 3 — A conta de destino

O banco facilitou (mediante orde xudicial) os datos da conta de destino. Era unha conta aberta 22 días antes da fraude, nunha sucursal situada nunha cidade afastada do domicilio do titular, con documentación que a peritaxe notarial posterior demostrou manipulada.

Os movementos eran reveladores:

• 80.000€ entran o día da fraude.
• Ás 4 horas, a conta inicia unha cascada de traspasos a 7 contas distintas (3 nacionais + 4 estranxeiras).
• Cada operación está por debaixo do límite de detección antibranqueo (os famosos 9.999€).
• En 18 horas a conta queda con saldo cero.

Esta operativa é tan típica de redes organizadas de branqueo que o informe pericial puido afirmar, con respaldo bibliográfico, que o patrón de movementos era incompatible cun titular lexítimo da conta.

Fase 4 — Os fallos de seguridade do banco

Aquí é onde a peritaxe resultou decisiva para a reclamación. Documentamos:

• O banco non validou SPF/DMARC sobre o dominio de orixe do correo (o dominio do atacante non tiña DMARC e iso debería ter lanzado unha alerta antifraude).
• O patrón de transferencia (importe alto, beneficiario novo, conta de recente creación) cumpría tres dos cinco criterios do propio manual antifraude do banco — e aínda así non se xerou alerta.
• Os traspasos posteriores foron procesados sen ningunha intervención humana a pesar de coincidir cun patrón de branqueo de manual.

Fase 5 — Informe pericial e resultado

O informe pericial entregado ao xulgado tiña 74 páxinas, 12 anexos con evidencias técnicas e unha conclusión clara:

A fraude non foi resultado dunha neglixencia básica do empregado, senón dun ataque de spear phishing planificado durante semanas. Existen indicios técnicos, documentados con cadea de custodia, de que o banco omitiu controis antifraude que o seu propio manual interno establece como obrigatorios para operacións deste perfil.

Resultado do caso

• Denuncia penal: admitida a trámite por estafa informática e falsidade documental. A policía xudicial está a investigar a rede de branqueo en colaboración con Europol.
• Reclamación bancaria: o banco aceptou devolver o 70% do importe (56.000€) en mediación extraxudicial tras ler o informe pericial. A reclamación xudicial segue o seu curso polo 30% restante.
• Melloras internas: a peme implementou un protocolo de dobre validación para transferencias por riba de 5.000€.

Leccións aprendidas

Este caso, lonxe de ser excepcional, é cada vez máis frecuente en pemes españolas. O que o distingue doutros similares non é o ataque en si —que é de manual— senón a velocidade de resposta:

• As 48 horas entre a fraude e o noso contacto foron clave: se pasasen 7 días, varios dos logs do banco xa non estarían dispoñibles baixo política de retención.
• O clonado inmediato dos equipos preservou os arquivos do navegador e a caché de DNS que axudaron a reconstruír a cronoloxía.
• A denuncia simultánea á reclamación civil multiplicou a presión sobre o banco para chegar a un acordo.

Se a túa empresa quere previlo

Tres medidas, por orde de impacto:

1. Dobre validación humana en transferencias por riba dun límite (recomendado: 3.000€ para pemes).
2. DMARC con política reject no teu dominio corporativo. Isto bloquea fisicamente que o teu propio dominio poida ser suplantado en correos.
3. Formación trimestral ao persoal con simulacros reais de phishing dirixido — non xenéricos, senón con datos da túa empresa.

Se queres que avaliemos o risco da túa peme antes de que pase algo, podemos facer unha auditoría preliminar que inclúe análise do estado DMARC, exposición do persoal en redes (vector clásico para spear phishing) e revisión do protocolo financeiro. Ver máis en servizos periciais ou contacta directamente para unha valoración inicial sen compromiso.