The Phishing Kit That Deletes Canary Tokens: What BigBear 2.0's Code Admits About Your Detections

Buried in the JavaScript on one BigBear 2.0 phishing page is a three-item blocklist: canarytokens, events.data.microsoft.com, and OneCollector. Any request from the page that matches is silently dropped. Any <img> tag that matches is removed from the page by a MutationObserver as soon as it appears.

Someone wrote that on purpose. They ran into canary tokens often enough to decide their phishing kit needed a filter for them.

CloudSEK's TRIAD team published its teardown of BigBear 2.0 on 7 September 2026, after getting administrator access to the operator's panel. Most coverage has focused on the numbers, and they're bad. I think the more useful thing for defenders is the code. BigBear's three custom injections show what this operator was worried about. That's also a fairly honest list of which of your controls hold up and which don't.

What the panel showed

The numbers below come from CloudSEK's report. Infosecurity Magazine and CSO Online reported the same figures independently on 8 September.

• 5,137 credential records across 461 organizations and 438 unique domains
• 4,148 session cookies and 1,032 plaintext passwords
• 474 records CloudSEK classified as complete MFA-bypassed authentications, about 9.2% of the total
• 3,331 unique victim IPs in more than 40 countries, led by India (658 records), France (463) and Saudi Arabia (353)
• 42 VPS nodes over the campaign's life, almost all at The Constant Company (Vultr), with 26 removed from the panel since late July

The operator goes by "General Boss" and runs BigBear as a service. CloudSEK confirmed at least five affiliate operators, each receiving victims through its own Telegram bot. Two panel accounts act as resellers, each with two operators under it. Call it a small franchise.

Look at the sector list. IT services and managed service providers account for 151 of the identified organizations, far ahead of SaaS/technology at 38. CloudSEK describes the targeting as a mix of broad spraying and sector-specific lists, and the MSP share shows which lists someone paid attention to. An MSP engineer's Microsoft 365 session can lead to RMM consoles, customer tenants and password vaults. We covered the downstream version of this in how Storm-1175 moved from one N-central server into every customer network. BigBear is the step that comes before that.

The mechanics, briefly

BigBear 2.0 is a rebranded Evilginx2 build with one phishlet, called "offy", aimed only at Microsoft 365. The victim clicks a link, usually from email, and lands on a page that relays everything to and from login.microsoftonline.com. They type their real password into the real Microsoft form, pass their real MFA challenge and get a real session. The proxy copies the ESTSAUTH cookie from the Set-Cookie header on its way through.

From there it's automated. A Telegram alert fires, a cookie.js file is attached, and a replay API at /api/jobs loads the cookies in bulk. According to CloudSEK, the operators then use refresh tokens to stay in past the 1 to 24 hour cookie lifetime. Refresh tokens often last 90 days on a sliding window.

Two more details make the usual detections less reliable:

1. Residential proxies in 69 countries, chosen to match the victim's country. If your Conditional Access or impossible-travel alerts depend on "this sign-in came from somewhere odd", they'll see a local residential IP and let it through.
2. Anti-bot filtering through ipapi.is, which blocks datacenter, VPN and proxy visitors. CloudSEK's researchers could only reach the panel from a residential IP. Your email gateway's link sandbox, which runs from a datacenter, probably sees a blank page.

None of that is new on its own. The three injected scripts are where BigBear goes further.

Injection one: turning passkeys off

The first script sets PublicKeyCredential to undefined and patches navigator.credentials.get and navigator.credentials.create to reject any publicKey request. From the victim's side, the browser just looks like it doesn't support passkeys. Microsoft's sign-in page offers the next method on the list, which is usually push, TOTP or SMS, and all of those can be relayed.

This is the most encouraging thing in the report, even if it doesn't look that way. The operator had to build a downgrade because FIDO2 beats their proxy. WebAuthn binds the credential to the origin, so a passkey created for login.microsoftonline.com won't sign a challenge for a lookalike domain. The attacker can't relay it. All they can do is hope you have a fallback.

So here's my first strong opinion: if your users can register a passkey but can still fall back to push, you don't have phishing-resistant MFA. You have phishing-resistant MFA that attackers can switch off. Akshat Tyagi of HFS Research said the same thing to CSO: require passkeys rather than simply offering them. In Entra terms, that means a Conditional Access authentication strength that only accepts phishing-resistant methods, applied to the accounts that matter first. Start with your IT staff and anyone who can reach an RMM console.

Injection two: the canary killer

This is the one I'd print and pin on the SOC wall.

Over the last few years, a popular low-cost trick for catching AiTM proxies has been to put a canary in your Entra sign-in page's company branding. You add a CSS background image that loads from a canary URL, and the canary only fires when the Referer isn't login.microsoftonline.com. When a proxy serves your branded page from its own domain, the image loads from there and you get an alert. It's clever, it's free, and it has caught plenty of Evilginx deployments.

BigBear's second injection is built to stop it. It wraps fetch and XMLHttpRequest, drops anything that matches the blocklist, and watches the page for image beacons so it can delete them before they load. The same filter also drops Microsoft's own client telemetry (events.data.microsoft.com, OneCollector), which is the signal Microsoft could use to spot a sign-in page being served from somewhere it shouldn't be.

I need to be straight here, because this blog tends to be enthusiastic about tripwires. Canaries placed on the phishing page itself are weaker against this kit than they were a year ago. A beacon that depends on the victim's browser loading your resource can be removed by anyone who controls the page, and an AiTM proxy controls the page completely. The blocklist matches on hostname strings, so a canary on a custom domain that isn't in the list might still fire. I wouldn't bet a detection program on the attacker's list staying short, though.

