The call is coming from inside the helpdesk

On April 24, BleepingComputer reported on a financially motivated cluster that Palo Alto's Unit 42 is tracking as CL-CRI-1116, also known as BlackFile, also known as UNC6671, and which CrowdStrike (separately, but probably the same people, or at least cousins) calls Cordial Spider. The taxonomy is a mess. The behaviour is not.

Here is the behaviour, in the order it happens to you:

1. You get a phone call. The caller ID says it is internal IT, or close enough — spoofed VoIP, or a fraudulent CNAM (the human-readable name the phone network shows alongside a number, which it turns out is not especially well authenticated). The person on the phone is friendly and slightly apologetic. They are very sorry to bother you. There is a small problem with your account.
2. To fix the small problem with your account, they would like you to log in to a corporate page they will text you the link for, or sometimes just walk you to. The page looks correct. It has the company logo. It has the right wording. It is not the right page.
3. You type your password. The page asks for your one-time code from your authenticator app. You type that too.
4. The page says thank you and possibly displays a spinner. You hang up.
5. The attacker, on their own laptop, somewhere else, takes your freshly-typed password and your freshly-typed six-digit code, logs in to your real SSO portal in the next ninety seconds, and — and this is the elegant part — registers their own MFA device on your account.
6. They are now you. They have a permanent second factor that lives in their pocket. Your second factor still works too, which is why nobody notices.
7. They go to Salesforce, they go to SharePoint, they search for files with the words "confidential" or "SSN" in them, they download everything they can, and a week later your CEO gets a seven-figure ransom email from a Gmail address. Sometimes, per BleepingComputer's report, employees also get swatting threats, which is a level of customer service most extortion crews do not bother with.

Anyway.

Where, exactly, the attack happens

It is worth being precise about what part of this chain runs where, because the chain is not all in the same place.

The phone call runs over the phone. The call is phone-shaped. No browser, no laptop, no operating system you can patch can do anything about the call itself, because the call is not on the laptop. (You can train people, you can put signage in the breakroom, you can have the real helpdesk send a follow-up email after every legitimate call, and all of those help, but the call is, as they say in the field, a people-shaped problem.)

The fake login page runs in a browser. Specifically, it runs in whatever browser the employee happens to have open on their work laptop, in whatever profile they were last using, with whatever sessions and cookies and saved-password autofill they happen to be carrying around. This part is a computer-shaped problem.

The MFA registration on the real account runs on the attacker's laptop, in the attacker's browser, against the legitimate SSO portal. This is not a problem in the user's browser at all; it is a problem with how the SSO portal handles MFA enrollment when somebody knows the password and a current OTP. Your IdP (the identity provider that runs SSO — Okta, Entra ID, Google Workspace, whichever one decided your password is correct) treats "I have the password and a fresh OTP" as proof enough to add another factor. That is a policy choice, and it is the policy most enterprises ship with by default, because the alternative is users locking themselves out when they replace their phone.

The Salesforce and SharePoint exfil runs also on the attacker's laptop, against your real SaaS, with their freshly-minted second factor. This part is, in the strictest sense, not "an attack on the employee's browser." It is the attacker logging in like a normal person, because at this point they are a normal person. Your employee's browser sat the last three steps out.

So if you are looking for a single technology lever you can pull to prevent BlackFile end-to-end, there isn't one. The attack is split across a phone, a fake page, an IdP policy, and an attacker's laptop.

What there is — and this is the only part of the chain a browser vendor can credibly say anything about — is the second step, the fake login page. The page has to render somewhere. Wherever it renders, the employee types real credentials and a real OTP into it. So the question is just: in what kind of container do you want that particular event to happen?

The page has to render somewhere

Right. So the page renders in a browser. Which browser?

If you do not do anything, it renders in whatever browser the employee was using — Chrome on a personal laptop, Edge on a corporate laptop, Safari on the iPad they happened to have nearby. Whichever browser it is, it has been around for a while. It has a profile that has been around for a while. That profile probably has cookies for the real corporate SSO portal already, because the employee logs in to work every morning. It has saved passwords. It has an autofill suggestion that is, helpfully, the actual corporate password — except that autofill correctly won't fire on a phishing domain (browsers are good at this), so the user types it manually, which they are also good at, because they have done it ten thousand times.

