Google Calendar-phishing kringgår MFA med reverse proxy
En sofistikerad kampanj utnyttjar kalendernbjudningar och Googles egna omdirigerare för att kapra aktiva sessioner. Angriparna använder ett reverse proxy som vidarebefordrar tvåfaktorskoder i realtid, vilket gör traditionellt MFA-försvar tandlöst.
AI-genererad AI-kontrollerad mot källor
kontroll mot källor:4 källor lästa4 uppgifter kontrollerade0 utan stöd i källorna0 omskrivningar
Kontrollen visar om uppgifter finns i de lästa källorna. Den är ingen oberoende bekräftelse.
Texten är skriven av AI-agenter utifrån publika källor och publiceras utan att en människa läser den först. Uppgifter kan vara fel, så jämför gärna med källorna. Så arbetar vi
Ett av de mest betrodda verktygen i den moderna arbetsplatsens arsenal kan vara farligare än vi trott. Sedan mitten av augusti 2026 har en organiserad phishing-grupp drabbat företag genom att utnyttja Google Calendar-inbjudningar som ingresspunkt för att stjäla aktiva användarsessioner 1. Det handlar inte om en sårbarhet i Googles kod, utan om en skicklig kombination av social ingenjörskonst och teknisk manipulation som kringgår tvåfaktorsautentisering (MFA) genom att lura både användare och säkerhetssystem. Säkerhetsbolaget Material Security har döpt kampanjen till Operation CloudFire och avslöjat hur angriparna bygger kedjor av legitima komponenter för att dölja sina avsikter.
Vad som hände
Angreppet inleds med ett e-postmeddelande eller, mer ofta, en kalenderinbjudning. Beten är vardagliga: aviseringar om röstmeddelanden, inbetalningsuppmaningar eller officiella handlingar. Länkarna i meddelandena pekar initialt på Googles egna omdirigeringsdomäner, som /url eller share.google, vilket får dem att framstå som helt ofarliga för traditionella spamfilter och reputationskontroller.
När mottagaren klickar möts hen av en utmaning från Cloudflare Turnstile, ibland den genuina widgeten serverad från Cloudflares infrastruktur. Efter att ha passerat denna kontroll konstrueras den faktiska inloggningssidan dynamiskt i webbläsaren via JavaScript. Det finns ingen statisk hemsida att skanna; sidan existerar bara när en användare är på plats.
Här kommer kärnan i angreppet: ett ramverk som heter Nyasher, vilket fungerar som en live reverse proxy. När offret matar in lösenord och godkänner sin MFA-prompt (oavsett om det gäller SMS-kod, authenticator-app eller Googles "Tap-Yes"-matchning), vidarebefordras denna interaktion i realtid till Googles autentiseringsserver via angriparens proxy. Angriparen agerar som en osynlig mellanhand, så kallad Adversary-in-the-Middle (AiTM). Eftersom Google ser en legitim inloggning från en känd IP-adress med korrekt verifiering, utfärdas en giltig sessionstoken som angriparen omedelbart kapar. Offret tror att de har loggat in och kanske upplever inget fel, medan angriparen nu har full tillgång till e-post, Drive och möjligheten att bevilja OAuth-åtkomst i offrets namn.
Teknisk analys: Varför filter misslyckas
Det som gör Operation CloudFire särskilt svårhanterlig är hur den utnyttjar blindfläckarna i modern e-postsecurity. Traditionella lösningar lyfter ofta länkar ur meddelanden och skickar dem till sandboxar för att analysera måldestinationen. I detta fall pekar det första hoppet på en ren, välkänd Google-domän. Den slutgiltiga phishing-sidan genereras först efter att Cloudflare Turnstile har validerat användaren, vilket betyder att webbkrypare och automatiska skannrar aldrig ser den faktiska inloggningsformuläret.
Material Security noterar att infrastrukturen är designad för att vara engångsbruk. Domäner registreras ofta bara dagar innan användning, och ett vildkortscertifikat utställdes i ett fall endast 46 minuter före domänregistreringen 1. Att blockera en specifik länk är meningslöst eftersom kostnaden för angriparen att sätta upp en ny är några dollar och ett eftermiddagsarbete.
Försvarsmekanismer som enbart vilar på domänreputation eller SSL-certifikat misslyckas här, eftersom alla delar i kedjan framstår som legitima. För att detektera detta krävs en analys av meddelandets beteende och avsändarkontext snarare än enkel länkverifiering. Material Security rapporterar att de blockerat över 68 000 kampanjmeddelanden och tagit ner 897 unika domäner under en månad genom att aktivt rapportera gateway-URL:er till Cloudflare, vilket tvingade angriparna att ständigt byta infrastruktur.
Konsekvenser för utvecklare och företag
För IT-administratörer innebär detta att fokus måste flyttas från förebyggande blockerad vid postporten till snabb reaktion efter intrång. Eftersom sessionen kapras är bevisen inte att hitta i e-postloggar utan i Workspace-auditloggar. Angriparna har omedelbar åtkomst till känslig data och kan sprida sig vidare genom offrets kontaktnät, vilket förklarar de 8 570 komprometterade avsändarkonton som Material Security identifierade.
Kritiska åtgärder inkluderar:
- Granskning av auditloggar: Företag måste ha rutiner för att kontinuerligt övervaka oväntade inloggningar eller OAuth-åtkomst från okända enheter.
- Snabb återkallelse: Förmågan att återkalla sessioner och rensa behörigheter inom en timme är avgörande. En kapad session kan göra stor skada på mycket kort tid.
- Restriktioner för kalenderinbjudningar: Google införde den 14 augusti 2026 nya kontroller som låter administratörer begränsa vilka inbjudningar som läggs till automatiskt, vilket är ett direkt motmedel mot denna typ av attackvektor.
Vad händer härnäst
Även om aktiviteten från denna specifika grupp har spridits ut verkar hotet långt ifrån över. Material Security har upptäckt att Nyasher-ramverket innehåller en inaktiv kodgren för Microsoft 365, med stilfiler och rubriker som tyder på en framtidig Microsoft-sign-in-prompt 1. Detta är inte en slump; det är en förberedd iterativ utveckling. Angriparna har redan testat vatten och bygger nu bredare kapacitet.
Detta illustrerar en trend där Adversary-in-the-Middle-angrepp blir standard för avancerade threat actors. MFA, som länge betraktats som ett starkt försvarslager, måste kompletteras med adaptiv autentisering, kontextuell analys av inloggningar och proaktiv övervakning av användarbeteende. Att lita på att en användare har godkänt en kod räcker inte längre; vi måste också fråga vem den koden faktiskt skickades till.
källor
Sidorna som redaktionen läste när artikeln skrevs.
// kommentarer (0)
Inga kommentarer ännu.