Spear phishing
In offensive security, spear phishing is a targeted phishing attack aimed at a specific person or small group, built from research about them rather than sent in bulk. It is what a realistic simulation actually rehearses, because it is the technique that gets past the awareness training designed for generic mass email.
How it works
Spear phishing starts with reconnaissance rather than a template. The attacker gathers who the target reports to, which suppliers they use, what projects are live and how the organisation writes internally, then crafts a message that fits that context: an invoice from a real vendor, a reply that appears to continue an existing thread, a request from a named executive. The payload varies (a credential-harvesting page, a malicious attachment, or a link into an adversary-in-the-middle proxy that captures the session and its multi-factor token), but the delivery is the same idea: plausibility built from real detail, sent to a person chosen on purpose. The channel is not always email: the same targeting reaches a target through a text message, a voice call or a QR code, but the principle does not change.
What goes wrong
Generic phishing training teaches people to spot the obvious tells: bad grammar, a stranger’s name, an implausible prize. Spear phishing has none of those, because the detail is correct. In our simulations the message that works is the one that matches something the target was already expecting, sent at a moment when they are busy. The defensive assumption that “our staff are trained” collapses against a well-researched, single-recipient email that references a genuine project. This is also the on-ramp to business email compromise: the same targeting, applied to someone who can move money.
Where this shows up in an audit
A phishing engagement report separates the click from the compromise. We record the pretext used, who interacted, whether credentials were entered, and whether the session (including any second factor) could be captured and reused, because a click is not the finding, a working session is. We avoid publishing individual names and frame results as process gaps, not personal failures. This is how we run a targeted simulation that reflects real social engineering rather than a generic test.