Én ubeskyttet server afslørede tre Microsoft 365-phishing-kampagner

I juli 2026 afslørede to parallelle opdagelser en bølge af avancerede phishing-angreb mod Microsoft 365, der omgår multi-faktor-godkendelse (MFA) ved hjælp af to fundamentalt forskellige metoder: adversary-in-the-middle (AiTM)-proxyangreb og misbrug af device code-godkendelse. Den første opdagelse kom fra en enkelt angribers fejl – en fejlkonfigureret Python-webserver, der eksponerede tre igangværende kampagner. Den anden kom fra forskere, der sporede en ny kommerciel phishing-platform kaldet Forg365. At forstå, hvordan hvert angreb fungerer, er det første skridt mod at implementere de rigtige forsvar, fordi løsningen på det ene ikke stopper det andet.

Den fejlkonfigurerede server, der afslørede tre Evilginx-operationer

Den 13. juli 2026 afdækkede forskere fra det franske sikkerhedsfirma Lexfo tre aktive Evilginx-baserede phishing-operationer mod Microsoft 365, efter en angriber efterlod en Python-webserver eksponeret på en offentlig port med mappelisting aktiveret. Kommandoen

python3 -m http.server 8080

Alle tre operationer var Evilginx-baserede AiTM-phishing-kampagner, der proksede Microsoft 365-loginsider for at stjæle sessionstokens, efter brugeren havde gennemført MFA . En af de tre kampagner havde logget 218 opsamlede konti på tværs af 12 lande, hvoraf 94% var virksomheds-postkasser . Operationerne brugte to forskellige angrebsveje: Evilginx-sessionstokentyveri (via en AiTM-proxy) og device code-phishing – et kit sendte ofrene til den rigtige Microsoft-enhedsloginside, hvor de selv godkendte adgangen, og angriberens backend pollede efter tokenet .

Forg365: En kommerciel Phishing-as-a-Service-platform

Separat blev Forg365 phishing-as-a-service (PhaaS)-platformen identificeret af ZeroBEC-forskere (rapporteret 9.–13. juli 2026) som et kommercielt Telegram-distribueret kit, der koster $400 om måneden (eller $3.800 om året). I modsætning til de tilpassede Evilginx-forgreninger, der blev fundet på den eksponerede server, samler Forg365 flere angrebsmetoder og værktøjer i et enkelt operatør-dashboard .

Forg365 kombinerer tre kerneegenskaber:

• AiTM-proxying – en transparent reverse proxy, der fanger sessionstokens, efter brugeren har gennemført MFA
• Device code-phishing – misbruger Microsofts legitime OAuth-device code-flow, hvilket betyder, at brugeren gennemfører godkendelse på en ægte Microsoft-side uden at angriberen nogensinde ser deres adgangskode
• AI-assisteret lokkemadgenerering – bruger AI til at skabe overbevisende phishing-e-mails og landingssider, der efterligner SharePoint, OneDrive, DocuSign og Adobe Acrobat Sign

Platformen inkluderer også antibot-evasionsdetektering (opdager sandkasser og sikkerhedscrawlere), adgang til postkassen efter kompromittering (operatører kan gennemse og eksfiltrere e-mail fra panelet), SMTP-rotation og kampagneplanlægning .

Ét angreb stjæler tokens efter MFA; det andet misbruger en legitim protokol

Disse to opdagelser illustrerer den kritiske forskel mellem AiTM-proxyangreb og device code-misbrug. At forstå forskellen er afgørende, fordi det samme forsvar ikke virker for begge:

• AiTM-proxyangreb (Evilginx-stil): Angriberen opsætter en falsk loginside, der prokser trafik til den rigtige Microsoft-lognside. Brugeren indtaster deres adgangskode og gennemfører MFA på angriberens proxy. Efter vellykket godkendelse udsteder Microsoft en session-cookie til det, det tror er brugerens browser – men den cookie lander faktisk i angriberens proxy, ikke brugerens browser. Angriberen kan derefter genafspille cookien for at få adgang til offerets Microsoft 365-konto .

