No hubo malware. No hubo una intrusión visible en los sistemas. No hubo un enlace sospechoso.

Hubo algo mucho más difícil de detectar: un correo que parecía legítimo, provenía de un dominio legítimo y solicitaba información que, dentro de un contexto determinado, parecía completamente razonable entregar.

Así funciona el Business Email Compromise (BEC): un tipo de fraude de ingeniería social que busca que una persona realice voluntariamente una acción que favorece al atacante.

Y uno de los casos más recientes muestra hasta dónde puede llegar este tipo de ataque.

¿QUÉ ES BEC Y POR QUÉ NO SE PARECE AL "HACKEO" TRADICIONAL?

El Business Email Compromise es una modalidad de fraude en la que un atacante se hace pasar por una persona u organización de confianza —un gerente, proveedor, cliente o incluso una autoridad— para conseguir que la víctima transfiera dinero, modifique información, entregue datos o habilite algún tipo de acceso.

A diferencia del phishing masivo, el BEC suele ser mucho más preciso.

No necesariamente llega a miles de personas con un enlace sospechoso. Puede llegar a una persona específica, en el momento adecuado y con una solicitud que encaja perfectamente con su trabajo.

• Por eso puede pasar desapercibido.
• No siempre hay un archivo malicioso.
• No siempre existe una URL sospechosa.
• No necesariamente hay malware.

Hay algo más simple: contexto, confianza y urgencia.

Entre las variantes conocidas están el fraude del CEO, el fraude de proveedores, el robo de nómina y las solicitudes fraudulentas de información.

Esta última modalidad merece especial atención porque el objetivo ya no es necesariamente obtener dinero de inmediato. El objetivo puede ser conseguir información que posteriormente permita realizar nuevos fraudes o suplantaciones.

Y las cifras muestran que el problema está lejos de ser marginal.

Según el Internet Crime Report 2025 del FBI, el Internet Crime Complaint Center (IC3) recibió 24.768 denuncias asociadas a BEC, con pérdidas reportadas por aproximadamente US$3.046 millones. En términos de pérdidas, BEC ocupó el segundo lugar entre las categorías de fraude registradas por IC3, detrás del fraude de inversión.

Estas cifras corresponden únicamente a los casos reportados al organismo. Por lo tanto, no representan necesariamente la totalidad del fenómeno.

EL DETALLE QUE CAMBIA TODO: SUPLANTAR UN DOMINIO O UTILIZAR UNO REAL

Cuando hablamos de suplantación de correo electrónico, normalmente pensamos en un dominio parecido al verdadero:

• Una letra cambiada;
• Un guion agregado;
• Una extensión diferente;
• O una dirección visualmente casi idéntica.

Para reducir este tipo de ataques existen controles ampliamente utilizados como SPF, DKIM y DMARC.

Estos mecanismos permiten validar aspectos relacionados con la autenticación y autorización de los mensajes enviados utilizando un determinado dominio.

Pero existe otro escenario mucho más complejo.

¿Qué ocurre si el atacante no necesita imitar el dominio porque consigue utilizar una cuenta o dirección legítima?

En ese caso, el mensaje puede superar correctamente los controles técnicos de autenticación.

El dominio es real.

El correo puede ser técnicamente válido.

La dirección existe.

Pero la solicitud es fraudulenta.

Y aquí aparece una distinción fundamental: SPF, DKIM y DMARC ayudan a verificar el correo. No pueden determinar por sí solos si una persona autorizada está realizando una solicitud legítima.

El problema deja de ser únicamente tecnológico y pasa a involucrar procesos, personas y toma de decisiones.

EL CASO REVOLUT: CUANDO EL CORREO DE UNA AUTORIDAD PARECE OFICIAL

En septiembre de 2026, Revolut confirmó un incidente en el que un tercero no autorizado utilizó un correo perteneciente a un dominio legítimo de una agencia gubernamental para enviar solicitudes fraudulentas de información.

Según la información comunicada por Revolut, un grupo limitado de clientes se vio afectado y la empresa indicó que sus sistemas y los fondos de sus clientes no fueron comprometidos. La compañía bloqueó la dirección utilizada y notificó al organismo gubernamental correspondiente, a las autoridades y a los reguladores pertinentes.

La información entregada podía incluir datos personales y de contacto, documentos de identidad y, en algunos casos, selfies utilizados para verificación, extractos de cuenta e historiales de transacciones.

El punto relevante no es solamente qué información terminó expuesta. Es cómo se consiguió.

No fue necesario convencer a un empleado de que descargara un archivo malicioso.

La solicitud aparentaba formar parte de un procedimiento oficial.

Ese es precisamente el tipo de situación que hace tan complejo al BEC: el atacante intenta convertir un proceso legítimo en una herramienta para cometer fraude.

Y el caso tiene además una particular relevancia para Perú.

En marzo de 2026, la Superintendencia de Banca, Seguros y AFP (SBS) autorizó la organización de Revolut Bank Perú S.A. como empresa bancaria, aunque el inicio de operaciones quedó sujeto a la posterior autorización de funcionamiento.

Por eso, el caso permite observar un riesgo que no pertenece exclusivamente a las grandes fintech internacionales. También puede afectar a organizaciones peruanas que reciben diariamente solicitudes de organismos públicos, clientes, proveedores o instituciones financieras.

¿QUÉ NOS ENSEÑA ESTE CASO?

1. El atacante puede explotar un proceso legítimo

Las organizaciones reguladas reciben solicitudes de autoridades y terceros como parte de sus operaciones normales.

El problema no necesariamente está en tener ese procedimiento.

