Ett telefonsamtal gav ShinyHunters åtkomst till ReliaQuests Okta-panel

Den 22 augusti ringde en angripare flera anställda på ReliaQuest, en amerikansk leverantör av Managed Detection and Response (MDR), och utgav sig för att vara en namngiven medlem av företagets eget säkerhetsteam. En anställd angav sina inloggningsuppgifter på en klonad sida för Single Sign-On (SSO) och godkände den efterföljande MFA-förfrågan. Det räckte för att öppna en aktiv session i ReliaQuests identitetspanel i Okta.

Sessionen var endast läsbar. En policy för enhetsförtroende blockerade alla försök att starta en applikation från panelen. ReliaQuest uppger att man därefter avslutade sessionerna, återkallade det exponerade lösenordet och återställde alla autentiseringstoken. Företagets uttalande är tydligt: ”Inga ReliaQuest-applikationer eller system fick åtkomst, och inga kunddata berördes.”

Dagen därpå, den 23 augusti, lade ShinyHunters till företaget på sin dataläckagesida och bifogade skärmdumpar från Okta-panelen.

Domänen hette reliaquest.claims

Sex dagar innan telefonsamtalet, den 17 augusti, hade ReliaQuests eget hotforskarteam publicerat en varning om den kampanj som senare skulle drabba företaget. Gruppen registrerade domäner under toppdomänen .claims genom att placera målorganisationens namn eller förkortning framför suffixet och använde dem för att utge sig för att vara helpdesk, IT-avdelningar och, på senare tid, juridiska team. Enligt källor var domänen som användes mot ReliaQuest reliaquest.claims.

Sidan som användes för att samla in inloggningsuppgifter låg bakom ett Content Delivery Network (CDN), vilket placerar en legitim IP-adress framför en skadlig webbplats och kan ge angriparen flera timmar innan webbplatsen tas ned. Ingen av dessa metoder är ny. ReliaQuests egen beskrivning av tillvägagångssättet omfattar tillfälliga domäner som efterliknar legitima domäner, klonade inloggningssidor bakom ett CDN, missbruk av MFA-förfrågningar och ett omedelbart försök att registrera en ny autentiseringsmetod under angriparens kontroll.

MFA godkände inloggningen. Device trust nekade den.

Den skillnaden är viktigare än själva utfallet. En pushnotis bekräftar att den person som har tillgång till den registrerade telefonen tryckte på ”godkänn”. Den säger ingenting om vilken enhet som begär åtkomst, var begäran kommer ifrån eller om inloggningssidan är äkta. När medarbetaren väl hade godkänt begäran hade Okta en session som systemet betraktade som legitim.

Kontrollen som stoppade eskaleringen var en separat säkerhetsåtgärd. Device Trust kräver att den anslutande enheten är registrerad och hanterad innan en applikation kan öppnas, oavsett hur övertygande telefonsamtalet var. ReliaQuest uppger att angriparen fortsatte att försöka öppna applikationer från panelen men nekades åtkomst varje gång. Företaget har sedan dess granskat Device Trust och åtkomst från det interna nätverket tillbaka till den 21 augusti och inte hittat några ytterligare tecken på intrång.

Båda sidor berättar samma historia. Det är inte en bekräftelse.

ReliaQuest uppger att angriparen aldrig tog sig längre än till kontrollpanelen. ShinyHunters sade samma sak: inga andra identiteter nåddes, inga verksamhetsapplikationer öppnades, ingenting utöver en uppsättning inloggningsuppgifter kom i angriparens händer och ingen beständig åtkomst etablerades. Att ett offer och den grupp som försöker utpressa det är överens om händelseförloppet är tillräckligt ovanligt för att vara värt att notera.

Det är dock ingen oberoende bekräftelse. ReliaQuest är en säkerhetsleverantör som rapporterar om en incident som drabbat det egna företaget, och den version av händelserna där de egna säkerhetskontrollerna fungerade har ett tydligt kommersiellt värde. ShinyHunters har ett annat motiv som pekar i samma riktning: att offentligt genera en MDR-leverantör kan vara mer värdefullt för gruppen än ett datautbyte som den inte kan bevisa. Skärmdumparna på läckagesidan visar en kontrollpanel, inte någon dataexfiltration. Ingen oberoende part har verifierat någon av parternas uppgifter.

Gruppens svar på ReliaQuests forskningsinlägg på X bestod av tre ord: ”Who’s hunting who?”, följt av skärmdumparna. Både inlägget och svaret raderades från X, och enligt SOCRadar dök bilderna åter upp på läckagesidan den 23 augusti. ReliaQuest har avvisat påståenden om ett mer omfattande intrång och beskrivit uppgifter om att incidenten skulle ha varit en ransomware-attack som felaktiga.

Pandora mötte samma grupp via en tredje part

Nordisk exponering mot ShinyHunters är inte hypotetisk. Danska Pandora skrev i augusti 2025 till sina kunder att viss information hade nåtts via en tredjepartsplattform som bolaget använder, begränsat till namn och e-postadresser, utan lösenord eller betaluppgifter. Pandora namngav inte gruppen. BleepingComputer kopplade händelsen till ShinyHunters kampanj mot företags Salesforce-miljöer samma sommar, där också Chanel, Adidas, Qantas och Allianz Life fanns bland de drabbade.

Google Threat Intelligence, som spårar gruppen som UNC6040, dokumenterade metoden i juni 2025: ett telefonsamtal där angriparen utger sig för att vara intern IT, därefter inloggningsuppgifter och MFA-tokens som lämnas över frivilligt. Ett år senare används samma metod mot ett bolag vars produkt är att upptäcka den. Har ni ett känt varumärke och en helpdesk hos en leverantör finns ni redan på listan.

Sök efter ert eget namn under .claims den här veckan

Registrering av en domän som liknar den äkta är offentlig information. Certificate transparency-loggar visar en ny .claims-domän med företagsnamnet eller förkortningen, oftast inom några timmar från att certifikatet utfärdats. Lägg till de nyare generiska toppdomänerna i den bevakning av typosquatting ni redan har. För en månad sedan stod .claims på nästan ingens lista.

Fyra kontroller avgör om ett lyckat phishing-försök blir en incident:

Phishing-resistent MFA, FIDO2 eller passkeys, på identitetspaneler och samtliga administrativa konton. En push-notis kan inte skilja en kopierad SSO-sida från den äkta.
Device trust, eller motsvarande villkorad åtkomst för hanterade enheter, tillämpad på alla applikationer och inte bara de viktigaste. Det var den kontrollen som höll hos ReliaQuest.
Larm när en ny autentiseringsmetod registreras. Angripare försöker med det inom minuter efter att de tagit över en session.
Återuppringning från helpdesk till ett nummer ur den interna katalogen, även när den som ringer namnger en verklig kollega, eftersom det var precis vad som hände i den här kampanjen.

ReliaQuest publicerade en teknisk redogörelse för angreppet dagen efter att det inträffade, snabbare än de flesta bolag klarar och värt att kopiera. Den anställda som godkände notisen gjorde exakt vad push-notiser lär användare att göra. Kontrollen som stoppade angreppet konfigurerades långt innan telefonen ringde.