What Phishing Actually Is in 2026
Phishing is a message that impersonates someone you already trust, so that you hand over a credential, approve a login, pay an invoice or open a file. The message is not the attack. The message is the introduction. The attack is whatever happens after you believe it.
The word covers a family of techniques that fail against different defences, and that is why a single habit - "look for bad spelling" - stopped working years ago. A modern phishing page is a pixel-accurate copy of the real one, served over a valid certificate, on a domain that looks plausible enough to survive a two-second glance. It may arrive inside a thread you were already part of, from a colleague's real mailbox, with the correct signature block and the correct project name.
What has not changed is the thing attackers need from you. Every variant wants one of four things: a secret (a password, a code, a recovery phrase), an approval (a push prompt, an OAuth consent screen), a payment (a transfer, a card number, a change of bank details), or access (an attachment or a link that installs something). If you can name which of the four a message is asking for, you already know how to respond, and you know it without having to judge whether the message "feels" fake.
It also helps to know who is on the other end, because the advice differs. A criminal crew renting phishing kits by subscription wants volume and cares about your bank and your mailbox. A targeted intrusion aimed at one organisation wants a foothold on a work laptop and will invest weeks in a believable pretext. A romance or investment scam wants a relationship and works in months, not minutes. The technical signals overlap; the correct response - report, ignore, or verify slowly - does not.
The Tells That Still Hold Up
Most of what circulates as phishing advice is folklore. These five checks survive contact with real attacks, because each one targets something the attacker cannot easily fake.
1. Read the address from the right-hand end
A web address is read by a machine from the right. The part that determines who owns the site is the registrable domain: the last label before the first single slash.
accounts.google.combelongs togoogle.com. The leftmost label is just a subdomain.google.com.secure-login.examplebelongs toexample. The brand has been pushed to the left, where the eye lands first.login-g00gle.combelongs tologin-g00gle.com, and the zeroes are doing the work.
The same rule applies to email: only what follows the final @ means anything. billing@yourbank.com.secure-pay.example is not your bank, and no amount of correct branding inside the message changes that. Where a domain contains characters you cannot read, browsers display it in encoded form beginning xn--. Seeing that on a page claiming to be a well-known brand is a stop signal.
2. Was this expected?
Unexpected is the strongest single predictor. You know which deliveries you are waiting for and which invoices your company issues. Attackers choose pretexts that are plausible in general and unverifiable in the moment - a document shared with you, a parcel held at customs, a subscription you do not remember, a colleague who needs a favour before a meeting.
Expectation is checkable in a way that "does this look real" is not: open the app or the site yourself and look for the thing the message claims is waiting. Genuine notices are duplicated inside the account. If nothing is there, the message was not genuine.
3. Is it trying to produce urgency, secrecy or exception?
Urgency collapses the time you would spend checking. Secrecy removes the second opinion that would catch it - "do not tell the team yet". Exception asks you to skip a control that exists precisely to prevent this: pay outside the system, approve before the paperwork, send the codes so the fix can be finished. In a work context, a request that routes around normal process is the single most reliable indicator of fraud, regardless of how senior the sender appears.
Real organisations do set deadlines and do sometimes need speed. The difference is that a real one tolerates you calling back on a number you looked up yourself, and a fake one punishes the idea.
4. Is it asking for a secret or an approval?
No legitimate organisation asks for your password, a one-time code, a recovery code or remote access to your machine. Support staff do not need your password; they have their own tools. A bank will never need the code it just sent you - that code exists to prove the person typing is holding your phone.
Approval is the quieter version. A login prompt you did not start, a consent screen asking an app to "read your mail", a browser extension asking to "read and change all your data on all websites" - each is a request for standing access, and each is granted with one tap that feels like nothing.
5. Does the message disagree with itself?
The display name says your bank; the address does not. The link text says yourbank.com; the status bar preview says something else. The document is a PDF that asks you to enable editing, or an HTML file that opens a login form from your own Downloads folder. The domain was registered three weeks ago - check any domain's creation date with a public WHOIS lookup before you trust a "since 1998" claim.
One honest limit: legitimate marketing systems, link shorteners and click trackers hide the real destination behind their own domain too. A link that looks clean is therefore inconclusive rather than reassuring. The check tells you when something is wrong, not when it is right.
Advice That Has Stopped Being True
| Common advice | Why it fails | What to do instead |
|---|---|---|
| "Look for spelling mistakes and bad grammar." | Large-scale campaigns are professionally written, often by native speakers, and increasingly drafted with language models. Meanwhile plenty of genuine internal mail is terse and badly punctuated. | Check the domain and the request, not the prose. |
| "Make sure the site has a padlock." | A padlock means the connection is encrypted. It says nothing about who operates the site. Certificates are free and issued in minutes to any domain. | Read the domain name next to the padlock. |
| "It came from a colleague's real address, so it is safe." | A real address proves the mailbox sent it, not that your colleague did. Compromised mailboxes are the standard route for invoice fraud. | Confirm unusual requests through a second channel you choose. |
| "They knew my name, address and order number." | All of that is in breach dumps and broker databases. Personalisation is a sign of data, not of legitimacy. | Treat personalisation as noise. Judge the request. |
| "It was their voice on the phone." | Seconds of public audio are enough to clone a voice, and live video filters exist. Voice is no longer identity. | Hang up and call back on a number you already had. |
| "Antivirus will catch it." | Antivirus is useful against known malware. It does not detect a phishing page, a consent grant, or a stolen session cookie. | Treat it as one layer, not as the plan. |
Why Even a Two-Factor Code Can Be Stolen
The technique that made old advice obsolete is adversary-in-the-middle phishing, sometimes called a reverse-proxy or real-time relay attack. It is worth understanding precisely, because the mental model decides what you do about it.
The lookalike domain does not host a copy of the login page. It runs a proxy that sits between you and the genuine site. When you load it, the attacker's server fetches the real login page and passes it through, so what you see is the real page - its markup, its fonts, its branding. When you type your password, the server forwards it immediately. When the real site demands a second factor, the demand is relayed to you, you read the six digits from your app, and the server forwards those too, inside their validity window.
The genuine site now considers the login complete and issues a session cookie: the token your browser holds to say this visitor is already authenticated. The proxy keeps a copy. The attacker needs no further secrets - not the password, not a code - because they can simply load the cookie into their own browser. From the service's point of view nothing unusual happened at all.
What survives that attack is a credential that cannot be relayed. Passkeys and hardware security keys are bound to the exact domain they were registered for, and it is the browser - not the page, and not you - that checks the match. On a lookalike domain there is simply no usable credential, so there is nothing to forward. That is what "phishing-resistant" means in practice; multi-factor authentication and passkeys covers how to set it up.
What to do if you think you just typed a password into a proxy page. From a device and network you trust, open the real site by typing its address, change that password, then sign out of all other sessions - the sign-out is what kills the stolen cookie. Do not skip it: a password change alone often leaves the attacker's session alive. Then check the account's recovery email, recovery phone and connected apps for anything you did not add.
The Same Trick, Five Different Wrappers
The pretext changes with the medium. The underlying request does not.
| Channel | Typical pretext | The check that actually helps |
|---|---|---|
| A shared document, a corrected invoice, mailbox quota warning, payroll change | Read the registrable domain of the sender and of every link before reading the body | |
| SMS (smishing) | Parcel fee, unpaid road toll, bank alert, "sorry, wrong number" chat | Sender IDs are trivially spoofed, so the number proves nothing. Open the organisation's own app instead |
| Phone call (vishing) | Fraud team confirming a payment, IT support, courier needing a code | Hang up and dial back the number printed on your card or statement. Never the number the caller gives you |
| QR code (quishing) | A sticker placed over a real code on a parking meter or poster, a code inside a PDF | Read your camera's destination preview before opening. If it is shortened or unfamiliar, type the address yourself |
| Chat and collaboration apps | A compromised teammate, a fake helpdesk or bot account, a "shared file" in a workspace | Names and avatars are editable. Confirm identity in a second channel, and be suspicious of any file shared outside the normal workspace |
QR codes are popular with attackers for a structural reason: they move the victim from a filtered work computer onto a personal phone, where there is no mail gateway, no endpoint protection and a narrow address bar that truncates the very part of a URL that matters.
Push-notification bombing - dozens of approval prompts in a row, usually at night, until one is tapped to stop the noise - is the same idea applied to a different sense. The rule is absolute: a prompt you did not start is a report, not a decision. One unexpected prompt already tells you that someone else knows your password. Deny it, then change that password and sign out all sessions.
The Sixty-Second Check
Run this in order. Stopping at any yes is enough.
- Source. What is the registrable domain of the sender, and of every link? Does it belong to the organisation it claims to be?
- Expectation. Was I waiting for this - the parcel, the invoice, the document, the reset?
- Pressure. Is there a deadline in hours, a threatened closure, or someone unreachable behind it?
- Process. Does it ask me to skip a normal step, use a different channel, or keep it quiet?
- Secret. Does it want a password, a code, an approval, a payment, or remote access to my device?
- Route. Did I reach this login page by following a link, or did I navigate there myself?
- Autofill. Did my password manager decline to fill a page it has filled before? That silence is a hint, not proof - but it is worth ten seconds.
If you have already acted on a message, do not spend time on self-reproach; go straight to what to do when an account is compromised and work the steps in order. Speed matters far more than dignity.
Reporting, and What It Is Worth
Reporting is not just civic duty. It is how a phishing domain gets blocked at the gateway for everyone in your organisation, and how a takedown request gets grounds.
- At work: use the report button built into the mail client - Report Message in Microsoft 365, Report phishing in Gmail - which submits the original headers rather than a forwarded copy. Forwarding destroys exactly the data that matters.
- Consumer mail: the Anti-Phishing Working Group accepts reports at
reportphishing@apwg.org. - United Kingdom: the National Cyber Security Centre's Suspicious Email Reporting Service takes reports at
report@phishing.gov.uk, and suspicious texts can be forwarded to7726. Similar short-code and portal arrangements exist in many countries; find yours on the regulator's own domain rather than through a search advertisement. - If money moved: your bank the same day. Chargeback rights and fraud-liability rules are frequently tied to how quickly you reported, and that window can be measured in hours.
Be realistic about outcomes. One report rarely identifies an attacker. Its value is a dated paper trail, a blocked domain, a takedown, and the aggregate signal that eventually gets infrastructure taken offline. And refuse one offer outright: anyone who contacts you offering paid account recovery, or a "hacker for hire" to get your account back, is running a second scam aimed at people who were just robbed.
Questions readers ask about this page
Can a phishing site look exactly like the real login page?
Yes, and in one common variant it literally is the real page. An adversary-in-the-middle kit proxies the genuine site to you, so the markup, fonts and branding are authentic because they come from the real server. Only the domain is fake, which is why reading the registrable domain matters more than judging how professional a page looks.
Does HTTPS or the padlock mean a site is safe?
No. The padlock means traffic to that site is encrypted; it says nothing about who operates it. Certificates are free and issued within minutes to any domain, including lookalikes that exist only to harvest logins. Read the domain name next to the padlock, from the right-hand end.
I gave away a one-time code. What now?
Treat the password as compromised too, because the code is normally asked for after the password. From a trusted device, go to the real site by typing its address, change the password, then use sign-out-all-sessions so any stolen cookie stops working. Then check recovery email, recovery phone, connected apps and mail forwarding rules for anything you did not add.
Why do I get approval prompts I never asked for?
Someone already knows your password and is trying to complete a sign-in. These prompt floods - push bombing or MFA fatigue - are aimed at tiring you into tapping Approve. Deny every prompt, change the password, and sign out all other sessions. One unexpected prompt means your password is not a secret any more.
Are password managers safe to use on a page I am not sure about?
They are most useful precisely there. A manager only fills a credential on the domain it was saved for, so silence on a lookalike page is a warning you would not otherwise have had. It is a hint rather than proof: a lookalike on a subdomain of the real service can still match. Never copy a password out of the manager and paste it in manually.
Sources checked for this page
- CISA - Recognize and Report Phishing
- CISA - Implementing Phishing-Resistant MFA (PDF)
- UK NCSC - Phishing: spot and report scam emails, texts, websites and calls
- US FTC - How to recognize and avoid phishing scams
- W3C - Web Authentication Level 2 (origin binding)
- FIDO Alliance - Passkeys
- Anti-Phishing Working Group - trend reports and reporting address
- MDN - HTTP cookies, sessions and credentials
About DEWA89
DEWA89 is an independent educational project written by one person. It is not a company, an agency or a managed editorial team, and it does not pretend to be one. Rehan Aldiansyah writes these pages, checks them against the primary sources cited on each one, and answers corrections sent to the address on the support page.
DEWA89 is the name the site publishes under; the name above is the person accountable for what it says. Nothing here is generated and published unread: a claim either traces to a source you can open yourself, or it is marked as the author's own judgement.
How this site is funded
It is not. There is no advertising, no sponsorship, no affiliate link, no paid placement and no product for sale anywhere on this site. No company pays to be mentioned, and no page carries a commission-bearing link. Hosting is paid for out of the author's own pocket, which is the whole of the commercial relationship. If that ever changes, the change will be disclosed on this page before it appears anywhere else.
How to read this site
- Primary sources only. Where a claim can be checked, it links to the standards body, regulator or vendor documentation that supports it — not to another summary of it.
- Limits are stated. Where a control fails, or a setting only partly helps, the page says so in the same breath as the advice.
- Country-specific answers are labelled. Reporting routes, consumer protections and privacy law differ by country, so a passage that applies in only one is marked as such.
- No fear as a sales tool. Scaring a reader into a purchase is the behaviour this site exists to argue against.
Editorial standards we hold ourselves to
- We do not quote a statistic without naming the report and its year.
- We do not name a step-by-step settings path unless the vendor's own documentation still shows it.
- We do not present a product as the answer. Where a category of tool helps, we describe the category and what to look for in it.
- We do not write in the voice of expertise we do not have. When a question needs a lawyer, a doctor or a regulator, the page says so and stops.
- We do not silently rewrite a substantive claim. Material corrections are recorded with a dated note on the page, as described on the support page.
Dates, and what they mean
The date below is the last time these pages were re-checked against the sources they cite. It is a record of what happened, not a schedule: no page here states a calendar interval for review, because a static site cannot enforce one. Pages are re-checked when something they describe actually changes — a vendor renames a setting, a standard is revised, a regulation is amended, a link breaks — and at least once a year regardless, so that nothing is left unexamined through neglect.
The date moves only when a person has re-opened the cited sources and confirmed the text still matches them. It is not the date a file was last saved. Where a passage has been left standing but is no longer certain, it is marked as uncertain rather than quietly carried forward.
If the date below looks old, that is information, not a fault. It means the pages are due for their next pass. Everything on them links its primary source precisely so you can check the current position yourself rather than relying on our copy of it.
Who is accountable for this page
| Published by | DEWA89, an independent educational project written and paid for by Rehan Aldiansyah |
|---|---|
| Written by | Rehan Aldiansyah — an independent writer, publishing under the DEWA89 name. No employer, qualification or years of experience is claimed here, because this site asserts only what can be checked. |
| Reviewed by | Rehan Aldiansyah. This site has no separate reviewer, and we do not name one to look better. Every page is self-reviewed against the sources it cites, and that is exactly what the review record below means. |
| Corrections | Send a correction — specific reports are checked against a primary source and fixed or answered |
| First published | 2026-10-08 |
| Last reviewed | 2026-10-08 — every page on this site carries the same review date, and each one links the sources it was checked against |
Contact
Corrections, factual disputes, reports of a link that now leads somewhere harmful, and notices that a described setting has moved are all welcome at the address below. Rehan Aldiansyah reads them.
We will never ask you for a password, a one-time code, a recovery code or remote access to your device, and we will never ask you to confirm account details by replying to a message. Any message claiming to come from this site and asking for any of that is not from us.
Scope and limitations
Read this before acting on anything here.
- This is general education, not advice for your situation. It explains how account takeover and phishing generally work and what a reader can do about them. It is not legal advice, it creates no advisory relationship, and it should not be quoted in a dispute, a claim or a police report. If an account, your money or your identity is already affected, the people who can act are the provider's own recovery process, your bank, and the police or reporting body where you live.
- We cannot see your accounts or your devices. We cannot tell you whether a particular message you received is genuine, whether an account has been compromised, or what an organisation holds about you.
- We cannot act on your behalf. We cannot contact a platform, bank, regulator or data protection authority for you, and we cannot investigate anyone. Requests like that have to go to the provider directly.
- Menus move. Settings are renamed, moved and reset by updates. A click path that was accurate on the review date may look different in your version. Treat every step here as a description of what to look for rather than a guarantee of what you will see.
- We can be wrong. Errors get through. If you find one, the support page explains what happens next.