Innkjøpsfellen: Slik kaprer hackere Microsoft 365-økter via kompromitterte Outlook-postkasser

Hvordan angrepet fungerer (teknisk mekanisme)

Angriperen setter opp et mellomliggende phishing-nettsted som fungerer som en levende omvendt proxy mellom offeret og den legitime Microsoft 365-autentiseringstjenesten . Når et offer skriver inn legitimasjon og fullfører MFA, fanger proxyen opp den resulterende øktkaken før den når offerets nettleser. Angriperen importerer deretter den kaken inn i sin egen nettleser og får full tilgang til offerets Exchange Online, SharePoint, OneDrive og alle tilkoblede apper .

Flere kilder beskriver den samme kjernemekanismen: proxyen skaper sanntids toveiskommunikasjon, mens tradisjonell phishing bare kloner innloggingssider og høster legitimasjon . Fordi økt-tokenet beviser at brukeren allerede har passert MFA, trenger angriperen aldri å knekke MFA-en i seg selv .

Hvorfor standard MFA ikke er nok

Microsofts egen dokumentasjon advarer om at AiTM-phishing overvinner vanlige MFA-metoder som SMS-koder, push-varslinger fra autentiseringsapper og TOTP-tokener . Øktkaken som utstedes etter at MFA er fullført, er premien: Hvis den blir stjålet, kan den spilles av fra hvilken som helst enhet, hvor som helst, frem til tokenet utløper eller blir administrativt tilbakekalt.

Infobloxs rapport understreker at tradisjonell MFA er utilstrekkelig fordi AiTM-proxyer stjeler økt-tokenet som utstedes etter at MFA er fullført . Det underliggende problemet er arkitektonisk: proxyen sitter mellom brukeren og det virkelige autentiseringsendepunktet på en måte som klassisk MFA ikke kan oppdage.

Forsvar utover MFA anbefalt av Infoblox

Infoblox anbefaler en lagdelt forsvarsstrategi som ikke stoler på MFA som et eneste feilpunkt. Deres primære anbefalinger inkluderer:

1. DNS-lagsikkerhet – Blokker kjente ondsinnede domener og nyregistrerte algoritmiske domener (RDGA) på DNS-nivå for å forstyrre phishing-infrastrukturen før brukere kan nå den .
2. Phishing-resistente legitimasjon – Implementer FIDO2/WebAuthn maskinvaresikkerhetsnøkler eller Windows Hello for Business. Disse bruker offentlig-nøkkelkryptografi bundet til en spesifikk opprinnelse. En AiTM-proxy kan ikke videresende FIDO2-utfordringer fordi den kryptografiske bekreftelsen er knyttet til det legitime nettstedets domene, ikke til proxyen.
3. Conditional Access-policyer – Håndhev strenge påloggingsrisikopoliser i Microsoft Entra ID, som å kreve tokenbinding, blokkere pålogginger fra uvanlige steder eller enheter, og forkorte øktlevetider for å redusere vinduet for kakereplay.
4. Eksponeringshåndtering og varemerkeovervåking – Proaktivt oppdage phishing-domener som utgir seg for å være organisasjonen, og fjerne infrastruktur før brukere møter agnene .
5. Sikkerhetsbevissthet og rapportering – Tren brukere til å gjenkjenne innkjøpstema-phishing-agn og rapportere mistenkelige e-poster, noe som muliggjør raskere respons fra sikkerhetssenteret (SOC).

FBI har også advart spesifikt om Kali365, og anbefalt organisasjoner å revidere sine MFA-metoder, gjennomgå påloggingslogger for unormale enhetskode-flyter, og vurdere å blokkere enhetskodeautentisering for alle brukere unntatt klarerte applikasjoner .

Bevisbegrensninger og omfang

Infoblox-rapporten er hovedkilden for kampanjens navn, målretting av EU/FN-institusjoner, og bruk av kompromitterte Outlook-postkasser og småbedriftsnettsteder. Sekundær rapportering bekrefter uavhengig målene og verktøyrotasjonen.

Kali365-komponenten er uavhengig bekreftet av FBIs PSA og av sikkerhetsleverandørene Huntress og Paubox , men Infobloxs rapport grupperer den sammen med EvilProxy og FlowerStorm under samme innkjøpstema-infrastruktur.

Forsvarsanbefalingene kombinerer direkte uttalelser fra Infobloxs rapport med veletablerte bransjestandarder dokumentert på tvers av flere kilder . Ingen enkelt avsnitt i kildene lister opp hvert forsvarspunkt i punktform; listen over syntetiserer veiledningen funnet på tvers av det siterte materialet.

Bunnlinjen

«The Procurement Trap» illustrerer en voksende trend: Trusselaktører prøver ikke å knekke MFA – de omgår den fullstendig ved å stjele øktkakene som utstedes etter vellykket autentisering. Tekniske mottiltak som FIDO2-maskinvare nøkler og DNS-nivå domene-blokkering kan betydelig redusere eksponeringen, men den første forsvarslinjen forblir brukervåkenhet. Organisasjoner som bruker Microsoft 365, bør gjennomgå autentiseringsloggene sine for uventede enhetskode- eller AiTM-mønstre og implementere phishing-resistente legitimasjon som en prioritet.