Researchers Document “Forg365,” a Phishing-as-a-Service Platform Targeting Microsoft 365

A newly named phishing-as-a-service platform puts Microsoft 365 identity back at the center of the week — and turns the defender conversation toward device-code restrictions, conditional access, and session monitoring.

SAN FRANCISCO, CALIFORNIA — Security researchers on or around July 13, 2026 documented a phishing-as-a-service platform, tracked as “Forg365,” that reporting says is built and marketed to target Microsoft 365 users by pairing device-code phishing with adversary-in-the-middle (AitM) session theft. The platform is described as a packaged offering — an operator dashboard that bundles account management, campaign delivery, and post-compromise access into a single subscription-style service — which lowers the effort required to run identity attacks against Microsoft 365 tenants.

For defenders, the notable element is not a new vulnerability but the further commoditization of methods the community has tracked for more than a year. The account, first detailed by The Hacker News and referenced in SentinelOne’s weekly roundup, frames Forg365 as a mature toolkit rather than a one-off campaign. That framing matters because it changes the defensive question from “how do we block one lure” to “how do we harden the Microsoft 365 identity surface against a repeatable, low-cost service that many operators can rent.” This piece stays strictly on the defender side of that line: what teams can detect, and what they can harden.

What Researchers Documented

According to reporting from The Hacker News, researchers documented a phishing-as-a-service platform, referred to as “Forg365,” that is marketed to target Microsoft 365 accounts. The platform is characterized as an end-to-end service: an operator-facing panel that packages campaign delivery, account and link management, and post-compromise handling into one product. Two capabilities are called out as central to how it is advertised — device-code phishing, which abuses a legitimate Microsoft authentication pathway, and adversary-in-the-middle (AitM) session theft, in which an authenticated session rather than a static password is the prize. The CyberSignal is deliberately not reproducing the operational sequence of either technique; what follows is the defender-relevant summary.

The reporting also describes two force-multipliers that raise the platform above a commodity kit. The first is AI-assisted lure generation, which lowers the cost and language barrier to producing convincing, tailored phishing content at volume — part of a broader trend The CyberSignal has tracked in coverage of AI-developed tooling used to bypass 2FA at scale. The second is anti-analysis behavior — evasion designed to frustrate automated inspection and to serve benign decoy content when it detects that it is being examined. Both features are significant to defenders because they degrade the reliability of the two cheapest detection strategies: static content signatures on the lure, and drive-by sandbox detonation of the link. Neither of those additions is a new attack class; the news is that they are now bundled and rented rather than hand-built.

What Forg365 does not appear to represent is a break in Microsoft’s security model. Device-code phishing and AitM both operate by convincing a legitimate user to complete a legitimate authentication, then capturing the resulting session — they are abuses of trust and workflow, not exploits of an unpatched flaw. That distinction is the through-line of this story: there is no CVE to apply here, and the defensive work sits in identity configuration, monitoring, and user-facing controls rather than in a patch cycle.

A Continuation of the Microsoft 365 Identity-Targeting Wave

Forg365 lands in the middle of a sustained run of Microsoft 365 identity attacks, and it reads as continuity rather than novelty. Only days earlier, The CyberSignal covered Okta’s warning about a vishing campaign targeting Microsoft 365 customers, in which attackers used phone-based social engineering to pry open the same identity surface Forg365 now packages into a self-serve product. The two stories describe different front doors — a live caller versus a rented platform — onto the same objective: a valid, authenticated Microsoft 365 session.

The device-code angle in particular echoes prior coverage. The CyberSignal has tracked the OAuth device-code variant of Tycoon2FA that turns Microsoft’s own login page against M365, which established the pattern Forg365 now productizes. Read alongside the Signal recovery-key phishing wave and a multi-vendor phishing cluster abusing the hospitality sector, the trend line is clear: adversaries are consolidating around session theft and legitimate-workflow abuse, and increasingly renting the tooling to do it. Forg365 is best understood as the packaging of a technique family, not the invention of one.

