Kennisbank · 25 mei 2026

Device-code phishing trainen: leer medewerkers onverwachte codes melden

Door Sander Vermeer

Veel phishingtraining leert medewerkers vooral om foute links, rare afzenders en taalfouten te herkennen. Dat blijft nuttig, maar het is niet genoeg voor device-code phishing. De IC3-waarschuwing van 21 mei 2026 over Kali365 laat zien waarom: de gebruiker kan naar een echte Microsoft-verificatiepagina worden gestuurd en toch de verkeerde toegang goedkeuren.

Een training die alleen vraagt “zie je de neplink?” mist dan de kern. De betere oefenvraag is: waarom vraagt iemand mij nu om een code in te voeren? Als medewerkers die vraag leren stellen, wordt de kans groter dat ze stoppen en melden voordat er toegang ontstaat.

Train de aanleiding, niet alleen het scherm

Bij device-code phishing ziet het scherm er vaak minder verdacht uit dan de opdracht eromheen. De mail, chat of documentmelding probeert de medewerker naar een handeling te duwen die niet logisch past bij het werkmoment. Daarom moet de training niet beginnen met een screenshot van een loginpagina, maar met de context: wie vraagt dit, waarom nu, en welk apparaat hoort erbij?

• Laat medewerkers oefenen met berichten waarin een code wordt gevraagd zonder dat ze zelf een apparaat koppelen.
• Bespreek dat een echte verificatiepagina niet automatisch betekent dat de opdracht veilig is.
• Gebruik scenario’s waarin melden de juiste actie is, ook als er nog niets “mis” lijkt.
• Vermijd afrekentaal. De gewenste reflex is vertragen en melden.

Op Phishingtrainer sluiten we dit aan op phishing voorbeelden voor training en de gratis phishing trainingscan. Daarmee kun je eerst bepalen welke situaties voor jouw team herkenbaar zijn.

Maak van MFA geen blind vertrouwen

Een veelgemaakte trainingsfout is dat MFA wordt uitgelegd als eindstation: als het aanstaat, zijn we veilig. In de praktijk moeten medewerkers juist leren dat MFA-prompts ook beoordeeld moeten worden. Heb ik dit zelf gestart? Klopt het apparaat? Klopt het moment? Verwacht ik deze toegang? Zo niet, dan is melden beter dan gokken.

De unieke les uit Kali365 is dat aanvallers niet altijd het wachtwoord nodig hebben. Ze kunnen proberen de gebruiker een legitieme toegangshandeling te laten uitvoeren. Training moet daarom minder gaan over “trap niet in slechte mails” en meer over “autoriseer niets dat je niet zelf begrijpt”.

Een oefening in drie minuten

Je kunt dit klein oefenen. Toon een korte mail waarin staat dat iemand een document moet openen via een verificatiecode. Vraag medewerkers niet alleen of ze klikken, maar wat ze zouden controleren. Het goede antwoord is niet “ik herken meteen phishing”. Het goede antwoord is: ik heb deze code niet zelf aangevraagd, ik voer hem niet in en ik meld het bericht.

Bespreek daarna wat de meldroute moet zijn. Een medewerker die twijfelt, moet niet eerst vijf pagina’s beleid hoeven vinden. Zet een vast meldadres, een knop of een korte afspraak neer: twijfel over een code is altijd melden.

Wat je meet

Meet niet alleen hoeveel mensen de code zouden invullen. Meet vooral hoeveel mensen de situatie vroeg melden en welke woorden ze gebruiken. Als meldingen vaag blijven, weet het securityteam vaak nog niet of er een sessie is ontstaan. Train daarom op zinnen als: “Ik kreeg een onverwachte apparaatcode en heb die wel/niet ingevuld.”

Bron voor de aanleiding: de IC3-waarschuwing Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens.