Blog

Vi er sikre, for vi har MFA – men er det virkelig nok?

Angriberen behøver ikke engang at hacke dig – det er bare at logge sig på og få adgang.

Er klassisk MFA nok i 2025?

Din første indskydelse er nok ”selvfølgelig er det det”. Vi har sørget for, at alle vores brugere skal autentificere med en MFA-løsning, når de tilgår virksomhedens ressourcer internt eller i en SaaS-applikation.” Selvfølgelig har I sørget for, at man ikke kan blive godkendt igennem den mindst sikre og regulerede beskedtjeneste, SMS – ikk?

Når vi taler om Multi-Faktor Autentifikation (MFA), tænker de fleste nok på den basale opsætning. Altså en kode sendt til din telefon eller via en app, der genererer en engangskode. Men er det virkelig nok, når vi skriver 2025 i kalenderen?

Jeg vil vove at påstå, at mange virksomheder ikke tænker MFA eller login-sikkerhed i dybden. Vi konfigurerer det, og så glemmer vi det igen – fire and forget-metoden, for det virker jo? Og det er så ærgerligt, for det kræver ikke nødvendigvis særlig mange ressourcer, og ofte er det allerede inkluderet i de fleste moderne MFA-løsninger som Cisco Duo eller Microsoft Entra ID.

Men hvorfor burde man overveje at harden’e sine løsninger? Hvad er det blandt andet vi ikke allerede sikrer os mod? Det vil jeg gerne komme med et bud på i dette blogindlæg, hvor jeg vil forklare om én af de mange årsager til, at I burde få vendt tilbage til konfigurationen, både jeres MFA samt login / Entra-løsning og lave et par justeringer – nemlig konceptet ’Token Theft’.

Vi har MFA, så hvorfor skal jeg være bekymret?

Først og fremmest så er det et reelt problem, og mange virksomheder er ikke klar over at disse angreb er mulige – selv hvis man har MFA-konfigureret. Langt de fleste ondsindede angreb med blandt andet Token Theft kan forbigå simple MFA-løsninger, og derved lever mange med en falsk sikkerhed.

Når jeg læser om diverse phishing-angreb eller kompromitterede konti indenfor nyere tid, så er det ret tit, at jeg ser, der er brugt metoder som phishing kombineret med Token Theft til at lure oplysninger og adgange – og mange virksomheder står tilbage med spørgsmålet; ”Vi bruger jo MFA? Hvordan kan de komme udenom denne sikkerhedsforanstaltning?”

Og for at gøre tingene endnu værre, så kræver det ikke særlig meget viden eller tid at opsætte et sådant system. Der findes sågar flere af disse løsninger direkte offentlig tilgængelige, og en hver person eller ’script kiddie’ (en uerfaren hacker, der bruger andres værktøjer uden at forstå, hvordan de virker) kan opsætte dette indenfor meget få timer.

Hvad er Token Theft?

Token theft handler helt basalt om at stjæle din ”identitet”, og ved hjælp af din ’token’ kan en ondsindet udgive sig for at være dig uden at skulle angive login-oplysninger eller blive spurgt efter MFA.

Forestil dig, at du har en nøgle til dit hus. Hvis nogen stjæler den nøgle, kan de gå ind og ud af dit hus, som de vil, uden at du ved det. Selvom dit alarmsystem også skal slås fra, har du været så smart at konfigurere systemet til automatisk at slå fra, når din telefon er i nærheden, så du ikke behøver at bekymre dig om at slå det fra, når du kommer hjem. Det samme gælder for session tokens. Hvis en hacker får fat i din token, kan de få adgang til dine data og ressourcer, som om de var dig – oftest uden nogen stiller spørgsmål.

Der er flere måder at udføre disse tyverier på. Den letteste og mest almindelige metode er gennem et ‘adversary-in-the-middle’-angreb. Praktisk set opretter angriberen en ondsindet hjemmeside, hvor de typisk gennem phishing lokker brugerne til at logge ind på den pågældende hjemmeside – ofte ligner den f.eks. Office365 login-siden én-til-én. Derefter sendes brugeren videre til en rigtig Office365-side, hvorved brugeren ikke nødvendigvis finder det mistænkeligt.

