Breach · Phishing

Forg365: A New Phishing-as-a-Service Platform Using AI to Compromise Microsoft 365 Accounts

July 10, 2026 · 6 min read

Phishing-as-a-service platforms have been around long enough that most security teams have a general mental model of how they work: a criminal rents infrastructure, fires off credential-harvesting emails, and waits for victims to type their passwords into a fake login page. Forg365, documented by researchers at ZeroBEC and reported by BleepingComputer in July 2026, does not fit that model anymore. It combines adversary-in-the-middle proxying, device-code flow abuse, and AI-generated lure content into a single operator dashboard, and it ships with a browser extension specifically designed to keep that access alive long after the initial compromise. The controls that stopped yesterday's phishing campaigns are increasingly insufficient against tools like this, and the gap is worth understanding in concrete terms.

What actually happened

ZeroBEC's investigation started with phishing emails that impersonated business documents, formatted to look like correspondence from a trusted service. Those emails were delivered through Amazon SES, with message bodies that included images and tracking resources hosted on SendGrid, which are two legitimate platforms that help the messages clear standard reputation filters. When researchers followed the trail back to the infrastructure, they found a full-featured PhaaS operation with a polished operator dashboard covering campaign creation, phishing link management, OAuth application and SMTP profile configuration, token management, and AI-assisted email content generation.

Forg365 offers operators two distinct attack paths. The first is adversary-in-the-middle phishing, where the platform operates a proxy that sits between the victim and Microsoft's actual authentication infrastructure. The victim interacts with what appears to be a real Microsoft login, the proxy relays requests and responses in real time, and in the process it captures the authenticated session cookies that Microsoft issues after login. Because the authentication actually completes against Microsoft, MFA codes entered by the victim are consumed by the real session, and the resulting cookies are handed to the attacker. Standard time-based one-time password MFA provides no protection here because the victim's own device is doing the authenticating.

The second path abuses Microsoft's legitimate OAuth 2.0 device code flow. In normal use, this flow lets a device with limited input capabilities, like a smart TV, display a short code that a user enters on another device to authorize access. Forg365 weaponizes this by showing victims a Microsoft-style verification page and walking them through authorizing an attacker-controlled device. The victim sees what looks like a standard Microsoft prompt and completes the steps, at which point the attacker receives a persistent access token tied to the victim's account.

For persistence, Forg365 includes a browser extension called ForgCookie, compatible with Chrome, Edge, and Brave. Once installed, it silently triggers OAuth flows in the background to capture fresh session cookies, meaning that even if an organization resets a compromised account's password, the extension can generate new valid tokens without any additional interaction from the victim. On the evasion side, Forg365 uses AES-encrypted redirectors, bot detection logic, debugger traps, sandbox environment checks, and polymorphic code to make it harder for researchers to reach the admin panel. Landing pages are hosted on Cloudflare Pages, and campaign management runs through Gophish. ZeroBEC noted feature overlap with other PhaaS platforms including Kali365 and Sneaky2FA, though researchers could not establish a direct operational connection between them.

"AI reduces the cost of developing custom phishing content, but it also reduces the cost of building custom PhaaS platforms." — ZeroBEC

Why this should matter to you even if you don’t run Microsoft 365

If your organization runs Microsoft 365, this matters directly. If you run any other identity provider, it still matters because the architectural patterns here are not specific to Microsoft. AiTM proxying works against any service that issues session cookies after authentication. Device-code flow abuse works against any OAuth 2.0 implementation that supports the device authorization grant. The Microsoft-specific features in Forg365 reflect market demand, since Microsoft 365 is the dominant enterprise productivity platform, and that is where the PhaaS operators are focusing their tooling development.

The AI angle deserves attention beyond the marketing noise around it. The ZeroBEC quote above captures the practical reality: AI in a PhaaS platform is not about generating impressive prose. It is about reducing the per-campaign labor cost enough that operators can run more targeted, more customized campaigns at the same price point. An operator who previously sent generic lures to thousands of accounts can now generate role-specific, context-appropriate content for a much smaller and higher-value target list, and do it faster. That changes the economics of spear-phishing in a way that makes previously expensive attack patterns accessible to lower-tier criminal operators.

The ForgCookie persistence mechanism is the piece I think gets underweighted in most discussions of phishing. Organizations tend to focus heavily on the initial compromise event, and for good reason, but a browser extension that silently refreshes session tokens turns a single successful phish into a long-duration access problem. Detection and response timelines that are adequate for credential-based attacks may be entirely inadequate when the attacker has a mechanism that regenerates valid access every time the victim opens their browser. This is particularly relevant for incident response playbooks that rely on password resets as a primary remediation step.

The control that would have blunted it

The control category here is MFA, but the specific requirement is phishing-resistant MFA, and that distinction carries real operational weight. TOTP-based MFA, the kind where you open an authenticator app and type a six-digit code, is defeated by both attack paths in Forg365. The AiTM proxy consumes the code in real time as part of the proxied authentication, and the device-code flow bypasses the password and TOTP step entirely by abusing a legitimate OAuth grant type. Cyber insurers increasingly require phishing-resistant MFA, specifically FIDO2 or passkey-based authentication, because these methods bind the authentication credential to the legitimate origin domain at the hardware or platform level. A FIDO2 authenticator will refuse to respond to an AiTM proxy's authentication request because the origin presented does not match the registered relying party.

Deploying FIDO2 across an enterprise is not a weekend project. Hardware security keys require procurement, distribution, and user training. Platform authenticators tied to device TPMs require a managed device fleet and enrollment processes. There are accessibility considerations for users who cannot use certain form factors. And there are legacy systems, service accounts, and integration points that may not support modern authentication at all, which means you end up with a segmented environment where some accounts have strong protection and others are still exposed. Mapping that residual exposure honestly is more useful than claiming blanket phishing-resistant MFA coverage.

Beyond MFA method, the ForgCookie persistence mechanism points to two additional controls worth considering. First, Conditional Access policies that evaluate device compliance and token binding at each request can limit what an attacker can do with a stolen session cookie, since a token issued to a managed device may not be usable from an unmanaged one. Second, monitoring for anomalous OAuth application grants and browser extension installations on managed devices gives you a detection layer that operates independently of whether the initial phish succeeded. Neither of these is a complete answer, and both require ongoing maintenance as the threat landscape shifts, but they address the specific persistence technique Forg365 relies on in ways that a password reset alone does not.

From an insurance perspective, carriers are asking specifically about MFA coverage rates, authentication methods in use, and whether privileged accounts are protected with stronger controls than standard user accounts. A gap assessment that documents where phishing-resistant MFA is deployed, where it is not, and what compensating controls exist in the gaps is the kind of artifact that supports both underwriting conversations and post-incident response.

Strondex SME provides continuous visibility into authentication configurations, MFA coverage gaps, and OAuth application permissions across Microsoft 365 environments. Learn more on the Strondex SME product page.