Beveiliging van Outlook Web App: Exchange beveiligen met MFA

Inleiding

De meeste discussies over beveiliging bij externe toegang beginnen met VPN. Bijna geen enkele begint met Outlook Web App, en dat is een vreemde omissie gezien wat OWA eigenlijk is: een inlogformulier voor zakelijke e-mail, dat zich op het open internet bevindt en overal, vanaf elke browser en elk apparaat, bereikbaar is. Er hoeft geen VPN-client te worden geconfigureerd, er hoeft geen firewallregel te worden omzeild, er hoeft geen netwerksegment te worden doorkruist — alleen een veld voor de gebruikersnaam, een veld voor het wachtwoord en wat de Exchange-server ook maar besluit te accepteren.

Voor een aanvaller is dat zo ongeveer de meest directe weg naar een mailbox die er maar bestaat. Een gecompromitteerde OWA-aanmelding hoeft geen laterale beweging te maken om gevaarlijk te worden — het is al meteen gevaarlijk, omdat de mailbox zelf het doelwit is. Business Email Compromise heeft geen malware nodig, geen exploit, en activeert de meeste detectietools die zijn gebouwd voor netwerkinbraken niet. Het heeft één set geldige inloggegevens nodig en een inlogpagina die om niets anders vraagt.

Waarom On-Prem en Hybrid Exchange geen gratis MFA krijgen

De verwarring hier is begrijpelijk, omdat Microsoft 365-tenants die Exchange Online gebruiken inderdaad vrijwel automatisch sterke authenticatie krijgen — Entra ID-beleidsregels voor voorwaardelijke toegang kunnen MFA op identiteitsniveau vereisen voordat er überhaupt een sessietoken wordt uitgegeven, en die bescherming strekt zich uit tot Outlook op het web zonder enige Exchange-specifieke configuratie. Beveiligingsteams die altijd alleen in een pure cloudomgeving hebben gewerkt, gaan er redelijkerwijs van uit dat MFA voor webmail gewoon de standaard is bij Exchange.

On-premises en hybride Exchange nemen dat gedrag niet over. De eigen authenticatiestack van Exchange Server — de rol ‘Client Access Services’ die OWA en het Exchange Admin Center afhandelt — valideert een gebruikersnaam en wachtwoord tegen Active Directory en, bij gebrek aan aanvullende configuratie, is dat de volledige authenticatiebeslissing. Er is geen ingebouwde tweede authenticatiefactor in de on-premises OWA-aanmelding. Hybride implementaties maken dit nog ingewikkelder: sommige mailboxen zijn mogelijk al verplaatst naar Exchange Online en vallen onder voorwaardelijke toegang, terwijl andere on-premises blijven en mogelijk nog steeds vertrouwen op het eigen authenticatiepad van Exchange Server, tenzij Hybrid Modern Authentication of een andere MFA-oplossing expliciet is geconfigureerd. Het is heel goed mogelijk dat een organisatie denkt dat haar e-mail „beveiligd is door MFA”, omdat dat geldt voor de tenant, terwijl een aanzienlijk deel van de mailboxen nog steeds achter de on-prem OWA zit, die alleen met een wachtwoord werkt.

Dit is de kloof die operationeel van belang is, niet omdat on-prem Exchange inherent minder veilig is door het ontwerp, maar omdat de verantwoordelijkheid voor het toevoegen van een tweede authenticatiefactor volledig bij de Exchange-beheerder ligt, zonder dat er een standaardinstelling is om op terug te vallen.

Wat een gecompromitteerd OWA- of EAC-account een aanvaller daadwerkelijk oplevert

De waarde van één enkele OWA-inlog is gemakkelijk te onderschatten als je het beschouwt als ‘gewoon e-mail’. In de praktijk is een gecompromitteerd mailboxaccount een voet aan de grond met verschillende afzonderlijke aanvalspaden die daaruit vertakken.

Business Email Compromise (BEC) levert financieel gezien de directe schade op.

Business Email Compromise (BEC) is financieel gezien de meest directe vorm. Het Internet Crime Complaint Center van de FBI registreerde in 2025 in de Verenigde Staten 3,046 miljard dollar aan gemelde BEC-verliezen, de op één na hoogste verliescategorie na beleggingsfraude, verdeeld over ongeveer 24.768 klachten — een gemiddeld verlies van ruim 120.000 dollar per bevestigd incident. Kenmerkend voor BEC-aanvallen is dat er geen malware en geen kwaadaardige link bij betrokken is die door een beveiligingsfilter kan worden onderschept; de aanvaller bevindt zich in een legitieme mailbox, verstuurt berichten vanaf een legitiem adres en reageert vaak binnen een bestaande thread met een gewijzigd bankrekeningnummer of een doorgestuurde factuur. Regels voor de e-mailstroom maken het moeilijker om deze techniek achteraf op te sporen — een aanvaller met toegang tot de mailbox kan een inboxregel instellen die berichten met woorden als ‘factuur’, ‘overschrijving’ of ‘betaling’ stilzwijgend doorstuurt of verwijdert, waardoor de inbreuk onzichtbaar blijft voor de accounteigenaar terwijl de frauduleuze conversatie parallel doorgaat.

