Una empresa puede tener sistemas protegidos y aun así sufrir una brecha si una persona confía en una solicitud fraudulenta. El caso Revolut muestra cómo la ingeniería social puede convertir una comunicación aparentemente legítima en una fuga de información.
El incidente no comenzó con un atacante rompiendo una aplicación o desplegando ransomware. El punto crítico fue la confianza depositada en una solicitud que parecía proceder de una autoridad legítima.
¿Qué ocurrió en el caso Revolut?
En septiembre de 2026, Revolut confirmó que un tercero no autorizado consiguió que empleados entregaran información sensible de clientes mediante solicitudes fraudulentas que aparentaban proceder de un dominio gubernamental legítimo. La compañía indicó que sus sistemas y los fondos de los clientes no se vieron afectados.
Las informaciones publicadas posteriormente señalan que los datos potencialmente afectados incluían documentos de identidad, fotografías de verificación, información personal y registros de transacciones. El Financial Times informó de aproximadamente 680 clientes afectados, aunque Revolut ha utilizado la expresión "número limitado" y no ha confirmado públicamente esa cifra.
El caso adquirió una nueva dimensión cuando el grupo que se identifica como iamnotavillain publicó una exigencia de aproximadamente 3 millones de dólares en Monero y amenazó con vender los datos. Revolut, sin embargo, declaró que no había recibido una comunicación directa del grupo.
La distinción es importante: el incidente confirmado es una brecha de datos provocada mediante suplantación e ingeniería social, no un ransomware tradicional que haya cifrado los sistemas de Revolut.
El problema: una identidad legítima no garantiza una solicitud legítima
El caso permite extraer una lección que va más allá de Revolut.
Un sistema de correo puede comprobar que un mensaje procede realmente de un dominio determinado. Eso no significa que la persona que utiliza esa cuenta tenga autoridad para solicitar determinada información.
En otras palabras:
Autenticación no es lo mismo que autorización.
Una dirección legítima puede haber sido comprometida. Una cuenta real puede estar siendo utilizada por un atacante. Y una petición técnicamente auténtica puede ser operacionalmente fraudulenta.
Por eso, las organizaciones necesitan procedimientos que permitan verificar no solo quién solicita algo, sino también si está autorizado para solicitarlo y si la petición tiene sentido en ese contexto.
Esta lógica coincide con los principios de Zero Trust, donde ninguna solicitud debe considerarse confiable automáticamente y el acceso debe evaluarse según identidad, contexto y autorización.
Ingeniería social: atacar a la persona en lugar del sistema
La ingeniería social utiliza manipulación, urgencia, autoridad o confianza para conseguir que una persona revele información, conceda acceso o realice una acción.
No siempre necesita un enlace malicioso.
Puede adoptar diferentes formas:
- Phishing: mensajes diseñados para inducir al usuario a hacer clic, introducir credenciales o entregar información.
- Spear phishing: ataques personalizados dirigidos a una persona concreta.
- Vishing: llamadas telefónicas en las que el atacante se hace pasar por soporte, un banco, un proveedor o un responsable de la empresa.
- Smishing: engaños mediante SMS o mensajería instantánea.
- Fraude del CEO: suplantación de un directivo para solicitar una acción urgente o confidencial.
- Falso proveedor: solicitud fraudulenta de cambio de cuenta bancaria.
- Pretexting: creación de una historia o contexto falso para justificar una solicitud. El caso Revolut encaja especialmente en esta categoría.
El denominador común es siempre el mismo: conseguir que una persona haga algo que no haría si conociera la verdadera identidad o intención del interlocutor.
Por qué los controles técnicos no son suficientes
Un firewall puede bloquear una conexión maliciosa. Un sistema de autenticación puede impedir el acceso con credenciales incorrectas. Una solución de protección del correo puede identificar determinados patrones sospechosos.
Pero ninguno de esos controles sustituye una decisión humana frente a una petición que parece legítima.
Por eso, una estrategia de cultura de ciberseguridad debe preparar a los colaboradores para reconocer situaciones en las que la urgencia, la autoridad aparente o la presión pueden utilizarse para saltarse los procedimientos.
La formación tampoco debería limitarse a explicar qué es un phishing.
Un programa eficaz debe entrenar comportamientos concretos:
- comprobar el remitente y el contexto;
- desconfiar de solicitudes inusualmente urgentes;
- verificar las peticiones sensibles mediante un segundo canal;
- no utilizar los datos de contacto proporcionados por el propio solicitante para realizar esa verificación;
- escalar solicitudes excepcionales al responsable correspondiente;
- evitar entregar información sensible solo porque la petición parece proceder de una organización conocida.
La ingeniería social también puede simular situaciones reales
Una presentación teórica puede explicar que no se deben abrir enlaces sospechosos. El problema es que muchos ataques actuales no tienen ese aspecto.
Una solicitud puede utilizar el nombre de una autoridad, un proveedor conocido, un compañero o un directivo. También puede aprovechar información pública de la organización para construir un escenario creíble.
Por eso, las simulaciones de phishing permiten convertir la formación en una prueba práctica.
Las simulaciones permiten observar cómo responde realmente el equipo ante situaciones controladas y utilizar el resultado para reforzar los comportamientos que necesitan mayor atención.
Guardey combina simulaciones con formación continua y retos breves de concienciación. El objetivo no es penalizar al empleado que comete un error, sino convertir ese momento en una oportunidad de aprendizaje y reforzar hábitos seguros.
Del phishing tradicional a la ingeniería social avanzada
El caso Revolut también plantea una evolución importante.
La pregunta ya no debería ser solamente:
"¿El empleado sabe reconocer un correo de phishing?"
También debería ser:
"¿El empleado sabe cuestionar una solicitud que parece legítima?"
Una organización madura necesita preparar a sus equipos para escenarios como:
La clave es transformar la seguridad en un comportamiento repetido, no en una información que el empleado recibe una vez al año.
Cómo reducir el riesgo de ingeniería social
La prevención requiere varias capas.
1. Establecer procedimientos de verificación
Las solicitudes excepcionales de datos, pagos o cambios de configuración deben contar con un procedimiento independiente de validación.
2. Aplicar el principio de mínimo privilegio
No todas las personas necesitan capacidad para acceder, modificar o entregar la misma información.
3. Utilizar autenticación resistente al phishing
La autenticación multifactor reduce determinados riesgos de robo de credenciales, aunque no sustituye la verificación de una solicitud ni protege por sí sola frente a todos los escenarios de ingeniería social.
4. Formar de manera continua
La concienciación debe incluir ejercicios prácticos y escenarios que reproduzcan situaciones reales de la organización.
5. Medir el comportamiento
Los responsables de seguridad necesitan conocer qué tipos de engaño generan más errores y qué áreas requieren refuerzo.
La combinación de tecnología, procesos y entrenamiento permite reducir la dependencia de una única barrera.
La lección de Revolut para cualquier empresa
El caso Revolut deja una conclusión especialmente relevante para los responsables de TI y ciberseguridad:
No hace falta vulnerar un sistema para provocar una brecha.
Si una organización tiene información sensible, también debe proteger los procesos que permiten solicitarla, acceder a ella y compartirla.
Un dominio legítimo no demuestra que una petición sea legítima. Una identidad autenticada no demuestra que exista autorización. Y una persona bien intencionada puede convertirse, sin saberlo, en el mecanismo que permite materializar un ataque.
La ingeniería social exige, por tanto, una defensa que combine cultura de ciberseguridad, simulaciones prácticas y controles técnicos basados en principios de Zero Trust.
El objetivo no es conseguir que los empleados desconfíen de todo. Es conseguir que sepan cuándo deben verificar antes de actuar.
{{fs-button}}