Google fue suplantado mediante un ataque de replay de DKIM: análisis técnico

• Un caso en el que un atacante logró enviar con éxito un correo de phishing haciéndose pasar por Google mediante un ataque de replay de DKIM
• La dirección del remitente y los resultados de autenticación parecían los de un correo oficial real de Google, por lo que el usuario podía caer fácilmente en el engaño
• El atacante usó Google Sites para crear un sitio que aparentaba ser una página oficial de soporte y así aumentar la credibilidad
• Aunque SPF, DMARC y DKIM pasan la autenticación, la clave del ataque es el reenvío del correo sin modificar el cuerpo ni los encabezados firmados
• Como medidas de mitigación, se recomienda la rotación periódica de claves DKIM y reforzar la concientización de los usuarios

---

Inicio: un correo de phishing que parecía legítimo

• Por la mañana, un conocido recibió un correo sobre una solicitud de documentos legales relacionada con su cuenta de Google
• El remitente aparecía como la dirección oficial no-reply de Google, y el mensaje estaba redactado con mucho cuidado, sin errores tipográficos, enlaces sospechosos ni dominios anómalos
• Al destinatario le resultó difícil determinar si era auténtico, así que consultó con un especialista

Análisis detallado del correo

• Se investigaron los encabezados del correo y la vista previa de los enlaces en un entorno sandbox
• La dirección del remitente, el branding, la calidad del lenguaje y la ausencia de archivos adjuntos parecían normales
• Sin embargo, al revisar los resultados de autenticación SPF, DKIM y DMARC, se detectaron señales anómalas

Precauciones ante correos de phishing

• Se enfatiza no hacer clic en enlaces ni ejecutar instrucciones contenidas en correos sospechosos
• Si se responde al correo o se abre un archivo adjunto fuera de un entorno sandbox, existe riesgo de filtración de información, compromiso del correo corporativo, robo de cuentas y compromiso de la red
• En caso de sospecha, es necesario reportarlo de inmediato al equipo de seguridad y solicitar un análisis especializado

Flujo del ataque: uso de Google Sites

• El enlace del correo malicioso dirige directamente a Google Sites si el usuario ya tiene sesión iniciada
• Google Sites es un subdominio oficial de google.com que cualquiera puede crear gratis, pero su contenido no es necesariamente una página oficial de soporte
• Se usa para distintos fines, como wikis internas, dashboards de proyectos, documentación y sitios de eventos, pero también puede ser abusado como en este ataque

Cuando la confianza en la infraestructura se vuelve una amenaza

• Google Sites (lanzado en 2008) se integra con Google Workspace y ofrece creación y publicación sencilla, SSL y confianza de marca
• Esto permite a un atacante montar fácilmente y a bajo costo un sitio de phishing con apariencia oficial, sin necesidad de dominio ni hosting propios

Detalle del proceso del ataque de replay de DKIM

Paso 1: obtener un correo real de Google

• El atacante recibe un correo legítimo desde la cuenta [e-mail] y guarda el cuerpo original y los encabezados

Paso 2: preparar el reenvío del mensaje firmado

• DKIM aplica una firma digital sobre parte del cuerpo del mensaje y determinados encabezados
• Si se conservan el mensaje original y el encabezado de firma, la autenticación puede seguir siendo válida al reenviarlo

Paso 3: reenvío mediante Outlook

• El atacante envía el correo del ataque desde una cuenta de Outlook
• Aunque cambian algunos datos del origen y la ruta, la firma DKIM sigue siendo válida

Paso 4: uso del servidor relay SMTP Jellyfish

• Microsoft enruta el correo a través del sistema Jellyfish (para añadir distancia con respecto al servidor de origen)

Paso 5: envío a través de Namecheap PrivateEmail

• El servicio PrivateEmail de Namecheap recibe el correo y actúa como relay adicional
• En este proceso se agrega una nueva firma DKIM, pero no cumple con el criterio de DMARC
• Aun así, la firma DKIM original de Google coincide y es válida, por lo que la verificación DMARC pasa

Paso 6: entrega final en Gmail

• Finalmente, el destinatario recibe un correo que aparenta ser un mensaje oficial de Google
• El resultado es que SPF, DKIM y DMARC pasan la autenticación

Por qué es peligroso el correo falso de citación

• Un correo de “citación” genera miedo, urgencia y confusión en el destinatario
• Además, difiere de las formas reales de emisión o entrega de una citación, que normalmente se realizan por medios físicos o canales oficiales
• Este tipo de phishing es muy convincente, por lo que incluso usuarios con experiencia técnica pueden caer en la trampa

Conclusión y respuesta recomendada