Toegang via volmacht vergroot het risico nog verder.

Toegang via volmacht vergroot het risico. Assistenten van leidinggevenden en leden van het financiële team beschikken vaak over volmacht- of ‘verzenden als’-rechten voor de mailboxen van leidinggevenden als onderdeel van de normale workflow. Dit betekent dat één gecompromitteerd assistentenaccount kan worden gebruikt om berichten te versturen die lijken te zijn afkomstig van een CFO of CEO, zonder dat de inloggegevens van die leidinggevende ooit in aanraking komen.

Gegevensblootstelling is het stille risico

Gegevensblootstelling is het stille risico, en vaak het risico met de grootste gevolgen voor gereguleerde organisaties. Een mailbox bevat jaren aan bijlagen, interne memo’s, HR-correspondentie en communicatie met klanten, die allemaal toegankelijk zijn via de eigen interface van OWA zodra een aanvaller is geauthenticeerd — er is geen aparte tool voor gegevensdiefstal nodig, omdat de aanvaller de inhoud van de mailbox kan openen en downloaden met behulp van legitieme OWA-functionaliteit.

Aanpak 1: MFA rechtstreeks toegepast op OWA- en EAC-aanmelding

De meest gerichte oplossing pakt het specifieke risicovlak aan zonder iets anders aan te raken dat verbonden is met Active Directory. MFA voor Outlook Web App en het Exchange Admin Center wordt geïnstalleerd als een component binnen de Exchange Client Access-servicerol, en wordt voor de bestaande OWA- en EAC-inlogpagina’s geplaatst in plaats van het authenticatiemechanisme van Exchange volledig te vervangen. Na installatie verifiëren gebruikers zich eerst met hun normale AD-gebruikersnaam en wachtwoord, waarna ze een tweede verificatiestap doorlopen — bijvoorbeeld door een eenmalige code (OTP) uit een authenticator-app of hardwaretoken in te voeren, of door een pushmelding goed te keuren — voordat de sessie wordt toegestaan.

De reikwijdte wordt tijdens de installatie ingesteld via het lidmaatschap van een Active Directory-groep: een beheerder kan MFA onmiddellijk voor alle gebruikers verplicht stellen, of het in eerste instantie inschakelen voor één enkele AD-groep – een pilotgroep, of specifiek de groep die toegang heeft tot het Exchange Admin Center – terwijl de bredere uitrol wordt gepland. Dat onderscheid is in de praktijk van belang, omdat EAC-accounts aanzienlijk meer organisatorische risico’s met zich meebrengen dan een individuele mailbox; een beheerdersaccount met toegang tot het EAC kan regels voor de e-mailstroom aanmaken, machtigingen wijzigen of gegevens exporteren binnen de gehele Exchange-omgeving, en dat is precies de reden waarom het beveiligen van EAC-aanmeldingen doorgaans prioriteit heeft, zelfs als de volledige uitrol naar alle gebruikers meer tijd in beslag neemt.

Het sessiegedrag is configureerbaar en niet vastgelegd. Beheerders stellen in hoe vaak gebruikers opnieuw om een nieuwe OTP worden gevraagd — bijvoorbeeld eens per 12 uur bij continu gebruik van OWA — waarbij een afweging wordt gemaakt tussen de hinder van herhaalde authenticatie en het risico van een langdurige, onbeheerde sessie op een gedeeld of onbeheerd apparaat. De component ondersteunt HOTP, TOTP en het challenge-response-systeem OCRA, wat flexibiliteit biedt voor organisaties die verschillende soorten OTP-tokens gebruiken.

Aanpak 2: MFA op Active Directory-niveau, waarbij OWA samen met al het andere wordt gedekt

Een meer specifieke vraag die het waard is om te stellen voordat de OWA-specifieke component wordt geïmplementeerd: is OWA daadwerkelijk de enige met AD verbonden dienst die nog steeds uitsluitend op basis van een wachtwoord authenticeert? Voor de meeste on-prem-omgevingen is het eerlijke antwoord nee — Winlogon, RDP en vaak ook interne, aan LDAP gekoppelde applicaties bevinden zich in dezelfde situatie, beschermd door niets meer dan het wachtwoordbeleid dat AD afdwingt.

