← Back to Blog

Threat Research

Inside Forg365: A Telegram-Distributed Sneaky 2FA-Style PhaaS Targeting Microsoft 365

ZeroBEC threat research on Forg365, a Kali365-class Microsoft 365 PhaaS that combines Telegram distribution, AI-assisted lure generation, device-auth phishing, AiTM routing, AntiBot evasion, token vaulting, and a Manifest V3 browser extension (ForgCookie) for persistent Microsoft SSO access.

By ZeroBEC Team · July 9, 2026 · 18 min read

Forg365 is a mature Microsoft 365-focused phishing-as-a-service platform that combines device-auth phishing, AiTM delivery, AntiBot evasion, campaign delivery, session persistence, AI-assisted lure creation, and post-compromise mailbox operations inside a commercial operator ecosystem.

Executive summary

This matters because Microsoft classifies device code flow as a high-risk authentication method that can be abused in phishing attacks, and Microsoft Defender research has already described AI-enabled device-code campaigns as an escalation from static and manual phishing operations toward automated infrastructure.

The commercial model is also important. Forg365 is distributed and supported through Telegram, which mirrors the distribution pattern described in the FBI IC3 Kali365 PSA, where Kali365 is described as a Telegram-distributed PhaaS that captures Microsoft 365 OAuth tokens and lowers the barrier to entry through AI-generated lures, automated templates, dashboards, and token capture. Forg365 follows the same category direction, but the material observed by ZeroBEC exposes a broader integrated product surface: AI lure generation inside the panel, template-driven invitations, SMTP rotation, token vaulting, viewer links, keyword listeners, inbox sync, cookie generation, automatic session refresh, and a dedicated browser extension for persistent Microsoft SSO access.

Forg365 should therefore be understood as a Kali365-class platform, not as a small standalone kit. Public reporting on the broader Kali365/Octopi365 ecosystem by Huntress describes multiple panel variants, built-in templates, a large API surface, billing, domain marketplace functionality, token management, and companion tooling. In the Forg365 material, the operator-facing functionality appears similarly productized and, in several observed areas, more complete than the agency-level public summaries of Kali365. The most important finding is the maturity of the business model and operator workflow, not a single lure.

Forg365 also overlaps with the Sneaky 2FA tradecraft class. Sekoia described Sneaky 2FA as a Telegram-operated AiTM PhaaS targeting Microsoft 365 accounts, and ZeroBEC previously documented Sneaky 2FA-style Microsoft 365 replay and device-code PhaaS tradecraft in the Sneaky 2FA Returns and DEBULL Storm-2372 research posts. Forg365 brings these lines together: Telegram commercialization, Microsoft 365 identity abuse, AiTM routing, device-code authorization, Cloudflare-hosted landing pages, and post-compromise mailbox tooling.

Defensively, Forg365 reinforces why device-code and authentication-transfer controls must be treated as identity-risk controls, not simply user-awareness issues. CISA Microsoft Entra ID guidance recommends blocking device-code authentication, and Microsoft recommends allowing device-code flow only where necessary. Forg365 shows why: the victim can interact with legitimate Microsoft authentication surfaces while authorizing attacker-controlled access, and the platform then attempts to preserve that access through token, cookie, inbox, and browser-session workflows.

Key findings

