Forg365 shows why modern security failures happen in the gaps between identity, email, cloud access, and human behavior
By Jennifer Gilligan, President, IntegraMSP
The most dangerous part of the latest Microsoft 365 phishing operation is not that the sign-in page is fake.
It may be real.
Security researchers recently uncovered Forg365, a new phishing-as-a-service platform targeting Microsoft 365 accounts. According to ZeroBEC’s research, the service combines artificial intelligence-assisted phishing content, adversary-in-the-middle attacks, device-code authentication abuse and tools for maintaining access to compromised mailboxes.
The price is $400 a month. There is even a five-day free trial.
Apparently, cybercrime has reached the subscription economy, complete with onboarding, automation, and customer support.
The darkly impressive part is not any single feature. It is how thoroughly the operation has been productized. An attacker can use the platform to prepare convincing phishing messages, manage campaigns, capture tokens, monitor compromised accounts, search mailboxes, and refresh browser sessions. AI-assisted writing is built directly into the same dashboard used to manage the attack.
This is what operational maturity looks like when it is pointed in the wrong direction.
When a legitimate sign-in becomes the attack
Device-code authentication is a legitimate Microsoft process. It was designed to help users sign in to devices that do not have a convenient keyboard or browser, such as a smart TV or printer. A code appears on one device, and the user enters it through a Microsoft authentication page on another. Forg365 turns that convenience into a weapon.
The attacker initiates the authentication request and presents the victim with the code. The victim follows the instructions, reaches a real Microsoft page and completes the sign-in process, potentially including multifactor authentication. The password is not necessarily stolen. Instead, the victim unknowingly authorizes the attacker’s session. That distinction matters.
For years, security awareness training has taught users to inspect the link and look for a legitimate domain. In this attack, the final authentication page may be legitimate. The user can follow a familiar process and still make the wrong authorization decision because the context surrounding the sign-in has been manipulated.
Forg365 also supports adversary-in-the-middle phishing, which can proxy authentication traffic and capture session cookies. Its post-compromise tools are reportedly designed to preserve access, monitor mailbox activity, and help operators search for useful information after the initial intrusion. This is not simply credential theft. It is a packaged identity takeover operation.
AI is accelerating the operation, not inventing the crime
For months, we have argued that AI adoption is not primarily a technology problem. It is a governance and operational maturity problem. Forg365 is the ugly reverse image of that argument. AI did not invent phishing, token theft, or social engineering. What it does extraordinarily well is reduce friction. It helps attackers write more convincing messages, tailor them to a person’s role, translate them, refine them and deploy them at greater scale. It also lowers the technical barrier to building and operating the platforms behind those campaigns.
Microsoft has already documented AI-enabled device-code phishing campaigns using personalized lures tied to invoices, requests for proposals and manufacturing workflows. Researchers observed attackers using automation for reconnaissance, Microsoft Graph mapping, inbox-rule creation, and email exfiltration after gaining access. In other words, attackers are not merely using AI to write a better phishing email. They are using it to improve the entire operating model.
Businesses should be doing the same thing in defense: looking at the complete system instead of buying another isolated tool and declaring the problem solved.
The real vulnerability is the space between the controls
Forg365 crosses email security, cloud identity, browser sessions, OAuth permissions, Microsoft Graph activity, mailbox rules, human behavior, and incident response. Most organizations manage those areas separately. That fragmentation is the opening.
The email team may see a message. The identity platform may record a successful authentication. The user may see a legitimate Microsoft page. The help desk may reset a password. Each action can appear reasonable when viewed alone, while the larger attack continues through the gaps.
This is why governance cannot be reduced to a policy document, and security cannot be reduced to a stack of products. Governance is the operating system that determines who owns a risk, which controls apply, how exceptions are approved, what activity is monitored, and what happens when trust must be revoked.
It is also why a password reset may not be enough. When access tokens, refresh tokens, registered devices, mailbox rules, or OAuth grants are involved, the response must address the identity and cloud environment as a whole.
What business leaders should ask NOW
This is not a request for every executive to become an identity engineer. It is a request for leadership to make sure someone clearly owns the answers.
Organizations using Microsoft 365 should be asking:
- Is device-code authentication allowed in our environment, and do we have a documented business reason for it?
- If it is required, is it restricted through Conditional Access to approved users, applications, devices, and circumstances?
- Are Microsoft Entra sign-in events monitored and correlated with unusual device registrations, Microsoft Graph activity, mailbox forwarding, and new inbox rules?
- Can our incident response team quickly revoke sessions and refresh tokens, disable a compromised account when necessary, remove unauthorized devices, and inspect mailbox changes?
- Does our security awareness training explain that a real Microsoft page does not make an unexpected device-code request safe?
- Who owns the evidence that these controls are configured, monitored, and tested?
Microsoft recommends blocking device-code flow wherever possible and limiting it through Conditional Access when it is genuinely required. Proofpoint’s threat researchers similarly recommend blocking the flow where possible, requiring compliant or joined devices, and updating user education for this specific attack method.
Those are technical measures, but the decision to implement, verify, and maintain them is an operational one.
Governance must move at the speed of the threat
The uncomfortable lesson of Forg365 is that attackers are already building governed AI-enabled ecosystems. They have integrated tools, repeatable workflows, defined handoffs, subscription pricing, and automation from first contact through post-compromise activity. Meanwhile, many legitimate businesses are still debating whether AI governance means writing an acceptable use policy. The policy matters. It is not the finish line. Real AI governance must account for how AI changes the threat environment, not only how employees use AI internally. It must connect identity, data, security, human behavior, business process, and incident response. Most importantly, it must create ownership and evidence.
The future will not belong to the organization with the longest policy. It will belong to the one who can answer, quickly and clearly: What was authorized? By whom? From where? For what business purpose? How would we know if that changed, and what would we do next?
The login can be real. The user can complete MFA. The control can appear to work. And the attacker can still get in.
That is not a reason to abandon MFA. It is a reason to stop confusing any single control with a security program.
