# How a phishing attack is actually built

Most phishing advice is useless because it describes the symptoms. Here is the construction, from the attacker's side — and the two defences that actually survive it.

- Published: 2026-07-30
- 8 min read
- Mustafa Yousry — Entrepreneur · CTO · Cyber Security
- https://mustafayousry.com/en/articles/how-phishing-actually-works

---

## Start with the list

Nobody phishes strangers at random. The first artifact of any real campaign is a list, and the list is built from things you published on purpose.

The raw material is public. LinkedIn gives roles, reporting lines, and who just started — a new hire has no instinct yet for what a normal internal email looks like. The company website names people. Job adverts leak the stack: "experience with Okta and Microsoft 365" tells the attacker exactly which login page to clone. Conference talks, GitHub commits, press releases, the org chart implied by a support-ticket signature.

Addresses rarely need harvesting one by one, because corporate email follows a pattern. Find one address and you have the formula.

```
firstname.lastname@company.com
```

Now every name on LinkedIn is an address. Tools like `theHarvester` automate the collection; breach dumps and "combolists" fill in the rest, and cross-referencing a leaked personal password against a work address tells the attacker who reuses credentials before a single email is sent.

> The reconnaissance is finished before you get any warning that it happened. There is nothing to detect, because nothing was attacked — it was read.

## The pretext is the whole thing

Amateurs obsess over the fake page. Professionals obsess over the reason you would ever visit it.

The pretext is the story the email tells: why it exists, why now, why you specifically. It is the entire attack. A flawless clone of your payroll portal is worthless if there is no believable reason to log in today. A plain-text email with a good reason works even when the technology is crude.

Good pretexts borrow authority and add time pressure without inventing anything you can check. A shared document from a colleague you actually work with. An invoice on a project that actually exists. A benefits-enrolment deadline in the week HR actually runs enrolment. The attacker read your reconnaissance; the message fits the shape of your week. That fit is what disables suspicion — not a logo.

This is why "spot the phishing email" training generalises so badly. It teaches people to distrust clumsy, generic messages. The message built for you is neither.

## Picking a domain that passes

The sender needs a domain. There are three ways to get one that survives a glance, and none of them require compromising anything.

**Lookalike domains.** Register something adjacent. `company-support.com`, `company.co` instead of `.com`, `rn` in place of `m`. You own it outright, which — as we will see — matters more than it should.

**Homoglyphs.** Some characters are visually identical across alphabets. A Cyrillic "а" renders the same as a Latin "a", and internationalised domains let you register them.

Browsers fought back on this, and it is worth knowing exactly how far. Since around 2017, Chrome, Firefox and Safari display a domain label as raw punycode whenever it *mixes* scripts. So one Cyrillic letter dropped into an otherwise Latin word does not get you a convincing address — it gets you this:

```text
Typed:      https://cоmpany.com      (the "o" is Cyrillic, U+043E)
Displayed:  https://xn--cmpany-wqf.com
```

What survives is a **whole-script** confusable: every letter from a single non-Latin alphabet, so there is no mix to detect. The 2017 proof of concept spelled "apple" entirely in Cyrillic, and browsers rendered it as the real thing:

```text
Registered: xn--80ak6aa92e.com
Displayed:  https://аррӏе.com       (Cyrillic а р р ӏ е — no Latin letters at all)
```

That one is genuinely hard to see. It is also much harder to build, because the target word has to be spellable in another alphabet.

**Subdomain framing.** People read a domain left to right and stop at the first familiar word. Put the brand on the left and your own domain on the right.

```text
https://company.com.account-verify.net/login
```

The registrable domain there is `account-verify.net`. `company.com` is just a subdomain the attacker created. It reads as the real thing to anyone who does not parse right to left.

**Legitimate-service abuse** is the strongest option, because it removes the domain problem entirely. Send the lure as a genuine Google Docs share notification, a real DocuSign envelope, a SendGrid or Mailchimp campaign, or from a mailbox the attacker already compromised. The email comes from an infrastructure the whole internet trusts. Every authentication check passes, because the mail is, technically, real.

## What SPF, DKIM and DMARC actually do

These three are the email world's answer to spoofing, and they are widely misunderstood as a spam filter for lies. They are not. They authenticate a domain. They say nothing about whether the domain is one you should trust.

