Phishing desde los servidores de Google: SPF, DKIM y DMARC …

El investigador en seguridad Jameson Lopp reveló públicamente el 17 de mayo de 2026 una técnica de phishing que abusa de la propia solicitud de contacto de recuperación de cuenta de Google para enviar correos maliciosos directamente desde los servidores de Google. Como el mensaje procede realmente de la infraestructura de Google, toda comprobación en la que se apoyan Gmail, Outlook, Yahoo y el resto del sector — SPF, DKIM, DMARC — devuelve un resultado válido. Es el segundo caso documentado este mes tras la campaña AccountDumpling vía AppSheet que Guardio Labs vinculó a unos 30 000 robos de cuentas de Facebook Business. Dos vías de abuso distintas, la misma brecha estructural: la autenticación confirma que el remitente es Google, no puede confirmar qué hay dentro.

Cómo funciona el ataque por contacto de recuperación

El atacante inicia una solicitud de contacto de recuperación de cuenta de Google que nombra la dirección de la víctima. La canalización de recuperación de Google envía entonces un correo de notificación real desde sus propios servidores — dirigido a la víctima — explicando que alguien la ha nominado como contacto de recuperación. El atacante controla el campo libre «mensaje para el contacto» de esa solicitud y lo rellena con un bloque largo de espacios en blanco seguido de una falsa alerta de seguridad y un enlace de phishing. La víctima ve un correo de seguridad de Google de apariencia auténtica; al deslizarse más allá del contenido visible, aparece el cebo. (Fuente: Crypto Times, 18 de mayo de 2026.)

La formulación de Lopp en Twitter es directa: el ataque «abusa de un formulario real de solicitud de contacto de recuperación de Google y lo rellena con un mensaje muy largo que contiene un enlace de phishing. El mensaje verdadero se empuja al final, detrás de varias páginas de espacio en blanco». El enfoque «inversores cripto» del artículo original refleja el primer grupo de víctimas, pero el mecanismo es independiente del proveedor: cualquier dirección Gmail puede ser objetivo y la misma familia de técnicas aplica a otros grandes proveedores cuyas superficies de producto aceptan texto saliente generado por el usuario.

Por qué SPF, DKIM y DMARC no lo cazan

SPF, DKIM y DMARC verifican infraestructura, no intención. SPF pregunta si la IP de envío está autorizada para el dominio From:. DKIM firma criptográficamente el cuerpo del mensaje con la clave del dominio emisor. DMARC exige alineación entre el dominio autenticado y la cabecera From: visible. Cuando son los servidores de Google los que envían, las tres comprobaciones pasan por construcción: la IP es de Google, la firma es de Google, la alineación es exacta. Los protocolos se diseñaron para detener la suplantación; no se diseñaron para juzgar si el contenido que un tercero puede inyectar en un producto de Google es seguro. (Fuente: Field Effect — Valid, signed Google emails used in new sophisticated phishing campaign.)

La campaña AccountDumpling documentada por Malwarebytes Labs el 4 de mayo ilustra el mismo patrón desde otro ángulo: los correos de phishing llegaban «vía infraestructura legítima de Google, apareciendo como noreply@appsheet.com entregado a través de appsheet.bounces.google.com», lo que les permitía «pasar las comprobaciones técnicas habituales» y eludir filtros antispam guiados por la autenticación. (Fuente: Malwarebytes Labs, 4 de mayo de 2026.) Guardio Labs contabilizó unos 30 000 comprometidos en cuentas de Facebook Business de Estados Unidos, Italia, Canadá, Filipinas, India, España, Australia, Reino Unido, Brasil y México antes de la divulgación. (Fuente: The Hacker News, mayo de 2026.) La revelación del 17 de mayo no es un caso aislado — es el segundo episodio de este mes en el que los atacantes industrializan una brecha estructural conocida.

Qué hacer esta semana

Añada una regla al triaje: trate «¿lo he iniciado yo?» como una pregunta distinta de «¿el remitente es auténtico?». La autenticación le dice que Google envió el correo — no le dice si usted lo pidió. Todo correo de seguridad de Google no solicitado debe verificarse abriendo accounts.google.com directamente en una pestaña nueva, no haciendo clic en un enlace del mensaje. Recorra todo el contenido antes de actuar: la variante por contacto de recuperación oculta su enlace de phishing muy por debajo del contenido visible. Para cuentas con dinero o activos del negocio, sustituya el 2FA por SMS o código de aplicación por una passkey o una llave de seguridad por hardware — las passkeys resisten el reenvío adversary-in-the-middle que rompe los códigos de un solo uso.