• Cuanto más inesperado y urgente parezca un correo, más importante es verificar su autenticidad y pedir intervención especializada
• No se debe hacer clic en enlaces, responder ni ejecutar nada
• Se recomienda solicitar análisis al equipo de seguridad o a personal especializado en investigación

Adicional: proceso de reproducción del ataque

• El atacante registra un dominio en Namecheap y obtiene el servicio gratuito de PrivateEmail
• Luego se registra en Google Workspace (prueba gratuita), verifica el dominio y crea una aplicación maliciosa de Google OAuth
• En el campo App Name puede configurar el nombre que quiera (por ejemplo, Google Support)
• La alerta de cuenta enviada por Google llega a PrivateEmail, donde es posible manipular la dirección del remitente y la dirección de respuesta
• Finalmente, el correo del ataque se entrega al objetivo deseado

Preguntas frecuentes

• Ataque de replay de DKIM: el atacante captura un correo legítimo con una firma DKIM válida y luego lo reenvía con el mismo contenido y encabezados
• Límites de bloqueo de SPF y DMARC: SPF solo valida el servidor o la IP de envío, y en un ataque de replay DMARC también puede pasar si DKIM mantiene alineación
• Por qué es difícil de detectar: sin modificar el cuerpo ni los encabezados, es difícil identificarlo únicamente mediante la verificación de firmas
• Bypass con Google OAuth en el ataque: el atacante crea una app maliciosa de OAuth y reenvía una notificación oficial enviada por Google para ganar credibilidad
• Medidas de mitigación: es importante la rotación periódica de claves DKIM (cada 30 días o menos) y la capacitación de usuarios (cuidado con enlaces sospechosos, revisión de URL y cultura de reporte)

[GN⁺]

Comentarios en Hacker News

• Estoy trabajando en una solución para este problema (junto con coautores ex-Google y ex-Yahoo; es un proyecto serio y confiable)
  Revisen el documento Draft: DKIM2 Motivation
  Este enfoque no impide que se envíe desde Google texto ingresado por el usuario, pero sí evita que ese mensaje sea reenviado sin la intención real de Google
  Porque los campos SMTP FROM/TO quedan protegidos
  El borrador de motivación no incluye detalles técnicos; pueden ver el borrador en los documentos relacionados
  Consulten el enlace DKIM Working Group Documents

  • Como el sitio de Datatracker no muestra bien los documentos candidatos, dejo los enlaces directos
    Draft: dkim2-dns
    Draft: dkim2-header
    Draft: dkim2-modification-algebra
    Draft: dkim2-bounce-processing
    Draft: dkim2-message-examples

  • Me pregunto cómo funcionaría esto con listas o grupos de correo
    Por ejemplo, es común reenviar automáticamente al equipo correos externos enviados a [e-mail]
    Me pregunto si en el sistema del destinatario final habría que configurar confianza en el reenviador de la lista de correo, o si tendría que haber lógica interna para rastrear a qué lista pertenece
    Debería poder verificarse que accounts-payable, el destinatario original, es un destinatario válido

• De hecho, después de ser condenado por cargos de hackeo informático, el FBI incautó todos los datos de mi cuenta de Google
  Se llevaron la información una vez en 2016 y otra vez en 2018
  En la práctica no lo hacen como en este artículo
  Según mi experiencia, envían un correo a un departamento específico de Google y llevan la comunicación por canales oficiales
  Las agencias de investigación actúan con mucho cuidado para que la persona investigada no se dé cuenta lo antes posible

  • Para quienes tengan curiosidad, lo explico con más detalle
    Recibí un correo de [e-mail] con este contenido:

Dear Google user,

Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.

For more information about how Google handles legal process, view our transparency report at http://google.com/transparencyreport/userdatarequests/….

Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.

Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.

Regards, 
Legal Investigations Support
Google LLC

En una citación de gran jurado federal (Federal Grand Jury subpoena), por lo general se pide una notificación diferida de 1 a 2 años para que el proveedor de servicios (como Google) no pueda avisarte
La citación solo entrega registros generales (información de facturación, historial de inicio de sesión, etc.), no contenido (como correos electrónicos)
Para los datos reales, como los correos, hace falta una orden de cateo aparte, y Google normalmente no notifica por separado que esa orden fue ejecutada

• Es viernes, pero este comentario me despertó un 10%
  Me da curiosidad conocer la historia completa

• Interesante
  Me pregunto si esta solicitud queda registrada o etiquetada en el archivo completo de datos de mi cuenta cuando pido “todos los datos relacionados con mi cuenta” bajo el GDPR o algo por el estilo

• Supongo que la orden de cateo habrá sido por una violación de la CFAA, fraude electrónico (wire fraud) o conspiración, algo así
  Espero que hayas conseguido un buen abogado y que todo haya salido bien

