If your organization uses Microsoft 365 with MFA enabled, you may assume account takeovers are largely off the table. Forg365 breaks that assumption. This phishing-as-a-service platform, documented by security company ZeroBEC, gives attackers a way into M365 accounts without cracking passwords or defeating MFA through brute force. (Source: Csoonline)

The core problem is session theft, not credential guessing. Forg365 tricks users into authorizing attacker-controlled sessions through Microsoft's own legitimate infrastructure, then captures the resulting authentication material. Because the sign-in flows through genuine Microsoft services, the request looks credible to the victim, and MFA is satisfied by the user's own valid approval.

What makes Forg365 notable is packaging. It bundles AI-assisted lure creation, evasion, and post-compromise mailbox access into a single subscription service distributed through Telegram. Attackers with limited skill get a single operator panel to build lures, control email delivery, manage captured account data, and monitor breached mailboxes.

Templates impersonate business platforms your staff already trust, including DocuSign, Adobe Acrobat Sign, SharePoint, and OneDrive. That familiarity is the point — a remittance-approval or document-review request from a known brand rarely raises suspicion.

"Phishing-as-a-service has been around for quite a few years," said Jonathan Ong, senior analyst for managed security services at Omdia. "But the degree to which AI is integrated into Forg365 and enables users is what makes it concerning."

Pricing lowers the barrier further: a five-day free trial, then $400 per month or $3,800 per year. For that fee, a low-skill attacker gets tooling that used to require real technical ability.

The false sense of security is the real exposure here. Having MFA turned on does not protect an account when the attacker rides a session the user personally approved. Any M365 tenant with standard MFA is in scope, which is why the details of how the platform bypasses those controls matter.

Attack Chain: From Phishing to Cookie Theft to Account Takeover

The attack chain investigated by ZeroBEC begins with an email built around a business-document and remittance-approval pretext. This maps to MITRE ATT&CK T1566 (Phishing), specifically the spearphishing link variant. The message relies on legitimate cloud and email services to pass reputation checks before routing the recipient through several redirects.

Those redirects feed a traffic-classification layer. Before serving any malicious content, Forg365 profiles each visitor and decides whether to show a device-code phishing page, an adversary-in-the-middle flow, or a harmless decoy. Suspicious visitors — automated crawlers, sandboxes, researcher IP ranges — get diverted to a benign page. This is classic T1027 (evasion) and filtering behavior, and it means the malicious flow may never render in an automated scan.

For your SOC, that gating matters: a URL that returns clean in a detonation sandbox can still deliver the phishing page to a real employee on a corporate network. Reputation-only URL scanning will not reliably catch these campaigns.

The device-code and AiTM paths

On the device-code path, the victim reaches a genuine Microsoft authentication process and is persuaded to enter a code that authorizes a session the attacker controls. Because real Microsoft infrastructure handles the prompt, the request looks credible. This aligns with device-code abuse under T1078 (Valid Accounts) and T1528 (Steal Application Access Token) — the attacker never touches the password.

The adversary-in-the-middle path (T1557) relays authentication through attacker infrastructure and captures session information as the user completes sign-in. Either route produces the same outcome: a valid, MFA-satisfied session token in attacker hands.

ForgCookie and session hijacking

The post-compromise stage is where ForgCookie, a browser extension, comes in. It lets attackers generate and refresh Microsoft single sign-on cookies directly from their own browsers. This is session hijacking via stolen web session cookies — T1539 (Steal Web Session Cookie) — combined with token refresh for persistence.

Stolen cookies bypass MFA because the token they carry already represents a completed, verified sign-in. Entra ID sees a session that passed authentication and treats subsequent requests as authorized. The attacker's browser presents that material and reads the mailbox without ever re-prompting for a factor.

Resetting a password may not remove the attacker. Stolen refresh-token material or an attacker-controlled session could remain usable after the password is changed.

Because ForgCookie can refresh tokens, the session stays alive well past a single expiry. Forg365 also advertises inbox-monitoring tools and can share read-only mailbox access through a password-protected link — a low-friction way for one operator to hand off access. For your business, that means a compromised executive mailbox can be quietly monitored for wire-fraud opportunities long after the initial phishing email is forgotten.

Behavioral signatures and IOCs

ForgCookie runs in the attacker's browser, not on your endpoints, so host-based detection alone will miss it. The observable signals live in Entra ID and Microsoft Graph telemetry. Per ZeroBEC, the following patterns are worth pulling from sign-in and audit logs:

• Repeated silent sign-ins and non-interactive Microsoft Graph activity originating from unfamiliar IP addresses.
• Device names beginning with "Forg365" — ZeroBEC found devices registered during its investigation using this naming pattern, a direct indicator of compromise.
• Newly enrolled authenticator applications or passkeys tied to accounts that did not initiate the enrollment.
• Mailbox forwarding rules or delegated-access changes appearing shortly after a successful sign-in.

The impersonated lure templates — DocuSign, Adobe Acrobat Sign, SharePoint, and OneDrive — give phishing-awareness and email-filtering teams a concrete set of brands to watch in inbound messages carrying document-approval language.