El riesgo aparece cuando la organización no cuenta con mecanismos suficientes para comprobar que quien solicita la información es realmente quien dice ser y que la solicitud corresponde a un requerimiento legítimo.

El proceso de cumplimiento puede convertirse así en parte del vector de ataque.

2. La madurez de una organización no elimina el riesgo humano

Contar con infraestructura de seguridad, equipos especializados y controles tecnológicos reduce riesgos, pero no elimina una decisión que finalmente puede quedar en manos de una persona.

Un correo convincente puede llegar a un área legal, financiera, de recursos humanos, atención al cliente o cumplimiento.

Y la pregunta puede ser muy sencilla:

¿Entregamos la información porque el correo parece oficial o verificamos primero la solicitud?

3. Los datos también son un objetivo del BEC

El BEC suele asociarse inmediatamente con transferencias bancarias.

Pero los datos tienen un valor enorme para los atacantes.

Una identidad, un documento, un teléfono, una dirección, un historial de transacciones o información sobre una relación comercial pueden utilizarse posteriormente para construir ataques mucho más convincentes.

El FBI ya había advertido en 2024 sobre el uso de cuentas comprometidas de organismos públicos para realizar solicitudes fraudulentas de información y obtener datos personales.

Por eso, el robo de información puede ser solamente el primer paso de una cadena de ataques posteriores.

4. La autenticación del correo no reemplaza la validación del proceso

SPF, DKIM y DMARC son controles fundamentales.

Pero tienen un alcance específico.

Pueden ayudar a reducir la suplantación directa de un dominio, pero no responden preguntas como:

• ¿La persona que envía la solicitud está autorizada para hacerla?
• ¿La solicitud realmente existe?
• ¿El requerimiento corresponde a un expediente válido?
• ¿La información solicitada es necesaria?
• ¿Debemos entregar toda esa información?

Por eso, autenticar el correo y autenticar la solicitud son problemas diferentes.

¿QUÉ PUEDE HACER UNA ORGANIZACIÓN DESDE HOY?

1. Implementar verificación fuera de banda

Toda solicitud sensible debería validarse mediante un canal independiente del correo que la originó.

Por ejemplo:

• Llamar a un número previamente conocido;
• Contactar directamente a una persona validada;
• Verificar el expediente mediante los canales oficiales correspondientes;
• Confirmar internamente con el responsable del proceso.

La regla puede ser sencilla:

Si la solicitud puede generar una pérdida financiera o una exposición importante de información, no debería validarse únicamente respondiendo al mismo correo que la originó.

2. Definir un procedimiento para solicitudes de autoridades

Debe existir claridad sobre:

• Quién recibe la solicitud;
• Quién valida su autenticidad;
• Quién autoriza la respuesta;
• Qué información puede entregarse;
• Qué evidencia debe conservarse.

Un requerimiento legítimo debería poder superar un proceso de validación.

3. Aplicar el principio de mínima entrega

Si se solicita un dato, entregar ese dato.

Si se solicita un documento específico, entregar ese documento.

No enviar automáticamente un expediente completo porque “es lo que normalmente se hace”.

Menos información expuesta significa menor impacto si la solicitud resulta fraudulenta.

4. Configurar correctamente SPF, DKIM y DMARC

Estos controles siguen siendo fundamentales para proteger el dominio corporativo frente a la suplantación directa.

Sin embargo, deben entenderse correctamente: no sustituyen los controles de identidad, autorización y validación de solicitudes.

5. Entrenar con escenarios que realmente ocurren

Una simulación de phishing no debería limitarse al clásico correo de “ganaste un premio”.

Las organizaciones deberían entrenar escenarios mucho más cercanos a la realidad:

• “La cuenta bancaria del proveedor cambió”.
• “La gerencia necesita esta transferencia hoy”.
• “La autoridad solicita información de un cliente”.
• “El área legal requiere estos documentos”.
• “Existe una emergencia y necesitamos responder inmediatamente”.

El objetivo no es enseñar a las personas a desconfiar de todos los correos.

Es enseñarles cuándo detenerse y verificar antes de actuar.

6. Monitorear la exposición de credenciales y datos

Una cuenta comprometida de un empleado, proveedor o tercero relacionado puede convertirse en el punto de partida de una campaña de BEC.

Por eso, conocer qué credenciales o información corporativa están expuestas permite actuar antes de que esa información sea utilizada contra la organización.

LA PREGUNTA NO ES SI EL CORREO PARECE REAL

La pregunta correcta es:

¿La solicitud es realmente legítima?

Imagine que mañana llega a su área legal, financiera o de atención al cliente un correo desde el dominio real de una entidad pública solicitando información de sus clientes.

¿Existe un procedimiento para verificarlo?

¿O la respuesta depende exclusivamente del criterio de la persona que abrió el correo?

¿Su dominio tiene SPF, DKIM y DMARC correctamente configurados?

¿Sabe si existen credenciales de su organización o de sus proveedores expuestas?

¿Su equipo ha enfrentado alguna vez una simulación de suplantación basada en situaciones reales de su negocio?

Si alguna respuesta no está clara, existe una oportunidad concreta para fortalecer el proceso.

En CompuNetGroup ayudamos a las organizaciones a abordar estos riesgos desde distintas dimensiones: revisión de autenticación de correo —SPF, DKIM y DMARC—, evaluación de procesos de verificación, campañas de phishing y suplantación simulada adaptadas a la realidad de cada organización y monitoreo de exposición de credenciales y datos.

Porque el BEC no necesariamente rompe sistemas.

Rompe la confianza en la que se basan nuestros procesos.

Y cuando un correo parece demasiado legítimo para ser cuestionado, quizás ese sea precisamente el momento en que más debemos verificar.

¿Está preparada su organización para hacerlo?