Forg365 PhaaS Chains AiTM + Device-Code + AI Lures at M365

Nothing about Forg365 is technically new. AiTM proxying has been the standard bypass for token-bound MFA since Evilginx made it turnkey. OAuth 2.0 device-code phishing is the identity abuse Microsoft has been telling tenants to lock down for years. AI-generated lures have been in the noisier PhaaS kits since last year. What ZeroBEC’s research, reported by BleepingComputer on 2026-07-09 describes is those three things bundled into one dashboard, sold as a service, and shipped with a browser extension that keeps the stolen session alive.

That’s the news, and that’s the reason to care. When the barrier to running an AiTM-plus-device-code campaign against Microsoft 365 tenants drops to “buy a subscription and paste a target list,” the volume goes up. That is the trend line to plan against, not any one feature of the kit.

What ZeroBEC actually found

Forg365 is a phishing-as-a-service platform focused exclusively on Microsoft 365 accounts. ZeroBEC noted tradecraft overlap with the earlier Kali365 and Sneaky2FA kits but explicitly could not attribute Forg365 to either operator. Its own operators remain unidentified.

The campaign side runs on familiar plumbing — Amazon SES for delivery, Cloudflare Pages for landing sites, Gophish for orchestration — behind AntiBot filtering (sandbox detection, VPN redirects) to keep researchers off the real payload. The dashboard integrates AI-assisted lure generation directly, which ZeroBEC calls out as the piece that “reduces the cost of developing custom phishing content.”

Two capture paths run in parallel:

• AiTM. A reverse proxy sits between the victim and login.microsoftonline.com, harvesting session cookies after the real Microsoft MFA prompt is completed. Same class of attack as the device-code overlap Deballs Insight described in the Storm-2372 cluster last week, packaged as SaaS.
• Device code. The victim is walked to a legitimate-looking Microsoft device authorization page and enters a code that grants an attacker-controlled device the OAuth token — the same underlying identity abuse Talos flagged in the ArToken/EvilTokens research earlier this month.

Post-compromise, a Chromium extension called ForgCookie (Chrome, Edge, and Brave) sits in the operator’s own browser and, per ZeroBEC, automatically refreshes Microsoft SSO cookies so the operator does not have to re-phish when the session expires. Combined with keyword-driven mailbox monitoring and a token/cookie management UI, the operator gets a durable, low-touch foothold from a single successful capture.

Here’s what to actually do

None of this changes what the defense looks like — it just raises the stakes on parts of it that have been on your queue.

1. Kill unrestricted device-code flow. Restrict OAuth 2.0 device-code authentication via Entra Conditional Access — allow it only for the specific clients that genuinely require it (typically legacy CLI tools, shared-device kiosks), block the rest. This is the single biggest lever against Forg365’s device-code path, and Microsoft has documented the Conditional Access policy for years. If the setting is still open in your tenant, close it this week.
2. Alert on device-code events in Entra sign-in logs. The authenticationProtocol: deviceCode field is right there. Flag every grant that is not tied to a known, sanctioned client. Once the Conditional Access rule above is in place the noise drops fast.
3. Enforce token protection where AiTM is the concern. For the AiTM half, session-token proxying still bypasses classic MFA. Phish-resistant methods (FIDO2, Windows Hello for Business, passkeys) and the token-protection Conditional Access binding are the ones that actually hold up. Legacy TOTP does not. If you are still rolling passkeys out incrementally, prioritize the accounts with Global Admin, Exchange Admin, and mail flow rules first — the same principal set the Entra passkey-enrollment vishing crew UNC-066 is chasing right now.
4. Have the revocation runbook cocked. The ForgCookie piece is the reminder that a stolen M365 session is durable now, not ephemeral — the extension is designed around that. When a compromise is confirmed, revoke sessions and rotate refresh tokens (Graph’s revokeSignInSessions or Revoke-AzureADUserAllRefreshToken for older tenants), audit mailbox rules, list newly registered devices, and enumerate consented OAuth grants. All four. Not one.

Priority

Device-code Conditional Access first. It closes the higher-leverage of the two paths Forg365 is selling, it is a one-shot policy change with a small compatibility surface, and every day the setting stays open is a day a low-cost PhaaS subscriber can walk in through it. AiTM hardening — phish-resistant credentials, token protection — is the longer program and worth continuing, but it is not the same flip-a-switch-this- afternoon fix.

The honest read on this class of report: the individual kits will change names and change operators. The mechanics — bypass MFA via session proxy, bypass tenant intent via device-code grant, decorate the lure with AI — do not. Fix the tenant so both paths cost something, and the next kit that shows up in ZeroBEC’s write-up is somebody else’s problem.

Sources

• BleepingComputer — New Forg365 phishing platform uses AI to target Microsoft 365 accounts (Bill Toulas, 2026-07-09)
• Microsoft Learn — Conditional Access: Filter for device code flow
• Microsoft Learn — Conditional Access token protection