The phishing kit with its own browser extension: how to fully evict an attacker after a Microsoft 365 phish

You got phished. You noticed, you reported it, and you reset your password and re-enrolled MFA. From where you sit, the attacker is gone.

But nobody checked whether the attacker still holds token material — or looked at the browser's extension list. Attackers now use browser extensions on both sides of that line.

This summer, researchers documented a phishing kit that ships its own browser extension as a persistence layer. It isn't installed on your machine. It runs in the attacker's browser, turning stolen token material into fresh Microsoft 365 sessions, and a password reset alone may not stop it. Let's unpack how that works, what actually cuts it off, and how to make sure your own browser doesn't have a tenant you didn't invite either.

Forg365: a phishing kit that ships its own extension

In July 2026, BleepingComputer reported on research from the ZeroBEC team into Forg365, a phishing-as-a-service platform targeting Microsoft 365 accounts. The kit combines three things you've probably seen in the threat reports this year: adversary-in-the-middle (AiTM) proxying that captures your session while you type your real credentials into a fake login page, OAuth 2.0 device-code phishing, and AI-generated lures.

The part that caught my attention is the fourth ingredient. According to ZeroBEC's findings, Forg365 also provides the operator with a browser extension that keeps access to the victim's linked Microsoft services — without re-authenticating. ZeroBEC's own write-up calls it ForgCookie, and it runs in the operator's browser, not the victim's: it injects a generated Microsoft refresh-token cookie, triggers a silent sign-in, and captures fresh session cookies, over and over. ZeroBEC tells defenders to treat it as "operator-side tradecraft, not a victim endpoint artifact."

The kit is also built to frustrate analysis. ZeroBEC describes an "AntiBot" feature boasting "AES-encrypted redirectors, bot detection, debugger traps, sandbox checks, and polymorphic code," with VPN visitors quietly redirected to innocuous content. Per the same research, the operator's infrastructure leans on boring, reputable services — Amazon SES for phishing email delivery, Cloudflare Pages for landing pages, Gophish for campaign management — which helps it slip past reputation filters. (That's a statement about attacker preferences, not about those services.)

And because Forg365 is sold as a service, this capability now belongs to anyone with a budget, not just to skilled operators. ZeroBEC noted feature overlap with other kits like Kali365 and Sneaky2FA, though the researchers could not establish a connection between them.

Why a password reset alone doesn't evict Forg365

Here's the mental model a lot of people still carry: a compromise is a password problem. Stolen password → reset it. Done.

Forg365's extension isn't on your machine at all. It's the attacker's tool for turning stolen token material into working browser sessions, and it survives the steps people usually stop at:

• Password reset invalidates the old password, but in Microsoft Entra ID a user's own password change leaves non-password-based tokens alive. ZeroBEC saw Forg365 sessions "survive password resets because refresh-token material is being replayed elsewhere."
• MFA re-enrollment protects future interactive logins, but ForgCookie never logs in interactively: it refreshes silently with token material the attacker already holds.
• Session revocation is the step that actually cuts it off: revoke the user's refresh tokens (in Entra, Revoke sessions) and disable any device registered during the attack. ZeroBEC's advice is the same: revoke "at the identity layer rather than relying on victim-side extension inventory."

I wrote about how the cookie-theft era is being squeezed by device-bound session credentials — hardware-bound cookies make stolen sessions much harder to replay from another machine. Forg365 shows the other route: keep minting new sessions from token material instead of replaying old cookies. Malicious extensions that do get installed in a victim's browser are a separate, real problem — the SNOWBELT and stealer cases below — and no account-side step removes those. That's why the checklist covers both the identity and the browser.

The device-code half of Forg365 deserves a quick explanation too, because it leaves a different kind of footprint. In a device-code flow, the attacker starts a legitimate Microsoft login on their device, which produces a short code and a URL. The lure gets you to enter that code while signed in as yourself — you've just approved a real Microsoft prompt, so nothing looks phishing-y. The attacker's device walks away with tokens. In Forg365's case, ZeroBEC saw the flow run through the legitimate Microsoft Authentication Broker and register devices named Forg365-… in the victim's tenant. A first-party Microsoft sign-in like that won't necessarily show up as a third-party app grant, so cleanup has to cover sign-ins, devices and tokens, not just app consents.

This is a trend, not one kit

If Forg365 were a one-off, I'd file this under curiosity. It isn't. Push Security's open-source Browser & Identity Attacks Matrix, published in May 2026, maps browser and identity attack techniques, and the numbers it aggregates (citing Microsoft and CrowdStrike data) point the same direction:

• ClickFix — the fake-CAPTCHA / "paste this command to prove you're human" trick — accounted for 47% of initial access attacks observed by Microsoft in 2025, and CrowdStrike documented a 563% increase in fake CAPTCHA lures.
• Device-code phishing is up 37.5x since the start of 2026, with at least 12 distinct attack kits offering it.
• At least 250 confirmed malicious browser extensions were publicly disclosed in 2026, affecting roughly 1.75 million users — plus a further 370+ extensions engaged in undisclosed or policy-disclosed data harvesting, affecting another 44 million users.
• CrowdStrike's average e-crime "breakout time" is 29 minutes from initial access, fastest observed: 27 seconds. Whatever the attacker sets up in that first window is what your cleanup has to find.

