Phishing and smishing

What phishing and smishing are

Phishing is deception aimed at getting a person to hand over their credentials or authorize an operation while believing they are interacting with a legitimate organization. Smishing is the same technique over SMS or messaging, and vishing is the same technique over a voice call.

The channel is the only thing that changes. The mechanism is identical: a message builds a credible, urgent situation, the person acts, and what they hand over is data that serves to gain access or to approve.

The operational distinction that matters is this: the attacker doesn't breach a system. They use an authorized user as an intermediary. That's why the perimeter controls of the attacked organization don't see it, and why the result looks so much like a legitimate session.

What the attack is after is a factor, not a password

Treating phishing as password theft is out of date. In a two-factor login, the password alone is useless, and the attacker knows it. What they set up is a real-time capture of every factor the system asks for, in the order it asks for them.

The real-time intermediary is the technique that makes it possible. The fake page doesn't store what the user types: it forwards it to the real site at that moment and returns to the user what the real site responds. If the real site asks for a code, the fake page asks for it. The user sees a flow that works, because it is working: on the other side, a genuine authentication is taking place.

What the attacker ends up with isn't a password. It's an open, valid session. Changing the password afterward doesn't close it.

How the attack runs, step by step

The sequence is the same over email, SMS and voice. Only step 2 changes.

1. Choose the pretext and the moment. A due date, an account lock, a pending delivery, an unrecognized transfer. The pretext doesn't need to be sophisticated; it needs to be plausible at that instant.
2. Deliver the message. An email from a look-alike domain, an SMS inside a thread that already holds legitimate messages from the brand, or a call from a number that displays the entity's caller ID.
3. Lead to a surface the attacker controls. A page that replicates the real login, or the phone conversation itself.
4. Capture the first factor. The user types username and password. The attacker forwards them to the real site at the same moment.
5. Capture the second factor. The real site sends the code or the approval notification. The attacker asks the user to read it out or to approve, and uses it within its validity window.
6. Keep the session. With authentication completed, the attacker operates. The effective window isn't the minute the code lasts: it's however long the session lasts.
7. Secure the access. Change of contact details and registered factors, so the owner loses their recovery path. At that point the incident becomes an account takeover.

Step 5 is the one that decides. Everything else is logistics.

Which factor falls and which one resists

This is the part that almost no general material on phishing answers, and it's the one a team needs in order to decide.

The property that separates the factors isn't their cryptographic strength. It's whether the factor can be transferred by the person to a third party. Anything a person can read, dictate, copy or approve, they can hand over under deception.

• Password — a shared secret. It's transferable by definition and falls on the first attempt.
• SMS OTP — the factor that falls most often. It's a readable code the user can dictate, it arrives through a channel the organization doesn't control, and it's also exposed to someone taking over the line, which is the mechanism of SIM swapping.
• In-app OTP (TOTP) — solves the channel problem, not the deception problem. It's still a code the person reads and can dictate.
• Approval notification (push) — moves the decision to the user at a moment when they've already been convinced. Sending requests repeatedly until someone approves out of fatigue is a known pattern in this family.
• Passkey and FIDO2 authentication — resists, and the reason is mechanical, not a matter of degree. The credential is a key pair whose private part never leaves the device, and the signature it produces is bound to the domain that registered it. A phishing page lives on another domain: it can't request a valid signature for the real site, even if the user wants to give it. There's nothing the victim can dictate.
• On-device biometrics — on its own, decides nothing. What it contributes is unlocking the local private key. The resistance comes from the binding to the domain, not from the face or the fingerprint.

The practical conclusion is uncomfortable and worth stating: adding a second factor doesn't make the login phishing-resistant. It only makes it resistant if that factor can't be handed over.

Who it affects and what it costs

The direct cost usually falls on the person. The operational and regulatory cost falls on the organization.

• Financial services — transfers authorized by the account holder themselves under deception, which are the hardest to reverse and the ones that fit worst into liability schemes.
• Retail and e-commerce — takeover of accounts with stored payment methods, and draining of loyalty programs, which is usually detected late because nobody checks the balance.
• Betting and gaming — accounts with a balance and with identity verification already done, which is what makes them valuable for resale.
• Government — access to procedures and benefits in another person's name.
• Corporate — an employee's access as the entry point to internal systems.

In every case the organization faces the same underlying problem: the fraudulent operation arrived with a correct authentication, and telling it apart from a legitimate one requires signals that authentication alone doesn't provide.

What controls stop it

No single control solves phishing, and a good part of the ones that yield the most are outside the reach of an identity provider. Naming them in full is the only way the list is useful for deciding.

• Origin-bound authentication (FIDO2, passkeys) — the control with the greatest effect on the mechanism. It removes step 5 instead of trying to detect it.
• Sender email authentication (SPF, DKIM and DMARC in reject mode) — reduces spoofing of the organization's own domain. It's email-infrastructure work, not the identity provider's.
• Filtering at the email gateway and browser protection — reputation lists, link analysis and warnings at the point of click. Provided by email-security vendors and by the browsers themselves.
• Registering SMS senders with the carriers — limits a third party sending messages with the brand's sender ID. It depends on the carrier and the telecom regulator in each country, not on a vendor.
• Detecting and taking down look-alike domains — monitoring registrations and requesting takedowns. A service from specialized third parties.
• Out-of-band confirmation with the operation's details — what the user approves shows destination and amount, not just "approve access". It turns a blind approval into an informed decision.
• Session and device risk signals — device reputation, inconsistent geolocation, interaction speed, signs of intermediation in the flow. It's what's left once authentication has already been passed.
• Step-up on the sensitive operation, not only at login — asking for presence again at the moment of the transfer, not only when entering.
• User training — limited and diminishing effect. It raises the floor; it doesn't sustain the defense. A good enough pretext works on trained people.

A team that builds its phishing defense only with what its identity provider sells is covering one stretch of the problem. Half of this list is bought elsewhere, and the email and telecom part isn't solved by any authentication vendor.

How VU approaches it

VU works on step 5 and on what happens afterward.

In authentication, Authenticate supports seven factors: face, TOTP, SMS OTP, email OTP, magic link, password and identity document. The fact that the catalog includes factors that fall to phishing is information, not a disclaimer: the choice of factor belongs to the organization, and this page exists so that choice is made knowing which one can be dictated and which one can't.

In detection, Protect against fraud evaluates risk signals on the session and the operation, which is the control still standing when authentication was legitimately passed by a third party.

And in recovery, biometric identity re-verification closes the path the attacker uses in step 7: if regaining access requires proving again who the person is, changing the contact details is no longer enough.