Phishing and smishing: the patterns that repeat

Why the same message keeps working

Fraudulent messages are cheap to send and cheap to iterate. An operator can send hundreds of thousands, measure which subject line produces clicks, discard the rest and run the winner again. What survives that process is not clever. It is _statistically optimised_ — tuned to the small number of situations where almost anyone, on almost any day, would plausibly be expecting a message.

That is why the winning stories are so mundane. A delivery fee. A traffic fine. A salary or refund notification. A subscription renewal you did not authorise. A one-time code you did not request. None of them are dramatic, and that is the point. Drama gets deleted. Mild administrative plausibility gets a tap.

You cannot win by memorising the current crop of stories, because the stories are a rotating surface. You can win by learning the parts that cannot change, because they are load-bearing.

The skeleton every phishing message shares

Strip away the wording and nearly all of them have the same five bones.

1. **A borrowed identity.** A brand, an institution, a government department, a colleague, a platform you use. Borrowed because it costs nothing to type a name.
2. **A pretext that is boring and plausible.** Something administrative that could reasonably be true this week.
3. **A single action with a deadline.** Confirm, verify, pay, update, release, claim. Almost always one action, because a second action halves the conversion rate.
4. **A channel that leaves their control at exactly one point.** A link, a phone number, a QR code, an attachment, a reply. This is the hinge — everything before it is theatre, and everything the message is for happens after it.
5. **A harvest.** Credentials, a card number, a one-time code, a payment, or software installed on your device.

Because bone four is structural, your entire defence can be concentrated there. You do not have to evaluate the story at all. You only have to evaluate the destination — and destinations are far easier to read than narratives, because they follow rules.

Reading a link the way a machine reads it

This is the single most transferable skill in this article. Most people scan a link left to right, see a familiar brand name early, and stop. Software does not read it that way, and neither should you.

The right-to-left rule

In a web address, the part that determines who actually controls the site sits at the **end** of the host portion, immediately before the first single slash. Read from that slash backwards.

Take an invented example. A host reading **secure-login.yourbank.verify-account.example-cdn.top** puts a familiar-looking bank name early, and your eye relaxes there. Read backwards from the first slash and the controlling domain is **example-cdn.top** — the bank name is merely a subdomain label, and anyone who owns a domain can create any subdomain they like, for free, in seconds. Subdomains are labels the owner invents. They prove nothing.

Practise on three shapes, all invented:

• **yourbank.com/login** — the domain is yourbank.com. Whatever follows the slash is a path and does not change who owns the site.
• **yourbank.com.security-check.xyz/login** — the domain is security-check.xyz. The ".com" here is not a top-level domain at all; it is a label sitting inside somebody else's name.
• **yourbank-verify.com/login** — the domain is yourbank-verify.com, which is a **different** registered domain from yourbank.com. A hyphen creates a new name, not a department of an existing one.

Lookalikes and homoglyphs

Some characters are visually close in common fonts. A lowercase L and the digit one, the letter pair r-n resembling a single m at small sizes, a capital O and a zero, and characters from other scripts that render nearly identically to Latin letters. A domain can be registered that looks correct at phone-screen size and is not. You will not reliably catch these by eye, which is why the durable habit is not "inspect carefully" but "do not use links from messages for anything that matters".

Shorteners, redirects and QR codes

A shortened link hides the destination by design. A QR code hides it even more thoroughly, because there is nothing to read at all until you have already opened it — and codes printed on stickers can be placed over legitimate ones on parking meters, restaurant tables and payment terminals. Treat a shortener or a QR code in a financial context as an unreadable destination. Unreadable is not neutral; for money purposes it is a refusal.

The rule that survives every variant is simple. Never authenticate or pay through a link you were sent. Reach the destination the way you already knew how to reach it — a saved bookmark, the app on your phone, the number on your card.

Why SMS is structurally weaker than email

Smishing — fraud delivered by SMS or messaging apps — deserves separate treatment because the medium itself offers you less to work with.

Email carries headers and has widely deployed authentication mechanisms that let receiving systems check whether a message plausibly came from the domain it claims. Those checks are imperfect and invisible to most users, but they exist. SMS has far less. The alphabetic sender identifier at the top of a message is essentially a label, and labels can be manipulated, which is why national telecommunications authorities publish awareness material about impersonation and provide routes to report fraudulent messages rather than advising people to trust the displayed senderSource^source.

Two consequences follow, and they are the reason smishing converts so well.

• **A fraudulent message can land inside the same thread as genuine ones.** Because phones group messages by sender label, a spoofed message may appear directly beneath real alerts from your bank, inheriting their credibility. Thread position is not evidence.
• **There is nothing to inspect.** No sender address, no headers, no hover preview. The only inspectable object is the link, which is usually shortened.

The practical result is that on a phone, the triage has to be shorter and stricter than on a desktop.

The mechanism that does the real damage — live code relay

Understanding this one mechanism explains a large share of account takeovers.