For security leaders, the practical takeaway from the continuity is that a lure-by-lure response will not keep pace. When the same objective is pursued through a caller one week and a subscription platform the next, the durable defense is at the identity layer that all of these approaches ultimately have to satisfy — which is where the remainder of this piece focuses.

Defender Posture for Microsoft 365 Customers

Because Forg365 targets identity workflows rather than a software flaw, the highest-leverage responses are configuration and monitoring changes that Microsoft 365 administrators can review now. The first is device-code flow restriction. The device-authorization grant exists for genuine input-constrained scenarios, but most enterprise user populations rarely need it; conditional access policies that block or tightly scope the device-code flow for standard users remove an entire branch of this attack surface without a patch. Reviewing whether device-code authentication is permitted by default, and for whom, is the single most direct hardening step this reporting points to.

The second is phishing-resistant multi-factor authentication. AitM session theft is specifically effective against one-time-code and push-based MFA because it targets the session established after the challenge rather than the challenge itself. Phishing-resistant factors bound to the origin — FIDO2 security keys and passkeys — raise the cost of this class of attack substantially, because the credential cannot be relayed through an intermediary the way a typed code can. Prioritizing phishing-resistant MFA for administrators and other high-value accounts is a proportionate response to a platform built around session capture.

The third is token and session monitoring paired with conditional access. Even where an authenticated session is stolen, defenders retain signal: sign-ins from anomalous locations or infrastructure, token use that does not match the enrolled device posture, and impossible-travel patterns are all detectable in Microsoft 365 sign-in and audit logs. Conditional access policies that enforce compliant-device or managed-network requirements, shorten session lifetimes for sensitive applications, and trigger re-authentication on risk are the controls that convert a stolen session from durable access into a narrow, observable window. None of these steps is new; the value of restating them is that Forg365 makes their absence more expensive.

A Detection-Engineering Review of the Published Indicators

For detection engineers, the arrival of a named, documented platform is an opportunity to move from generic phishing coverage to targeted analytics. The reported behaviors — device-code authentication events, session-token reuse, and lure delivery that leans on legitimate-looking infrastructure — map to concrete telemetry in Microsoft Entra ID sign-in logs, unified audit logs, and mail-flow data. Teams should treat the published account, together with the SentinelOne weekly roundup, as the starting point for a review of existing detections against this specific pattern rather than as a ready-made blocklist.

A useful review focuses on three questions. Do current analytics alert on successful device-code authentications for user populations that should not be using that flow? Do they correlate a new authenticated session with a change in device, network, or geography that would indicate the session did not originate with the legitimate user? And do mail and web controls account for the reported anti-analysis behavior, which is designed to show benign content to automated inspection — meaning detonation-only verdicts should not be trusted in isolation? Framing detection work around those questions turns Forg365’s documented tradecraft into testable coverage.

The evasion features argue for defense in depth rather than reliance on any single sensor. Because the platform reportedly serves decoy content when it senses scrutiny, identity-side detections — which observe the outcome of a successful phish rather than the lure itself — become the more reliable backstop. A detection strategy that assumes some lures will evade content and sandbox controls, and that instruments the post-authentication session accordingly, is the posture that best matches a threat built to defeat first-line inspection.

Scope and Impact

The measured read on scope is that it is not yet established. Reporting documents the existence and marketing of the Forg365 platform; it does not, at the time of writing, quantify how many Microsoft 365 tenants have been successfully compromised through it, how many operators have adopted it, or how long it has been in circulation. Those figures are open questions, and defenders should be wary of treating the platform’s advertised capabilities as evidence of confirmed mass impact. A capable toolkit lowers the barrier to attacks; it does not by itself demonstrate their realized scale.

What is assessable is the direction of the risk. The commoditization of Microsoft 365 session theft broadens the population of actors who can attempt it, which tends to increase attempt volume even if any individual operator is unremarkable. For organizations, the practical exposure is proportional to their identity posture rather than to the platform’s notoriety: tenants that permit unrestricted device-code authentication, rely solely on phishable MFA, and lack session-anomaly monitoring are more exposed to this category of tooling than those that have already tightened those controls. The impact story, in other words, is one each organization can partly measure for itself by auditing its own configuration.

