Highlights
The login page is real: device-code phishing makes the code, not the site, the trap.
$400 a month rents the full attack: AI lures, session theft, and evasion included.
AI lures convert 4.5x better: Microsoft measured 54% click-through versus 12% for manual phishing.
Forg365 phishes you on Microsoft's real login page. That should change how you train.
The unsettling detail in the Forg365 reporting isn't the AI. It's that the victim never sees a fake page.
In the kit's device-code branch, the target gets an email, opens a Microsoft-styled prompt, and completes a sign-in on Microsoft's genuine authentication flow. Real domain, real branding, real TLS. According to researchers at ZeroBEC, whose findings were covered by The Hacker News and BleepingComputer, the code the victim enters authorizes a session controlled by the attacker. Every visual cue we've spent a decade telling employees to check ("look at the URL, look for the padlock") checks out perfectly, because the page is legitimate. The deception is about what the code represents, not where it lives.
Forg365 itself is a subscription. It's sold through Telegram at $400 a month or $3,800 a year, with a free trial, support, and onboarding handled in-channel like any SaaS product. The operator panel bundles the device-code flow, adversary-in-the-middle session theft, anti-bot cloaking, AI-generated lures, and post-compromise mailbox tooling. Buying in requires a Telegram account and a credit card's worth of crypto. That's the whole barrier to entry.
How the two attack branches actually work
It's worth being precise, because the two branches fail differently and need different defenses.
Device-code phishing exploits a legitimate Microsoft authentication flow designed for devices without keyboards, such as smart TVs and conference room hardware. The attacker initiates the flow, obtains a short code, and socially engineers the victim into entering it on Microsoft's real sign-in page. The victim authenticates themselves correctly. Microsoft issues valid tokens correctly. The session still belongs to the attacker, because the code bound the sign-in to the attacker's device. No credential is stolen, so there's nothing for a password manager or a leaked-credential monitor to catch.
Adversary-in-the-middle is the more familiar branch. A proxy sits between the victim and Microsoft's real authentication service, routing traffic and capturing session cookies along the way. The victim completes MFA, and that's precisely the point: the attacker doesn't need the second factor; they need the session that exists after it. Per BleepingComputer, Forg365 even ships a browser extension, ForgCookie, that silently refreshes stolen Microsoft SSO cookies so access persists without the victim ever re-authenticating.
The kit wraps both in evasion: VPN and scanner traffic gets redirected to harmless decoy content, and lures ride legitimate delivery infrastructure like Amazon SES and Cloudflare Pages so they blend into normal business traffic.
Then AI does what AI does to economics. The panel generates lures (fake invoices, voicemails, document shares) tailored to the target from a prompt, in fluent corporate English, at volume. The personalization that used to be reserved for executive targets now costs nothing per victim.
The numbers behind that shift are stark. Microsoft's 2025 Digital Defense Report measured a 54% click-through rate for AI-automated phishing against 12% for traditionally written attempts, a 4.5x effectiveness gap the company says can make campaigns up to 50 times more profitable. And SlashNext's State of Phishing research pegs the increase in phishing volume since ChatGPT launched at over 4,000%. Better lures, at higher volume, now rentable by the month. That's the market Forg365 was built for.
The honest part: training alone doesn't fix this
We build security awareness and simulation software, so you'd expect us to say the answer is training. It isn't, or at least not first. The strongest fix for the device-code branch is administrative: a Conditional Access policy in Microsoft Entra that blocks or restricts device-code authentication unless a specific business case needs it. That's a configuration change your identity team can ship this week, and it removes the entire attack path rather than asking humans to out-judge it. Phishing-resistant MFA, meaning FIDO2 passkeys rather than push approvals, does similar structural damage to the AiTM branch; Microsoft's same report finds it blocks more than 99% of identity-based attacks, even when the attacker already holds valid credentials. Session monitoring (new device registrations, impossible-travel sign-ins, unexpected OAuth grants) is the net underneath both.
If your security budget forces a choice between those controls and a training refresh, buy the controls.
But most organizations can't fully close the device-code flow (some legitimately need it), passkey rollouts take quarters, and no session monitor catches everything on day one. Which leaves a question the controls can't answer: when a convincing, AI-written request reaches a human anyway, what happens in the next ninety seconds?
What the human layer has to look like now
Forg365 breaks the assumptions behind traditional awareness programs in two specific ways, and both have direct implications for how you test people.
First, the "spot the fake" heuristic is dead for this class of attack. An employee trained to inspect URLs will inspect the URL, find microsoft.com, and approve. Training has to shift from artifact inspection to intent verification: was this sign-in something I initiated? Does this code request match anything I actually did? That's a judgment habit, and judgment habits form only through realistic practice. A simulation program still sending single emails with typos is rehearsing employees for an attacker who retired years ago.
Second, the metric that matters most is reporting speed, not click rate. AI-generated lures at volume mean some will land no matter how good your people are. The difference between an incident and a non-event is how fast the first recipient reports it and how fast that report pulls the message from every other inbox. A lure reported in four minutes is a data point. The same lure sitting unreported for four days is a breach investigation.
Where email security can't follow
There's a reason Forg365 is sold on Telegram, and a reason modern lures don't stay in the inbox. Email is the most heavily defended channel you own: gateways, banner warnings, URL rewriting, retroactive message pulls. So attackers move the conversation. The pretext lands in email, but the pressure arrives by SMS ("it's the CFO, I'm boarding, approve it now") or inside WhatsApp, Signal, or Telegram, where the message is end-to-end encrypted and no corporate control can see it, scan it, or claw it back.
That last part inverts the usual defense model, and it's worth sitting with. On email, the human is one detection layer among several. On an encrypted channel, the human is the entire detection stack. No gateway, no telemetry, no retroactive pull. If your people have never practiced judgment on those channels, you've left your least-instrumented surface to your least-tested skill.
We simulate there for exactly that reason, and with guardrails, because testing on channels that touch personal devices is legally and culturally sharp-edged. SMS and messaging-app scenarios run only against consented, enrolled numbers, and we scope them first to the roles attackers actually target this way: finance approvers, executives and their assistants, help-desk operators, IT admins. The goal is not to trick employees on their personal phones. It's to give the people most likely to receive a real WhatsApp pretext a safe rep against one before the live version arrives. Reporting works the same way across channels, because a lure that hops from email to SMS should be reportable from wherever it lands.
This is the part of the problem we work on at Cimento. Our simulations are multi-turn and multi-channel because that's how kits like this operate: a pretext email, then pressure, then a channel switch. We track reporting speed and repeat exposure by role rather than by campaign click rates, and we weight scenarios toward the people and workflows an attacker would actually target first, such as finance approvers and help-desk operators. And per the section above, we'll be the first to tell you this sits alongside your Conditional Access and passkey work, not instead of it.
What comes next
Forg365 won't be the last of these. Researchers already group it with Kali365, which the FBI's IC3 flagged in a May 2026 advisory, and Sneaky2FA, and the pattern across all of them is the same: legitimate cloud components assembled into an identity attack and rented to whoever pays. The kits will keep getting cheaper, and the lures will keep getting better, because that's what a competitive market does.
The defense pattern is equally stable, though. Close the authentication flows you don't need. Make the sessions attackers steal less useful. And train the humans against the attack that exists this month, measured by how fast they raise their hand, not whether they ever click.
If you want to see what a Forg365-style multi-turn scenario looks like against your own high-risk roles, that's exactly what we build: https://cimento.ai/book-a-demo
Key Takeways
Restrict device-code authentication in Entra Conditional Access this week unless a workflow genuinely requires it.
Prioritize FIDO2 passkeys: Microsoft's data shows phishing-resistant MFA blocks over 99% of identity attacks.
Retire "spot the fake URL" training and test intent verification against multi-turn, AI-written lures instead.
Measure reporting speed, not click rate; a lure reported in minutes is a data point, not a breach.



