Category: Phishing & Social Engineering
Phishing in the browser
Phishing is when an attacker tricks someone into revealing credentials or approving access—often through a convincing message that sends them to a fake login page.
Most teams search for phishing after a suspicious email or a weird login prompt. The more useful question is what happens in the browser once a user follows the link: credential capture, token theft, OAuth consent abuse, or a full session replay against the real app.
Quick answer
One successful phish can become full SaaS account takeover, financial fraud, and long-lived access via stolen sessions—not just a “bad link.”
For risky links and login flows, isolation keeps the page off the endpoint by running it in a disposable container and streaming only the rendered output to the user.
Last updated
2026-04-09
How it usually happens in the browser
- A user clicks a link from email, chat, SMS, or an ad and lands on a lookalike domain (or a compromised legitimate site).
- The page imitates an identity provider or app login and prompts for email/password, MFA codes, or “approve this sign-in.”
- Attackers capture credentials directly, or proxy the login in real time to steal session cookies/tokens after MFA.
- The user is redirected to the real site so the attack feels “normal,” while the attacker reuses the captured session elsewhere.
What traditional defenses miss
- User training and “spot the URL” guidance doesn’t hold up under time pressure and mobile browsers.
- MFA helps, but modern kits can steal session tokens after MFA (adversary-in-the-middle).
- VPNs and network security don’t stop a user from typing secrets into a phishing page on the open web.
- Endpoint tools may not treat “a web page” as execution, even though the browser is now the primary attack surface.
How isolation changes the game
- Isolation keeps untrusted web pages away from the endpoint by running them in a separate container and streaming only the rendered output to the user.
- When the session ends, the isolated container is deleted, which reduces persistence from drive-by content and limits session residue.
- Admins can enforce policies for risky browsing paths (unknown domains, newly registered domains, webmail, file shares) without relying on perfect user decisions.
- Isolation reduces exposure from token/cookie theft techniques that rely on running active content close to the user’s device.
Operational checklist
- Define what “untrusted” means (unknown domains, external webmail, link-shorteners, newly registered domains).
- Route untrusted browsing into isolation by default; avoid per-user “security modes” that people forget to enable.
- Block or heavily restrict downloads from isolated sessions; require scanning and explicit exceptions.
- Prefer phishing-resistant auth (FIDO2/WebAuthn) for critical apps; tighten re-auth for sensitive actions.
- Roll out to a pilot group first; tune allow/deny and friction points before broad enforcement.
- Add user-facing signals (banner, indicator) so employees recognize “this is an isolated session.”
What to do next
Treat phishing as a browser-session problem, not just an email-filter problem. The fastest durable win is to keep risky browsing paths off the endpoint, restrict what happens after a suspicious click, and require stronger re-auth for high-impact actions.
Each finding-type guide is built from Legba Adversary's real detection and validation logic, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.
FAQs.
References
- 01
- 02Cloudflare: Browser IsolationCloudflare
- 03