It is also worth stating plainly what is not claimed. The CyberSignal has not verified any specific victim, tenant count, or operator identity, and does not attribute the platform to a known group. Any linkage between Forg365 and established PhaaS operations such as EvilProxy or ONNX is, at this stage, unconfirmed and should be treated as an open question rather than a finding.

Response and Attribution

Attribution for Forg365 is unresolved. The reporting documents a platform and its advertised capabilities without naming an operator, a hosting cluster, or a definitive link to a previously tracked crew. That is a normal posture for a freshly surfaced service, and it is a reason to focus response on posture rather than on chasing an actor. Whether the platform is run by a single operator or resold across an affiliate model, and whether it shares infrastructure or code lineage with other PhaaS offerings, are questions that may be answered as researchers publish further analysis.

On the vendor side, no formal Microsoft advisory tied specifically to Forg365 has been reported at the time of writing, and the absence of one is consistent with the nature of the threat: there is no product vulnerability for Microsoft to patch, and the relevant mitigations — conditional access, device-code restrictions, and phishing-resistant MFA — are existing platform features that customers configure. Defenders should not wait on an advisory that a workflow-abuse threat may never warrant; the response levers are already in their hands.

The open questions that will shape how this is ultimately assessed are concrete: the named operator, the realized number of affected Microsoft 365 tenants, whether Microsoft issues formal guidance, and any confirmed overlap with existing PhaaS operations. Until those are answered, the responsible framing is the one this coverage takes — a documented, commoditized threat to Microsoft 365 identity that calls for a posture review this week, reported without reconstructing the tradecraft that makes it work.

The CyberSignal Analysis

The reported facts above are drawn from the cited research and reporting; what follows is The CyberSignal’s editorial reading for defenders. None of the judgments below are new reported facts.

Signal 01 — Commoditization Is the Story, Not a New Exploit

The most important thing to hold onto about Forg365 is that it introduces no new vulnerability. Device-code phishing and AitM session theft are abuses of legitimate authentication workflows that defenders have tracked for well over a year; what changes here is that they are packaged, marketed, and rentable as a service. Our reading is that the correct mental model is a lowered barrier to entry, not a novel capability — and that the defensive implication is a broader population of attackers rather than a more sophisticated one.

That reframing should influence where teams spend effort. A platform that many operators can rent produces attempt volume, which rewards durable identity-layer controls over lure-specific blocking. We would treat the emergence of a named PhaaS platform as a prompt to audit configuration — device-code flow, MFA strength, session monitoring — rather than as a call to hunt a single campaign.

Signal 02 — Phishing-Resistant MFA Is the Control the Business Case Now Favors

AitM session theft is designed to defeat MFA that relies on a transmissible challenge, which is precisely why phishing-resistant factors keep surfacing as the answer. Our assessment is that Forg365 strengthens an already-strong business case: origin-bound credentials such as FIDO2 keys and passkeys raise the cost of this attack class enough to change an operator’s economics, especially for administrators and other high-value identities. The value of phishing-resistant MFA is no longer theoretical when the threat is a productized session-capture service.

The forward-looking read is that organizations still standardized on one-time-code or push MFA should treat this reporting as an accelerant for a rollout they likely already planned. The controls that bound a stolen session — short-lived tokens, conditional access on device and network posture, re-authentication on risk — compound the benefit, and none of them depend on a vendor patch.

Signal 03 — Detection Must Assume the Lure Will Slip Past First-Line Inspection

The reported anti-analysis behavior — serving benign decoy content when it senses scrutiny — is the detail we would put at the center of a detection review. Our interpretation is that content signatures and sandbox detonation, the two cheapest first-line controls, are exactly what this platform is built to evade, which means a detection strategy resting on them will underperform. The reliable backstop is identity-side telemetry that observes the outcome of a successful phish rather than the lure itself.

For detection engineering teams, the actionable posture is to instrument the post-authentication session: alert on device-code authentications for populations that should not use them, correlate new sessions with device and geography changes, and avoid trusting detonation-only verdicts. Defense in depth is not a platitude here; it is the direct consequence of a threat engineered to defeat the outer layer of inspection.

Sources