El buzón era oficial. La petición no
Revolut entregó datos de 680 clientes a quien los pidió desde el correo legítimo de una agencia gubernamental. No hizo falta entrar en sus sistemas: la autenticación era válida, pero el proceso confundió el origen del mensaje con la autoridad para pedir los datos.
El viernes 18, El Mundo tituló así: «Fallo informático, hackeo, rescate... Revolut confirma un incidente por suplantación de identidad que afecta a 680 clientes». Y en la propia pieza el banco rechaza las tres palabras del principio. Lo suyo, dice, fue «un sofisticado caso de suplantación de identidad».
Tiene razón, y eso es justo lo interesante. No hizo falta entrar en los sistemas de Revolut. Ni robarle una contraseña, ni explotar un fallo, ni instalar nada en sus servidores. Alguien pidió los datos de unos clientes por escrito, desde una dirección de correo que pertenece de verdad a un organismo público, y el banco se los mandó.
Hace tres semanas conté aquí la anatomía de una citación judicial falsa que pasó SPF, DKIM y DMARC porque salía, de verdad, del dominio que decía. La conclusión era que autenticar un correo responde a «¿viene del dominio que dice?» y nunca a «¿es verdad lo que cuenta?».
Esto es la misma frase con dos diferencias que la hacen bastante peor. El dominio, esta vez, era el de un organismo público. Y quien tenía que contestar a la pregunta no era una persona a las ocho de la mañana con el café a medias: era el departamento de cumplimiento normativo de un banco con más de ochenta millones de clientes.

El buzón parece oficial, el edificio también, y el papel lleva su sello. Lo que no sale en ninguna parte es quién lo ha escrito. Ilustración generada con IA para este artículo; no representa ningún buzón, edificio ni documento reales del caso.
Lo que se sabe, y quién lo dice
Esta semana se han mezclado tres voces distintas, y conviene no cambiarlas de columna:
| Lo confirma Revolut | Lo publica la prensa | Lo dicen los atacantes |
|---|---|---|
| Un tercero usó «el dominio legítimo de correo electrónico de una agencia gubernamental» para pedir información | Que la dirección es un buzón de correo certificado de la Prefectura de Reggio Calabria | Que entraron en un sistema del Gobierno italiano con un programa que roba credenciales |
| 680 clientes afectados | Que las peticiones se mandaron durante varios meses | Un rescate de 6.000 monero, unos tres millones de dólares |
| Ni sus sistemas ni los fondos de los clientes se han visto afectados | Que antes de pedir nada localizaron, analizando la cadena de bloques, cuentas con criptomonedas | Un plazo de 24 horas antes de vender los datos |
| No ha recibido ninguna exigencia de quienes se atribuyen la brecha | Que la autoridad británica de protección de datos ha recibido la notificación |
La primera columna sale de lo que el banco ha dicho a TechCrunch y a El Mundo. La segunda es sobre todo del Financial Times, que adelantó la cifra y la pista italiana, recogido por Euronews y por The Irish Times, y de la prensa italiana. La tercera es de un grupo que firma como iamnotavillain y ha publicado su exigencia en abierto, y es la que menos vale: la primera cifra de rescate que circuló fueron diez mil bitcoin.
Lo que salió por la puerta lo detalla el aviso que el banco ha mandado a los afectados, y que algunos han hecho público: fecha de nacimiento, direcciones postal y de correo, teléfono, copias del pasaporte o del carné de conducir y, según el caso, el selfi de verificación de identidad, extractos, IBAN e historial de movimientos, incluidos los de bitcoin.
Revolut no ha identificado públicamente a la agencia. Il Post publicó el 16 la dirección que aparece en las capturas: un buzón de correo electrónico certificado de la Prefectura de Reggio Calabria, en el dominio del Ministerio del Interior italiano. La Fiscalía de Reggio Calabria ha abierto una investigación por acceso ilícito a un sistema informático de interés público, y lo primero que intenta aclarar es si ese buzón fue vulnerado o si la cuenta se clonó o se usó de forma abusiva. Es decir: ni siquiera está resuelto cómo consiguieron mandar los mensajes.
Lo que enseñan las capturas
Esas capturas las difundió en X una cuenta que estuvo en contacto con los atacantes, así que su procedencia es la que es. Pero lo que cuenta Il Post a partir de ellas es muy concreto:
- Las peticiones no fueron a la filial italiana del banco, sino a la lituana.
- Invocaban una supuesta investigación de la Fiscalía de Milán y la orden europea de investigación, un instrumento de cooperación entre Estados de la Unión.
- El 24 de marzo, el banco pidió corregir el encabezado de un correo y explicó cómo rellenar bien la solicitud para recibir los datos.
- A principios de mayo, se disculpó por el retraso.
- El 24 de julio, confirmó el envío de todos los documentos, con la contraseña para descifrarlos en otro correo, y avisó de que 169 de los perfiles dependían de la entidad británica y necesitaban otro procedimiento.
Y Il Post señala las rarezas: una petición de la Fiscalía de Milán enviada desde una dirección de Reggio Calabria, y números de protocolo que corresponden a la Fiscalía de Roma.
Esta vez, DMARC tenía razón
En el post de la citación falsa escribí que aquel atacante no intentó suplantar un dominio de Justicia porque eso habría fallado, y que precisamente para eso existe DMARC.
Aquí nadie suplantó ningún dominio. Según lo publicado, las peticiones salieron de una dirección que pertenece al propio dominio del organismo; si porque la cuenta estaba comprometida o por otra vía, es lo que investiga la Fiscalía. Y El Mundo, en la explicación que acompaña a las declaraciones del banco, lo cuenta así: como las solicitudes llegaban con «una autenticación técnica de dominio válida», se tramitaron «siguiendo el procedimiento habitual de cumplimiento normativo», con «la presunción razonable de que se trataba de una petición legítima».
Es decir, las comprobaciones del correo dieron pass y tenían razón al darlo: el mensaje salía de verdad de ese dominio. El protocolo funcionó. Ninguna comprobación de autenticación puede parar esos correos sin parar también los auténticos del mismo buzón: a ese nivel, son indistinguibles.
DMARC te dice de qué casa sale la carta. No te dice quién estaba sentado a la mesa cuando se escribió.