• Forg365 is Telegram-distributed and commercially packaged. Observed onboarding showed a 5-day free trial, monthly access priced at $400, and annual access priced at $3,800.
• The current primary operator panel distributed after Telegram registration is hxxps://logfriend[.]com/login. Other related domains and direct nodes appear to represent alternate panel variants, test or legacy infrastructure, AntiBot administration, or delivery components.
• The panel exposes a mature operator workflow: accounts, links, invitations, OAuth app configuration, redirect links, SVG generation, campaign sending, SMTP profiles, SMTP rotation, AI email generation, token vaulting, account intelligence, keyword alerts, viewer links, and browser-extension support.
• The original delivered lure used legitimate email delivery and hosted-content infrastructure, including Amazon SES and SendGrid artifacts, before the redirect chain reached the Forg365-controlled branches.
• Entra telemetry linked the device-code branch to a Comcast/Xfinity fixed-line address and to a campaign-linked Forg365 backend hosted in Kyiv, Ukraine. The Comcast/Xfinity address appeared during Microsoft Authentication Broker/device-code activity, while the Ukraine node later performed Microsoft Graph/device-registration activity and exposed a Forg365 panel.
• Forg365 supports both device-auth phishing and AiTM routing. The device-auth branch shows a Microsoft-styled verification code page and launches the legitimate Microsoft Authentication Broker flow. The AiTM branch uses route tokens, session cookies, and traffic classification to decide whether to serve phishing content or a benign decoy.
• ForgCookie, the browser extension associated with the platform, is designed for Microsoft SSO cookie refresh, browser-based access, and persistent session workflows after compromise.
• The infrastructure is role-separated: Telegram commercialization, a primary operator panel, delivery infrastructure, Cloudflare-hosted landing infrastructure, AntiBot components, Gophish campaign delivery, token/session persistence, and post-compromise mailbox operations.
• ZeroBEC assesses Forg365 as a Kali365-class Microsoft 365 token-focused PhaaS platform with Sneaky 2FA-style AiTM overlap. We do not assess common ownership with Kali365 or Sneaky 2FA based on the current evidence.

Why Forg365 matters

Forg365 matters because it demonstrates how quickly Microsoft 365 phishing-as-a-service is becoming productized. The platform is not merely a landing page. It packages access, lure creation, delivery, evasion, token/session handling, and post-compromise operations into a subscription-based operator environment.

This is the broader trend: AI makes custom PhaaS development easier, and it also makes the operator workflow more accessible. In Forg365, AI is embedded directly into the panel to help generate phishing emails and lures. Operators do not need to rely only on external prompt tools or handcrafted templates. They can create and refine campaign material in the same environment that manages links, SMTP rotation, OAuth app workflows, token vaulting, and mailbox access.

The result is a platform that lowers the skill threshold while increasing operational consistency. Less experienced affiliates can use prebuilt templates, while more capable operators can customize landing pages, rotate infrastructure, manage tokens, generate cookie material, and monitor compromised accounts.

Email evidence and delivery artifacts

The investigation began with a real inbound lure rather than with the panel alone. The email presented a business-document themed request and used a trusted-service style pretext to move the recipient into the phishing flow. This evidence is important because it ties the operator-facing platform to a delivered campaign, not just to an exposed dashboard.

Header and content artifacts showed the lure was delivered through legitimate delivery infrastructure and included third-party hosted content. The observed sender domain used Amazon SES delivery, while the message body included SendGrid-hosted image or tracking resources. This mix of legitimate delivery services, hosted visual assets, and downstream phishing infrastructure is consistent with a mature PhaaS delivery model designed to blend into normal SaaS email traffic.

Email delivery evidence
Observed sender style: business-document / remittance approval lure
Delivery layer: Amazon SES observed in message headers
Hosted content: SendGrid-hosted image or tracking artifacts in the HTML body
Downstream flow: security wrappers -> redirect chain -> AiTM or device-auth phishing branch

This email evidence anchors the platform analysis in the actual campaign path: lure delivery, legitimate infrastructure abuse, redirect and cloaking behavior, Microsoft device-auth interaction, and post-compromise platform features.

Telegram-based distribution and commercialization

Forg365 uses Telegram as a distribution, onboarding, and support channel. The panel itself directs operators to contact support on Telegram, and the registration flow observed during this investigation used Telegram-based steps to reach the current primary panel. This is an important overlap with Kali365-class platforms, because Telegram provides discovery, payment coordination, support, bot-driven onboarding, and community-style operator enablement.