The second lesson in this injection is the one to hold onto. The blocklist runs in the victim's browser, during sign-in. It stops protecting the attacker once the session cookie leaves for the replay engine. Everything after that runs on the attacker's infrastructure and inside your tenant, where their JavaScript does nothing.

The kit shows that canaries worked on BigBear's operators and irritated them enough to write code. What it doesn't show is any way to filter a canary it never gets to render.

Injection three: Keep Me Signed In, clicked for you

The third script checks the #KmsiCheckboxField box and clicks idSIButton9 800 milliseconds later. "Stay signed in?" gets answered yes before the victim has read the question. A persistent session cookie is worth far more to a replay engine than a session cookie, and it's what makes the refresh-token strategy work.

For detection, this shows up as a pattern. Look for sign-ins where KMSI was accepted, from a residential ISP the user has never used, followed within minutes by the same session appearing from a different IP. The detail that decides it is the user agent on the replayed session, not the location, since BigBear has the location covered. CloudSEK also notes that device compliance is often skipped on these sessions, so a Conditional Access policy that requires a compliant or hybrid-joined device will block the replay even with a valid cookie. That control does more against BigBear than any geo rule.

Where to put tripwires after the login

Take the three injections together and you can see the attacker's plan. Get past MFA, hide from Microsoft and from canaries during sign-in, and make the session last. Then leave. The next attacker action, in the replay engine, happens somewhere the kit doesn't control.

That's where deception still pays off, and it's roughly where Mine2's approach places it. Here's where I'd put tripwires, based on what BigBear's affiliates do with a session:

The mailbox. CloudSEK's post-compromise notes list mailbox access, inbox-rule creation (MITRE T1098) and OAuth grant enumeration. An attacker with an MSP engineer's Outlook session searches for "password", "VPN", "RMM", "admin". Plant a message that answers that search: a believable handoff note with a decoy RMM login or a decoy break-glass account. Nobody legitimate uses those credentials, so any use is an attacker.

OneDrive and SharePoint. A document called something like Customer-Tenant-Access-Q3.xlsx, containing honeytoken service principal secrets or decoy admin accounts for tenants that don't exist. When someone authenticates with those secrets, it happens from the attacker's own tooling, and there's no injected script in the path to filter it.

The network behind the SaaS session. Affiliates who get as far as a VPN or RMM credential end up at your perimeter. Decoy services such as MineField's fake RDP, SSH and SMB listeners sit where a scan will hit them, and nothing legitimate ever connects to them.

What these have in common: the canary goes off when the attacker uses the stolen data, not when the victim loads a page. BigBear can remove a beacon from HTML it's relaying. It can't stop its own replay engine or its affiliates from trying the credentials they find, because trying them is the reason they bought the service.

One edge case we've hit in deployments: resist making the decoy too juicy. A mailbox containing a document titled "ALL ADMIN PASSWORDS" looks planted to anyone who has done this before. The decoys that fire are dull. A forwarded ticket from six weeks ago with a service account in the third paragraph. A spreadsheet tab called "old - do not use". Attackers skim for credentials, not for stories.

What to do this week

If you run Microsoft 365, and especially if you're an MSP or IT services firm, here's a short list based on what CloudSEK found:

1. Pull CloudSEK's IOCs (phishing domains, Vultr IPs, x-evg-* headers, evginx_* and bigbear_* cookies) into your proxy and SIEM, and search back to June. The five Sigma rules in the report, including one for Telegram sendDocument calls carrying cookie data, are ready to deploy.
2. Hunt for replayed sessions. Look for one session ID seen from two different IPs within a short window, and for KMSI accepts from residential ISPs followed by OAuth consents or new inbox rules.
3. Make phishing-resistant MFA mandatory for privileged and IT staff. Offering it isn't enough. Injection one exists because of that gap.
4. Require compliant devices for Microsoft 365 access from admin accounts. A replayed cookie from an unmanaged machine should fail.
5. When you find a hit, treat it as a live session, not a password reset. Keith Prabhu of Confidis told CSO to treat it "as an active session compromise, not merely a stolen-password incident." Revoke refresh tokens, force re-authentication, then review mailbox rules, OAuth grants and new MFA methods. We walked through what attackers do with a stolen session in our breakdown of AI tool session cookie theft.
6. Keep your branding canary, but don't depend on it. It still catches lazier kits. Just don't let it be your only AiTM detection now that one kit ships with a filter for it.

The trend behind it

Last month we wrote about RecruitTrap bringing back browser-in-the-browser phishing and about TheHatman selling Entra directory dumps obtained through password spraying and MFA fatigue. BigBear belongs with those. The attacks aren't getting cleverer about Microsoft's cryptography. They're getting better at dealing with the controls that sit around the login: geo rules, link sandboxes, passkey prompts, and now canary beacons.

That's a reasonable sign that those controls were working. It also means detection has to move to places a phishing page can't reach. The login page belongs to whoever is proxying it. Your mailbox contents, your file shares, your decoy accounts and your perimeter services still belong to you, and an attacker who reaches them with a stolen session has no script running to filter what fires.

If you want to see where a tripwire would have caught a BigBear-style session in your tenant, and what the alert looks like when it fires, book a Mine2 demo and we'll walk through it using your own Microsoft 365 layout.