En bref: Les comptes publicitaires ne sont pas piratés en devinant le mot de passe. Les méthodes documentées incluent une session de navigateur volée, un proxy de hameçonnage qui relaie le mot de passe et le code à usage unique, une fausse demande d’association de compte administrateur ou de partenaire, un token d’API volé et un accès jamais révoqué. Chez Lynt, nous effectuons donc une vérification toutes les 30 minutes sur le compte Google Ads et Meta de chaque client. Nous vérifions si le compte reste actif. Nous contrôlons les changements de mode de paiement ou de plafond de dépenses. Nous confirmons que les annonces pointent toujours vers le domaine du client. Nous détectons les nouveaux accès. Chaque changement part sur Slack et sur une page interne. Le responsable approuve ou rejette ce changement. Le brief d’intégration est disponible en téléchargement.
Les attaquants ne devinent pas les mots de passe des comptes Google Ads ou des comptes publicitaires Facebook. Les rapports de sécurité de 2025 et 2026 décrivent cinq méthodes d’accès : le mot de passe n’est le point faible d’aucune de ces méthodes.
- Une session de navigateur volée. Un malware de type infostealer copie les cookies d’un navigateur connecté. Recorded Future a indexé 276 millions d’identifiants avec un cookie de session actif en 2025. Un cookie ne nécessite aucun mot de passe ni deuxième facteur (Recorded Future). Les attaquants diffusent Ducktail sous forme de fausses offres d’emploi en marketing (WithSecure). Ducktail est une famille de malwares conçue pour les comptes Facebook Business.
- Un proxy de hameçonnage contournant la vérification à double facteur. La victime saisit le vrai mot de passe sur ce qui ressemble à la vraie page et approuve l’invite. Le proxy conserve ensuite la session que le vrai site crée. Mi-2025, un seul kit de hameçonnage loué était à l’origine de 62 % des tentatives de hameçonnage bloquées par Microsoft (Microsoft). Des criminels ont acheté des annonces Search pour la requête « Google Ads » afin d’envoyer les victimes vers un tel proxy (Malwarebytes).
- Une fausse invitation. Sur Meta, l’attaquant soumet une demande de partenaire. Le leurre se trouve dans le nom de l’entreprise, tandis que l’e-mail lui-même est un véritable message de Meta (Huntress). Sur Google, l’attaquant envoie une fausse invitation d’association de compte administrateur qui renvoie la victime vers une fausse page de connexion. Des agences ont perdu des comptes administrateur entiers de cette manière avec le double facteur activé (Search Engine Land).
- Un token d’API volé ou une autorisation d’application volée. Les autorisations OAuth et les tokens d’utilisateur système Meta continuent de fonctionner après une réinitialisation de mot de passe. Un administrateur doit les révoquer pour les arrêter.
- Un accès jamais révoqué. Le freelance d’il y a deux ans, l’agence précédente ou l’ancien responsable marketing du client.
Une fois à l’intérieur, l’attaquant ajoute un administrateur et associe un compte administrateur. Il modifie ensuite le mode de paiement ou le plafond de dépenses. Il lance des campagnes et dirige les annonces vers un domaine étranger au client. Mimecast a comptabilisé 1,86 million de détections de vols de comptes publicitaires au second semestre 2025. Un compte volé se vend pour quelques centaines de dollars (Mimecast). Dans les cas publiés, les agences ont découvert le vol elles-mêmes, souvent le lendemain matin.
Pourquoi nous avons créé une vérification toutes les 30 minutes
Chez Lynt, nous gérons des comptes clients sur Google Ads et Meta. Notre précédente vérification s’exécutait toutes les 2,5 heures et contrôlait uniquement les accès utilisateurs. Dans les cas publiés, l’argent a disparu en une journée. L’accès n’est qu’un des éléments modifiés dans un compte piraté. La vérification s’exécute désormais toutes les 30 minutes et couvre plus d’éléments. Elle surveille le statut du compte, le mode de paiement, le plafond de dépenses, les destinations des annonces et les accès utilisateurs.
Cette version a été lancée en septembre 2026. Elle lit chaque compte géré sur les deux plateformes toutes les 30 minutes. La liste des personnes ayant accès sur Google est lue encore plus souvent, toutes les 18 minutes. Une fois par jour, le moniteur relit aussi chaque compte en entier pour couvrir les données que les vérifications de 30 minutes ne touchent pas. Le logiciel ne modifie rien sur aucune des plateformes. Un humain prend les décisions.
Ce que le système vérifie
| Vérification | Google Ads | Meta |
|---|---|---|
| Le compte est-il actif ? | Statut du compte lu via notre compte administrateur. Les états incluent suspendu, annulé ou fermé. L’API ne donne aucune raison pour une suspension et l’alerte précise cette limite. | Statut du compte et raison de la désactivation. Cela inclut le signalement de compromission propre à Meta. |
| Y a-t-il un problème de paiement ? | Budget du compte épuisé sur les comptes facturés. L’API n’expose ni un refus de carte ni un solde prépayé. L’alerte précise cette limite. | Source de financement modifiée. Plafond de dépenses modifié ou réinitialisé. Compte marqué comme impayé pour un solde non réglé. |
| Les annonces pointent-elles toujours vers le domaine du client ? | Événements de modification et rapport de page de destination du jour toutes les 30 minutes. La vérification relit les éléments modifiés. Une passe quotidienne couvre les URL configurées et les modèles de suivi à chaque niveau. | Liens dans chaque création active toutes les 30 minutes. Un audit complet s’exécute quotidiennement. Il détecte toute modification des paramètres d’URL. |
| Quelqu’un de nouveau a-t-il obtenu un accès ? | Chaque utilisateur avec son rôle, sa date de création et la personne qui l’a invité. Invitations en attente. Liens administrateur dans tous les états. Une demande en attente est visible avant l’acceptation du client. Nous analysons nos propres comptes administrateur de la même manière. | Le journal d’activité montre quels utilisateurs ont été ajoutés ou supprimés sur le compte. Entreprises partenaires ajoutées ou supprimées. Les vérifications quotidiennes couvrent nos propres utilisateurs Business Manager, les utilisateurs système et les paramètres de double facteur. |
| Avons-nous perdu notre propre accès ? | Un compte qui cesse de répondre est marqué comme illisible jusqu’à ce qu’il réponde à nouveau. | Une autorisation perdue déclenche une alerte. Un token invalide fait échouer l’exécution et signale l’échec. |
Le système compare chaque lecture avec l’instantané précédent. Chaque ajout, suppression ou modification devient une détection. Une erreur d’autorisation est enregistrée comme un état distinct pour chaque compte. Elle n’est jamais stockée comme un résultat vide. Le résumé quotidien devient rouge lorsqu’une vérification n’est pas effectuée dans l’intervalle prévu.
Comment l’équipe travaille avec ce système
- Les détections concernant un même compte sont regroupées en un seul incident. L’incident est envoyé sur Slack au réviseur dans un message direct et publié dans le canal de l’équipe. Le message et l’enregistrement nomment tous deux le client et le spécialiste en charge du compte. Cela tient sur deux lignes avec un lien. Les alertes ne se répètent pas sauf si l’incident s’aggrave.
- Le lien ouvre une page interne accessible uniquement sur notre réseau. Elle montre le compte et les modifications. Elle affiche l’état précédent, le nouvel état, l’heure de détection et les éléments à vérifier.
- Approuver un événement enregistre la portée exacte. L’approbation nomme exactement ce qui a été autorisé, par exemple un utilisateur précis avec un rôle précis, ou un domaine précis sur un compte précis. Une modification ultérieure nécessite une nouvelle révision. Rejeter un événement garde l’incident ouvert comme non autorisé. Quand une nouvelle lecture ne peut ni confirmer ni réfuter un événement, le réviseur le ferme avec « Résoudre avec une note ».
- Un humain corrige le problème dans Google Ads ou Meta. L’incident se ferme lorsque la lecture complète suivante confirme la suppression de l’état non autorisé.
- La page d’état liste le spécialiste pour chaque compte. Elle montre la dernière lecture réussie, les décisions en attente et les données que nous ne pouvons pas lire. Un résumé de deux lignes pour les deux plateformes part sur Slack à 07:00.
Pourquoi ces choix
- Toutes les 30 minutes. Le quota de l’API fixe cet intervalle. Chaque lecture et la consommation de nos autres outils sont décomptées du même quota. Le moniteur compte ses propres opérations par rapport à cette limite. Il signale toute exécution tardive.
- Lecture seule avec approbation humaine. L’ajout d’un utilisateur ou d’un domaine est souvent le fait d’un spécialiste ou de la nouvelle agence du client. Cela peut tout aussi bien être un piratage. Le moniteur ne peut pas les différencier. La personne responsable le peut, généralement dans l’heure.
- Les pannes ne sont jamais cachées. Un moniteur qui meurt silencieusement est pire que rien. Il pousse l’équipe à arrêter de chercher. Un token expiré fait échouer l’exécution et signale l’échec. Une erreur d’autorisation constitue un état distinct et ne doit pas être assimilée à une absence de résultat. Un compte qui ne peut pas être lu est signalé comme non lu chaque jour.
- Limites sur chaque alerte. Le vert ne doit jamais signifier une incapacité à voir. Les URL de produits Shopping résident dans Merchant Center, pas dans la Google Ads API. Les annonces Dynamic Search Ads choisissent leur page de destination au moment de la diffusion. Dans notre propre analyse, quatre annonces Meta actives sur dix avaient leur lien stocké dans une publication de Page, et les annonces de catalogue stockent le leur dans le catalogue. Lire les publications de Page ou le catalogue nécessite des autorisations que notre application ne possède pas. Google n’expose pas les refus de carte. Le statut de double facteur des utilisateurs clients reste illisible sur les deux plateformes. Nous imposons le double facteur dans les paramètres du compte à la place.
Télécharge la checklist et le brief d’intégration
Un seul fichier. Une checklist de sécurité à revoir avec les administrateurs de tes comptes Google Ads et Meta. Le fichier contient aussi un brief d’intégration pour le moniteur ci-dessus. Il inclut des exemples de requêtes Google Ads API v23 et de lectures Meta API v24. Il propose des règles de détection et liste les lacunes de couverture connues. Un intégrateur doit l’adapter et le tester pour tes comptes. Laisse ton e-mail et le fichier est à toi.
Un fichier, une liste. Je n'écris que quand il y a quelque chose à lire.
Mon compte Google Ads a été piraté. Que dois-je faire en premier ?
Utilise un appareil de confiance et isole tout ordinateur potentiellement infecté. Signale immédiatement la compromission à Google Ads via son formulaire de compte compromis. Si tu peux encore ouvrir le compte, mets en veille les campagnes non autorisées. Conserve l’historique des modifications et les pages de facturation comme preuves. Supprime les utilisateurs non autorisés confirmés et les liens administrateur sous Accès et sécurité. Si tu es bloqué, lance la récupération du compte Google. Réinitialise le mot de passe. Vérifie les appareils connectés et révoque les accès tiers inconnus. Contrôle l’e-mail et le téléphone de récupération ainsi que les modes de paiement. Signale les débits non autorisés à l’émetteur de ta carte.
Comment savoir si mon compte publicitaire Facebook ou mon Business Manager a été piraté ?
Examine tout utilisateur ou partenaire inconnu. Vérifie toute suppression d’administrateur non demandée. Contrôle tout changement de financement et toute campagne non autorisée. Un seul de ces éléments suffit pour agir. N’attends pas une séquence complète ou le signalement de compromission de Meta. Sécurise le compte Facebook compromis via la récupération de compte piraté de Facebook. Contacte l’assistance aux entreprises de Meta concernant les composants affectés. Si tu as encore accès, mets en veille les annonces non autorisées et supprime les accès non autorisés confirmés. Demande à l’administrateur de l’entreprise de vérifier les intégrations et de révoquer les tokens d’utilisateur système affectés.
Pourquoi l’authentification à double facteur n’a-t-elle pas bloqué le piratage ?
Une session volée permet à un attaquant d’agir sans nouvelle connexion. Aucun deuxième facteur n’est donc demandé. Un proxy de hameçonnage relaie ton mot de passe et ton code à usage unique vers le vrai site. Ce proxy conserve la session que le vrai site crée. Les passkeys et les clés de sécurité matérielles résistent à cette forme de hameçonnage. Ces clés ne peuvent pas protéger une session déjà volée sur un appareil infecté. Approuver la demande d’accès d’un attaquant constitue une faille distincte. Tu as autorisé cet attaquant.
Les API Google Ads et Meta peuvent-elles indiquer le statut de double facteur des utilisateurs ?
La Google Ads API v23 n’expose ni le statut de validation en deux étapes par utilisateur ni l’exigence au niveau du compte. Meta expose les champs de double facteur pour une entreprise que tu es autorisé à administrer. Lors de notre test d’accès partenaire, la réponse de l’API pour l’entreprise d’un client omettait ces champs et renvoyait une liste d’utilisateurs vide. Traite un champ manquant comme inconnu et non comme désactivé. Vérifie les exigences du client dans les paramètres.
À quelle fréquence une agence doit-elle vérifier les accès aux comptes publicitaires des clients ?
Choisis l’intervalle selon les dépenses potentielles, le risque d’accès et la rapidité de réaction. Dans les cas publiés, les attaquants ont dépensé des dizaines de milliers de dollars en une seule journée. Une vérification nocturne laisse une longue fenêtre sur un compte à fortes dépenses. Nous interrogeons chaque compte client toutes les 30 minutes. Une revue des accès hebdomadaire ou trimestrielle est une vérification de départ. Elle ne détecte pas une prise de contrôle en cours. Utilise donc les notifications de sécurité et de facturation des plateformes entre les revues.
Interroger toutes les 30 minutes épuise-t-il le quota de la Google Ads API ?
Un petit portefeuille reste loin de la limite. Les totaux ci-dessous supposent que chaque lecture s’exécute toutes les 30 minutes. À un intervalle de 30 minutes, chacune des quatre lectures d’accès s’exécute 48 fois par jour. Avec sept lectures quotidiennes de destination et une lecture d’événement de modification toutes les 30 minutes, cela fait 247 opérations par compte et par jour. Ce total ne comprend ni les relectures ciblées, ni les nouvelles tentatives, ni les opérations effectuées par d’autres outils. L’accès de base autorise 15 000 opérations par 24 heures glissantes. À raison de 247 opérations par compte et par jour, ce volume permet de couvrir au maximum 60 comptes. Un portefeuille plus important nécessite un intervalle plus long ou l’accès standard. Vérifie le niveau d’accès de ton projet Google Cloud et réserve de la capacité pour l’ensemble de la charge de travail.
Commence par un seul compte. Vérifie manuellement sa liste d’utilisateurs et ses destinations approuvées. Teste ensuite la détection, une lecture échouée et la livraison des alertes. Étends ensuite le moniteur au reste des comptes.
