Email sospechoso del jefe pidiendo transferencia: qué hacer (BEC 2026)

Si en los últimos minutos has recibido un email aparentemente del CEO, del director financiero o de un proveedor habitual pidiendo una transferencia urgente o un cambio de cuenta bancaria, PARA. Lee esto antes de hacer la transferencia o de borrar el email. El fraude BEC (Business Email Compromise) movió 229 millones de euros en España en 2024 según datos del Ministerio del Interior. La mayoría de víctimas reaccionan mal en los primeros 5 minutos y pierden la evidencia que habría salvado el caso.

Te ha pasado, primeros 5 minutos

NO hagas la transferencia aunque el email diga “urgente”. Ningún CEO real exige transferencias por email saltándose el protocolo.
NO borres el email (ni la respuesta, si ya respondiste). Es la única evidencia técnica.
NO reenvíes el email como adjunto. Reenviar lo modifica y rompe la firma DKIM. Si tienes que avisar a alguien, hazlo por WhatsApp o teléfono.
Llama al supuesto remitente por un canal alternativo (teléfono que ya tengas guardado, NO el que aparece en la firma del email — puede ser falso) para verificar.
Exporta el .eml original AHORA (instrucciones más abajo). Calcula su SHA-256.
Si ya transferiste: llama al banco emisor INMEDIATAMENTE para pedir orden de retroceso SWIFT. Cada minuto cuenta.

Tabla de contenidos

Síntomas de email BEC: cómo reconocerlo antes de hacer la transferencia
Cómo preservar la evidencia ANTES de borrar nada
Pasos primeras 24 horas
Cuándo llamar al perito y cuándo basta con la denuncia
Cuándo a la policía: GDT Guardia Civil y BCIT Policía Nacional
Caso real anonimizado: cómo se gestionó
Preguntas frecuentes

1. Síntomas de email BEC: cómo reconocerlo antes de hacer la transferencia

Los emails BEC se diseñan para parecer legítimos. La detección depende de cruzar varias señales pequeñas — ninguna por sí sola es definitiva, pero la combinación lo es.

5 señales que aparecen en casi todos los BEC

Urgencia artificial — “necesito esta transferencia antes de las 17h”, “es para cerrar la operación de hoy”, “el cliente no espera”. El objetivo es que actúes sin verificar. Un CEO real entiende que las transferencias requieren protocolo.
Confidencialidad explícita — “no comentes esto con nadie de momento”, “es confidencial hasta el cierre”, “mantén discreción”. Buscan que NO llames por teléfono a verificar ni avises a otro miembro del equipo.
Dominio sutilmente distinto — el remitente parece ceo@empresa.com pero al inspeccionar es ceo@empresa-corp.com, ceo@empressa.com (typo deliberado) o ceo@empresa.com.it (TLD distinto). En móvil la dirección suele truncarse — verificar siempre en escritorio.
Petición fuera de protocolo — el CEO normalmente no pide transferencias por email; las solicita el departamento financiero, con firma autorizada. Si el flujo no es el habitual, sospechar.
Cambio de cuenta bancaria de un proveedor habitual — “hemos cambiado nuestra cuenta, los próximos pagos van al IBAN ESXX…”. Puede ser legítimo, pero TIENE QUE verificarse por canal alternativo (teléfono al contacto habitual, no al que aparece en el email).

Modalidades clásicas de BEC

Modalidad	Vector	Detección
CEO fraud	Email aparente del CEO al financiero	Dominio sutil + urgencia + confidencialidad
Vendor/Supplier fraud	Cambio cuenta bancaria de proveedor real	Email desde cuenta del proveedor REAL comprometida (DKIM PASS legítimo)
Account takeover interno	Atacante usa buzón real comprometido	DKIM PASS, dominio correcto — solo se detecta por contenido anómalo + verificación canal alternativo
Lawyer fraud	Email aparente de abogado/asesor con “operación urgente”	Cliente nuevo + transferencia a cuenta extranjera + presión emocional