Dos buzones de Poste Italiane en Sesto (Sexten), en el Tirol del Sur, en julio de 2020. El azul lleva hasta el escudo de la provincia autónoma. Todo lo que entra por esas ranuras sale con el mismo matasellos, y el matasellos dice por dónde entró la carta, no quién la escribió. La foto no tiene relación con el caso: son buzones postales de otra provincia, y el correo del que habla este artículo es electrónico. Foto: Mateus2019, CC BY 3.0 DE, vía Wikimedia Commons; imagen reescalada.
No se rompió nada, y ese es el problema
Lo que describe el banco es un proceso haciendo exactamente aquello para lo que está diseñado. Las entidades financieras están obligadas a atender los requerimientos legalmente válidos de los organismos públicos y de la policía, y un correo desde un dominio oficial no convierte cualquier solicitud en uno de ellos. El proceso tenía un paso de comprobación: «¿viene de un dominio oficial?». La respuesta era que sí. El resto vino solo.
Y antes de que salga el «qué torpes», hay que decir que ese paso no es ninguna tontería, y la mayoría de los proveedores hace lo mismo. Un equipo de cumplimiento que recibe peticiones de policías de media Europa no puede tratar cada una como sospechosa. Retrasar una petición legítima puede entorpecer una investigación, y en las de emergencia hay en juego la seguridad de alguien. Negarse tiene un coste, y lo pagan otros. Mark Rasch, exfiscal del Departamento de Justicia de Estados Unidos, se lo explicaba en 2022 a Brian Krebs: la mayoría de proveedores no tiene definido ningún mecanismo para comprobar la validez de una orden o un requerimiento, y mientras parezca correcto, lo cumplen.
Yo tampoco me pongo fuera. Si mañana me escribe una policía desde su dominio pidiendo los registros de acceso de la web de un cliente, mi primer reflejo va a ser preguntarme cómo se los mando, no si son quienes dicen.
Ya lo apunté a cuenta de la película Hackers: el eslabón que cede es el que quiere ser útil, y no cede por tonto, sino porque el ataque está diseñado para explotar una virtud. En 1995 la virtud era la amabilidad de un vigilante al teléfono. Aquí es institucional: cumplir la ley.
Las capturas añaden algo incómodo. El proceso miró con lupa la jurisdicción propia: esos 169 perfiles eran de otra entidad del grupo y pedían otro procedimiento. Nadie, que se sepa, se paró en la ajena: una fiscalía de Milán escribiendo desde una prefectura de Calabria, con números de protocolo de Roma. Y cuando el formato no era el correcto, la respuesta fue explicar cómo arreglarlo.
Visto desde fuera y a toro pasado, es fácil verlo. Dentro, cada petición llega sola, entre muchas, y un número de protocolo mal puesto parece casi siempre lo que es casi siempre: una errata.
Lo que falló no es el filtro. Es que el proceso comprobó el canal y dio por supuesta la autoridad, y a partir de ahí el contenido dejó de leerse como una prueba. Usó el dominio como si fuera una firma, y un dominio no es eso: es una dirección.
Tiene nombre, y tiene precio
La técnica no es nueva: es la familia de las peticiones oficiales falsas. Su versión más conocida, y la más peligrosa, es la de emergencia. En Estados Unidos se llama emergency data request, petición de datos de emergencia: el cauce por el que la policía pide datos a una empresa cuando no hay tiempo de conseguir una orden judicial porque hay una vida en peligro. No pasa por un juez, y por eso es rápido. Y por eso mismo es un objetivo.
En marzo de 2022, Krebs contó que había gente usando buzones robados de comisarías para mandar esas peticiones, y lo relacionó con Lapsus$, el grupo que por entonces acababa de entrar en Microsoft, Nvidia y Okta. Al día siguiente, Bloomberg publicó que Apple y Meta habían entregado a mediados de 2021 direcciones, teléfonos e IP de usuarios en respuesta a peticiones falsificadas así.
En noviembre de 2024 el FBI mandó a las empresas una notificación entera sobre el asunto. Cuenta que en los foros se venden cuentas de correo gubernamentales, alguna con instrucciones para redactar la petición incluidas, y que un vendedor presumía de tenerlas de más de veinticinco países. Otro, en agosto de 2023, enseñaba a preparar tus propias peticiones por cien dólares. Y la notificación trae una frase sobre la urgencia:
Los ciberdelincuentes entienden la necesidad de urgencia y la usan a su favor para saltarse el análisis que la petición necesita.
La misma notificación cuenta un caso que acabó bien: en marzo de 2024 alguien mandó a PayPal una petición de asistencia judicial internacional sobre una supuesta investigación de tráfico de menores, con su número de caso y su referencia legal, y PayPal la rechazó. Se puede decir que no.
En el caso de Revolut ni siquiera hizo falta la urgencia. Según las capturas, las peticiones se presentaban como una investigación ordinaria de una fiscalía, el intercambio duró meses, y quien se disculpó por el retraso fue el banco. Cambia el formulario. La familia es la misma.
Lo que convierte un buzón en autoridad
La lección de la citación falsa era para personas: comprobar lo que afirma un correo por un canal que no dependa del propio correo. Esta es exactamente la misma, subida un piso. La que tiene que aprenderla es la organización.
- Otro canal, y que no salga del correo. Es lo que recomienda el FBI: ante la duda, contactar con quien envía y con la autoridad de la que dice venir. Con un teléfono sacado del directorio oficial del organismo, no del pie de firma del mensaje, que lo ha escrito quien lo manda.
- Un historial, no un dominio. Kodex, una empresa que filtra peticiones policiales para plataformas tecnológicas y financieras, puntúa a cada solicitante por su trayectoria: quien lleva años mandando peticiones válidas puntúa más que quien escribe por primera vez. Su fundador, un exagente del FBI, lo resumía así en la pieza de Krebs de 2024: poder usar el correo legítimo de una policía para abrirse una cuenta no significa poder mandar nada. De 1.597 peticiones de emergencia que pasaron por ellos en un año, 485 —cerca del 30 %— no superaron la segunda verificación.
- Mirar el patrón, no solo la petición. Si una misma dirección concentró durante meses peticiones sobre cientos de clientes, eso tampoco tiene por qué ser automáticamente anómalo, porque hay investigaciones grandes. Pero es un contador que se puede mirar.
- Entregar lo que se pide, y no el expediente. Ante una petición oficial, ¿qué sale por la puerta en tu organización: los datos concretos que se piden, o todo lo que hay en la ficha del cliente? La diferencia entre las dos cosas es lo que se pierde el día que la petición es falsa.
Por qué esos datos
Según el FT, la lista de clientes no era aleatoria. Primero buscaron en la cadena de bloques cuentas con criptomonedas, y después pidieron los datos de esas cuentas.
Y el paquete que salió es precisamente el que sirve para pasar del dinero a la persona: el pasaporte, la cara, la dirección de casa y el justificante de que esa persona tiene criptomonedas. BankInfoSecurity recoge que al menos un afectado conocido del mundo cripto ha contado en público que ha recibido intentos de extorsión.
Una contraseña robada se cambia en un minuto. Una dirección y una cara no caducan.
Si eres cliente de Revolut
El banco dice que ya se ha puesto en contacto directamente con los afectados. Si tú estás entre ellos, lo que viene no es un problema técnico, sino llamadas y correos que van a saber cosas ciertas de ti.
- Que alguien sepa tu número de pasaporte no demuestra que sea del banco. Es justo el dato que ahora tienen los atacantes. Si te llaman, cuelga y entra tú en la aplicación o llama al número que busques tú.
- Si te piden mover dinero a una «cuenta segura», es la estafa de manual, se presente como se presente.
- No negocies con nadie que te escriba por los datos. Guarda los mensajes y denúncialo. Si no sabes por dónde empezar, INCIBE atiende gratis en el 017.
El remitente era auténtico, otra vez
Hace tres semanas terminé diciendo que verificar el remitente sigue siendo buena idea, solo que verifica al remitente. Esta semana ha salido el caso que lo lleva al extremo: un remitente que superaba todas las comprobaciones del correo, un proceso que hizo lo que tenía previsto, y 680 personas cuyos documentos de identidad están ahora en manos de alguien que pide rescate por ellos.
La pregunta «¿de dónde viene esto?» la tenemos resuelta, y muy bien. La que queda, «¿quién lo ha escrito y tiene derecho a pedirlo?», no la contesta ningún protocolo. La contesta un teléfono, marcado a mano, a un número que no venía en el correo.
(Y la diferencia entre los dos casos cabe en una línea. La citación falsa del 31 de agosto se inventó un tribunal, y conmigo no coló. Estas peticiones se inventaron una fiscalía, con los números de protocolo de otra, y colaron porque venían del buzón correcto.)
Todo lo que el artículo atribuye a Revolut sale de sus declaraciones a TechCrunch y a El Mundo. Lo del Financial Times está citado a través de Euronews y The Irish Times, porque el original va tras muro de pago. Lo de las capturas sale de Il Post, y esas capturas las difundió una cuenta en contacto con los atacantes. Lo que dicen los atacantes está marcado siempre como suyo y ninguna de esas afirmaciones se ha podido contrastar.
Preguntas frecuentes
¿Qué ocurrió con Revolut en septiembre de 2026?
Revolut confirmó que un tercero no autorizado utilizó el dominio legítimo de correo electrónico de una agencia gubernamental para solicitar información de clientes, y que el banco la entregó. Afectó a 680 clientes. Según el aviso enviado a los afectados, los datos incluían fecha de nacimiento, direcciones, teléfono, copias de pasaportes o permisos de conducir y, según el caso, selfis de verificación, extractos e historiales de movimientos. El banco afirma que ni sus sistemas ni los fondos de los clientes se vieron afectados. La Fiscalía de Reggio Calabria investiga el uso de un buzón de correo certificado de la Prefectura de esa ciudad.
¿Qué es una petición oficial falsa de datos?
Es una solicitud de datos de clientes que se hace pasar por un requerimiento de la policía, una fiscalía u otro organismo público. Su variante más conocida y peligrosa es la petición de datos de emergencia (emergency data request), que en Estados Unidos permite obtener datos sin orden judicial cuando existe un riesgo inminente para la vida de alguien. Desde al menos 2021 hay delincuentes que las envían desde buzones robados de comisarías u organismos públicos; en 2022 se supo que Apple y Meta habían entregado datos así, y en noviembre de 2024 el FBI alertó de su aumento.
¿Por qué SPF, DKIM y DMARC no detectaron las peticiones fraudulentas?
Porque a ese nivel no había nada que detectar. En conjunto, esas comprobaciones permiten verificar que el mensaje está autorizado por un dominio alineado con el que aparece como remitente. Según lo publicado, las peticiones procedían de una cuenta o sistema de correo perteneciente al dominio legítimo del organismo, y por eso la autenticación podía ser válida: un mensaje enviado mediante una cuenta comprometida puede superar las mismas comprobaciones que uno legítimo. La autenticación acredita el origen, no la autoridad de quien escribe para pedir lo que pide.
¿Cómo puede una empresa verificar un requerimiento oficial recibido por correo?
El FBI recomienda, ante la duda, contactar con el remitente y con la autoridad de la que dice proceder, y comprobar que las referencias legales correspondan a la jurisdicción que se invoca. Ese contacto debe hacerse por un canal independiente, con un teléfono o una dirección obtenidos del directorio oficial del organismo y nunca con los que figuran en el propio mensaje. Ayuda además valorar el historial del solicitante y no solo su dominio, vigilar el volumen de peticiones que llegan desde una misma dirección y entregar únicamente los datos concretos solicitados.
¿Qué debe hacer un cliente cuyos datos se han filtrado en un incidente así?
Desconfiar de cualquier llamada, mensaje o correo que utilice datos reales para parecer legítimo, porque esos datos son precisamente los filtrados. Ante un contacto supuestamente del banco, conviene colgar y comunicarse por la aplicación oficial o por un teléfono buscado de forma independiente. Ninguna petición de mover dinero a una supuesta cuenta segura es legítima. Tampoco se debe negociar con quien reclame un pago por los datos: se guardan los mensajes y se denuncia. En España, INCIBE atiende gratuitamente en el 017.
El blog, día a día
¿Te ha resultado útil o quieres comentar algo?
Hablemos →