Empresa de unas cuarenta personas. Un correo que parecía de un empleado pedía a RRHH cambiar la cuenta donde cobraba la nómina. Se cambió. Nadie lo comprobó. La nómina de ese mes, 2.140 €, se fue a la cuenta de un desconocido.
No hizo falta ningún virus. Solo una contraseña de correo filtrada y paciencia.
Detección
El empleado preguntó por qué no había cobrado. Ahí empezó todo.
Al revisar su correo vimos que la cuenta llevaba semanas comprometida. Había una regla oculta que reenviaba cada mensaje a una dirección externa. Quien la puso había leído sus conversaciones con RRHH, había aprendido cómo escribía y había esperado al momento adecuado.
Y no era el único intento. Con el mismo acceso habían colado una factura de 18.600 € de un proveedor habitual con el IBAN cambiado. Estaba en la bandeja de administración, pendiente de pago.
Actuación
Las primeras horas son las que importan:
- Cerramos todas las sesiones abiertas de la cuenta y de las demás cuentas de la empresa.
- Eliminamos las reglas de reenvío y restablecimos las contraseñas.
- Avisamos al banco para intentar retener la transferencia de la nómina. Se recuperaron 1.600 de los 2.140 €.
- Llamamos al proveedor de la factura. El IBAN era falso. Ese pago no salió.
- Revisamos el resto de cuentas de correo buscando el mismo patrón.
Mitigación
El problema de fondo no era el correo. Era que un dato tan sensible como una cuenta bancaria se cambiaba con un mensaje. Así que lo blindamos donde vive ese dato: en el ERP.
Criterios de validación de cuentas bancarias en el ERP:
- Ningún IBAN de empleado ni de proveedor cambia sin una segunda persona que lo apruebe.
- Cada cambio genera un aviso automático a dirección con quién lo ha hecho y cuándo.
- Verificación por teléfono con el número que ya estaba en la ficha, nunca con el que aparece en el correo que pide el cambio.
- Los pagos a cuentas modificadas en los últimos días quedan bloqueados salvo aprobación expresa.
- Todos los cambios quedan registrados para poder auditarlos.
- Doble factor en todas las cuentas de correo.
- Alerta cuando alguien crea una regla de reenvío.
- Bloqueo de inicios de sesión desde países donde la empresa no opera.
- Autenticación del dominio (SPF, DKIM y DMARC) para que nadie pueda enviar correos en su nombre.
- Un procedimiento escrito de una página: qué hacer cuando alguien pide cambiar datos bancarios.
Acompañamiento
Cerrar el agujero es la mitad. La otra mitad es que no se vuelva a abrir.
- Formación a administración y RRHH usando los correos reales del ataque. Cuando ves el mensaje que engañó a tu compañera, lo entiendes de otra manera.
- Simulacros de phishing periódicos, sin castigar a quien pica, para medir si mejoramos.
- Revisión trimestral de accesos, de intentos de fraude y de lo que se ve de la empresa desde fuera.
- Cada revisión deja una lista corta de mejoras y la vamos cerrando juntos. Eso es la mejora continua: no un informe al año, sino una lista viva.
Resultado
El segundo intento, la factura de 18.600 € con el IBAN cambiado, se detectó y se paró antes de tocar un euro. Desde entonces han llegado tres intentos más de cambio de cuenta por correo. Ninguno ha pasado el procedimiento. Hoy en esa empresa nadie cambia una cuenta bancaria por un correo.
¿Te puede pasar?
- ¿En tu empresa se puede cambiar el IBAN de un empleado o un proveedor con un correo?
- ¿El correo de administración tiene doble factor?
- ¿Alguien sabría detectar una regla de reenvío oculta?