The fake page does not need any of those cookies. The fake page just needs the user's fingers to keep doing what fingers do when a page asks for a password. The fake page collects the password. The fake page collects the OTP. The fake page is done.

But here is the question that has been bugging me. Why was the employee's personal browser, with its long-lived profile and its collection of every site they have ever logged into, the place where the fake corporate login page rendered in the first place? The page claims to be corporate. The user is at work. The user is, as far as the user is concerned, doing work things. Why is "the corporate login page" rendering in the same software environment as "the cousin's Spotify share link" and "an Etsy account from 2018"?

This is, I think, the question.

The managed-browser argument, made small

Here is the small, narrow, honest version of the Bromure argument for this attack.

An IT department can ship Bromure as the sanctioned corporate browser. Not the only browser on the laptop — the user can still have Chrome and Safari for personal browsing — but the only browser that is configured, enrolled, and visibly marked as the place where corporate SaaS is supposed to live. Bromure has an Enterprise settings tab whose entire job is exactly this: an HTTP proxy field, and a slot for internal root certificates. Two settings. That is all it does, and it is intentionally all it does. An org configures those two things once, hands employees a Bromure profile pre-configured to trust the corporate CA and route through the corporate proxy, and lets the profile be visibly the place where corporate SaaS lives.

(We are not claiming the Enterprise tab is a full MDM control plane. It is two text boxes. Two well-chosen text boxes are sometimes enough.)

Inside Bromure, every tab is its own disposable Linux VM with its own ephemeral profile. So when the corporate Salesforce tab opens, it opens in a managed VM that knows about the corporate proxy and trusts the corporate CA. When the employee opens, separately, the cousin's Spotify share link, that opens in a different VM with a different profile that has none of those things.

Now, the phone call still happens, exactly the same way. The user is still walked to a link. Here is what changes:

• The link, when clicked, opens in some Bromure VM. It does not, by default, open in the same VM as the employee's real Salesforce session. (Profiles in Bromure do not silently merge. The page that loads in a "throwaway link" profile cannot read cookies from the "corporate Salesforce" profile, because they live in different VMs with different network stacks and different disks.)
• The user, possibly, types real corporate credentials and a real OTP into the page anyway. Bromure does not stop typing. This is the honest part.
• The session token (or sometimes just the cookies, depending on the kit) the page captures lives inside a profile the user is about to close, on a VM that is about to be wiped, with no privileged relationship to anything corporate. The captured token is, in this sense, low-grade — it is a souvenir from a tab.

This last point, I want to be careful about, because it is exactly the kind of thing where it is easy to overclaim.

In the BlackFile chain as documented, the captured token is not actually used to log in to the real Salesforce — the attacker uses the credentials and OTP to log into the real SSO portal from their own laptop, and registers their own MFA device. The captured cookies were never going to be replayed against the real corporate session anyway, because they are cookies for a phishing domain, not for the real domain. Where Bromure's per-VM isolation matters is the leg behind the fake page: any tab-side mischief (token exfil to an attacker endpoint, follow-on script that tries to read other cookies, redirect chains that drop additional payloads) is contained inside a VM whose filesystem and network and process tree are sealed off from the rest of the laptop and from the real corporate browser session. The fake page is a fake page. It just gets to be a fake page in a box.

The cue, in particular, is doing a lot of work in this diagram, and it is worth saying out loud. A managed browser deployment whose sole function is "the corporate Salesforce / SharePoint / Workday tab looks visibly different from the random-link tab" is, on its own, a non-trivial defense, because the canonical BlackFile victim is a tired person who got a phone call at 4:45 PM on a Thursday. The visible distinction is not a UI flourish; it is the entire ballgame.

What this does not fix

I want to keep being honest about this, because the failure mode here is a vendor who explains how their product would have prevented an attack and then, when you read it carefully, describes a different attack.

