De meesten van ons denken bij het overnemen van een account aan iemand die een wachtwoord raadt of steelt. Maar een patroon dat bij verschillende recente incidenten naar voren komt, werkt anders: de aanvaller raakt je wachtwoord helemaal niet aan. In plaats daarvan zorgen ze ervoor dat je iets overdraagt dat werkt als een reservesleutel voor een account waarop je al bent ingelogd — een gekoppeld apparaat, een autorisatietoken, een sessie — en lopen ze zo langs de beveiligingen waar je normaal op vertrouwt.

Twee voorbeelden maken het mechanisme concreet. Beveiligingsonderzoekers beschreven onlangs een WhatsApp-scam die zich verspreidt vanuit al gekaapte accounts, waarbij een bericht je vraagt om op een vriend te 'stemmen' in een wedstrijd. Je wordt naar een pagina geleid die de WhatsApp-configuratie voor 'gekoppelde apparaten' nabootst, of krijgt te horen dat je een code moet invoeren in het menu voor gekoppelde apparaten. Als je die procedure voltooit, wordt de telefoon van de aanvaller als tweede, volledig geautoriseerd apparaat aan je account toegevoegd — met volledige lees- en verzendtoegang — zonder dat de aanvaller ooit een wachtwoord invoert. Omdat er geen wachtwoord is aangeraakt, krijg je geen e-mail voor het opnieuw instellen van je wachtwoord en geen waarschuwing voor een mislukte aanmelding. De malafide sessie blijft gewoon stilletjes in je apparatenlijst staan als nog een item.

Los daarvan heeft Microsoft gewaarschuwd voor een campagne die misbruik maakt van captive portals op hotel- en conferentie-wifi — de pagina met 'akkoord gaan met de voorwaarden' die je ziet wanneer je verbinding maakt. Aanvallers die zich op het netwerkpad bevinden, leiden slachtoffers om naar nep-inlogpagina's of nep-prompts voor een 'apparaatcode' die, zodra ze zijn voltooid, autorisatietokens in plaats van wachtwoorden overdragen. Het effect is hetzelfde: een sessie die er voor de dienst legitiem uitziet, omdat die dat technisch gezien ook is — alleen behoort die nu aan iemand anders toe.

Waarom je gebruikelijke verdediging dit mist

Een wachtwoordmanager beschermt het wachtwoord. Tweefactorauthenticatie beschermt het moment waarop je inlogt. Geen van beide houdt in de gaten wat er na gebeurt wanneer een sessie of apparaat wordt geautoriseerd, en dat is precies de lacune waarvoor deze aanvallen zijn ontworpen. De enige betrouwbare manier om deze categorie van compromittering te ontdekken, is regelmatig handmatig te controleren welke apparaten en apps momenteel blijvende toegang tot je accounts hebben — in plaats van te wachten op een waarschuwing die deze aanvallen er juist specifiek op zijn gericht niet te activeren.

De sessie-audit van 15 minuten

Doe dit voor de accounts die er het meest toe doen (e-mail, WhatsApp/Telegram, bankzaken en alles wat aan je identiteit of geld is gekoppeld) en stel een terugkerende herinnering in om het te herhalen. Als menunamen in de loop der tijd veranderen, zoek dan naar termen als 'apparaten', 'sessies' of 'verbonden apps':

  • WhatsApp: Instellingen → Gekoppelde apparaten. Tik op alles wat je niet herkent en log het onmiddellijk uit.
  • Google: myaccount.google.com/security → 'Je apparaten' en, afzonderlijk, 'Apps en services van derden' (soms aangeduid als 'Inloggen met Google'). Trek de toegang in voor alles wat je niet actief gebruikt.
  • Microsoft-account: account.microsoft.com/devices voor de apparatenlijst; account.microsoft.com/activity voor de aanmeldingsgeschiedenis.
  • Apple ID: Instellingen → [je naam] op een iPhone/iPad, of Systeeminstellingen op een Mac, toont elk apparaat waarop je met je Apple ID bent ingelogd.
  • Facebook/Instagram (Meta): Instellingen → Accountcentrum → Wachtwoord en beveiliging → Waar je bent ingelogd.
  • Bank- en financiële apps: de meeste hebben onder de beveiligingsinstellingen een scherm 'apparaten beheren' of 'actieve sessies', al verschilt de benaming per instelling — kijk nu bij die van jou, zodat je weet waar het staat voordat je het nodig hebt.

Als je toch in deze menu's zit, kijk dan ook even naar een lijst met 'verbonden apps' of OAuth-toekenningen — oude apps en browserextensies die je jaren geleden hebt geautoriseerd en bent vergeten, zijn precies het soort blijvende toegang dat deze aanvalsklasse opnieuw probeert te creëren.

Als je iets vindt wat je niet herkent

Verwijder het onbekende apparaat of de onbekende app of log het eerst uit — wacht niet. Verander daarna, ook al had de aanvaller je wachtwoord misschien niet nodig, toch je wachtwoord als extra veiligheidsmaatregel, en schakel tweefactorauthenticatie opnieuw in als die was uitgeschakeld (sommige kapingen schakelen die uit om het makkelijker te maken opnieuw binnen te komen). Controleer of de aanvaller iets kan hebben ingesteld om blijvend toegang te houden, zoals nieuwe doorstuurregels in e-mail, nieuwe telefoonnummers of e-mailadressen voor accountherstel, of nieuwe apparaten die elders zijn toegevoegd — een gekaapte sessie wordt vaak gebruikt om een tweede toegangspunt te plaatsen voordat het eerste wordt ontdekt. Als het gehackte account er een is dat contactpersonen vertrouwen (zoals WhatsApp), laat mensen dan weten dat berichten van jou uit het recente verleden — vooral berichten waarin om geld, stemmen of codes wordt gevraagd — mogelijk niet van jou afkomstig waren.

Een valkuil die specifiek met reizen te maken heeft

Als je verbinding maakt met wifi in een hotel, op een luchthaven of bij een conferentie en de captive-portalpagina je vraagt om je 'aan te melden' bij Microsoft, Google of een vergelijkbaar account, of je een apparaatcode toont die je moet invoeren, wees dan standaard wantrouwig — legitieme hotel-wifi vereist bijna nooit dat je een persoonlijk cloudaccount authenticeert om online te gaan. Sluit de browser, maak in plaats daarvan verbinding via de mobiele hotspot van je telefoon of een VPN, en als je hotel-wifi moet gebruiken, log er dan helemaal niet in op gevoelige diensten.

Nog één tip, als je code schrijft of publiceert

Dezelfde logica van 'het is niet je wachtwoord, maar je sessie/token' geldt voor ontwikkelaarsgegevens. Bij een recent supplychainincident met een vergiftigd npm-pakket werd specifiek gelet op het roteren van inloggegevens en kon het pakket daarop reageren — wat betekende dat de instinctieve eerste stap (je tokens roteren) in dat geval de verkeerde eerste stap was. Als je ooit vermoedt dat een build- of CI-inloggegeven is blootgesteld, controleer dan eerst wat het gecompromitteerde pakket daadwerkelijk heeft gedaan voordat je iets roteert, in plaats van aan te nemen dat alleen roteren de deur sluit.

Zet het in je agenda

Dit is geen eenmalige oplossing — het is een gewoonte, net zoals het controleren van je bankafschrift een gewoonte is. Kies een terugkerende datum (de eerste van de maand werkt goed) en loop de bovenstaande apparaat- en sessielijsten door. Het is een controle van vijftien minuten die precies het soort stille, wachtwoordvrije overname ontdekt dat al het andere in je beveiligingsopstelling juist niet kan detecteren.