{"id":68876,"date":"2026-09-16T04:10:50","date_gmt":"2026-09-16T04:10:50","guid":{"rendered":"https:\/\/overcentral.com\/es\/?p=68876"},"modified":"2026-09-16T04:10:50","modified_gmt":"2026-09-16T04:10:50","slug":"revolut-datos-clientes-falsas-solicitudes-68876","status":"publish","type":"post","link":"https:\/\/overcentral.com\/es\/revolut-datos-clientes-falsas-solicitudes-68876\/","title":{"rendered":"Revolut entrega datos de clientes por falsas solicitudes gubernamentales"},"content":{"rendered":"

El 12<\/a> de septiembre de 2026, la fintech Revolut<\/a> confirm\u00f3 un incidente de seguridad que, en lugar de relatar una intrusi\u00f3n inform\u00e1tica convencional, expuso un agujero mucho m\u00e1s profundo en la confianza digital. Un tercero no autorizado utiliz\u00f3 una direcci\u00f3n de correo electr\u00f3nico perteneciente al dominio leg\u00edtimo de una agencia gubernamental para solicitar informaci\u00f3n sensible de clientes. La compa\u00f1\u00eda respondi\u00f3 a esas peticiones y entreg\u00f3 los datos. No hubo vulneraci\u00f3n de la aplicaci\u00f3n, ni robo de credenciales de usuarios, ni acceso no autorizado a los servidores de la entidad. El atacante no necesit\u00f3 entrar: logr\u00f3 que la propia organizaci\u00f3n le abriera la puerta.<\/p>\n

Revolut entreg\u00f3 datos de clientes: la llamada que no fue una intrusi\u00f3n<\/h2>\n

La naturaleza del ataque es particularmente insidiosa. Revolut reconoci\u00f3 que un atacante explot\u00f3 la confianza depositada en los canales oficiales de comunicaci\u00f3n gubernamental. La empresa asegur\u00f3 que sus sistemas centrales y los fondos de los usuarios no se vieron comprometidos y que, una vez detectada la actividad fraudulenta, bloque\u00f3 la direcci\u00f3n de correo utilizada y notific\u00f3 a las autoridades, organismos de protecci\u00f3n de datos y reguladores financieros. Sin embargo, la investigaci\u00f3n posterior del Financial Times<\/em> revel\u00f3 detalles que agravan el caso: los atacantes habr\u00edan comprometido infraestructura italiana de Posta Elettronica Certificata (PEC)<\/strong>, un sistema de correo con valor jur\u00eddico, para hacerse pasar por organismos policiales. El diario cifr\u00f3 en aproximadamente 680 los clientes notificados<\/strong> por Revolut, se\u00f1alando que algunos objetivos estaban relacionados con importantes tenencias de criptomonedas. Estas afirmaciones provienen de la investigaci\u00f3n del FT<\/em> y de las declaraciones de los propios atacantes; Revolut no ha detallado qu\u00e9 organismo gubernamental fue suplantado ni el proceso interno que aprob\u00f3 cada solicitud.<\/p>\n

Autenticaci\u00f3n no equivale a autorizaci\u00f3n: una lecci\u00f3n t\u00e9cnica<\/h2>\n

El caso obliga a distinguir entre dos conceptos que en ciberseguridad son elementales pero que, en la pr\u00e1ctica, a menudo se confunden: la autenticaci\u00f3n y la autorizaci\u00f3n. Un sistema puede determinar con \u00e9xito que un mensaje proviene de la infraestructura de correo de una organizaci\u00f3n. Sin embargo, no puede garantizar que la persona que escribi\u00f3 ese mensaje estuviera facultada para realizar la petici\u00f3n. Con la informaci\u00f3n p\u00fablica disponible, no puede afirmarse que Revolut entregara los datos \u00fanicamente porque el correo proced\u00eda de un dominio gubernamental aut\u00e9ntico, pero sabemos que las solicitudes fraudulentas consiguieron superar el proceso de validaci\u00f3n.<\/p>\n

\u00bfQu\u00e9 es DMARC y por qu\u00e9 no protege contra este tipo de fraude?<\/h3>\n

DMARC (Domain-based Message Authentication, Reporting, and Conformance), junto con SPF y DKIM, son protocolos de autenticaci\u00f3n de correo electr\u00f3nico. Permiten comprobar que un mensaje proviene del dominio que dice utilizar y que no ha sido alterado en tr\u00e1nsito. Sin embargo, su alcance es limitado. La especificaci\u00f3n actual de DMARC (RFC 9989, publicado en 2026) deja claro que su funci\u00f3n es la autenticaci\u00f3n a nivel de dominio, no la autenticaci\u00f3n de entidades ni la legitimidad del contenido. Una validaci\u00f3n DMARC no constituye una expresi\u00f3n sobre el valor del mensaje. Es decir, un correo puede pasar todas las pruebas t\u00e9cnicas de autenticaci\u00f3n y ser, al mismo tiempo, completamente fraudulento en su contenido.<\/p>\n

La tabla siguiente ilustra esta diferencia crucial:<\/p>\n

    \n
  • SPF \/ DKIM \/ DMARC:<\/strong> Pueden acreditar que el dominio cumple condiciones de autenticaci\u00f3n. No acreditan<\/strong> que el empleado est\u00e9 autorizado para pedir datos.<\/li>\n
  • Cuenta gubernamental v\u00e1lida:<\/strong> Puede acreditar que el mensaje proviene de infraestructura real de la Administraci\u00f3n. No acredita<\/strong> que la cuenta no haya sido comprometida.<\/li>\n
  • Documento oficial:<\/strong> Puede acreditar que la petici\u00f3n tiene apariencia administrativa. No acredita<\/strong> que el documento no sea falso o manipulado.<\/li>\n
  • Identificaci\u00f3n del funcionario:<\/strong> Puede acreditar qui\u00e9n est\u00e1 detr\u00e1s de la petici\u00f3n. No acredita<\/strong> que tenga competencia legal para solicitar esos datos.<\/li>\n
  • Validaci\u00f3n jur\u00eddica:<\/strong> Puede acreditar una base legal. No acredita<\/strong> que todos los datos solicitados sean necesarios o proporcionales.<\/li>\n<\/ul>\n

    Por lo tanto, el incidente no deber\u00eda describirse como un simple \u00abfallo de autenticaci\u00f3n de correo\u00bb. Si el atacante controlaba efectivamente una cuenta o infraestructura gubernamental leg\u00edtima, los sistemas de autenticaci\u00f3n estaban funcionando correctamente. El fallo residi\u00f3 en convertir esa autenticaci\u00f3n t\u00e9cnica en una confianza suficiente para autorizar una operaci\u00f3n sensible. El verdadero problema de seguridad es que la autorizaci\u00f3n se bas\u00f3 en un \u00fanico factor de confianza.<\/p>\n

    El precedente del FBI: solicitudes de datos de emergencia fraudulentas<\/h2>\n

    Esta t\u00e9cnica no es nueva y estaba documentada. En noviembre de 2024, el FBI emiti\u00f3 una notificaci\u00f3n espec\u00edfica para el sector privado alertando sobre el aumento de fraudulent emergency data requests<\/strong>. El organismo estadounidense describ\u00eda exactamente este modus operandi: delincuentes que obten\u00edan acceso a cuentas de correo de administraciones p\u00fablicas y organismos policiales para solicitar informaci\u00f3n personal de ciudadanos a empresas privadas. El FBI advert\u00eda que los criminales conocen la presi\u00f3n que genera una petici\u00f3n con car\u00e1cter de urgencia y que la utilizan para que los responsables de cumplimiento reduzcan los controles habituales. Entre sus recomendaciones, el FBI ped\u00eda aplicar pensamiento cr\u00edtico, verificar firmas, logotipos y fundamentos legales, y sobre todo, contactar directamente con el organismo supuestamente solicitante para validar la petici\u00f3n<\/strong>.<\/p>\n

    Antes incluso, en 2022, KrebsOnSecurity document\u00f3 c\u00f3mo delincuentes utilizaban cuentas policiales comprometidas para enviar falsas solicitudes de emergencia a plataformas tecnol\u00f3gicas. 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.<\/p>\n

    La paradoja de la PEC italiana: un sistema legalmente robusto pero humanamente vulnerable<\/h2>\n

    Si se confirma que los atacantes utilizaron una cuenta de Posta Elettronica Certificata (PEC)<\/strong> de Italia, el caso adquiere una dimensi\u00f3n adicional. La PEC no es un correo electr\u00f3nico com\u00fan. Seg\u00fan la Agencia para la Italia Digital (AgID), este sistema garantiza el env\u00edo y la entrega del mensaje, proporciona una fecha cierta y asegura la integridad de la comunicaci\u00f3n. Un mensaje entre dos buzones PEC tiene un valor jur\u00eddico similar al de una carta certificada con acuse de recibo. La paradoja es evidente: un sistema puede certificar criptogr\u00e1ficamente el origen y la integridad del mensaje, pero ninguna de esas propiedades garantiza que el usuario que controlaba el buz\u00f3n en ese momento fuese quien estaba autorizado a escribir<\/strong>. Si las credenciales de la cuenta PEC fueron robadas, la infraestructura certifica perfectamente una comunicaci\u00f3n fraudulenta. Es la versi\u00f3n administrativa del Business Email Compromise<\/em>: el criminal escribe desde la cuenta aut\u00e9ntica.<\/p>\n

    Tres niveles de validaci\u00f3n para una solicitud oficial<\/h2>\n

    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<\/strong>: verificar de qu\u00e9 infraestructura procede la comunicaci\u00f3n. El segundo es la identidad del solicitante<\/strong>: determinar qu\u00e9 funcionario o agente est\u00e1 realizando la petici\u00f3n. El tercero, el m\u00e1s importante, es la autoridad de la solicitud<\/strong>: verificar que esa persona tiene competencia legal para pedir esa informaci\u00f3n concreta, sobre ese cliente espec\u00edfico y con ese alcance. Una organizaci\u00f3n puede superar el primer control y fallar estrepitosamente en los otros dos. El dominio de correo debe ser una se\u00f1al de confianza, no una prueba definitiva de autorizaci\u00f3n.<\/p>\n

    M\u00e1s all\u00e1 de la autenticaci\u00f3n: minimizaci\u00f3n de datos y proporcionalidad<\/h2>\n

    Incluso cuando una solicitud se autentica correctamente, la entidad receptora debe analizar su alcance. El Information Commissioner’s Office (ICO) brit\u00e1nico se\u00f1ala que una organizaci\u00f3n debe disponer de una base jur\u00eddica para la entrega y comprobar que es necesaria y proporcionada. El principio de minimizaci\u00f3n<\/strong> es clave: solo deben proporcionarse los datos adecuados, relevantes y estrictamente necesarios para la investigaci\u00f3n. El Reglamento General de Protecci\u00f3n de Datos (RGPD) europeo establece los mismos principios en su art\u00edculo 5, y en su art\u00edculo 32 exige aplicar medidas t\u00e9cnicas y organizativas adecuadas al riesgo, mencionando expl\u00edcitamente el riesgo de divulgaci\u00f3n o acceso no autorizado. La pregunta que debe hacerse un equipo de cumplimiento no es solo \u00ab\u00bfpodemos entregar estos datos?\u00bb, sino \u00ab\u00bfpor qu\u00e9 necesita esta autoridad cada uno de ellos?\u00bb y \u00ab\u00bfes proporcional la solicitud?\u00bb<\/p>\n

    Dise\u00f1ando un sistema m\u00e1s resistente: anticipar el compromiso gubernamental<\/h2>\n

    La respuesta al problema no es a\u00f1adir un filtro antiphishing. Un modelo de seguridad robusto debe partir de la premisa de que una administraci\u00f3n p\u00fablica tambi\u00e9n puede ser comprometida<\/strong>. Bajo ese supuesto, el dise\u00f1o de los procesos debe incluir:<\/p>\n

      \n
    • Un portal espec\u00edfico para solicitudes oficiales, con registro previo de organismos y funcionarios autorizados.<\/li>\n
    • Verificaci\u00f3n fuera de banda (por tel\u00e9fono o contacto directo) utilizando datos de directorios independientes, no los incluidos en la propia solicitud.<\/li>\n
    • Comprobaci\u00f3n del expediente, la base jur\u00eddica y la jurisdicci\u00f3n del solicitante.<\/li>\n
    • An\u00e1lisis de anomal\u00edas: una cuenta gubernamental que hist\u00f3ricamente 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\u00f3n.<\/li>\n
    • Doble aprobaci\u00f3n para entregas de informaci\u00f3n especialmente sensible (datos KYC, direcciones, historiales de operaciones).<\/li>\n
    • Minimizaci\u00f3n autom\u00e1tica de los datos proporcionados.<\/li>\n
    • Trazabilidad completa de cada decisi\u00f3n.<\/li>\n<\/ul>\n

      Para las solicitudes de emergencia, se necesita un procedimiento espec\u00edfico que acelere la revisi\u00f3n, pero que nunca elimine la verificaci\u00f3n de identidad y autoridad<\/strong>. La urgencia es precisamente la herramienta que los criminales utilizan para presionar. Por \u00faltimo, las propias administraciones p\u00fablicas deben proteger sus cuentas con autenticaci\u00f3n multifactor resistente al phishing, como recomend\u00f3 el FBI.<\/p>\n

      Zero Trust tambi\u00e9n para las autoridades<\/h2>\n

      El principio de Zero Trust<\/strong>, resumido como \u00abnunca conf\u00edes, verifica siempre\u00bb, debe aplicarse tambi\u00e9n a las relaciones entre empresas y administraciones p\u00fablicas. No se trata de desconfiar de las fuerzas de seguridad, sino de no confundir un canal confiable con una operaci\u00f3n autorizada. Una petici\u00f3n puede llegar desde un servidor leg\u00edtimo, superar SPF, DKIM y DMARC, proceder de un buz\u00f3n real de una administraci\u00f3n, contener logotipos y numeraci\u00f3n de expediente, y aun as\u00ed ser fraudulento. Esa es la lecci\u00f3n t\u00e9cnica m\u00e1s importante del caso.<\/p>\n

      Un problema de gobernanza de datos, no solo de ciberseguridad<\/h2>\n

      El incidente de Revolut transforma el relato de lo que significa una brecha de seguridad. El atacante no necesit\u00f3 vulnerar firewalls ni moverse lateralmente por la red. Consigui\u00f3 que la organizaci\u00f3n le proporcionara los datos aprovechando la confianza depositada en una identidad externa aparentemente leg\u00edtima. Esto convierte el episodio en un problema de gobernanza de datos, gesti\u00f3n de identidades, cumplimiento normativo y dise\u00f1o de procesos<\/strong>. La gran pregunta que debe responder la investigaci\u00f3n no es solo c\u00f3mo consiguieron los atacantes acceso al correo gubernamental. Es otra mucho m\u00e1s inc\u00f3moda: \u00bfQu\u00e9 pruebas deber\u00eda 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 \u00abel mensaje viene de un dominio de confianza\u00bb, estos fallos se repetir\u00e1n incluso en organizaciones con una excelente seguridad perimetral. La confianza digital debe ser un punto de partida para la verificaci\u00f3n, no un punto de llegada para la autorizaci\u00f3n.<\/p>\n","protected":false},"excerpt":{"rendered":"

      El 12 de septiembre de 2026, la fintech Revolut confirm\u00f3 un incidente de seguridad que, en lugar de relatar una intrusi\u00f3n inform\u00e1tica convencional, expuso un agujero mucho m\u00e1s profundo en la confianza digital. Un tercero no autorizado utiliz\u00f3 una direcci\u00f3n de correo electr\u00f3nico perteneciente al dominio leg\u00edtimo de una agencia gubernamental para solicitar informaci\u00f3n sensible […]<\/p>\n","protected":false},"author":2,"featured_media":68879,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/pub-4d4fc17555de4152be07eaf2a416a31e.r2.dev\/es\/ocie_1789531854359.jpg","fifu_image_alt":"Revolut entrega datos de clientes por falsas solicitudes gubernamentales","footnotes":""},"categories":[5],"tags":[],"class_list":["post-68876","post","type-post","status-publish","format-standard","has-post-thumbnail","category-tecnologia"],"fifu_image_url":"https:\/\/pub-4d4fc17555de4152be07eaf2a416a31e.r2.dev\/es\/ocie_1789531854359.jpg","fifu_image_alt":"Revolut entrega datos de clientes por falsas solicitudes gubernamentales","_links":{"self":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/68876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/comments?post=68876"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/68876\/revisions"}],"predecessor-version":[{"id":68878,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/posts\/68876\/revisions\/68878"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/media\/68879"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/media?parent=68876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/categories?post=68876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/es\/wp-json\/wp\/v2\/tags?post=68876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}