| Mechanism | What it checks |
|---|---|
| SPF | Was this sent from an IP the domain authorised? Checks the hidden Return-Path domain. |
| DKIM | Is there a valid cryptographic signature proving the message was not altered in transit? |
| DMARC | Do the authenticated domains match the visible `From:` address, and what should the receiver do if not? |

Here is the part that matters. When an attacker sends from a domain they registered, they set up SPF, DKIM and DMARC for that domain correctly. It is their domain. Everything passes.

```text
From: security@company-support.com
spf=pass  dkim=pass  dmarc=pass
```

Three green checks, on a domain that has nothing to do with the real company.

DMARC set to `p=reject` stops one specific thing: someone sending mail that uses *your exact domain* in the `From:` line. That is worth doing — it closes exact-domain spoofing. It does nothing about a lookalike domain, a homoglyph, a subdomain trick, or an abused legitimate service. Those are not spoofing your domain. They are using a different domain that resembles it, and authentication was never designed to have an opinion about resemblance.

> SPF, DKIM and DMARC prove a message came from where it says. They cannot tell you whether where it says is anywhere you should trust.

## The login page is a proxy now

The old kit was a saved copy of a login page. You typed your password into dead HTML, it was written to a file, and the attacker used it later. Two-factor authentication killed this outright: the password alone was no longer enough, and the attacker was not present when the code was needed.

So the kit changed. The modern login page is not a copy. It is a **reverse proxy** sitting between you and the real site — the technique is called adversary-in-the-middle, and the open tooling for it (Evilginx and similar) is mature and public.

The mechanics are simple and worth holding in your head:

1. You land on the phishing domain. The proxy fetches the *real* login page and shows it to you. It is real, because it is being served through from the genuine site in real time.
2. You type your password. The proxy passes it to the real site and passes the site's response back to you.
3. The real site asks for your 2FA code. You enter it. The proxy relays it. The code is correct, because you are really authenticating against the real service.
4. The real site, satisfied, issues a **session cookie**. The proxy keeps a copy.

That cookie is a logged-in session. The attacker loads it into their own browser and is inside your account, past the password and past the second factor, without knowing or needing either going forward.

This is why SMS codes and authenticator apps do not save you here. They prove a human completed a challenge; they do not bind that proof to the page the human was actually on. The one-time code is consumed in real time and the durable session token is what gets stolen.

## What actually survives

Two things defeat this, and they defeat it for the same reason.

**Passkeys and hardware security keys** — the FIDO2/WebAuthn family. When you register one, your device stores a private key. For a hardware key or a device-bound passkey it never leaves that device; for a synced passkey it moves between your devices end-to-end encrypted, through your platform account and never in the clear. When you sign in, the browser signs a challenge **and includes the exact origin** — the real domain — in what it signs. The key will only produce a valid signature for the domain it was registered to.

Put that against the proxy. The victim is on `company.com.account-verify.net`. The browser dutifully signs for *that* origin. The signature is worthless at `company.com`, because it attests to the wrong domain. There is no shared secret to relay, no code to type, nothing the proxy can pass through. The one thing the attacker needs — a valid assertion for the real site — is the one thing the cryptography refuses to produce on the wrong domain.

That property is called origin binding, and it is why this is the only category of defence that holds. The user cannot be tricked into overriding it, because the check is not performed by the user.

Now the advice that does not survive, and why:

- **"Look for the padlock."** The padlock means the connection is encrypted, nothing more. Phishing sites get free, valid certificates in minutes. The padlock is present on the fake page and always was.
- **"Check for spelling mistakes."** A serious kit has none. Homoglyph domains are spelled correctly by definition.
- **"Make sure it's the right link."** The subdomain trick and the homoglyph are built precisely to pass that inspection.
- **"Just be careful."** This is the one to retire. The attack is engineered to pass every check a careful person is told to make. When the failure signal is the same signal as success, attention buys you nothing.

## Closing

None of this is exotic. It is registration, a rented proxy, a plausible sentence, and patience — and it is built specifically to beat the checklist most people were handed. That is the honest reason the checklist fails: it asks a human to out-inspect a thing designed to be inspected.

The defence that works is the one that removes the human from the point of failure. Turn on passkeys where you can, carry a hardware key for the accounts that matter, and treat any login you reached by clicking as a login you have not really done yet. The rest is worth knowing mostly so you stop blaming the people who fall for it.

---

Source: https://mustafayousry.com/en/articles/how-phishing-actually-works · Site: https://mustafayousry.com