Service
Phishing Campaigns
Realistic simulated campaigns that measure detection and reporting, not blame.
A campaign that measures click rate produces a number and changes nothing. The useful measurements are whether anybody reported it, how quickly, and whether the technical controls behaved as expected. Those are properties of the organisation rather than of the individuals, and they are the ones that can actually be improved.
How this works
Pretexts that match current attacks
Scenarios are built from what is being used against organisations like yours now: adversary-in-the-middle pages that proxy your real identity provider, requests that arrive inside an existing thread, and payloads delivered through the tools your staff already trust. A campaign built on obvious tells measures nothing except who reads carefully.
Credential capture without holding credentials
Where a scenario involves a login page, the mechanism records that a submission happened, not what was submitted. There is no reason for an exercise to hold your staff's passwords, and doing so creates a liability the exercise was supposed to reduce.
Reporting measured as the primary metric
The number that matters is how long until the first report and how many people sent one, because that is the detection capability you actually have. Click rate is recorded and is the less interesting figure. Results are reported in aggregate; individuals are not named.
Technical controls tested alongside people
The campaign also establishes what your mail filtering, link inspection and identity controls did: what was delivered, what was rewritten, what was blocked, and whether a successful authentication from unusual infrastructure produced any alert. Frequently the more actionable finding is there rather than in the human results.
What we look for
- Time to first report, and total reporting rate
- Whether the reporting path is known, obvious and free of consequence
- What mail filtering delivered, quarantined or rewrote
- Whether authentication from unfamiliar infrastructure raised anything
- Whether a session established during the exercise would have been detected afterwards
- Which groups are most exposed, so training can be aimed rather than broadcast
What you get
- Aggregate results with time to first report as the headline number
- What the technical controls did at each stage of delivery
- Recommendations split between control changes and training, with the control changes first
- Material for a follow-up briefing that does not name anyone
What this does not include
- Naming individuals, to you or to anyone else
- Capturing or storing real credentials
- Pretexts involving bereavement, medical emergencies, redundancy or anything else that causes genuine distress
- Campaigns designed to maximise click rate for a slide, which is easy and worthless
Questions people ask
- Should we tell staff in advance?
- Announcing the specific campaign defeats it. Announcing that simulations happen as part of the security programme does not, and it is both fairer and better for the reporting culture you are trying to build. That framing is recommended.
- What if someone falls for it badly?
- They receive the same brief teaching moment as everyone who clicked, without their name leaving the exercise. An organisation that punishes clicking gets fewer reports rather than fewer clicks, which is a strictly worse position.
- Does MFA make this pointless?
- The opposite. Ordinary MFA does not stop an adversary-in-the-middle page, which lets the real authentication succeed and steals the resulting session cookie. A campaign of that shape tells you whether your MFA is actually phishing-resistant or merely present.