Det har blitt en stund siden første gang jeg pratet om viktigheten av å ta i bruk moderne autentiserings-løsninger. Som Entra ID med protokoller som SAML og OIDC. Viktigheten av å eliminere de gode gamle autentiseringsprotokollene som LM/NTLM og kerberos som "on-prem" Active Directory er bygget på.
Dette er blant annet begrunnet med og heller tvinge angripere til å måtte bryne seg på sikrere og mer robuste løsninger etter dagens standard, om de skal lykkes med sine angrep.
Underforstått at angriperne etter hvert vil rette seg mot og finne ut hvordan de både kan angripe og lykkes med å kompromittere også disse mer moderne autentiserings teknologiene.
Dette begynner vi å se tendensen av nå.
I det siste har vi sett stadig flere eksempler av "Adversary in the middle"-angrep (AiTM) for å stjele en" browser session cookie". For så gjenbruke denne "browser cookien" for å vellykket kunne logge på den samme tjenesten fra en helt annen browser, klient og til og med lokasjon. Helt uten å bli "promptet" for brukernavn/passord eller til og med MFA selv om det er aktivert på kontoen.
Dette gjelder alle tjenester som benytter samme autentiseringsmekanisme. Som Office 365, Facebook, Instagram, Google, og så videre. Eller nærmest en hvilken som helst annen SaaS tjeneste.
– Forbered deg på å bli hacka i jula!
Hvordan fungerer det?
For å utføre et slikt angrep benyttes en proxy server som "Adversary in the middel"-tjenesten, eller "Man in the middle" om du vil. Denne tjenesten trenger så en offentlig gyldig lenke. En lenke som er lik nok den originale URL-en til tjenesten du forsøker og lure deg tilgang til.
Så lik at en bruker kan la seg lure uten å se forskjell. Så må denne linken spres til brukere, gjerne per epost. Og brukerne må la seg lure til å klikke på linken og logge inn i tjenesten.
Lykkes du med dette vil proxy-tjenesten som står i midten være i stand til å fange opp "browser session cookien" som blir skrevet.
Denne cookien inneholder all informasjon som trengs til å fortelle tjenesten at du er autentisert ok. Og kan med det gjenbrukes i en annen browser-sesjon for å gjenskape en ferdig autentisert sesjon til tjenesten det gjelder.
Det hele fungerer helt uten å ha vært i nærheten av eller først ha lykkes med å kompromittere klienten til brukeren.
Proxy-tjenesten som trengs har nærmest blitt hyllevare.
Evilgnix kan lastes ned og installeres på en standard Linux eller Windows maskin. Du trenger tilgang på et domene som kan benyttes til å lage falske URL-er. Ellers finnes det mange ferdige konfigurasjonsmaler for de mest kjente tjenestene. Som Office365, Google, Facebook, Instagram, og så videre.
Eller du kan rett og slett bare kjøpe tid på en "public phishing-as-a-service"-tjeneste, som Evilproxy. Velg din phishinkampanje og sett i gang. Ingen forkunnskaper om konfigurering og så videre er nødvendig.
I Microsoft Digital Defense Report som ble sluppet i Oktober 2023 kan man lese mer om disse tjenestene og det store omfanget man ser at de benyttes.
Det siste har gjort at oppblomstringen av AiTM angrep har vært så massiv. Microsoft sier i sin Digital Defense Report at de ikke lenger sporer trusselaktørene som driver med phisihingkampanjer, fordi det er så mange av dem, men heller tjenestene som selger disse kampanjene.
Etter suksessfull phishing sitter man igjen med et sett med loggført sesjoner, men brukernavn, passord, "session cookie" og så videre.
Men alt man trenger er å ta "session cookie"-informasjonen, lime det inn som en "session cookie" i en helt ny browser, på en helt ny klient, og så er man logget inn uten spørsmål om verken brukernavn, passord og ikke engang MFA.
Hvordan kan man beskytte seg?
Ha god "Single Sign-on"-hygiene.
Det er noen åpenbare svakheter med et slikt AiTM phishing angrep.
- Du må klare å lure brukeren til å klikke på en ondsindet "look-a-like"-link.
- Brukeren må akseptere en "login prompt" og gjennomføre en autentisering.
Om brukeren er vant med god SSO hygiene i sitt vante miljø, vil brukeren stusse hvis det plutselig dukker opp en "login prompt" fra Office 365. Kanskje nok til at brukeren avbryter og mistenker at det er noe på ferde.
Om brukeren derimot er vant til at innlogging med brukernavn og passord, sågar kanskje MFA, kreves i nesten en hver situasjon. Så vil det ikke være noe unormalt ved at det dukker opp en "login prompt" denne gangen også. Dermed mye lettere å lure brukeren.
Bruk "Require device to be marked as compliant" i "Conditional Access".
Dette vil være en effektiv blokker for at angrepet blir vellykket i første omgang.
I det man stiller krav til at enheten skal være "compliant" betyr det også at man må identifisere enheten. Dette gjøres i "Conditional Access" ved hjelp av klient sertifikat-autentisering. Når du registrerer eller joiner en enhet i Entra ID vil den få tildelt et sertifikat som brukes til identifisering senere.
Når du i tillegg krever "compliant device" i "conditional access" vil du kunne se i autentiseringsflyten at du er innom devicelogin.microsoft.com.
Her må dette klient sertifikatet presenteres for at enheten skal bli identifisert og autentisert.
Står det en proxy i mellom, med full SSL terminering og re-etablering på den andre siden – som vil være nødvendig for å få tilstrekkelig innsikt i trafikken mellom browseren og tjenesten til å kunne fange opp "session cookien" – vil denne enhetsautentiseringen feile. Proxyen som står i midten har tross alt byttet ut enhetssertifikatet med et eget regenerert sertifikat som ikke vil bli godtatt av Entra ID.
Brukeren vil dermed få opp samme melding som om forespørselen hadde kommet fra en ikke-compliant device og dermed bli blokkert fra innlogging. Og med det heller ingen "session cookie" på avveie.
Bruk phising resistant MFA metode.
Passordløs pålogging med authenticator appen eller nummer matching vil ikke hjelpe.
Det som vil hjelpe er bruk av FIDO2 sikkerhetsnøkler (og Windows hello – også pga SSO) og "Entra ID Certificate Based authentication". Begge er pishing-resistente MFA metoder.
På sikt kan man se for seg og trolig vente at det vil komme flere alternativer som er phishing-resistent.
Felles for de phishing resistante autentiseringsmetoden er at de kryptografisk knytter autentiserings sesjonen til maskinen. Og/eller url’en til tjenesten det autentiseres med.
Certificate Based Authentication bruker "mutual TLS". Står det en proxy som terminerer SSL/TLS i mellom vil denne TLS-tunnelen ikke la seg etablere og autentiseringen feiler. Phishing-angrepet blir med det avverget.
Skru på "Token protection" i Conditional Access
Dette er en ny mulighet som har kommet i Conditional Access. "Token protection" vil knytte autentiseringstokenet som utstedes til maskinen det utstedes på. Det betyr at selv om noen er i stand til å fange opp tokenet, vil det ikke være til nytte på noen annen maskin.
Det vil ikke være mulig å gjenskape en ferdig autentisert sesjon på noen annen maskin med dette tokenet.
Dessverre er det en stor begrensning for bruk av token binding i "conditional access" per i dag. Det fungerer kun på Windows maskiner og det vil kun fungere for Exchange online og Sharepoint Online. Forhåpentligvis vil man se en utvidelse av dette etter hvert, og med det vil "token binding"-settingen være en viktig sikkerhetsmekanisme.
Avslører alt: Se hvor lett du lurer en GPT
Vurder Entra Internett Access / Global Secure Access
Entra Internet Access er en ny tjeneste fra Microsoft som ble lansert i "public preview" sommeren 2023. En av tingene som fremheves er beskyttelse mot "token theft".
Løsningen fungerer i form av å gi en sikker kommunikasjonskanal fra klienten, via Microsoft’s Global nettverk til den tjenesten som ønskes, for eksempel Office 365. I tillegg kan beskyttes det hele med "Conditional Access". Både ved etablering av kommunikasjonskanalen, og ved tilgang til selve applikasjonen. Da kan man enkelt konfigurere det slik at om henvendelsen ikke kommer fra en "Compliant Network location" får du ikke tilgang til applikasjonen.
Det betyr også at ved et phishing-angrep, men en proxy-tjeneste i midten. Vil plutselig forespørselen til applikasjonen ikke lenger komme fra en godkjent nettverks-lokasjon. Tilgangen blir dermed blokkert, og phishing-angrepet avverget.
Dataangrepet mot Tomra kostet 200 millioner kroner
Deteksjonsmulighetene som finnes
Microsoft Entra Identity Protection
I Entra Identity Protection detekteres det om et autentiseringstoken plutselig blir gjenbrukt på en annen maskin eller en annen lokasjon. Sørg for å ha gode policyer på plass som i de tilfellene vil re-kreve en MFA autentisering eller blokkere brukeren.
Så vidt jeg vet er denne deteksjonen i samarbeid med Defender for Cloud Apps, så pass på at den er i bruk i tillegg. Primært gjøres deteksjonen når tokenet brukes for tilgang til Office365 (Exchange online).
I tillegg har det kommet deteksjoner basert på Threat intelligence i Identity Protection. Her vil det trigges alarmer om det detekteres et påloggingsforsøk som kommer fra en kjent phishing-tjeneste-IP.
Microsoft 365 Defender
Microsoft 365 Defender konsollen vil selvfølgelig vise de deteksjonene som blir gjort i for eksempel "Identity protection".
I tillegg knytte disse til andre alarmer og vise hele hendelsesforløpet, om det eksisterer andre relevante alarmer fra andre deler miljøet.
Microsoft 365 Defender har også fått "automatic attack distruption"-muligheter for phishing angrep. Hvis det kjennes igjen at en bruker logger inn fra en kjent phishing-IP og vellykket tilfredsstiller MFA, vil denne brukeren automatisk bli deaktivert og "session tokens" bli tilbakekalt.
Lag egne deteksjons-regler
Ved et suksessfullt angrep, vil "SessionId" både for den påloggingen som ble gjort når "session cookien" ble stjålet og for den påloggingen som evtentuelt gjøres av angriperen senere med samme "session cookie", være den samme.
Ved å lage en KQL spørring hvor du leter etter sesjoner med samme SessionId, men hvor andre atributter har endret seg. For eksempel land, lokasjon, IP, OS, og så videre. Vil du kunne få en alarm så fort det er tegn til at en "session cookie" gjenbrukes.
Her er et eksempel på et "KQL query" som leter etter samme "SessionId", men hvor landet er forskjellig:
let OfficeHomeSessionIds = AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ErrorCode == 0
| where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application
| where ClientAppUsed == "Browser"
| where LogonType has "interactiveUser"
| summarize arg_min(Timestamp, Country) by SessionId;
AADSignInEventsBeta
| where Timestamp > ago(1d)
| where ApplicationId != "4765445b-32c6-49b0-83e6-1d93765276ca"
| where ClientAppUsed == "Browser"
| project OtherTimestamp = Timestamp, Application, ApplicationId, AccountObjectId, AccountDisplayName, OtherCountry = Country, SessionId
| join OfficeHomeSessionIds on SessionId
| where OtherTimestamp > Timestamp and OtherCountry != Country I "Advanced hunting" i Microsoft 365 Defender kan du lage en deteksjonsregel av denne spørringen. Du kan også lage en tilsvarende Analytics Rule i Microsoft Sentinel.
Triks til slutt:
Vær kreativ med Device Filtering i Conditional Access
Å være kreativ med "Device Filtering" i "conditional access" vil også kunne redusere sansynligheten for å bli kompromitert av et AiTM-angrep. Ved å sette krev til noe relatert til enheter i "Conditional Access", vil enheten måtte identifiseres. For å bli identifisert må det gjøres en autentisering, som er sertifikat-basert. Om sesjonen går igjennom en AiTM-proxy, vil denne autentiseringen feile og AiTM angrepet avverget.
Har beskrevet andre senarioer rundt Device filtrering her.
Det behøver ikke være det samme, det holder nærmest å sette krav til hvilket OS det skal være.
!! Være oppmerksom på at dette ikke er en offisiell løsning eller en løsning for å garantere sikker autentisering. Dette er å betrakte som en workaround som benyttes på egen risiko. !!
God Beskyttelse!