The pricing model observed through Telegram showed a 5-day free trial, monthly access at $400, and annual access at $3,800. This price point is slightly below the upper tier often associated with leading Microsoft 365 token-focused affiliate offerings, commonly assessed around $500 per month, but still clearly positions Forg365 as a maintained commercial service rather than a disposable phishing kit.

Primary operator panel and product surface

The most recent Telegram registration workflow provided access to the current primary Forg365 panel at hxxps://logfriend[.]com/login. Earlier observed domains and direct nodes remain relevant as infrastructure pivots, but they should be treated as related panel variants, alternate deployments, test or legacy nodes, or role-specific supporting services unless additional evidence shows they are current primary entry points.

The panel is organized as an operator product. The left navigation includes Home, Accounts, Links, Send, Activity, Others, and Settings. The Links section includes Invitations, OAuth App, Redirect Link, and SVG Generator. This grouping is significant because it shows that Forg365 supports multiple phishing modes and delivery artifacts rather than one static landing page.

Device-auth phishing branch

Forg365 includes a device-auth phishing branch that presents a Microsoft-styled verification code page and pushes the victim into a legitimate Microsoft Authentication Broker sign-in flow. The victim sees real Microsoft authentication surfaces, but the code authorizes an attacker-controlled session. This makes the flow difficult for a user to evaluate because the final authentication surface can be legitimate even when the session being authorized is not.

The observed device-auth branch aligns with Microsoft's own description of device-code phishing risk: the attacker does not need to steal the password directly. The user authorizes a session by entering a code into the legitimate Microsoft flow. Entra telemetry then becomes critical, especially fields such as original transfer method, Microsoft Authentication Broker usage, device registration activity, Graph access, and non-interactive token use.

AiTM and cloaking branch

The AiTM branch is separate from the device-auth branch. In the observed flow, the AiTM host used PHP session state, a preload cookie, and a long word-number route token stored in the rt cookie. The same route-token format appeared in the URL path. When the link was accessed from a NordVPN egress path, the flow redirected to a benign SpaceX decoy instead of showing the phishing content. This behavior is consistent with traffic reputation scoring and anti-analysis cloaking.

AiTM branch indicators
PHPSESSID=<session>
preload=1
rt=frog1_cat2_horse9_light4_soil6_branch7_milk10_paper10_village9_evening4_fox3_galaxy5_rock8_fish9_seed1_bread5_ocean7_stone9

Behavior: VPN / low-trust traffic redirected to benign SpaceX decoy

The AiTM branch also loaded Cloudflare telemetry and maintained a Socket.IO dependency through a separate WebSocket host. This reinforces that Forg365's phishing flow can classify visitors and decide whether to show AiTM content, device-auth content, or a benign redirect based on environment and reputation.

Tenant telemetry: Comcast relay and Ukraine-hosted Forg365 backend

The Microsoft Entra telemetry was one of the most important evidence sources because it tied the victim-facing device-auth experience to real authentication and post-authentication behavior. Two infrastructure observations were especially important: a Comcast/Xfinity fixed-line address in the United States during the device-code sequence, and a Ukraine-hosted Forg365 backend that later performed Microsoft Graph and device-registration activity.

First, the device-code branch produced Microsoft Authentication Broker activity from a Comcast/Xfinity address. The address was not part of the victim test environment and appeared during the Microsoft Authentication Broker / Microsoft Graph sequence with original transfer method set to deviceCodeFlow. This is important because it shows the attack did not rely only on a cloud-hosted server or a generic proxy. A residential or fixed-line U.S. network appeared in the authentication path, which can reduce suspicion in identity telemetry and complicate automated reputation-based blocking.

Second, the follow-on backend activity linked the campaign to a Forg365 host in Ukraine. Shodan identified the campaign-linked host as xoday[.]sbs on 139[.]28[.]38[.]129, located in Kyiv, Ukraine, running Ubuntu with nginx and the HTTP title Forg365. Entra non-interactive telemetry from the same address showed Microsoft Office / Microsoft Graph activity using node-style user agents and original transfer method deviceCodeFlow. Audit logs also recorded device-registration activity associated with the same address, and the resulting device names carried the Forg365 prefix.