It does not stop the call. The phone call is on the phone. Bromure does not run on the phone, does not see the phone, has no opinion about the phone. If the user picks up and is convinced by a friendly voice that there is a small problem with their account, the user is going to look at a fake login page. We can change which browser the page renders in. We cannot change whether the user looks at it.

It does not stop typing. If the user types real credentials and a real OTP into the fake page, those credentials and that OTP are now in the attacker's possession, regardless of where the page was rendered. The fact that the page is in a disposable VM does not unlearn what the user just typed.

It does not stop MFA enrollment. The MFA enrollment leg happens on the attacker's laptop, against the legitimate IdP. Bromure is not running on the attacker's laptop, and Bromure is not the IdP. The mitigation here is on the IdP side, and it is the boring one: turn on "require step-up authentication for new MFA enrollment," gate enrollments to the corporate network or a managed device, alert on new-factor registration, and accept that the alternative is users locking themselves out when they get a new phone. This is a config choice every Okta and Entra ID admin can make today, and many have not, and that is — to put it gently — the part of this story that should keep CISOs up at night more than the browser part.

It does not, in the strict sense, stop a real-time AiTM proxy attack. A separate class of phishing kit (Evilginx, Modlishka, Caffeine, the $2,500-a-pop AiTM-as-a-service rentals that have become the dominant Microsoft 365 attack pattern) does real-time relay: the user types into a page that proxies, in real time, to the legitimate IdP. The session cookie the IdP issues goes to the proxy; the proxy hands it back to the attacker. If you imagine a BlackFile-style call directing the user to that kind of page — which is not what BlackFile is currently described as doing, but which is where this category is going — then the captured cookie is a real session cookie for the legitimate IdP, and the question becomes whether it can be replayed from somewhere else. That is a different post, and a harder one, and the honest answer involves session-binding controls (DBSC, mTLS-bound tokens) that are mostly the IdP's job and only partly the browser's. We are not going to wave a magic wand at that one.

What managed Bromure does, narrowly: it makes the fake page render in a place that is unmanaged, ephemeral, and visibly distinct from the managed corporate environment. It restricts the blast radius of any post-page tricks the kit might pull (extension installs, host filesystem writes, persistence) to a VM that is going away. And, in the BlackFile-as-described chain specifically, it does not, by itself, prevent the attacker from going on to register their own MFA device — that's the IdP's job. We are mitigating one of the four machines in the chain, which is the only one we run on.

Why this is, eventually, the only way

Anyway. Look. Step back.

The thing about BlackFile is that it is a remarkably efficient business. They picked retail and hospitality because retail and hospitality have lots of employees, distributed shifts, after-hours schedules, real IT helpdesk teams that legitimately call employees, and a payroll of very stressed people who really do not want to be the reason the cash registers are down. They picked vishing because vishing scales (one person on a phone can call a dozen targets in an hour, and the success rate is, by the standards of this industry, incredible) and because the call is the part of the chain you cannot patch. They harvest credentials and OTPs because credentials and OTPs are the part of the chain that, in 2026, is still most enterprises' front door, despite a decade of presentations explaining that they shouldn't be.

The part of the chain a browser can affect is small. It is one of four machines. You should not buy a browser because it claims to defeat BlackFile end-to-end. You should buy a browser because it does the one thing it can do well — keep the corporate session in a managed, identifiable place, and keep the random-link session in a place that ceases to exist when you close it — and then you should pair it with the boring, unsexy, IdP-side controls that close the actual loop.

The phone is going to keep ringing. The page is going to keep loading. The question is just where, exactly, it loads, and what is around it when it does. It turns out that is something you can change.

Sources:

• BleepingComputer — New BlackFile extortion gang targets retail and hospitality orgs (2026-04-24)
• CrowdStrike — Cordial Spider adversary profile
• Help Net Security — Attackers use AiTM phishing kit, typosquatted domains to hijack AWS accounts (2026-03-10) (referenced for the broader AiTM-as-a-service market context, not for BlackFile specifically)