Jordy HerberSocial engineering is niet meer alleen een mail met een slechte link. De moderne variant combineert email bombing, vishing, deepfake-audio, Teams-berichten, nep-helpdeskprocessen en ClickFix-schermen die gebruikers vragen om zelf de aanval uit te voeren.
Ik zie dit vaak bij klanten: technisch staat er best veel aan, maar het proces rond de gebruiker is zwak. De servicedesk vraagt telefonisch nog steeds om verificatie op basis van informatie die aanvallers ook kunnen weten. Gebruikers mogen PowerShell starten. OAuth-consent staat te ruim. En MFA-push wordt nog gezien als ‘sterk genoeg’.
Deze blog vertaalt social engineering naar detectie en controls in Microsoft Security. Niet met de boodschap ‘gebruikers moeten beter opletten’, maar met een architectuur die menselijk gedrag opvangt: Defender for Office 365, Defender XDR, Entra Conditional Access, Attack Surface Reduction en Sentinel.
Waarom dit onderwerp nu speelt
Het MDDR 2025 benoemt ClickFix als een opvallende initial access-methode. Het patroon is simpel en effectief: de gebruiker krijgt een overtuigende foutmelding of instructie, kopieert een commando of voert een actie uit en denkt dat hij een probleem oplost. De aanval voelt als IT-support, niet als phishing.
Email bombing wordt vaak gebruikt om druk te creëren. Een mailbox loopt vol, de gebruiker raakt geïrriteerd, en precies dan komt een telefoontje of Teams-bericht: ‘Ik ben van IT, klik dit even weg.’ Dat is geen technisch wonder. Het is timing, druk en misbruik van vertrouwen.
Mijn advies is om moderne social engineering te behandelen als een keten van signalen. Eén e-mail is misschien niet genoeg. Een e-mailstorm plus risky sign-in plus browser die PowerShell start is wél een incident.
Wat je moet weten: deepfake is niet het enige probleem
Deepfakes krijgen veel aandacht, maar in veel organisaties is ClickFix praktischer gevaarlijker. Een aanvaller hoeft geen perfecte video van de CEO te maken als een gebruiker zelf een commandoregel plakt omdat een nepportaal zegt dat dit nodig is.
Vishing is vooral gevaarlijk bij servicedeskprocessen. Als wachtwoordresets, MFA-resets of device-registraties telefonisch te makkelijk zijn, wordt identity security afhankelijk van social skills. In de praktijk gaat dit vaak mis bij processen die ooit handig waren, maar nooit zijn aangepast aan AI-stemmen en gestolen HR-data.
Daarom hoort social engineering in je Zero Trust-ontwerp. Niet als awarenesslaag achteraf, maar als ontwerpprincipe: helpdesk-verificatie, phishing-resistant MFA, admin consent workflow, ASR rules, browser hardening en monitoring op user-to-shell gedrag.
Architectuur: van mail naar endpoint en identity
Defender for Office 365 ziet mail, URL’s, attachments en impersonation. Defender for Endpoint ziet process execution. Entra ID ziet sign-ins en MFA. Defender for Cloud Apps ziet OAuth en cloud app-gedrag. Sentinel brengt dit samen over tijd.
Een sterke detectie is bijvoorbeeld: een gebruiker krijgt meer dan honderd mails in vijftien minuten, daarna volgt een risky sign-in of MFA-change, en binnen een uur start PowerShell vanuit een browser of Teams. Losse events kunnen vals-positief zijn; de keten is verdacht.
Dit klinkt klein, maar heeft impact op je SOC proces. Je gaat minder triëren op subjectregel en meer op gedrag na contact. Dat past beter bij AI-gegenereerde phishing, want taal- en stijlfouten zijn geen betrouwbare indicator meer.
Configuratie in een Microsoft 365 E5 demo tenant
Klikpad: Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies. Gebruik Standard of Strict preset security policies als basis. Configureer impersonation protection voor directie, finance, HR en servicedesk.
Klikpad: Microsoft Defender portal > Endpoints > Configuration management > Attack surface reduction. Blokkeer of audit gedrag zoals Office child processes, executable content uit mail/webmail en obfuscated scripts. Test eerst met audit op een pilotgroep.
Klikpad: Microsoft Entra admin center > Protection > Conditional Access. Vereis phishing-resistant MFA voor admins en gevoelige processen. Maak aparte regels voor MFA registration, security info change en admin portals.
Praktijkvoorbeeld: email bombing gevolgd door ClickFix
Een gebruiker krijgt binnen tien minuten honderden nieuwsbrieven, bevestigingsmails en mislukte aanmeldingsmeldingen. De mailbox is onbruikbaar. Daarna komt een Teams-bericht van een gecompromitteerd extern account of een telefoontje van iemand die zich voordoet als IT. De instructie klinkt behulpzaam: open deze pagina, kopieer deze regel, plak die in Run of PowerShell, dan stoppen we de spam.
Voor de gebruiker voelt dit logisch. De timing klopt, de druk is hoog en de actie lijkt een IT-herstelstap. Voor het SOC zijn de signalen verspreid: veel e-mail, mogelijk een Teams-event, een browserproces, PowerShell en misschien daarna een download of tokenactie. Zonder correlatie wordt dit geen incident, maar vijf losse signalen.
Een goede detectie kijkt naar de volgorde. Email bombing is de trigger, shell execution is de uitvoering, identity change of malwaredownload is de impact. Juist die volgorde maakt het verdacht. Daarom is een simpele mailvolume-regel niet genoeg, maar wel een goede start.
Servicedeskprocessen moeten hierop aangepast worden. Een medewerker die belt over een mailboxbombing mag nooit een commandoregel krijgen als oplossing. Maak intern beleid: IT vraagt gebruikers niet om onbekende commands uit chat, browser of telefoon uit te voeren. Zet dat ook in awareness, maar vooral in technische preventie.
Defender for Endpoint kan veel ClickFix-achtig gedrag zichtbaar maken. ASR-regels kunnen Office-child-processes beperken, scripts blokkeren en executable content uit mail en webmail tegenhouden. Begin met audit, meet impact en ga dan naar block waar het kan.
Niveau 400: detectie en response op gedragsketens
EmailEvents bevat veel volume, dus let op querykosten. Gebruik korte bins, bijvoorbeeld vijftien minuten, en aggregeer per recipient. Voeg daarna pas joins toe met DeviceProcessEvents of IdentityLogonEvents. Een query die alle mailrecords van dertig dagen koppelt aan alle process events wordt onbruikbaar.
Voor ClickFix is de parent-child relatie belangrijk. Browser naar PowerShell, Teams naar cmd, Outlook naar mshta of wscript zijn rode vlaggen. Niet elk gebruik is kwaadaardig, maar in combinatie met commandlines zoals Invoke-WebRequest, encoded commands, mshta met URL of rundll32 met vreemde parameters stijgt de zekerheid.
Gebruik entity mapping goed. Koppel gebruiker, device, IP en URL waar mogelijk. Zonder entiteiten kan Defender XDR of Sentinel het incident minder goed correleren. Voeg custom details toe zoals MailCount, Senders, ProcessCommandLine en InitiatingProcessFileName.
Voor vishing kun je niet alles technisch detecteren. Wat je wel kunt detecteren zijn de gevolgen: MFA registration changes, security info updates, password resets, Temporary Access Pass-activiteit, device registrations en role activations. Maak hier aparte detections voor high-value users en servicedeskmedewerkers.
OAuth-consent na een social engineering-event verdient aparte aandacht. Een gebruiker die kort na email bombing een app consent geeft met offline_access of Files.Read permissions is verdacht. Dit patroon hoort in je OAuth governance.
Response moet menselijk en technisch zijn. Bel de gebruiker via een bekend intern nummer, niet via het nummer uit het ticket. Vraag niet ‘heb jij geklikt?’, maar vraag naar de volgorde van events. Trek sessies in, controleer device timeline en blokkeer de gebruikte URL’s of indicatoren.
Implementatieplan in drie sprints
Sprint 1 is mail- en endpointzichtbaarheid. Controleer EmailEvents, EmailUrlInfo en DeviceProcessEvents in Defender XDR. Maak één hunt-query voor email bombing en één voor browser-to-shell gedrag. Gebruik deze eerst voor hunting, zodat je weet welke legitieme processen in je omgeving lijken op ClickFix.
Sprint 2 is proceshardening. Pas servicedeskprocedures aan voor MFA-reset, password reset en security info changes. Leg expliciet vast dat gebruikers nooit commando’s uit chat, telefoon of browser hoeven te plakken. Combineer dat met technische controls zoals ASR in audit en later block.
Sprint 3 is correlatie. Maak een Sentinel- of Defender-detectie die email bombing koppelt aan risky sign-in, OAuth-consent of shell execution binnen een uur. Dat is veel waardevoller dan een losse spamalert. Voeg een gebruikercontactscript toe aan de triage, zodat het SOC snel en veilig kan verifiëren wat er is gebeurd.
Praktische keuzes voor productie
Voor productie is het belangrijk om ClickFix-detecties niet te breed te maken. PowerShell vanuit een browser is verdacht, maar sommige beheerportalen, supporttools of trainingslabs kunnen vergelijkbare patronen geven. Gebruik daarom een pilotgroep en log eerst commandlines, parentprocessen en devicegroepen voordat je blokkeert.
Awareness blijft nuttig, maar alleen als het aansluit op technische controls. Train gebruikers niet alleen om phishing te herkennen, maar geef duidelijke regels: IT vraagt nooit om commando’s te plakken, MFA-reset gebeurt alleen via bekend proces, en urgente betaal- of identity-verzoeken krijgen altijd een tweede kanaal. Maak het gebruikers makkelijk om verdachte situaties te melden.
Koppel user reports uit Defender for Office 365 aan je SOC-proces. Een gemelde mail na email bombing kan de ontbrekende context zijn. Laat meldingen niet in een mailbox verdwijnen, maar zorg voor triage, feedback en waar mogelijk automatische enrichment.
Technisch voorbeeld
De voorbeelden hieronder zijn bedoeld als startpunt. Test altijd met je eigen logging, tijdzones, naming conventions en false-positive patroon. Maak van een hunt-query pas een analytics rule als je eigenaar, severity, response en uitzonderingen hebt vastgelegd.
KQL
// Microsoft 365 email bombing: veel inbound mail naar één gebruiker in korte tijd
EmailEvents
| where Timestamp > ago(24h)
| summarize
MailCount=count(),
Senders=dcount(SenderFromAddress),
Subjects=make_set(Subject, 20),
SenderSamples=make_set(SenderFromAddress, 20)
by RecipientEmailAddress, bin(Timestamp, 15m)
| where MailCount > 100 and Senders > 20
| project Timestamp, RecipientEmailAddress, MailCount, Senders, Subjects, SenderSamples
| order by MailCount desc
KQL
// ClickFix-achtig gedrag: browser -> clipboard/paste instructie -> PowerShell/cmd/mshta
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ (“chrome.exe”,”msedge.exe”,”firefox.exe”,”outlook.exe”,”teams.exe”)
| where FileName in~ (“powershell.exe”,”pwsh.exe”,”cmd.exe”,”mshta.exe”,”wscript.exe”,”cscript.exe”,”rundll32.exe”)
| where ProcessCommandLine has_any (“iex”, “Invoke-WebRequest”, “FromBase64String”, “mshta”, “http”, “https”, “curl”, “bitsadmin”)
| project Timestamp, DeviceName, InitiatingProcessAccountUpn, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc
Mapping: social engineering naar controls
| Aanval | Gedragssignaal | Control |
| Email bombing | Veel mails, veel afzenders, korte tijd | Defender for Office 365 + Sentinel |
| ClickFix | Browser/Teams/Outlook start shell of script | Defender for Endpoint + ASR |
| Vishing | MFA reset, device registration, helpdeskactie | Entra audit + procescontrole |
| OAuth phishing | Consent op risicovolle app | Defender for Cloud Apps + admin consent workflow |
| Deepfake CEO-fraude | Financiële of identity-change buiten proces | Vier-ogenproces + phishing-resistant MFA |
Advies vanuit de praktijk
Mijn advies is om dit onderwerp niet als los project te behandelen. Koppel het aan je SOC-proces, je identity governance, je cloud governance en waar relevant je Purview data security-aanpak. De techniek is belangrijk, maar ownership bepaalt of het blijft werken.
Begin klein en meetbaar. Kies één high-value scenario, bouw één goede detectie, test één responsepad en leg vast wie eigenaar is. Daarna schaal je uit. Dat werkt beter dan tien half afgemaakte policies die niemand durft aan te zetten.
Conclusie
Social Engineering 2.0: ClickFix, email bombing en vishing detecteren met Microsoft Security is geen onderwerp voor alleen awareness of alleen tooling. De kern is dat moderne aanvallen misbruik maken van normale processen: aanmelden, toestemming geven, data openen, scripts uitvoeren, cloudrechten gebruiken en incidenten te laat correleren. Microsoft Security helpt hier sterk bij, maar alleen als je de signalen over identity, endpoint, cloud en data samenbrengt. Maak logging betrouwbaar, maak detections herhaalbaar, automatiseer de eerste response waar de zekerheid hoog genoeg is en gebruik Purview-context om data-impact te begrijpen.
Volg ITCowboys voor de volgende technische deep dive. In de komende blogs pak ik meer Microsoft Security, XDR, Sentinel, Identity en Purview onderwerpen op vanuit de praktijk.
Bronnenlijst
De hyperlinks hieronder zijn gebruikt voor broncontrole en release-status.