He probado esta mañana la ruta de verificación en mi propia cuenta de Gmail: abrir accounts.google.com → Seguridad → «Tus dispositivos y eventos de inicio de sesión» revela cada incorporación legítima de contacto de recuperación de la que Google me notificaría, sin necesidad de confiar en ningún enlace de un correo. La comprobación me llevó menos de treinta segundos y es la contramedida más fiable frente a esta clase de ataque — la página se sirve desde la auténtica superficie de autenticación de Google, no desde el contenido de ninguna bandeja. La solución estructural está en manos de las plataformas, no de los destinatarios. Google debe acotar el campo libre en las solicitudes de contacto de recuperación, y la superficie de envío saliente de AppSheet necesita un paso de clasificación de contenido antes de que los mensajes abandonen las IP de Google. Mientras tanto, los usuarios cargan el peso — y la respuesta no es desconfiar de SPF, DKIM y DMARC. Siguen bloqueando la suplantación y siguen siendo la higiene mínima que proveedores como GMX y web.de imponen ya en la entrada. La respuesta es leer los resultados de autenticación como una señal entre varias, junto a «¿lo esperaba?», «¿qué me pide hacer?» y «¿la acción encaja con el canal?». La misma lógica subyace en el zero-day de Exchange OWA parcheado en mayo y el RCE zero-click de Outlook — otra clase de bug, la misma enseñanza: en 2026, fiarse de un sobre con los colores de Gmail ya no es una postura defendible. Quien se pregunte si su buzón principal debe seguir alojado en los grandes proveedores puede revisitar el despliegue post-cuántico de Proton Mail o Thundermail recientemente lanzado por Mozilla en su próximo replanteamiento.

Alexis Dollé

Fundador y editor

Alexis Dollé, experto en email desde hace más de 10 años. Fundador de Email Tools. Pruebo personalmente cada cliente y utilidad de correo y luego escribo como se lo explicaría a un amigo — sin discurso de marketing, sin rankings patrocinados, cada afirmación con su fuente.

Preguntas frecuentes

¿Qué es la estafa de phishing por contacto de recuperación de Google revelada el 17 de mayo de 2026? — un correo de phishing enviado a través de la canalización de recuperación de Google

El investigador en seguridad Jameson Lopp describió públicamente una técnica que abusa de la función de solicitud de contacto de recuperación de cuenta de Google. El atacante inicia una solicitud de contacto de recuperación dirigida a la víctima y rellena el campo libre del formulario con un bloque largo de espacios en blanco seguido de un enlace de phishing. Google envía el correo resultante desde sus propios servidores: SPF es válido, la firma DKIM es válida y la alineación DMARC también. La víctima ve un correo de seguridad de Google de apariencia auténtica que se extiende hacia abajo hasta un cebo de phishing oculto.

¿Por qué SPF, DKIM y DMARC no bloquean estos correos? — verifican infraestructura, no contenido

SPF autoriza las direcciones IP de envío, DKIM firma el contenido del mensaje con la clave del dominio y DMARC exige alineación entre el dominio From: visible y el dominio autenticado. Los tres protocolos verifican la infraestructura del remitente, no su intención. Cuando un atacante hace que un sistema legítimo de Google envíe el correo, todas las comprobaciones pasan porque el correo realmente procede de Google. La capa de autenticación confirma «Google envió esto» — no puede juzgar si el contenido es benigno u hostil.

¿En qué se diferencia el ataque del 17 de mayo de la campaña AccountDumpling / Google AppSheet? — vía distinta, misma brecha

Vía de abuso distinta, la misma debilidad estructural. La operación AccountDumpling revelada por Guardio Labs a principios de mayo enrutaba el phishing a través de Google AppSheet — los correos partían de noreply@appsheet.com vía appsheet.bounces.google.com, suplantaban al soporte de Meta y recolectaban credenciales de cuentas de Facebook Business. Cerca de 30 000 cuentas fueron comprometidas. La técnica del 17 de mayo emplea la canalización de recuperación de cuenta de Google en lugar de AppSheet. Ambas eluden SPF, DKIM y DMARC por la misma razón: el correo procede realmente de Google.

¿Qué debe hacer un usuario final para detectar estos mensajes? — verifique la intención de forma independiente de la autenticación

Trate «¿quién lo envió?» como una pregunta distinta de «¿lo pedí yo?». Un correo de seguridad real de Google llega porque usted ha iniciado una acción — añadir un contacto de recuperación, conectarse desde un dispositivo nuevo, cambiar la contraseña. Si llega un correo con los colores de Google sin motivo, recorra todo el mensaje antes de hacer clic: la variante por contacto de recuperación esconde su enlace de phishing muy por debajo del contenido visible, tras espacios en blanco. En caso de duda, abra accounts.google.com directamente en una pestaña nueva y verifique allí el estado de seguridad, no a través de un enlace del correo.

¿Sirve la autenticación de dos factores frente a este ataque? — parcialmente, y solo con passkey o llave por hardware

Parcialmente. Una 2FA fuerte — idealmente una passkey o una llave de seguridad por hardware, no SMS — protege la mitad de la contraseña incluso si la introduce en una página de phishing. No impide que esa misma página pida también un código 2FA de un solo uso y lo retransmita en tiempo real. El equipo de Microsoft Defender ha documentado kits adversary-in-the-middle (AiTM) que reenvían códigos 2FA en segundos. Las passkeys resisten ese reenvío porque el reto criptográfico está vinculado al dominio legítimo — la página de phishing no puede satisfacerlo.

¿Google ha respondido a la divulgación sobre el contacto de recuperación? — sin aviso formal por ahora

En el momento de la divulgación pública del 17 de mayo de 2026, Google no había publicado un aviso formal específico para la variante por contacto de recuperación. Google sí reconoció la campaña AccountDumpling de AppSheet a principios de mayo y dio de baja los proyectos AppSheet abusivos identificados por Guardio Labs. El problema estructural — dominios e infraestructura de Google encaminando contenido controlado por el usuario — desborda a ambos incidentes y previsiblemente exigirá barreras a nivel de producto: en el campo libre del contacto de recuperación y en la superficie de envío saliente de AppSheet.

Fuentes