Men fordi angriberen var mellem brugeren og Office365 i dette tilfælde, betyder det også, at de har kunnet se alt, der blev sendt imellem dem. Derved har angriberen nu loginoplysningerne, men de har samtidig også den token, som bliver udvekslet mellem brugeren og Office365. Angriberen kan nu genbruge denne token til at få adgang til de samme ressourcer som den legitime bruger.

Selv da brugeren fik en MFA-prompt, har angriberen været lusket, og sørget for at alting så helt normalt ud. Men det bagved liggende system har blot videresendt denne forespørgsel, og derved har det set legitimt ud for brugeren og Office365-loginsystemet.

Men hvad er en Token?

Før vi kan kæde alting sammen, lad mig forklare, hvad en “token” egentlig er. Der findes mange forskellige slags tokens, men lad os holde det simpelt.

Grundlæggende er en token en midlertidig tilladelse, der giver dig adgang til specifikke ressourcer. For at få en token skal vi logge ind med vores brugeroplysninger gennem en såkaldt ’identity provider’ (idP), som f.eks. Microsoft Entra ID. Når idP’en godkender vores oplysninger, udsteder og sender den en token tilbage til brugeren. Denne token beskriver, hvem vi er, og hvilke rettigheder vi har – det er vores nøgle til at få adgang til de ønskede ressourcer.

Når vi derefter vil tilgå en applikation eller ressource, fremviser vi blot vores nyligt udstedte token. Baseret på denne token får vi tilladelse til at bruge tjenesten.

Dette er fantastisk for brugeroplevelsen, da vi ikke hele tiden behøver at indtaste vores oplysninger. Token’en klarer det for os. Problemet opstår, hvis denne token kommer i de forkerte hænder og vi ikke har sikret brugen af token’en ordentligt.

Lad os tage et spadestik dybere

Nu har vi sat barren for hvad Token Theft er, samt hvad og hvordan en token fungerer i praksis. Lad os prøve at tage et spadestik dybere i teknikken, og se hvordan det egentlig fungerer sammensat.

Angriberen skal i første omgang oprette en hjemmeside, hvorved brugerne skal lokkes hen. Den lette og offentlig-tilgængelige løsning, som næsten virker ’out-of-the-box’, ville være at opsætte en ’EvilGinx’ server med dertilhørende ’phishlet’ specifikt til f.eks. Office365. Herefter oprettes der et domæne, som brugerne lures hen til, samt et offentligt certifikat der stoles bredt på.

Efterfølgende er der lidt forskellige måder at lokke brugerne hen på den ondsindede EvilGinx hjemmeside – det kunne være gennem traditionel phishing, hvor brugeren klikker ind på den ondsindet hjemmeside.

Hjemmesiden ligner Office365 login siden, bruger indtaster sine oplysninger og får sin MFA-prompt. Derefter bliver der automatisk omdirigeret til den ’rigtige’ Office365 side.

I mellemtiden har EvilGinx-serveren sørget for at opsamle brugeroplysninger og den token, som blev sendt tilbage fra Microsoft – alt imens den selvfølgelig har sendt de rigtige oplysninger til Microsoft også – blot fra den ondsindet server og ikke direkte fra brugeren.

Ovenfor ses et illustreret eksempel på hvordan workflowet ser ud. I dette tilfælde har jeg blot indsat en fiktiv Conscia-server, samt en fiktiv Conscia-loginserver – princippet er helt det samme med Office365.

Hvordan kommer vi videre herfra?

Heldigvis findes der et hav af muligheder, som kan hjælpe os godt på vej, så vi forhåbentlig ikke ender i en sådan situation som beskrevet. I langt de fleste tilfælde betaler virksomhederne også for mange af de funktioner, vi kan gøre brug af – de har bare ikke aktiveret og taget stilling til dem.

Der er mange tiltag en virksomhed kan tage i dette henseende. Nedenfor vil jeg komme med et udpluk – disse er både relevante for MFA-løsninger, men også specifikt i blandt andet Microsoft miljøer.

Overvågning

At have sat de rigtige politikker og alarmer op kan hjælpe med at skabe indsigten, når et uheld er ude.

Opsæt politikker så der alarmeres, når én eller flere af følgende ting sker:

