Recognizing Phishing: A Walkthrough From a Real Message

Most security controls — firewalls, SAST, DAST, access policies — defend against attacks on systems. Phishing skips the system entirely and attacks the person operating it, which is exactly why it remains one of the most common ways attackers get an initial foothold, regardless of how hardened the infrastructure behind that person is.

The Message

A friend of mine shared a text he received, in a cybersecurity WhatsApp group we're both in. It read, roughly: "We noticed an issue with your account transactions. Kindly verify your identity within 24 hours to avoid full restriction on your account."

Classic phishing — but worth walking through properly, because the mechanics are more interesting than "don't click suspicious links."

Why It Works

Phishing leans on three levers, almost always in combination:

• Urgency — a deadline removes the time needed to think clearly

• Authority — impersonating an institution borrows trust the attacker hasn't earned

• A plausible link — just convincing enough to survive a glance

The link is where the real craft shows up. The two common tricks:

• Typosquatting — swapping or transposing letters in a real domain (bankA.com → bamkA.com), relying on the reader not reading closely

• IDN homograph attacks — using a Unicode character that looks identical to a Latin letter (a Cyrillic "а" instead of a Latin "a", for example) but is a completely different character to a browser. Hover over a link like this and the real address — often rendered in Punycode as xn--... — gives it away, but only if you actually look at the status bar instead of the link text.

How I'd Walk Through It

1. Start from a baseline expectation. My bank will never text me a link demanding urgent action. The moment one does, that's already a signal, before I've read a single other detail.

2. Inspect the link before anything else. Hover (don't click) and read the actual destination, not the display text. On mobile, long-press to preview instead of tapping. If it doesn't match the bank's real domain exactly, stop there.

3. Read it as if the sender wrote it. Would a real bank threaten to lock an account over an unsolicited text? If it's engineered to make you panic, or sounds too convenient, that alone is reason enough to stop.

4. Verify independently, never through the message. Call your account officer or visit a branch, using contact details you already had — never a number or link supplied in the message itself.

5. For email specifically, check the headers. The display name is trivial to spoof; the actual From address, Reply-To, and Return-Path often aren't. SPF, DKIM, and DMARC results (visible in the raw headers of most mail clients) will usually flag a forged sender outright.

6. Never download attachments on trust alone. A "harmless" image or PDF can carry embedded scripts or macros that execute on open — a common backdoor that doesn't require you to click anything beyond opening the file.

Beyond Email

The same patterns show up as smishing (text), vishing (phone calls), and fake opportunities on platforms like LinkedIn — I've seen developers lose accounts chasing job offers that, in hindsight, were obviously too good to be true. Tailgating (following someone through a physical access point) is a related but distinct social-engineering vector — different channel, same underlying exploit of trust and urgency.

Even without a direct account compromise, information handed over in a successful phishing attempt tends to resurface later — identity theft, credentials or personal data sold on the dark web.

One More Layer: MFA

None of the above replaces multi-factor authentication. It won't stop a phishing attempt from reaching you, but it stops a stolen password from being enough on its own — which is why it's worth enabling everywhere it's offered, independent of how careful you are about spotting the message in the first place.

The Pattern

Almost every phishing attempt reduces to the same shape: urgency, a link, and a reason to skip verifying. Slow down enough to check the actual link destination and confirm through a channel you already trust, and most of these fall apart on their own.

Stephen Ngwu is a full-stack engineer with a focus on application security.