En resumen: Los atacantes no entran en las cuentas publicitarias adivinando la contraseña. Las cinco vías documentadas son una sesión de navegador robada, un proxy de phishing que reenvía la contraseña y el código de un solo uso, una solicitud falsa para vincular una cuenta de administrador o añadir un socio, un token de API robado y un acceso que nadie revocó. Por eso, en Lynt comprobamos cada 30 minutos todas las cuentas de Google Ads y Meta de nuestros clientes. Revisamos si la cuenta sigue activa y si han cambiado el método de pago o el límite de gasto. También comprobamos si los anuncios siguen apuntando al dominio del cliente y si alguien nuevo ha obtenido acceso. Cada cambio se envía a Slack y a una página interna, donde la persona responsable lo aprueba o lo rechaza. El documento de implementación se puede descargar.
Los atacantes no necesitan adivinar las contraseñas de las cuentas de Google Ads o Facebook. Los informes de seguridad de 2025 y 2026 describen cinco vías de entrada, y en ninguna de ellas el punto débil es la contraseña.
- Una sesión de navegador robada. Un infostealer copia las cookies de un navegador con una sesión abierta. Recorded Future catalogó 276 millones de credenciales que incluían una cookie de sesión activa en 2025. Con una cookie no hacen falta ni la contraseña ni el segundo factor (Recorded Future). Ducktail es una familia de malware creada para las cuentas de Facebook Business que los atacantes distribuyen mediante falsas ofertas de trabajo en marketing (WithSecure).
- Un proxy de phishing que supera la comprobación de dos factores. La víctima introduce su contraseña válida en lo que parece la página auténtica y aprueba la solicitud. El proxy se queda entonces con la sesión que crea el sitio real. A mediados de 2025, un único kit de phishing de alquiler estaba detrás del 62 % de los intentos de phishing que bloqueó Microsoft (Microsoft). Los delincuentes incluso han comprado anuncios en Google Search para la consulta «Google Ads» con el fin de llevar a sus víctimas a uno de estos proxies (Malwarebytes).
- Una invitación falsa. En Meta, el atacante envía una solicitud de socio. El señuelo está en el nombre del negocio. El correo en sí es un mensaje legítimo de Meta (Huntress). En Google, envía una invitación falsa para enlazar la cuenta con una cuenta de administrador y dirige a la víctima a una página de inicio de sesión que imita a la auténtica. Las agencias han perdido de este modo cuentas de administrador completas incluso con la autenticación de dos factores activada (Search Engine Land).
- Un token de API o permiso de aplicación robado. Las autorizaciones de OAuth y los tokens de usuario del sistema de Meta siguen funcionando después de restablecer la contraseña hasta que un administrador los revoca.
- Un acceso que nadie revocó. El freelance de hace dos años, la agencia anterior o el antiguo responsable de marketing del cliente.
Una vez dentro, el atacante añade un administrador y vincula una cuenta principal. Después cambia el método de pago o el límite de gasto, lanza campañas y dirige los anuncios a un dominio distinto del cliente. Mimecast registró 1,86 millones de detecciones de robo de cuentas publicitarias solo en la segunda mitad de 2025. Una cuenta robada se vende por unos cientos de dólares (Mimecast). En los casos publicados, fueron las propias agencias las que descubrieron el robo, a menudo a la mañana siguiente.
Por qué creamos una comprobación cada 30 minutos
Gestionamos cuentas de clientes en Google Ads y Meta. Antes, nuestra comprobación se ejecutaba cada 2,5 horas y solo revisaba los accesos de usuarios. En los casos publicados, el dinero desapareció en cuestión de un día, y en una cuenta secuestrada no solo cambian los accesos. Por eso, ahora comprobamos cada 30 minutos el estado de la cuenta, el método de pago, el límite de gasto, los destinos de los anuncios y los accesos de usuarios.
Esta versión entró en funcionamiento en septiembre de 2026. El sistema consulta cada 30 minutos todas las cuentas que gestionamos en ambas plataformas. En Google, la lista de quién tiene acceso se consulta incluso cada 18 minutos. Una vez al día el monitor también vuelve a consultar por completo todas las cuentas. Así cubre los datos que las consultas de 30 minutos no tocan. El software no modifica nada en ninguna plataforma. Las decisiones las toma una persona.
Qué comprueba
| Comprobación | Google Ads | Meta |
|---|---|---|
| ¿Está activa la cuenta? | Consultamos el estado de la cuenta a través de nuestra cuenta de administrador. Puede aparecer como suspendida, cancelada o cerrada. La API no indica el motivo de una suspensión, y la alerta deja clara esta limitación. | Consultamos el estado de la cuenta y el motivo por el que está inhabilitada, incluida la marca de cuenta comprometida de Meta. |
| ¿Hay un problema de pago? | En las cuentas con facturación, detectamos si se ha agotado el presupuesto de la cuenta. La API no muestra ni un rechazo de tarjeta ni el saldo de prepago, y la alerta deja clara esta limitación. | Detectamos si cambia la fuente de financiación, si cambia o se restablece el límite de gasto y si la cuenta aparece como pendiente de pago por un saldo impagado. |
| ¿Los anuncios siguen apuntando al dominio del cliente? | Cada 30 minutos consultamos los eventos de cambio y el informe de páginas de destino del día. Volvemos a consultar los elementos modificados. Una revisión diaria cubre las URL configuradas y las plantillas de seguimiento en todos los niveles. | Cada 30 minutos revisamos los enlaces de todas las creatividades activas. Además, hacemos una auditoría completa cada día que detecta cualquier cambio en los parámetros de URL. |
| ¿Alguien nuevo obtuvo acceso? | Para cada usuario, consultamos su rol, la fecha de creación y quién lo invitó. También revisamos las invitaciones pendientes y los enlaces de administrador en cualquier estado. Así detectamos una solicitud pendiente antes de que el cliente la acepte. Aplicamos la misma revisión a nuestras propias cuentas de administrador. | El registro de actividad nos permite detectar los usuarios y las empresas asociadas que se han añadido o eliminado de la cuenta. Las comprobaciones diarias también cubren nuestros propios usuarios de Business Manager, los usuarios del sistema y la configuración de dos factores. |
| ¿Hemos perdido nuestro propio acceso? | Si una cuenta deja de responder, la marcamos como inaccesible hasta que vuelva a responder. | Si perdemos un permiso, se activa una alerta. Si un token deja de ser válido, la ejecución falla y el sistema informa del fallo. |
El sistema compara cada consulta con la captura anterior. Cada fila añadida, eliminada o modificada se registra como un hallazgo. Un error de permisos queda guardado como un estado específico de esa cuenta, nunca como un resultado vacío. El resumen diario aparece en rojo si alguna comprobación no se ha ejecutado en el intervalo previsto.
Cómo trabaja el equipo con el sistema
- Los hallazgos relacionados de una misma cuenta se agrupan en un incidente. El incidente llega al revisor por mensaje directo de Slack y también se publica como un único registro en el canal del equipo. Tanto el mensaje como el registro indican en dos líneas el nombre del cliente y el del especialista responsable de la cuenta e incluyen un enlace. Las alertas no vuelven a enviarse salvo que el incidente escale.
- El enlace lleva a una página interna a la que solo se puede acceder desde nuestra red. Allí aparecen la cuenta, el cambio, el estado anterior, el estado nuevo, cuándo lo detectamos y qué hay que verificar.
- Cuando alguien aprueba un evento, queda registrado el alcance exacto de la aprobación. Se indica exactamente qué se autorizó, como un usuario concreto con un rol concreto o un dominio concreto en una cuenta concreta. Cualquier cambio posterior exige una nueva revisión. Si se rechaza el evento, el incidente permanece abierto como no autorizado. Si una nueva consulta no permite confirmar ni descartar el evento, el revisor lo cierra con «Resolver con una nota».
- Una persona corrige el problema en Google Ads o Meta. El incidente se cierra cuando una consulta completa posterior confirma que el estado no autorizado ha desaparecido.
- La página de estado indica el especialista responsable de cada cuenta, la última consulta completada correctamente, las decisiones pendientes y los datos que no podemos consultar. A las 07:00 se envía a Slack un resumen de dos líneas que abarca ambas plataformas.
Por qué estas decisiones
- Cada 30 minutos. La cuota de la API determina ese intervalo. Tanto cada consulta como el uso de nuestras otras herramientas se descuentan de la misma cuota. El monitor contabiliza sus propias operaciones dentro de ese límite y avisa si alguna ejecución se retrasa.
- Solo lectura con aprobación humana. Muchas veces, un usuario o dominio nuevo corresponde a un cambio de un especialista o a la nueva agencia del cliente. También puede ser un secuestro de la cuenta. El monitor no puede saber cuál de estas situaciones se ha producido. La persona responsable sí puede distinguirlas, normalmente en menos de una hora.
- Los fallos nunca se ocultan. Un monitor que deja de funcionar sin avisar es peor que no tener ninguno, porque hace que el equipo deje de prestar atención. Si un token caduca, la ejecución falla y el sistema informa del fallo. Un error de permisos se guarda como un estado propio, nunca como un resultado vacío. Cada día, las cuentas que no se pueden consultar aparecen marcadas como no leídas.
- Cada alerta muestra sus limitaciones. Un estado verde nunca debe significar «no podemos verlo». Las URL de los productos de Shopping están en Merchant Center, no en la Google Ads API. Los anuncios de Dynamic Search Ads eligen la página de destino en el momento de mostrarse. En nuestro propio análisis, cuatro de cada diez anuncios activos de Meta tenían el enlace guardado en una publicación de la página, mientras que los anuncios de catálogo lo guardaban en el catálogo. Para leer las publicaciones de la página o el catálogo se necesitan permisos que nuestra aplicación no tiene. Google no muestra los rechazos de tarjetas. Tampoco podemos consultar en ninguna de las dos plataformas el estado de la autenticación de dos factores de los usuarios de los clientes. Por eso exigimos la autenticación de dos factores en la configuración de la cuenta.
Descarga la lista de comprobación y el documento de implementación
Un único archivo incluye una lista de comprobación de seguridad para revisar con quienes administran tus cuentas de Google Ads y Meta. También contiene el documento de implementación de este monitor. El documento incluye consultas de ejemplo de la versión 23 de la Google Ads API, consultas de la versión 24 de la API de Meta, reglas de detección propuestas y las limitaciones de cobertura conocidas. Quien lo implemente debe adaptarlo a tus cuentas y probarlo. Deja tu correo electrónico y podrás descargarlo.
Un archivo, una lista. Solo escribo cuando hay algo que merece leerse.
Me han hackeado la cuenta de Google Ads. ¿Qué hago primero?
Usa un dispositivo de confianza y aísla cualquier ordenador que pueda estar infectado. Informa de inmediato a Google Ads mediante el formulario para cuentas comprometidas. Si todavía puedes acceder a la cuenta, pausa las campañas no autorizadas, conserva como prueba el historial de cambios y las páginas de facturación y elimina en Acceso y seguridad los usuarios y enlaces de administrador que hayas confirmado como no autorizados. Si ya no puedes acceder, inicia la recuperación de tu cuenta de Google. Restablece la contraseña, revisa los dispositivos con sesiones abiertas y revoca cualquier acceso de terceros que no reconozcas. Comprueba también el correo y el teléfono de recuperación y los métodos de pago. Si hay cargos no autorizados, comunícalos al emisor de tu tarjeta.
¿Cómo sé si han hackeado mi cuenta publicitaria de Facebook o mi Business Manager?
Investiga cualquier usuario o socio que no reconozcas, cualquier administrador eliminado sin que tú lo hayas pedido, cualquier cambio en la fuente de financiación y cualquier campaña que no hayas autorizado. Basta con uno de estos indicios para actuar. No esperes a que se produzca toda la secuencia ni a que Meta marque la cuenta como comprometida. Protege la cuenta de Facebook afectada mediante la recuperación de cuentas hackeadas de Facebook y contacta con el servicio de ayuda para empresas de Meta acerca de los activos afectados. Si todavía tienes acceso, pausa los anuncios no autorizados y elimina los accesos que hayas confirmado como no autorizados. Pide al administrador del negocio que revise las integraciones y revoque los tokens de los usuarios del sistema que se hayan visto afectados.
¿Por qué no lo detuvo la autenticación de dos factores?
Una sesión robada permite al atacante actuar sin volver a iniciar sesión, por lo que el sistema no solicita un segundo factor. Un proxy de phishing reenvía tu contraseña y tu código de un solo uso al sitio real y se queda con la sesión que este crea. Las llaves de acceso y las llaves de seguridad físicas resisten este tipo de phishing, pero no pueden proteger una sesión que el atacante ya ha robado de un dispositivo infectado. Aprobar una solicitud de acceso del atacante es un fallo distinto porque eres tú quien le ha dado permiso.
¿Pueden la Google Ads API y la API de Meta indicar si los usuarios tienen activada la autenticación de dos factores?
La versión 23 de la Google Ads API no muestra ni el estado de la verificación en dos pasos de cada usuario ni el requisito a nivel de cuenta. Meta sí proporciona campos de autenticación de dos factores de los negocios que estés autorizado a administrar. En nuestra prueba con acceso de socio, la respuesta de la API del negocio de un cliente no incluía esos campos y devolvía una lista de usuarios vacía. Si uno de esos campos no aparece, considera que su estado es desconocido, no que está desactivado, y verifica en la configuración los requisitos del cliente.
¿Cada cuánto debe comprobar una agencia quién tiene acceso a las cuentas publicitarias de sus clientes?
Decide la frecuencia según el gasto potencial, el riesgo asociado a los accesos y el tiempo que tarda alguien en responder. En secuestros documentados se gastaron decenas de miles de dólares en un solo día, así que una comprobación nocturna deja demasiado tiempo sin vigilancia en una cuenta con un gasto elevado. Nosotros comprobamos cada cuenta de cliente cada 30 minutos. Una revisión de accesos semanal o trimestral sirve para comprobar que los accesos se hayan retirado al terminar una colaboración. No sirve para detectar un secuestro en curso, así que entre revisiones debes apoyarte en las notificaciones de seguridad y facturación de las plataformas.
¿Comprobar las cuentas cada 30 minutos agota la cuota de la Google Ads API?
Una cartera pequeña queda muy lejos del límite. Los cálculos siguientes asumen que cada consulta se ejecuta cada 30 minutos. Con un intervalo de 30 minutos, cada una de las cuatro consultas de acceso se ejecuta 48 veces al día. Si sumas siete consultas diarias de destinos y una consulta de eventos de cambio cada 30 minutos, el total es de 247 operaciones por cuenta y día antes de las consultas adicionales sobre elementos concretos, los reintentos y cualquier otra herramienta. El nivel de acceso básico permite 15.000 operaciones por cada periodo móvil de 24 horas. A 247 operaciones por cuenta, ese cupo alcanza para un máximo de 60 cuentas. Una cartera mayor necesita un intervalo más largo o el nivel de acceso estándar. Comprueba el nivel de acceso de tu proyecto de Google Cloud y reserva capacidad para toda la carga de trabajo.
Empieza por una sola cuenta y revisa a mano su lista de usuarios y sus destinos aprobados. Después, prueba la detección, una consulta fallida y la entrega de alertas antes de ampliar el monitor al resto.