These two telemetry pivots should remain prominent because they anchor the Forg365 backend to real Microsoft authentication and post-authentication telemetry. The Comcast/Xfinity event shows the device-code branch can involve residential or fixed-line U.S. access, while the Ukraine-hosted node anchors the Forg365 backend used for follow-on Microsoft Graph and device-registration activity.

Role-separated infrastructure

Forg365 uses a role-separated operating model. Public-facing and campaign-facing infrastructure is often Cloudflare-fronted, while selected panel subdomains resolve directly to VPS nodes. The infrastructure includes the current primary operator panel, related panel variants, AntiBot administration, Gophish campaign delivery, Cloudflare Pages and Workers landing infrastructure, and a central API service for the ForgCookie extension.

ForgCookie: browser-session persistence

ForgCookie is one of the strongest indicators that Forg365 is designed for ongoing access, not only initial capture. The extension is described as an automatic Microsoft SSO cookie refresh component for Forg365. The panel welcome message advertises cookie generation for browser-based access, automatic session refresh, real-time inbox sync, and no need to re-authenticate. The extension operationalizes that promise in the browser.

Static analysis of the extension showed a Manifest V3 browser extension named ForgCookie, version 1.0.21. The extension requests cookie and storage permissions and grants host access to Microsoft login infrastructure and the Forg365 extension API. Its runtime configuration points to logfriend[.]com as the API base. The code includes endpoints for login, logout, refresh, account listing, cookie generation, health, and version checks.

ForgCookie static artifacts
Name: ForgCookie
Version: 1.0.21
Description: Auto-refresh Microsoft SSO cookies for Forg365
API base: hxxps://logfriend[.]com
Extension endpoints:
  /api/extension/login
  /api/extension/accounts
  /api/extension/generate-cookie
Cookie target: x-ms-RefreshTokenCredential on login.microsoftonline[.]com
Silent SSO flow: Microsoft Authentication Broker / prompt=none / substrate.office[.]com

The extension workflow is especially important because it shows the bridge between token acquisition and browser access. ForgCookie requests account data from the Forg365 backend, calls the cookie-generation endpoint for a selected account, clears Microsoft session cookies, injects the generated refresh-token credential cookie into the Microsoft login domain, triggers a silent OAuth flow, captures resulting Microsoft cookies across Microsoft domains, and repeats this cycle through Chrome alarms. In practical terms, this is a persistence and session-refresh layer designed to keep browser access available after initial compromise.

The presence of account properties such as hasDeviceRegistration in the extension code also aligns with the Entra telemetry showing Forg365-named device objects. ForgCookie itself runs on the operator's browser, not the victim's, so defenders should not hunt for it in managed-browser inventories. Instead, hunt for the telemetry footprint it produces in the victim tenant: repeated silent Microsoft SSO refreshes, non-interactive Graph traffic from IPs unrelated to the user, and sessions that survive credential reset because refresh-token material is being replayed from an attacker-controlled browser.

AI-assisted lure generation and campaign preparation

AI is not an external afterthought in Forg365. The platform exposes AI-assisted content generation directly inside the operator workflow. This means operators can create phishing emails, prepare lure text, and refine campaign messaging from inside the same platform used to configure SMTP profiles, landing pages, invitation links, and post-compromise activity.

This is strategically important. AI reduces the cost of developing custom phishing content, but it also reduces the cost of building custom PhaaS platforms. Forg365 reflects both sides of that trend: the platform itself appears productized, and the operator experience includes AI assistance for content creation.

Cloudflare deployment, SVG redirectors, and AntiBot

Forg365 includes Cloudflare Worker deployment workflows and victim-facing Cloudflare Pages infrastructure. This allows operators to rapidly create or rotate landing infrastructure while keeping the core panel and persistence services separate. The observed device-auth branches used Cloudflare Pages, while campaign configuration screenshots show Cloudflare Worker deployment options inside the panel.

