Intended readership: CISOs, SOC managers, threat hunters, incident response teams, IT leaders, MSSPs

Available in: Group-IB XDR

Introduction

Security teams have always known where credential phishing succeeds: on a rendered page in a browser tab, open for a few seconds, with a form on it. The hard part has been doing anything about it from outside the browser, which is as close as your EDR, network sensors, and proxy can get.

Group-IB’s new Browser Agent works from the inside. It closes the tab before the form can take a password, blocks the domain for everyone else in the company, and invalidates the credential before anyone can sign in with it.

This is prediction instead of reaction. Group-IB Threat Intelligence identifies phishing infrastructure while the attacker is still preparing it, hours or days before anyone clicks, so the verdict exists before your employee reaches the page.

Keep reading to see how one employee’s encounter ends up protecting everyone in the company.

Why other tools couldn’t help

If you have ever investigated an account takeover, you already know what the evidence looks like: your EDR registered a browser process making an outbound connection, which is what browser processes do all day long; your network sensor recorded an HTTPS session to a domain it had no particular reason to distrust; and your proxy wrote a line into a log that would not be read until the following morning. Every one of those tools did exactly what it was built to do, and between them they still captured only the fact of a web visit, never the page itself.

That is a question of where the sensors sit rather than how well they are tuned. Forrester reports that more than two thirds of business users now do the majority or all of their work inside the browser, which is where the applications, the data, and the sign-in pages all live, while most security stacks were built around the endpoint and the network perimeter. Forrester describes the consequence plainly: even leading EPP, EDR, and XDR platforms have “limited insight regarding activity within the browser itself” unless an additional component, usually an extension, is deployed into the browser.

A secure web gateway narrows the gap without closing it, because it only sees the traffic it is positioned to decrypt, it loses the session entirely when the device is off the corporate network, and even where it does have visibility it sees the request rather than the page rendered in response to it. Reputation data does not close it either, because phishing infrastructure is usually newer than the feeds looking for it.

Figure 1. Everything else arrives after the fact. The Browser Agent acts at second zero

A new component in Group-IB XDR

To close that gap, we are adding the Browser Agent: a lightweight Chrome extension, deployed and managed from a dedicated module in the XDR console, that turns every managed corporate browser into a sensor. Visited domains and URLs are checked against Group-IB Threat Intelligence in real time, and page-visit telemetry streams to the console alongside every other sensor you run.

It does not treat every page visit as equally interesting. The extension builds a local picture of what normal browsing looks like for that user, based on which domains they visit and how often, and sends the unfamiliar ones to the console to be checked.

Some vendors in this space answer the problem by replacing the browser entirely. Gartner’s definition of the category puts the extension at the center: policy and control delivered through a centrally managed browser extension, with a full replacement browser treated as an optional addition rather than the starting point. Employees keep the browser they already use.

What happens when your employee visits a phishing page

On a malicious verdict the extension closes the active tab before the page can take input, and the user is shown a page explaining what was blocked and why. The domain is then blacklisted across every managed browser in the organization, so the first employee to encounter a phishing site closes it for everyone behind them. The campaign gets one attempt against the whole company.

The verdict comes back within two seconds, the tab closes within 300 milliseconds of the click, and the blacklist reaches every browser in the organization seconds after the first encounter, faster than a second employee could realistically open the same web page. In the near future, identity remediation will also begin automatically within five seconds of the verdict.

Figure 2. One verdict, two automatic actions, and a one-click reset for an analyst

Figure 3. What the second employee sees instead of the phishing page

Identity protection runs alongside it. The alert identifies the account that was targeted, and resetting its password requires a single click in the console, with no need to work out which identity was involved or switch tools to act on it. Automatic reset through the API and session and token revocation are planned for a later version.

The agent also identifies what kind of account the page was trying to harvest, whether a corporate login, a banking login, or an administrative one, so the response matches the target rather than resetting a corporate password because something suspicious happened.

If a domain is only recognized as malicious later, a retrospective scan of collected history finds the employees who reached it earlier and starts the same protection for them.

The alert that lands in the console is therefore a record of something already contained rather than a task. It opens with a dedicated browser asset block, a table of the browser events that led to the detection, and an investigation graph connecting the asset, the URL and domain, and the target, so the sequence arrives assembled rather than waiting to be reconstructed from three separate log sources.

What this looks like on your typical work day

People reach phishing pages by more routes than a security team can watch. A link in a message, a link passed on by a co-worker who thought it was legitimate, an ad, or a search result that outranks the real site because the fraudsters spent days pushing traffic at it with bots. Whatever the route, the destination is the same page that gets reached by more than one person.

With the Browser Agent in place, one person reaches the page first. Their browser checks the domain, closes the tab, and pushes the block to every other browser in the company, so everyone arriving after them finds a page that no longer loads. The campaign spent its entire run on a single employee, and that employee’s credentials were reset before the attacker could use them.

What disappears is most of the morning routine: incident queue filling with duplicate reports, bulk credential reset for everyone who might have clicked, or conversation with their managers explaining why a precaution locked out half a department. No reconstructing from mail logs and proxy records who reached the page and who only saw the link, because the browser already knows. The exposure is one person, that person was remediated before anyone opened a ticket, and what is left for your team is deciding whether the campaign is worth hunting further.

