From 35.8% to 2.7%: what a pattern in support tickets taught us about phishing

Most security problems don't announce themselves. They show up sideways, in a support queue, as a handful of small, slightly embarrassed tickets that are easy to close and forget.

That's how this one started. Over a few weeks, we noticed the same kind of ticket coming in again and again from one client. A member of staff had clicked a link and wasn't sure they should have. Someone had received an email that didn't feel right. Someone else had typed a password into a page and only afterwards wondered whether it was genuine. In a few cases, endpoint protection had fired straight after a link was clicked.

Each ticket on its own was minor. Together, they told a clear story: people were clicking, some were entering credentials, and they only realised afterwards. So we took the pattern to the client and suggested awareness training. Before that, though, we suggested finding out how big the problem really was.

Measure first, then train

It's tempting to go straight to training when you suspect a phishing problem. But training without a baseline is guesswork. You don't know which lures work on your people, how many are affected, or whether anything you do afterwards actually changes behaviour.

A controlled phishing simulation answers those questions. It shows how many people would fall for a realistic email today, and it gives you a number to measure against later.

How the simulation worked

We registered a domain similar to the client’s own and used it to send a realistic email, the kind staff might plausibly receive on an ordinary working day. The email contained a link to a simulated sign-in page, also hosted on that domain.

For each recipient, we recorded three things: whether they clicked the link, whether they submitted the sign-in form, and when each of those happened. We agreed the scenario, the domain and the allowlisting with the client's IT team before anything was sent, so the test ran in a controlled way and nothing reached staff unexpectedly.

One point matters more than any other: passwords were never captured or stored. We recorded that a submission happened, not what was typed. A simulation should measure behaviour, not collect credentials.

What the first round found

The first round went to 1,829 employees.

655 people clicked the link, which is 35.8%. More than one person in three.

393 people went further and submitted the sign-in form, which is 21.5%. In a real attack, that's more than one in five staff handing their credentials to someone outside the business.

No one reported the email through the simulation's reporting dashboard. That doesn't prove nobody raised it through another channel, but it did suggest reporting wasn't yet a habit.

We deliberately didn't read too much into email opens. Privacy controls and mail scanners can open messages automatically, which inflates the numbers, so we focused on clicks and submissions. We also reviewed automated interactions before drawing any conclusions about individual behaviour.

The awareness pack

The first round results were the training brief. Rather than sending out a generic phishing course, we built a pack for the client to send to every employee, based on what had actually happened.

It had three parts. The first explained what we'd done and what we'd found, openly, so nobody felt caught out or tricked. The second showed the simulated emails staff had received, with the warning signs marked, so people could see exactly what they'd missed. The third used screenshots of the real URLs to show what to check in the address bar before signing in anywhere.

The point was to make it personal. People remember far more from the email they fell for than from a stock example in a course.

The second round

Once the pack had gone out, we ran a second round to the same 1,829 employees.

This time, 50 people clicked, down from 655, a click rate of 2.7%. 19 people submitted the form, down from 393, which is about 1%.

That's a 92.4% fall in clicks and a 95.2% fall in submissions between the two rounds.

What the numbers do and don't tell you

It's worth being clear about what a simulation measures. It measures how susceptible people are to a realistic lure under controlled conditions. It doesn't count real attacks, and a second round sent to people who've just been told about the first will always benefit from some extra alertness.

Even so, the change is hard to argue with. The number of people who would have handed over a password went from 393 to 19. That's the difference between a phishing email almost certainly succeeding somewhere in the business and it very probably failing.

The work isn't finished, either. The next gap is reporting. A team that doesn't click is good; a team that doesn't click and tells IT straight away is better, because one early report can protect everyone else who received the same email.

What we'd suggest to any business

Treat the worried tickets as a signal, not just noise. "I think I clicked something" is your staff telling you about a risk, and a cluster of those tickets is worth acting on.

Measure before you train, so you know where you're starting from and can prove whether anything changed.

Build the training from your own results. The emails your people actually fell for are the most useful material you have.

Then test again. One improvement is encouraging. Several over time show that it’s lasting.

Where Crowswatch fits

Phishing works best when the email looks convincing, and one of the things that makes it convincing is the sender. Attackers often use lookalike domains, but if your own domain isn't protected by an enforced DMARC policy, they may be able to send email that appears to come from you directly.

You can check that in under a minute. Run a free Domain Health scan on your domain to see your SPF, DKIM and DMARC setup, what's missing and how to fix it. If you'd like to run a phishing simulation for your own team, get in touch.