Forg365: un PhaaS cible Microsoft 365 via device code — IAM pour NIS 2 et RGPD

Excerpt — Le 9 juillet 2026, ZeroBEC a dévoilé « Forg365 », une plateforme de phishing‑as‑a‑service qui combine adversary‑in‑the‑middle et « device‑code » contre Microsoft 365, avec IOCs publics. Voici comment une gouvernance IAM concrète matérialise NIS 2 art. 21 et RGPD art. 32.

Les faits

Le 9 juillet 2026, des chercheurs de ZeroBEC ont publié une analyse détaillée de Forg365, une nouvelle plateforme de phishing‑as‑a‑service (PhaaS) visant les comptes Microsoft 365. Forg365 industrialise deux vecteurs : (1) du device‑code phishing (abuse du protocole OAuth 2.0 Device Authorization Grant) qui pousse la victime à autoriser, sur les écrans Microsoft légitimes, un « appareil » contrôlé par l’attaquant ; (2) de l’adversary‑in‑the‑middle (AiTM) pour intercepter des sessions et cookies. La plateforme intègre en plus une extension navigateur (« ForgCookie ») pour rafraîchir les cookies SSO et pérenniser l’accès à la messagerie une fois le compte compromis. ZeroBEC documente des IOCs et de la télémétrie : panneau d’opérateur à hxxps://logfriend[.]com/login, nœuds liés (xoday[.]sbs, ructus[.]site, panel.incogxray[.]sbs, adresses IP 139[.]28[.]38[.]129, 185[.]174[.]101[.]1, 45[.]82[.]84[.]29), et une adresse Comcast observée durant la séquence device‑code (67[.]190[.]46[.]128). Les pages d’atterrissage abusent Cloudflare Pages et la livraison s’appuie sur Amazon SES et SendGrid pour se fondre dans le trafic légitime (ZeroBEC).

Le même jour, BleepingComputer confirmait que Forg365 combine AiTM et device‑code, utilise l’IA pour générer des leurres, et fournit une extension « ForgCookie » pour garder l’accès aux services Microsoft sans ré‑authentification. Ce modèle s’inscrit dans une tendance déjà signalée en 2026 : l’essor des kits « device‑code » (EvilTokens, Tycoon2FA, Kali365) et la hausse spectaculaire des attaques OAuth device‑code cette année (BleepingComputer).

Le cadre légal qui s’applique

NIS 2 — article 21 : les entités essentielles et importantes doivent mettre en œuvre des mesures de gestion des risques en matière de cybersécurité, « appropriées et proportionnées », incluant notamment des politiques de gestion des identités et des accès et l’authentification multifacteur, avec contrôle des sessions et des accès privilégiés. Référence : Directive (UE) 2022/2555 (NIS 2). Au Luxembourg, la loi du 5 mai 2026 transpose NIS 2 ; l’ILR rappelle la responsabilité des organes de gestion et l’obligation de notifier un incident significatif, avec une alerte préliminaire dans les 24 heures (Gouvernement/ILR ; FAQ ILR). Pour structurer vos politiques et preuves, voir notre page dédiée au cadre NIS 2.

RGPD — article 32 : le responsable du traitement et son sous‑traitant doivent mettre en place des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque (ex. authentification robuste, gestion des accès, journalisation, chiffrement). Référence : EUR‑Lex — RGPD. Pour un rappel opérationnel des exigences, consultez notre ressource RGPD.

La solution technique à déployer : une gouvernance IAM « by design »

Face à Forg365, la mesure décisive n’est pas un unique « anti‑phishing », mais une gouvernance IAM (Identity & Access Management) qui rend l’abus du device‑code et des sessions improductif. Concrètement, dans Microsoft Entra ID :