• Hace poco recibí un ataque parecido
  El atacante envía un correo desde [e-mail] (no exactamente desde gmail.com), luego reenvía a [e-mail] el mensaje de rebote por error de entrega recibido desde los servidores de correo de Google, y al final le inserta un mensaje de spam
  Así logra pasar todas las verificaciones de seguridad
  Es realmente raro que combine un error de postmaster con una campaña de phishing
  Alguien no técnico podría caer fácilmente
  En mi caso, el contenido del phishing decía que me había ganado herramientas de construcción

  • Yo también he estado recibiendo correos así desde hace semanas
    Ya me da la impresión de que Google se rindió con el correo

• Me sentí muy confundido al leer el artículo
  Describe con bastante detalle como si el atacante hubiera manipulado el cuerpo del correo para insertar un enlace de phishing, pero en realidad no había evidencia de eso ni tal manipulación
  La firma DKIM incluye un hash del cuerpo
  Técnicamente se puede limitar el alcance del hash usando el campo I=, pero confirmé que Google no usa esa opción en correos cortos (lo verifiqué revisando directamente un correo de [e-mail])
  Es decir, para que pasen las verificaciones de DKIM y DMARC, el cuerpo no debe modificarse, así que el enlace de phishing también era contenido que Google envió originalmente (aunque probablemente para otro destinatario previsto)
  Por lo tanto, en realidad el punto clave es más bien “un correo alarmante reenviado por error”, y el título “DKIM replay attack” puede sonar mucho más grave para la gente no familiarizada con este tema
  Edición: vi “The Takeaway?” en el artículo y pensé que ahí terminaba, pero en la actualización de abajo explican que el enlace en realidad estaba insertado en el nombre de una app de Google OAuth y quedó incluido dentro de la plantilla de correo de Google
  Esa es la parte más importante del ataque, pero la estructura del artículo es tan mala que queda enterrada y da la impresión equivocada de que se puede enviar contenido arbitrario
  Además: otro comentario señala que la captura del correo fue recortada a la mitad para que no se viera la parte fija de la plantilla de Google
  El ataque en sí es mucho más improvisado de lo que parecía

  • Parece que este artículo fue escrito de una forma intencionalmente engañosa
    Hacen parecer que la parte mostrada en la captura es todo el correo, pero en realidad seguramente seguía texto que habría dado motivos para sospechar

  • Según entendí, DKIM se valida porque el atacante simplemente está reenviando tal cual un correo que realmente recibió desde Google
    El vector real del ataque es que Google permite que el atacante provoque el envío de un correo con cierto texto bajo su control

• Personalmente, creo que la verdadera vulnerabilidad aquí es que se puede poner una URL en el nombre de una app de Google OAuth, y eso se renderiza sin restricciones en correos no-reply desde el dominio raíz de Google apuntando a una dirección arbitraria
  Aunque el enlace no sea clicable, si el texto alrededor suena lo bastante amenazante, es muy probable que la víctima entre por su cuenta
  El hecho de que puedan encadenarse varios servicios de reenvío que preservan la integridad de DKIM es un punto adicional interesante a nivel educativo
  Deberían bloquear por completo que el nombre de una app OAuth contenga URLs, especialmente URLs con google.com

• ¡Por fin!
  Hace unos meses recibí un correo casi idéntico (dirigido a administradores de Google Domains)
  Definitivamente ese correo también me dio escalofríos
  Yo también esperé en vez de hacer clic impulsivamente, y traté de buscar otras referencias sobre esta estafa
  Lo raro era que todas las direcciones de correo estaban ocultas y el patrón de enmascaramiento no coincidía con los correos que administro
  El correo en sí era legit, y al buscar en Google confirmé que el texto del cuerpo coincidía
  En mi caso era un correo sobre la cuenta de una persona fallecida, pero no correspondía con la realidad
  Aun así, de verdad llegué a sospechar casi al 100% que alguien había convencido a Google de que yo estaba muerto para intentar apoderarse de toda mi cuenta de Google
  Fue una experiencia aterradora

• Paso 3: el atacante envía el correo desde Outlook
  Hasta donde sé, es imposible falsificar la ruta en los encabezados Received:
  Cada servidor sigue agregando su propia información de ruta
  Por eso siempre reviso esos datos para verificar el origen de un correo
  Un correo de Google no debería pasar por servidores de Microsoft

  • El encabezado del último servidor “de confianza” no se puede falsificar; el resto de la ruta sí puede falsificarse

  • Me pregunto si revisan manualmente los encabezados de todos los correos
    O si usan alguna herramienta que los marque o los visualice

