Marie-Michèle Normandeau
Subject matter expert
Overview
Last week, a phishing campaign hit several of our customers—the one our research team documented in Link Laundering & Device-Code Deception. It was aimed at executives by name and at other important mailboxes, and it came from the genuine, authenticated mailboxes of real Canadian small businesses. These were not spoofs or lookalike domains. The emails were dressed as routine billing correspondence, and the link inside pointed to Google.
By every test most phishing training teaches, those emails passed. The senders were real. The domain was famous. There was no misspelling to catch, no suspicious URL to hover over and unmask.
Layered email defences did their job on most of it. The variant aimed at the executives was flagged and quarantined. But one variant slipped past the filters and reached an inbox.
The person who received it reported it.
That single report led our research team to the entire campaign and gave every other customer in the blast radius early warning. That moment is what a modern awareness program is for: a person caught the message the filters missed.
The short version
What changed
- Real, compromised senders can pass reputation checks.
- Trusted services can hide the attacker's final destination.
- A genuine Microsoft sign-in page can still be part of an attack.
What to teach
- Stop when an authentication request appears that you did not initiate.
- Open documents and portals through a known bookmark or app, not an email link.
- Report uncertainty quickly; detection belongs to employees, diagnosis to security.
A clean link is not proof that an interaction is safe.
Link inspection still matters, but modern awareness programs must also teach people to notice when the story of a task breaks.
What our research team found
Our research team investigated the campaign in real time and traced what happened after that innocent-looking Google link. It was laundered through a legitimate Monday.com tracking redirect before handing the victim to attacker infrastructure—a chain built specifically so that no single hop would look wrong. The fake Microsoft sign-in page at the end even had the victim's email address already filled in, so it looked less like a form to question and more like a session that had timed out. The kit behind it could capture MFA codes in real time, not just passwords.
A second lure in the same investigation was nastier still. It never showed a fake login page at all. It handed
the victim a genuine Microsoft device authorization code and coached them to paste it into Microsoft's
real sign-in page. The victim authenticates on login.microsoftonline.com—the actual domain
and the actual page—and the attacker walks away with working access tokens.
The full technical analysis is worth reading. My focus here is different: what these findings mean for how organizations prepare people to make decisions.
Link checking still matters, but it has limits
Our research team wrote something in that article that deserves careful reading:
The takeaway is not “train users to spot bad links.”
The wrong conclusion would be to stop teaching link inspection, a basic skill everyone should ideally master. Inspecting links, recognizing lookalike domains, and comparing displayed text with real destinations still stop many everyday phishing attempts.
But their real function is narrower than most training implies. Technical inspection can give an employee reasons not to proceed. What it cannot do, and never could, is provide affirmative proof that an entire interaction is safe. A real sender can be a compromised sender. A famous first domain says nothing about the last one in the chain. A genuine Microsoft login page can be the final step of an attack.
Most awareness programs give too much weight to a clean link. The campaign our team dissected was engineered precisely for that mental model. The problem is not that we teach people to check links. It is that most programs have little to say about what happens when the link check comes back clean and something is still not right.
The layer most programs are missing: what happens after the check passes
Here is what a modern awareness rule looks like. It comes straight from our team's findings:
No legitimate service asks you to paste a code that a website gave you into a sign-in screen. That instruction, by itself, is the attack.
This rule is about recognizing an unexpected authentication request: a sign-in you did not initiate, a code you did not ask for, or an approval prompt that does not match anything you just did. The situation is the red flag, even when every technical detail checks out.
In practice, for an employee with no security background, the moment worth teaching in this campaign was the password prompt itself. The recipient was already signed in to Microsoft 365 and reading email when a page produced by that email asked for their password. A sign-in request appearing in the middle of a task that never needed one is the event to react to. Two plain-language rules cover it:
1. Did I start this?
Any password prompt, approval push, or verification code you did not initiate means stop, not evaluate.
2. Never sign in through the link
If a document or invoice genuinely requires signing in, close the page and reach the portal the way you always do—through your bookmark or desktop app. If the document is real, it will be waiting there.
This single habit defeats an entire laundered-link chain without the employee needing to understand redirects at all.
Rules like these work because they do not ask employees to out-analyze an attacker. They do not have to be right. They have to notice the story of their task breaking and report it. The person who contained this campaign never proved the email was malicious and never needed to. Reporting was fast, carried no penalty, and someone acted on it in time. Detection is the employee's job. Diagnosis belongs to the security team. Programs that blur that division ask too much of people and then blame them for it.
How many rules like these does your current program teach? For many organizations, the honest answer is few or none, because the program was designed around indicators and these attacks are designed to have none. Which rules an organization needs—and how to turn them into reflexes rather than posters—depends on its workflows, authentication setup, and reporting path. That is program design work.
Five questions to ask about your program
Your program almost certainly has strong numbers: completion rates, quiz scores, and maybe declining click rates on simulations. But those measure participation in a curriculum. They do not tell you whether the report that contained this campaign would happen in your organization.
- When was the content last updated against real campaigns? Does it cover attacks where the sender is genuine and the login page is real, or only classic red flags?
- Does it teach any rules for unexpected authentication requests? That includes device codes, unprompted MFA approvals, and sign-in requests employees did not initiate.
- Do your simulations ever include scenarios with few or no technical indicators? Are they measured on whether people report, or does every test contain a findable flaw?
- Can an employee report a suspicious message in one click, without fear of being wrong? And does anyone act on those reports fast enough to matter?
- What do you measure besides training completion? If a clean-looking phish landed tomorrow, would any metric you track today predict whether it gets reported?
If you can answer all five with confidence, your program is ahead of most. If two or more gave you pause, the gap is not a missing training module. It runs through content, process, measurement, and how awareness connects to your technical controls.
Realistic simulations, without setting people up to fail
A fair objection at this point: awareness leaders are rightly told to keep simulations achievable so employees stay confident, keep participating, and keep reporting. We agree. So does a scenario engineered to pass every check not simply set people up to fail?
It does if it is run like an ordinary simulation. The first condition is that it must be treated differently, not merely labelled differently. Results are read in aggregate. No individual is tracked or named. The message shown after a click is honest: this test was built to pass every check, most people proceed, and here is the one tell that gave it away. Nobody can be bulletproof against an attack with no flaws to find, and the exercise should say so.
That is why the metric changes with the difficulty: not who clicked, but whether anyone reported and how quickly. A report that comes after a click still counts, because in a real incident that report is what limits the damage. The result is feedback on the program.
The second condition is sequence. Realistic scenarios belong in a program only after the basics are in place: recognition skills built through achievable simulations, a one-click reporting path, and a culture where reporting a false alarm is welcomed.
With those two conditions met, a realistic test is not a gotcha and does not undermine confidence. It shows employees their judgment matters even when the checklist comes up clean—which is exactly the behaviour that contained the campaign our team investigated.
Where to go from here
Modernizing a program for these attacks is not about adding another generic phishing module. It means rethinking what employees are trained to decide, how ambiguity gets reported, what readiness actually gets measured, and how the human layer connects to controls like phishing-resistant MFA and restricted authentication flows—the technical defences our research team recommends in its analysis.
That work crosses training, IT, and governance, and it starts with an honest look at where your current program stands.
If you are not sure how your program would hold up against the campaign described here, that is usually a sign it is worth an outside look.