Phishing en ISO 27001 voor Nederlands MKB
Phishing en ISO 27001 voor Nederlands MKB
Geschreven door
Jordy Bouwknegt
Phishing is voor Nederlands MKB geen “awareness-onderwerp”, maar een praktische aanvallijn naar account takeover, betaalfraude, datadiefstal, leveranciersmisbruik en ransomware. De moderne variant stopt bovendien niet meer bij een valse inlogpagina: aanvallers misbruiken ook SMS, QR-codes, OAuth-consent, helpdesks, MFA-pushmeldingen, device-code flows en vertrouwde leveranciersrelaties. In de praktijk leidt dat ertoe dat organisaties met “MFA aan” en “jaarlijkse awareness” toch gewoon worden gehacked. Grote incidenten bij onder meer Odido, Twilio, MGM Resorts en Caesars laten precies dat patroon zien.
Voor ISO/IEC 27001:2022 is dat relevant omdat Annex A geen enkele losse “phishing-control” heeft. Phishingweerbaarheid ontstaat pas uit een combinatie van organisatorische, people- en technische controls: awareness en training, secure authentication, malwarebescherming, web filtering, logging en monitoring, leveranciersbeheersing en incidentmanagement. ISO 27001:2022 groepeert zijn 93 controls bovendien expliciet over A.5 organisatorisch, A.6 people, A.7 fysiek en A.8 technologisch; juist daardoor moet een audit phishing als keten bekijken en niet als los inboxprobleem.
De kernconclusie voor MKB is hard maar simpel: wie phishing hoofdzakelijk probeert op te lossen met training, laat de echte aanvalsvlakken open. Wie alleen “MFA” zegt zonder phishing-resistente methoden, resetprocedures, fallback-beheer, logging en leverancierstoegang serieus te regelen, heeft vaak vooral schijnveiligheid ingericht. Grote, recente studies laten bovendien zien dat klassieke anti-phishingtraining vaak beperkte of inconsistente effecten heeft, terwijl interactieve en doorlopende interventies vooral helpen als zij bovenop technische maatregelen komen, niet in plaats daarvan.
Maar, wat is phishing nou eigenlijk écht?
Het technische aanvalsbeeld van phishing
De moderne phishingketen is geen enkelvoudige mail meer, maar een flexibele reeks lokmiddelen, identiteitsmisbruik en doorstoten naar hogere impact. Dat patroon is goed zichtbaar in reële campagnes met SMS-phishing, captcha-gates, token theft, QR-codes, OAuth-misbruik en helpdesk-social engineering.
Techniek | Aanvalsstroom | Veelvoorkomende indicatoren | Vereiste skills en middelen | Reële voorbeelden |
Credential harvesting | Mail/SMS/Teams-bericht lokt gebruiker naar valse login; ingevoerde credentials gaan direct naar de aanvaller; daarna mailbox takeover, interne phishing, BEC of data-exfiltratie. | Nieuwe login vanaf ongebruikelijke bron; direct daarna mailboxregels of forwarding; mislukte en daarna geslaagde login; captcha-pagina vóór de login; PDF die naar browser-login leidt. | Laag tot middelmatig: domeinregistratie, phishingkit, hosting, merkimitatie. Moderne kits verlagen de drempel sterk. | Microsoft beschreef in 2026 een campagne tegen meer dan 35.000 gebruikers bij 13.000 organisaties in 26 landen via PDF’s, captcha-stappen en real-time credential- en tokenverzameling. Ook Microsoft beschreef een campagne met SVG-bestanden vermomd als PDF’s die naar credential-harvesting leidden [6]. |
Malware via bijlagen of links | Lokbericht laat gebruiker een bijlage openen of een bestand downloaden; dat levert malware, loader of legitieme remote tooling op; daarna verkenning, laterale beweging en mogelijk ransomware. | SVG/ZIP/LNK/HTML-smuggling; onverwachte “voicemail”, “factuur” of “beveiligde pdf”; endpointproces dat direct na openen PowerShell of remote tooling start. | Laag tot middelmatig voor commodity malware; hoger voor stealth en evasions. | Microsoft beschreef een campagne waarin scriptable SVG-bijlagen werden gebruikt om gebruikers via redirect en captcha naar phishing of payloads te sturen. Ưit Reuters en FBI-rapportages blijkt bovendien dat ransomware nog steeds een groot operationeel risico blijft nadat initiële toegang is verkregen [7]. |
MFA fatigue | Aanvaller heeft al een wachtwoord en pusht herhaaldelijk MFA-verzoeken tot een gebruiker er één goedkeurt; daarna account takeover en vaak privilege escalation. | Tientallen pushverzoeken; veel “deny” gevolgd door één “allow”; meldingen buiten werktijd; helpdeskverzoeken direct na MFA-problemen. | Middelmatig: eerder buitgemaakt wachtwoord, geautomatiseerde pushspam. | Scattered Spider staat bekend om MFA-fatigue en andere identiteitsaanvallen; onderzoekers en opsporingsdiensten koppelden die werkwijze aan latere grote compromises. |
AiTM en phishing proxies | Slachtoffer logt in op een proxypagina die de echte Microsoft- of Google-login doorzet; credentials, MFA-code en vooral sessiecookies/tokens worden realtime onderschept; daarna geen nieuwe MFA meer nodig. | Geldige credentials én MFA maar tóch verdachte sessie; nieuwe sessiecookies; browser- of user-agent-afwijkingen; succesvolle login na verdachte redirectketen. | Middelmatig tot hoog; maar PhaaS-platforms maken dit steeds goedkoper. | Tycoon 2FA werd in 2026 ontmanteld; Europol en Microsoft koppelden het aan AiTM, MFA-bypass, bijna 100.000 getroffen organisaties en honderden aanvalsdomeinen. Barracuda zag daarnaast Whisper 2FA op grote schaal tegen Microsoft 365 [8]. |
OAuth-consent phishing | Gebruiker geeft een app toestemming in plaats van een wachtwoord te delen; de aanvaller krijgt tokens of app-rechten voor mail, bestanden of directorydata; daarna persistente toegang zonder klassiek wachtwoordmisbruik. | Nieuwe app-consent door eindgebruiker; onverwachte Graph-permissies; mail- of files-toegang door onbekende app; verdachte app-registraties. | Middelmatig: kwaadaardige app-registratie, permissiekennis, overtuigende UX. | Datadog beschreef in 2025 “CoPhish”, misbruik van Microsoft Copilot Studio-agents op legitieme Microsoft-domeinen voor OAuth-consent en tokenmisbruik. Microsoft waarschuwde daarnaast in 2026 voor actieve OAuth-campagnes die browser- en maildefenses konden omzeilen [9]. |
QR-phishing | QR-code in mail, PDF, poster of pakketje leidt gebruiker naar login- of malwarepagina; filters die URL’s in tekst detecteren missen dit vaak. | PDF met QR-code; “scan om document te bekijken”; onverwachte QR in facturen of toegangsverzoeken; mobiel device als afwijkende loginbron. | Laag: QR-generator en landingspagina volstaan vaak. | De FBI waarschuwde in 2025 voor QR-scams in ongewenste pakketten; er zijn ook waarschuwingen voor gerichte quishing door Kimsuky. Onderzoekers benadrukken bovendien dat QR-phishing expliciet is ontworpen om klassieke URL-inspectie te omzeilen. |
BEC en factuurfraude | Aanvaller gebruikt gespoofte of gecompromitteerde mailbox, volgt lopende correspondentie en stuurt betalings- of bankrekeningwijzigingen; doel is fraude, niet per se malware. | Draadjes over facturen worden opeens “urgent”; subtiele domeinvariaties; wijziging iban; verzoek tot geheimhouding; antwoordgedrag buiten normaal patroon. | Laag tot middelmatig: mailboxtoegang plus sociale engineering. | FBI-cijfers laten zien dat BEC nog steeds miljardenverliezen veroorzaakt; academische case studies analyseerden onder meer Unatrac en Ubiquiti als voorbeelden van grote BEC-impact [10] |
Spear-phishing en CEO-fraude | Aanvaller personaliseert sterk op rol, timing en context; doelwit is vaak finance, directie, HR of IT; einddoel is geld, data of een eerste foothold. | Taal en context lijken “te goed”; verwijzing naar echte projecten of agenda’s; druk op snelheid; ongebruikelijke kanalen of privé-mail. | Middelmatig tot hoog; AI verlaagt de personalisatiedrempel sterk. | Nieuwe onderzoeksliteratuur laat zien dat generatieve AI contextbewuste spear-phishing op schaal kan maken met overtuigende stijl- en contextimitatie. Praktisch sluit dit aan op CEO-fraude en BEC. |
Helpdesk- en voice social engineering | Aanvaller belt of chat met servicedesk, doet zich voor als medewerker of leverancier en laat wachtwoorden resetten, telefoonnummers toevoegen of MFA-apparaten inschrijven; daarna volgt account takeover en vaak ransomware. | Dringende resetaanvragen; verzoek om “nieuw nummer” of nieuw device; veel kennis over interne processen; calls kort na credential theft of SIM-swap. | Middelmatig; vereist goede pretexting en OSINT, weinig malwarekennis. | Reuters en andere rapportages koppelden Scattered Spider aan social engineering tegen MGM en Caesars; latere waarschuwingen voor retailers en aviation benadrukten opnieuw misbruik van helpdesks en MFA-resets. |
Supply-chain phishing | Aanvaller compromitteert een leverancier, MSP of SaaS-dienstverlener en gebruikt die vertrouwde relatie voor secundaire aanvallen; doel is schaal, geloofwaardigheid en toegang tot meerdere klanten. | Geldige vendor-mailbox maar afwijkende inhoud; vendor vraagt om nieuwe login of bestand; personeel vertrouwt de afzender te snel; gedeelde tenants of admins. | Middelmatig tot hoog; vereist leverancierscompromis of misbruik van supportketens. | Twilio werd gecompromitteerd via SMS-phishing; dat trof secundair klantorganisaties zoals Signal en droeg supply-chain-effecten in zich. Wired beschreef daarnaast vergelijkbare third-party impact bij DoorDash en Mailchimp [1]. |
Device-code phishing | Aanvaller stuurt een echte Microsoft device code en laat slachtoffer inloggen via een legitieme Microsoft-pagina; slachtoffer autoriseert feitelijk het device van de aanvaller; resultaat is token-based toegang zonder wachtwoorddiefstal. | Device-code login-event; legitieme Microsoft-pagina, maar vanuit verdacht initiatiekanaal; langdurige access en refresh tokens. | Laag tot middelmatig dankzij kant-en-klare kits. | De FBI waarschuwde in mei 2026 voor Kali365, dat precies dit mechanisme gebruikte om Microsoft 365-accounts over te nemen en OAuth-tokens vast te leggen [11]. |
De rode draad is dat de skill-eis voor veel phishingtechnieken daalt. Niet omdat aanvallen simpeler worden, maar omdat de tooling kant-en-klaar wordt verkocht als Phishing-as-a-Service. Dat maakt vooral MKB kwetsbaar: de tegenstander hoeft niet beter te zijn dan uw IT-partner; hij hoeft alleen een geloofwaardige lokstap en een fout geconfigureerde identiteitsketen te vinden.
Hoe phishing escaleert naar een echte hack
Phishing wordt vaak te eng gedefinieerd als “mail met link”. In werkelijkheid is het meestal de initiële identiteitshandeling in een langere keten. Eerst wordt vertrouwen gewonnen of misbruikt, dan wordt een identiteit gebruikt, daarna volgt persistentie, en pas daarna komt de zichtbare schade: frauduleuze betalingen, data-exfiltratie, vendor-misbruik of encryptie. Twilio laat zien hoe één succesvol phishingpad meteen tientallen of honderden klantorganisaties kan raken; MGM en Caesars laten vervolgens zien hoe identiteitsmisbruik kan doorlopen naar operationele verstoring en hoge financiële impact.
Voor MKB zijn vooral vier escalatiepunten beslissend.
Het eerste is mailboxmisbruik:
aanvallers maken forwarding rules, lezen factuurstromen mee en sturen intern nieuwe lures.
Het tweede is token- en sessiemisbruik:
bij AiTM, device-code phishing en OAuth-consent is het niet genoeg om alleen wachtwoorden te resetten; tokens moeten worden ingetrokken en app-consents verwijderd.
Het derde is identity recovery: helpdesks, self-service reset, fallback-MFA en oude authenticatiemethoden zijn vaak zwakker dan de primaire login.
Het vierde is leverancierstoegang: een MSP, mailprovider of SaaS-tool kan de hele trust chain openzetten.
De detectiesignalen die MKB het vaakst over het hoofd ziet, zitten precies in die escalatiefase. Voorbeelden zijn nieuwe mailbox forwardingregels, OAuth-appconsent door gewone gebruikers, een nieuw MFA-device, veel denied pushrequests met daarna één succesvolle approval, een login vanaf een normale locatie maar met atypische browser-/sessiekenmerken, of een onverwachte wijziging in betaalinstructies vanuit een bestaand e-maildraadje. Geen van die signalen zie je terug in een simpel “phishing awareness dashboard”; ze zitten in identity-logs, mailflow-logs, endpointtelemetrie en change-events.
ISO27001 vertaald naar phishing weerbaarheid voor MKB
Phishingweerbaarheid in ISO-termen is een samengestelde control-set. Dat is ook precies waarom veel organisaties en auditors het fout aanpakken: zij zoeken één awarenessbewijs, terwijl Annex A de relevante maatregelen juist over people, organisatorische en technische controls verdeelt. Dat volgt direct uit de 2022-structuur van A.5 tot en met A.8. De onderstaande mapping is daarom een praktische interpretatie voor MKB, gebaseerd op de aanvalstechnieken hierboven.
Aanvals techniek | Relevante Annex A-controls | Minimale MKB-baseline | Versterking die sterk aan te raden is | Veelgemaakte fout |
Credential harvesting | A.6.3 awareness; A.8.5 secureAuthentication; A.8.15/A.8.16 logging/monitoring; A.5.24-A.5.26 incidentmanagement | MFA voor alle (cloud)accounts; blokkeren van legacy auth; mailreport-knop; logging van sign-ins en mailboxregels; reset en token revocation-proces | FIDO2/passkeys voor beheerders en finance; CA-policies; mailbox-rule alerts; suspicious impossible-travel review | “MFA staat aan” zonder te weten welke methoden, fallbacks en uitzonderingen actief zijn |
Malware via bijlagen/links | A.8.7 protection against malware; A.8.23 web filtering; A.8.15/A.8.16 | Defender/EDR, attachment sandboxing of veilige mailfilter, blokkeren van risicobestanden waar mogelijk, browser- en Office-hardening | Application control, macrobeleid, RMM-detectie, DNS/web filtering op (roaming) devices | Alleen antivirus tellen, maar geen EDR, geen browser/web controls en geen blokbeleid voor rare file types |
MFA fatigue | A.8.5 secure authentication; A.6.3 awareness | Push-notifications alleen met number matching of vergelijkbare bevestiging; rate-limiting; helpdesk-instructie bij MFA-problemen | FIDO2/passkeys voor admins en gevoelige rollen; uitschakelen van zwakke methoden zoals SMS waar mogelijk | Push-MFA uitrollen zonder number matching of gebruikersafspraken |
AiTM/phishing proxies | A.8.5, A.8.15/A.8.16, A.8.23, A.5.7 threat intelligence | MFA plus login- en sessielogs; afwijkende browsers/locations review; url-click bescherming | Phishing-resistente authenticatie; token protection waar platform dit ondersteunt; strengere CA-policies | Denken dat gewone MFA op zichzelf AiTM oplost |
OAuth-consent phishing | A.5.15-A.5.18 identity/access; A.8.15/A.8.16; A.5.24-A.5.26 | Eindgebruikers mogen niet vrij high-risk app-consents geven; app-registraties en grants loggen | Admin consent workflow; periodieke review van enterprise apps en Graph-rechten | Alleen naar wachtwoorden kijken, niet naar app-permissies en tokens |
QR-phishing | A.6.3, A.8.23, A.8.5 | Mobiele awareness specifiek op QR-codes; mailfilters ook op QR in PDF’s waar mogelijk; users instrueren om niet via QR in te loggen | MDM/mobile threat defense voor risicoprofielen; veilige mobiele browsers | Training alleen richten op zichtbare links in e-mails |
BEC/factuurfraude | A.6.3; A.5.14 information transfer; A.8.15/A.8.16; A.5.24-A.5.26 | Vier-ogenprincipe op rekeningwijzigingen en spoedbetalingen; callback-procedure naar bekend nummer; mailbox logging | Detectie op anomalieën in correspondentie, DMARC/SPF/DKIM streng afsluiten, stronger finance segregation | Vertrouwen op “de mail zag er legitiem uit” zonder onafhankelijke verificatie |
Spear-phishing/CEO-fraude | A.6.3, A.5.10 acceptable use, A.5.14, A.8.15/A.8.16 | Beschermde processtappen voor HR, finance, directie en IT; geen uitzonderingen voor “urgent van directie” | Extra identity controls voor directie en finance; executive monitoring en VIP-protection | Duidelijke processen hebben, maar directie buiten proces laten werken |
Helpdesk/social engineering | A.5.2 roles/responsibilities; A.5.17 authentication information; A.8.5; A.5.24-A.5.26 | Servicedesk mag nooit alleen op kennisvragen of beller-ID resetten; resets via aparte verificatiestap | Verbale passphrases of identity proofing, break-glass-procedures, call recording en review | Helpdesk zien als “operationeel”, niet als security control |
Supply-chain phishing | A.5.19-A.5.23 supplier- en cloudcontrols; A.8.15/A.8.16; A.5.24-A.5.26 | Supplier access register; MFA en least privilege voor MSP’s (of JIT access); incidentmeldplicht contractueel vastleggen | Review van vendor mailflows, delegated admin beperken, JML-proces voor leveranciersaccounts | Volledige tenant-admin aan leverancier geven zonder logging, review of contractuele eisen |
Twee controlgebieden verdienen extra scherpte.
Awareness en phishingtesten. Klassieke trainingen en losse “phishing simulaties” zijn geen onzin, maar wel zwakke primaire controls. Grote reproductiestudies vonden weinig statistisch effect van standaard training op klik- of rapportagegedrag; kleinere en interactievere interventies, zoals role-play en groepsdiscussie, lieten positievere effecten zien; langdurige, continue programma’s kúnnen de kwetsbaarheid verlagen, maar dat effect vervaagt door personeelswisselingen en organisatorische context. Voor auditdoeleinden betekent dit: vraag niet “heeft u training?”, maar “welk risico reduceert deze training aantoonbaar, voor welke rollen, en wat doet u technisch als training faalt?” [12].
MFA. MFA blijft extreem waardevol; in grootschalig onderzoek bleken MFA-geactiveerde accounts veel minder vaak gecompromitteerd dan accounts zonder MFA. Maar “MFA” is geen homogene maatregel. Push zonder number matching, SMS, zwakke recoveryflows, fallback-methoden, niet-gemonitorde app-consents en helpdesk-bypasses maken dat de controle wel op papier bestaat maar onvoldoende phishing-resistent is. Tegelijk laten studies naar FIDO2 en passkeys zien dat zij de lat tegen phishing duidelijk verhogen, terwijl enterprise-uitrol juist struikelt over recovery, lifecycle en legacy-ondersteuning. Voor MKB is de juiste conclusie dus niet “MFA werkt niet”, maar “MFA werkt, behalve waar uw organisatie de zwakke uitwijkpaden laat bestaan.” [13].
Waar reguliere audits vaak tekortschieten
De meest voorkomende auditfout is dat phishing wordt teruggebracht tot één people-control: awareness. Dat is precies de verkeerde abstrahering. De incidenten die publiek bekend zijn, tonen juist dat identity recovery, sessiecookies, OAuth-apps, leverancierstoegang, helpdeskprocedures en logging de doorslag geven wanneer een campagne door de eerste verdedigingslaag heen komt. Onderstaande auditmatrix is daarom nadrukkelijk een kritisch en praktisch MKB-model, afgeleid uit de aanvalspatronen en incidenten hierboven.
Controlgebied | Waar auditors te vaak genoegen mee nemen | Wat zij wél moeten vragen | Sterk bewijs |
Awareness en training | Presentielijst, e-learningcertificaten, één klikratio | Zijn finance, HR, directie en servicedesk apart getraind? Worden QR, phishing, OAuth en BEC behandeld? Is er follow-up op gedrag? | Rolspecifieke trainingsinhoud, rapportage over meldgedrag, lessons learned uit echte meldingen |
E-mailsecurity | “SPF/DKIM/DMARC staat ergens aan” | Staat DMARC op reject/quarantine of alleen monitor? Worden lookalike-domeinen, display-name en externe afzenders gemarkeerd? | Aanwijsbare mailpolicies, screenshots of exports van mailconfiguratie, DMARC-rapportage |
Web filtering | “Browser heeft safe browsing” | Wordt ook gefilterd buiten kantoor of op roaming devices? Worden nieuwe en onbekende domeinen, file-sharing-services en phishing categories geblokkeerd? | Policy-overzichten, blocklogs, incident- of testvoorbeelden |
Anti-malware en endpoint | Antivirus aanwezig | Is er EDR? Worden scripts, LNK/HTML-smuggling, ongewone remote tools en child-processen bewaakt? | EDR-configuratie, detectieregels, incidenttickets, blockevents |
MFA en conditional access | “MFA verplicht” | Welke methoden zijn toegestaan? Is SMS nog actief? Is number matching actief? Hoe werkt account recovery? Wie mag MFA-methoden resetten? | Exports van authentication methods, CA-policies, servicedesk runbooks, logs van method changes |
Logging en monitoring | SIEM-licentie of “logging staat aan” | Worden mailbox rules, OAuth grants, sign-ins, new devices, app consents en forwarding rules gelogd en beoordeeld? Hoe lang blijven logs beschikbaar? | Bewaartermijnen, concrete logevents, queries, alertregels |
Incident management | Procedure op papier | Kan men tokens revoken, mailboxregels verwijderen, account compromise isoleren en leveranciers snel laten meedoen? Is ooit geoefend op AiTM/BEC? | Oefenverslagen, incidentdossiers, post-incidentacties |
Leveranciers management | Standaard NDA of algemene SLA | Welke leveranciers mogen in de tenant? Hoe is delegated admin beperkt? Wat is de meldplicht en responstijd bij compromittering? | Supplier register, contractclausules, toegangsreview, admin-rollenlijst |
De conclusie is eenvoudig: een auditor die alleen naar awareness of incidentregistratie vraagt, audit niet op phishingweerbaarheid maar op papieraanwezigheid. Een auditor die geen vragen stelt over app-consent, MFA-reset, service desk, mailboxregels en vendor-admins, mist precies de paden waar hedendaagse campagnes daadwerkelijk doorheen gaan.
Casussen en wat daar echt van geleerd moet worden
1. Twilio en de 0ktapus-campagne is een schoolvoorbeeld van supply-chain phishing. Aanvallers stuurden gerichte SMS-berichten naar werknemers van meer dan honderd organisaties, met links naar overtuigende valse SSO-pagina’s. Twilio werd gecompromitteerd; secundaire slachtoffers waren onder meer Signal en Authy-gerelateerde accounts. Het relevante leerpunt voor MKB is niet alleen “let op SMS”, maar vooral dat identiteitsaanvallen tegen leveranciers en platformproviders zich als een hefboom gedragen: één succes kan tientallen klantorganisaties raken. Het verdedigingsverschil lag bij partijen als Cloudflare in phishing-resistente hardware keys en strakke access controls, niet bij beter opletten alleen. [1]
2. MGM Resorts en Caesars Entertainment tonen het gevaar van helpdesk- en identiteitsprocessen als zwakke plek. Reuters en andere betrouwbare bronnen koppelden de casino-incidenten aan Scattered Spider, een groep die phishing, social engineering en identiteitsmisbruik combineerde. Caesars meldde dat gevoelige klantdata was geraakt; MGM rapporteerde uiteindelijk een financiële impact van ongeveer 100 miljoen dollar en operationele verstoring van hotel- en casinofuncties. De les voor MKB is messcherp: een goed gefilterde inbox helpt weinig als uw helpdesk een telefoonnummer of MFA-device toevoegt op basis van sociale druk en oppervlakkige verificatie. [2]
3. Tycoon 2FA is geen enkel slachtoffer, maar misschien wel de belangrijkste hedendaagse infrastructuurcasus. Europol en Microsoft ondersteunden in 2026 de verstoring van dit PhaaS-platform, dat AiTM gebruikte om MFA te omzeilen, sessiecookies te stelen en op grote schaal account takeovers mogelijk te maken. De betekenis voor MKB is groot: er is geen geavanceerde staatsactor meer nodig om MFA te omzeilen; een crimineel kan tooling huren die dit kant-en-klaar levert. Daarom is “MFA verplicht” zonder FIDO2, logging, token revocation en sterke fallbackbeheersing simpelweg niet meer genoeg. [3]
4. BEC-cases zoals Unatrac en Ubiquiti, zoals geanalyseerd in academische literatuur, laten een ander maar even vernietigend patroon zien: geen ransomware, geen zichtbare malware, soms zelfs geen spectaculaire technische exploit, maar toch grote financiële schade omdat e-mailvertrouwen, beslissingsdruk en betalingsprocessen werden misbruikt. Voor MKB is dat essentieel, omdat juist kleinere organisaties vaak denken dat zij pas “echt gehackt” zijn als systemen uitvallen. In werkelijkheid kan de eerste materiële schade al zijn ontstaan terwijl de omgeving technisch nog ogenschijnlijk normaal draait. [4]
5. Nederlandse casuïstiek is in openbare bronnen vaak minder technisch uitgewerkt dan internationale SEC-filings en grote Amerikaanse incidenten. Dat is geen teken dat Nederlandse organisaties minder worden geraakt (Odido, Chipsoft, BasicFit), maar vooral dat de publieke forensische diepgang vaak beperkter is. Het Nederlandse MKB moet die lacune niet verwarren met lager risico. Het NCSC richt zijn dienstverlening inmiddels expliciet op het versterken van de digitale weerbaarheid van circa 2,4 miljoen bedrijven en organisaties in Nederland, juist omdat de dreiging breed is. [5]
Prioriteiten voor Nederlands MKB
Voor Nederlands MKB zonder SOC is het verstandig om niet te beginnen met een perfect programma, maar met een smalle, harde baseline die de meest misbruikte phishingpaden dichtzet. De prioritering hieronder is bewust pragmatisch en volgt de schade- en waarschijnlijkheidsmix uit de incidenten en studies hierboven.
Prioriteit | Wat regelen | Waarom eerst | Concreet minimumresultaat |
Direct | MFA saneren | Slechte MFA is een schijncontrol | Geen legacy auth; geen SMS voor admins/finance; push alleen met number matching; gedocumenteerde resetflow |
Direct | Mail- en identity-logging bruikbaar maken | Zonder logs geen detectie en geen incidentrespons | Sign-in logs, mailboxregels, forwarding, app-consent en method-changes minimaal aantoonbaar beschikbaar |
Direct | Finance- en directieprocessen verharden | BEC kan schade veroorzaken zonder zichtbare hack | Verplichte callback bij rekeningwijziging of spoedbetaling; vier-ogenprincipe |
Direct | Servicedesk identity proofing aanscherpen | Helpdesk is een aanvalsvlak | Geen resets of device-enrollment op basis van alleen beller-ID of HR-kennisvragen |
Binnen korte termijn | E-mailbeveiliging en web filtering verbeteren | Reductie van volume en klikroutes | DMARC opschalen, externe afzenders markeren, URL-/attachmentbescherming, web/DNS-filtering ook buiten kantoor |
Binnen korte termijn | Endpointbescherming op orde brengen | Bijlage- en toolsmisbruik stopt anders niet bij de mail | EDR met basisdetecties op scripts, LNK, HTML-smuggling en remote tools |
Binnen middellange termijn | App-consent en cloudtoegang beheersen | OAuth-consent en tokenmisbruik omzeilen wachtwoorddenken | Eindgebruikers mogen geen high-risk app-permissies zelfstandig verlenen |
Binnen middellange termijn | Vendor- en MSP-toegang beperken | Supply-chain phishing vergroot impact | Supplier register, least privilege, aparte adminaccounts, logreview |
Doorlopend | Awareness opnieuw positioneren | Training moet ondersteunend zijn, niet cosmetisch | Rolspecifieke mini-sessies, meldgedrag meten, QR/vishing/OAuth meenemen |
Doorlopend | Incidentrespons op phishing oefenen | Phishing is pas voorbij na containment en token cleanup | Oefening op mailbox takeover, BEC en OAuth-consent inclusief revoke-acties |
Een kort implementatiechecklist voor MKB kan zonder zware governance als volgt worden gebruikt:
Termijn | Praktische checklist | |
Binnen 30 dagen | Inventariseer alle gebruikte MFA-methoden; schakel legacy auth uit; leg vast wie accounts en MFA reset; activeer logging op sign-ins, mailboxregels en app-consent; voer callback-procedure in voor rekeningwijzigingen en spoedbetalingen. | |
Binnen 90 dagen | Markeer externe e-mail, verbeter DMARC, richt URL- en attachmentbescherming in, activeer EDR op alle beheerde endpoints, beperk eindgebruikersconsent voor cloudapps, beoordeel MSP- en leveranciersrollen, maak een korte playbook voor mailbox compromise en token revocation. | |
Binnen 180 dagen | Migreer gevoelige rollen naar phishing-resistente authenticatie zoals FIDO2/passkeys waar haalbaar, oefen een scenario met helpdesk-vishing en een scenario met BEC, toets of logs echt bruikbaar zijn tijdens een tabletop of praktijktest, en verwerk lessons learned in het ISMS. |
Ben ik gelijk gehackt als ik op een phishinglink klik? Niet altijd. In de meeste gevallen gebeurt er nog niets wanneer u alleen op een phishinglink klikt. Het daadwerkelijke risico ontstaat vaak pas wanneer u vervolgens een actie uitvoert, zoals het invoeren van uw gebruikersnaam en wachtwoord, het goedkeuren van een MFA-verzoek, het openen van een bestand of het installeren van software. Dat betekent echter niet dat het klikken op een link altijd onschuldig is. Sommige phishingwebsites proberen direct malware te downloaden of misbruik te maken van kwetsbaarheden in een browser of apparaat. Hoewel dit tegenwoordig minder vaak voorkomt dan credential harvesting, blijft het een reëel risico. Een phishingaanval verloopt meestal in één van de volgende stappen:
U klikt op een link → meestal nog geen compromittering.
U voert uw wachtwoord in → account mogelijk gecompromitteerd.
U keurt MFA goed → account waarschijnlijk gecompromitteerd.
U opent een kwaadaardige bijlage → apparaat mogelijk gecompromitteerd.
U installeert software → apparaat waarschijnlijk gecompromitteerd.
Praktische vuistregel: bent u per ongeluk op een verdachte link terechtgekomen, maar heeft u verder niets gedaan? Dan is de kans groot dat er geen directe schade is ontstaan. Heeft u gegevens ingevuld, een bestand geopend of een MFA-verzoek goedgekeurd? Meld dit direct bij IT of uw securityverantwoordelijke en wijzig uw wachtwoord zo snel mogelijk. Wat zien we tijdens audits?
Veel medewerkers melden een phishingincident pas wanneer zij denken dat zij "echt gehackt" zijn. Daardoor gaan waardevolle uren verloren. Ook een verdachte klik zonder verdere acties kan nuttige informatie opleveren voor onderzoek en monitoring. Meld het daarom altijd, ook als u twijfelt of er daadwerkelijk iets is gebeurd.
[1] https://www.wired.com/story/twilio-breach-phishing-supply-chain-attacks/
[4] https://arxiv.org/abs/2011.11112
[10] https://arxiv.org/abs/2511.20944
Phishing is voor Nederlands MKB geen “awareness-onderwerp”, maar een praktische aanvallijn naar account takeover, betaalfraude, datadiefstal, leveranciersmisbruik en ransomware. De moderne variant stopt bovendien niet meer bij een valse inlogpagina: aanvallers misbruiken ook SMS, QR-codes, OAuth-consent, helpdesks, MFA-pushmeldingen, device-code flows en vertrouwde leveranciersrelaties. In de praktijk leidt dat ertoe dat organisaties met “MFA aan” en “jaarlijkse awareness” toch gewoon worden gehacked. Grote incidenten bij onder meer Odido, Twilio, MGM Resorts en Caesars laten precies dat patroon zien.
Voor ISO/IEC 27001:2022 is dat relevant omdat Annex A geen enkele losse “phishing-control” heeft. Phishingweerbaarheid ontstaat pas uit een combinatie van organisatorische, people- en technische controls: awareness en training, secure authentication, malwarebescherming, web filtering, logging en monitoring, leveranciersbeheersing en incidentmanagement. ISO 27001:2022 groepeert zijn 93 controls bovendien expliciet over A.5 organisatorisch, A.6 people, A.7 fysiek en A.8 technologisch; juist daardoor moet een audit phishing als keten bekijken en niet als los inboxprobleem.
De kernconclusie voor MKB is hard maar simpel: wie phishing hoofdzakelijk probeert op te lossen met training, laat de echte aanvalsvlakken open. Wie alleen “MFA” zegt zonder phishing-resistente methoden, resetprocedures, fallback-beheer, logging en leverancierstoegang serieus te regelen, heeft vaak vooral schijnveiligheid ingericht. Grote, recente studies laten bovendien zien dat klassieke anti-phishingtraining vaak beperkte of inconsistente effecten heeft, terwijl interactieve en doorlopende interventies vooral helpen als zij bovenop technische maatregelen komen, niet in plaats daarvan.
Maar, wat is phishing nou eigenlijk écht?
Het technische aanvalsbeeld van phishing
De moderne phishingketen is geen enkelvoudige mail meer, maar een flexibele reeks lokmiddelen, identiteitsmisbruik en doorstoten naar hogere impact. Dat patroon is goed zichtbaar in reële campagnes met SMS-phishing, captcha-gates, token theft, QR-codes, OAuth-misbruik en helpdesk-social engineering.
Techniek | Aanvalsstroom | Veelvoorkomende indicatoren | Vereiste skills en middelen | Reële voorbeelden |
Credential harvesting | Mail/SMS/Teams-bericht lokt gebruiker naar valse login; ingevoerde credentials gaan direct naar de aanvaller; daarna mailbox takeover, interne phishing, BEC of data-exfiltratie. | Nieuwe login vanaf ongebruikelijke bron; direct daarna mailboxregels of forwarding; mislukte en daarna geslaagde login; captcha-pagina vóór de login; PDF die naar browser-login leidt. | Laag tot middelmatig: domeinregistratie, phishingkit, hosting, merkimitatie. Moderne kits verlagen de drempel sterk. | Microsoft beschreef in 2026 een campagne tegen meer dan 35.000 gebruikers bij 13.000 organisaties in 26 landen via PDF’s, captcha-stappen en real-time credential- en tokenverzameling. Ook Microsoft beschreef een campagne met SVG-bestanden vermomd als PDF’s die naar credential-harvesting leidden [6]. |
Malware via bijlagen of links | Lokbericht laat gebruiker een bijlage openen of een bestand downloaden; dat levert malware, loader of legitieme remote tooling op; daarna verkenning, laterale beweging en mogelijk ransomware. | SVG/ZIP/LNK/HTML-smuggling; onverwachte “voicemail”, “factuur” of “beveiligde pdf”; endpointproces dat direct na openen PowerShell of remote tooling start. | Laag tot middelmatig voor commodity malware; hoger voor stealth en evasions. | Microsoft beschreef een campagne waarin scriptable SVG-bijlagen werden gebruikt om gebruikers via redirect en captcha naar phishing of payloads te sturen. Ưit Reuters en FBI-rapportages blijkt bovendien dat ransomware nog steeds een groot operationeel risico blijft nadat initiële toegang is verkregen [7]. |
MFA fatigue | Aanvaller heeft al een wachtwoord en pusht herhaaldelijk MFA-verzoeken tot een gebruiker er één goedkeurt; daarna account takeover en vaak privilege escalation. | Tientallen pushverzoeken; veel “deny” gevolgd door één “allow”; meldingen buiten werktijd; helpdeskverzoeken direct na MFA-problemen. | Middelmatig: eerder buitgemaakt wachtwoord, geautomatiseerde pushspam. | Scattered Spider staat bekend om MFA-fatigue en andere identiteitsaanvallen; onderzoekers en opsporingsdiensten koppelden die werkwijze aan latere grote compromises. |
AiTM en phishing proxies | Slachtoffer logt in op een proxypagina die de echte Microsoft- of Google-login doorzet; credentials, MFA-code en vooral sessiecookies/tokens worden realtime onderschept; daarna geen nieuwe MFA meer nodig. | Geldige credentials én MFA maar tóch verdachte sessie; nieuwe sessiecookies; browser- of user-agent-afwijkingen; succesvolle login na verdachte redirectketen. | Middelmatig tot hoog; maar PhaaS-platforms maken dit steeds goedkoper. | Tycoon 2FA werd in 2026 ontmanteld; Europol en Microsoft koppelden het aan AiTM, MFA-bypass, bijna 100.000 getroffen organisaties en honderden aanvalsdomeinen. Barracuda zag daarnaast Whisper 2FA op grote schaal tegen Microsoft 365 [8]. |
OAuth-consent phishing | Gebruiker geeft een app toestemming in plaats van een wachtwoord te delen; de aanvaller krijgt tokens of app-rechten voor mail, bestanden of directorydata; daarna persistente toegang zonder klassiek wachtwoordmisbruik. | Nieuwe app-consent door eindgebruiker; onverwachte Graph-permissies; mail- of files-toegang door onbekende app; verdachte app-registraties. | Middelmatig: kwaadaardige app-registratie, permissiekennis, overtuigende UX. | Datadog beschreef in 2025 “CoPhish”, misbruik van Microsoft Copilot Studio-agents op legitieme Microsoft-domeinen voor OAuth-consent en tokenmisbruik. Microsoft waarschuwde daarnaast in 2026 voor actieve OAuth-campagnes die browser- en maildefenses konden omzeilen [9]. |
QR-phishing | QR-code in mail, PDF, poster of pakketje leidt gebruiker naar login- of malwarepagina; filters die URL’s in tekst detecteren missen dit vaak. | PDF met QR-code; “scan om document te bekijken”; onverwachte QR in facturen of toegangsverzoeken; mobiel device als afwijkende loginbron. | Laag: QR-generator en landingspagina volstaan vaak. | De FBI waarschuwde in 2025 voor QR-scams in ongewenste pakketten; er zijn ook waarschuwingen voor gerichte quishing door Kimsuky. Onderzoekers benadrukken bovendien dat QR-phishing expliciet is ontworpen om klassieke URL-inspectie te omzeilen. |
BEC en factuurfraude | Aanvaller gebruikt gespoofte of gecompromitteerde mailbox, volgt lopende correspondentie en stuurt betalings- of bankrekeningwijzigingen; doel is fraude, niet per se malware. | Draadjes over facturen worden opeens “urgent”; subtiele domeinvariaties; wijziging iban; verzoek tot geheimhouding; antwoordgedrag buiten normaal patroon. | Laag tot middelmatig: mailboxtoegang plus sociale engineering. | FBI-cijfers laten zien dat BEC nog steeds miljardenverliezen veroorzaakt; academische case studies analyseerden onder meer Unatrac en Ubiquiti als voorbeelden van grote BEC-impact [10] |
Spear-phishing en CEO-fraude | Aanvaller personaliseert sterk op rol, timing en context; doelwit is vaak finance, directie, HR of IT; einddoel is geld, data of een eerste foothold. | Taal en context lijken “te goed”; verwijzing naar echte projecten of agenda’s; druk op snelheid; ongebruikelijke kanalen of privé-mail. | Middelmatig tot hoog; AI verlaagt de personalisatiedrempel sterk. | Nieuwe onderzoeksliteratuur laat zien dat generatieve AI contextbewuste spear-phishing op schaal kan maken met overtuigende stijl- en contextimitatie. Praktisch sluit dit aan op CEO-fraude en BEC. |
Helpdesk- en voice social engineering | Aanvaller belt of chat met servicedesk, doet zich voor als medewerker of leverancier en laat wachtwoorden resetten, telefoonnummers toevoegen of MFA-apparaten inschrijven; daarna volgt account takeover en vaak ransomware. | Dringende resetaanvragen; verzoek om “nieuw nummer” of nieuw device; veel kennis over interne processen; calls kort na credential theft of SIM-swap. | Middelmatig; vereist goede pretexting en OSINT, weinig malwarekennis. | Reuters en andere rapportages koppelden Scattered Spider aan social engineering tegen MGM en Caesars; latere waarschuwingen voor retailers en aviation benadrukten opnieuw misbruik van helpdesks en MFA-resets. |
Supply-chain phishing | Aanvaller compromitteert een leverancier, MSP of SaaS-dienstverlener en gebruikt die vertrouwde relatie voor secundaire aanvallen; doel is schaal, geloofwaardigheid en toegang tot meerdere klanten. | Geldige vendor-mailbox maar afwijkende inhoud; vendor vraagt om nieuwe login of bestand; personeel vertrouwt de afzender te snel; gedeelde tenants of admins. | Middelmatig tot hoog; vereist leverancierscompromis of misbruik van supportketens. | Twilio werd gecompromitteerd via SMS-phishing; dat trof secundair klantorganisaties zoals Signal en droeg supply-chain-effecten in zich. Wired beschreef daarnaast vergelijkbare third-party impact bij DoorDash en Mailchimp [1]. |
Device-code phishing | Aanvaller stuurt een echte Microsoft device code en laat slachtoffer inloggen via een legitieme Microsoft-pagina; slachtoffer autoriseert feitelijk het device van de aanvaller; resultaat is token-based toegang zonder wachtwoorddiefstal. | Device-code login-event; legitieme Microsoft-pagina, maar vanuit verdacht initiatiekanaal; langdurige access en refresh tokens. | Laag tot middelmatig dankzij kant-en-klare kits. | De FBI waarschuwde in mei 2026 voor Kali365, dat precies dit mechanisme gebruikte om Microsoft 365-accounts over te nemen en OAuth-tokens vast te leggen [11]. |
De rode draad is dat de skill-eis voor veel phishingtechnieken daalt. Niet omdat aanvallen simpeler worden, maar omdat de tooling kant-en-klaar wordt verkocht als Phishing-as-a-Service. Dat maakt vooral MKB kwetsbaar: de tegenstander hoeft niet beter te zijn dan uw IT-partner; hij hoeft alleen een geloofwaardige lokstap en een fout geconfigureerde identiteitsketen te vinden.
Hoe phishing escaleert naar een echte hack
Phishing wordt vaak te eng gedefinieerd als “mail met link”. In werkelijkheid is het meestal de initiële identiteitshandeling in een langere keten. Eerst wordt vertrouwen gewonnen of misbruikt, dan wordt een identiteit gebruikt, daarna volgt persistentie, en pas daarna komt de zichtbare schade: frauduleuze betalingen, data-exfiltratie, vendor-misbruik of encryptie. Twilio laat zien hoe één succesvol phishingpad meteen tientallen of honderden klantorganisaties kan raken; MGM en Caesars laten vervolgens zien hoe identiteitsmisbruik kan doorlopen naar operationele verstoring en hoge financiële impact.
Voor MKB zijn vooral vier escalatiepunten beslissend.
Het eerste is mailboxmisbruik:
aanvallers maken forwarding rules, lezen factuurstromen mee en sturen intern nieuwe lures.
Het tweede is token- en sessiemisbruik:
bij AiTM, device-code phishing en OAuth-consent is het niet genoeg om alleen wachtwoorden te resetten; tokens moeten worden ingetrokken en app-consents verwijderd.
Het derde is identity recovery: helpdesks, self-service reset, fallback-MFA en oude authenticatiemethoden zijn vaak zwakker dan de primaire login.
Het vierde is leverancierstoegang: een MSP, mailprovider of SaaS-tool kan de hele trust chain openzetten.
De detectiesignalen die MKB het vaakst over het hoofd ziet, zitten precies in die escalatiefase. Voorbeelden zijn nieuwe mailbox forwardingregels, OAuth-appconsent door gewone gebruikers, een nieuw MFA-device, veel denied pushrequests met daarna één succesvolle approval, een login vanaf een normale locatie maar met atypische browser-/sessiekenmerken, of een onverwachte wijziging in betaalinstructies vanuit een bestaand e-maildraadje. Geen van die signalen zie je terug in een simpel “phishing awareness dashboard”; ze zitten in identity-logs, mailflow-logs, endpointtelemetrie en change-events.
ISO27001 vertaald naar phishing weerbaarheid voor MKB
Phishingweerbaarheid in ISO-termen is een samengestelde control-set. Dat is ook precies waarom veel organisaties en auditors het fout aanpakken: zij zoeken één awarenessbewijs, terwijl Annex A de relevante maatregelen juist over people, organisatorische en technische controls verdeelt. Dat volgt direct uit de 2022-structuur van A.5 tot en met A.8. De onderstaande mapping is daarom een praktische interpretatie voor MKB, gebaseerd op de aanvalstechnieken hierboven.
Aanvals techniek | Relevante Annex A-controls | Minimale MKB-baseline | Versterking die sterk aan te raden is | Veelgemaakte fout |
Credential harvesting | A.6.3 awareness; A.8.5 secureAuthentication; A.8.15/A.8.16 logging/monitoring; A.5.24-A.5.26 incidentmanagement | MFA voor alle (cloud)accounts; blokkeren van legacy auth; mailreport-knop; logging van sign-ins en mailboxregels; reset en token revocation-proces | FIDO2/passkeys voor beheerders en finance; CA-policies; mailbox-rule alerts; suspicious impossible-travel review | “MFA staat aan” zonder te weten welke methoden, fallbacks en uitzonderingen actief zijn |
Malware via bijlagen/links | A.8.7 protection against malware; A.8.23 web filtering; A.8.15/A.8.16 | Defender/EDR, attachment sandboxing of veilige mailfilter, blokkeren van risicobestanden waar mogelijk, browser- en Office-hardening | Application control, macrobeleid, RMM-detectie, DNS/web filtering op (roaming) devices | Alleen antivirus tellen, maar geen EDR, geen browser/web controls en geen blokbeleid voor rare file types |
MFA fatigue | A.8.5 secure authentication; A.6.3 awareness | Push-notifications alleen met number matching of vergelijkbare bevestiging; rate-limiting; helpdesk-instructie bij MFA-problemen | FIDO2/passkeys voor admins en gevoelige rollen; uitschakelen van zwakke methoden zoals SMS waar mogelijk | Push-MFA uitrollen zonder number matching of gebruikersafspraken |
AiTM/phishing proxies | A.8.5, A.8.15/A.8.16, A.8.23, A.5.7 threat intelligence | MFA plus login- en sessielogs; afwijkende browsers/locations review; url-click bescherming | Phishing-resistente authenticatie; token protection waar platform dit ondersteunt; strengere CA-policies | Denken dat gewone MFA op zichzelf AiTM oplost |
OAuth-consent phishing | A.5.15-A.5.18 identity/access; A.8.15/A.8.16; A.5.24-A.5.26 | Eindgebruikers mogen niet vrij high-risk app-consents geven; app-registraties en grants loggen | Admin consent workflow; periodieke review van enterprise apps en Graph-rechten | Alleen naar wachtwoorden kijken, niet naar app-permissies en tokens |
QR-phishing | A.6.3, A.8.23, A.8.5 | Mobiele awareness specifiek op QR-codes; mailfilters ook op QR in PDF’s waar mogelijk; users instrueren om niet via QR in te loggen | MDM/mobile threat defense voor risicoprofielen; veilige mobiele browsers | Training alleen richten op zichtbare links in e-mails |
BEC/factuurfraude | A.6.3; A.5.14 information transfer; A.8.15/A.8.16; A.5.24-A.5.26 | Vier-ogenprincipe op rekeningwijzigingen en spoedbetalingen; callback-procedure naar bekend nummer; mailbox logging | Detectie op anomalieën in correspondentie, DMARC/SPF/DKIM streng afsluiten, stronger finance segregation | Vertrouwen op “de mail zag er legitiem uit” zonder onafhankelijke verificatie |
Spear-phishing/CEO-fraude | A.6.3, A.5.10 acceptable use, A.5.14, A.8.15/A.8.16 | Beschermde processtappen voor HR, finance, directie en IT; geen uitzonderingen voor “urgent van directie” | Extra identity controls voor directie en finance; executive monitoring en VIP-protection | Duidelijke processen hebben, maar directie buiten proces laten werken |
Helpdesk/social engineering | A.5.2 roles/responsibilities; A.5.17 authentication information; A.8.5; A.5.24-A.5.26 | Servicedesk mag nooit alleen op kennisvragen of beller-ID resetten; resets via aparte verificatiestap | Verbale passphrases of identity proofing, break-glass-procedures, call recording en review | Helpdesk zien als “operationeel”, niet als security control |
Supply-chain phishing | A.5.19-A.5.23 supplier- en cloudcontrols; A.8.15/A.8.16; A.5.24-A.5.26 | Supplier access register; MFA en least privilege voor MSP’s (of JIT access); incidentmeldplicht contractueel vastleggen | Review van vendor mailflows, delegated admin beperken, JML-proces voor leveranciersaccounts | Volledige tenant-admin aan leverancier geven zonder logging, review of contractuele eisen |
Twee controlgebieden verdienen extra scherpte.
Awareness en phishingtesten. Klassieke trainingen en losse “phishing simulaties” zijn geen onzin, maar wel zwakke primaire controls. Grote reproductiestudies vonden weinig statistisch effect van standaard training op klik- of rapportagegedrag; kleinere en interactievere interventies, zoals role-play en groepsdiscussie, lieten positievere effecten zien; langdurige, continue programma’s kúnnen de kwetsbaarheid verlagen, maar dat effect vervaagt door personeelswisselingen en organisatorische context. Voor auditdoeleinden betekent dit: vraag niet “heeft u training?”, maar “welk risico reduceert deze training aantoonbaar, voor welke rollen, en wat doet u technisch als training faalt?” [12].
MFA. MFA blijft extreem waardevol; in grootschalig onderzoek bleken MFA-geactiveerde accounts veel minder vaak gecompromitteerd dan accounts zonder MFA. Maar “MFA” is geen homogene maatregel. Push zonder number matching, SMS, zwakke recoveryflows, fallback-methoden, niet-gemonitorde app-consents en helpdesk-bypasses maken dat de controle wel op papier bestaat maar onvoldoende phishing-resistent is. Tegelijk laten studies naar FIDO2 en passkeys zien dat zij de lat tegen phishing duidelijk verhogen, terwijl enterprise-uitrol juist struikelt over recovery, lifecycle en legacy-ondersteuning. Voor MKB is de juiste conclusie dus niet “MFA werkt niet”, maar “MFA werkt, behalve waar uw organisatie de zwakke uitwijkpaden laat bestaan.” [13].
Waar reguliere audits vaak tekortschieten
De meest voorkomende auditfout is dat phishing wordt teruggebracht tot één people-control: awareness. Dat is precies de verkeerde abstrahering. De incidenten die publiek bekend zijn, tonen juist dat identity recovery, sessiecookies, OAuth-apps, leverancierstoegang, helpdeskprocedures en logging de doorslag geven wanneer een campagne door de eerste verdedigingslaag heen komt. Onderstaande auditmatrix is daarom nadrukkelijk een kritisch en praktisch MKB-model, afgeleid uit de aanvalspatronen en incidenten hierboven.
Controlgebied | Waar auditors te vaak genoegen mee nemen | Wat zij wél moeten vragen | Sterk bewijs |
Awareness en training | Presentielijst, e-learningcertificaten, één klikratio | Zijn finance, HR, directie en servicedesk apart getraind? Worden QR, phishing, OAuth en BEC behandeld? Is er follow-up op gedrag? | Rolspecifieke trainingsinhoud, rapportage over meldgedrag, lessons learned uit echte meldingen |
E-mailsecurity | “SPF/DKIM/DMARC staat ergens aan” | Staat DMARC op reject/quarantine of alleen monitor? Worden lookalike-domeinen, display-name en externe afzenders gemarkeerd? | Aanwijsbare mailpolicies, screenshots of exports van mailconfiguratie, DMARC-rapportage |
Web filtering | “Browser heeft safe browsing” | Wordt ook gefilterd buiten kantoor of op roaming devices? Worden nieuwe en onbekende domeinen, file-sharing-services en phishing categories geblokkeerd? | Policy-overzichten, blocklogs, incident- of testvoorbeelden |
Anti-malware en endpoint | Antivirus aanwezig | Is er EDR? Worden scripts, LNK/HTML-smuggling, ongewone remote tools en child-processen bewaakt? | EDR-configuratie, detectieregels, incidenttickets, blockevents |
MFA en conditional access | “MFA verplicht” | Welke methoden zijn toegestaan? Is SMS nog actief? Is number matching actief? Hoe werkt account recovery? Wie mag MFA-methoden resetten? | Exports van authentication methods, CA-policies, servicedesk runbooks, logs van method changes |
Logging en monitoring | SIEM-licentie of “logging staat aan” | Worden mailbox rules, OAuth grants, sign-ins, new devices, app consents en forwarding rules gelogd en beoordeeld? Hoe lang blijven logs beschikbaar? | Bewaartermijnen, concrete logevents, queries, alertregels |
Incident management | Procedure op papier | Kan men tokens revoken, mailboxregels verwijderen, account compromise isoleren en leveranciers snel laten meedoen? Is ooit geoefend op AiTM/BEC? | Oefenverslagen, incidentdossiers, post-incidentacties |
Leveranciers management | Standaard NDA of algemene SLA | Welke leveranciers mogen in de tenant? Hoe is delegated admin beperkt? Wat is de meldplicht en responstijd bij compromittering? | Supplier register, contractclausules, toegangsreview, admin-rollenlijst |
De conclusie is eenvoudig: een auditor die alleen naar awareness of incidentregistratie vraagt, audit niet op phishingweerbaarheid maar op papieraanwezigheid. Een auditor die geen vragen stelt over app-consent, MFA-reset, service desk, mailboxregels en vendor-admins, mist precies de paden waar hedendaagse campagnes daadwerkelijk doorheen gaan.
Casussen en wat daar echt van geleerd moet worden
1. Twilio en de 0ktapus-campagne is een schoolvoorbeeld van supply-chain phishing. Aanvallers stuurden gerichte SMS-berichten naar werknemers van meer dan honderd organisaties, met links naar overtuigende valse SSO-pagina’s. Twilio werd gecompromitteerd; secundaire slachtoffers waren onder meer Signal en Authy-gerelateerde accounts. Het relevante leerpunt voor MKB is niet alleen “let op SMS”, maar vooral dat identiteitsaanvallen tegen leveranciers en platformproviders zich als een hefboom gedragen: één succes kan tientallen klantorganisaties raken. Het verdedigingsverschil lag bij partijen als Cloudflare in phishing-resistente hardware keys en strakke access controls, niet bij beter opletten alleen. [1]
2. MGM Resorts en Caesars Entertainment tonen het gevaar van helpdesk- en identiteitsprocessen als zwakke plek. Reuters en andere betrouwbare bronnen koppelden de casino-incidenten aan Scattered Spider, een groep die phishing, social engineering en identiteitsmisbruik combineerde. Caesars meldde dat gevoelige klantdata was geraakt; MGM rapporteerde uiteindelijk een financiële impact van ongeveer 100 miljoen dollar en operationele verstoring van hotel- en casinofuncties. De les voor MKB is messcherp: een goed gefilterde inbox helpt weinig als uw helpdesk een telefoonnummer of MFA-device toevoegt op basis van sociale druk en oppervlakkige verificatie. [2]
3. Tycoon 2FA is geen enkel slachtoffer, maar misschien wel de belangrijkste hedendaagse infrastructuurcasus. Europol en Microsoft ondersteunden in 2026 de verstoring van dit PhaaS-platform, dat AiTM gebruikte om MFA te omzeilen, sessiecookies te stelen en op grote schaal account takeovers mogelijk te maken. De betekenis voor MKB is groot: er is geen geavanceerde staatsactor meer nodig om MFA te omzeilen; een crimineel kan tooling huren die dit kant-en-klaar levert. Daarom is “MFA verplicht” zonder FIDO2, logging, token revocation en sterke fallbackbeheersing simpelweg niet meer genoeg. [3]
4. BEC-cases zoals Unatrac en Ubiquiti, zoals geanalyseerd in academische literatuur, laten een ander maar even vernietigend patroon zien: geen ransomware, geen zichtbare malware, soms zelfs geen spectaculaire technische exploit, maar toch grote financiële schade omdat e-mailvertrouwen, beslissingsdruk en betalingsprocessen werden misbruikt. Voor MKB is dat essentieel, omdat juist kleinere organisaties vaak denken dat zij pas “echt gehackt” zijn als systemen uitvallen. In werkelijkheid kan de eerste materiële schade al zijn ontstaan terwijl de omgeving technisch nog ogenschijnlijk normaal draait. [4]
5. Nederlandse casuïstiek is in openbare bronnen vaak minder technisch uitgewerkt dan internationale SEC-filings en grote Amerikaanse incidenten. Dat is geen teken dat Nederlandse organisaties minder worden geraakt (Odido, Chipsoft, BasicFit), maar vooral dat de publieke forensische diepgang vaak beperkter is. Het Nederlandse MKB moet die lacune niet verwarren met lager risico. Het NCSC richt zijn dienstverlening inmiddels expliciet op het versterken van de digitale weerbaarheid van circa 2,4 miljoen bedrijven en organisaties in Nederland, juist omdat de dreiging breed is. [5]
Prioriteiten voor Nederlands MKB
Voor Nederlands MKB zonder SOC is het verstandig om niet te beginnen met een perfect programma, maar met een smalle, harde baseline die de meest misbruikte phishingpaden dichtzet. De prioritering hieronder is bewust pragmatisch en volgt de schade- en waarschijnlijkheidsmix uit de incidenten en studies hierboven.
Prioriteit | Wat regelen | Waarom eerst | Concreet minimumresultaat |
Direct | MFA saneren | Slechte MFA is een schijncontrol | Geen legacy auth; geen SMS voor admins/finance; push alleen met number matching; gedocumenteerde resetflow |
Direct | Mail- en identity-logging bruikbaar maken | Zonder logs geen detectie en geen incidentrespons | Sign-in logs, mailboxregels, forwarding, app-consent en method-changes minimaal aantoonbaar beschikbaar |
Direct | Finance- en directieprocessen verharden | BEC kan schade veroorzaken zonder zichtbare hack | Verplichte callback bij rekeningwijziging of spoedbetaling; vier-ogenprincipe |
Direct | Servicedesk identity proofing aanscherpen | Helpdesk is een aanvalsvlak | Geen resets of device-enrollment op basis van alleen beller-ID of HR-kennisvragen |
Binnen korte termijn | E-mailbeveiliging en web filtering verbeteren | Reductie van volume en klikroutes | DMARC opschalen, externe afzenders markeren, URL-/attachmentbescherming, web/DNS-filtering ook buiten kantoor |
Binnen korte termijn | Endpointbescherming op orde brengen | Bijlage- en toolsmisbruik stopt anders niet bij de mail | EDR met basisdetecties op scripts, LNK, HTML-smuggling en remote tools |
Binnen middellange termijn | App-consent en cloudtoegang beheersen | OAuth-consent en tokenmisbruik omzeilen wachtwoorddenken | Eindgebruikers mogen geen high-risk app-permissies zelfstandig verlenen |
Binnen middellange termijn | Vendor- en MSP-toegang beperken | Supply-chain phishing vergroot impact | Supplier register, least privilege, aparte adminaccounts, logreview |
Doorlopend | Awareness opnieuw positioneren | Training moet ondersteunend zijn, niet cosmetisch | Rolspecifieke mini-sessies, meldgedrag meten, QR/vishing/OAuth meenemen |
Doorlopend | Incidentrespons op phishing oefenen | Phishing is pas voorbij na containment en token cleanup | Oefening op mailbox takeover, BEC en OAuth-consent inclusief revoke-acties |
Een kort implementatiechecklist voor MKB kan zonder zware governance als volgt worden gebruikt:
Termijn | Praktische checklist | |
Binnen 30 dagen | Inventariseer alle gebruikte MFA-methoden; schakel legacy auth uit; leg vast wie accounts en MFA reset; activeer logging op sign-ins, mailboxregels en app-consent; voer callback-procedure in voor rekeningwijzigingen en spoedbetalingen. | |
Binnen 90 dagen | Markeer externe e-mail, verbeter DMARC, richt URL- en attachmentbescherming in, activeer EDR op alle beheerde endpoints, beperk eindgebruikersconsent voor cloudapps, beoordeel MSP- en leveranciersrollen, maak een korte playbook voor mailbox compromise en token revocation. | |
Binnen 180 dagen | Migreer gevoelige rollen naar phishing-resistente authenticatie zoals FIDO2/passkeys waar haalbaar, oefen een scenario met helpdesk-vishing en een scenario met BEC, toets of logs echt bruikbaar zijn tijdens een tabletop of praktijktest, en verwerk lessons learned in het ISMS. |
Ben ik gelijk gehackt als ik op een phishinglink klik? Niet altijd. In de meeste gevallen gebeurt er nog niets wanneer u alleen op een phishinglink klikt. Het daadwerkelijke risico ontstaat vaak pas wanneer u vervolgens een actie uitvoert, zoals het invoeren van uw gebruikersnaam en wachtwoord, het goedkeuren van een MFA-verzoek, het openen van een bestand of het installeren van software. Dat betekent echter niet dat het klikken op een link altijd onschuldig is. Sommige phishingwebsites proberen direct malware te downloaden of misbruik te maken van kwetsbaarheden in een browser of apparaat. Hoewel dit tegenwoordig minder vaak voorkomt dan credential harvesting, blijft het een reëel risico. Een phishingaanval verloopt meestal in één van de volgende stappen:
U klikt op een link → meestal nog geen compromittering.
U voert uw wachtwoord in → account mogelijk gecompromitteerd.
U keurt MFA goed → account waarschijnlijk gecompromitteerd.
U opent een kwaadaardige bijlage → apparaat mogelijk gecompromitteerd.
U installeert software → apparaat waarschijnlijk gecompromitteerd.
Praktische vuistregel: bent u per ongeluk op een verdachte link terechtgekomen, maar heeft u verder niets gedaan? Dan is de kans groot dat er geen directe schade is ontstaan. Heeft u gegevens ingevuld, een bestand geopend of een MFA-verzoek goedgekeurd? Meld dit direct bij IT of uw securityverantwoordelijke en wijzig uw wachtwoord zo snel mogelijk. Wat zien we tijdens audits?
Veel medewerkers melden een phishingincident pas wanneer zij denken dat zij "echt gehackt" zijn. Daardoor gaan waardevolle uren verloren. Ook een verdachte klik zonder verdere acties kan nuttige informatie opleveren voor onderzoek en monitoring. Meld het daarom altijd, ook als u twijfelt of er daadwerkelijk iets is gebeurd.
[1] https://www.wired.com/story/twilio-breach-phishing-supply-chain-attacks/
[4] https://arxiv.org/abs/2011.11112
[10] https://arxiv.org/abs/2511.20944
AuditDirect begeleid u van A tot Z richting uw ISO 27001 Certificatie
ISO Reality Check
Een kort, eerlijk gesprek om te bepalen of ISO 27001 écht nodig is.
GRATIS*
In 45 minuten bespreken we:
Waarom de ISO-eis er is (van uw klant of intern)
Of een certificering echt nodig is, of een alternatief volstaat
Wat uw organisatie nu al goed doet
En welke opties u hebt om het slimmer en eenvoudiger aan te pakken
En wij zijn zo pragmatisch, dat wij dit gesprek ook met u en uw klant aan willen gaan.
*Een beperkt aantal plekken beschikbaar.
Plan uw ISO Reality Check
Meer informatie
ISO Nulmeting
In één dag brengen we samen in kaart hoe ver uw organisatie al is richting ISO 27001.
€1.250,-
Binnen 24 uur krijgt u:
Een complete nulmeting van uw huidige situatie
een plan van aanpak met concrete vervolgstappen
Inzicht in uw sterkste én verbeterpunten
Draagvlak in de organisatie aangezien onze consultants gesprekken voeren met betrokken medewerkers
Begeleiding is pas na de nulmeting. Zo weten we precies wat wél en wat níet nodig is zonder onnodige tijdverspilling aan de kant van uw bedrijf.
Plan uw ISO Nulmeting
Meer informatie
ISO Interne Audit
Een praktische Interne Audit waarmee u precies weet of u klaar bent voor de externe audit.
€1.600*,-
Binnen 72 uur krijgt u:
Een complete onafhankelijke interne audit die voldoet aan de ISO 27001 norm 9.2.
Duidelijke en toepasselijke bevindingen en aanbevelingen
Concreet overzicht van verbeterpunten vóór de externe audit
Heldere toelichting voor management en betrokken teams
*prijs is gebaseerd op een kleine organisatie
Plan uw ISO Interne Audit
Meer informatie
AuditDirect
Boek nu een call
Contact
Rob Veen
7908 BN, Hoogeveen
Van Leeuwenhoekstraat 132
KVK nummer 91987024
AuditDirect
Boek nu een call
Contact
Rob Veen
7908 BN, Hoogeveen
Van Leeuwenhoekstraat 132
KVK nummer 91987024
AuditDirect
Boek nu een call
Contact
Rob Veen
7908 BN, Hoogeveen
Van Leeuwenhoekstraat 132
KVK nummer 91987024