Wanneer MFA niet langer voldoende is: de opkomst van AiTM-phishingaanvallen
Multi-Factor Authentication (MFA) staat aan. Medewerkers zijn getraind. Securitytools zijn aanwezig. En toch… raken organisaties nog steeds gecompromitteerd.
Bij Resilient Security blijven we het zien gebeuren, recent nog in een praktijkcase waarbij een phishingaanval erin slaagde MFA te omzeilen. Dankzij snelle detectie en response bleef de impact beperkt. Maar de aanval toont vooral één belangrijke realiteit aan: MFA alleen is niet langer voldoende.
Een phishingaanval die er volledig normaal uitziet
Phishing blijft één van de meest gebruikte aanvalsvectoren. En met de opkomst van AI worden deze aanvallen geloofwaardiger dan ooit.
In dit geval verliep de aanval volgens een herkenbaar patroon:
- Een medewerker ontvangt een phishingmail van een ogenschijnlijk betrouwbare afzender
- De gebruiker klikt op de link en komt terecht op een realistische loginpagina
- De gebruiker logt in en voert MFA uit
- Alles lijkt volledig legitiem
Maar achter de schermen gebeurt iets heel anders.
Dit type aanval staat bekend als een Adversary-in-the-Middle (AiTM) aanval.
De aanvaller bevindt zich tussen de gebruiker en de echte loginservice en onderschept de authenticatiestroom in realtime. Wanneer de gebruiker inlogt en MFA uitvoert, onderschept de aanvaller de session cookie. Hierdoor krijgt hij toegang tot de sessie zonder opnieuw credentials of MFA nodig te hebben.
Wat gebeurt er nadat toegang verkregen is?
Eens binnen hoeven aanvallers niet snel te handelen, ze moeten vooral onopgemerkt blijven.
Typische acties zijn:
- Meekijken in mailboxen en gesprekken monitoren
- Inboxregels aanmaken om bepaalde mails te verbergen
- E-mails versturen vanuit het gecompromitteerde account
- Facturen onderscheppen of betaalgegevens aanpassen
In veel gevallen ontstaat de echte schade pas later, bijvoorbeeld via financiële fraude of verdere laterale bewegingen binnen de omgeving.
Waarom dit vandaag relevanter is dan ooit
Dit type aanval is niet volledig nieuw, maar wordt steeds relevanter.
Tools worden toegankelijker. Phishingcampagnes worden geavanceerder. En gebruikers vertrouwen sneller wat ze zien.
Organisaties die uitsluitend vertrouwen op traditionele MFA en awareness-training lopen het risico deze evoluerende dreiging te missen.
Hoe we dit aanpakken binnen Resilient PROTECT
Het voorkomen en beantwoorden van AiTM-aanvallen vereist een gelaagde aanpak.
Preventie via sterkere security controls
We zetten in op phishing-resistant MFA en Conditional Access policies die het risico op session hijacking beperken en toegang contextafhankelijk controleren.
Detectie en snelle response
Wanneer een incident plaatsvindt, is snelheid cruciaal. Belangrijke acties zijn onder andere:
- Actieve sessies intrekken
- Credentials resetten
- Ongeautoriseerde authenticatiemethodes controleren en verwijderen
Duidelijke processen zijn noodzakelijk om deze stappen snel en consistent uit te voeren.
Het belang van correcte configuratie
De juiste tools hebben, zoals Microsoft Defender XDR met automatische Attack Disruption-functionaliteit, is slechts een deel van de oplossing. Correcte configuratie en tuning maken het verschil tussen effectieve detectie en gemiste signalen.
Van tools naar resilience
AiTM-phishingaanvallen tonen duidelijk aan hoe cyberdreigingen sneller evolueren dan traditionele verdedigingsmechanismen.
Security draait vandaag niet langer om één enkele controle, maar om de samenwerking tussen technologie, processen en mensen.
Bij Resilient Security focussen we op dat volledige plaatje: van preventie en detectie tot response en langdurige cyber resilience.
Want in het huidige dreigingslandschap is veilig zijn niet langer voldoende. Je moet resilient zijn!
Case 1: De Multi-Tenant API Orchestrator
De uitdaging: één JSM, meerdere Entra tenants
In een managed services omgeving moeten we aanvragen voor meerdere klanten verwerken vanuit één centrale Jira-omgeving.
Onze oplossing maakt gebruik van de automation engine van Jira om aanvragen dynamisch te routeren op basis van de organisatie van de gebruiker.
De workflow & API-keten
Wanneer een gebruiker een “Request an access package IGA” ticket aanmaakt, doorloopt de automation volgende stappen:
- Tenant identificatie
Op basis van de organisatie van de aanvrager wordt eentenantIDvariabele ingesteld. Hierdoor kan dezelfde automation schaalbaar ingezet worden over verschillende klanten. - Access package opzoeken
GET /identityGovernance/entitlementManagement/accessPackages - Policy ophalen & encoding fix: https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackages/{{AccessPackageID.urlEncode.replace(“+”,”%20″)}}?$expand=accessPackageAssignmentPolicies
Technische noot
Jira’s .urlEncode functie zet spaties om naar +, terwijl Microsoft Graph %20 verwacht. Door .replace("+","%20") toe te voegen, vermijden we fouten zoals 400 Bad Request
- Identity resolutie:
GET https://graph.microsoft.com/v1.0/users/{{reporter.emailAddress}}
Hiermee vertalen we het e-mailadres naar de unieke Entra User ID. - Final provisioning:
POST /identityGovernance/entitlementManagement/assignmentRequests
Het resultaat
Na validatie van de laatste API-call wordt de workflow afgerond.
Binnen enkele seconden krijgt de gebruiker automatisch toegang via een Access Package in Entra ID, zonder enige manuele actie van IT.
Case 2: Hybride governance via Custom Extensions
Automatisatie voor “offline” applicaties
Wat als een applicatie niet automatisch beheerd kan worden via Entra ID? Voor legacy of “offline” applicaties bouwen wij een brug via een Logic App.
De architectuur
We integreren een Logic App rechtstreeks in de Access Package workflow van Entra ID.
- Integratiepunt
Via een Custom Extension binnen de Access Package configuratie - Lifecycle triggers
We focussen op twee cruciale momenten:- Request approved
→ Logic App maakt automatisch een Jira-ticket aan
→ Lokale IT krijgt instructies om toegang manueel toe te kennen - Request removed
→ Automatisch ticket om toegang onmiddellijk te verwijderen
- Request approved
- Security layer: De Logic App valideert de oorsprong van de aanvraag, zodat enkel legitieme Entra events acties kunnen triggeren.
Waarom Resilient Security?
De integratie tussen JSM en Entra ID vraagt meer dan technische configuratie alleen. Het vereist inzicht in: OData filtering, URI encoding, API orchestration en Custom extensions.
Wij leveren niet enkel security services, we bouwen slimme, geautomatiseerde en resilient workflows die jouw organisatie vooruit helpen.
Overig NIEUWS
Wanneer MFA niet langer voldoende is: de opkomst van AiTM-phishingaanvallen
Technische deep dive: Multi-tenant IGA-automatisatie met JSM en Microsoft Entra ID