A fake login page is not a passive collection box. Many are operated as live relays. The moment you type your username and password into it, an operator or an automated system enters them into the _real_ site immediately. The real site then does exactly what it is supposed to do and sends you a genuine one-time code. The fake page, timed perfectly, asks you for the code. You supply it. The operator enters it on the real site within its validity window and is now inside your account.

Three things follow from this.

• **The code arriving from the real number does not mean the page is real.** The code is genuine. The page is not. The code was triggered by the attacker.
• **A code should never be typed into a page you reached from a message, or read to any person.** Codes exist to approve a specific action. Handing one over hands over the approval, which is why digital identity guidance ranks codes delivered by message below authenticators cryptographically bound to the legitimate site — the latter simply will not release anything to a lookalike domain, because the domain does not matchSource^source.
• **Speed matters after the fact.** If a code has been entered on a suspicious page, the account is likely already being accessed, and the response is measured in minutes.

Worked example — the parcel fee

Suppose a message arrives saying a shipment is held pending an unpaid customs charge of 12.50, with a link. You are, as it happens, expecting a delivery.

Look at what the design is doing. The amount is deliberately trivial, because a small sum triggers far less scrutiny than a large one, and the target is not the 12.50 at all — it is the card details entered on the payment page, which have a resale value regardless of what was "paid". The story is timed to a period when most people have something in transit. The urgency is mild and administrative rather than frightening, so your guard stays down.

The correct response takes ten seconds and does not involve evaluating whether you really have a parcel. Open the courier's own app or type its address yourself, and look up the tracking number you were originally given by the sender. If nothing is held, nothing is held. If something genuinely is, you can pay through the route you reached independently.

Worked example — the payroll or supplier redirect

A message or email, apparently from a colleague or a supplier, asks that a salary or invoice payment be sent to a new account from this month. It is polite, correctly branded, and sometimes appears inside an existing reply chain because the real mailbox was compromised.

This variant carries no urgency and no fear, which defeats every instinct tuned to detect panic. It is beaten by policy alone: **any change of payment details is verified by an outbound call to a number that was already on file before the message arrived, and approved by a second person.** The same principle applies at home when a relative messages from a "new number" asking for money — call the old number, or ask a question only they could answer, and never in the same channel the request arrived in.

A fifteen-second triage you can run on a phone

Run these in order and stop at the first failure. It is deliberately short, because a long checklist is one nobody uses.

1. **Was I expecting this, from this specific organisation, right now?** Not "is it plausible" — plausible is what the message was optimised for.
2. **What is the actual domain, read right to left from the first single slash?** If it is shortened, a QR code, or unreadable on your screen, treat that as a fail.
3. **What is the one action being requested, and is it reversible?** Codes, credentials, card numbers, payments and installations are all irreversible.
4. **Is there any pressure — a deadline, a suspension, a fine, a limited window?** Pressure plus an irreversible ask is sufficient reason to stop, with no further analysis.
5. **Can I reach the same outcome through a route I already trust?** If yes — and it almost always is — do that instead and simply ignore the message.

Notice that step five means you rarely have to decide whether a message is fake. You route around it. Being wrong about a genuine message costs you thirty seconds; being wrong about a fraudulent one can cost an account.

Two settings worth more than any amount of vigilance

• **Use phishing-resistant authentication where it is offered.** Passkeys and hardware security keys will not authenticate to a lookalike domain, because the check is performed by your device against the real domain rather than by you against a rendering of it. This removes human judgement from the loop entirely, which is the point.
• **Turn on transaction alerts and keep them on a separate channel.** Immediate notification is often the difference between a reversible situation and an unrecoverable one, and banks and the central bank publish guidance on how institutions legitimately contact customers so you have a baseline to compare againstSource^source.

The first hour after you clicked

Assume for a moment it already happened. Order matters more than completeness here.

1. **Change the password for that account, from a different device you trust**, and change it anywhere you reused it. Reuse is what turns one compromise into five.
2. **Revoke active sessions and check for added devices, forwarding rules, recovery email or phone changes, and new payees.** Attackers frequently add a mail forwarding rule so they keep seeing your reset codes after you lock them out.
3. **Call your bank on the number on your card if any payment detail was entered.** Do this even if no transaction has appeared yet. Card details are often used days later.
4. **Report the message** through the reporting routes published by your telecom regulator or provider, and to your employer's security team if a work account or a supplier payment is involvedSource^source.
5. **Write down what happened while it is fresh** — the time, the number or address, the amount, screenshots. This is the material a bank or the police will ask for, and memory degrades fast under embarrassment.

Do not spend the first hour trying to establish exactly how you were fooled. Containment first, analysis later.

What this article does not cover

This is about messages that ask _you_ to act. It does not address compromises that never involve you — a breach at an organisation holding your data, malware arriving through software, or attacks on the infrastructure between you and a service. It also does not address deepfaked voice or video calls, which follow the same influence structure but require the same second-channel discipline rather than better eyes and ears.

Nothing here is advice about a particular bank, provider or product, and none of it replaces reporting to your bank, your employer or the police when money or credentials have actually moved. If you are unsure whether a message from your bank was genuine, the resolution is always the same and always safe — close it and contact the institution through a route you already had.