Identity Security & Authentication Market Intelligence — Weekly Brief

Week of 13 July 2026 | Compiled by Team Paringa

The assumption that MFA equals protection is collapsing in real time. This week produced two major research disclosures documenting how attackers are building industrialised platforms to bypass every common MFA method — including FIDO2 — at scale, targeting Microsoft 365 with kits that cost less than a mid-range laptop.

SECTION 1 — What Happened This Week

🔴 Forg365: AI-Assisted Microsoft 365 Phishing Kit at $400/Month Combines Device Code and AiTM in One Platform

A new phishing-as-a-service operation called Forg365, documented this week by ZeroBAC, represents a significant maturation in the commercial attack toolkit market. Distributed via Telegram at $400/month (or $3,800 annually), Forg365 combines device code phishing, adversary-in-the-middle session theft, AI-assisted lure generation, antibot evasion, and post-compromise mailbox operations into a single operator panel — lowering the skill threshold for Microsoft 365 account takeover to near zero.

The platform's architecture is notable precisely because it attacks multiple layers simultaneously. On the delivery side, it routes phishing emails through legitimate infrastructure — Amazon SES and Twilio SendGrid — so messages blend into normal enterprise mail flows. The email bodies contain SendGrid-hosted images, making them indistinguishable from legitimate vendor communications at the transport layer. On the evasion side, the platform serves decoy content to VPN connections and known scanner IPs, meaning conventional security testing and URL reputation checks will return false negatives.

Once a target engages, Forg365 offers two distinct attack paths. The AiTM path proxies the live Microsoft login session, intercepting the authenticated session cookie before it is delivered to the victim. The device code path is structurally different and more dangerous for identity teams to defend against: it generates a genuine Microsoft device authentication code, wraps it in an Authenticator-branded lure page, and directs the victim to enter the code at the real `microsoft.com/devicelogin`. The victim completes genuine MFA on genuine Microsoft infrastructure. The attacker's backend polls the Microsoft token endpoint and harvests the resulting token the moment authentication succeeds. Microsoft receives a legitimate authentication event. The victim's MFA logs show a successful, unforced sign-in.

Post-compromise, Forg365 provides a browser extension called ForgCookie for Chromium-based browsers (Chrome, Edge, Brave) that continuously refreshes Microsoft session cookies, maintaining persistent access to compromised accounts without re-authenticating. The platform also enables AI-drafted response emails to be sent from compromised mailboxes to specific threads — enabling business email compromise at scale from a single harvested account.

Sources: The Hacker News — Forg365 PhaaS Targets Microsoft 365 with Device Code and AitM Session Theft | ZeroBAC Research

The device code attack path documented in Forg365 does not bypass MFA — it uses it. The victim completes real MFA on a real Microsoft page. There is no anomalous authentication event to alert on. This is the critical point for identity and security teams: a control model that depends on MFA completion as proof of legitimate access is structurally defeated by this technique. The question is not whether MFA was satisfied — it was. The question is whether a credential was ever issued at all. Authentication architectures that eliminate the credential entirely remove what the attacker is stealing, which is a fundamentally different posture from layering controls on top of a credential that can still be harvested.

🔴 Three Evilginx Operations Exposed — 218 Confirmed Corporate Accounts Captured, Sessions Kept Alive for Over a Year

French security firm Lexfo this week published a detailed analysis of three simultaneous Microsoft 365 phishing operations, uncovered after one operator left a Python web server with directory listing enabled on a live attack host. The exposed server at 185.163.204.7 in Budapest contained phishing configs, credential harvesting logs, RMM installers, and the operator's own Telegram session files — a complete operational picture of a running campaign.

From that single OPSEC lapse, Lexfo traced two additional operators through shared code repositories, revealing three separate campaigns using custom forks of the open-source Evilginx proxy. The three campaigns collectively captured 218 confirmed corporate accounts across a dozen countries between June 2025 and July 2026, with approximately 94% of victims being corporate rather than personal mailboxes. The largest operation had been running continuously for over a year.

The most technically significant finding concerns the third operation, run by an operator tracked as saroula01, which used Microsoft's OAuth device code flow exclusively — no AiTM proxy, no credential interception. The technique generates a real device code, presents it inside an Authenticator-themed lure, and directs the target to the genuine `microsoft.com/devicelogin`. When the victim authenticates and clears MFA, the attacker's backend polls the Microsoft token endpoint and takes the token. MFA is not bypassed; it is completed by the victim on real Microsoft infrastructure, authorising an attacker-controlled session.

Critically, saroula01's platform did not just harvest tokens — it kept them alive. Token files in the repository showed sessions with `autoRefresh` enabled, some refreshed up to 25 times. One captured session cookie had an expiration date of June 30, 2027 — a full year from now. A Conditional Access policy without Continuous Access Evaluation cannot revoke a session token once it has been issued; the attacker's session outlasts password resets.

The Lexfo report also found AI-assisted development across all three operations. Two operators had co-authored git commits with Claude models. A third left an `instructions.txt` that was a verbatim save of an AI coding session, documenting exactly how the URL-rewriting feature was built. None of the operators built the underlying Evilginx frameworks themselves — they cloned public repositories and used AI to build the custom tooling around them.

Sources: The Hacker News — Misconfigured Server Reveals Three Evilginx Phishing Operations Targeting Microsoft 365 | Lexfo CTI Report