La modalidad más peligrosa es la takeover interno: el atacante envía desde la cuenta REAL de un empleado o proveedor (acceso por phishing previo). El DKIM saldrá PASS, el dominio será correcto, todo parece legítimo. Solo la verificación por canal alternativo y el patrón anómalo lo detectan.

2. Cómo preservar la evidencia ANTES de borrar nada

Esta es la parte que los abogados y peritos van a agradecerte. Si el caso acaba en juzgado o en denuncia ante la Guardia Civil, la evidencia técnica del email original es decisiva.

Lo que NO debes hacer (errores irreversibles)

❌ Borrar el email, ni siquiera de la papelera (en algunos servidores se purga a los 30 días).
❌ Reenviar el email como adjunto — el reenvío modifica las cabeceras y rompe la firma DKIM. Pierdes la prueba criptográfica.
❌ Imprimirlo a PDF y trabajar sobre el PDF — el PDF no contiene cabeceras técnicas (DKIM-Signature, Received:, etc.). El peritaje sobre PDF es mucho más débil que sobre .eml.
❌ Capturar pantalla y mandarla al banco/abogado/perito — la captura no es evidencia técnica, solo visual.
❌ Responder al email sospechoso preguntando “¿esto es real?” — confirma al atacante que la víctima está leyendo y suele desencadenar la siguiente fase del fraude.

Lo que SÍ debes hacer (en orden)

Exporta el .eml original ahora mismo

El .eml es el archivo que contiene cabeceras técnicas + cuerpo + adjuntos en formato RFC 5322. Por proveedor:

Cliente	Procedimiento
Outlook M365 (web)	Abre el email → menú `⋮` → “Ver” → “Ver origen del mensaje” → guarda como `.eml`
Outlook desktop	Arrastra el email desde la bandeja al escritorio → genera `.msg` (luego se convierte a `.eml`)
Gmail web	Abre el email → menú `⋮` → “Mostrar original” → “Descargar mensaje original”
Apple Mail	Email seleccionado → “Archivo” → “Guardar como…” → “Sin formato”
Thunderbird	Clic derecho sobre el email → “Guardar como” → `.eml`

Calcula el SHA-256 del .eml
En macOS / Linux:
```
shasum -a 256 email.eml > email.eml.sha256
```
En Windows (PowerShell):
```
Get-FileHash email.eml -Algorithm SHA256
```
Apunta el hash en un cuaderno físico o en una nota fechada. Servirá como prueba de integridad: si la evidencia se modifica posteriormente, el hash cambia.
Guarda copias en al menos dos sitios
- Copia 1: pendrive USB o disco externo (no conectado a internet).
- Copia 2: carpeta cifrada en la nube (no en la cuenta corporativa que pudiera estar comprometida).
Si ya respondiste al email, exporta también tu respuesta como .eml. Aporta contexto procesal.
Si ya hiciste la transferencia, conserva los justificantes bancarios (PDF + screenshot del banco) con su hash SHA-256.
Documenta TODO lo que has hecho desde la recepción del email hasta este momento. Hora exacta de cada acción. Esta cronología es oro para el perito y el abogado.

Por qué importa el `.eml` y no el PDF

El .eml permite verificación criptográfica DKIM contra DNS público — el perito puede demostrar matemáticamente si el email procede o no del dominio que dice. El PDF/captura solo permite acreditar “una imagen que se parecía a un email”. La diferencia procesal es enorme: con .eml peritado tienes prueba documental electrónica robusta (art. 326-329 LEC); sin .eml tienes un indicio impugnable.

3. Pasos primeras 24 horas

Una vez tienes el .eml exportado y las copias guardadas, las siguientes 24 horas determinan si recuperas el dinero (caso de transferencia ya hecha) y si la denuncia tiene fuerza probatoria.

Si YA hiciste la transferencia (cada minuto cuenta)

