Las exclusiones de IP en Google Ads se pueden saltar. Lo hemos hecho.

Lo que los anunciantes de Google Ads deberían saber sobre los usos de IPs en las estrategias de fraude

Las exclusiones de IP en Google Ads se pueden saltar. Lo hemos hecho.

TL;DR — Hemos reproducido de principio a fin, sobre nuestra propia cuenta de Google Ads de Fáktica en marzo de 2026, una técnica que permite a un atacante seguir generando clics cobrados desde una IP que el anunciante ya ha añadido a la lista de exclusión de Google Ads. Además, ya estamos documentando en cuentas de clientes dos huellas consistentes con esta técnica: clics desde IPs excluidas que Google sigue cobrando, y un mismo GCLID reutilizado desde múltiples IPs y equipos. Hasta que Google lo resuelva desde su lado del servidor, las exclusiones de IP — y cualquier herramienta de terceros construida sobre ellas — ofrecen una protección mucho menor de la que los anunciantes suponen.

La técnica

Las listas de exclusión de IPs son una de las pocas herramientas nativas que tienen los anunciantes para bloquear fuentes fraudulentas conocidas. Ya en el mejor de los casos son una defensa débil — hemos escrito en otro post sobre cómo las IPs dinámicas y el CG-NAT erosionan su eficacia, y por qué solo las recomendamos como último recurso. Lo que documentamos aquí es diferente: una técnica que no solo erosiona la exclusión de IPs — la anula por completo. La hemos bautizado como IP Exclusion Bypass via Link Harvesting.

El ataque utiliza dos IPs con roles distintos:

Una IP expuesta — visible para el anunciante, en la lista de exclusión, la que hace el trabajo sucio.
Una IP oculta — invisible para el anunciante, limpia, la que hace posible el ataque.

El punto de partida es el patrón de fraude habitual: el atacante genera clics desde una IP, el anunciante los detecta y la añade a la lista de exclusión. Esa IP es, desde ese momento, la IP expuesta. Hasta aquí, nada nuevo. Lo novedoso — el bypass propiamente dicho — es lo que ocurre después:

Con la IP expuesta ya bloqueada, el atacante introduce la IP oculta, utilizada exclusivamente para capturar (harvest) la URL del anuncio — es decir, para recuperar el enlace de destino y sus parámetros de tracking (incluido el GCLID). La IP oculta nunca hace clic; solo captura.
La IP oculta pasa la URL capturada y el GCLID a la IP expuesta.
La petición de clic real se envía desde la IP expuesta — la bloqueada. A pesar de estar en la lista de exclusión, Google cobra el clic.
Como la IP oculta nunca hace clic, nunca aparece en los datos de tráfico del anunciante. No se puede detectar y no se puede bloquear. Puede seguir capturando indefinidamente.

El resultado neto: la lista de exclusión deja de funcionar. La IP expuesta sigue produciendo clics cobrados, y la IP oculta permanece permanentemente invisible para el anunciante.

Cómo lo verificamos

En marzo de 2026 reprodujimos el ataque completo en una prueba de concepto (PoC) controlada, sobre nuestra propia cuenta de Google Ads de Fáktica, simulando un atacante contra nuestras propias campañas. Conseguimos generar clics cobrados desde una IP que estaba en nuestra lista de exclusión, exactamente como se describe arriba. El experimento está documentado internamente y es totalmente reproducible.

Por qué esto importa más allá del laboratorio

Esto no es una curiosidad teórica. En el trabajo forense que estamos haciendo sobre cuentas de clientes observamos comportamientos plenamente compatibles con que esta técnica se esté explotando de forma activa — y lo observamos de dos maneras distintas.

La primera es la prueba más directa: clics desde IPs excluidas que Google sigue cobrando. Hemos documentado casos de IPs individuales que han acumulado miles de clics a lo largo de casi dos años, con decenas de clics al día, encajando en cada patrón de libro de texto del fraude automatizado. También botnets coordinados de IPs que rotan el mismo conjunto de user-agents día tras día. Cuando los anunciantes añaden esas IPs a sus listas de exclusión, lo que ocurre no es que los clics se detengan — lo que ocurre es que Google invalida algunos de los clics posteriores desde esas IPs, pero cobra otros. Una IP excluida que sigue produciendo clics cobrados está, por definición, saltándose el mecanismo de exclusión.

