A friend forwarded me a phishing email this week. It claimed to be from her UK bank, said her account had "unusual activity" requiring verification, and provided a link to a login page. The construction was more sophisticated than I had expected.
I have been writing about this category in passing — the messaging-protocol surface, HTTP authentication mistakes — but have not given it a focused post. The forwarded email was useful enough as a case study to write up.
What the email looked like
The sender was customer-service@[bank-name-with-typo].com — a typo-domain registered for the campaign. The visible name in the From field was the legitimate bank's name; the address was hidden behind it in most mail clients.
The body was well-written:
- The bank's logo (loaded from a hot-linked image on their actual site, so it was authentic).
- The bank's standard footer (copy-pasted from the legitimate site).
- A reasonable explanation of why verification was needed.
- A specific deadline (which produces urgency without being suspiciously short).
- A "verify your account" button linking to the typo-domain.
The clicked-through page was a near-pixel-perfect copy of the legitimate login page. The HTML was scraped from the real site; the CSS was loaded from the real site (cleverly, to make the page render correctly even if the attacker did not host all the assets); the form action posted credentials to the typo-domain.
What is different from the early phishing
Four things I had not seen in earlier examples.
The typo-domain is plausible. Earlier phishing campaigns used domains that were obviously wrong; this one uses a single-character variant that someone scanning casually would miss. The look-alike-domain technique has become standard.
The visual fidelity is excellent. Earlier phishing pages had visible flaws — wrong fonts, broken images, inconsistent layout. This one is essentially indistinguishable from the real page on first inspection.
The hot-linked images are clever. Loading the bank's logo from the real site means the email shows correctly even after the attacker's hosting goes down. The forensic attribution is harder; the email looks legitimate longer.
The credential-collection is operationalised. The captured credentials presumably feed into either an automated login system or a marketplace where the credentials are sold. The economic infrastructure behind phishing is forming.
What this teaches
A few things.
Social-engineering attacks are not a niche. They are a major category of attack now and growing. The attacker skill required is modest; the technical defences are limited; the success rate (per email sent) is small but the volumes are large.
The defensive responsibility is split. Banks need to make legitimate communications more reliably distinguishable from phishing. Mail providers need to filter inbound phishing. Browsers need to warn about login pages on look-alike domains. Users need to be educated about the threat. Each of these has gaps.
The technical defence stack is uneven. Spam filters catch some phishing; the visible filters do not catch this kind. Browser warnings against look-alike domains are early stages. The user education is the weakest layer.
What I have advised my friend
Delete the email. Do not click the link. Verify her account through the bank's actual website (typed manually, not via email link). If she had clicked, change her password from a different device.
The broader advice — "do not trust unsolicited emails asking for credentials" — sounds obvious but is not always followed. Some education is necessary; some structural defence is needed.
What I expect over the next year
Three predictions:
Phishing volume continues growing. The economic infrastructure favours the attacker. Probability: 90%. Deadline: 31 December 2001.
Specific bank-targeted phishing campaigns become front-page news. A high-profile case where significant losses are attributed to phishing. Probability: 70%. Deadline: 31 December 2001.
At least one major mail provider rolls out anti-phishing filtering specifically. Beyond generic spam filtering. Probability: 65%. Deadline: 31 December 2001.
More as the year develops.