Vorige maand gebruikten aanvallers gestolen inloggegevens om Klue, een SaaS-aanbieder van concurrentieanalyse, te hacken. De kiem voor de aanval werd echter blijkbaar al vier jaar eerder gelegd.

Klue-managers zei dat het in Vancouver gevestigde bedrijf in 2022 een vergunning heeft verleend aan een niet nader genoemde derde partij voor een beperkte pilot. onderzoek Crowdstrike onthulde later dat de inloggegevens een GitHub Personal Access Token (PAT) betroffen, waarmee ontwikkelaars toegang krijgen tot softwareontwikkelingsrepositories.

Toen de pilot was afgelopen, bleef het token actief omdat niemand het had ingetrokken. Het bevond zich ergens, onzichtbaar voor klanten die Klue toegang hadden gegeven tot hun meest intieme geheimen. Het was een tikkende tijdbom.

Het onderzoek heeft niet vastgesteld hoe Icarus (een nieuwe groep, actief sinds april 2026) aan de PAT is gekomen, maar op 11 juni gebruikte de groep het token om nieuwe code in de integratieservicelaag van Klue te pushen.

Op die laag haalt Klue gegevens uit de systemen van haar klanten, die worden gehost op diensten zoals Salesforce en Gong. Klue gebruikt deze gegevens om concurrentieanalyses uit te voeren voor haar klanten, waardoor hun verkopers beter voorbereid de onderhandelingen ingaan.

De code-update heeft de OAuth-tokens (permanente sessietokens voor herhaalde toegang zonder wachtwoord) die Klue bewaarde om toegang te krijgen tot de gegevens van haar klanten op die systemen, buitgemaakt. De aanvallers gebruikten die tokens vervolgens om gegevens te stelen van de Salesforce- en Gong-instanties van die klanten.

OAuth-tokens als middel om legitimiteit te verbergen

De aanval was niet gemakkelijk te ontdekken, omdat het gebruik van gestolen OAuth-tokens pas op een inbraak lijkt als die tokens worden ingetrokken. Icarus verstuurde rechtstreeks REST-aanroepen naar Salesforce- en Gong-instanties, net zoals elke legitieme klant zou doen.

Het was Salesforce dat Klue vertelde wat er op 12 juni was gebeurd, waarna het bedrijf voor concurrentieanalyse zijn OAuth-tokens vernieuwde.

De lijst met bevestigde slachtoffers bevatte HackerOne, Huntress, Jamf, Recorded Future, Snyk en LastPass. Het leest als een opsomming van bedrijven die er hun dagtaak van maken om andere bedrijven te vertellen hoe ze precies dit risico moeten beheersen.

De gevolgen voor de slachtoffers zijn overal op internet te lezen, aangezien zij updates moesten plaatsen over hoe het probleem met Klue hen had getroffen. Salesforce bevestigde dat het incident "beperkt was tot de app-verbinding van Klue en niet voortkwam uit een kwetsbaarheid binnen het Salesforce-platform" – waarmee de verantwoordelijkheid voor de monitoring volledig bij de klant kwam te liggen die de integratie had geautoriseerd. zei "Organisaties kunnen tot nader order geen verbinding maken met Salesforce via deze app." Gong zei hetzelfdeEn Tanium ook Klue geblokkeerd.

LastPass bekendgemaakt Dat klantnamen, e-mailadressen, telefoonnummers, fysieke adressen, details van supportaanvragen en verkoopgerelateerde gegevens openbaar waren gemaakt, heeft het bedrijf de toegang van alle medewerkers tot Klue ontzegd.

jagerin bevatte gedetailleerde updatesHet bericht legde uit dat Icarus een datalek had gepubliceerd op zijn darkweb-site en had gedreigd meer gegevens vrij te geven, waarbij meer dan 200 bedrijven als slachtoffers werden genoemd. De site waar het datalek plaatsvond, bleek in Rusland te worden gehost.

Geen van de slachtoffers had een plausibele manier om te zien wat er zich binnen de infrastructuur van Klue afspeelde; hun leveranciersrisicoprogramma's hadden de integratie vermoedelijk goedgekeurd en waren verdergegaan. Voor veel beveiligingsteams lijken audits van SaaS-bedrijven een momentopname te zijn. Zodra de leverancier de vragenlijst heeft ingevuld en is goedgekeurd, is de audit afgerond.

Waarom dit ISO 27001 waardevoller maakt

De leveranciers- en toegangsbeheersmaatregelen van ISO 27001 zijn ontworpen om te beschermen tegen de fouten die Icarus heeft uitgebuit.

Controle A.5.16 vereist dat organisaties de volledige levenscyclus van elke identiteit beheren, van het aanmaken tot het verwijderen ervan, terwijl A.5.18 dezelfde discipline uitbreidt naar authenticatiegegevens en gedocumenteerde rotatieschema's voor API-sleutels en -tokens verplicht stelt.

Als ze consequent waren toegepast, zou een van beide methoden al lang vóór Icarus een vier jaar oud probleem aan het licht hebben gebracht. Klue's huidige problemen zijn een schoolvoorbeeld van de gevolgen van het niet toepassen van deze principes op de lange termijn.

Maar dat is iets wat Klue intern had kunnen doen, niet iets waar klanten invloed op hebben. Wat kan een bedrijf doen om zich te beschermen tegen misstappen van een leverancier?

De beheersmaatregelen A.5.19 tot en met A.5.23 hebben betrekking op de relatie met de leverancier zelf. A.5.22 vereist dat organisaties de diensten van leveranciers regelmatig monitoren, beoordelen en auditeren.

A.5.21 gaat nog een stap verder en vereist dat beveiligingsvereisten ook gelden voor subverwerkers en dat het gebruik door subverwerkers wordt vastgelegd in leveranciersovereenkomsten.

Een informatiebeveiligingsbeheersysteem operationaliseert deze clausules door een jaarlijkse vragenlijst om te zetten in een actueel register van integraties, referenties en tokenverleningen. Het dwingt het gesprek over de deprovisionering af wanneer een pilotproject eindigt. Het biedt compliance managers ook een auditspoor om aan te tonen dat zowel de leveranciers waarop ze vertrouwen als hun subverwerkers dezelfde continue controle krijgen als de directe leveranciers waarmee ze contracten hebben.

Klue verdient lof voor de genomen maatregelen om herhaling te voorkomen, waaronder het verbieden van het gebruik van PAT's en de overstap naar andere authenticatiemechanismen. Het bedrijf heeft de auditregistratie verbeterd en strengere controles ingevoerd op de softwareontwikkelingsprocessen. Beter laat dan nooit.

Een ISMS is de manier waarop compliance managers ervoor zorgen dat ze niet zelf in het nieuws komen, hetzij als direct doelwit van een datalek, hetzij als klant van een bedrijf dat slachtoffer is geworden van een datalek.

Breid je kennis uit

Blog: Hoe ransomware een probleem voor de bedrijfscontinuïteit is geworden

Blog: Let op de kloof: het Salesforce-incident en de veranderende aard van cloudrisico's

Podcast: Phishing voor problemen S02 E03: Domino's in de toeleveringsketen: waarom hun risico nu ook jouw risico is