Llama al banco emisor INMEDIATAMENTE (los primeros 30 minutos son críticos). Pide hablar con seguridad/fraude. Solicita “orden de retroceso SWIFT” o “orden de recall” del envío. Si la transferencia aún no se ha procesado del todo, hay margen para revertirla. Si se procesó, el banco emisor puede contactar al receptor para congelar fondos.
Pide al banco un escrito formal de la operación (no solo el extracto): fecha, hora exacta del débito, IBAN destino, importe, referencia SWIFT. Esto es prueba documental.
Denuncia en GDT Guardia Civil o BCIT Policía Nacional dentro de las primeras 24 h (instrucciones más abajo). La denuncia activa investigación bancaria internacional y permite cooperación con bancos receptores.
Avisa a tu equipo de TI/seguridad para revisar si hay account takeover (cuenta corporativa comprometida) que haya facilitado el fraude. Cambiar contraseñas inmediatamente, revisar reglas de reenvío automático del correo (los atacantes suelen crearlas), revisar conexiones activas.
Contacta con un perito informático para que peritee técnicamente el .eml (verificación DKIM, cadena de custodia ISO/IEC 27037, dictamen UNE 197001:2019). El peritaje es la prueba que sostendrá el procedimiento civil contra el banco o el penal contra el atacante.
Contacta con tu abogado (mercantil + penal económico) para diseñar la estrategia procesal: reclamación al banco emisor, denuncia penal, posible acción contra terceros (proveedor real cuya cuenta se comprometió, si aplica).

Si AÚN NO has hecho la transferencia (más fácil)

NO la hagas.
Verifica por canal alternativo (teléfono al contacto habitual, NO al que aparece en el email).
Confirmado que es BEC, sigue los pasos 4, 5 y 6 anteriores (TI, perito, abogado).
Considera denunciar igualmente — aunque no haya pérdida económica, el intento de estafa es delito y la denuncia ayuda a investigar la red.

Documentación que tendrás que aportar al perito y al abogado

.eml original + SHA-256 (Paso 2 del bloque anterior).
Justificantes bancarios (PDF + screenshot) si hubo transferencia.
Cronología documentada de tus acciones desde la recepción.
Cualquier email previo del contacto suplantado (proveedor habitual, CEO real) para comparar dominios y patrones.
Logs del servidor de correo corporativo si los tienes (pídeselos a TI).
Copia de la denuncia (cuando la tengas).

4. Cuándo llamar al perito y cuándo basta con la denuncia

No todos los casos BEC requieren peritaje. Esta es la decisión.

Casos donde el peritaje es imprescindible

Transferencia hecha ≥ 5.000€ y quieres reclamar al banco emisor por incumplimiento del deber de diligencia. El peritaje técnico acredita que el email era falso (falla DKIM contra DNS público), reforzando la posición procesal.
Disputa con un proveedor sobre si el cambio de cuenta fue legítimo (vendor fraud). El peritaje demuestra si el email procede del dominio del proveedor o de un suplantador.
Sospecha de account takeover interno — un peritaje que verifique DKIM PASS desde el dominio corporativo + análisis de logs ayuda a determinar si la cuenta del CEO/financiero está comprometida.
Caso con repercusión penal grande (pérdida importante, riesgo reputacional) que va a juicio.
Si planeas demandar al proveedor real cuya cuenta se comprometió — necesitas peritaje que demuestre la suplantación antes de demandar al equivocado.

Casos donde basta con la denuncia (sin peritaje)

Intento de fraude sin pérdida económica — denuncia para que la red entre en investigación, pero sin litigio civil propio el peritaje no compensa el coste.
Pérdida pequeña (por debajo de 1.000€ aprox.) donde el coste del peritaje supera lo recuperable.
Fraude obvio + atacante claramente identificable (ej. el banco receptor ya bloqueó la cuenta y devolvió el dinero) — el peritaje aporta poco.

En la duda, llama al perito antes de demandar — un peritaje hecho rápido evita demandar al actor equivocado (típico error en vendor fraud: demandar al proveedor real, que era víctima de takeover).

5. Cuándo a la policía: GDT Guardia Civil y BCIT Policía Nacional

En España, dos cuerpos especializados investigan delitos informáticos. La elección depende de tu zona y del tipo de incidente.