• Bloquer ou restreindre le « Device Code Flow » (OAuth 2.0) par Conditional Access et stratégies d’Authentication flows, ne l’autoriser que pour des appareils gérés et des scénarios justifiés (politique « block device code » par défaut, exceptions nominatives). Surveiller les champs « original transfer method = deviceCodeFlow » et l’activité « Microsoft Authentication Broker » dans les journaux.
• Durcir l’authentification : FIDO2/WebAuthn pour les usages interactifs, mais couplé à des contrôles de session et de consentement OAuth (interdire les consentements utilisateurs, exiger l’approbation admin, vérifier les scopes), car Forg365 évite souvent la saisie du mot de passe.
• Réduire la surface de persistance : rotation/révocation systématiques des refresh tokens après un événement device‑code, Continuous Access Evaluation, Token Protection (liage au contexte), et Sign‑in frequency adaptée au risque.
• Chasse et détection : règles SIEM/XDR sur (i) créations de règles de boîte aux lettres, (ii) nouveaux appareils enregistrés, (iii) accès non interactifs Graph depuis IPs inexpliquées, (iv) séquences « device‑code » suivies d’activité OneDrive/Exchange anormale, (v) patterns prompt=none vers substrate.office.com, (vi) IOC de Forg365 (logfriend[.]com/api/extension/*, *.pages[.]dev, xoday[.]sbs, panel.incogxray[.]sbs, ructus[.]site, IPs citées).
• Durcir l’email : SEG, DMARC/SPF/DKIM en enforcement, détection d’images/ressources distantes (SendGrid) et de liens redirigés vers Cloudflare Pages, sandboxes/URL rewriting — Forg365 s’appuie sur Amazon SES/SendGrid et pages pages.dev.

Normes de référence : ISO 27001 Annexe A.8.3/A.8.16 (informations d’authentification, gestion des identités), CIS Controls 6/5/16 (accès, MFA, application hardening), NIST CSF 2.0 PR.AA/PR.AC (gestion des identités, contrôle d’accès).

Comment Luxgap déploie cela

• Notre SOC managed 24/7 : nous intégrons les journaux Entra ID/Exchange/SharePoint et appliquons des détections prêtes à l’emploi sur les marqueurs Forg365 (séquences device‑code, prompt=none, règles de boîte, artefacts pages.dev, appels logfriend[.]com/api/extension). En cas d’alerte, nous révoquons sessions et tokens, coupons les consentements OAuth non approuvés, et ouvrons un playbook M365 (purge règles, audit délégations, resynchronisation MFA). Découvrez notre SOC managed.
• Notre gouvernance ISO 27001 : nos consultants (Lead Implementer/Auditor) cadrent les politiques IAM : blocage par défaut du device‑code, revue mensuelle des apps OAuth, séparation des rôles, journalisation probante (évidence NIS 2 art. 21/RGPD 32), et trame de preuve pour l’ILR.
• Notre plateforme e‑learning : modules ciblés pour dirigeants/équipes métiers sur les leurres « device‑code », QR phishing et consentement OAuth (mise en situation courte : « Ne jamais valider un code d’un email/tiers »), avec certificats et mesure d’engagement.

Cas concret au Luxembourg ou en UE

Exemple réaliste : une fiduciaire de la place, soumise à NIS 2 (services essentiels indirects), subissait des leurres « confidential invoice » menant à des pages pages.dev. En 6 semaines, Luxgap a : (1) bloqué le device‑code par défaut (exceptions nominatives), (2) mis FIDO2 + consentement admin‑only, (3) outillé le SOC avec des règles SIEM sur les marqueurs Forg365 et les IOCs publiés, (4) automatisé la révocation des tokens et la purge des règles de boîte, (5) formé 120 collaborateurs à reconnaître le parcours « saisir un code Microsoft » comme signal d’alerte. Résultat : deux tentatives détectées puis neutralisées en moins de 15 minutes, et un dossier de preuves prêt pour l’ILR/CNPD.

Premiers pas concrets

1. Bloquez maintenant le Device Code Flow dans Entra (Conditional Access) et créez un processus d’exception sponsorisé par le métier, avec révision trimestrielle.
2. Activez l’approbation admin pour toute app OAuth et lancez un audit des consentements existants (supprimez les grants orphelins et à large périmètre).
3. Chargez les IOCs Forg365 dans vos SIEM/SEG/EDR : domaines logfriend[.]com, *.pages.dev, xoday[.]sbs, ructus[.]site, panel.incogxray[.]sbs, IPs 139[.]28[.]38[.]129, 185[.]174[.]101[.]1, 45[.]82[.]84[.]29, et recherchez /api/extension dans les proxys.
4. Paramétrez des alertes sur : « original transfer method = deviceCodeFlow », prompt=none vers substrate.office.com, nouvelles règles de boîte, appareils Entra récents, consentements OAuth ajoutés.
5. Préparez le dossier de preuve (NIS 2 art. 21 / RGPD 32) : politiques IAM signées, journalisation, rapports de détection, comptes‑rendus d’exercices et plan de notification ILR 24/72/30.

Sources officielles

• Actualité et IOCs — ZeroBEC : Inside Forg365 (09/07/2026) ; BleepingComputer : Forg365 vise Microsoft 365 (09/07/2026)
• Cadre NIS 2 — Directive (UE) 2022/2555 — art. 21 ; Luxembourg : Conférence ILR (06/07/2026) et FAQ NIS 2 (ILR)
• Cadre RGPD — RGPD — article 32 (sécurité du traitement)