In breve: Gli account pubblicitari non vengono violati indovinando la password. I metodi documentati sono una sessione del browser rubata, un proxy di phishing che trasmette la password e il codice monouso, un falso collegamento amministratore o richiesta di partnership, un token API rubato e un accesso mai revocato. Lynt esegue quindi un controllo ogni 30 minuti su ogni account Google Ads e Meta dei clienti. Il sistema verifica se l'account è attivo, se il metodo di pagamento o il limite di spesa cambiano, se gli annunci puntano ancora al dominio del cliente e se un nuovo utente ottiene l'accesso. Ogni modifica arriva su Slack e su una pagina interna. La persona responsabile approva o rifiuta la modifica. Il brief di implementazione è disponibile per il download.
Gli aggressori non indovinano le password degli account Google Ads o degli account pubblicitari Facebook. I rapporti sulla sicurezza del 2025 e del 2026 descrivono cinque metodi di intrusione. La password non è il punto debole in nessuno di questi.
- Una sessione del browser rubata. Il malware infostealer copia i cookie da un browser connesso. Recorded Future ha indicizzato 276 milioni di credenziali con un cookie di sessione attivo nel 2025. Un cookie non richiede password né un secondo fattore (Recorded Future). Gli aggressori distribuiscono Ducktail come false offerte di lavoro nel marketing (WithSecure). Ducktail è una famiglia di malware scritta per gli account Facebook Business.
- Un proxy di phishing che supera il controllo a due fattori. La vittima digita la vera password in quella che sembra la pagina reale e approva la richiesta. Il proxy conserva quindi la sessione creata dal sito reale. A metà del 2025 un singolo kit di phishing a noleggio era responsabile del 62% dei tentativi di phishing bloccati da Microsoft (Microsoft). I criminali hanno comprato annunci sulla rete di ricerca di Google per la query “Google Ads” per inviare le vittime a tale proxy (Malwarebytes).
- Un falso invito. Su Meta, l’aggressore invia una richiesta di partnership. L’esca si trova nel nome dell’azienda, mentre l’email in sé è un messaggio autentico di Meta (Huntress). Su Google, l’aggressore invia un falso invito a collegare un account amministratore che reindirizza la vittima a una pagina di accesso che imita quella autentica. Le agenzie hanno perso interi account amministratore in questo modo con i due fattori attivati (Search Engine Land).
- Un token API rubato o un’autorizzazione dell’app. Le autorizzazioni OAuth e i token degli utenti di sistema di Meta continuano a funzionare dopo il ripristino della password. Un amministratore deve revocarli.
- Un accesso mai revocato. Il freelance di due anni fa, l’agenzia precedente o l’ex responsabile marketing del cliente.
Una volta dentro, l’aggressore aggiunge un amministratore e collega un account amministratore. Poi cambia il metodo di pagamento o il limite di spesa. L’aggressore lancia campagne e punta gli annunci verso un dominio diverso da quello del cliente. Mimecast ha contato 1,86 milioni di rilevamenti di furti di account pubblicitari solo nella seconda metà del 2025. Un account rubato viene venduto per poche centinaia di dollari (Mimecast). Nei casi pubblicati le agenzie hanno scoperto il furto da sole. Questo è avvenuto spesso la mattina successiva.
Perché abbiamo creato un controllo ogni 30 minuti
Lynt gestisce gli account dei clienti su Google Ads e Meta. Il nostro controllo precedente veniva eseguito ogni 2,5 ore. Questo controllo verificava solo l’accesso degli utenti. Nei casi pubblicati, il denaro è sparito in un giorno. L’accesso è solo uno degli elementi che cambiano in un account violato. Il controllo ora viene eseguito ogni 30 minuti e copre più elementi. Il sistema verifica lo stato dell’account, il metodo di pagamento, il limite di spesa, le destinazioni degli annunci e l’accesso degli utenti.
Questa versione è andata online a settembre 2026. Il sistema legge ogni account gestito su entrambe le piattaforme ogni 30 minuti. L’elenco di chi ha accesso su Google viene letto ancora più spesso, ogni 18 minuti. Una volta al giorno il monitor rilegge anche ogni account per intero, coprendo i dati che i controlli ogni 30 minuti non toccano. Il software non modifica nulla in nessuna delle due piattaforme. Un operatore umano prende le decisioni.
Cosa controlla il sistema
| Controllo | Google Ads | Meta |
|---|---|---|
| L'account è attivo? | Stato dell'account letto tramite il nostro account amministratore. Gli stati includono sospeso, annullato o chiuso. L'API non fornisce alcun motivo per una sospensione e l'avviso segnala questo limite. | Stato dell'account e motivo della disabilitazione. Questo include l'avviso di compromissione di Meta. |
| C'è un problema di pagamento? | Budget dell'account esaurito negli account con fatturazione mensile. L'API non espone né un rifiuto della carta né un saldo prepagato. L'avviso segnala questo limite. | Fonte di finanziamento modificata. Limite di spesa modificato o azzerato. Account contrassegnato come non saldato per un saldo non pagato. |
| Gli annunci puntano ancora al dominio del cliente? | Eventi di modifica e report odierno sulle pagine di destinazione ogni 30 minuti. Il controllo rilegge gli elementi modificati. Un passaggio giornaliero copre gli URL configurati e i modelli di monitoraggio a ogni livello. | Link all'interno di ogni creatività attiva ogni 30 minuti. Un audit completo viene eseguito ogni giorno. Il sistema rileva ogni modifica ai parametri URL. |
| Qualcuno di nuovo ha ottenuto l'accesso? | Ogni utente con ruolo, data di creazione e nome di chi lo ha invitato. Inviti in sospeso. Collegamenti amministratore in ogni stato. Una richiesta in sospeso viene vista prima che il cliente la accetti. Scansioniamo i nostri account amministratore allo stesso modo. | Il registro delle attività mostra quali utenti sono stati aggiunti o rimossi dall'account. Aziende partner aggiunte o rimosse. I controlli giornalieri coprono i nostri utenti di Business Manager, gli utenti di sistema e le impostazioni dei due fattori. |
| Abbiamo perso il nostro accesso? | Un account che smette di rispondere viene contrassegnato come illeggibile finché non risponde di nuovo. | Un'autorizzazione persa attiva un avviso. Un token non valido blocca l'esecuzione e segnala l'errore. |
Il sistema confronta ogni lettura con lo snapshot precedente. Ogni riga aggiunta, rimossa o modificata diventa un risultato. Un errore di autorizzazione viene archiviato come stato a sé stante per account. L’errore non viene mai salvato come risultato vuoto. Il riepilogo giornaliero diventa rosso quando un controllo non viene eseguito nel suo intervallo programmato.
Come il team lavora con il sistema
- I risultati correlati su un account si uniscono in un unico incidente. L’incidente viene inviato su Slack come messaggio diretto al revisore e pubblicato come singolo record nel canale del team. Il messaggio e il record indicano entrambi il cliente e lo specialista che segue l’account. Il messaggio occupa due righe e include un link. Nessun avviso si ripete a meno che l’incidente non si aggravi.
- Il link apre una pagina interna raggiungibile solo dalla nostra rete. La pagina mostra l’account e le modifiche. Mostra anche lo stato precedente e quello nuovo, quando lo abbiamo visto e cosa verificare.
- L’approvazione di un evento registra l’ambito esatto. L’approvazione indica esattamente cosa è stato autorizzato, ad esempio un utente specifico con un ruolo specifico o un dominio specifico su un account specifico. Una modifica successiva richiede una nuova revisione. Il rifiuto di un evento mantiene l’incidente aperto come non autorizzato. Quando una nuova lettura non può confermare né smentire un evento, il revisore lo chiude con «Risolvi con una nota».
- Un operatore umano risolve il problema in Google Ads o Meta. L’incidente si chiude quando la lettura completa successiva conferma la rimozione dello stato non autorizzato.
- La pagina di stato elenca lo specialista per ogni account. La pagina mostra l’ultima lettura riuscita, le decisioni in sospeso e i dati che non possiamo leggere. Un riepilogo di due righe per entrambe le piattaforme arriva su Slack alle 07:00.
Perché queste scelte
- Ogni 30 minuti. La quota dell’API stabilisce quell’intervallo. Ogni lettura e il consumo dei nostri altri strumenti incidono sulla stessa quota. Il monitor conta le proprie operazioni rispetto a quel limite e segnala ogni esecuzione in ritardo.
- Sola lettura con approvazione umana. Un nuovo utente o un nuovo dominio può essere una modifica di uno specialista. Può anche essere la nuova agenzia di un cliente o un’intrusione. Il monitor non può distinguerli. La persona responsabile può farlo, di solito entro un’ora.
- I guasti non vengono mai nascosti. Un monitor che si blocca senza che te ne accorga è peggio di nessun monitor, perché il team smette di controllare. Un token scaduto blocca l’esecuzione e segnala l’errore. Un errore di autorizzazione viene salvato come stato a sé stante, mai come risultato vuoto. Un account che non può essere letto viene contrassegnato come non letto ogni giorno.
- Limiti su ogni avviso. Il verde non deve mai significare “non possiamo vederlo”. Gli URL dei prodotti Shopping risiedono nel Merchant Center, non nella Google Ads API. Le Dynamic Search Ads scelgono la pagina di destinazione al momento della pubblicazione. Nella nostra scansione, quattro annunci Meta attivi su dieci avevano il link memorizzato in un post della Pagina, e gli annunci del catalogo lo memorizzano nel catalogo. La lettura dei post della Pagina o del catalogo richiede autorizzazioni che la nostra app non possiede. Google non espone i rifiuti delle carte. Lo stato dei due fattori degli utenti dei clienti rimane illeggibile su entrambe le piattaforme. Imponiamo i due fattori nelle impostazioni dell’account.
Scarica la checklist e il brief di implementazione
Un solo file. Una checklist di sicurezza da esaminare con le persone che amministrano i tuoi account Google Ads e Meta. Il file include un brief di implementazione per il monitor descritto sopra. Troverai query di esempio per la Google Ads API v23 e letture per la Meta API v24. Il brief contiene regole di rilevamento proposte e le lacune di copertura note. Un implementatore deve adattare e testare il sistema per i tuoi account. Lascia la tua email e il file è tuo.
Un file, una lista. Scrivo solo quando c'è qualcosa che vale la pena leggere.
Il mio account Google Ads è stato hackerato. Cosa faccio per prima cosa?
Usa un dispositivo sicuro e isola ogni computer sospetto. Segnala subito la violazione a Google Ads tramite il modulo per gli account compromessi. Se puoi ancora aprire l’account, metti in pausa le campagne non autorizzate. Conserva la cronologia delle modifiche e le pagine di fatturazione come prova. Rimuovi gli utenti non autorizzati e i collegamenti amministratore confermati in Accesso e sicurezza. Se non riesci ad accedere, avvia il recupero dell’Account Google. Reimposta la password, controlla i dispositivi collegati e revoca gli accessi di terze parti sconosciuti. Controlla l’email e il telefono di recupero e i metodi di pagamento. Segnala gli addebiti non autorizzati all’emittente della carta.
Come capisco se il mio account pubblicitario Facebook o Business Manager è stato hackerato?
Indaga su ogni utente o partner sconosciuto, su ogni rimozione di un amministratore non richiesta, su ogni modifica ai fondi e su ogni campagna non autorizzata. Un solo elemento basta per agire. Non aspettare una sequenza completa o l’avviso di compromissione di Meta. Metti in sicurezza l’account Facebook compromesso tramite il recupero degli account hackerati di Facebook. Contatta il supporto aziendale di Meta per gli asset colpiti. Se hai ancora l’accesso, metti in pausa gli annunci non autorizzati e rimuovi gli accessi non autorizzati confermati. Chiedi all’amministratore aziendale di controllare le integrazioni e di revocare i token degli utenti di sistema compromessi.
Perché l'autenticazione a due fattori non ha bloccato l'attacco?
Una sessione rubata permette a un aggressore di agire senza un nuovo login. Il sistema non richiede un secondo fattore. Un proxy di phishing trasmette la tua password e il codice monouso al sito reale e conserva la sessione creata dal sito reale. Le passkey e le chiavi di sicurezza hardware resistono a questa forma di phishing. Questi strumenti non possono proteggere una sessione già rubata da un dispositivo infetto. Approvare la richiesta di accesso di un aggressore è un errore diverso. In questo caso sei tu ad autorizzare l’aggressore.
La Google Ads API e la Meta API possono segnalare lo stato dei due fattori degli utenti?
La Google Ads API v23 non espone lo stato della verifica in due passaggi per utente né il requisito a livello di account. Meta espone i campi dei due fattori per un’azienda che sei autorizzato ad amministrare. Nel nostro test sull’accesso dei partner, la risposta dell’API per l’azienda di un cliente non conteneva questi campi e restituiva un elenco di utenti vuoto. Tratta un campo mancante come sconosciuto, non come disabilitato. Verifica i requisiti del cliente nelle impostazioni.
Con quale frequenza un'agenzia dovrebbe controllare chi ha accesso agli account pubblicitari dei clienti?
Scegli l’intervallo in base alla spesa potenziale, al rischio di accesso e alla velocità di risposta. Nei casi pubblicati, gli aggressori hanno speso decine di migliaia di dollari in un solo giorno. Un controllo notturno lascia una lunga finestra su un account ad alta spesa. Lynt controlla ogni account cliente ogni 30 minuti. Una revisione degli accessi settimanale o trimestrale è un controllo di fine rapporto. Non rileva un furto in corso, quindi usa le notifiche di sicurezza e di fatturazione delle piattaforme tra una revisione e l’altra.
Un controllo ogni 30 minuti esaurisce la quota della Google Ads API?
Un portafoglio piccolo non si avvicina al limite. I calcoli seguenti presuppongono che ogni lettura venga eseguita ogni 30 minuti. A un intervallo di 30 minuti, ciascuna delle quattro letture di accesso viene eseguita 48 volte al giorno. Con sette letture giornaliere delle destinazioni e una lettura degli eventi di modifica ogni 30 minuti, si ottengono 247 operazioni per account al giorno. Questo calcolo esclude le riletture mirate, i nuovi tentativi e gli altri strumenti. L’accesso di base consente 15.000 operazioni in una finestra mobile di 24 ore. A 247 operazioni per account, questo copre al massimo 60 account. Un portafoglio più grande richiede un intervallo più lungo o l’accesso Standard. Controlla il livello di accesso del tuo progetto Google Cloud e riserva capacità per l’intero carico di lavoro.
Inizia con un solo account. Verifica manualmente l’elenco degli utenti e le destinazioni approvate. Poi testa il rilevamento, una lettura fallita e la consegna degli avvisi. Solo dopo espandi il monitor al resto degli account.