Grupo de Delitos Telemáticos (GDT) — Guardia Civil

Competencia: zonas rurales y zonas donde la Guardia Civil es la fuerza primaria.
Web: https://www.gdt.guardiacivil.es/webgdt/home_alerta.php (formulario de denuncia online).
Presencial: cualquier puesto de la Guardia Civil — pedir derivación al GDT.
Útil para: BEC, phishing, ransomware, suplantación de identidad, estafas online.

Brigada Central de Investigación Tecnológica (BCIT) — Policía Nacional

Competencia: ciudades grandes, zonas urbanas con presencia de Policía Nacional.
Comisaría de Policía Nacional: presentar denuncia y pedir derivación a BCIT.
Útil para: mismo perfil de delitos.

Qué llevar a la denuncia

.eml original en pendrive USB + impresión del SHA-256 calculado.
Justificantes bancarios si hubo transferencia.
DNI y datos de la empresa.
Cronología documentada de los hechos.
Si ya tienes peritaje preliminar, llévalo (no es obligatorio para denunciar pero acelera la investigación).

Qué esperar después de denunciar

Número de atestado / diligencias para futuras consultas.
Posible derivación al juzgado de instrucción correspondiente si se inicia investigación judicial.
Cooperación bancaria internacional vía SWIFT/SEPA si la transferencia fue al extranjero.
Tiempos: las investigaciones BEC suelen durar meses; la denuncia es necesaria pero no garantiza recuperación rápida del dinero.

6. Caso real anonimizado: cómo se gestionó

Caso real (anonimizado)

Contexto: cliente (controller financiero de pyme) recibió un email aparentemente del proveedor habitual con instrucciones de cambio de cuenta bancaria y solicitud de redirigir el siguiente pago (importe medio-alto). La transferencia se hizo. A los pocos días el proveedor real reclamó el cobro del que sí tenía constancia. El cliente descubrió el fraude.

Qué hizo bien

No borró el email sospechoso ni la respuesta de confirmación que envió al supuesto proveedor.
Conservó las cabeceras técnicas — el .eml se exportó completo desde Outlook M365.
Llamó al banco emisor en la primera hora tras descubrir el fraude, pidiendo orden de retroceso SWIFT.
Contactó con perito antes de demandar al proveedor real (lo que habría sido un error procesal).

Qué descubrió el peritaje

El peritaje técnico (cuyo procedimiento detallamos en el pillar técnico del cluster) demostró que:

El servidor receptor del cliente había marcado Authentication-Results: dkim=pass.
La verificación criptográfica DKIM independiente contra DNS público devolvió False.
La cabecera Received: del primer hop apuntaba a un IP que no correspondía a la infraestructura del proveedor real.

Es decir: el email NO era auténtico criptográficamente. El proveedor real era víctima también (su identidad fue suplantada).

Qué se hizo procesalmente

NO se demandó al proveedor real — el peritaje demostró que no fue origen del email. La estrategia procesal se redirigió al banco emisor (por incumplimiento del deber de diligencia en operación atípica) y a la denuncia GDT para investigar al atacante real.
El proveedor real, alertado, reforzó la seguridad de su correo corporativo (revisó account takeover, activó MFA en M365, eliminó reglas de reenvío automático sospechosas).

Sin el peritaje técnico previo, la estrategia procesal habría sido errónea: demandar al proveedor inocente habría supuesto perder el procedimiento y dejar prescribir la acción contra el banco.

¿Acabas de recibir un email BEC y necesitas peritaje urgente?

Análisis forense con DKIM verificado contra DNS público, cadena de custodia ISO/IEC 27037 y dictamen UNE 197001. Atención prioritaria casos en curso. Cobertura nacional España.

Solicitar peritaje urgente

Conceptos relacionados que conviene tener claros: Business Email Compromise (BEC) (qué es, modalidades, marco legal), cadena de custodia digital (ISO/IEC 27037), y evidencia digital (admisibilidad procesal). Si tu abogado va a llevar el caso, comparte con él la guía sobre cómo validar el peritaje de email.

