Ukratko: Oglasni računi ne hakiraju se pogađanjem lozinke. Dokumentirani načini proboja su ukradena sesija preglednika, phishing proxy koji prosljeđuje lozinku i jednokratni kod, lažni zahtjev za povezivanje upravitelja ili partnera, ukradeni API token i pristup koji nikada nije opozvan. U agenciji Lynt zato provodimo provjeru svakih 30 minuta na svakom Google Ads i Meta računu klijenta. Provjeravamo je li račun aktivan, jesu li promijenjeni način plaćanja ili ograničenje potrošnje, vode li oglasi na domenu klijenta i je li netko novi dobio pristup. Svaka promjena ide na Slack i na internu stranicu. Tamo odgovorna osoba odobrava ili odbija promjenu. Upute za implementaciju dostupne su za preuzimanje.
Napadači ne pogađaju lozinke za Google Ads ili Facebook oglasne račune. Sigurnosna izvješća iz 2025. i 2026. opisuju pet načina proboja. Lozinka nije slaba točka ni u jednom od tih načina.
- Ukradena sesija preglednika. Infostealer zlonamjerni softver kopira kolačiće iz prijavljenog preglednika. Tvrtka Recorded Future indeksirala je 276 milijuna vjerodajnica s aktivnim kolačićem sesije u 2025. godini. Kolačić ne zahtijeva lozinku ni drugi faktor (Recorded Future). Napadači isporučuju Ducktail kao lažne marketinške ponude za posao. Ducktail je obitelj zlonamjernog softvera napisana za Facebook Business račune (WithSecure).
- Phishing proxy koji prolazi dvofaktorsku provjeru. Žrtva upisuje pravu lozinku na stranicu koja izgleda kao prava i odobrava upit. Proxy zatim zadržava sesiju koju stvara prava stranica. Do sredine 2025. godine jedan je phishing alat koji se iznajmljuje stajao iza 62 % phishing napada koje je Microsoft blokirao (Microsoft). Kriminalci su kupovali Google Search oglase za korisnički upit „Google Ads” kako bi poslali žrtve na takav proxy (Malwarebytes).
- Lažna pozivnica. Na platformi Meta napadač podnosi zahtjev za partnerstvo. Mamac se nalazi u nazivu tvrtke, dok je sam e-mail autentična poruka od Mete (Huntress). Na Googleu napadač šalje lažnu pozivnicu za povezivanje upravitelja koja vodi žrtvu na sličnu stranicu za prijavu. Agencije su na taj način izgubile cijele račune upravitelja uz uključenu dvofaktorsku autentifikaciju (Search Engine Land).
- Ukradeni API token ili odobrenje aplikacije. OAuth odobrenja i tokeni Metinih sistemskih korisnika nastavljaju raditi nakon poništavanja lozinke. Rade dok ih administrator ne opozove.
- Pristup koji nitko nije opozvao. Freelancer od prije dvije godine, prethodna agencija ili klijentov bivši voditelj marketinga.
Nakon ulaska, napadač dodaje administratora i povezuje nadređeni račun. Zatim mijenja način plaćanja ili ograničenje potrošnje. Napadač pokreće kampanje i usmjerava oglase na domenu koja nije klijentova. Tvrtka Mimecast izbrojala je 1,86 milijuna otkrivanja krađe oglasnih računa samo u drugoj polovici 2025. godine. Ukradeni račun prodaje se za nekoliko stotina dolara (Mimecast). U objavljenim slučajevima agencije su same otkrile krađu. Krađu su često otkrile tek sljedeće jutro.
Zašto smo izradili provjeru svakih 30 minuta
Upravljamo računima klijenata na platformama Google Ads i Meta. Naša ranija provjera izvodila se svaka 2,5 sata i gledala je samo pristup korisnika. U objavljenim slučajevima novac je nestao unutar jednog dana. Pristup je samo jedna od stvari koje se mijenjaju na preuzetom računu. Provjera se sada izvodi svakih 30 minuta i pokriva više stvari. Provjerava status računa, način plaćanja, ograničenje potrošnje, odredišta oglasa i pristup korisnika.
Ova verzija puštena je u rad u rujnu 2026. godine. Sustav čita svaki upravljani račun na obje platforme svakih 30 minuta. Popis tko ima pristup na Googleu čita se još češće, svakih 18 minuta. Jednom dnevno monitor također u potpunosti ponovno čita svaki račun i pokriva podatke koje provjere svakih 30 minuta ne dotiču. Softver ne mijenja ništa ni na jednoj platformi. Čovjek donosi odluke.
Što sustav provjerava
| Provjera | Google Ads | Meta |
|---|---|---|
| Je li račun aktivan? | Status računa čita se kroz naš račun upravitelja. Stanja uključuju suspendiran, otkazan ili zatvoren račun. API ne daje razlog za suspenziju, a upozorenje navodi to ograničenje. | Status računa i razlog onemogućavanja. To uključuje Metinu vlastitu oznaku kompromitiranog računa. |
| Postoji li problem s plaćanjem? | Na računima s mjesečnim fakturiranjem provjeravamo je li proračun računa iscrpljen. API ne prikazuje odbijanje kartice ni unaprijed plaćeni saldo. Upozorenje navodi to ograničenje. | Izvor financiranja je promijenjen. Ograničenje potrošnje je promijenjeno ili poništeno. Račun je označen kao nepodmiren zbog neplaćenog salda. |
| Vode li oglasi i dalje na domenu klijenta? | Događaji promjene i današnje izvještavanje o odredišnim stranicama svakih 30 minuta. Provjera ponovno čita izmijenjene stavke. Dnevni prolaz pokriva konfigurirane URL-ove i predloške za praćenje na svakoj razini. | Veze unutar svake aktivne kreative svakih 30 minuta. Potpuna revizija provodi se dnevno. Revizija hvata svaku promjenu URL parametara. |
| Je li netko novi dobio pristup? | Svaki korisnik s ulogom, datumom kreiranja i osobom koja ga je pozvala. Pozivnice na čekanju. Veze upravitelja u svakom statusu. Zahtjev na čekanju vidljiv je prije nego što ga klijent prihvati. Naše vlastite račune upravitelja skeniramo na isti način. | Dnevnik aktivnosti prikazuje koji su korisnici dodani na račun ili uklonjeni s njega. Partnerske tvrtke dodane ili uklonjene. Dnevne provjere pokrivaju naše korisnike alata Business Manager, sistemske korisnike i postavke dvofaktorske autentifikacije. |
| Jesmo li izgubili vlastiti pristup? | Račun koji prestane odgovarati označava se kao nečitljiv dok ponovno ne odgovori. | Izgubljeno odobrenje pokreće upozorenje. Nevažeći token prekida izvođenje i prijavljuje neuspjeh. |
Sustav uspoređuje svako čitanje s prethodnom snimkom. Svaki dodani, uklonjeni ili promijenjeni redak postaje nalaz. Pogreška dopuštenja pohranjuje se kao vlastito stanje po računu. Pogreška dopuštenja nikada se ne pohranjuje kao prazan rezultat. Dnevni sažetak postaje crven kada se provjera ne izvrši unutar svog zakazanog intervala.
Kako tim radi s tim sustavom
- Povezani nalazi na jednom računu spajaju se u jedan incident. Incident se šalje na Slack kao izravna poruka recenzentu i objavljuje kao jedan zapis u timskom kanalu. Poruka i zapis imenuju klijenta i stručnjaka koji brine o računu. Informacije su u dva retka s vezom. Upozorenja se ne ponavljaju osim ako incident ne eskalira.
- Veza otvara internu stranicu dostupnu samo unutar naše mreže. Stranica prikazuje račun, što se promijenilo te prethodno i novo stanje. Stranica prikazuje kada smo to vidjeli i što treba provjeriti.
- Odobravanje događaja bilježi točan opseg. Odobrenje točno navodi što je dopušteno, na primjer određenog korisnika s određenom ulogom ili određenu domenu na određenom računu. Kasnija promjena zahtijeva novu recenziju. Odbijanje događaja drži incident otvorenim kao neovlašten. Kada novo čitanje ne može potvrditi ni opovrgnuti događaj, recenzent taj događaj zatvara uz napomenu.
- Čovjek rješava problem na platformi Google Ads ili Meta. Incident se zatvara kada sljedeće potpuno čitanje potvrdi uklanjanje neovlaštenog stanja.
- Stranica statusa navodi stručnjaka za svaki račun. Stranica prikazuje posljednje uspješno čitanje, odluke na čekanju i podatke koje ne možemo pročitati. Jedan sažetak u dva retka za obje platforme ide na Slack u 07:00.
Zašto smo odabrali ova rješenja
- Svakih 30 minuta. API kvota određuje taj interval. Svako čitanje i potrošnja naših ostalih alata troše istu kvotu. Monitor broji vlastite operacije prema tom ograničenju i prijavljuje svako zakašnjelo izvođenje.
- Samo za čitanje uz ljudsko odobrenje. Novi korisnik ili nova domena često upućuju na ovlaštenu izmjenu stručnjaka ili uključivanje klijentove nove agencije, a jednako tako mogu značiti i preuzimanje računa. Monitor ih ne može razlikovati. Odgovorna osoba može, obično unutar sat vremena.
- Kvarovi se ne smiju skrivati. Monitor koji tiho prestane raditi gori je od nikakvog monitora. Zbog njega tim prestaje provjeravati. Istekli token prekida izvođenje i prijavljuje neuspjeh. Pogreška dopuštenja sprema se kao zasebno stanje, nikad kao prazan rezultat. Račun koji nije moguće pročitati označava se kao nepročitan svaki dan.
- Ograničenja na svakom upozorenju. Zeleno nikada ne smije značiti „ne možemo to vidjeti”. URL-ovi Shopping proizvoda nalaze se u alatu Merchant Center, a ne u Ads API-ju. Dynamic Search Ads odabiru svoju odredišnu stranicu u trenutku posluživanja. U našem vlastitom skeniranju, četiri od deset aktivnih Meta oglasa imala su vezu pohranjenu unutar objave na stranici. Kataloški oglasi pohranjuju svoje veze u katalogu. Čitanje objava na stranici ili kataloga treba dopuštenja koja naša aplikacija nema. Google ne prikazuje odbijanja kartica. Status dvofaktorske autentifikacije korisnika klijenta ostaje nečitljiv na objema platformama. Mi umjesto toga provodimo dvofaktorsku autentifikaciju u postavkama računa.
Preuzmi kontrolni popis i upute za implementaciju
Jedna datoteka. Sigurnosni kontrolni popis za pregled s osobama koje administriraju tvoje Google Ads i Meta račune. Upute za implementaciju za gore opisani monitor. Upute sadrže primjere upita za Google Ads API v23, čitanja za Meta API v24, predložena pravila detekcije i poznate praznine u pokrivenosti. Implementator ih mora prilagoditi i testirati za tvoje račune. Ostavi svoj e-mail i datoteka je tvoja.
Jedna datoteka, jedna lista. Pišem samo kad ima što za pročitati.
Moj Google Ads račun je hakiran. Što prvo trebam napraviti?
Upotrijebi pouzdani uređaj i izoliraj svako računalo za koje sumnjaš da je zaraženo. Odmah prijavi proboj platformi Google Ads putem obrasca za kompromitirane račune. Ako i dalje možeš otvoriti račun, pauziraj neovlaštene kampanje. Zadrži povijest promjena i stranice za naplatu kao dokaz. Ukloni potvrđene neovlaštene korisnike i veze upravitelja pod Access and security. Ako nemaš pristup, pokreni oporavak Google računa. Poništi lozinku, pregledaj prijavljene uređaje i opozovi pristup trećih strana koji ne prepoznaješ. Provjeri e-mail i telefon za oporavak te načine plaćanja. Prijavi neovlaštene troškove izdavatelju kartice.
Kako mogu znati je li moj Facebook oglasni račun ili Business Manager hakiran?
Istraži svakog nepoznatog korisnika ili partnera. Istraži svako uklanjanje administratora koje nisi zatražio. Istraži svaku promjenu financiranja i svaku kampanju koju nisi odobrio. Jedna od tih stvari dovoljna je za reakciju. Nemoj čekati cijeli niz događaja ili Metinu oznaku kompromitiranog računa. Osiguraj kompromitirani Facebook račun putem Facebookovog postupka za oporavak hakiranog računa. Kontaktiraj Metinu poslovnu podršku u vezi s pogođenim elementima. Ako i dalje imaš pristup, pauziraj neovlaštene oglase i ukloni potvrđeni neovlašteni pristup. Zatraži od administratora da pregleda integracije i opozove pogođene tokene sistemskih korisnika.
Zašto dvofaktorska autentifikacija nije zaustavila napad?
Ukradena sesija omogućuje napadaču djelovanje bez nove prijave. Zbog toga se ne traži drugi faktor. Phishing proxy prosljeđuje tvoju lozinku i jednokratni kod na pravu stranicu. Proxy zatim zadržava sesiju koju stvara prava stranica. Pristupni ključevi i hardverski sigurnosni ključevi otporni su na taj oblik krađe identiteta. Ti ključevi ne mogu zaštititi sesiju koja je već ukradena sa zaraženog uređaja. Odobravanje napadačevog zahtjeva za pristup zaseban je propust. Tim odobrenjem ti ovlašćuješ napadača.
Mogu li Google Ads i Meta API-ji prijaviti status dvofaktorske autentifikacije korisnika?
Google Ads API v23 ne prikazuje status potvrde u dva koraka po korisniku. Google Ads API v23 ne prikazuje ni zahtjev na razini računa. Meta prikazuje polja dvofaktorske autentifikacije za tvrtku koju si ovlašten administrirati. U našem testiranju pristupa partnera, API odgovor za klijentovu tvrtku nije imao ta polja i vratio je prazan popis korisnika. Tretiraj polje koje nedostaje kao nepoznato, a ne kao onemogućeno. Provjeri zahtjeve klijenata u postavkama.
Koliko često agencija treba provjeravati tko ima pristup oglasnim računima klijenata?
Odaberi interval prema potencijalnoj potrošnji, riziku pristupa i brzini reakcije. U javno opisanim slučajevima napadači su u jednom danu potrošili desetke tisuća dolara s preuzetih računa. Noćna provjera ostavlja dug prozor na računu s visokom potrošnjom. Mi provjeravamo svaki račun klijenta svakih 30 minuta. Tjedni ili kvartalni pregled pristupa je provjera pri odlasku klijenta. On ne otkriva preuzimanje u tijeku. Između pregleda zato koristi sigurnosne obavijesti i obavijesti o naplati na platformama.
Troši li provjera svakih 30 minuta kvotu za Google Ads API?
Troši kvotu. Mali portfelj ne dolazi ni blizu ograničenja. Brojke u nastavku pretpostavljaju da se svako čitanje izvršava svakih 30 minuta. U intervalu od 30 minuta, svako od četiri čitanja pristupa izvršava se 48 puta dnevno. Uz sedam dnevnih čitanja odredišta i čitanje događaja promjene svakih 30 minuta, to je 247 operacija po računu dnevno. To je broj prije ciljanih ponovnih čitanja, ponovnih pokušaja i bilo kojeg drugog alata. Osnovni pristup dopušta 15.000 operacija u pomičnom razdoblju od 24 sata. Pri 247 operacija po računu to pokriva najviše 60 računa. Veći portfelj treba duži interval ili standardni pristup. Provjeri razinu pristupa svog Google Cloud projekta i rezerviraj kapacitet za cjelokupno radno opterećenje.
Započni s jednim računom. Ručno provjeri njegov popis korisnika i odobrena odredišta. Zatim testiraj detekciju, neuspjelo čitanje i isporuku upozorenja. Tek nakon toga proširi monitor na ostale račune.
