Phishing

A phishing attack has three parts: a pretext that makes acting feel reasonable, a channel that carries it, and a mechanism that converts the victim’s action into access.

The pretext is built from context, and context is cheap. Public filings, job listings, social profiles, supplier logos on a website, an out-of-office reply, a conference attendee list. A message about an invoice from a supplier you genuinely use, sent while your finance lead is visibly away, is not a trick anyone should feel embarrassed to fall for.

The mechanism is what changed, and it is the part most awareness training has not caught up with. The old model harvested a password on a fake page and used it later, which multi-factor authentication largely closed. The current model is a reverse proxy: the attacker’s site relays the real login page in real time, so the victim sees the genuine site because it is the genuine site. They enter the password, they complete the second factor on the real service, authentication succeeds, and the attacker keeps the resulting session cookie. Nothing was cracked. The factor worked. The session was taken after it succeeded.

From there the attacker does not need to log in again. They register their own authentication method, create a mailbox rule to hide replies, and look for what the account reaches. In a corporate tenant that is usually mail, files and a directory that tells them where to go next.

There are quieter variants that avoid credentials entirely: persuading a user to approve an application’s access request, so the attacker holds a token rather than a password, and abusing device authorisation flows so the victim enters a legitimate code on a legitimate page. Both produce durable access and neither looks like a phishing page.

The organisational failure is measuring the wrong thing. Click rate is easy to collect and it tells you almost nothing, because with a good pretext the rate approaches everyone. The numbers that matter are how many people reported it, how quickly the first report arrived, and what the attacker reached with the first success. An organisation with a high click rate and a two-minute reporting time is in much better shape than one with a low click rate and no reporting channel.

The second failure is treating awareness as the control. Training reduces the easy cases and it does not make people immune to a well-researched pretext, and it should not be expected to. Blaming a user for a message crafted specifically for their role and their week is both unfair and operationally useless, because it suppresses reporting, which is the control that actually works.

The third is the gap between mail security and identity security. Mail authentication with DMARC stops people spoofing your domain and does nothing about a lookalike domain, a compromised supplier’s real mailbox, or a message that arrives by chat instead. Meanwhile the attack lands in the identity plane, where the controls that matter are session binding, device compliance and the factor type.

The fourth is what happens after the click, which is where the incident is decided. If a compromised session can register a new authentication method silently, create forwarding rules and read the whole mailbox history, one successful message is a serious breach. If sensitive actions require a fresh origin-bound check, the same message is an alert.

The word covers a family, and the varieties differ in channel and in target rather than in principle.

Two of these deserve separate attention. Business email compromise frequently involves no malicious link at all: a real supplier mailbox is compromised and a genuine invoice thread continues with different bank details. And quishing exists because a QR code moves the victim onto a personal phone, which usually has none of the corporate protections the desktop has.

Reporting click rate as the programme metric. It measures the pretext, not the organisation. Report rate and time to first report measure the organisation.

Punishing people who click. It reduces reporting, which is the only control that scales.

Assuming MFA solves it. It solves credential harvesting. It does not solve a relayed session unless the factor is origin-bound.

Testing with a weak pretext. A generic message with obvious errors produces a comfortable number and no information. A realistic simulation is uncomfortable and useful.

Focusing entirely on email. Voice calls to the helpdesk succeed at a high rate in our engagements, and they are the path most organisations have never tested.

Reduce what a successful message is worth, because you will not reduce the success rate to zero. Move to origin-bound factors so a relayed login yields nothing, apply conditional access so a session is bound to a compliant device, and require a fresh check before adding an authentication method, changing a payment detail or creating a mail forwarding rule. Those three changes convert most successful phishing into a contained event.

Make reporting the easiest action available. A one-click report button, an acknowledgement, and a visible response. The metric to improve is the time between the first delivery and the first report, because that is what determines whether the rest of the recipients can be protected.

Fix the technical hygiene that removes the cheap variants: mail authentication published and enforced, external sender marking, and monitoring of lookalike domain registrations for your brand. Then agree an out-of-band verification rule for payment changes that applies without exception, since exceptions are exactly what the pretext is designed to create.

For detection, the strongest signals are in the identity log rather than in the mail gateway: an authentication method registered shortly after a sign-in from an unusual location, a new mail forwarding rule, a token issued for a client the user has never used, or a sign-in from a hosting provider address. Adversary in the middle sessions are visible there when they are invisible everywhere else.

A phishing engagement reports what happened after the click, not only how many clicked. We record the pretext, the delivery, the proportion who interacted, the proportion who reported, the time to first report, and then the technical outcome: what session we obtained, what it reached, and which control stopped us or failed to.

The evidence is timestamped so the client can find the corresponding entries in their own logs, and credentials are never recorded. Where we obtained a session by relaying a login, we say so plainly, because the client’s team will otherwise assume their factor was misconfigured when it was working correctly.

Severity is written against reach. A user handing over credentials on an account with no privileges is one thing. A session in a mailbox that approves payments, in a tenant where a new factor can be enrolled silently, is another.

Running that exercise realistically, and measuring the response rather than the click, is what a controlled social engineering exercise is for.

Does MFA stop phishing? It stops the version that harvests passwords. It does not stop a real-time relay of the login, which captures the session after the factor succeeds. Only origin-bound factors such as WebAuthn resist that, because the signature is tied to the real site.

What is the difference between phishing and spear phishing? Volume and research. Phishing is sent broadly with a generic pretext. Spear phishing targets a named individual with details drawn from their role, their projects and their calendar, and its success rate is much higher.

Should we punish employees who click? No. It suppresses reporting, and reporting is the control that limits the damage. Measure the organisation’s response, make reporting trivial, and reserve consequences for repeated disregard of a verification procedure rather than for falling for a well-built pretext.

What is quishing? Phishing delivered as a QR code. It matters because it moves the victim onto a personal phone, outside the mail filtering, the managed browser and the device policy that protect the corporate desktop.