La segunda son los GCLID replay patterns — URLs individuales de anuncios (cada una con un GCLID único) apareciendo en los logs de servidor desde múltiples IPs distintas, a menudo en países diferentes, dentro de ventanas temporales cortas. Esa es justamente la huella que produce la técnica de captura y replay: una captura, múltiples ejecuciones. Es también una de las explicaciones plausibles de que un mismo GCLID acabe cobrado dos veces, patrón que hemos cubierto aparte.

No podemos confirmar desde el lado del anunciante que el mecanismo concreto sea siempre el que describimos aquí — no tenemos acceso a los logs de servidor de Google. Pero la huella está ahí, es consistente y no es rara.

La implicación es estructural:

La exclusión nativa de IPs en Google Ads deja de ser un mecanismo de bloqueo fiable para cualquier atacante dispuesto a separar captura y clic.
Las herramientas antifraude de terceros que se apoyan en el bloqueo de IPs heredan la misma limitación. Todo lo que bloqueen a nivel de IP se puede saltar con la misma división en dos IPs.

Lo que Google puede hacer

Google está en una posición única para cerrar esto. Cuando un usuario hace clic en un anuncio de Google Ads, la URL del anuncio no es el destino final — es un redirect de Google que actúa como puente a la landing del anunciante. El anunciante no ve la IP oculta, pero Google sí: Google ve la IP que recuperó la URL del anuncio y la IP que finalmente ejecutó el clic, y ambas peticiones comparten el mismo click ID (GCLID).

Correlacionar esas dos IPs es una operación server-side. Google podría marcar como inválido cualquier clic cuyo GCLID fue capturado desde una IP distinta a la que lo ejecuta, o — como mínimo — tratar como inválidos los clics que provengan de IPs que están en la lista de exclusión del propio anunciante, independientemente de qué IP capturó la URL en primer lugar. Ninguna de las dos cosas es técnicamente compleja. Ninguna requiere una señal nueva que Google no esté recogiendo ya.

Hemos reportado esto a Google en varias ocasiones, en nombre de clientes que sufren pérdidas sustanciales de seis y siete cifras por ataques que muestran exactamente esta huella. Hasta la fecha, nada de lo que podemos observar desde el lado del anunciante ha cambiado, y la técnica sigue funcionando.

No es la primera vez que un problema de este tipo se hace público. Hace más de una década, el Prof. Manuel Blázquez (Universidad Complutense de Madrid) documentó una vulnerabilidad relacionada en Google AdSense — un exploit diferente (lado del publisher, no del anunciante), pero con un núcleo estructuralmente idéntico: extraer la URL validada del anuncio por un canal, ejecutar el clic desde otro, aprovechar que Google ve ambos lados mientras que la víctima solo ve uno. Blázquez se lo comunicó a Google en 2013, no obtuvo respuesta sustantiva, y lo publicó. Más de diez años después, estamos publicando una variante del mismo problema estructural, que sigue sin parchearse.

Qué puedes hacer como anunciante hoy

Siendo honestos, poco unilateralmente — la información necesaria para detectar este ataque con certeza vive en los servidores de Google, no en los tuyos. Pero hay un primer paso concreto que merece la pena dar:

Comprueba si te está pasando. Cruza tus logs de servidor con las IPs que has añadido a la lista de exclusión de Google Ads. Si se están cobrando clics desde IPs que crees bloqueadas, es un indicio fuerte de que la técnica de captura y replay se está usando contra tu cuenta. Una segunda señal complementaria es el uso repetido de un mismo GCLID desde múltiples IPs en los logs de peticiones.
Si lo detectas, escálalo a Google con la evidencia. Extractos de logs de servidor que muestren clics desde IPs excluidas, y GCLIDs apareciendo desde múltiples IPs, son el tipo de evidencia que consigue tracción en las reclamaciones de clics inválidos. Asegúrate de que el ticket cae en Billing, no en soporte genérico.
Deja de tratar la exclusión de IPs como defensa principal. Es una capa, y cada vez más débil — tanto por los motivos que ya señalamos en otro post (IPs dinámicas, CG-NAT) como por el motivo estructural documentado aquí. La detección tiene que apoyarse en señales comportamentales y server-side que los atacantes no puedan enmascarar simplemente cambiando de IP.

Si quieres entender la superficie de ataque más amplia que estamos viendo en Google Ads — fraude de impresiones, cobros por GCLID duplicado, emplazamientos tóxicos en YouTube — el resto de este blog es un buen punto de partida. Y si sospechas que te están atacando y quieres una auditoría forense independiente de tu tráfico, eso es exactamente lo que hacemos.