Forg365: a PhaaS targets Microsoft 365 via device code — IAM for NIS 2 and GDPR

Excerpt — On July 9, 2026, ZeroBEC unveiled “Forg365,” a phishing‑as‑a‑service platform combining adversary‑in‑the‑middle and “device‑code” against Microsoft 365, with public IOCs. Here is how concrete IAM governance fulfills NIS 2 Art. 21 and GDPR Art. 32.

What happened

On July 9, 2026, researchers at ZeroBEC published an in‑depth analysis of Forg365, a new phishing‑as‑a‑service (PhaaS) platform targeting Microsoft 365 accounts. Forg365 industrializes two vectors: (1) device‑code phishing (abusing the OAuth 2.0 Device Authorization Grant) to trick victims into authorizing, on legitimate Microsoft screens, an attacker‑controlled “device”; (2) adversary‑in‑the‑middle (AiTM) to intercept sessions and cookies. The platform also ships a browser extension (“ForgCookie”) to refresh SSO cookies and maintain mailbox access once the account is compromised. ZeroBEC documents IOCs and telemetry: operator panel at hxxps://logfriend[.]com/login, related nodes (xoday[.]sbs, ructus[.]site, panel.incogxray[.]sbs, IPs 139[.]28[.]38[.]129, 185[.]174[.]101[.]1, 45[.]82[.]84[.]29), and a Comcast address observed during the device‑code sequence (67[.]190[.]46[.]128). Landing pages abuse Cloudflare Pages and delivery leverages Amazon SES and SendGrid to blend into legitimate traffic (ZeroBEC).

The same day, BleepingComputer confirmed that Forg365 combines AiTM and device‑code, uses AI to generate lures, and provides a “ForgCookie” extension to keep access to Microsoft services without re‑authentication. This model aligns with a 2026 trend: the rise of “device‑code” kits (EvilTokens, Tycoon2FA, Kali365) and a sharp increase in OAuth device‑code attacks this year (BleepingComputer).

The applicable legal framework

NIS 2 — Article 21: essential and important entities must implement appropriate and proportionate cybersecurity risk management measures, notably identity and access management policies and multi‑factor authentication, with session and privileged access control. Reference: Directive (EU) 2022/2555 (NIS 2). In Luxembourg, the law of May 5, 2026 transposes NIS 2; the ILR stresses management bodies’ accountability and the obligation to notify significant incidents, with a preliminary alert within 24 hours (Government/ILR; ILR FAQ). To structure policies and evidence, see our page on the NIS 2 framework.

GDPR — Article 32: controllers and processors must implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk (e.g., strong authentication, access management, logging, encryption). Reference: EUR‑Lex — GDPR. For an operational reminder of requirements, see our GDPR resource.

The technical solution to deploy: IAM governance by design

Against Forg365, the decisive measure is not a single “anti‑phishing” tool but IAM governance that makes device‑code and session abuse unproductive. In Microsoft Entra ID:

• Block or restrict the Device Code Flow (OAuth 2.0) via Conditional Access and Authentication flows policies; allow it only for managed devices and justified scenarios (default “block device code” with named exceptions). Monitor “original transfer method = deviceCodeFlow” and “Microsoft Authentication Broker” activity in logs.
• Harden authentication: FIDO2/WebAuthn for interactive use, and pair with session and OAuth consent controls (disable user consent, require admin approval, validate scopes), since Forg365 often avoids password entry.
• Reduce persistence surface: routinely rotate/revoke refresh tokens after a device‑code event, enable Continuous Access Evaluation, Token Protection (context binding), and risk‑based sign‑in frequency.
• Hunt and detect: SIEM/XDR rules for (i) mailbox rule creation, (ii) new device registrations, (iii) non‑interactive Graph access from unexplained IPs, (iv) device‑code sequences followed by anomalous OneDrive/Exchange activity, (v) prompt=none patterns to substrate.office.com, (vi) Forg365 IOCs (logfriend[.]com/api/extension/*, *.pages[.]dev, xoday[.]sbs, panel.incogxray[.]sbs, ructus[.]site, listed IPs).
• Harden email: SEG, DMARC/SPF/DKIM enforcement, detection of remote images/resources (SendGrid) and links redirected to Cloudflare Pages, sandboxes/URL rewriting — Forg365 leverages Amazon SES/SendGrid and pages.dev sites.

Reference standards: ISO 27001 Annex A.8.3/A.8.16 (authentication information, identity management), CIS Controls 6/5/16 (access, MFA, application hardening), NIST CSF 2.0 PR.AA/PR.AC (identity management, access control).

How Luxgap delivers this

• Our 24/7 managed SOC: we ingest Entra ID/Exchange/SharePoint logs and apply ready‑to‑use detections for Forg365 markers (device‑code sequences, prompt=none, mailbox rules, pages.dev artifacts, logfriend[.]com/api/extension calls). On alert, we revoke sessions and tokens, disable unapproved OAuth consents, and execute an M365 playbook (rule purge, delegation audit, MFA resync). Learn more about our managed SOC.
• Our ISO 27001 governance: our consultants (Lead Implementer/Auditor) define IAM policies: default device‑code block, monthly OAuth app review, role separation, evidential logging (NIS 2 Art. 21/GDPR 32), and an ILR‑ready evidence pack.
• Our e‑learning platform: targeted modules for executives/business teams on device‑code lures, QR phishing, and OAuth consent (short scenario: “Never approve a code from an email/third party”), with certificates and engagement metrics.

Realistic case in Luxembourg or the EU

Plausible example: a local fiduciary subject to NIS 2 (indirect essential services) faced “confidential invoice” lures leading to pages.dev sites. In 6 weeks, Luxgap: (1) blocked device‑code by default (named exceptions), (2) enforced FIDO2 + admin‑only consent, (3) equipped the SOC with SIEM rules for Forg365 markers and published IOCs, (4) automated token revocation and mailbox rule purge, (5) trained 120 staff to recognize the “enter a Microsoft code” path as a red flag. Result: two attempts detected and neutralized in under 15 minutes, and an evidence pack ready for ILR/CNPD.

First concrete steps

1. Block Device Code Flow now in Entra (Conditional Access) and create a business‑sponsored exception process with quarterly reviews.
2. Enable admin approval for all OAuth apps and audit existing consents (remove orphaned and overly broad grants).
3. Load Forg365 IOCs into your SIEM/SEG/EDR: domains logfriend[.]com, *.pages.dev, xoday[.]sbs, ructus[.]site, panel.incogxray[.]sbs, IPs 139[.]28[.]38[.]129, 185[.]174[.]101[.]1, 45[.]82[.]84[.]29, and search for /api/extension in proxies.
4. Set alerts for: “original transfer method = deviceCodeFlow”, prompt=none to substrate.office.com, new mailbox rules, recent Entra devices, newly added OAuth consents.
5. Prepare your evidence pack (NIS 2 Art. 21 / GDPR 32): signed IAM policies, logging, detection reports, exercise debriefs, and a 24/72/30 ILR notification plan.

Official sources

• News and IOCs — ZeroBEC: Inside Forg365 (2026‑07‑09); BleepingComputer: Forg365 targets Microsoft 365 (2026‑07‑09)
• NIS 2 framework — Directive (EU) 2022/2555 — Art. 21; Luxembourg: ILR conference (2026‑07‑06) and NIS 2 FAQ (ILR)
• GDPR framework — GDPR — Article 32 (security of processing)