7. Preguntas frecuentes

¿Qué hago en los primeros 5 minutos si recibí un email BEC?

NO transferir, NO borrar el email, NO reenviarlo como adjunto, NO responder, NO imprimirlo a PDF. Llamar al supuesto remitente por canal alternativo (teléfono guardado previamente, no el del email). Exportar el .eml original y calcular su SHA-256. Si ya transferiste, llamar al banco emisor inmediatamente para pedir orden de retroceso SWIFT.

¿Puedo recuperar el dinero si ya hice la transferencia BEC?

Depende de la rapidez. Los primeros 30 minutos tras la transferencia son críticos para una orden de retroceso SWIFT/SEPA. Si la transferencia ya se procesó del todo, el banco emisor puede contactar al receptor para congelar fondos (recovery rate típico baja drásticamente con cada hora). La denuncia inmediata en GDT Guardia Civil o BCIT Policía Nacional activa cooperación bancaria internacional. La recuperación NO está garantizada y depende de jurisdicción del banco receptor.

¿Es obligatorio denunciar en Guardia Civil o Policía Nacional?

No es obligatorio legalmente, pero es altamente recomendable. La denuncia (1) activa investigación bancaria internacional para intentar recuperar fondos, (2) genera atestado que sirve como prueba en reclamaciones civiles posteriores contra el banco, (3) ayuda a que la red de fraude entre en investigación coordinada. Sin denuncia no hay investigación, aunque se pierda dinero.

¿Cuál es el plazo para denunciar un BEC?

Cuanto antes, mejor — idealmente en las primeras 24 horas. Penalmente la denuncia se puede presentar mientras no prescriba el delito (estafa: 5-10 años según importe, art. 248 y 250 CP). Pero la efectividad de la investigación bancaria internacional cae rápidamente con el tiempo (los fondos se mueven entre bancos en horas).

¿Necesito siempre un perito informático para casos BEC?

No siempre. Si la pérdida es pequeña o el atacante está identificado, puede bastar con la denuncia. El peritaje es imprescindible cuando: (a) vas a reclamar al banco emisor por incumplimiento del deber de diligencia, (b) hay disputa con el proveedor real cuya cuenta se comprometió (vendor fraud), (c) sospecha de account takeover interno corporativo, (d) caso con repercusión grande que va a juicio. En la duda, consulta antes de demandar.

¿Qué pasa si no tengo el `.eml` original (lo borré o solo tengo PDF)?

El peritaje pierde la dimensión criptográfica (DKIM no verificable). El perito puede acreditar lo que tienes (PDF, capturas) y describir su contenido, declarando explícitamente la limitación. La fuerza probatoria es menor pero no nula. Si fue Outlook M365 o Gmail, en algunos casos el .eml aún puede recuperarse del servidor en los primeros 30 días (incluso de la papelera vaciada, vía soporte del proveedor) — consulta con TI o con el perito antes de descartar.

Referencias y fuentes

Ministerio del Interior — Estadísticas de cibercriminalidad. https://estadisticasdecriminalidad.ses.mir.es/
Grupo de Delitos Telemáticos (GDT) — Guardia Civil. https://www.gdt.guardiacivil.es/webgdt/home_alerta.php
Policía Nacional — Denuncia de delitos informáticos. https://www.policia.es/_es/colabora_informacion_general.php
INCIBE-CERT — Recomendaciones BEC. https://www.incibe.es/incibe-cert
OS3 / EUROPOL — Business Email Compromise threat assessment. https://www.europol.europa.eu/
Ley 1/2000 de Enjuiciamiento Civil — arts. 326-329 (prueba documental electrónica). https://www.boe.es/eli/es/l/2000/01/07/1/con
RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. https://datatracker.ietf.org/doc/html/rfc6376
ISO/IEC 27037:2012 — Identification, collection, acquisition and preservation of digital evidence. https://www.iso.org/standard/44381.html
Ley Orgánica 10/1995 (Código Penal) — arts. 248-251 (delito de estafa). https://www.boe.es/eli/es/lo/1995/11/23/10/con