Every other sensor in the stack learns about a phishing page by inference, after the fact. In the browser you can act while the page is still open: close it, block it for everyone else in the company, and invalidate the credential before anyone has a chance to use it.

What stops it locking people out

Automation of this kind raises an obvious worry: the false positive that resets someone’s password in the middle of a workday. The gating matters as much as the capability.

Password resets happen only above a confidence threshold. A resource rated suspicious rather than malicious produces a passive warning and no automated reset. Blocking actions are reversible, and a domain later cleared is removed from the blacklist and access restored. Anything on your organization’s allowlist is left alone, so a domain you have deliberately permitted will not be blocked. If the extension loses contact with the console, it carries on blocking the domains it already knows about rather than letting everything through.

Every verdict also needs to be explainable. It records the signal that triggered it, the conclusion reached, and the confidence behind it, so the analyst can act on evidence. If the analyst then triggers a reset, that decision trail is preserved: anyone reviewing the case three days later can see exactly why the action was taken, rather than having to infer the reasoning, and the compliance team has a clear record to support it.

Where the intelligence comes from

A verdict this consequential is only as good as the intelligence behind it, and public reputation sources are critically late: a phishing domain is typically registered, weaponized, used to harvest credentials for a few hours, and abandoned before it ever surfaces in an open feed. That is the reason page-analysis approaches and reputation feeds don’t suffice.

Group-IB Threat Intelligence tracks phishing infrastructure from the moment it is created, monitoring domain registrations, hosting patterns, and the toolkits used to assemble credential harvesting pages, and it is that same pipeline, the one behind Group-IB’s investigations into phishing ecosystems, which decides what the extension blocks.

The verdict on a phishing domain is reached days before any of your employees encounter it, which means the block is not a fast reaction to an unfolding attack but a decision made in advance and enforced the moment it becomes relevant. Intelligence that would otherwise sit in a report becomes an action taken inside a browser tab, on behalf of one specific employee, without a rule being written.

Finding out who else reached it

Blocking handles the encounter in front of you. The harder question is when Threat Intelligence identifies new phishing infrastructure today, who in the organization reached it last week, before anyone knew?

Page-visit activity, including which pages were opened and how long the user stayed on them, streams to the console as Threat Intelligence classified events, which gives hunters a queryable stream of artifacts no other sensor produces at the same resolution. Endpoint and network telemetry can only describe a web visit as a process or a connection; the browser records it as it actually happened. Three hunting patterns follow:

Retrospective sweeps. When Threat Intelligence identifies new phishing infrastructure, one query returns every employee who reached it before anyone knew it was dangerous.

Organization-wide exposure checks. During an active campaign, establish how many people across the company reached the infrastructure and which accounts were involved.

Unfamiliar browsing activity. Domains that fall outside what is normal for that user, surfaced as browser-level events rather than inferred from a connection log.

Rolling it out

The new Browser Agent was built to deploy through the tooling your IT team already operates. A guided wizard in the console generates a ready-to-deploy package containing the signed extension, a per-device client certificate, and the connection configuration, which distributes through GPO, Intune, or Jamf across Windows, macOS, and Linux. Each managed browser then registers as a first-class asset with its own card and a regular heartbeat, so you can see which version is running where, across thousands of concurrent browsers and through the traffic spikes a live phishing campaign produces.

Browser extensions are a recognized risk category, so asking you to install one more deserves an answer. The risk in extensions comes from how they arrive and how they are governed. Browser Agent is signed and deployed centrally through the same allowlist your IT team already uses to keep other extensions out, rather than around it. It authenticates with a per-device certificate over mTLS, so it holds no credentials, tokens, or API keys worth stealing. The reason extensions are a risk category at all is that they can see and act on the page, which is the same reason an extension is the only thing that can stop what happens there.

Browser Agent collects the domains and URLs visited, timestamps, and how long each page was open, but never the content of a page, what is typed into a form, or the credentials themselves. It operates only in corporate browsers the organization has explicitly provisioned with a certificate, so personal devices and personal profiles stay outside its scope, retention is configurable, and the local baseline described earlier means routine browsing is largely evaluated on the device rather than shipped to a console.

Where the Browser Agent is today

The Browser Agent is currently a beta release giving customers using Google Chrome early access. Support for Microsoft Edge, Mozilla Firefox, and Apple Safari is to be added in the coming months, with pre-download file checks and broader SaaS identity tracking to follow.

Browser-level protection has generally meant buying a separate product from a separate vendor, with its own procurement cycle, its own console, and its own line in next year’s budget. In 2026, every Group-IB XDR customer gets the Browser Agent at no additional cost, regardless of which components they currently have installed.

One click, everyone covered

Putting the sensor inside the browser changes what is possible in the seconds that decide whether an account is compromised. The page can be shut down while the employee is still looking at it, the domain can be taken away from the campaign across your whole organization, and the credential can be invalidated before anyone reaches a login screen with it.

Somebody in your company will always be the first to click. The question is whether anyone else has to.