• Device code-phishing: Angriberen genererer en legitim Microsoft-enhedskode (en kort kode, der bruges til at logge ind på enheder uden tastatur, som smart-tv'er) og sender den til offeret i en phishing-e-mail. Offeret besøger den rigtige Microsoft-loginside, indtaster koden, gennemfører MFA og godkender angriberens applikation. Intet "omgås" – offeret har godkendt adgangen. Angriberens backend poller derefter Microsoft efter tokenet .

Anbefalede forsvar: Hvilke kontroller stopper hvert angreb

Forsvar mod adversary-in-the-middle-proxyangreb (Evilginx-stil)

Det enkeltstående mest effektive forsvar mod AiTM-proxyangreb er phishing-resistent MFA, specifikt FIDO2/WebAuthn og passkeys. Disse binder legitimationsoplysninger til det legitime domænenavn, så når brugerens browser opretter forbindelse til angriberens proxyside (som har et andet domæne), registrerer godkendelsesprotokollen domæne-uoverensstemmelsen og blokerer automatisk legitimationsudvekslingen .

Andre forsvar inkluderer:

• Conditional Access-politikker (Entra ID): Kræv enhedsoverholdelse og betroede lokationskrav for at blokere token-udstedelse fra upålidelige proxyservere
• Continuous Access Evaluation (CAE): Muliggør næsten-realtids-tilbagekaldelse af tokens, når risikable forhold opdages
• Overvåg unormal token-brug: Se efter tokens, der bruges fra en anden IP eller et andet land, end hvor de blev udstedt, umulige rejser og "ukendte loginegenskaber"
• Bloker nyligt registrerede phishing-domæner: Overvåg domæner registreret inden for de sidste 30 dage, der opløses til kendte hosting-IP-intervaller, der bruges til phishing-infrastruktur

Forsvar mod device code-godkendelsesmisbrug

Device code-phishing kræver ikke, at angriberen narrer offeret til at indtaste legitimationsoplysninger på en falsk side – brugeren interagerer med den rigtige Microsoft-loginside. Det betyder, at FIDO2/passkeys alene ikke fuldt ud beskytter mod dette angreb, fordi det legitime OAuth-flow bliver brugt .

Det primære forsvar er at blokere device-code OAuth-grant for brugere, der ikke har brug for det, ved hjælp af Microsoft Entra ID Conditional Access:

• Opret en politik ved hjælp af betingelsen "Godkendelsesflows" for at blokere device code-flow for alle brugere undtagen en dokumenteret undtagelsesgruppe
• Før blokering, kør i report-only-tilstand eller tjek historiske logningslogfiler for at identificere legitim brug af device code (f.eks. smart-tv'er, mødelokaleenheder)
• Planlæg en Device Registration Service (DRS)-undtagelse, fordi blokering af device code-flow kan forstyrre Autopilot og Windows-enhedstilmelding

Yderligere forsvar:

• Begræns app-samtykke og OAuth-grant-omfang: Begræns, hvilke apps der kan bruge device code-grants, og revider regelmæssigt godkendte applikationer
• Implementer phishing-resistent MFA også for device code-flow: Selvom det ikke er en komplet løsning, reducerer FIDO2-hardwarenøgler eller certifikatbaseret godkendelse stadig angrebsoverfladen

Bundlinjen

FBI's offentlige service-meddelelse fra maj 2026 om Kali365 PhaaS-platformen anbefalede specifikt at blokere device code-flow som det primære forsvar . Efterhånden som phishing-platforme som Forg365 fortsætter med at kommercialisere disse angrebsteknikker, er det operationelle hastværk for forsvarere klart: implementer FIDO2/passkeys for alle privilegerede konti for at stoppe AiTM-proxyangreb, og brug Conditional Access til at deaktivere device code-grant for brugere, der ikke har brug for det. Én åben mappe eksponerede måske tre kampagner – men lektionerne gælder for alle Microsoft 365-lejere.