Een recente campagne laat zien hoe Google session hijacking kan plaatsvinden met een ogenschijnlijk onschuldige lure: Google Calendar-uitnodigingen. Sinds half augustus 2026 zouden criminelen live sessies van zakelijke gebruikers hebben overgenomen. Opvallend daarbij is dat veel verdedigingschecks netjes “goed” terugkomen—wat de aanval juist zo moeilijk detecteerbaar maakt.
Onderzoekers van Material Security brachten de techniek in kaart en namen daarbij honderden aanvallersdomeinen offline. Ze labelden het geheel Operation CloudFire. Hieronder lees je hoe de campagne werkt, waarom traditionele controles stil blijven, en welke maatregelen je team prioriteit moet geven.
De lokroep: kalenderuitnodigingen die niet opvallen
De berichten kwamen binnen als Google Calendar-invites. Sommige gingen met BCC en veel meldingen leken afkomstig van organisaties waarmee de ontvanger al eerder contact had. Dat is precies het soort “vertrouwde context” dat in een drukke mailbox minder snel opvalt.
De inhoud was expres braaf en alledaags: meldingen zoals voicemail, RFP/RFI-verzoeken, gerechtelijke stukken of een herinnering voor een gemiste betaling. Er was niets in de tekst dat direct alarm zou doen.
Waarom de links er legitiem uitzien
Veel van de links leken naar Google zelf te wijzen. Het patroon liep via een Google-redirector, waarbij de echte bestemming verstopt zat in een queryparameter. In andere varianten werden ook links gebruikt die ogenschijnlijk met Google of gedeelde Drive-bestanden te maken hadden.
Ook het signaal dat je vaak gebruikt voor triage—zoals domein, certificaat en reputatie—kwam in de onderzochte gevallen “gezond” over. Dat betekende dat verdachten niet meteen aan de oppervlakte kwamen via standaard domein- of certificaatchecks.
De kern van de aanval: een live reverse proxy
Wanneer een slachtoffer op de link klikt, staat er geen statische phishingpagina klaar. In plaats daarvan start de aanvaller een live reverse proxy die voor de echte Google-aanmeldpagina zit.
Het slachtoffer ziet een authentieke inlogervaring: het wachtwoord wordt ingevoerd, daarna komt er een echte prompt. Vervolgens kan de gebruiker—zonder dat te doorzien—goedkeuring geven terwijl de aanvaller live meekijkt.
Belangrijk detail: elke tweede factor die het slachtoffer normaal gebruikt (zoals SMS-codes, authenticatorcodes, “Tap-Yes”-achtige goedkeuringen of telefonische accountherstelstappen) wordt doorgegeven zodra die beschikbaar komt. De extra controle voorkomt in dit scenario dus niet dat de sessie wordt afgevangen.
De techniek erachter: Nyasher en waarom hij niet “scanbaar” is
Het framework dat hierbij werd gebruikt heet Nyasher. Het werd al eerder publiek gedocumenteerd nadat onderzoekers in februari een hardcoded sleutel in JavaScript hadden gevonden.
Voor verdediging betekent dit: er is weinig “materiaal” om vooraf te analyseren. De pagina die om inlog vraagt wordt pas opgebouwd nadat bezoekers de tussenstap hebben doorlopen. Daardoor kan een crawler nauwelijks iets ophalen—en proxylogs kunnen minder direct bewijs verzamelen.
In de campagne zat bovendien een gelaagde opbouw. Die volgt globaal drie stappen: de eerste redirect valt binnen het vertrouwde bereik van Google-achtige URLs, daarna volgt een challenge-component (in sommige gevallen via Cloudflare), en pas daarna verschijnt de effectieve inlogstap.
Waarom reputatie en linkanalyse alleen te weinig zeggen
Veel teams leunen op signalen zoals domeinreputatie en eigenaarschap—bijvoorbeeld via registratiegegevens en klachtenhistorie. Deze campagne was er expliciet op ingericht om daar doorheen te glijden: de aanvallers zorgden dat de “antwoorden” op die vragen geen rode vlag vormden.
Linkanalyse biedt eveneens geen vanzelfsprekend voordeel. De eerste stap is immers een “goede” Google-url en de echte inlogpagina bestaat bovendien pas nadat de browser het proces compleet doorloopt.
Wat volgens de onderzoekers wél werkt, is een aanpak die meerdere signalen tegelijk meeweegt: technische indicators én de context van de boodschap, inclusief waar de links uiteindelijk naartoe leiden en hoe de afzenderrelatie eruitziet.
Gaten in je aanpak: mailgateways zijn niet gemaakt voor dit type oppervlak
Een ander belangrijk leerpunt: niet elke beveiligingslaag is geschikt voor kalenderuitnodigingen. Gateways die vooral e-mailverkeer in transit scannen, zijn niet altijd optimaal voor dit specifieke threat surface.
De onderzoekers benadrukken dat calendar invites als eigen categorie risico moeten worden behandeld. Contextrijke signalen—zoals wat een account eerder heeft gezien in de historie—kunnen belangrijker zijn dan losse URL-indicatoren.
Wat is de impact als je sessie is overgenomen?
Als een aanvaller een sessie van een slachtoffer kaapt, blijft er een spoor achter in Google Workspace audit logs. In de praktijk gaat het echter verder dan alleen “inbox”-toegang.
Een live sessie kan ook gebruikt worden om toegang te krijgen tot mail, Drive en om OAuth-toegang namens de gebruiker toe te staan. Daardoor wordt de mogelijke schade breder dan de initiële phishingmail lijkt te suggereren.
Dat leidt tot een kritische vraag voor securityteams: wie bekijkt de audit logs, hoe snel kan er worden ingegrepen, en kan het team binnen korte tijd sessies intrekken, OAuth-grants beperken en het getroffen account resetten?
Operation CloudFire: infrastructuur burnen in plaats van eindeloos rules-tunen
Richtlijnen, detectieregels en modelaanpassingen helpen om toekomstige slachtoffers te beschermen. Maar volgens de onderzoekers lost dat niet het kernprobleem op voor een aanvaller die direct doorgaat naar een volgende golf. Daarom kozen ze uiteindelijk voor een andere route: het aanpakken van de infrastructuur.
Ze identificeerden tijdens verzendingen de gateway- en backend-URL’s en dienden meldingen in via Cloudflare’s abuse reporting. Cloudflare bevestigde vervolgens de nep-tussenstap en de geproxyde Google-inlogpagina, waarna er waarschuwingspagina’s voor die bestemmingen verschenen.
Dat had twee effecten: de aanvalskosten stegen (domeinen moesten opnieuw worden opgezet) en mensen die een gerapporteerde link klikten, kregen een waarschuwing in plaats van een credential-capture flow.
Resultaten na één maand: veel geblokkeerde berichten en honderden domeinen
De gepubliceerde cijfers gelden voor organisaties die data deelden, waardoor de werkelijke impact mogelijk hoger ligt. Over ongeveer een maand rapporteerden de onderzoekers:
- 68.676 campagneberichten geblokkeerd
- 2.112 unieke kwaadaardige URL’s geanalyseerd
- 897 unieke domeinen offline gehaald
- 8.570 unieke gecompromitteerde afzenders, verspreid over 6.354 root-domeinen
Daarnaast zagen ze een ritme in verzendingen dat aansloot bij Amerikaanse werkuren. Het hoge aantal afzenders is een verklaring voor de “vertrouwenslaag”: de aanvaller controleerde elk account voordat de invites verstuurd werden en gebruikte vervolgens contactlijsten van slachtoffers om geloofwaardige communicatie te creëren.
Wat verandert er nu: van calendar naar Drive-deeluitnodigingen
De onderzoeksgroep zag dat de thema’s in latere fases verschoven. Waar eerst kalenderuitnodigingen dominant waren, dook later vooral het deelschiene op via Google Drive-bestanden en documenten die gedeeld worden.
Er was op dat moment geen duidelijke aanwijzing voor een brede uitbreiding naar heel andere lurevormen. Wel waarschuwen de onderzoekers dat het framework en de opbouwprincipes al langer bekend zijn, en dat een volgende pivot even snel kan volgen.
Wat kun je doen in je eigen omgeving?
Hoewel de campagne vooral draait om een live sessie, kun je je verdediging juist versterken door je processen en detectie niet te laten afhangen van één enkel signaal. Richt je daarom op drie praktische pijlers.
- Kalender- en deeluitnodigingen als apart risico: behandel Google Calendar invites en (later) Drive-deelverzoeken als een eigen dreigingscategorie, niet als “gewone mail”.
- Audit logs écht operationaliseren: toets hoe snel je team logs kan beoordelen en sessies en OAuth-toegang kan intrekken zodra er een verdacht patroon is.
- Detectie op combinatie van context en techniek: bouw signalering op basis van waar de link werkelijk eindigt, de afzenderrelatie en technische indicatoren—niet uitsluitend op reputatie of domeinalleen.
Wil je daarnaast inspiratie voor het verbeteren van context-gedreven SOC-detectie? Dan past dit artikel over identity context voor SOC en het voorkomen van blinde vlekken goed bij deze denkrichting.
Conclusie: Google session hijacking vraagt om snelle, contextrijke actie
Google session hijacking via calendar invites is geen aanval die je eenvoudig “uit de lucht” haalt met één detectieregel. De campagne was bewust gebouwd om reputatie-, link- en statische scanchecks te omzeilen, terwijl de echte schade ontstaat zodra de aanvaller live meeloopt bij inlog en tweede factoren.
De beste verdediging combineert technische signalen met de context van het bericht, maakt calendar/deeluitnodigingen onderdeel van je threat surface en zorgt dat audit logs niet alleen bestaan, maar ook snel leiden tot containment en herstel.
Beveiliging is tenslotte geen race tegen een detector, maar een race tegen tijd—zeker wanneer een aanvaller met een live sessie binnen het uur veel kan doen.
Bron: https://thehackernews.com/2026/11/calendar-invites-and-live-proxies.html