• Es una situación realmente preocupante
  Imaginen tener que explicarle a un familiar la lección que deja este artículo
  Da tristeza pensar que hay que decirles que siempre desconfíen incluso si el correo viene de un dominio de confianza y pasa dkim/dmarc/spf en ese orden
  Pero este ataque tiene bastantes límites en lo que realmente puede hacer
  Por ejemplo, no permite falsificar mensajes desde la cuenta de Gmail de otra persona
  “Cuando un mensaje se reenvía, la firma DKIM se conserva mientras no cambien el cuerpo ni los encabezados firmados”
  Lo sorprendente es que el encabezado To: no esté incluido en lo firmado por DKIM
  Creo que habría que cambiar la forma de firmar, o que los clientes de correo agreguen una advertencia cuando el correo sea válido pero el To haya cambiado

  • Imaginen explicarle esta lección a un familiar: que siempre desconfíe
    Y encima primero hay que explicar qué son dkim/dmarc/spf
    En realidad, estas tecnologías son de backend y el usuario no debería ni tener que conocerlas
    Este ataque no da tanto miedo como parece
    El artículo está algo exagerado porque intenta vender un producto
    Que el encabezado To: no esté en la firma tampoco significa mucho
    En la práctica, el To de un correo no necesariamente indica al destinatario final

  • Esa actitud de desconfiar siempre del correo ha sido el estado por defecto desde hace mucho tiempo
    Lo mejor es no confiar jamás en el campo From

  • Dijiste que te sorprendía que To: no estuviera incluido en DKIM, pero sí lo está
    Por eso tuvieron que conservar el valor original de To:
    La captura en la sección de reproducción muestra la dirección original en To:
    Eso no significa que el mensaje se haya entregado a esa dirección
    En esencia, un correo puede entregarse a cualquier dirección con cualquier valor en To:

  • Mi recomendación básica es que, si cualquier correo te pide realizar una acción, vayas directamente al sitio web correspondiente
    No hagas clic en ningún enlace
    Es menos cómodo, pero al final te resuelve el problema
    Especialmente en bancos o sistemas importantes, esa incomodidad vale completamente la pena

  • En mi trabajo, este tipo de amenazas ya está totalmente incorporado a la política
    En internet, desconfiar de todo es una buena práctica
    Muchos pequeños negocios y freelancers todavía no usan MFA, y aun cuando lo usan, caen fácilmente en robo de tokens
    Cuando comprometen esas cuentas, empiezan a llegar correos maliciosos que de verdad parecen enviados por un usuario interno
    Desde la perspectiva del usuario, se ven totalmente legit
    Por eso siempre hay que tratar el correo con sospecha

• El autor dice:
  “Here is the URL from that email [...] https://sites.google.com[...]”
  Ese enlace es justamente la primera señal de alerta
  Creo que el autor debió haber puesto ese punto desde el principio y no tres párrafos después

  • No todo el mundo conoce todos los subdominios de google.com
    El verdadero problema, además del tema de campos válidos en SSO, es que Google sirve contenido de usuarios desde subdominios de su dominio principal
    Otros servicios como Drive también pueden hacerlo

  • Puede ser una señal de alerta para ti, pero quizá no para nuestros padres

• En general, creo que este caso muestra lo frágil que sigue siendo la seguridad del correo electrónico
  En este foro hay mucha gente inteligente, así que uno pensaría que podríamos proponer una alternativa que arregle esto de una vez
  También creo que Google debería servir estos sitios en un dominio separado, no desde el dominio principal, algo como hostedbygoogle.com
  Me pregunto por qué no lo separaron desde hace tiempo

  • Siendo realistas, todas las alternativas viables terminan siendo sistemas donde todo el control queda en manos de una sola empresa
    Eso hace que se pierda el principal valor que le queda al correo: ser un sistema que no está completamente controlado por nadie
    Los problemas técnicos se pueden resolver de sobra, pero los problemas humanos y de intereses son mucho más difíciles
    Quienes tienen los recursos para resolverlo casi nunca tienen incentivos para construir una plataforma totalmente abierta
    A menos que se queden con todo el dinero y el control, no van a hacer ese esfuerzo
    Y por otro lado, no todo el mundo quiere entregar todo el control a una sola compañía
    Ese es justamente el problema: no es técnico, es de negocio
    (Es exactamente la misma razón por la que en el metaverso es prácticamente imposible que todos los servicios compartan avatares y objetos
    No es tanto que sea técnicamente imposible, sino que los dueños de esos derechos jamás lo permitirían)

  • ¡Anunciado Shadowfax, la nueva startup en la que invirtió Thiel!
    Nuestro servicio monopólico seguro y centralizado viene con una capa impulsada por IA y blockchain, y está listo para reemplazar el sistema anticuado del correo electrónico
    Ya conseguimos contratos con el Departamento de Defensa de EE. UU. y se perfila como el estándar para todas las comunicaciones federales internas y externas para 2027