Kort fortalt: Annoncekonti hackes ikke ved at gætte adgangskoden. De dokumenterede metoder er en stjålet browsersession, en phishing-proxy, der videresender adgangskoden og engangskoden, et falsk manager-link eller en partneranmodning, et stjålet API-token og en adgang, der aldrig blev fjernet. Hos Lynt kører vi derfor et tjek hvert 30. minut på alle vores kunders Google Ads- og Meta-konti. Vi tjekker, om kontoen er aktiv. Vi tjekker, om betalingsmetoden eller forbrugsgrænsen er ændret. Vi tjekker, om annoncerne peger på kundens domæne. Vi tjekker, om nye brugere har fået adgang. Hver ændring sendes til Slack og til en intern side. Her godkender eller afviser den ansvarlige person ændringen. Du kan downloade implementeringsbriefet.
Angribere gætter ikke adgangskoder til Google Ads eller Facebook-annoncekonti. Sikkerhedsrapporter fra 2025 og 2026 beskriver fem metoder. Ingen af metoderne udnytter en svag adgangskode.
- En stjålet browsersession. Malware af typen infostealer kopierer cookies fra en browser, hvor brugeren er logget ind. Recorded Future indekserede i 2025 276 millioner loginoplysninger, der omfattede en aktiv sessionscookie. En cookie kræver ingen adgangskode og ingen totrinsgodkendelse (Recorded Future). Angribere spreder Ducktail gennem falske jobtilbud inden for markedsføring. Ducktail er en malwarefamilie målrettet Facebook Business-konti (WithSecure).
- En phishing-proxy, der kommer forbi totrinsgodkendelsen. Offeret indtaster den rigtige adgangskode på det, der ligner den rigtige side, og godkender anmodningen. Proxyen gemmer derefter den session, som den rigtige side opretter. Ved midten af 2025 stod et enkelt lejet phishing-kit bag 62 % af de phishing-forsøg, Microsoft blokerede (Microsoft). Kriminelle har købt Google Search-annoncer på søgetermen „Google Ads“ for at sende ofre til en sådan proxy (Malwarebytes).
- En falsk invitation. På Meta indsender angriberen en partneranmodning. Lokkemidlet står i virksomhedsnavnet, mens selve e-mailen er en ægte besked fra Meta (Huntress). På Google sender angriberen en falsk managerinvitation, der fører offeret til en loginside, som ligner den ægte. Bureauer har på denne måde mistet hele managerkonti, selv om totrinsgodkendelse var slået til (Search Engine Land).
- Et stjålet API-token eller en apptilladelse. OAuth-tilladelser og Meta-systembrugertokens fungerer fortsat efter en nulstilling af adgangskoden. De holder først op med at fungere, når en administrator tilbagekalder dem.
- Adgang, som ingen fjernede. Freelanceren fra for to år siden, det tidligere bureau eller kundens tidligere marketingchef har stadig adgang.
Når angriberne først er inde, tilføjer de en administrator og knytter kontoen til en overordnet konto. Derefter ændrer de betalingsmetoden eller forbrugsgrænsen. De starter kampagner og lader annoncerne pege på et domæne, der ikke tilhører kunden. Mimecast registrerede alene i anden halvdel af 2025 1,86 millioner detektioner af annoncekontotyveri. En stjålet konto bliver solgt for et par hundrede dollars (Mimecast). Bureauerne i de offentliggjorte sager opdagede selv tyveriet, ofte næste morgen.
Hvorfor vi byggede et 30-minutters tjek
Vi administrerer kundekonti på Google Ads og Meta. Vores tidligere tjek kørte hver 2,5 time og kontrollerede kun brugeradgangen. I de offentliggjorte sager var pengene væk inden for en dag. Brugeradgang er kun ét af de forhold, der ændrer sig, når en konto bliver overtaget. Tjekket kører nu hvert 30. minut og omfatter mere. Det kontrollerer kontostatus, betalingsmetode, forbrugsgrænse, annoncedestinationer og brugeradgang.
Denne version gik live i september 2026. Systemet henter data fra alle konti, vi administrerer på de to platforme, hvert 30. minut. Listen over, hvem der har adgang i Google Ads, læses endnu oftere, nemlig hvert 18. minut. Én gang om dagen genlæser systemet også hver konto fuldt ud og dækker de data, som 30-minutters-kørslerne ikke rører ved. Softwaren foretager ingen ændringer på nogen af platformene. Et menneske træffer beslutningerne.
Hvad det tjekker
| Tjek | Google Ads | Meta |
|---|---|---|
| Er kontoen aktiv? | Vi læser kontostatus via vores managerkonto. Mulige statusser er suspenderet, annulleret eller lukket. API'et giver ingen grund til en suspendering, og advarslen oplyser om denne begrænsning. | Vi læser kontostatus og årsagen til deaktivering. Det omfatter Metas egen markering af kontoen som kompromitteret. |
| Er der et betalingsproblem? | Vi registrerer, når kontobudgettet er opbrugt på fakturerede konti. API'et viser hverken et afvist kort eller en forudbetalt saldo. Advarslen oplyser om denne begrænsning. | Vi registrerer ændringer af finansieringskilden, og om forbrugsgrænsen bliver ændret eller nulstillet. Vi registrerer også, hvis kontoen er markeret som uafregnet på grund af en ubetalt saldo. |
| Peger annoncerne stadig på kundens domæne? | Hvert 30. minut læser vi ændringshændelser og dagens rapport over landingssider. Tjekket genlæser ændrede elementer. En daglig gennemgang dækker konfigurerede URL'er og sporingsskabeloner på alle niveauer. | Hvert 30. minut læser vi links i alle aktive kreativer. En fuld kontrol kører dagligt. Den fanger enhver ændring af URL-parametre. |
| Har nogen ny fået adgang? | For hver bruger læser vi rollen, oprettelsesdatoen og navnet på den person, der inviterede brugeren. Vi læser også afventende invitationer. Vi læser managerlinks i alle statusser. Vi ser en afventende anmodning, før kunden accepterer den. Vi kontrollerer vores egne managerkonti på samme måde. | I aktivitetsloggen ser vi, hvilke brugere der er føjet til eller fjernet fra kontoen. Vi ser også, hvilke partnervirksomheder der er tilføjet eller fjernet. Daglige tjek dækker vores egne Business Manager-brugere, systembrugere og indstillinger for totrinsgodkendelse. |
| Mistede vi vores egen adgang? | En konto, der holder op med at svare, markeres som ulæselig, indtil den svarer igen. | Når vi mister en tilladelse, udløser det en advarsel. Hvis et token er ugyldigt, mislykkes kørslen, og fejlen bliver rapporteret. |
Systemet sammenligner hver læsning med det tidligere øjebliksbillede. Hver tilføjet, fjernet eller ændret række registreres som et fund. En tilladelsesfejl gemmes som en særskilt tilstand for den enkelte konto og aldrig som et tomt resultat. Den daglige oversigt bliver rød, når et tjek ikke har kørt inden for sit planlagte interval.
Sådan arbejder teamet med det
- Relaterede fund på en konto samles i én hændelse. Hændelsen sendes til Slack som en direkte besked til den person, der skal gennemgå sagen. Den bliver også slået op i teamkanalen. Både den direkte besked og opslaget nævner kunden og specialisten, der passer kontoen. Oplysningerne står på to linjer sammen med et link. Systemet gentager ikke advarslen, medmindre hændelsen eskalerer.
- Linket åbner en intern side, som kun kan tilgås fra vores netværk. Den viser kontoen og den ændring, vi har registreret, sammen med den tidligere og den nye tilstand. Den viser også, hvornår vi opdagede ændringen, og hvad der skal kontrolleres.
- Når du godkender en hændelse, registrerer systemet det præcise omfang. Godkendelsen angiver præcis, hvad der blev tilladt, for eksempel en bestemt bruger med en bestemt rolle eller et bestemt domæne på en bestemt konto. En senere ændring kræver en ny gennemgang. Hvis du afviser en hændelse, forbliver den åben som uautoriseret. Når en ny læsning hverken kan bekræfte eller afkræfte en hændelse, lukker den ansvarlige medarbejder hændelsen med en note.
- Et menneske løser problemet i Google Ads eller Meta. Hændelsen lukkes, når den næste komplette læsning bekræfter, at den uautoriserede tilstand er fjernet.
- Statussiden viser den ansvarlige specialist for hver konto. Den viser den seneste vellykkede læsning, afventende beslutninger og de data, vi ikke kan læse. Klokken 07.00 sendes en oversigt på to linjer for begge platforme til Slack.
Hvorfor disse valg
- Hvert 30. minut. API-kvoten fastsætter dette interval. Hver læsning og forbruget fra vores andre værktøjer tæller med i den samme kvote. Systemet tæller selv sine operationer med i kvoten og rapporterer forsinkede kørsler.
- Kun læseadgang med menneskelig godkendelse. En ny bruger eller et nyt domæne skyldes ofte en ændring fra en specialist eller et nyt bureau, kunden har hyret. Men det kan lige så vel være et tegn på en kontoovertagelse. Systemet kan ikke skelne mellem de to. Den ansvarlige kan normalt skelne mellem dem inden for en time.
- Fejl skjules aldrig. Et overvågningssystem, der går ned uden at give besked, er værre end slet ingen overvågning. Det får teamet til at holde op med selv at holde øje. Hvis et token er udløbet, mislykkes kørslen, og fejlen bliver rapporteret. En tilladelsesfejl gemmes som en særskilt tilstand og aldrig som et tomt resultat. En konto, der ikke kan læses, markeres hver dag som en konto, vi ikke har kunnet læse.
- Begrænsninger i hver advarsel. Grøn må aldrig betyde „vi kan ikke se det“. URL’erne for Shopping-produkter ligger i Merchant Center, ikke i Ads API’et. Dynamic Search Ads vælger først landingssiden, når annoncen vises. I vores egen scanning havde fire ud af ti aktive Meta-annoncer deres link gemt i et sideopslag, mens katalogannoncernes links ligger i kataloget. Læsning af sideopslag eller kataloget kræver tilladelser, som vores app ikke har. Google viser ikke afviste kort. Status for totrinsgodkendelse hos kundernes brugere kan fortsat ikke læses på nogen af platformene. Vi håndhæver i stedet totrinsgodkendelse via kontoindstillingerne.
Download tjeklisten og implementeringsbriefet
Du får det hele i én fil. Filen indeholder en sikkerhedstjekliste, som du kan gennemgå med de personer, der administrerer dine Google Ads- og Meta-konti. Den indeholder også et implementeringsbrief til overvågningen ovenfor. Implementeringsbriefet indeholder eksempler på forespørgsler til Google Ads API v23, læsninger i Meta API v24, forslag til detektionsregler og de kendte dækningshuller. Den, der implementerer løsningen, skal tilpasse og teste den på dine konti. Indtast din e-mailadresse, og filen er din.
Én fil, én liste. Jeg skriver kun, når der er noget værd at læse.
Min Google Ads-konto er blevet hacket. Hvad gør jeg først?
Brug en enhed, du har tillid til, og isoler alle computere, du mistænker for at være inficeret. Anmeld straks angrebet til Google Ads via deres formular til kompromitterede konti. Hvis du stadig har adgang til kontoen, skal du sætte uautoriserede kampagner på pause. Gem ændringshistorikken og faktureringssiderne som dokumentation. Fjern brugere og managerlinks, som du har bekræftet er uautoriserede, under Adgang og sikkerhed. Hvis du er låst ude, skal du starte gendannelsen af din Google-konto. Nulstil adgangskoden, gennemgå indloggede enheder og tilbagekald tredjepartsadgang, du ikke genkender. Tjek e-mailadressen og telefonnummeret til gendannelse samt betalingsmetoderne. Rapportér uautoriserede debiteringer til din kortudsteder.
Hvordan ved jeg, om min Facebook-annoncekonto eller Business Manager er blevet hacket?
Undersøg alle ukendte brugere og partnere samt alle administratorer, der er blevet fjernet, uden at du har bedt om det. Undersøg også alle ændringer af finansieringen og kampagner, du ikke har godkendt. Et enkelt af disse tegn er nok til, at du bør handle. Vent ikke på hele forløbet eller på, at Meta markerer kontoen som kompromitteret. Sikr den kompromitterede Facebook-konto via Facebooks side til gendannelse af hackede konti. Kontakt Metas support til virksomheder om de berørte aktiver. Hvis du stadig har adgang, skal du sætte uautoriserede annoncer på pause og fjerne den adgang, som du har bekræftet er uautoriseret. Bed virksomhedsadministratoren om at gennemgå integrationer og tilbagekalde de berørte systembrugertokens.
Hvorfor stoppede totrinsgodkendelse det ikke?
Med en stjålet session kan en angriber handle uden at logge ind igen. Derfor bliver angriberen ikke bedt om en anden faktor. En phishing-proxy videresender din adgangskode og engangskode til den rigtige side. Proxyen gemmer derefter den session, som den rigtige side opretter. Adgangsnøgler og hardwaresikkerhedsnøgler beskytter mod denne type phishing. De kan dog ikke beskytte en session, der allerede er stjålet fra en inficeret enhed. Hvis du godkender en angribers adgangsanmodning, er der tale om en anden type fejl. Så har du selv givet angriberen adgang.
Kan Google Ads API og Meta API vise brugernes status for totrinsgodkendelse?
Google Ads API v23 viser hverken status for totrinsgodkendelse for den enkelte bruger eller kravet om totrinsgodkendelse på kontoniveau. Meta viser felter om totrinsgodkendelse for en virksomhed, du er autoriseret til at administrere. I vores test af partneradgang indeholdt API-svaret for en kundes virksomhed ikke disse felter og returnerede en tom brugerliste. Hvis et felt mangler, skal du betragte status som ukendt, ikke som deaktiveret. Kontrollér kravene til kundens konto i indstillingerne.
Hvor ofte bør et bureau tjekke, hvem der har adgang til kundernes annoncekonti?
Vælg intervallet ud fra det potentielle forbrug, adgangsrisikoen og hvor hurtigt nogen kan reagere. I de offentliggjorte sager brugte angriberne titusindvis af dollars på en enkelt dag. Med et natligt tjek går der derfor lang tid mellem kontrollerne af en konto med højt forbrug. Vi kontrollerer hver kundekonto hvert 30. minut. En ugentlig eller kvartalsvis adgangsgennemgang er et tjek i forbindelse med offboarding. Den opdager ikke en igangværende kontoovertagelse. Brug derfor platformenes sikkerheds- og faktureringsmeddelelser mellem gennemgangene.
Bliver kvoten i Google Ads API overskredet, hvis vi tjekker hvert 30. minut?
En lille portefølje kommer ikke i nærheden af grænsen. Beregningerne nedenfor antager, at hver læsning kører hvert 30. minut. Med et interval på 30 minutter kører hver af de fire læsninger af adgangsdata 48 gange om dagen. Med syv daglige læsninger af destinationsdata og en læsning af ændringshændelser hvert 30. minut bliver det til 247 operationer per konto per dag. Det er før målrettede genlæsninger, genforsøg og de operationer, som andre værktøjer bruger. Basic-adgang tillader 15.000 operationer i et rullende døgn. Med 247 operationer per konto rækker kvoten til højst 60 konti. En større portefølje kræver et længere interval eller Standard-adgang. Tjek, hvilket adgangsniveau dit Google Cloud-projekt har, og reservér kapacitet til hele arbejdsbyrden.
Start med én konto. Kontrollér manuelt kontoens brugerliste og godkendte destinationer. Test derefter detektionen, en mislykket læsning og leveringen af advarsler, før du udvider overvågningen til resten af kontiene.
