Klueless: Hvordan en fire år gammel legitimasjon førte til et stort hackingangrep

Name: ISMS.online
Address: Nile House, Nile Street, Brighton, East Sussex, BN1 1HW, GB
Telephone: +441273041140
Price range: ££

By Danny Bradbury • 14. juli 2026 • 5 minutters lesetid

Forrige måned brukte angripere stjålet legitimasjon til å hacke SaaS-leverandøren Klue, en konkurranseetterretningstjeneste. Men kimen til angrepet startet visstnok fire år tidligere.

Klue-ledere sa at selskapet, som er basert i Vancouver, i 2022 utstedte en legitimasjon til en ikke navngitt tredjepart for et begrenset pilotprosjekt. En etterforskning Crowdstrike avslørte senere at legitimasjonen var en GitHub Personal Access Token (PAT), som lar utviklere få tilgang til programvareutviklingslagre.

Da piloten var over, forble tokenet aktivt fordi ingen tilbakekalte det. Det lå et sted, usynlig for kunder som ga Klue tilgang til deres innerste hemmeligheter. Det var en tikkende bombe.

Etterforskningen fant ikke ut hvordan Icarus (en ny gruppe, kun aktiv siden april 2026) fikk tak i PAT-en, men 11. juni brukte de tokenet til å sende ny kode til Klues integrasjonstjenestelag.

Det er på dette laget at Klue henter data fra kundenes systemer, som ligger på tjenester som Salesforce og Gong. De bruker disse dataene til å utføre konkurranseanalyse for kundene sine, slik at selgerne deres kan gå bedre forberedt inn i forhandlinger.

Kodeoppdateringen samlet OAuth-tokenene (vedvarende økttokener for gjentatt passordløs tilgang) som Klue beholdt for å få tilgang til kundenes data på disse systemene. Angriperne brukte deretter disse tokenene til å hente data fra disse kundenes Salesforce- og Gong-instanser.

OAuth-tokens som hvitvasking av legitimitet

Angrepet var ikke lett å oppdage fordi bruken av stjålne OAuth-tokener ikke ser ut som et innbrudd før disse tokenene blir tilbakekalt. Icarus utløste direkte REST-kall mot Salesforce- og Gong-instanser akkurat som enhver legitim kunde ville gjort.

Det var Salesforce som fortalte Klue hva som hadde skjedd 12. juni, noe som fikk konkurranseetterretningsselskapet til å rotere sine OAuth-tokens.

Den bekreftede offerlisten inkluderte HackerOne, Huntress, Jamf, Recorded Future, Snyk og LastPass. Den kan leses som en oversikt over selskaper som har som daglige jobb å fortelle andre selskaper hvordan de skal håndtere nettopp denne risikoen.

Effekten på ofrene er skrevet over hele nettet, ettersom de måtte legge ut oppdateringer om hvordan Klues problem hadde påvirket dem. Salesforce bekreftet at hendelsen var «begrenset til Klues apptilkobling og ikke oppsto fra en sårbarhet i Salesforce-plattformen» – og plasserte dermed overvåkingsansvaret helt og holdent på kunden som autoriserte integrasjonen. Det ble også sa «Organisasjoner vil ikke kunne koble seg til Salesforce via denne appen inntil videre.» Gong sa det sammeOg Tanium også blokkerte Klue.

LastPass avslørt at kundenavn, e-postadresser, telefonnumre, fysiske adresser og detaljer om støttesaker og salgsrelaterte data hadde blitt eksponert. Selskapet avbrøt alle ansattes tilgang til Klue.

Huntress gjennomførte detaljerte oppdateringer, og forklarte at Icarus hadde publisert en datadump på sitt mørke nettsted, og hadde truet med å frigi mer data, med henvisning til over 200 offerselskaper. De identifiserte nettstedet for datalekkasjen som vert i Russland.

Ingen av ofrene nedstrøms hadde en troverdig måte å se hva som skjedde i Klues infrastruktur; leverandørrisikoprogrammene deres hadde antagelig godkjent integrasjonen og gått videre. For mange sikkerhetsteam virker revisjoner av SaaS-selskaper som en øyeblikkelig affære. Når leverandøren har fullført spørreskjemaet og blitt godkjent, anses det som ferdig.

Hvorfor dette gjør ISO 27001 mer verdifull

ISO 27001s leverandør- og tilgangsstyringskontroller er utformet for å beskytte mot feilene Icarus utnyttet.

Kontroll A.5.16 krever at organisasjoner administrerer hele livssyklusen til hver identitet fra provisjonering til avprovisjonering, mens A.5.18 utvider den samme disiplinen til autentiseringslegitimasjon, og pålegger dokumenterte rotasjonsplaner for API-nøkler og tokener.

Ved konsekvent bruk ville begge disse ha dukket opp en fire år gammel PAT lenge før Icarus gjorde det. Klues nåværende problemer er et skoleeksempel på hva det koster å ikke anvende disse prinsippene senere i livet.

Men det er noe Klue kunne ha gjort internt, ikke noe kundene deres kan kontrollere. Hva kan et selskap gjøre for å beskytte seg mot en leverandørs feiltrinn?

Kontrollene A.5.19 til A.5.23 styrer selve leverandørforholdet. A.5.22 krever at organisasjoner regelmessig overvåker, gjennomgår og reviderer leverandørtjenester.

A.5.21 går videre med forpliktelsen og krever at sikkerhetskravene overføres til underdatabehandlere, og at bruk av underdatabehandlere registreres i leverandøravtaler.

Et informasjonssikkerhetsstyringssystem operasjonaliserer disse klausulene, og konverterer et årlig spørreskjema til et live-register over integrasjoner, legitimasjon og tokentildelinger. Det fremtvinger samtalen om avprovisjonering når en pilotprosess avsluttes. Det gir også samsvarsansvarlige et revisjonsspor for å bevise at både leverandørene de stoler på og deres underdatabehandlere får samme kontinuerlige tilsyn som de direkte leverandørene de har kontrakt med.

Til sin ære skal Klue ha tatt flere grep for å sikre at dette ikke skjer igjen, inkludert å forby bruk av PAT-er og migrere til andre autentiseringsmekanismer. De har forbedret revisjonsloggingen og innført strengere kontroll over programvareutviklingsprosessene. Bedre sent enn aldri.

Et ISMS er hvordan compliance-ledere sørger for at de ikke blir den neste overskriften, verken som direkte mål for et datainnbrudd eller som kunde til et kompromittert offer.