El 12 de septiembre de 2026, la fintech Revolut confirmó un incidente de seguridad que, en lugar de relatar una intrusión informática convencional, expuso un agujero mucho más profundo en la confianza digital. Un tercero no autorizado utilizó una dirección de correo electrónico perteneciente al dominio legítimo de una agencia gubernamental para solicitar información sensible de clientes. La compañía respondió a esas peticiones y entregó los datos. No hubo vulneración de la aplicación, ni robo de credenciales de usuarios, ni acceso no autorizado a los servidores de la entidad. El atacante no necesitó entrar: logró que la propia organización le abriera la puerta.
Revolut entregó datos de clientes: la llamada que no fue una intrusión
La naturaleza del ataque es particularmente insidiosa. Revolut reconoció que un atacante explotó la confianza depositada en los canales oficiales de comunicación gubernamental. La empresa aseguró que sus sistemas centrales y los fondos de los usuarios no se vieron comprometidos y que, una vez detectada la actividad fraudulenta, bloqueó la dirección de correo utilizada y notificó a las autoridades, organismos de protección de datos y reguladores financieros. Sin embargo, la investigación posterior del Financial Times reveló detalles que agravan el caso: los atacantes habrían comprometido infraestructura italiana de Posta Elettronica Certificata (PEC), un sistema de correo con valor jurídico, para hacerse pasar por organismos policiales. El diario cifró en aproximadamente 680 los clientes notificados por Revolut, señalando que algunos objetivos estaban relacionados con importantes tenencias de criptomonedas. Estas afirmaciones provienen de la investigación del FT y de las declaraciones de los propios atacantes; Revolut no ha detallado qué organismo gubernamental fue suplantado ni el proceso interno que aprobó cada solicitud.
Autenticación no equivale a autorización: una lección técnica
El caso obliga a distinguir entre dos conceptos que en ciberseguridad son elementales pero que, en la práctica, a menudo se confunden: la autenticación y la autorización. Un sistema puede determinar con éxito que un mensaje proviene de la infraestructura de correo de una organización. Sin embargo, no puede garantizar que la persona que escribió ese mensaje estuviera facultada para realizar la petición. Con la información pública disponible, no puede afirmarse que Revolut entregara los datos únicamente porque el correo procedía de un dominio gubernamental auténtico, pero sabemos que las solicitudes fraudulentas consiguieron superar el proceso de validación.
¿Qué es DMARC y por qué no protege contra este tipo de fraude?
DMARC (Domain-based Message Authentication, Reporting, and Conformance), junto con SPF y DKIM, son protocolos de autenticación de correo electrónico. Permiten comprobar que un mensaje proviene del dominio que dice utilizar y que no ha sido alterado en tránsito. Sin embargo, su alcance es limitado. La especificación actual de DMARC (RFC 9989, publicado en 2026) deja claro que su función es la autenticación a nivel de dominio, no la autenticación de entidades ni la legitimidad del contenido. Una validación DMARC no constituye una expresión sobre el valor del mensaje. Es decir, un correo puede pasar todas las pruebas técnicas de autenticación y ser, al mismo tiempo, completamente fraudulento en su contenido.
La tabla siguiente ilustra esta diferencia crucial:
- SPF / DKIM / DMARC: Pueden acreditar que el dominio cumple condiciones de autenticación. No acreditan que el empleado esté autorizado para pedir datos.
- Cuenta gubernamental válida: Puede acreditar que el mensaje proviene de infraestructura real de la Administración. No acredita que la cuenta no haya sido comprometida.
- Documento oficial: Puede acreditar que la petición tiene apariencia administrativa. No acredita que el documento no sea falso o manipulado.
- Identificación del funcionario: Puede acreditar quién está detrás de la petición. No acredita que tenga competencia legal para solicitar esos datos.
- Validación jurídica: Puede acreditar una base legal. No acredita que todos los datos solicitados sean necesarios o proporcionales.
Por lo tanto, el incidente no debería describirse como un simple «fallo de autenticación de correo». Si el atacante controlaba efectivamente una cuenta o infraestructura gubernamental legítima, los sistemas de autenticación estaban funcionando correctamente. El fallo residió en convertir esa autenticación técnica en una confianza suficiente para autorizar una operación sensible. El verdadero problema de seguridad es que la autorización se basó en un único factor de confianza.
El precedente del FBI: solicitudes de datos de emergencia fraudulentas
Esta técnica no es nueva y estaba documentada. En noviembre de 2024, el FBI emitió una notificación específica para el sector privado alertando sobre el aumento de fraudulent emergency data requests. El organismo estadounidense describía exactamente este modus operandi: delincuentes que obtenían acceso a cuentas de correo de administraciones públicas y organismos policiales para solicitar información personal de ciudadanos a empresas privadas. El FBI advertía que los criminales conocen la presión que genera una petición con carácter de urgencia y que la utilizan para que los responsables de cumplimiento reduzcan los controles habituales. Entre sus recomendaciones, el FBI pedía aplicar pensamiento crítico, verificar firmas, logotipos y fundamentos legales, y sobre todo, contactar directamente con el organismo supuestamente solicitante para validar la petición.
Antes incluso, en 2022, KrebsOnSecurity documentó cómo delincuentes utilizaban cuentas policiales comprometidas para enviar falsas solicitudes de emergencia a plataformas tecnológicas. Para bancos, fintechs y operadores de telecomunicaciones, una cuenta gubernamental comprometida debe formar parte del modelo de amenazas. Ya no puede ser considerado un supuesto excepcional.
La paradoja de la PEC italiana: un sistema legalmente robusto pero humanamente vulnerable
Si se confirma que los atacantes utilizaron una cuenta de Posta Elettronica Certificata (PEC) de Italia, el caso adquiere una dimensión adicional. La PEC no es un correo electrónico común. Según la Agencia para la Italia Digital (AgID), este sistema garantiza el envío y la entrega del mensaje, proporciona una fecha cierta y asegura la integridad de la comunicación. Un mensaje entre dos buzones PEC tiene un valor jurídico similar al de una carta certificada con acuse de recibo. La paradoja es evidente: un sistema puede certificar criptográficamente el origen y la integridad del mensaje, pero ninguna de esas propiedades garantiza que el usuario que controlaba el buzón en ese momento fuese quien estaba autorizado a escribir. Si las credenciales de la cuenta PEC fueron robadas, la infraestructura certifica perfectamente una comunicación fraudulenta. Es la versión administrativa del Business Email Compromise: el criminal escribe desde la cuenta auténtica.
Tres niveles de validación para una solicitud oficial
El incidente demuestra que las entidades financieras deben separar tres comprobaciones que tradicionalmente se han tratado como una sola. El primer nivel es la autenticidad del canal: verificar de qué infraestructura procede la comunicación. El segundo es la identidad del solicitante: determinar qué funcionario o agente está realizando la petición. El tercero, el más importante, es la autoridad de la solicitud: verificar que esa persona tiene competencia legal para pedir esa información concreta, sobre ese cliente específico y con ese alcance. Una organización puede superar el primer control y fallar estrepitosamente en los otros dos. El dominio de correo debe ser una señal de confianza, no una prueba definitiva de autorización.
Más allá de la autenticación: minimización de datos y proporcionalidad
Incluso cuando una solicitud se autentica correctamente, la entidad receptora debe analizar su alcance. El Information Commissioner’s Office (ICO) británico señala que una organización debe disponer de una base jurídica para la entrega y comprobar que es necesaria y proporcionada. El principio de minimización es clave: solo deben proporcionarse los datos adecuados, relevantes y estrictamente necesarios para la investigación. El Reglamento General de Protección de Datos (RGPD) europeo establece los mismos principios en su artículo 5, y en su artículo 32 exige aplicar medidas técnicas y organizativas adecuadas al riesgo, mencionando explícitamente el riesgo de divulgación o acceso no autorizado. La pregunta que debe hacerse un equipo de cumplimiento no es solo «¿podemos entregar estos datos?», sino «¿por qué necesita esta autoridad cada uno de ellos?» y «¿es proporcional la solicitud?»
Diseñando un sistema más resistente: anticipar el compromiso gubernamental
La respuesta al problema no es añadir un filtro antiphishing. Un modelo de seguridad robusto debe partir de la premisa de que una administración pública también puede ser comprometida. Bajo ese supuesto, el diseño de los procesos debe incluir:
- Un portal específico para solicitudes oficiales, con registro previo de organismos y funcionarios autorizados.
- Verificación fuera de banda (por teléfono o contacto directo) utilizando datos de directorios independientes, no los incluidos en la propia solicitud.
- Comprobación del expediente, la base jurídica y la jurisdicción del solicitante.
- Análisis de anomalías: una cuenta gubernamental que históricamente solicita datos de ciudadanos locales y de repente pide historiales financieros de numerosos residentes extranjeros con criptomonedas debe generar una alerta inmediata, incluso si el correo supera todas las pruebas de autenticación.
- Doble aprobación para entregas de información especialmente sensible (datos KYC, direcciones, historiales de operaciones).
- Minimización automática de los datos proporcionados.
- Trazabilidad completa de cada decisión.
Para las solicitudes de emergencia, se necesita un procedimiento específico que acelere la revisión, pero que nunca elimine la verificación de identidad y autoridad. La urgencia es precisamente la herramienta que los criminales utilizan para presionar. Por último, las propias administraciones públicas deben proteger sus cuentas con autenticación multifactor resistente al phishing, como recomendó el FBI.
Zero Trust también para las autoridades
El principio de Zero Trust, resumido como «nunca confíes, verifica siempre», debe aplicarse también a las relaciones entre empresas y administraciones públicas. No se trata de desconfiar de las fuerzas de seguridad, sino de no confundir un canal confiable con una operación autorizada. Una petición puede llegar desde un servidor legítimo, superar SPF, DKIM y DMARC, proceder de un buzón real de una administración, contener logotipos y numeración de expediente, y aun así ser fraudulento. Esa es la lección técnica más importante del caso.
Un problema de gobernanza de datos, no solo de ciberseguridad
El incidente de Revolut transforma el relato de lo que significa una brecha de seguridad. El atacante no necesitó vulnerar firewalls ni moverse lateralmente por la red. Consiguió que la organización le proporcionara los datos aprovechando la confianza depositada en una identidad externa aparentemente legítima. Esto convierte el episodio en un problema de gobernanza de datos, gestión de identidades, cumplimiento normativo y diseño de procesos. La gran pregunta que debe responder la investigación no es solo cómo consiguieron los atacantes acceso al correo gubernamental. Es otra mucho más incómoda: ¿Qué pruebas debería exigir una entidad financiera antes de convertir un correo oficial en permiso para extraer y entregar el expediente completo de un cliente? Mientras la respuesta siga descansando en la frase «el mensaje viene de un dominio de confianza», estos fallos se repetirán incluso en organizaciones con una excelente seguridad perimetral. La confianza digital debe ser un punto de partida para la verificación, no un punto de llegada para la autorización.
