Cómo evitar el spam y phishing proveniente de Google Cloud en tu correo o servidor

En todos estos años de sysadmin no había visto cosa semejante. Y no son pocos. En las últimas horas un cliente se ha quejado, y no sin razón, de una barbaridad de mensajes de spam que entraban cada ciertos minutos directamente en su bandeja principal, saltándose todo filtro. Bueno, al principio pensé que no sería tan grave, tal vez alguna red pequeña zombie que aún no está en listas negras en los servicios habituales de consulta. Pues sí, sí que era grave. Por algún motivo que aún no comprendo, su dirección de correo es objeto de un bombardeo masivo de phishing, con links falsos de dominios aún más falsos.

Todo esto suele ser controlable. Igual solo hace falta un baneo temporal de un rango /24, igual un ajuste de puntuación en SpamAssassin. Hasta que miro el origen de todas esas IPs que salen en las cabeceras de correo. Por todos los santos de internet. Son de Google. Todas y cada una de las IPs son de Google Cloud. Ahora sí que empiezo a preocuparme. ¿Cómo se puede evitar spam que llega VERIFICADO desde Google mismo? Pues la cosa está difícil, porque... ¡demonios, es Google!

Las denuncias se las pasan por el forro

Me pareció tan extraño que al instante empecé a buscar información o si había casos similares. Topándome con un formulario de Google Developers para denunciar, me dije que no perdía nada por intentarlo. A lo mejor se lo toman en serio, no en vano son ya unas cuantas IPs desperdigadas por sus sistemas haciendo el mal. Así que envié nada menos que cuatro denuncias. Mientras redacto este artículo bien podría enviar ahora mismo otras más de 40, con una lista de IPs diferentes que no deja de crecer, desde varias localizaciones (Estados Unidos, Asia, etc.) que utilizan los servicios de Google Cloud. Son IPs públicamente conocidas. Esto que me está sucediendo a mí tiene que estar forzosamente sucediendo a más administradores, es imposible que sea un caso aislado. La gran Google dejando que una red de bots descontrolados envíen spam y phishing a diestro y siniestro. Menuda cagada tamaño Silicon Valley. Una cosa absolutamente demencial.

Formulario de denuncia de Google Cloud ─aviso, no contestan─

Obviamente si esperas a que contesten a las denuncias, ya puedes esperar sentado hasta el final de los tiempos. Por lo que se ve ya en casos anteriores de estas "oleadas" de spam, nunca pasa nada y no hacen nada. ¿Por qué? Es incomprensible. Va en contra de todas sus leyes y reglas. Tanto cuidar el spam en su servicio de gmail y lo están enviando ELLOS a través de su nube, sin monitorizar qué sale desde sus instancias de máquinas virtuales. Es a todas luces increíble. Ni un solo filtro, ni una sola medida.

Por qué no funcionan los filtros y qué está pasando

Lo primero que comproblé: las puntuaciones de spam eran bajísimas. Al ser rangos validados por los mismos sistemas de Google, pasan con facilidad toda verificación importante como DKIM o SPF. Añadiendo que muchísimos sistemas de control y monitorización los habrán colocado, por motivos obvios en su día, en listas blancas o mitigadas. ¿Cómo va a salir un spam con enlaces para robarte credenciales directamente de los servidores de Google? Eso es imposible, ¿verdad? Pues no, no es imposible.

Ya desde hace meses se han dado casos de intento de suplantación de identidad utilizando servidores de Google Cloud y Google Drive. Enlaces contaminados que apuntan a archivos en su nube, links intermedios con el dominio googleusercontent.com... No es un caso aislado. Tarde o temprano, si tienes una cuenta de correo profesional y algo extendida por la red te va a tocar. Y cuando te toque va a ser un bombardeo masivo.

Vale, está la cosa canija. Qué se puede hacer contra el spam de Google Cloud

Hay tres opciones: no hacer nada, bloquear IPs a nivel cortafuegos / iptables o ajustar los filtros de spam para intentar frenar a estos bots pesadísimos y descontrolados.

A) No hacer nada

Lo primero que uno piensa cuando se enfrenta a Google. ¿Cómo voy a bloquear IPs de Google? ¿Y si son de sus rastreadores? ¿O de Gmail? Te metes en un jardín bien complicado. Lo ideal es mantener el equilibro entre garantizar la seguridad de tus servidores y clientes y no pegarte un tiro en el pie pasándote de largo. Y claro, ante la duda, me creo perfectamente que muchos ni siquiera se atreverán a poner en cuestión un bloqueo masivo a las IPs que vienen de Google. Tal vez porque algunas sí que tengan servicios legítimos en esos rangos. Servicios necesarios para, a saber, aplicaciones, software de terceros, envío de información importante... En realidad sería tan bruto como bloquear los sistemas de AWS en Amazon, teniendo en cuenta la salvaje cantidad de sitios webs y empresas que los usan. Pero bueno, uno podría llegar a pensar que Google tarde o temprano hará algo con tanto spam. No sé qué decirte, pero lo dudo. Además, que si no quieres seguir recibiendo quejas de tus clientes, toca probar la siguiente opción.