• Device enrollment: Hold øje med nye enheder der pludselig er opkoblet til jeres Entra ID. Med de rigtige rettigheder giver dette megen adgang.
• Email regler: Hvorfor blev der oprettet en email-regel, der videresender mails udenfor vores organisation?
• MFA-ændringer: Som med device enrollment, så hold øje med nye MFA-opkoblinger – dette er ofte et overset, men utrolig let sted at beholde adgang.
• Unormale sign-ons: Hold øje med underlige lokationer og hurtige lokationsskift. Carsten loggede ind i Danmark og en time senere fra Kina – det er ikke fysisk muligt at rejse så hurtigt.

Vigtigst af alt: overvåg og reagér på disse alarmer og hændelser – enten gennem jeres egen SIEM-løsning eller få et professionelt firma, som Conscia, til at holde øje og reager for jer.

/

Tekniske foranstaltninger

Udover at alarmere på hændelser kan vi også indsætte nogle tekniske foranstaltninger, som gør det svære for angriberne at tilluske sig adgange. Nogen er relativ ligeud ad landevejen, og andre kræver lidt større overvejelser – men fælles for dem alle er, at de højner jeres sikkerhedsniveau.

Opsæt tekniske politikker såsom:

• Tokens levetid: Tokens kan ofte være valide i op til 24 timer. Ved at sænke levetiden begrænses det, hvor længe en kompromitteret token kan bruges. For eksempel kan man vælge at sætte levetiden til 8 eller 9 timer, så den dækker en typisk arbejdsdag, hvilket giver en god balance mellem sikkerhed og brugervenlighed.
• Device trust: Sørg for, at kun godkendte og sikrede enheder kan tilgå virksomhedens ressourcer.
• Risiko baseret styring: Evaluér løbende adgange og styr sikkerheden, hvis der sker unormale adfærdsmønstre – f.eks. pludselig ny enhed, et nyt land eller anden lokation indenfor kort tid. Kræv derved flere oplysninger fra brugeren.
• Conditional Access: I kombination med risko-baseret styring, kan du oprette adgange med strenge krav til lokation og enheder – endda baseret på tjenesten eller servicen der bruges.
• Token binding: Ved at bruge dette sikres der at token kun kan bruges på den enhed, som den blev udstedt til.

En helt anden vej man kan gå er ved at implementere en FIDO2 (Fast Identity Online) authenticator. FIDO2 standarden bruger en offentlig nøglekryptografi, som vil kunne beskytte mod sådanne angreb.

Når en bruger registrerer sig med en FIDO2 enhed, genereres der to sæt nøgler – en offentlig nøgle og en privat nøgle. Den offentlige nøgle deles, mens den private forbliver sikkert på brugerens enhed.

Når brugeren forsøger at logge ind på et system, bliver den bedt om at bevise, hvem den er, hvilket kun kan gøres med brugerens egen unikke private nøgle. På denne måde er det et ekstra og sikkert værn mod f.eks. Token Theft eller lignende phishing-angreb.

De afsluttende og opsummerende ord

Jeg håber ikke, at jeg har taget alt håb og pusten fra dig, men derimod har jeg inspireret og fået dig til at gentænke den måde din organisation laver login og MFA-sikkerhed på.

Det er også værd at understrege, at der naturligvis findes mange andre metoder derude. Jeg har blot taget udgangspunkt i én af dem, som jeg i øjeblikket ofte støder på og ser i felten. Og selvom mine forslag specifikt retter sig mod Token Theft-scenariet, vil det stadig være en fordel at overveje implementeringen af de nævnte foranstaltninger generelt, da de kan styrke sikkerheden på tværs af flere angrebsmetoder.

I mit tilfælde nævner jeg, at ’angrebsmetoden’ var en traditionel phishing, som brugeren hoppede i. Dertil er det selvfølgelig også vigtigt at nævne, at vi kan implementere andre sikkerhedsløsninger som kan hjælpe os til selve phishingdelen.

Blandt andet ved at implementere en ordentlig e-mail sikkerhedsløsning, samt udnytte DNS sikkerhed som er utrolig let at sætte op, men giver værdi fra dag ét – f.eks. Cisco Umbrella DNS- eller Cisco Secure Email-sikkerhed

Hos Conscia har vi jeres ryg – uanset om det gælder rådgivning, teknisk implementering eller overvågning. Så tøv ikke med at række ud til enten din Account Manager eller direkte til mig.

Om forfatteren