The subscription model behind this — a five-day trial, then $400 per month or $3,800 per year, sold through Telegram — means the same tooling and infrastructure patterns can appear across unrelated campaigns targeting different organizations at once. Treat the "Forg365" device-name string and the silent Graph activity as shared indicators rather than one actor's fingerprint.

Business and Compliance Impact for M365 Environments

When Forg365 hands an attacker a live session inside your Microsoft 365 tenant, the compromise is not limited to one mailbox. A single hijacked account typically holds email history, shared document access, and directory visibility that let an intruder read internal communications and map who approves payments, signs contracts, and manages vendor relationships.

The mailbox monitoring features built into the platform matter here. Because operators can watch a compromised inbox and share read-only access through a password-protected link, more than one person can observe your correspondence over an extended period. For a business, that means invoices, wire instructions, and legal discussions may be exposed without any obvious sign of a break-in.

The remittance-approval pretext used in the campaign points directly at financial fraud. If an attacker sits inside a finance or executive mailbox, they can study genuine payment threads and insert fraudulent instructions that match your company's tone and process. This is how business email compromise turns a single account takeover into a redirected wire or an altered vendor payment.

Persistence is the part that changes your legal calculus. Since stolen refresh-token material and attacker-controlled sessions can survive a password reset, you may believe an incident is closed while access continues. If newly registered devices or mailbox forwarding rules remain in place, sensitive data can keep flowing out after you think you have recovered.

That distinction between "password changed" and "attacker removed" drives your disclosure obligations:

• GDPR — Unauthorized access to mailboxes holding EU personal data can trigger the 72-hour breach notification requirement, and regulators expect you to know what was accessed and for how long.
• HIPAA — If a compromised M365 account contains protected health information, mailbox access alone may constitute a reportable breach, with patient and regulator notification duties.
• SOX — Attacker access to finance-related email and approval workflows raises questions about the integrity of your internal financial controls, which auditors will examine.

The impersonation templates that mimic DocuSign, Adobe Acrobat Sign, SharePoint, and OneDrive also create downstream exposure. If an attacker sends convincing lures from your legitimate accounts, your customers and suppliers become the next targets. A breach that starts in your tenant can spread across your supply chain, and partners who receive fraudulent documents from your domain may treat you as the source of their loss.

That pricing is the business risk worth sitting with. For a few hundred dollars a month, an attacker with limited skill gains automated tooling to take over accounts and keep watching your mail. The low cost of entry means the volume of attempts against M365 tenants is likely to rise, and each successful takeover carries the same investigation, notification, and recovery burden regardless of how cheaply the intrusion was purchased.

For decision-makers, the practical consequence is that an M365 account takeover is not a help-desk password event. It is a data-exposure incident that may require forensic investigation, regulatory reporting, and outreach to customers and partners whose trust in your correspondence has been undermined.

Detection and Immediate Response Actions

The most urgent action is to revoke active refresh tokens and terminate every existing session on any account you suspect Forg365 has touched. Because the attacker holds stolen session material rather than a password, a password reset alone leaves them signed in. Session revocation in Microsoft Entra ID invalidates the tokens that ForgCookie generates and refreshes from the attacker's own browser.

Following the NIST Cybersecurity Framework, work through detection and containment before you move to hardening.

Start your investigation in the Entra ID sign-in logs. ForgCookie produces authentication activity that does not match normal user behavior, so look for the patterns ZeroBEC flagged:

• Repeated silent (non-interactive) sign-ins from unfamiliar IP addresses, which indicate token refresh happening in the attacker's browser rather than at the user's device.
• Non-interactive Microsoft Graph API activity from addresses that don't match the user's normal locations.
• Impossible-travel sign-ins — a session from the user's usual city and another from a distant address within a window too short to be physical travel.
• Device registrations with names beginning with "Forg365", a confirmed indicator of compromise from the ZeroBEC investigation.

Adlumin monitors authentication patterns across managed environments Capstone operates, catching the silent sign-in and non-interactive Graph activity that signals stolen-session reuse before an intruder settles into a mailbox.

In the first hour, once you confirm a compromise, contain it in this order:

• Revoke refresh tokens and end active sessions for the account.
• Disable the account or force credential reset alongside the token revocation — not instead of it.
• Audit and remove OAuth application grants the user did not authorize; a consented app can hold access independent of the sign-in session.
• Remove any registered device you cannot attribute to the user, and check whether an unauthorized authenticator app or passkey was enrolled during the intrusion.

Then review the mailbox itself for persistence the attacker left behind. Check inbox forwarding rules and delegated-access permissions for unauthorized changes — either lets an intruder keep reading mail after you reset the password. Removing these closes the quieter routes back in.

Within the first week, tighten the controls that shorten an attacker's window. Reduce refresh-token and session lifetimes in Entra ID so stolen material expires sooner. Turn on risky sign-in alerts and configure conditional access to require reauthentication on anomalous behavior. If your organization does not need device-code authentication, block it in Entra ID — this disrupts the device-code path Forg365 relies on, though it does not stop adversary-in-the-middle relaying or reuse of already-stolen cookies.