The Lexfo disclosure makes a point that identity teams need to absorb carefully: FIDO2 and passkeys stop the AiTM proxy path — they do not stop device code abuse. These are two different attacks that need different defences. An organisation that deploys passkeys and marks the identity threat as resolved still has an open exposure if it has not blocked device code authentication flow in Conditional Access. Microsoft's own guidance is explicit: block device code flow wherever it is not genuinely needed (input-constrained hardware like Teams room devices). The practical reality is that most enterprises have not done this, and there is no automatic remediation — it requires a deliberate Conditional Access policy change.

🟡 M365 Phishing Ecosystem Expands: ARToken, EvilTokens, ConsentFix — Multiple Industrialised Kits in Active Circulation

Beyond Forg365, this week's research documented additional active phishing-as-a-service platforms targeting Microsoft 365. ARToken PhaaS, exposed as an affiliate of the EvilTokens platform, gives operators a toolkit designed to compromise Microsoft 365 through device code flows via legacy email aliases — routing phishing pages through Mailjet tracking links, compromised WordPress sites, and CAPTCHA interstitials before reaching the actual kit. Separately, Huntress documented ConsentFix and ClickFix attacks that steal Microsoft 365 tokens in seconds through fake OAuth consent prompts, bypassing MFA entirely at the session level.

The pattern across all of these platforms is consistent: attackers are targeting the session token, not the password. MFA protects the authentication event. It does not protect the resulting session. A stolen token grants persistent access — to email, SharePoint, OneDrive, and in some cases admin portals — without any further authentication required. Conventional enterprise security monitoring is tuned to detect credential abuse, not token replay from unexpected locations or suspicious device code grant events.

The commercial ecosystem supporting this is now mature: operators can rent infrastructure, purchase pre-built kits, buy lists of target email addresses, and use AI to generate convincing lures — all for a monthly fee competitive with enterprise SaaS tools.

Sources: BleepingComputer — ARToken PhaaS exposes EvilTokens' Microsoft 365 phishing toolkit | BleepingComputer — ConsentFix and ClickFix: How Microsoft 365 Accounts are Hijacked in 3 Seconds

The proliferation of commercial M365 phishing kits is not primarily a technology problem — it is a procurement signal. Every kit in this ecosystem monetises the same fundamental weakness: authentication depends on a credential or token that can be stolen or hijacked after the fact. The growth of this market reflects how much value remains in that attack surface. Identity teams should be auditing their Entra sign-in logs specifically for device code grant events and refresh-token chains from unfamiliar client IDs, particularly the Microsoft Office desktop client ID `d3590ed6-52b3-4102-aeff-aad2292ab01c`, which multiple kits abuse.

SECTION 2 — What Identity Teams Are Dealing With

The Two-Path Problem: Why Phishing-Resistant MFA Is Not a Complete Answer

The dominant enterprise response to phishing over the past two years has been the deployment of phishing-resistant MFA — FIDO2, passkeys, Windows Hello for Business, and Microsoft Entra's certificate-based authentication. The marketing framing from Microsoft and the broader identity industry presents this as the definitive defence against credential phishing. This week's research demonstrates why that framing is incomplete.

Phishing-resistant MFA — specifically FIDO2 and passkeys — does neutralise adversary-in-the-middle proxy attacks. The origin binding built into the WebAuthn protocol means that a credential signed for `login.microsoft.com` cannot be replayed by an Evilginx proxy sitting in between. For that attack path, phishing-resistant MFA works as advertised.

Device code phishing is mechanically different. It does not intercept the authentication event. It authorises an attacker-controlled session using a legitimate Microsoft authentication flow that the victim completes on genuine Microsoft infrastructure. No credential is phished. MFA is satisfied correctly. The FIDO2 key, if the organisation has one, is used against the real Microsoft sign-in page. What is harvested is the resulting token — which is valid, because the authentication was valid. Phishing-resistant MFA provides no protection against this attack path.

This creates a two-path exposure that requires two separate controls. The AiTM path is closed by phishing-resistant MFA. The device code path is closed by Conditional Access policy blocking device code flow. Most enterprise Microsoft 365 deployments have neither control fully implemented, and many that have deployed phishing-resistant MFA have not addressed device code authentication at all. As the Forg365 and Evilginx disclosures show, both attack paths are now available in commercial kits at low cost, operated by individuals with no specialist development skills.

Three Things Worth Watching Next Week

1. Microsoft response to device code flow abuse — The Hacker News contacted Microsoft for comment on the abuse of its device code authentication flow; Microsoft had not responded by publication time. Any policy changes or additional Conditional Access recommendations from Microsoft could shift how quickly enterprises implement blocking controls.

2. Further Forg365 campaign activity — Forg365 launched with infrastructure already in place and a commercial affiliate model. Expect to see campaign volume increase as more operators onboard. Email security teams should be tuning rules for the specific delivery indicators: SES and SendGrid infrastructure used for initial delivery, followed by redirect chains to Forg365-controlled domains.

3. Regulatory treatment of token-based access in post-breach disclosure — As session token theft becomes the dominant enterprise account compromise method, regulators and cyber insurers are likely to revisit how "unauthorised access" is defined. Organisations that were breached via device code phishing — with no failed authentication events in their logs — face difficult disclosure questions. Watch for NCSC or ICO guidance touching on this.

Questions about anything in this brief? hello@paringa.ai

Paringa partners with Symania to deliver phishing-resistant, credential-free authentication to enterprise clients. A model where no credential is ever issued is the only model where token theft is not the fallback attack. | 13 July 2026 | © Paringa Ltd