For Dutch SMEs, phishing is not an “awareness topic”, but a practical line of attack leading to account takeover, payment fraud, data theft, supplier abuse, and ransomware. Furthermore, the modern variant no longer stops at a fake login page: attackers also abuse SMS, QR codes, OAuth consent, helpdesks, MFA push notifications, device-code flows, and trusted supplier relationships. In practice, this means that organizations with “MFA on” and “annual awareness” still get hacked. Major incidents at companies like Odido, Twilio, MGM Resorts, and Caesars show exactly this pattern.
This is relevant for ISO/IEC 27001:2022 because Annex A contains no single, standalone “phishing control”. Phishing resilience only arises from a combination of organizational, people, and technical controls: awareness and training, secure authentication, malware protection, web filtering, logging and monitoring, supplier management, and incident management. Moreover, ISO 27001:2022 explicitly groups its 93 controls into A.5 organizational, A.6 people, A.7 physical, and A.8 technological; precisely because of this, an audit must look at phishing as a chain and not as a standalone inbox problem. The core conclusion for SMEs is harsh but simple: anyone trying to solve phishing primarily with training leaves the real attack surfaces open. Anyone who only says “MFA” without seriously setting up phishing-resistant methods, reset procedures, fallback management, logging, and supplier access, is usually just setting up a false sense of security. Furthermore, large recent studies show that classic anti-phishing training often has limited or inconsistent effects, while interactive and ongoing interventions primarily help when they are implemented on top of technical measures, not instead of them. But what actually is phishing, really?
The technical attack landscape of phishing
The modern phishing chain is no longer a single email, but a flexible sequence of bait, identity theft, and escalation to higher impact. This pattern is clearly visible in real-world campaigns involving SMS phishing, captcha gates, token theft, QR codes, OAuth abuse, and helpdesk social engineering.
| Technique | Attack Flow | Common Indicators | Required Skills and Resources | Real-World Examples |
|---|---|---|---|---|
| Credential harvesting | Email/SMS/Teams message lures user to a fake login; entered credentials go straight to the attacker; followed by mailbox takeover, internal phishing, BEC, or data exfiltration. | New login from an unusual source; immediate mailbox rules or forwarding; failed followed by successful login; captcha page before login; PDF leading to browser login. | Low to medium: domain registration, phishing kit, hosting, brand impersonation. Modern kits lower the entry barrier significantly. | Microsoft described a 2026 campaign targeting over 35,000 users across 13,000 organizations in 26 countries using PDFs, captcha steps, and real-time credential and token collection. Microsoft also described a campaign using SVG files disguised as PDFs leading to credential harvesting [6]. |
| Malware via attachments or links | Lure message prompts user to open an attachment or download a file; this delivers malware, a loader, or legitimate remote tooling; followed by reconnaissance, lateral movement, and potentially ransomware. | SVG/ZIP/LNK/HTML smuggling; unexpected “voicemail”, “invoice”, or “secured pdf”; endpoint process starting PowerShell or remote tooling immediately after opening. | Low to medium for commodity malware; higher for stealth and evasion. | Microsoft described a campaign where scriptable SVG attachments were used to redirect users through captchas to phishing pages or payloads. Reports from Reuters and the FBI also show that ransomware remains a major operational risk after initial access is gained [7]. |
| MFA fatigue | Attacker already has a password and repeatedly pushes MFA requests until a user approves one; followed by account takeover and often privilege escalation. | Dozens of push requests; many “deny” actions followed by one “allow”; notifications outside working hours; helpdesk requests immediately following MFA issues. | Medium: previously compromised password, automated push spam. | Scattered Spider is known for MFA fatigue and other identity attacks; researchers and law enforcement linked this method to subsequent major compromises. |
| AiTM and phishing proxies | Victim logs into a proxy page that relays the real Microsoft or Google login; credentials, MFA code, and especially session cookies/tokens are intercepted in real time; after which no new MFA is needed. | Valid credentials and MFA, yet a suspicious session; new session cookies; browser or user-agent anomalies; successful login after suspicious redirect chain. | Medium to high; though PhaaS platforms are making this cheaper and cheaper. | Tycoon 2FA was dismantled in 2026; Europol and Microsoft linked it to AiTM, MFA bypass, nearly 100,000 affected organizations, and hundreds of attack domains. Barracuda also observed Whisper 2FA on a large scale targeting Microsoft 365 [8]. |
| OAuth consent phishing | User grants permission to an app instead of sharing a password; the attacker gets tokens or app permissions for email, files, or directory data; followed by persistent access without classic password abuse. | New app consent by end user; unexpected Graph permissions; email or files access by unknown app; suspicious app registrations. | Medium: malicious app registration, permission knowledge, convincing UX. | In 2025, Datadog described “CoPhish”, the abuse of Microsoft Copilot Studio agents on legitimate Microsoft domains for OAuth consent and token abuse. In 2026, Microsoft also warned of active OAuth campaigns designed to bypass browser and email defenses [9]. |
| QR phishing | QR code in email, PDF, poster, or package directs user to a login or malware page; filters that detect URLs in text often miss this. | PDF with QR code; “scan to view document”; unexpected QR in invoices or access requests; mobile device as an anomalous login source. | Low: QR generator and landing page are often sufficient. | The FBI warned in 2025 about QR scams in unsolicited packages; there are also warnings for targeted quishing by Kimsuky. Researchers emphasize that QR phishing is explicitly designed to bypass classic URL inspection. |
| BEC and invoice fraud | Attacker uses a spoofed or compromised mailbox, monitors ongoing correspondence, and sends payment or bank account changes; the goal is fraud, not necessarily malware. | Threads about invoices suddenly become “urgent”; subtle domain variations; changes to IBAN; request for confidentiality; reply behavior outside normal patterns. | Low to medium: mailbox access plus social engineering. | FBI figures show that BEC continues to cause billions in losses; academic case studies analyzed Unatrac and Ubiquiti, among others, as examples of major BEC impact [10]. |
| Spear phishing and CEO fraud | Attacker highly personalizes based on role, timing, and context; targets are often finance, executive management, HR, or IT; ultimate goal is money, data, or an initial foothold. | Language and context seem “too good”; reference to real projects or schedules; pressure for speed; unusual channels or private email. | Medium to high; AI significantly lowers the personalization barrier. | Recent research literature shows that generative AI can create context-aware spear phishing at scale with convincing style and context imitation. Practically, this aligns with CEO fraud and BEC. |
| Helpdesk and voice social engineering | Attacker calls or chats with service desk, impersonates an employee or vendor, and gets passwords reset, phone numbers added, or MFA devices registered; followed by account takeover and often ransomware. | Urgent reset requests; request for a “new number” or new device; deep knowledge of internal processes; calls shortly after credential theft or SIM swap. | Medium; requires good pretexting and OSINT, little malware knowledge. | Reuters and other reports linked Scattered Spider to social engineering against MGM and Caesars; subsequent warnings for retailers and aviation re-emphasized the abuse of helpdesks and MFA resets. |
| Supply chain phishing | Attacker compromises a vendor, MSP, or SaaS provider and uses that trusted relationship for secondary attacks; goal is scale, credibility, and access to multiple clients. | Valid vendor mailbox but unusual content; vendor asks for a new login or file; staff trusts the sender too quickly; shared tenants or admins. | Medium to high; requires supplier compromise or abuse of support chains. | Twilio was compromised via SMS phishing; this secondarily affected customer organizations like Signal, carrying supply-chain impacts. Wired also described similar third-party impacts at DoorDash and Mailchimp [1]. |
| Device code phishing | Attacker sends a real Microsoft device code and prompts victim to log in via a legitimate Microsoft page; victim effectively authorizes the attacker’s device; result is token-based access without password theft. | Device-code login event; legitimate Microsoft page, but originating from a suspicious initiation channel; long-lived access and refresh tokens. | Low to medium thanks to ready-to-use kits. | The FBI warned in May 2026 of Kali365, which used exactly this mechanism to take over Microsoft 365 accounts and capture OAuth tokens [11]. |
The common thread is that the skill level required for many phishing techniques is dropping. Not because attacks are getting simpler, but because the tooling is sold ready-to-use as Phishing-as-a-Service. This makes SMEs particularly vulnerable: the adversary does not need to be better than your IT partner; they only need to find a credible bait step and a misconfigured identity chain.
How phishing escalates into a real breach
Phishing is often defined too narrowly as just “an email with a link.” In reality, it is usually merely the initial identity action in a longer chain. First, trust is won or abused, then an identity is used, followed by persistence, and only after that comes the visible damage: fraudulent payments, data exfiltration, vendor abuse, or encryption. Twilio shows how a single successful phishing path can instantly hit dozens or hundreds of client organizations; MGM and Caesars then show how identity abuse can escalate into operational disruption and high financial impact.
For SMEs, four escalation points are particularly decisive.
The first is mailbox abuse: attackers create forwarding rules, monitor invoice streams, and send new internal lures.
The second is token and session abuse: with AiTM, device-code phishing, and OAuth consent, it is not enough to just reset passwords; tokens must be revoked and app consents removed.
The third is identity recovery: helpdesks, self-service resets, fallback MFA, and legacy authentication methods are often weaker than the primary login.
The fourth is supplier access: an MSP, email provider, or SaaS tool can expose the entire trust chain.
The detection signals that SMEs miss most often are exactly in this escalation phase. Examples include new mailbox forwarding rules, OAuth app consent by standard users, a new MFA device, multiple denied push requests followed by one successful approval, a login from a normal location but with atypical browser/session characteristics, or an unexpected change in payment instructions within an existing email thread. You won’t find any of these signals on a simple “phishing awareness dashboard”; they reside in identity logs, mail flow logs, endpoint telemetry, and change events.
ISO 27001 translated into phishing resilience for SMEs
Phishing resilience in ISO terms is a composite control set. This is exactly why many organizations and auditors get it wrong: they look for a single proof of awareness, whereas Annex A splits the relevant measures across people, organizational, and technical controls. This follows directly from the 2022 structure of A.5 through A.8. The mapping below is therefore a practical interpretation for SMEs, based on the attack techniques described above.
| Attack Technique | Relevant Annex A Controls | Minimum SME Baseline | Highly Recommended Enhancements | Common Mistake |
|---|---|---|---|---|
| Credential harvesting | A.6.3 awareness; A.8.5 secure authentication;A.8.15/A.8.16 logging/monitoring; A.5.24-A.5.26 incident management | MFA for all (cloud) accounts; blocking legacy auth; email report button; logging of sign-ins and mailbox rules; reset and token revocation process | FIDO2/passkeys for admins and finance; CA policies; mailbox rule alerts; suspicious impossible-travel review | “MFA is on” without knowing which methods, fallbacks, and exceptions are active |
| Malware via attachments/links | A.8.7 protection against malware; A.8.23 web filtering; A.8.15/A.8.16 | Defender/EDR, attachment sandboxing or secure email filter, blocking risky files where possible, browser and Office hardening | Application control, macro policies, RMM detection, DNS/web filtering on (roaming) devices | Counting only antivirus, but having no EDR, no browser/web controls, and no block policy for unusual file types |
| MFA fatigue | A.8.5 secure authentication; A.6.3 awareness | Push notifications only with number matching or similar verification; rate-limiting; helpdesk instructions for MFA issues | FIDO2/passkeys for admins and sensitive roles; disabling weak methods like SMS where possible | Rolling out push MFA without number matching or user agreements |
| AiTM/phishing proxies | A.8.5, A.8.15/A.8.16, A.8.23, A.5.7 threat intelligence | MFA plus login and session logs; anomalous browsers/locations review; URL click protection | Phishing-resistant authentication; token protection where supported by platform; stricter CA policies | Believing that standard MFA on its own solves AiTM |
| OAuth consent phishing | A.5.15-A.5.18 identity/access; A.8.15/A.8.16; A.5.24-A.5.26 | End users should not be allowed to freely grant high-risk app consents; log app registrations and grants | Admin consent workflow; periodic review of enterprise apps and Graph permissions | Only looking at passwords, completely ignoring app permissions and tokens |
| QR phishing | A.6.3, A.8.23, A.8.5 | Mobile awareness specifically for QR codes; email filters checking QR in PDFs where possible; instructing users not to log in via QR | MDM/mobile threat defense for risky profiles; secure mobile browsers | Focusing training exclusively on visible links in emails |
| BEC/invoice fraud | A.6.3; A.5.14 information transfer; A.8.15/A.8.16; A.5.24-A.5.26 | Four-eyes principle on account changes and urgent payments; callback procedure to a known number; mailbox logging | Detection of anomalies in correspondence, strictly enforcing DMARC/SPF/DKIM, stronger segregation of duties in finance | Relying on “the email looked legitimate” without independent verification |
| Spear phishing/CEO fraud | A.6.3, A.5.10 acceptable use, A.5.14, A.8.15/A.8.16 | Protected process steps for HR, finance, management, and IT; no exceptions for “urgent requests from management” | Extra identity controls for management and finance; executive monitoring and VIP protection | Having clear processes, but allowing management to work outside of them |
| Helpdesk/social engineering | A.5.2 roles/responsibilities; A.5.17 authentication information; A.8.5; A.5.24-A.5.26 | Service desk must never reset credentials based solely on knowledge questions or caller ID; resets via a separate verification step | Verbal passphrases or identity proofing, break-glass procedures, call recording and review | Viewing the helpdesk as merely “operational” rather than a security control |
| Supply chain phishing | A.5.19-A.5.23 supplier and cloud controls; A.8.15/A.8.16; A.5.24-A.5.26 | Supplier access register; MFA and least privilege for MSPs (or JIT access); contractually mandate incident reporting | Review of vendor mail flows, restricting delegated admins, JML process for supplier accounts | Giving full tenant admin rights to a supplier without logging, review, or contractual obligations |
Two control areas deserve extra scrutiny.
- Awareness and phishing tests. Classic training and isolated “phishing simulations” are not useless, but they are weak primary controls. Large replication studies found little statistical effect of standard training on click or reporting behavior; smaller, more interactive interventions like role-play and group discussions showed more positive results; long-term, continuous programs can lower vulnerability, but this effect fades with staff turnover and organizational changes. For audit purposes, do not ask “do you have training?” but rather “what risk does this training demonstrably reduce, for which roles, and what is your technical fallback when training fails?” [12].
- MFA. MFA remains extremely valuable; large-scale research shows that accounts with MFA enabled are far less likely to be compromised than those without. However, “MFA” is not a uniform measure. Push notifications without number matching, SMS, weak recovery flows, fallback methods, unmonitored app consents, and helpdesk bypasses mean that while the control exists on paper, it is not sufficiently phishing-resistant. At the same time, studies on FIDO2 and passkeys show they clearly raise the bar against phishing, although enterprise deployment often struggles with recovery, lifecycle management, and legacy support. For SMEs, the correct conclusion is not “MFA does not work,” but “MFA works, except where your organization leaves weak fallback paths open.” [13].
Where regular audits often fall short
The most common auditing mistake is reducing phishing to a single people control: awareness. This is exactly the wrong abstraction. Publicly known incidents prove that identity recovery, session cookies, OAuth apps, supplier access, helpdesk procedures, and logging are what make or break security when a campaign gets past the first line of defense. The audit matrix below is therefore explicitly designed as a critical and practical SME model, derived from the attack patterns and incidents above.
| Control Area | What auditors too often settle for | What they should actually ask | Strong Evidence |
|---|---|---|---|
| Awareness and training | Attendance list, e-learning certificates, single click rate | Are finance, HR, management, and the service desk trained separately? Do sessions cover QR, phishing, OAuth, and BEC? Is there behavioral follow-up? | Role-specific training content, reporting on user submissions, lessons learned from real alerts |
| Email security | “SPF/DKIM/DMARC is turned on somewhere” | Is DMARC set to reject/quarantine or monitor-only? Are lookalike domains, display name spoofing, and external senders flagged? | Identifiable mail policies, screenshots or exports of mail configuration, DMARC reporting |
| Web filtering | “Browser has safe browsing enabled” | Is filtering enforced outside the office or on roaming devices? Are new and unknown domains, file-sharing services, and phishing categories blocked? | Policy overviews, block logs, incident or test examples |
| Anti-malware and endpoint | Antivirus present | Is EDR deployed? Are scripts, LNK/HTML smuggling, unusual remote tools, and child processes monitored? | EDR configuration, detection rules, incident tickets, block events |
| MFA and conditional access | “MFA mandatory” | Which methods are allowed? Is SMS still active? Is number matching enabled? How does account recovery work? Who is authorized to reset MFA methods? | Exports of authentication methods, CA policies, service desk runbooks, logs of method changes |
| Logging and monitoring | SIEM license or “logging is enabled” | Are mailbox rules, OAuth grants, sign-ins, new devices, app consents, and forwarding rules logged and reviewed? How long are logs kept? | Retention periods, actual log events, queries, alert rules |
| Incident management | A written procedure | Can you quickly revoke tokens, remove mailbox rules, isolate account compromise, and engage suppliers? Have you ever run a tabletop drill for AiTM/BEC? | Drill reports, incident files, post-incident actions |
| Supplier management | Standard NDA or general SLA | Which suppliers have access to your tenant? How are delegated admin rights restricted? What is the reporting window and response time in case of a breach? | Supplier register, contract clauses, access reviews, admin role list |
The conclusion is simple: an auditor who only asks about awareness or incident logging is auditing for compliance on paper, not actual phishing resilience. An auditor who fails to ask about app consent, MFA resets, service desk procedures, mailbox rules, and vendor admins is missing the very pathways that modern campaigns exploit.
Case studies and what should actually be learned from them
1. Twilio and the 0ktapus campaign is a textbook example of supply chain phishing. Attackers sent targeted SMS messages to employees of over a hundred organizations, with links to highly convincing fake SSO pages. Twilio was compromised; secondary victims included Signal and Authy-associated accounts. The key takeaway for SMEs is not just to “watch out for SMS”, but that identity attacks against suppliers and platform providers act as a multiplier: a single success can impact dozens of client organizations. The difference in defense for companies like Cloudflare lay in phishing-resistant hardware keys and tight access controls, not simply in staff paying better attention. [1]
2. MGM Resorts and Caesars Entertainment demonstrate the danger of helpdesk and identity recovery processes as weak points. Reuters and other reputable sources linked these casino incidents to Scattered Spider, a group that combined phishing, social engineering, and identity theft. Caesars reported that sensitive customer data was accessed; MGM ultimately reported an estimated financial impact of $100 million and operational disruption to hotel and casino systems. The lesson for SMEs is razor-sharp: a well-filtered inbox does little if your helpdesk adds a phone number or MFA device based on social pressure and superficial verification. [2]
3. Tycoon 2FA is not a single victim, but perhaps the most significant modern infrastructure case. Europol and Microsoft supported the disruption of this PhaaS platform in 2026, which used AiTM to bypass MFA, steal session cookies, and enable large-scale account takeovers. The impact for SMEs is massive: you no longer need an advanced nation-state actor to bypass MFA; a petty criminal can rent tooling that does it out of the box. That is why “mandatory MFA” without FIDO2, logging, token revocation, and rigorous fallback management is simply no longer enough. [3]
4. BEC cases like Unatrac and Ubiquiti, as analyzed in academic literature, reveal a different but equally devastating pattern: no ransomware, no visible malware, sometimes not even any dramatic technical exploit, but still massive financial losses because email trust, organizational pressure, and payment workflows were exploited. This is essential for SMEs, as smaller businesses often think they have only been “really hacked” when systems go offline. In reality, material damage can occur while the technical environment still appears to run normally. [4]
5. Dutch case studies are often less technically detailed in public sources compared to international SEC filings and major US incidents. This is not a sign that Dutch organizations are hit less often (Odido, Chipsoft, BasicFit), but rather that public forensic disclosure is often more limited. Dutch SMEs must not mistake this lack of details for a lower risk profile. The Dutch NCSC is now explicitly focusing its services on strengthening the digital resilience of approximately 2.4 million businesses and organizations in the Netherlands, precisely because the threat is widespread. [5]
Priorities for Dutch SMEs
For Dutch SMEs without a dedicated Security Operations Center (SOC), it is wise not to start with an all-inclusive program, but with a narrow, hard baseline that closes off the most abused phishing pathways. The prioritization below is intentionally pragmatic and matches the damage and probability mix observed in the incidents and studies above.
| Priority | What to set up | Why first | Concrete Minimum Result |
|---|---|---|---|
| Immediate | Clean up MFA | Weak MFA is a cosmetic control | No legacy auth; no SMS for admins/finance; push notifications with number matching only; documented reset flow |
| Immediate | Enable usable email and identity logging | Without logs, there is no detection and no incident response | Sign-in logs, mailbox rules, forwarding, app consent, and method changes must be demonstrably available |
| Immediate | Harden finance and executive processes | BEC can cause damage without any visible system breach | Mandatory callback for bank account changes or urgent payments; four-eyes principle |
| Immediate | Tighten service desk identity verification | The helpdesk is a major attack surface | No resets or device enrollments based solely on caller ID or HR knowledge questions |
| Short term | Improve email security and web filtering | Reduction of volume and click-through options | Enforce DMARC, flag external senders, implement URL/attachment protection, DNS/web filtering active outside the office |
| Short term | Deploy proper endpoint protection | Otherwise, attachment and tool abuse won’t stop at the inbox | EDR with basic controls for scripts, LNK files, HTML smuggling, and remote admin tools |
| Medium term | Manage app consent and cloud access | OAuth consent and token abuse bypass password-centric defenses | End users must not be allowed to grant high-risk app permissions on their own |
| Medium term | Restrict vendor and MSP access | Supply-chain phishing multiplies threat impact | Supplier registry, least privilege, dedicated admin accounts, log reviews |
| Ongoing | Reposition user awareness | Training must support technical defenses, not replace them cosmetic-only | Role-specific mini-sessions, measuring reporting rates, including QR/vishing/OAuth scenarios |
| Ongoing | Practice phishing incident response | Phishing is only resolved after containment and token cleanup | Drill scenarios for mailbox takeover, BEC, and OAuth consent including token-revoke actions |
A short implementation checklist for SMEs can be used without heavy governance as follows:
| Timeline | Practical Checklist | |
|---|---|---|
| Within 30 days | Inventory all active MFA methods; disable legacy auth; document who is authorized to reset accounts and MFA; activate logging for sign-ins, mailbox rules, and app consent; implement a callback procedure for bank account modifications and urgent payments. | |
| Within 90 days | Flag external emails, improve DMARC, set up URL and attachment protection, deploy EDR on all managed endpoints, restrict user consent for cloud apps, review MSP and supplier access roles, draft a brief playbook for mailbox compromise and token revocation. | |
| Within 180 days | Migrate sensitive roles to phishing-resistant authentication like FIDO2/passkeys where viable, run a helpdesk voice-phishing (vishing) drill, simulate a BEC scenario, test if logs are actually usable during a tabletop or practical test, and integrate lessons learned into your ISMS. |
Am I hacked immediately if I click on a phishing link? Not always. In most cases, nothing happens if you only click on a link. The actual risk usually arises when you perform a subsequent action, such as entering your username and password, approving an MFA request, opening a file, or installing software. However, that does not mean clicking a link is always harmless. Some phishing websites attempt to trigger immediate malware downloads or exploit vulnerabilities in a browser or device. While this is less common today than credential harvesting, it remains a real risk. A phishing attack typically progresses through the following steps:
- You click a link → usually no compromise yet.
- You enter your password → account potentially compromised.
- You approve MFA → account likely compromised.
- You open a malicious attachment → device potentially compromised.
- You install software → device likely compromised.
Practical rule of thumb: if you accidentally landed on a suspicious link but did nothing else, there is a good chance no immediate damage was done. Did you fill in details, open a file, or approve an MFA request? Report this immediately to IT or your security officer and change your password as quickly as possible. What do we see during audits?
Many employees only report a phishing incident when they believe they have been “really hacked.” This loses valuable hours. Even a suspicious click without further action can provide useful information for investigation and monitoring. Therefore, always report it, even if you are unsure whether anything actually happened.
[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