Klueless: Hur en fyra år gammal legitimation ledde till en större hackning

By Danny Bradbury • 14 juli 2026 • 5 minuters läsning

Förra månaden använde angripare stulna inloggningsuppgifter för att hacka SaaS-leverantören Klue, en konkurrensinformationstjänst. Men fröna till attacken började tydligen fyra år tidigare.

Klue-chefer sade att det Vancouver-baserade företaget år 2022 utfärdade en legitimation till en icke namngiven tredje part för ett begränsat pilotprojekt. Undersökningen Crowdstrike avslöjade senare att autentiseringsuppgifterna var en GitHub Personal Access Token (PAT), vilket gör det möjligt för utvecklare att komma åt programvaruutvecklingsdatabaser.

När pilotprojektet avslutades förblev token aktiv eftersom ingen återkallade den. Den låg någonstans, osynlig för kunder som gav Klue tillgång till deras innersta hemligheter. Det var en tickande tidsbomb.

Utredningen fastställde inte hur Icarus (en ny grupp, aktiv först sedan april 2026) fick PAT:n, men den 11 juni använde de token för att skicka in ny kod i Klues integrationstjänstlager.

Det är i det lagret som Klue hämtar data från sina kunders system, som finns på tjänster som Salesforce och Gong. De använder dessa data för att utföra konkurrensinformationsanalyser för sina kunder, vilket gör det möjligt för deras säljare att gå in i förhandlingar bättre förberedda.

Koduppdateringen samlade in OAuth-tokens (persistenta sessionstokens för upprepad lösenordslös åtkomst) som Klue behöll för att komma åt sina kunders data på dessa system. Angriparna använde sedan dessa tokens för att hämta data från dessa kunders Salesforce- och Gong-instanser.

OAuth-tokens som legitimitetstvätt

Attacken var inte lätt att upptäcka eftersom användningen av stulna OAuth-tokens inte ser ut som ett intrång förrän dessa tokens återkallas. Icarus utlöste direkta REST-anrop mot Salesforce- och Gong-instanser precis som vilken legitim kund som helst skulle göra.

Det var Salesforce som berättade för Klue vad som hade hänt den 12 juni, vilket fick konkurrensinformationsföretaget att rotera sina OAuth-tokens.

Den bekräftade offerlistan inkluderade HackerOne, Huntress, Jamf, Recorded Future, Snyk och LastPass. Den kan läsas som en katalog över företag vars dagliga jobb är att berätta för andra företag hur de ska hantera just denna risk.

Effekten på offren skrivs över hela webben, eftersom de var tvungna att publicera uppdateringar om hur Klues problem hade påverkat dem. Salesforce bekräftade att incidenten var "begränsad till Klues appanslutning och inte uppstår från en sårbarhet i Salesforce-plattformen" – vilket placerar övervakningsansvaret helt och hållet på kunden som godkände integrationen. Det sägs också sade ”Organisationer kommer inte att kunna ansluta till Salesforce via den här appen tills vidare”. Gong sa detsammaOch Tanium också blockerade Klue.

Lastpass beskrives att kundnamn, e-postadresser, telefonnummer, fysiska adresser och supportärenden samt försäljningsrelaterad data hade exponerats. Företaget avbröt alla anställdas åtkomst till Klue.

Huntress genomförde detaljerade uppdateringaroch förklarade att Icarus hade publicerat en datadump på sin mörka webbplats och hotat med att släppa mer data, med hänvisning till över 200 offerföretag. De identifierade webbplatsen för dataläckan som värd i Ryssland.

Inget av offren i nedströmskedjan hade ett rimligt sätt att se vad som hände inuti Klues infrastruktur; deras leverantörsriskprogram hade förmodligen godkänt integrationen och gått vidare. För många säkerhetsteam verkar granskningar av SaaS-företag vara en händelse i ett ögonblick. När leverantören har fyllt i frågeformuläret och blivit godkänd anses det vara klart.

Varför detta gör ISO 27001 mer värdefull

ISO 27001:s leverantörs- och åtkomsthanteringskontroller är utformade för att skydda mot de fel som Icarus utnyttjade.

Kontroll A.5.16 kräver att organisationer hanterar hela livscykeln för varje identitet, från provisionering till avprovisionering, medan A.5.18 utvidgar samma disciplin till autentiseringsuppgifter och kräver dokumenterade rotationsscheman för API-nycklar och tokens.

Om de tillämpades konsekvent skulle båda dessa ha lett till en fyra år gammal PAT långt före Icarus. Klues nuvarande problem är ett tydligt exempel på vad det kostar senare i livet att inte tillämpa dessa principer.

Men det är något som Klue kunde ha gjort internt, inte något som deras kunder kan kontrollera. Vad kan ett företag göra för att skydda sig mot en leverantörs misstag?

Kontrollerna A.5.19 till A.5.23 styr själva leverantörsrelationen. A.5.22 kräver att organisationer regelbundet övervakar, granskar och reviderar leverantörstjänster.

A.5.21 driver skyldigheten ytterligare och kräver att säkerhetskraven ska överföras till underleverantörer och att användningen av underleverantörer ska registreras i leverantörsavtal.

Ett system för informationssäkerhetshantering operationaliserar dessa klausuler och omvandlar ett årligt frågeformulär till ett liveregister över integrationer, autentiseringsuppgifter och tokenbeviljanden. Det tvingar fram en avprovisioneringskonversation när ett pilotprojekt avslutas. Det ger också compliance-ansvariga en revisionslogg för att bevisa att både de leverantörer de förlitar sig på och deras underleverantörer får samma kontinuerliga tillsyn som de direkta leverantörer de har avtal med.

Till sin förtjänst ska Klue ha vidtagit flera åtgärder för att säkerställa att detta inte händer igen, inklusive att förbjuda användningen av PAT:er och migrera till andra autentiseringsmekanismer. De har förbättrat sin granskningsloggning och infört strängare kontroll över sina programvaruutvecklingspipelines. Bättre sent än aldrig.

Ett ISMS är hur compliance-chefer ser till att de inte blir nästa rubrik, antingen som direkt måltavla för ett dataintrång eller som kund till ett komprometterat offer.