Why EDR and antivirus miss web-based threats

For most people, the operating system has quietly become a launcher for one application: the browser. Research from the Enterprise Strategy Group found that knowledge workers now spend the majority of their day inside a browser window — on average around 56% of the working day, and more than half the day for most employees. [1] Email, documents, finance systems, customer records, admin consoles and AI tools all live behind a browser tab now, which means so do the credentials, session cookies and access tokens that unlock them.

Attackers have followed the work. By the most widely cited estimate, more than 90% of cyberattacks begin with phishing — and phishing is, overwhelmingly, a link or a page opened in a browser. [2] (For balance: breach forensics such as the Verizon DBIR attribute a smaller share of breaches to phishing as the single “initial vector,” while noting the human element appears in around 60% of breaches — but no one disputes that the browser is where the click lands.) The browser is now the most concentrated point of exposure most organizations have, and the layer the rest of the security stack sees least.

What antivirus was built to do — and why the web slips past it

Traditional antivirus answers one question very well: is this file known to be malicious? It scans files written to disk, compares them against signatures of known malware, and watches for known-bad behaviour when a program runs. For decades that was the shape of the threat: something gets downloaded and executed.

A credential-phishing page breaks that model completely. When you land on a fake login page, nothing is downloaded and nothing is executed. A web form collects what you type and posts it to an attacker’s server. From the antivirus’s point of view, no malicious file ever touched the machine, so there is nothing to scan and nothing to quarantine. [3] The most damaging part of the attack — handing over a password or an MFA code — looks identical to normal browsing.

Signature-based scanning has a second, well-known weakness: it can only recognise what it has already catalogued. Against a genuinely new (zero-day) page or payload, there is no signature yet, so it is permitted by default until vendors analyse the threat and push an update — a delay that can run from hours to weeks. [4] Modern phishing is built precisely to live inside that window.

EDR is far more capable — and still can’t see inside the tab

Endpoint Detection and Response was the industry’s answer to antivirus’s limits. Instead of only matching signatures, an EDR agent records rich telemetry from the operating system — process launches, file changes, registry edits, network connections — and uses behavioural analysis to flag suspicious activity on the host. Against malware that executes on a device, it is genuinely strong: compromising the OS without tripping an EDR has become expensive and noisy for attackers.

Which is exactly why attackers increasingly don’t bother. The defining trait of a browser-based attack is that it plays out inside the application session, not on the host. EDR protects the integrity of the operating system, but it has no visibility into what is happening on the page rendering inside a tab. [5] Consider how the most common web attacks actually unfold:

• Adversary-in-the-middle (AiTM) phishing renders a pixel-perfect login page and relays your credentials and session token to the real site in real time, defeating MFA. To the operating system, nothing unusual happened — a browser loaded a web page, as it does thousands of times a day. [5]
• Session hijacking uses a stolen session cookie to walk straight into an account with no password and no malware. The activity blends into ordinary browser traffic and generates no endpoint event to detect. [5]
• Credential harvesting happens entirely in a web form; the data leaves via a normal HTTPS request that looks like any other.

Network-layer tools don’t close this gap either. Secure web gateways see traffic and DLP scans files, but none of them inspect what is happening inside the session — which tab is open, what is being typed into a form, or which script a page is running. [6] The result is a parallel attack surface that the endpoint-and-network stack simply cannot reach.

Blocklists and “Safe Browsing” don’t fill the gap

The usual fallback is a reputation list: block the URL once it’s known to be bad. The problem is timing. A 2025 study that tracked more than 286,000 live phishing URLs found that Google Safe Browsing detected only 18.4% of phishing sites, taking about 4.5 days on average — and that nearly 84% of phishing sites were already gone before detection ever caught up. [7] The median phishing site stays live just a few hours; many single-use links exist for seconds. By the time a domain reaches a blocklist, the campaign is usually over and the attacker has moved on.

It gets harder. Roughly two-thirds of the phishing campaigns analysed in 2025 used MFA-bypass and URL-obfuscation techniques, and many hide behind CAPTCHAs specifically so automated crawlers and URL filters never see the malicious page at all. [6] List-based defences are answering a question — “has someone already reported this exact thing?” — that brand-new attacks are designed to make irrelevant.

The common thread: they all ask the wrong question

Antivirus asks “is this file known to be bad?” EDR asks “is this process or host behaviour suspicious?” Blocklists ask “is this domain already on a list?” Each is good at its question. But a phishing page that downloads nothing, executes nothing, runs on a brand-new or compromised domain, and harvests credentials through an ordinary web form returns the same comforting answer to all three: no.

The cost of that blind spot isn’t abstract. Phishing remains the most common — and one of the most expensive — breach entry points, averaging around $4.88 million per phishing-related breach. [8] The tools are working as designed; the attack just isn’t where they’re looking.

What actually closes the gap: judge the page, in the browser, as it loads

If the attack happens inside the browser session, the defence has to live there too — and it has to judge the page by what it is, not by whether anyone has reported it. That means analysing the page itself, in real time, at the moment it renders:

• Visual analysis. Does this page look like a login for a brand it has no right to imitate? A convincing clone of a bank or Microsoft 365 page is recognisable by appearance even when the domain is brand-new and clean.
• Structural “x-ray” analysis. What do the page’s forms, scripts and components actually do? Credential-harvesting and off-domain data posting show up in the structure — even on an aged or compromised domain that every reputation check waves through.
• Per-page and in-session. Judging each page individually, as the user sees it, is the only way to catch one malicious page hidden on an otherwise-trusted site — and to act before anything is typed.

This is the layer antivirus and EDR were never designed to be. It doesn’t replace them — you still want strong endpoint and network defences for malware and host compromise — it covers the surface they can’t see. SafeToOpen Browser Security runs inside the browser and inspects each risky page as it loads, so a phishing page is caught on its own behaviour in well under a second, whether or not anyone has ever seen it before.

The takeaway

The browser became the workplace, and attackers moved in behind the work. Antivirus, EDR and blocklists remain essential against the threats they were built for — malicious files, host compromise, and the long tail of already-known bad infrastructure. But none of them can see the live page inside a tab, which is precisely where credential phishing now operates. Closing that gap takes a defence that evaluates each page in real time, in the browser itself — judging what a page does, not what its file hash, host telemetry or domain reputation happens to say.