The SVG Generator feature adds another delivery and evasion layer. The panel presents AES-encrypted SVG redirectors for email delivery, including bot detection, debugger traps, headless/browser automation checks, sandbox and VM fingerprinting, and polymorphic code. This is consistent with a platform designed to survive automated scanning and email security detonation rather than a basic phishing kit.

Gophish delivery infrastructure

The same broader infrastructure cluster exposed a Gophish login page on a related campaign-delivery subdomain. The observed host was go.incogxray[.]sbs, a role-specific subdomain under the same incogxray[.]sbs namespace that also hosted other panel-related infrastructure. The page used default Gophish branding, stock logo assets, a standard login POST flow, and cookies named _gorilla_csrf and gophish. This does not mean Forg365 is built from Gophish. It means the operator ecosystem appears to incorporate open-source Gophish infrastructure for campaign sending or lure management alongside the custom Forg365 platform.

Gophish evidence
Host role: campaign delivery / sender infrastructure
Observed branding: Gophish - Login
Cookies: _gorilla_csrf, gophish
Assessment: open-source Gophish appears to be used as a supporting delivery component
            in the broader ecosystem

Post-compromise operations

Forg365's post-compromise functionality is extensive. The panel includes Token Vault, Account Intel, Admin Control, M365 Search, Keyword Listener, AI mailbox context, and Viewer Links. These features show a platform designed to monetize access after the initial phish, not merely to collect a credential or token.

Relationship to Kali365-class and Sneaky 2FA-style PhaaS

Forg365 should be classified as Kali365-class because it shares the category-defining characteristics: Telegram distribution, subscription-based access, Microsoft 365 OAuth and device-auth abuse, AI-generated lure support, automated templates, dashboards, token capture, and persistent access workflows. The currently available evidence does not prove that Forg365 is Kali365, a Kali365 rebrand, or operated by the same developers. The stronger and more defensible assessment is that Forg365 sits in the same rapidly maturing class of Microsoft 365 token-focused PhaaS platforms.

Forg365 also shows Sneaky 2FA-style overlap in its AiTM branch, Microsoft 365 focus, Telegram commercialization, anti-analysis behavior, and infrastructure reuse. The overlap is operational and architectural. It is not, by itself, proof of common ownership. The safe phrasing is that Forg365 combines Kali365-class device-auth/token workflows with Sneaky 2FA-style AiTM and evasion patterns.

Detection and defensive guidance

Defenders should not treat device-code events as isolated user mistakes. Forg365 shows that a single device-auth event may be the front door into a broader platform that supports token vaulting, session refresh, mailbox monitoring, and fraud workflows.

• Block or tightly restrict device-code flow through Conditional Access unless there is a documented business requirement.
• Review Entra sign-in logs for original transfer method equal to deviceCodeFlow, Microsoft Authentication Broker usage, unusual device registration, non-interactive Graph activity, and node-fetch or node-style user agents.
• Hunt for device names beginning with Forg365- or other suspicious operator naming conventions.
• Treat ForgCookie as operator-side tradecraft, not a victim endpoint artifact. The extension runs in the attacker's own browser and calls logfriend[.]com/api/extension/* to refresh Microsoft SSO cookies for compromised accounts. Hunt for the symptoms it produces in your tenant: repeated silent prompt=none sign-ins to substrate.office[.]com and other Microsoft resources, non-interactive Graph activity from IPs unrelated to the user, and sessions that survive password resets because refresh-token material is being replayed elsewhere. Revoke sessions and refresh tokens at the identity layer rather than relying on victim-side extension inventory.
• Search proxy and DNS logs for Forg365 extension API paths, Cloudflare Pages project names, suspicious pages[.]dev lures, and role-specific panel domains.
• Investigate mailbox artifacts after device-code events: inbox rules, forwarding, OAuth grants, sent items, deleted items, keyword searches, viewer links, and unusual Graph activity.
• Treat VPN-to-decoy behavior as evidence of anti-analysis, not proof that the original link is benign.