Extensions aren't just the payload in this landscape — they're also the target and the foothold. The Register reported on a macOS ClickFix campaign this April whose AppleScript stealer harvested data from 14 browsers, 16 crypto wallets, and 200+ browser extensions — your wallet extension's local data is loot on its own now. And at the enterprise end of the spectrum, Google's threat intel team documented UNC6692's SNOWBELT backdoor, a malicious extension sideloaded into headless Edge that ended in full domain compromise — I broke that one down in my SNOWBELT piece.

Different scales, one lesson: extensions sit on both sides of the attack — the operator's tool for keeping sessions alive, and the foothold planted in the victim's browser. Remediation that touches only the password misses both.

How to fully evict an attacker: the post-phishing browser checklist

If you (or someone in your team) fell for a phishing page — especially one impersonating Microsoft, Google, or your bank — treat account recovery as half the job. Here's the other half.

1. Do the account steps, then assume they weren't enough

Reset the password, revoke sessions and refresh tokens, re-enroll MFA. For a work account, ask IT to use Entra's Revoke sessions and to disable any device registered during the attack. Against Forg365, the token and device steps are what cut access; a password reset on its own may not.

2. Audit every extension, in every browser, in every profile

Open chrome://extensions (or edge://extensions, or about:addons in Firefox) and go through the list honestly. Remove anything you don't recognize, anything you don't remember installing, and anything you installed around the time of the incident. Pay attention to extensions that appeared after clicking a link or running an "update" or a pasted command.

Two traps here. First, profiles: if you use more than one Chrome/Edge profile, audit each one — extensions are per-profile. Second, forced installs: if an extension has no Remove button, check chrome://policy (edge://policy in Edge, about:policies in Firefox) — an ExtensionInstallForcelist entry, or ExtensionSettings with force_installed, means something deployed it via policy, which in a corporate environment is an IT question and on a personal machine is a red-flag-on-red-flag situation.

3. Audit what the account granted and registered, not just what's installed

Device-code phishing can leave a registered device or an ordinary-looking app grant behind. In the affected account, review devices and app access (for a work Microsoft 365 account: myaccount.microsoft.com → Devices, plus your recent sign-ins — and ask IT to review OAuth grants and inbox rules; for Google: Security → "Your connections to third-party apps & services") and remove anything you don't recognize or don't remember approving. Then check recent sign-in activity for logins from devices and locations that aren't yours — that's how you spot whether stolen access is being used.

4. Check sync before you clean, or your cleanup won't stick

Browser sync can carry an extension to every device signed in to the same profile. Before cleaning, check which devices sync with the affected profile. Clean every one of them, or pause sync during cleanup. If you're seriously compromised — you typed credentials into something like Forg365, or IT confirmed account takeover — my honest advice is don't clean, replace: create a fresh browser profile (or reinstall the browser) and sign back in. Malware that installs an extension can also register native messaging hosts and other artifacts that survive uninstalling it; I explained what those are in my native messaging breakdown.

5. Make the check continuous, not a one-time panic

Extension footholds last because nobody looks at the extension list between incidents. So look at it regularly. For the extensions you installed from a store, Extenshi's Guard cross-checks them against our catalog of scanned extensions and flags the ones worth a second look — npx @extenshi/guard scan (needs a free account; npx @extenshi/guard list shows your local inventory without one). Extensions loaded from a local folder in developer mode are listed but not analyzed — that's a manual review. Before you install anything new, check it first — one store URL, one report: safety score, permissions, what the extension actually touches.

If you're doing this for a whole team rather than a single browser, the process is heavier — forced-install policies, fleet-wide extension inventories, C2 blocking — and I walked through that in the enterprise incident-response playbook.

The takeaway

A password reset is where cleanup starts, not where it ends. Forg365 keeps stolen sessions alive from the attacker's own browser until someone revokes the tokens and devices behind them — while campaigns like SNOWBELT plant extensions inside the victim's browser, where no account step reaches.

After any phishing incident, the browser profile is part of the blast radius. Revoke the tokens, audit the devices and grants, audit the extensions, check the sync, and when in doubt, start from a fresh profile. Five extra minutes now beats discovering the tenant three months later, reading your email over your shoulder.

Scan the extensions you installed from a store with Guard → (docs.extenshi.io/extensions/guard) — and browse the Extenshi catalog to see the security report for any extension before you install it.

Sources

• Inside Forg365: A Telegram-Distributed Sneaky 2FA-Style PhaaS Targeting Microsoft 365 — ZeroBEC, July 9, 2026 (primary research)
• New Forg365 phishing platform uses AI to target Microsoft 365 accounts — BleepingComputer, July 2026 (reporting ZeroBEC research)
• Introducing the Browser & Identity Attacks Matrix — Push Security, May 2026 (aggregating Microsoft and CrowdStrike data)
• macOS ClickFix attacks deliver AppleScript stealers — The Register, April 2026 (reporting Netskope research)
• UNC6692 social engineering and custom malware — Google Threat Intelligence Group
• Refresh tokens in the Microsoft identity platform and Revoke user access in Microsoft Entra ID — Microsoft Learn

---

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].