Meervoudige authenticatie op directoryniveau pakt die bredere kwetsbaarheid aan door te integreren in Active Directory zelf in plaats van op de inlogpagina van elke afzonderlijke dienst. In plaats van een reeks afzonderlijke MFA-implementaties – één component voor OWA, een andere agent voor RDP, een RADIUS-proxy voor VPN, die elk afzonderlijk moeten worden geïnstalleerd, geconfigureerd en onderhouden – verandert een integratie op directoryniveau de manier waarop gebruikersgegevens in Active Directory werken door statische wachtwoorden te vervangen door tijdgebonden dynamische wachtwoorden, zodat met AD verbonden diensten dezelfde dynamische inloggegevens kunnen gebruiken zonder dat voor elke dienst afzonderlijke MFA-componenten nodig zijn. OWA valt hieronder, niet omdat het specifiek het doelwit was, maar omdat het, net als al het andere dat op AD is gericht, nu aan dezelfde dynamische inloggegevenscontrole moet voldoen.

De afweging loopt in de tegenovergestelde richting van Aanpak 1: bredere dekking in ruil voor een ingrijpender verandering in hoe AD-authenticatie zich in de hele omgeving gedraagt, wat doorgaans meer doordachte tests en een gefaseerde uitrol vereist dan bij een OWA-component voor één enkele dienst het geval is. De juiste keuze tussen de twee hangt echt af van de omvang — een organisatie waarvan OWA het enige onbeschermde, met AD verbonden oppervlak is, hoeft de directory niet aan te raken om dat te verhelpen; een organisatie die ontdekt dat OWA, RDP en Winlogon allemaal op authenticatie met alleen een wachtwoord draaien, heeft een breder probleem dat niet met een oplossing voor één enkele dienst kan worden opgelost.

Hoe het mechanisme op directory-niveau werkt zonder endpoint-agents

Het mechanisme achter MFA op directory-niveau is op zichzelf al de moeite waard om te begrijpen, omdat het verklaart waarom het elke met AD verbonden service bereikt zonder dat er iets op individuele werkstations of servers hoeft te worden geïnstalleerd.

Dynamische sterke wachtwoordverificatie werkt door het in Active Directory zelf opgeslagen wachtwoord aan te passen, in plaats van het verificatieverkeer op elk eindpunt te onderscheppen. Het statische wachtwoord van een gebruiker wordt vervangen door een roterend, op TOTP gebaseerd dynamisch wachtwoord dat automatisch verandert met een door de beheerder geconfigureerde interval — een waarde die een veelvoud van 30 seconden moet zijn. Het huidige dynamische wachtwoord wordt gegenereerd met behulp van het TOTP-algoritme en is voor de gebruiker beschikbaar via de Protectimus SMART-app of een ondersteunde chatbot. Omdat de wijziging rechtstreeks in de directory plaatsvindt, gebruikt elke client of dienst die zich bij AD authenticeert – Winlogon, RDP, OWA, LDAP-gebonden applicaties – automatisch het huidige dynamische wachtwoord, zonder dat die dienst hoeft te weten dat er iets is veranderd.

Dit is wat de aanpak ‘agentloos’ maakt in de zin die ertoe doet: er draait geen software op de laptop, de RDP-host of de Exchange Client Access-server die controleert op een tweede factor. De directory zelf is het handhavingspunt. Het bijbehorende nadeel is dat dit onderdeel draait als onderdeel van een on-premises implementatie in plaats van een puur clouddienst, aangezien het directe integratie met de domeincontroller vereist.

De reikwijdte kiezen: alleen webmail, of de hele AD-omgeving

Beide benaderingen lossen het onderliggende probleem op — een wachtwoord alleen is niet langer voldoende voor authenticatie — maar ze doen dat op verschillende niveaus in de stack, en de juiste keuze hangt af van een eerlijke inventarisatie in plaats van een standaardvoorkeur.

Als OWA en EAC daadwerkelijk de enige diensten zijn die nog steeds uitsluitend met een wachtwoord bij AD authenticeren — VPN wordt al gedekt via RADIUS, RDP is al beveiligd, en er zijn geen andere verouderde applicaties die stilletjes vertrouwen op AD-inloggegevens — dan dicht de gerichte OWA-component die specifieke leemte met minimale verstoring van al het andere dat tegen de directory draait. Als uit de inventarisatie blijkt dat er meer dan één kwetsbare dienst is – wat vaker voorkomt zodra IT-teams daadwerkelijk op zoek gaan – sluit MFA op directoryniveau ze allemaal af vanuit één integratiepunt, in plaats van voor elke dienst een apart MFA-product aan te schaffen.

Hoe dan ook, de cijfers van de FBI over BEC-schade wijzen op hetzelfde onderliggende feit: inloggen met alleen een wachtwoord op een bedrijfsmailbox die op het open internet staat, is niet langer een verdedigbare positie voor welke organisatie dan ook die Exchange gebruikt — on-premises, hybride of anderszins.