Example hunting logic (conceptual)
- Device-code sign-ins followed by Microsoft Graph non-interactive access from a new IP
- Microsoft Authentication Broker success followed by device registration
- New device names matching Forg365-*
- Browser extension inventory containing ForgCookie or extension host permissions
  for logfriend[.]com and login.microsoftonline[.]com
- URL telemetry involving pages[.]dev plus Microsoft device-auth URLs within the
  same session
- Mailbox rule, forwarding, keyword-search, or viewer-link activity after
  token-focused sign-in events

Observed infrastructure and pivots

The following indicators are provided for defensive hunting and clustering. Benign security-wrapping services observed in the URL chain should not be treated as malicious by themselves.

Primary / commercial panel
hxxps://logfriend[.]com/login
logfriend[.]com/api/extension/*

Related panel and backend nodes
xoday[.]sbs
139[.]28[.]38[.]129
ructus[.]site
panel.ructus[.]site
185[.]174[.]101[.]1
45[.]82[.]84[.]29
panel.incogxray[.]sbs

Gophish delivery component
go.incogxray[.]sbs
_gorilla_csrf
gophish

Device-auth landing layer
critical-silver-yak[.]pages[.]dev
shy-crimson-wren[.]pages[.]dev
forg_jschk

AiTM / redirect branch
pjeqlikeln.briggselectrlc[.]co
PHPSESSID
preload=1
rt=<word-number route token>
manlivep[.]org/socket.io/

Browser extension artifacts
ForgCookie
ForgCookie 1.0.21
x-ms-RefreshTokenCredential
/api/extension/login
/api/extension/accounts
/api/extension/generate-cookie

For defenders, the lesson is operational. Effective response requires connecting email headers, lure rendering, redirect behavior, Entra telemetry, device registrations, OAuth and device-code activity, browser-extension artifacts, mailbox access, and infrastructure pivots.

Why ZeroBEC

Forg365 is not a lure to block. It is an operator platform, sold on Telegram, that packages a full identity-attack supply chain into a subscription. A single delivered email touches Amazon SES, SendGrid-hosted content, a security-wrapper redirect, an AntiBot filter, an AiTM or device-auth branch, a Microsoft Authentication Broker sign-in, a device registration, Microsoft Graph traffic from a Ukraine-hosted backend, a token vault, and eventually a browser extension that keeps the session alive. Every one of those steps is designed to look explainable in isolation. The compromise is only visible when they are read as a sequence.

That is precisely the layer ZeroBEC is built to see. The platform learns what normal looks like for each user and tenant: who they interact with, what senders they trust, what SaaS delivery paths they see, what devices they register, what Entra transfer methods they use, what mailbox activity fits their role. When a Forg365-shaped sequence appears, the individual events may pass every reputation, DMARC, and sender-trust check, but the pattern does not fit the user. ZeroBEC surfaces that mismatch and quarantines the message before the identity chain begins.

Once a device-code or AiTM event does slip through elsewhere, ZeroBEC also closes the loop on the post-compromise side. It correlates the Entra device-code event to the follow-on non-interactive Graph activity, the Forg365-prefixed device registration, the browser extension host access, the inbox rules and forwarding, and the mailbox reading pattern that a Token Vault + Keyword Listener + Viewer Links platform is designed to produce. The investigation trail is built automatically: original lure, delivery chain, landing branch (device-auth or AiTM), Microsoft Authentication Broker activity, attacker IPs, device registrations, token/session persistence artifacts, and mailbox operations.

Traditional gateways stop at the email. Forg365 does not. That is why closing the gap between the phishing email and the account-takeover activity that follows is not optional anymore. ZeroBEC exists to make that end-to-end view the default: from lure to token to mailbox, in one investigation, in real time.

Ready to see how ZeroBEC protects your organization? Start free or contact us.