AiTM angrep. Hvordan gjennomføres de? Hvordan kan man beskytte seg mot disse?
Azure Open AI sammendrag av blogg-innlegget:
Blogginnlegget diskuterer fremveksten av Adversary in the Middle (AiTM)-angrep, som brukes til å stjele en nettleserøkt-informasjonskapsel og gjenbruke den for å få tilgang til den samme tjenesten fra en annen nettleser, klient eller plassering. Innlegget forklarer hvordan disse angrepene fungerer, hvordan angripere kan utføre dem, og hvordan de kan beskytte seg mot dem. Følgende er hovedpunktene i innlegget:
1. AiTM-angrep er på vei oppover, og angripere begynner å målrette mot mer moderne autentiseringsteknologier som SAML og OIDC.
2. Angrepene involverer bruk av en proxy-server for å avskjære nettleserøktens informasjonskapsel og gjenbruke den for å få tilgang til samme tjeneste fra en annen nettleser, klient eller plassering.
3. Angrepene kan utføres ved hjelp av lett tilgjengelige verktøy som Evilginx og offentlige phishing-as-a-service-plattformer.
4. For å beskytte mot AiTM-angrep bør brukere praktisere god Single Sign-On-hygiene, bruke betinget tilgang for å kreve at enheter merkes som kompatible, og bruke phishing-resistente MFA-metoder som FIDO2-sikkerhetsnøkler.
5. Tokenbeskyttelse i betinget tilgang kan også brukes for å forhindre AiTM-angrep, og Entra Internet Access kan gi ekstra beskyttelse mot tokentyveri.
6. Deteksjonsmetoder som Entra Identity Protection og Microsoft 365 Defender kan brukes til å oppdage og forstyrre AiTM-angrep.
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 middel (AiTM) angrep for å stjele en browser session cookie. For så gjenbruke denne browser cookien for og 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, etc. Eller nærmest en hvilken som helst annen SaaS tjeneste.
Hvordan fungerer det?
For å utføre et slikt angrep benyttes en proxy server som «Adversary in the middel» tjenesten, eller Man in the middel om du vil. Denne tjenesten trenger så en public gyldig link. En link som er lik nok den orginale 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 pr 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 fake url’er. Ellers finnes det mange ferdige configurasjons templates for de mest kjente tjenestene. Som Office365, Google, Facebook, instagram, etc..
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 etc er nøvendig.
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.
Microsoft Digital Defense Report 2023 (MDDR) | Microsoft Security Insider
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 etc. Men alt man trenger er å ta session cookie informasjonen, paste det inn som en session cookie i en helt nye browser, på en helt ny klient, og så er man logget inn uten spørsmål om hverken brukernavn, passord og ikke engang MFA.
Hvordan kan man beskytte seg?
Ha god Signle 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 loginprompt 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 loggin 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 devicen skal være compliant betyr det også at man må identifisere devicen. Dette gjøres i Conditional Access ved hjelp av klient sertifikat autentisering. Når du registrerer eller joiner en device i Entra ID vil den få issuet 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 devicen skal bli identifisert og autentisert.
Om det står 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 device autentiseringen feile. Proxyen som står i midten har tross alt byttet ut device sertifikatet 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 tunnel 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 pr 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 etterhvert, og med det vil token binding settingen være en viktig sikkerhetsmekanisme.
Vurder Entra Internett Access / Global Secure Access
Entra Internet Access er en nyt 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, f.eks Office 365. I tillegg kan beskyttes det hele med Conditional Access. Både ved etablering av kommunikasjonskannalen, 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.
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 konsollet vil selvfølgelig vise de deteksjonene som blir gjort i f.eks Identity protection. I tillegg knytte disse til andre alarmer og vise hele incident forløpet, om det eksisterer andre relevante alarmer fra andre deler miljøet.
I tillegg har Microsoft 365 Defender 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 den brukeren automatisk bli disablet og session tokens bli revokert.
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 evt 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. F.eks land, lokasjon, IP, OS, etc. 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 device i Conditional Access, vil devicen måtte identifieres. 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: Vær kreativ med Filter for devices i Conditional Access – Northgrove blog
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!
