Kort sagt: Annonskonton hackas inte genom att gissa lösenordet. De dokumenterade intrångsmetoderna är en stulen webbläsarsession, en nätfiskeproxy som vidarebefordrar lösenordet och engångskoden, en falsk inbjudan att länka ett förvaltarkonto eller en falsk begäran om partneråtkomst, en stulen API-token och åtkomst som aldrig återkallades. På Lynt kontrollerar vi därför varje kunds Google Ads- och Meta-konto var 30:e minut. Vi kontrollerar om kontot fortfarande är aktivt. Vi kontrollerar om betalningsmetoden eller utgiftsgränsen har ändrats. Vi kontrollerar om annonserna fortfarande pekar på kundens domän. Vi kontrollerar om någon ny har fått åtkomst. Varje ändring skickas till Slack och till en intern sida. Där godkänner eller avvisar den ansvariga personen ändringen. Implementeringsunderlaget kan laddas ner.
Angripare tar sig inte in i Google Ads- eller Facebook-annonskonton genom att gissa lösenord. Säkerhetsrapporter från 2025 och 2026 beskriver fem vägar in. Lösenordet är inte den svaga punkten i någon av dem.
- En stulen webbläsarsession. Skadeprogram av typen infostealer kopierar cookies från en inloggad webbläsare. Recorded Future indexerade 276 miljoner inloggningsuppgifter med en aktiv sessionscookie under 2025. En sessionscookie kräver varken lösenord eller en andra autentiseringsfaktor (Recorded Future). Angripare sprider Ducktail genom falska jobberbjudanden inom marknadsföring. Ducktail är en familj av skadeprogram som har utvecklats för Facebook Business-konton (WithSecure).
- En nätfiskeproxy som klarar tvåfaktorskontrollen. Offret skriver in sitt riktiga lösenord på vad som ser ut som den riktiga sidan och godkänner inloggningsbegäran. Proxyn behåller sedan den session som den riktiga webbplatsen skapar. I mitten av 2025 låg ett enda hyrt nätfiskepaket bakom 62 procent av de nätfiskeförsök som Microsoft blockerade (Microsoft). Brottslingar har köpt annonser i Googles söknätverk för sökfrågan ”Google Ads” för att leda offren till en sådan proxy (Malwarebytes).
- En falsk inbjudan. På Meta skickar angriparen en partnerförfrågan. Angriparen lägger det vilseledande budskapet i företagsnamnet, medan själva e-postmeddelandet är ett äkta utskick från Meta (Huntress). I Google Ads skickar angriparen en falsk inbjudan att koppla ett förvaltarkonto, och länken leder offret till en snarlik inloggningssida. På det här sättet förlorade byråer hela förvaltarkonton trots att tvåfaktorsautentisering var aktiverad (Search Engine Land).
- En stulen API-token eller appbehörighet. OAuth-behörigheter och API-token för Metas systemanvändare fortsätter att fungera efter en lösenordsåterställning. De slutar först fungera när en administratör återkallar dem.
- Åtkomst som ingen återkallade. Det kan vara frilansaren från två år tillbaka, den tidigare byrån eller kundens förra marknadschef.
Väl inne lägger angriparen till en administratör och kopplar kontot till ett överordnat konto. Därefter ändrar angriparen betalningsmetoden eller utgiftsgränsen. Angriparen startar kampanjer och pekar annonserna mot en domän som inte är kundens. Mimecast registrerade 1,86 miljoner detekteringar av annonskontostölder enbart under andra halvåret 2025. Ett stulet konto säljs för några hundra dollar (Mimecast). I de publicerade fallen upptäckte byråerna stölden själva, ofta morgonen därpå.
Varför vi byggde en 30-minuterskontroll
Vi hanterar kundkonton på Google Ads och Meta. Vår tidigare kontroll kördes var 2,5 timme och tittade bara på användaråtkomst. I dokumenterade fall försvann pengarna inom ett dygn. Åtkomsten är bara en av flera saker som kan ändras när ett konto kapas. Kontrollen körs därför nu var 30:e minut och omfattar kontostatus, betalningsmetod, utgiftsgräns, annonsdestinationer och användaråtkomst.
Den här versionen togs i drift i september 2026. Kontrollen läser av alla konton vi hanterar på båda plattformarna var 30:e minut. Åtkomstlistan i Google Ads läses ännu oftare, var 18:e minut. En gång om dagen läser övervakaren också av varje konto i sin helhet. Den täcker in de data som 30-minuterskörningarna inte rör. Programvaran ändrar ingenting i någon av plattformarna. En människa fattar besluten.
Vad den kontrollerar
| Kontroll | Google Ads | Meta |
|---|---|---|
| Är kontot aktivt? | Kontostatus läses via vårt förvaltarkonto. Kontot kan bland annat vara avstängt, avslutat eller stängt. API:et anger inte varför ett konto har stängts av. Den begränsningen framgår av larmet. | Vi läser kontostatus och orsaken till en inaktivering. Vi läser även Metas egen flagga för komprometterade konton. |
| Finns det ett betalningsproblem? | På konton med månadsfakturering ser vi om kontobudgeten är förbrukad. API:et visar varken ett nekat kort eller ett förbetalt saldo. Larmet anger den begränsningen. | Finansieringskällan har ändrats. Utgiftsgränsen har ändrats eller återställts. Kontot är markerat som obetalt eftersom det finns ett utestående saldo. |
| Pekar annonserna fortfarande på kundens domän? | Var 30:e minut hämtar kontrollen ändringshändelser och dagens målsidesrapport. Kontrollen läser in ändrade objekt på nytt. Den dagliga genomgången kontrollerar konfigurerade webbadresser och spårningsmallar på alla nivåer. | Var 30:e minut kontrolleras länkarna i alla aktiva annonsmaterial. En fullständig granskning körs dagligen. Den fångar upp alla ändringar av URL-parametrar. |
| Fick någon ny person åtkomst? | För varje användare läser vi rollen, skapandedatumet och vem som skickade inbjudan. Vi kontrollerar också väntande inbjudningar och länkar till förvaltarkonton oavsett status. En väntande förfrågan syns innan kunden accepterar. Vi kontrollerar våra egna förvaltarkonton på samma sätt. | Aktivitetsloggen visar vilka användare som lades till eller togs bort från kontot. Vi ser också vilka partnerföretag som har lagts till eller tagits bort. Dagliga kontroller omfattar våra egna Business Manager-användare, systemanvändare och tvåfaktorsinställningar. |
| Förlorade vi vår egen åtkomst? | Ett konto som slutar svara markeras som oläsbart tills det svarar igen. | Om en behörighet försvinner utlöses ett larm. En ogiltig token gör att körningen misslyckas och felet rapporteras. |
Systemet jämför varje avläsning med den föregående ögonblicksbilden. Varje tillagd, borttagen eller ändrad rad registreras som ett fynd. Ett behörighetsfel lagras som ett eget tillstånd för kontot. Felet lagras aldrig som ett tomt resultat. Den dagliga sammanfattningen blir röd när en kontroll inte har körts inom sitt schemalagda intervall.
Hur teamet arbetar med övervakningen
- Relaterade fynd på ett konto slås ihop till en incident. Incidenten skickas till Slack som ett direktmeddelande till granskaren och publiceras som en post i teamkanalen. I både direktmeddelandet och posten står kunden och den ansvariga specialisten på två rader tillsammans med en länk. Nya larm skickas först om incidenten eskalerar.
- Länken öppnar en intern sida som bara kan nås i vårt nätverk. Där ser du vilket konto det gäller, vad som ändrades och både det tidigare och det nya tillståndet. Sidan visar också när vi såg ändringen och vad som ska verifieras.
- När granskaren godkänner en händelse registrerar systemet exakt vad godkännandet omfattar. I godkännandet står exakt vad som tilläts, till exempel en viss användare med en viss roll eller en viss domän på ett visst konto. En senare ändring kräver en ny granskning. Om granskaren avvisar händelsen förblir incidenten öppen och markerad som obehörig. När en ny avläsning varken kan bekräfta eller motbevisa en händelse stänger granskaren den med ”Avsluta med en anteckning”.
- En människa åtgärdar problemet i Google Ads eller Meta. Incidenten stängs när nästa fullständiga avläsning bekräftar att problemet har åtgärdats.
- Statussidan anger vilken specialist som ansvarar för varje konto. Den visar den senaste lyckade avläsningen, väntande beslut och vilka data vi inte kan läsa. En gemensam sammanfattning på två rader för båda plattformarna skickas till Slack klockan 07:00.
Varför vi gjorde dessa val
- Var 30:e minut. API-kvoten bestämmer intervallet. Både avläsningarna och API-anropen från våra andra verktyg räknas mot samma kvot. Övervakaren räknar hur många av kvotens operationer den själv förbrukar och rapporterar varje försenad körning.
- Endast läsning med mänskligt godkännande. En ny användare eller domän kommer ofta från en ändring som en specialist har gjort eller från kundens nya byrå. Det kan lika gärna vara en kapning. Övervakaren kan inte skilja dem åt. Den ansvariga personen kan avgöra vad som är legitimt, vanligtvis inom en timme.
- Fel döljs aldrig. En övervakare som slutar fungera utan att larma är sämre än ingen övervakare alls. Då slutar teamet att hålla uppsikt. En utgången token gör att körningen misslyckas och felet rapporteras. Ett behörighetsfel sparas som ett eget tillstånd, aldrig som ett tomt resultat. Ett konto som inte går att läsa markeras varje dag som ej avläst.
- Tydliga begränsningar i varje larm. Grönt får aldrig betyda ”vi kan inte se det”. Produktwebbadresser för Shopping finns i Merchant Center, inte i Ads API. Dynamic Search Ads väljer sin målsida vid visningstillfället. I vår egen skanning fanns länken i ett sidinlägg för fyra av tio aktiva Meta-annonser. Katalogannonser lagrar i stället länken i katalogen. Att läsa sidinlägg eller katalogen kräver behörigheter som vår app inte har. Google visar inte nekade kort. Vi kan fortfarande inte läsa tvåfaktorstatus för kundernas användare på någon av plattformarna. Vi kräver i stället tvåfaktorsautentisering i kontoinställningarna.
Ladda ner checklistan och implementeringsunderlaget
Du får en fil med en säkerhetschecklista som du kan gå igenom med dem som administrerar dina Google Ads- och Meta-konton. Filen innehåller också ett implementeringsunderlag för övervakaren ovan, med exempel på frågor mot Google Ads API v23 och läsningar via Meta API v24. Där finns även förslag på detekteringsregler och kända begränsningar i täckningen. Den som implementerar övervakningen måste anpassa och testa den för dina konton. Lämna din e-postadress så är filen din.
En fil, en lista. Jag skriver bara när det finns något värt att läsa.
Mitt Google Ads-konto har blivit hackat. Vad gör jag först?
Använd en betrodd enhet. Isolera alla datorer som du misstänker är infekterade. Rapportera intrånget direkt till Google Ads via formuläret för komprometterade konton. Om du fortfarande kan öppna kontot ska du pausa obehöriga kampanjer, spara ändringshistoriken och faktureringssidorna som bevis samt ta bort bekräftade obehöriga användare och länkar till förvaltarkonton under Åtkomst och säkerhet. Om du är utelåst ska du i stället starta återställningen av Google-kontot. Återställ lösenordet. Gå igenom inloggade enheter och återkalla tredjepartsåtkomst som du inte känner igen. Kontrollera e-postadressen och telefonnumret för återställning samt betalningsmetoderna. Rapportera obehöriga debiteringar till din kortutgivare.
Hur vet jag om mitt Facebook-annonskonto eller Business Manager har blivit hackat?
Utred alla användare och partner som du inte känner igen. Kontrollera om en administratör har tagits bort utan att du har begärt det. Granska alla ändringar av finansieringen och alla kampanjer som du inte har godkänt. Du ska agera redan om du hittar en obekant användare eller partner, en administratör som tagits bort utan din begäran, en ändring av finansieringen eller en obehörig kampanj. Vänta inte på en fullständig händelsekedja eller på Metas flagga för komprometterade konton. Säkra det komprometterade Facebook-kontot via Facebooks återställning för hackade konton. Kontakta Metas support för företag om de berörda tillgångarna. Om du fortfarande har åtkomst ska du pausa obehöriga annonser och ta bort åtkomst som du har bekräftat är obehörig. Be företagsadministratören granska integrationerna och återkalla berörda token för systemanvändare.
Varför stoppade inte tvåfaktorsautentiseringen intrånget?
En stulen session gör att en angripare kan agera utan att logga in igen. Då begär webbplatsen inte en andra autentiseringsfaktor. En nätfiskeproxy vidarebefordrar ditt lösenord och din engångskod till den riktiga webbplatsen och behåller den session som webbplatsen skapar. Lösenordsnycklar och fysiska säkerhetsnycklar står emot den typen av nätfiske. De kan däremot inte skydda en session som redan har stulits från en infekterad enhet. Att godkänna en angripares begäran om åtkomst är ett separat misstag. Då har du gett angriparen behörighet.
Kan Google Ads API och Meta Marketing API rapportera användares tvåfaktorstatus?
Google Ads API v23 visar varken enskilda användares status för tvåstegsverifiering eller om kravet är aktiverat för kontot. Meta API ger tillgång till fält om tvåfaktorsautentisering för företag som du har behörighet att administrera. När vi testade partneråtkomst för en kund saknade API-svaret för kundens företag de här fälten och innehöll en tom användarlista. Om ett fält saknas är statusen okänd, inte inaktiverad. Kontrollera därför kundens krav i inställningarna.
Hur ofta bör en byrå kontrollera vem som har åtkomst till kunders annonskonton?
Välj intervall utifrån hur mycket kontot kan spendera, risken för obehörig åtkomst och hur snabbt någon kan agera. I dokumenterade fall spenderade angriparna tiotusentals dollar på ett enda dygn. En nattlig kontroll innebär därför att konton med stora annonsutgifter inte kontrolleras på länge. Vi läser av varje kundkonto var 30:e minut. En åtkomstgranskning varje vecka eller kvartal är till för att kontrollera åtkomsten vid avslut. Den upptäcker inte en pågående kapning, så använd plattformarnas säkerhets- och faktureringsmeddelanden mellan granskningarna.
Förbrukar kontroller var 30:e minut hela kvoten för Google Ads API?
En liten portfölj kommer inte ens i närheten av gränsen. Uträkningarna nedan förutsätter att varje avläsning körs var 30:e minut. Med kontroller var 30:e minut görs var och en av de fyra åtkomstläsningarna 48 gånger per dygn. Därtill kommer sju dagliga läsningar av annonsdestinationer och en läsning av ändringshändelser var 30:e minut. Totalt blir det 247 operationer per konto och dygn före riktade omläsningar, nya försök och andra verktyg. Grundläggande åtkomst tillåter 15 000 operationer under en rullande 24-timmarsperiod. Med 247 operationer per konto räcker den kvoten till högst 60 konton. En större portfölj kräver längre intervall mellan kontrollerna eller standardåtkomst. Kontrollera vilken åtkomstnivå ditt Google Cloud-projekt har. Reservera kapacitet för hela arbetsbelastningen.
Börja med ett konto. Kontrollera kontots användarlista och godkända annonsdestinationer manuellt. Testa sedan att systemet upptäcker en ändring, registrerar en misslyckad avläsning och levererar larmet. Utöka inte övervakningen till resten av kontona förrän testerna fungerar.
