Kort version
En stulen sessionscookie är en giltig, redan autentiserad session. Angriparen behöver inte lösenordet, inte andra faktorn och inte passkeyn. Den importerar cookien i sin egen webbläsare och är därmed du.
Det spelar roll, för standardrådet "slå på MFA" siktar på inloggningssteget, och den här attacken använder inte inloggningssteget. Vi har sett konton som skyddats av både TOTP och passkeys tas över på det här sättet. Skydden fungerade precis som de var byggda. De bevakade bara en dörr som angriparen aldrig gick igenom.
Kedjan
Tekniken för initial åtkomst som cirkulerar just nu heter ClickFix: en sida påstår att något är trasigt och att lösningen är att klistra in ett kommando i Kör-dialogen eller en terminal. Ibland är det förklätt till en CAPTCHA ("verifiera att du är människa"), ibland till en videokodek eller ett typsnitt som behöver installeras. Offret kör kommandot själv, så det finns ingen sårbarhet som utnyttjas, ingen skadlig bilaga och inget för ett mailfilter att fånga.
Det avgörande är sista steget. Väl inne sitter angriparen inte still. Den lägger till egen återställningsadress eller enhet, ändrar vilka som är administratörer och låser ut den rättmätige ägaren. Ur plattformens perspektiv kom varje sådan åtgärd från en autentiserad session, och det är just därför automatiska överklaganden så ofta faller: det finns ingen avvikelse att upptäcka i den data plattformen tittar på.
Varför standardrådet missar
"Slå på MFA." Skyddar inloggningen. Angriparen hoppar över inloggningen.
"Använd passkeys eller FIDO2." Genuint bra, och värt att införa. Det gör lösenordsphishing i stort sett meningslöst, eftersom det inte finns någon delad hemlighet att stjäla. Det gör ingenting åt en cookie som lyfts efter en lyckad autentisering.
"Använd lösenordshanterare." Hjälper mot återanvändning och phishing. Infostealers riktar sig specifikt mot lösenordshanterares filer och webbläsarens lagring.
Inget av detta är ett argument mot de skydden. De stoppar andra, vanligare attacker och du bör ha samtliga. Poängen är snävare: utgå inte från att de täcker den här.
Vad som faktiskt hjälper
Ungefär i fallande ordning efter effekt mot just det här hotet:
- Enhetsbundna sessioner. Chromes Device Bound Session Credentials knyter sessionen till en nyckel i enhetens TPM. En cookie som kopieras till en annan maskin blir verkningslös. Det är det första skyddet som angriper grundorsaken i stället för symtomet. Aktivera där plattformen stödjer det.
- Kör inte payloaden. Hela kedjan börjar med att en människa klistrar in ett kommando. Ingen legitim sajt har någonsin bett dig klistra in något i Kör-dialogen för att bevisa att du är människa. Det är värt att säga rakt ut och upprepat till alla med kontoåtkomst, eftersom det är det enda steget där försvaret är gratis.
- Korta sessioner och omautentisering. Kräv ny autentisering före åtgärder med stor påverkan: ändra administratörsroller, lägga till återställningsmetoder, flytta pengar. En stulen cookie räcker då mycket kortare.
- Separera administratörsidentiteten. Kontot som administrerar företagssidan ska inte vara samma konto som används för daglig surf. Att en surfsession komprometteras ska inte innebära att företagstillgången komprometteras.
- Minska skadeytan. Gå igenom vilka som har administratörsrättigheter. En sida vars enda administratör är ett personligt konto är en stulen cookie från att bli oåterkallelig.
- Endpoint-detektion. Laddarsteget är högljutt: en webbläsare som startar PowerShell som i sin tur hämtar och kör kod är en tydlig signal. Det är precis vad endpoint-verktyg finns till för.
- Granska sessioner. De flesta plattformar listar aktiva sessioner och inloggningsplatser. Titta på dem, och slå på inloggningsaviseringar.
Om det redan har hänt
Agera snabbt, och utgå från att uppgifterna är borta snarare än bara exponerade:
- Ogiltigförklara alla sessioner på de drabbade kontona, inte bara den du ser. "Logga ut från alla enheter" finns för det här.
- Rotera allt webbläsaren hade. Sparade lösenord, API-nycklar, OAuth-medgivanden. Behandla hela webbläsarprofilen som komprometterad, för det är den.
- Kartlägg vad mer som använde identiteten för inloggning. Sociala konton är ofta återställningsväg eller inloggning för en lång svans av andra tjänster. Den sekundära exponeringen är oftast större än kontot i sig.
- Ladda ner din data medan du fortfarande har någon åtkomst alls. Plattformarnas dataexport innehåller även angriparens aktivitet, med enheter och platser, vilket är användbar bevisning.
- Anmäl på rätt sätt. För en företagstillgång, gå via plattformens företagssupport i stället för det automatiska konsumentöverklagandet, som är där de här ärendena tenderar att dö.
Den obekväma delen
Att återfå ett kapat konto på en social plattform är genuint svårt, och den automatiska överklagandeprocessen är inte byggd för ett fall där varje fientlig åtgärd kom från en giltig session. Planera utifrån att du kanske inte får tillbaka kontot. Det förändrar kalkylen: arbetet hör hemma i skydden ovan, innan något händer, snarare än i en återställningsprocess du inte råder över.
Om verksamheten kör betald annonsering eller kundkommunikation via en social plattform är det kontot produktionsinfrastruktur. Det förtjänar samma behandling som vilket annat produktionssystem som helst: utpekade ägare, separata administratörsidentiteter, granskad åtkomst, och en plan för vad som händer när det går förlorat.
Källor
- FortiGuard Labs, From ClickFix to Command: A Full PowerShell Attack Chain, teknisk genomgång av laddaren och PowerShell-stegen.
- Google Chrome Security, Device Bound Session Credentials, sessionsbindningen som beskrivs ovan.
Adminor arbetar med attackyteövervakning och säkerhetstestning. Vill du ha en genomgång av hur er organisations verksamhetskritiska konton är skyddade, hör av dig.