Before you block device-code broadly, identify legitimate uses. Command-line tools, conference-room systems, and other devices with limited input may need exceptions, so scope the policy rather than applying a blanket rule that breaks working systems.

Over the first month, move toward phishing-resistant MFA such as FIDO2 security keys or WebAuthn passkeys, which do not produce a code a user can be tricked into approving. Pair that with device-compliance requirements in conditional access so only enrolled, healthy devices reach your tenant. This rollout may require hardware keys or managed smartphones and will likely raise support requests during the transition, so plan the deployment in stages rather than switching every user at once.

Hardening M365 Against Cookie-Based Account Takeover

The single most important hardening move is to make session cookies useless when stolen. Token protection (token binding) in Microsoft Entra ID cryptographically ties a sign-in session to the device that created it, so a refresh token lifted into an attacker's browser cannot be replayed elsewhere. This directly counters the cookie-refresh technique at the heart of a Forg365 compromise, where the attacker signs in from unfamiliar addresses using material captured during the phishing flow.

Standard MFA does not stop this. When an attacker relays your authentication or persuades you to approve a session, TOTP authenticator codes and SMS one-time passwords are satisfied by your own valid approval. The attacker walks away with a live session that already cleared the MFA prompt, so the second factor never sees the fraud.

Phishing-resistant authentication changes that math. FIDO2 security keys, WebAuthn passkeys, and Windows Hello for Business bind the credential to the specific origin and device, so there is no code to relay and no shared secret to capture. The authentication cannot complete against an adversary-in-the-middle site because the browser refuses to sign for the wrong domain.

Build Conditional Access rules that treat atypical sessions as untrusted rather than merely inconvenient. In Entra ID, prioritize the following:

• Require phishing-resistant MFA as the grant control for administrators first, then extend it to all users who touch email, finance, or document platforms.
• Enforce token protection for Exchange Online and SharePoint Online sign-in sessions so bound tokens fail when replayed from another device.
• Block or scope legacy and device-code flows using an authentication-flow policy, applying named exceptions only for the command-line tools and shared-room devices that genuinely need them.
• Set sign-in frequency and disable persistent browser sessions for higher-risk roles so long-lived cookies expire faster and reduce the window an attacker can ride.
• Use continuous access evaluation (CAE) so that token revocation and risky sign-in events cut off access in near real time rather than waiting for the next token refresh.

Layer in named-location and IP-based conditions so sign-ins from unmanaged networks trigger step-up authentication or blocking. Pair this with device compliance requirements: if a session did not originate from an enrolled, compliant device, it should not reach mailbox data. This narrows the surface that attacker-side session refresh depends on.

OAuth consent is a quieter path to persistence that survives password changes. Restrict user consent to verified publishers and low-risk permissions, and route requests for broader Microsoft Graph scopes through an admin consent workflow. Enable app consent policies so a compromised user cannot silently grant a malicious application standing access to their mailbox.

Monitoring closes the loop. Adlumin ITDR correlates authentication behavior across managed environments, surfacing non-interactive Graph activity and repeated silent sign-ins from unfamiliar addresses that indicate a bound-token bypass attempt. Feed Entra ID sign-in and audit logs, OAuth consent grants, and device-registration events into that telemetry so a new consent grant or an unexplained enrolled device raises an alert instead of sitting unnoticed.

For security architects, the roadmap is ordered: enable token protection and phishing-resistant MFA, constrain device-code and legacy flows, shorten session lifetimes with CAE, lock down OAuth consent, and monitor for the sign-in patterns that stolen sessions produce. Each control removes value from a captured cookie, so a single phished approval no longer buys durable access to the tenant.

Key Takeaway: Assume Credentials Are Compromised; Protect the Session

The lesson from the Forg365 campaign is straightforward: a valid password approval no longer proves the person signing in is who they claim to be. The platform's operators do not defeat multi-factor authentication by cracking it. They wait for your users to satisfy MFA legitimately, then take over the resulting session. That distinction changes how you should think about account security.

Once you accept that any credential or authentication approval can be captured and replayed, the priority shifts to protecting the session itself rather than trusting it after sign-in. A password reset, an MFA prompt, or even a fresh login means little if the attacker already holds live session material and can refresh it from their own browser.

Practically, that means the session — not the password — is the asset worth defending. Controls that tie a session to a known device and flag sign-ins that break normal patterns close the window Forg365 depends on. A session that only works from the device that created it cannot be replayed elsewhere, and a login from two distant locations within minutes signals theft regardless of a correct password.

A reasonable starting point for your organization is a review of your Microsoft 365 tenant for signs that a session has already been taken over: unfamiliar mailbox forwarding rules, unexpected delegated mailbox access, and OAuth applications no one recognizes. Pair that review with Conditional Access policies that block impossible-travel sign-ins.

Treat authentication as the beginning of trust, not the end of it. Verifying who signed in matters less than confirming the session that follows still belongs to that user.