DORA
Revolut sufrió una brecha por aceptar una petición oficial falsa: el fraude que pone a prueba DORA
20 min lectura
Imagen generada por IARevolut no fue víctima de un robo de fondos ni de una intrusión en sus sistemas. Fue algo más incómodo: alguien consiguió que la empresa entregara datos personales sensibles porque la petición parecía proceder de una autoridad pública.
La plataforma financiera británica confirmó el 14 de septiembre de 2026 que un atacante utilizó un dominio gubernamental comprometido para formular una solicitud de información. La compañía no ha publicado el número exacto de afectados ni los países donde residen. Solo ha indicado que se trató de un grupo «muy limitado» de clientes y que las personas afectadas han sido notificadas directamente.
La diferencia entre hackear una base de datos y convencer a un empleado autorizado para que la consulte puede ser técnicamente relevante. Para el cliente cuya copia del pasaporte, fecha de nacimiento o selfie de verificación acaba en manos de un delincuente, lo es bastante menos.
El incidente, revelado por Bank Info Security, merece atención por tres razones. Primero, muestra que la identidad del solicitante puede ser el control más débil de un proceso diseñado para responder a autoridades. Segundo, obliga a separar con cuidado las obligaciones de GDPR, DORA y NIS2, que no se activan exactamente de la misma manera. Y tercero, desmonta una idea cómoda pero peligrosa: que la ingeniería social pertenece al departamento de fraude y no al programa de resiliencia operativa.
La brecha no empezó con malware, sino con una decisión aparentemente legítima
La información publicada describe una cadena sencilla. Un tercero envió a Revolut una petición de datos con apariencia oficial desde un dominio de correo gubernamental que había sido comprometido. La empresa trató la comunicación como una solicitud válida y facilitó información de clientes. El atacante no habría accedido directamente a los sistemas internos ni habría sustraído fondos de las cuentas.
La compañía comunicó a los clientes que la exposición podía incluir nombre, fecha de nacimiento, profesión, datos de contacto, una copia del permiso de conducir o del pasaporte empleado para verificar la cuenta y una selfie utilizada en el proceso de identificación facial. También se habrían visto afectados extractos de cuenta con el IBAN, la fecha de apertura y el número de referencia de una cartera móvil.
Revolut añadió una precisión relevante: no se había comprometido la telemetría biométrica facial. Eso limita el tipo de información biométrica afectada, pero no convierte la filtración en un incidente menor. Una imagen facial aislada puede no equivaler a una plantilla biométrica, pero combinada con documento de identidad, IBAN, profesión, fecha de nacimiento y datos de contacto forma un paquete extraordinariamente útil para el fraude dirigido.
El investigador de blockchain ZachXBT apuntó que el ataque podía haber tenido como objetivo a usuarios con un patrimonio elevado. La hipótesis no está confirmada por Revolut, pero encaja con la selección de datos: una petición falsa no necesita obtener millones de registros si identifica a unas pocas personas con capacidad económica, exposición pública o acceso a cuentas empresariales.
Aquí está el quid. El control falló antes de la base de datos. Falló en la autenticación de la autoridad solicitante, en la validación del canal y, previsiblemente, en la segregación entre quien recibe una petición y quien autoriza la entrega. La tecnología pudo funcionar como estaba diseñada. El proceso, no.
Qué hace especialmente peligroso al expediente expuesto
Los datos no tienen todos el mismo valor operativo. Un nombre puede servir para una suplantación básica. Un documento oficial permite superar controles de identidad deficientes. Un IBAN facilita campañas de fraude convincentes. La combinación de una selfie, un pasaporte y datos financieros aumenta la credibilidad de llamadas, mensajes y correos posteriores.
El riesgo tampoco termina en el titular de la cuenta. Un atacante con información suficiente puede fabricar una emergencia, hacerse pasar por un empleado de Revolut, contactar con un familiar o utilizar datos profesionales para dirigirse al departamento de tesorería de una empresa. La finalidad puede ser conseguir nuevas credenciales, redirigir pagos, persuadir al cliente para que instale una aplicación o vencer una comprobación manual que, vista desde fuera, parece razonable.
Los datos de identificación tienen además una característica que los diferencia de una contraseña: no se cambian con facilidad. Si se filtra un secreto de acceso, se rota. Si se filtra una copia del pasaporte o una fecha de nacimiento, el margen de reparación es mucho menor. Por eso la notificación al afectado no debería limitarse a informar de que hubo una exposición. Debe explicar qué datos concretos salieron, qué usos fraudulentos son plausibles y qué señales debe vigilar el cliente.
La frase «no se robaron fondos» puede ser cierta y aun así insuficiente. La ausencia de una transferencia fraudulenta en el momento de la revelación no demuestra que el incidente carezca de impacto financiero. En un caso de suplantación de identidad, el daño puede aparecer semanas después, cuando los datos ya circulan entre actores distintos y la entidad original ha dejado de controlar su distribución.
La exposición de documentos y selfies plantea también una cuestión de minimización. El artículo 5.1.c del GDPR exige que los datos sean adecuados, pertinentes y limitados a lo necesario para la finalidad perseguida. Ese principio no impide a una entidad conservar documentación de identificación cuando existe una obligación legal de diligencia debida. Pero sí obliga a preguntar cuánto dato se entrega ante una solicitud externa, quién puede verlo, durante cuánto tiempo y por qué el solicitante necesita cada campo.
Una petición de emergencia de una autoridad no debería convertirse en una llave maestra. Si el proceso permite descargar de una sola vez documentos, datos de contacto y extractos financieros sin una justificación granular, el diseño está tratando una excepción como si fuera un flujo ordinario. Las excepciones son precisamente donde los controles suelen acudir con menos entusiasmo.
GDPR: la pregunta no es solo si hubo acceso, sino cuándo empezó la obligación
Para el GDPR, el caso encaja potencialmente en la definición de violación de la seguridad de los datos personales del artículo 4.12: una vulneración que provoque destrucción, pérdida, alteración, comunicación o acceso no autorizado a datos personales. No hace falta que un atacante explote una vulnerabilidad de software. Una comunicación no autorizada causada por ingeniería social puede entrar en la misma categoría.
El artículo 32 exige medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. En una entidad financiera digital, eso no se traduce únicamente en cifrado, detección de intrusiones o gestión de parches. Incluye los procedimientos de verificación aplicados cuando alguien pide datos de clientes en nombre de una policía, un regulador o una fiscalía.
El artículo 33 establece el plazo de 72 horas para notificar una violación a la autoridad de control competente cuando sea probable que entrañe un riesgo para los derechos y libertades de las personas. El plazo empieza cuando el responsable del tratamiento tiene constancia de la brecha, no cuando termina la investigación forense ni cuando la dirección ha conseguido una narración perfectamente ordenada de los hechos.
La notificación inicial puede ser incompleta. El propio artículo 33 permite aportar información por fases cuando no sea posible facilitar todos los detalles al mismo tiempo. Esperar a conocer el número exacto de afectados no es una estrategia prudente si ya existe evidencia de que documentos de identidad y datos financieros fueron comunicados a un tercero no autorizado.
El artículo 34 añade la comunicación directa a los interesados cuando la violación pueda entrañar un alto riesgo para sus derechos y libertades. La exposición de una copia de pasaporte, una selfie de verificación y datos de cuenta ofrece argumentos claros para valorar ese riesgo, aunque el volumen de afectados sea pequeño. «Muy limitado» describe una cantidad; no describe necesariamente la gravedad individual.
El análisis debe documentarse incluso si finalmente no se notifica a la autoridad. El artículo 33.5 obliga al responsable a documentar las violaciones, incluidos los hechos, sus efectos y las medidas correctivas adoptadas. Esa documentación debe permitir a la autoridad comprobar el cumplimiento, no funcionar como un cajón donde se archiva la decisión que nadie quiere volver a discutir.
También importa la geografía jurídica. Las entidades de Revolut que operan en el Espacio Económico Europeo estarán sujetas al GDPR respecto de tratamientos que entren en su ámbito. La operación británica se relaciona con el UK GDPR, cuyo plazo de notificación también es de 72 horas y cuya autoridad de referencia es la Information Commissioner’s Office. El artículo publicado sitúa la actividad del grupo en 30 países, pero no identifica dónde estaban los clientes afectados. Por eso no sería serio atribuir el expediente a una única autoridad sin conocer la entidad responsable del tratamiento y la localización de los interesados.
La cifra de multas que circula en algunas referencias también necesita precisión. El GDPR de la Unión Europea permite multas de hasta 20 millones de euros o el 4 % del volumen de negocio anual mundial total del ejercicio financiero anterior, según el artículo 83.5. El UK GDPR contempla un máximo de 17,5 millones de libras o el 4 % de la facturación global anual. No son intercambiables, y presentar ambas cifras en dólares solo añade ruido.
DORA convierte el fraude de identidad en un asunto de resiliencia operativa
La aplicación de DORA no depende de que el atacante haya ejecutado código dentro de la infraestructura de Revolut. El Reglamento (UE) 2022/2554 define en su artículo 3.8 el incidente relacionado con las TIC como un suceso que compromete la seguridad de las redes y sistemas de información y afecta negativamente a la disponibilidad, autenticidad, integridad o confidencialidad de los datos o servicios. Una divulgación no autorizada de información mediante un canal manipulado puede activar, como mínimo, un análisis serio bajo esa definición.
El artículo 17 exige que las entidades financieras establezcan y mantengan un proceso de gestión de incidentes relacionados con las TIC. Ese proceso debe detectar, gestionar y notificar incidentes. Si el equipo de solicitudes legales o de cumplimiento recibe una comunicación falsa, el incidente no debería permanecer encerrado en ese departamento como un error administrativo. Tiene que entrar en el circuito de incidentes, con evaluación de impacto, preservación de evidencias y participación de seguridad, privacidad, fraude y dirección.
El artículo 18 obliga a clasificar los incidentes relacionados con las TIC y las ciberamenazas atendiendo a criterios como el número y relevancia de clientes o contrapartes afectados, la duración, la propagación geográfica, las pérdidas económicas y la criticidad de los servicios comprometidos. DORA no dice que todo incidente con pocos afectados sea menor. La clasificación debe atender al impacto y a los umbrales técnicos establecidos en las normas de desarrollo.
Cuando el incidente sea grave, el artículo 19 exige informar a la autoridad competente. DORA prevé un aviso inicial, un informe intermedio y un informe final, con plazos y formatos armonizados. La evaluación no debe hacerse con una regla simplista del tipo «no hubo caída de servicio, luego no hay incidente DORA». La confidencialidad es uno de los atributos protegidos por el artículo 3.8; una filtración puede ser material aunque la aplicación siga funcionando con normalidad.
La investigación pública disponible no permite afirmar que Revolut debiera haber remitido un informe DORA ni que la autoridad haya abierto un expediente. Eso dependerá de la entidad jurídica afectada, de la clasificación y de los umbrales aplicables. Sí permite afirmar que el escenario debe estar contemplado en el proceso de incidentes de una entidad financiera. Si no lo está, el programa de resiliencia está midiendo disponibilidad mientras ignora autenticidad y confidencialidad.
DORA también lleva la conversación al órgano de dirección. El artículo 5 atribuye al órgano de gestión la responsabilidad última de gestionar y controlar los riesgos relacionados con las TIC. No basta con que el CISO presente un cuadro de amenazas y el responsable de privacidad otro de brechas. El consejo debe saber quién puede ordenar la entrega de datos, qué comprobación se exige antes de hacerlo y cuántas excepciones se han utilizado sin una segunda validación.
El artículo 11, dedicado a la respuesta y recuperación, exige políticas y procedimientos para detectar, gestionar y notificar incidentes relacionados con las TIC. En este caso, la recuperación no consiste en restaurar servidores desde una copia de seguridad. Consiste en identificar los datos entregados, congelar el proceso que permitió la divulgación, contactar con los afectados, alertar a las autoridades pertinentes y reducir el uso posterior de esa información.
Para el sector financiero español, el mensaje es práctico. Una entidad supervisada por el Banco de España, la CNMV o la Dirección General de Seguros y Fondos de Pensiones no puede tratar las peticiones de autoridades como un proceso puramente jurídico. Si sus sistemas gestionan solicitudes externas, ese flujo debe figurar en el inventario de procesos críticos, en el registro de incidentes y en las pruebas de resiliencia. El hecho de que la petición llegue por correo electrónico no la convierte en un asunto ajeno a DORA.
NIS2 no es un comodín regulatorio
La referencia a NIS2 resulta comprensible, pero hay que evitar una lectura automática. El artículo 21 de la Directiva (UE) 2022/2555 exige medidas de gestión de riesgos de ciberseguridad para entidades esenciales e importantes. El artículo 23 establece la comunicación de incidentes significativos: alerta temprana en 24 horas, notificación del incidente en 72 horas y un informe final, normalmente, en el plazo de un mes.
Sin embargo, el artículo 4.1 de NIS2 establece una relación específica con la normativa de resiliencia digital del sector financiero. Las entidades financieras sujetas a requisitos de gestión de riesgos y notificación de incidentes equivalentes en actos jurídicos de la Unión, incluido DORA, quedan fuera de determinadas obligaciones de NIS2 en la medida prevista por esa disposición. En otras palabras, no se deben sumar mecánicamente las dos cadenas de notificación sobre el mismo incidente.
Eso no hace irrelevante a NIS2. Sí obliga a identificar qué entidad del grupo está afectada, qué servicio presta, qué régimen sectorial le corresponde y qué autoridad recibe la comunicación. Una fintech con varias sociedades puede tener una entidad financiera cubierta por DORA y otras compañías tecnológicas o de servicios sujetas a obligaciones distintas. El organigrama legal, que rara vez entusiasma a nadie, puede decidir qué reloj regulatorio empieza a correr.
La lección para los equipos de compliance es evitar el documento titulado «matriz DORA-NIS2» que solo enumera normas. La matriz útil debe responder a preguntas operativas: quién decide que una petición externa es legítima, quién puede extraer información, qué evidencias se conservan, qué autoridad debe recibir la notificación y cómo se coordina la respuesta si el mismo grupo tiene varias entidades en diferentes jurisdicciones.
El método de los atacantes: credenciales legítimas, canales legales y autoridad prestada
Alon Gal, director de tecnología de Hudson Rock, señaló que los actores maliciosos pueden comprometer buzones mediante credenciales legítimas obtenidas, por ejemplo, de infostealers, o acceder a plataformas destinadas a gestionar solicitudes de autoridades. El patrón importa porque desplaza la defensa desde la detección de malware hacia la confianza en la identidad y el contexto.
El correo de un dominio gubernamental puede ser auténtico y aun así no ser una petición auténtica. La cuenta puede estar comprometida. El dominio puede estar correctamente configurado. La firma digital puede corresponder a un buzón real. Ninguno de esos elementos prueba, por sí solo, que la persona que solicita los datos tenga autoridad, que la investigación exista o que el alcance de la petición sea legítimo.
Plataformas como Kodex se diseñaron para reducir la dependencia del correo electrónico en solicitudes legales, incluidos requerimientos y peticiones de emergencia. Esa arquitectura puede mejorar la trazabilidad, pero no elimina el riesgo. El propio artículo recuerda que en 2024 el actor conocido como Tamagami afirmó ofrecer acceso a cuentas gubernamentales de Kodex para presentar solicitudes falsas. Sustituir el email por un portal reduce una clase de ataque; no convierte la identidad en una verdad matemática.
La recomendación de llamar a la persona que inicia una petición es razonable, pero ya no basta con una llamada improvisada. Las herramientas de clonación de voz y vídeo hacen que la comunicación audiovisual sea una señal adicional, no una prueba concluyente. La validación debe apoyarse en un canal independiente y previamente registrado: un número publicado en el directorio oficial de la autoridad, un contacto verificado en una red institucional o una consulta directa a la unidad competente. El número que aparece en el email no cuenta como canal independiente si el atacante controla el mensaje.
La autenticación multifactor tampoco resuelve por sí sola el problema. Protege la cuenta del solicitante frente a determinados accesos no autorizados, pero no confirma que una petición enviada desde una cuenta legítima sea proporcional, actual o válida. La identidad digital y la legitimidad de la solicitud son controles distintos. Confundirlos es cómo se acaba entregando un documento perfectamente protegido a la persona equivocada.
Qué debería cambiar en los controles de una entidad financiera
La primera corrección es separar recepción, validación y entrega. Una misma persona no debería poder recibir una solicitud externa, decidir que es válida, seleccionar los datos y exportarlos sin revisión, especialmente cuando se piden documentos de identidad o información financiera. La separación no tiene que paralizar las emergencias, pero sí exigir una segunda aprobación documentada para las categorías de datos de mayor riesgo.
La segunda es diseñar una clasificación de solicitudes. No requiere el mismo nivel de prueba una petición para confirmar si existe una cuenta que una solicitud de pasaporte, selfie, extractos, IBAN y datos de contacto. El sistema debería elevar automáticamente el nivel de control cuando concurran identificadores oficiales, información financiera, múltiples clientes, urgencia extraordinaria o una autoridad extranjera.
La tercera es exigir minimización por campo. El solicitante debe explicar qué necesita y para qué. El operador interno debe entregar solo aquello que esté autorizado. Las exportaciones masivas, los archivos comprimidos sin detalle y las respuestas que incluyen campos no solicitados deberían activar una alerta. La pregunta decisiva no es «¿podemos enviar todo?», sino «¿qué elemento concreto está justificado?».
La cuarta es registrar la evidencia antes de cerrar el expediente. Deben conservarse la petición original, las cabeceras técnicas, los dominios y certificados relevantes, los contactos utilizados para verificarla, la identidad de quienes aprobaron la entrega, los campos exportados y las instrucciones dadas al personal. En un proceso regulado, una captura de pantalla del correo es insuficiente si no permite reconstruir quién hizo qué y cuándo.
La quinta es probar el control con escenarios realistas. Un ejercicio útil no consiste en enviar un correo obviamente mal redactado desde una dirección extraña. Debe simular una petición de emergencia desde un dominio comprometido, con lenguaje jurídico correcto, una firma verosímil y presión temporal. El objetivo es comprobar si el empleado sabe romper la urgencia, encontrar un canal independiente y escalar la decisión.
La sexta es conectar los equipos. Legal puede reconocer el formato de una orden; fraude puede detectar una selección sospechosa de clientes; privacidad puede evaluar el riesgo para los interesados; seguridad puede analizar la infraestructura del remitente; relaciones institucionales puede verificar a la autoridad. Si cada uno trabaja en su propia bandeja, el atacante solo necesita convencer al primero.
También conviene establecer indicadores concretos. Por ejemplo: porcentaje de solicitudes verificadas mediante un canal independiente; tiempo medio entre recepción y validación; número de entregas con doble aprobación; peticiones que incluyen más datos de los necesarios; solicitudes rechazadas por inconsistencias; y exportaciones realizadas fuera de horario. No son métricas perfectas, pero son más útiles que afirmar que el procedimiento está «implantado» porque existe un documento en la intranet.
La supervisión no se detiene en el incidente publicado
La confirmación de una brecha no resuelve las preguntas de fondo. Revolut tendrá que determinar cuándo recibió la petición, cuándo verificó —o dejó de verificar— su autenticidad, qué entidad aprobó la entrega, cuántos registros salieron, qué usuarios eran de la Unión Europea o del Reino Unido y qué controles se activaron después. La investigación deberá distinguir entre hechos confirmados, hipótesis y afirmaciones de terceros.
La comunicación a clientes tiene una dificultad adicional: debe ser suficientemente concreta sin proporcionar un manual para futuras campañas de fraude. Informar de que se expusieron documentos de identidad y selfies exige explicar el riesgo de suplantación, pero también advertir contra llamadas que utilicen esos datos para pedir códigos, transferencias o cambios de número de teléfono.
La entidad debería revisar asimismo si sus contratos y procedimientos con proveedores de gestión de solicitudes, verificación de identidad y atención al cliente reflejan el riesgo. El artículo 28 de DORA exige gestionar los riesgos derivados de terceros proveedores de servicios TIC y el artículo 30 establece elementos contractuales esenciales para esos acuerdos. Si una plataforma intermediaria, un sistema de tickets o un servicio de archivo participa en el flujo, el análisis no puede acabar en el buzón de la entidad financiera.
El mismo razonamiento se aplica a los ejercicios de pruebas. DORA no pide una colección de certificados decorativos; exige capacidad de resistencia. Una organización que supera una prueba de penetración pero entrega documentos ante un dominio gubernamental comprometido ha probado una parte del problema, no el problema completo.
La alta dirección también debería pedir una respuesta a una pregunta incómoda: ¿cuántas personas pueden entregar datos sensibles basándose solo en la apariencia de una petición? Si la respuesta es «depende del criterio del operador», el control no es escalable. El criterio humano debe existir, pero encajado en reglas de escalado, doble autorización y trazabilidad.
El verdadero perímetro de seguridad está donde alguien toma una decisión
El caso de Revolut no inaugura la suplantación de autoridades. El artículo de Bank Info Security recuerda que se trata de una táctica habitual. Lo relevante es que el sector financiero sigue tratando muchos flujos de información como si la amenaza principal fuera un atacante intentando entrar por la puerta técnica, cuando algunos de los incidentes más dañinos comienzan con una persona que abre la puerta desde dentro creyendo que está cumpliendo la ley.
La respuesta no es prohibir las solicitudes urgentes ni exigir una burocracia imposible cada vez que una autoridad necesita información. Es diseñar un proceso que asuma que el dominio puede estar comprometido, la cuenta puede ser legítima, la firma puede ser correcta y la urgencia puede ser falsa. La confianza debe acumularse mediante señales independientes, no concederse por la estética institucional del mensaje.
Para Revolut, el episodio llega mientras la compañía busca nuevas autorizaciones en Estados Unidos y prepara el lanzamiento previsto de Revolut US en 2027, sujeto a las aprobaciones pendientes. Esa expansión no convierte automáticamente el incidente europeo en un problema estadounidense, pero sí eleva el escrutinio sobre gobierno, controles de identidad y capacidad de operar como entidad financiera en varias jurisdicciones. La escala comercial multiplica los servicios; también multiplica los lugares donde una petición falsa puede parecer plausible.
La lección para cualquier banco, aseguradora o fintech es más amplia que «formar mejor a los empleados». Hay que gobernar el canal, verificar la autoridad, limitar los datos, registrar la evidencia y ensayar la excepción. GDPR preguntará por el riesgo para las personas. DORA preguntará por la gestión del incidente y la resiliencia. NIS2 puede entrar en juego según la entidad y el régimen aplicable. Ninguna de esas normas acepta como defensa que el correo tenía buena pinta.