Ir al contenido
Introducción: El ataque que pasó los filtros de Google
Durante abril de 2025, el mundo de la ciberseguridad fue sacudido por un ataque de phishing que logró lo impensable: engañar a los filtros de seguridad de Gmail y burlar el sistema de autenticación DKIM de Google. Lo más alarmante es que los correos maliciosos llegaban desde direcciones aparentemente legítimas, sin alertas ni señales de peligro. La técnica utilizada: un DKIM Replay Attack, explotando la infraestructura de Google para enviar correos firmados válidamente, pero con fines maliciosos.
Este incidente, ampliamente reportado por medios técnicos y generalistas, como EasyDMARC, Newsweek y Legal.io, pone en duda la robustez de los estándares actuales de autenticación de correo y plantea una pregunta clave: ¿podemos confiar ciegamente en una firma DKIM válida?
A continuación, analizaremos en profundidad cómo ocurrió este ataque, cómo fue posible que se ejecutara sin ser detectado, y lo más importante: qué podemos hacer para protegernos, tanto a nivel personal como empresarial, especialmente si gestionas dominios desde un proveedor de hosting como Bitralix.
¿Qué es DKIM y por qué importa tanto en la seguridad del correo?
DKIM (DomainKeys Identified Mail) es uno de los pilares actuales para verificar la legitimidad de un correo electrónico. Se basa en un sistema de firmas criptográficas que permite al servidor receptor validar que el mensaje realmente proviene del dominio que dice representarlo y que su contenido no ha sido alterado en tránsito.
Cuando un correo es enviado, el servidor del remitente firma ciertas partes del mensaje (como el cuerpo, el asunto y los encabezados) con una clave privada. El servidor receptor utiliza la clave pública del dominio (publicada en el DNS) para verificar la firma. Si todo encaja, el correo se considera auténtico.
El problema radica en lo que DKIM no valida:
- No valida el envelope del correo (quién lo reenvía).
- No verifica quién lo reenvía después de la firma.
- Y lo más grave: no considera el contexto, solo que la firma era válida al momento de enviarse.
Esto hace que DKIM, aunque útil, no sea infalible. Y el ataque reciente lo ha demostrado con creces: los atacantes reutilizaron un correo legítimo generado por Google, lo reenviaron, y la firma seguía siendo válida, haciendo que Gmail lo tratara como un mensaje legítimo de Google.
Cómo se explotó la vulnerabilidad de DKIM en Google
¿Qué es un ataque DKIM Replay?
Un DKIM Replay Attack consiste en reutilizar (o reenviar) un correo previamente firmado por un servidor legítimo, sin alterar los elementos firmados, para que pase los controles de autenticación aunque el propósito ya no sea el original. En este caso, los atacantes se valieron de un correo de alerta legítimo generado por Google, y lo reenviaron a sus víctimas, sabiendo que DKIM lo seguiría validando como auténtico.
Lo más preocupante es que la firma DKIM solo se asegura de que el contenido no fue modificado, pero no de quién está reenviando el correo ni de si es parte de un contexto legítimo.
Google firmando correos maliciosos sin saberlo
Según la cronología expuesta por EasyDMARC, el ataque comenzó al menos desde el 10 de abril de 2025, aunque fue reportado oficialmente el 15. Los atacantes registraron un dominio, crearon una cuenta de Google como «[email protected]», y configuraron una aplicación OAuth con un nombre extenso que contenía el mensaje de phishing completo seguido de «Google Legal Support».
Al autorizar la app, Google generó un correo de alerta de seguridad legítimo enviado a esa cuenta. Este correo, generado por sus propios servidores, contenía una firma DKIM completamente válida. Luego, simplemente reenviaron ese mensaje a sus víctimas.
El rol de Google Sites y OAuth en el engaño
Un abuso brillante del sistema
La creatividad de los atacantes fue notable. Utilizaron una antigua funcionalidad de Google Sites para hospedar páginas web visualmente idénticas al centro de soporte de Google. Así, al hacer clic en los enlaces incluidos en el correo de alerta (legítimo), el usuario era redirigido a una página clonada, construida para recopilar sus credenciales.
Este paso fue crucial para aumentar la credibilidad del ataque: todo parecía proceder de Google, y la infraestructura usada era… de Google.
La firma DKIM como carta de confianza
En este punto es donde la estrategia se vuelve aún más alarmante. La firma DKIM actuó como un aval de autenticidad, cuando en realidad estaba firmando el arma del engaño. Como explicó el propio Nick Johnson, desarrollador principal de ENS y víctima directa, el correo se veía idéntico a los avisos de seguridad reales de Google.
"Since Google generated the email, it's signed with a valid DKIM key and passes all the checks. It shows up as a legitimate message — even in the same thread as legit security alerts." — Nick Johnson
Fuente: X
Caso real: Nick Johnson y el correo que parecía 100% legítimo
La historia de Nick Johnson es clave para entender el alcance del problema. Recibió un correo que, a primera vista, parecía enviado desde la propia Google. Gmail no lo marcó como sospechoso, ni lo envió a spam, y lo clasificó como mensaje de seguridad.
Dentro del correo, un enlace llevaba a una página alojada en Google Sites, imitando el portal oficial de soporte. Al interactuar con ella, el flujo llevaba a una página que replicaba exactamente la pantalla de inicio de sesión de Google, incluyendo tipografías, botones, logos y diseño visual.
Nick, con su experiencia como desarrollador en Web3, identificó la anomalía al inspeccionar la firma DKIM del mensaje. Confirmó que era válida, y que efectivamente provenía de Google. No obstante, el contenido había sido diseñado con fines maliciosos.
Lo más desconcertante: no hubo señales visibles de que el correo era peligroso, y todo pasó por los filtros como si fuera una alerta real de seguridad de Google.
La respuesta de Google: ¿Negligencia o error de criterio?
El 15 de abril, Nick Johnson reportó el incidente a Google. Para su sorpresa, la respuesta inicial fue que “el sistema está funcionando como se espera”. Es decir, consideraban que no era un fallo, ya que DKIM se validó correctamente.
Esto generó gran controversia en redes sociales y foros técnicos, hasta que 24 horas más tarde, Google reconsideró su postura. Reabrieron el reporte, reconocieron que había riesgo real y comenzaron a tomar acciones correctivas.
Este cambio de criterio revela algo preocupante: incluso en una de las infraestructuras más avanzadas del mundo, los límites entre seguridad y funcionalidad siguen difusos.
Consecuencias para la ciberseguridad: lecciones que aprender
Este ataque marca un antes y un después en cómo entendemos la seguridad del correo. Demuestra que los estándares actuales como DKIM y SPF, aunque necesarios, no son suficientes para detener ataques avanzados si los atacantes se valen de los propios sistemas legítimos para construir el engaño.
Afecta no solo a los usuarios particulares, sino especialmente a:
- Administradores de dominios corporativos
- Equipos de soporte técnico
- Servicios que dependen de alertas vía correo
El ataque también pone en evidencia que la confianza ciega en la autenticación técnica sin verificación contextual puede resultar peligrosa.
Cómo protegerte de correos firmados maliciosamente
Aquí tienes algunas recomendaciones prácticas:
- Verifica manualmente enlaces antes de hacer clic, incluso si el correo parece venir de una fuente confiable.
- Inspecciona la cabecera completa del correo para comprobar rutas de envío y remitentes intermedios.
- Utiliza herramientas como MXToolbox, GSuite Toolbox o DKIMValidator para analizar firmas y encabezados.
- Considera herramientas avanzadas de detección como DMARC con políticas estrictas y servicios antiphishing externos.
Y lo más importante: si gestionas un dominio, elige un proveedor de hosting que te permita configurar estas políticas de forma segura y personalizada.
Preguntas frecuentes
¿Qué es un ataque DKIM Replay?
Es un tipo de ataque en el que se reutiliza un mensaje previamente firmado (con DKIM válido) para enviarlo nuevamente con fines maliciosos, aprovechando que la firma sigue siendo válida.
¿Por qué Gmail no detectó el ataque como phishing?
Porque el correo fue originalmente firmado por los servidores de Google, y no hubo modificaciones técnicas en los elementos firmados.
¿Google solucionó la vulnerabilidad?
Sí, tras una respuesta inicial errónea, Google rectificó y tomó medidas para mitigar el exploit.
¿Qué medidas puedo tomar si tengo un dominio personalizado?
Implementar DMARC, SPF y DKIM correctamente. Además, contar con monitoreo de actividad sospechosa en tus correos.
¿Bitralix puede ayudarme con esto?
Sí, en Bitralix ofrecemos configuraciones avanzadas de seguridad en hosting, incluyendo herramientas para proteger tus correos y dominios contra estos tipos de ataques.
Conclusión Final: Más allá de DKIM, confianza en peligro
Este ataque nos recuerda que la ciberseguridad no depende únicamente de tecnologías como DKIM o SPF, sino del uso inteligente y vigilante de estas herramientas. El fallo no fue solo técnico, fue de confianza ciega en los sistemas.
Como administradores de dominios, como usuarios, como desarrolladores… este ataque demuestra que incluso las mejores infraestructuras pueden ser usadas en tu contra si no estás preparado.
¿Gestionas un dominio corporativo o personal? No dejes tu seguridad al azar.
🔐 En Bitralix te ayudamos a blindar tu hosting y correo con:
- Configuración avanzada de SPF, DKIM y DMARC
- Soporte personalizado para prevenir phishing y spoofing
- Infraestructura segura y optimizada
👉 Protege tu dominio hoy con Bitralix. No esperes al siguiente ataque.