B) La opción radical: bloquear en cortafuegos rangos completos

Cuando ya te has cansado de bloquear IPs individuales que no dejan de cambiar con cada envío, la opción radical que he usado anteriormente ─y sigo usando a menudo con spammers─ es bloquear el rango entero, del tipo /24, /16, o del que corresponda. Es matar moscas a cañonazos, no lo niego. Puede que esa IP tras destruirse el servidor/instancia o lo que sea, pase a un pool y se asigne a otro servicio que sí sea legal. Hay muchos factores. Pero he aquí mi razonamiento para suponer que no va a hacer daño a otros servicios importantes.

Google tiene un montón de IPs: digamos que más de cientos de miles, asociadas o no, a servidores activos o simplemente sin servicio, a la espera de uso. Ellos públicamente tienen dos archivos JSON con la lista de sus IPs propias y las de Cloud. Las propias son intocables, lógicamente: sus servicios, los spiders, todo está ahí. Las de Cloud son de servicios de usuarios y para las instancias. Si bloqueas rangos de esta último lista archivo, asumiría que no va a afectar para nada al resto de servicios. Todo esto lo digo desde mi opinión y por lo que he podido leer, que tampoco es que haya información extensa sobre el asunto.

Lista de rangos de Google Cloud

En el enlace anterior puedes comprobar si la IP que envía spam forma parte de su red, aunque cualquier servicio de whois (yo uso cleantalk.org), también te dirá cual es el origen real. Sí, bloquear rangos en iptables es medida radical. Pero dejan de entrar correos basura. Lo que no se sabe es si dejan de entrar otros correos que no lo sean. Y nunca lo sabremos. La otra cosa, además, es que tan pronto bloqueas un rango, sale otro en otra zona o continente o centro de datos. Es una auténtica plaga de spam. ¿Te imaginas estar día y noche pendiente de bloquear IPs? Pues yo no. Con unas horas ya tuve suficiente, así que vamos a la tercera opción.

C) Utilizar SpamAssassin o similar para filtrar el correo lo mejor posible

Una de las cosas irritantes es que estos mails parecen chungos desde el momento que se lee el asunto y los dominios raros que muestran. O sea, amigo, es spam sin dudas. No posible, no. SPAM del bueno. De ese que hasta tu madre si lo ve dice "uy, mejor no hacer clic en este enlace que me promete un regalo". De ese tipo. Pues a pesar de eso, pasan el filtro. No hay nadie que haya reportado las IPs a listas negras, todas verifican su "inocencia". Hay que joderse. Llevo dos días con esta pesadez y siguen entrando felices al inbox. En fin. Bueno, que después de bloquear medio internet con iptables, me pregunté si habría alguna manera de "filtrar" y "marcar" esos mensajes para al menos desviarlos a la carpeta JUNK.

Después de investigar un poquito pues sí, hay una manera rápida y eficaz. Todos estos correos aparecen en las cabeceras del archivo como recibidos desde IP XX.XX.XX.XX.bc.googleusercontent.com, tal cual. Así que es más que suficiente crear una nueva regla en SpamAssassin (local.cf) y mandarlos al limbo del correo basura con una buena puntuación.

# Nuevo filtro para Google Cloud 
header      FROM_GOOGLE_USERCONTENT  Received =~/googleusercontent\.com/i
describe    FROM_GOOGLE_USERCONTENT  Castigar el spam desde Google Cloud
score       FROM_GOOGLE_USERCONTENT  10.0

Hale, reiniciado el servicio spamd o Spamassassin y a disfrutar. Yo le puse 10 punticos para que no hubiera manera de esquivar el marcado de SPAM (5.0 suele ser el valor por defecto). Pero vamos, cada cual es libre de darle el score que quiera. Y ya con esto, entiendo que algún día dejará de llegar tanta basura desde Google. Pero mientras, que al menos no sature las bandejas de entrada. Y aquí estaremos observando lo que sucede con estas oleadas. Una última cosa, ¿para qué tienen IA monitorizando si no detecta estos ataques? Ejem.

Webs legítimas que disparan esta penalización

IKEA manda desde servidores de Google Cloud (lo siento, suecos, cambiad de proveedor o montad vuestros propios servidores, que pasta bien tenéis, ejem de nuevo). Seguro que hay más. Si detecto alguno importante, actualizaré este post para saber qué correos verídicos podrían acabar en la carpeta de spam por culpa de Google que, recordemos, no hace NADA por evitarlo.

Fuentes para ampliar información

Entrada (en inglés) sobre campañas de phishing desde Google Cloud en MalwareBytes

Noticia en FoxNews sobre lo mismo (en inglés

Entrada en Infobae sobre exactamente lo mismo

Otra noticia que tal

Resumiendo estas fuentes: sí, en enero de 2026 ya hubo una oleada de ataques para capturar credenciales de Microsoft 365 desde Google Cloud, emails válidos y verificados. Tremendo. A lo mejor no debería quejarme por un poco de spam simplón, ¿no?