Aller au contenu
Software Supply Chain Security

Device code phishing : le PhaaS Greatness s’en mêle

device code phishing

Une nouvelle brique vient renforcer les capacités d’un kit de phishing-as-a-service (PhaaS) déjà actif : le device code phishing. Selon des analyses relayées dans le secteur, le service connu sous le nom de Greatness évoluerait pour exploiter le mécanisme légitime OAuth 2.0 Device Authorization Grant, afin de contourner la MFA et de récupérer des jetons permettant de prendre le contrôle de comptes.

L’enjeu est clair : en s’appuyant sur un flux OAuth prévu pour des contextes où l’utilisateur n’a pas un écran dédié, des attaquants peuvent obtenir des sessions et des jetons sans susciter d’alertes visibles côté victime. Voici ce que l’on sait sur cette menace et comment réduire son impact.

Qu’est-ce que le device code phishing ?

Le device code phishing consiste à abuser d’un flux d’autorisation OAuth 2.0 destiné à des scénarios légitimes. Au lieu d’imposer une saisie dans un faux formulaire d’identification, l’attaque fait utiliser à la victime un code (dans un contexte apparemment normal) pour autoriser silencieusement l’accès.

Cette approche est décrite comme plus “propre” pour l’attaquant que d’autres techniques : l’utilisateur saisit son mot de passe sur une page qui ressemble à l’environnement attendu, et ce qui paraît inhabituel se limite à un code et à une justification plausiblement associée au processus. Résultat : l’attaque peut être moins détectable, notamment pour des utilisateurs qui se fient fortement à l’aspect “authentique” de la page.

Greatness : un PhaaS qui combine plusieurs méthodes

Greatness est présenté comme une plateforme commerciale de PhaaS, accessible via un modèle d’abonnement, qui permet de lancer des campagnes de phishing à grande échelle. Les analyses citées expliquent que le kit ne se limite plus à la collecte de simples identifiants : il intégrerait désormais un ensemble de techniques liées au vol de jetons et à l’exploitation de flux OAuth.

Parmi les capacités évoquées, on retrouve notamment des scénarios d’attaque man-in-the-middle (AiTM) et des abus de consentement OAuth, avec une gestion centralisée depuis un panneau opérateur. Dans ce contexte, le device code phishing serait une extension visant à élargir les angles d’attaque et à faciliter l’obtention de jetons.

Une montée en gamme : de la collecte à l’écosystème d’attaque

Ce qui ressort des observations, c’est la tendance des PhaaS à passer d’outils “simples” de moissonnage à des chaînes d’attaque intégrées. En pratique, cela signifie que des opérateurs peuvent relier des étapes : préparation des leurres, exécution de redirect, contournement de contrôles, puis exploitation des sessions.

Le device code phishing illustre cette évolution : au lieu de s’arrêter à une étape de collecte, l’objectif devient l’obtention de jetons et la persistance d’accès.

Accès et fonctionnement : un abonnement et un panneau opérateur

D’après les informations disponibles, l’accès à Greatness passerait par un canal public sur Telegram, servant de point central pour les annonces et les mises à jour. Les opérateurs intéressés pourraient s’abonner, avec un tarif mentionné à partir de 289 dollars par mois, contre un niveau inférieur rapporté précédemment.

Une fois abonné, l’opérateur obtiendrait un espace de gestion fournissant des éléments utiles à la campagne : statistiques, configuration de domaine, choix de mécanismes de CAPTCHA et des modèles de leurres prêts à l’emploi. Des templates supplémentaires seraient disponibles, incluant des variantes liées à des thèmes comme les boîtes vocales, le partage de documents et des contenus exploitant des codes QR.

La configuration et la prise en charge seraient gérées via des échanges automatisés sur Telegram, avec des identifiants de licence et des étapes d’enregistrement. Le panneau utiliserait également un schéma de domaine propre à l’opérateur, basé sur un format du type “api-[token].[…].”

Des redirects en plusieurs étapes et des protections anti-analyse

Les victimes qui interagissent avec un lien piégé suivent typiquement une chaîne de redirection comprenant plusieurs étapes. Cette chaîne intégrerait des mécanismes visant à réduire l’analyse automatisée (protections anti-analyse), du fingerprinting par User-Agent, ainsi qu’un passage par CAPTCHA avant d’atteindre la destination finale.

Selon les scénarios, la redirection pourrait mener soit vers un proxy AiTM, soit vers un point d’entrée lié au device code phishing. L’objectif est de rendre le chemin d’exécution plus complexe à auditer, et de diminuer la probabilité de blocage durant l’attaque.

Des leurres orientés confiance : quand le fournisseur est réellement client

Un élément marquant des campagnes associées au kit concerne la façon d’exploiter la confiance. Les analyses font état d’envois utilisant des leurres imitant des notifications vocales, en profitant d’exemptions “safe sender” qui permettraient d’atteindre la boîte de réception malgré des contrôles SPF, DKIM et DMARC qui échoueraient.

Ce qui ajoute une dimension supplémentaire, c’est la logique d’attaque basée sur la relation réelle de la cible avec un fournisseur : l’adversaire ne ferait pas seulement “semblant” d’être le bon expéditeur, mais viserait des utilisateurs identifiés comme clients du service imité. Autrement dit, la configuration de confiance en place serait utilisée comme levier.

Après la compromission : rejouer des jetons et étendre l’accès

Les comptes touchés ne seraient pas seulement utilisés pour déclencher une session temporaire. Des analyses indiquent que des jetons d’authentification obtenus seraient rejoués rapidement depuis une infrastructure dédiée, puis que l’attaquant s’en servirait pour parcourir des ressources associées à des environnements Microsoft 365 via l’API Microsoft Graph.

Les données citées concernent des composants typiques : Outlook, Teams, SharePoint, Exchange, OneDrive, mais aussi des éléments comme les contacts et calendriers, ainsi que d’autres applications enregistrées.

Autre point évoqué : la validité prolongée de certains jetons permettrait à l’attaquant de conserver un accès au-delà de la phase initiale. Des signes d’authentification réalisés plus longtemps après la campagne initiale illustreraient cette persistance.

Persistance et détection : nouveaux dispositifs et délais tactiques

Dans le cadre d’attaques menées via le device code phishing, des actions post-incident seraient également observées : enregistrement de nouveaux dispositifs peu après la compromission, afin de générer un jeton de rafraîchissement permettant un accès à long terme.

Les descriptions mentionnent aussi une stratégie de temporisation : attendre plusieurs heures avant de mettre en place des règles malveillantes dans la messagerie ou avant d’exfiltrer des données sensibles. Le but serait d’éviter une détection immédiate.

Autres variantes et contexte : le device code phishing ne vient pas de nulle part

Le device code phishing n’est pas décrit comme la première tentative d’abus de ce type. Des campagnes combinant des techniques issues d’autres kits (notamment autour de la MFA) avec des flux d’autorisation par code pour périphériques auraient aussi été rapportées.

Dans ce contexte, l’industrie rappelle régulièrement que les pages d’attaque emploient des mécanismes d’anti-analyse (CAPTCHA, redirections via des infrastructures légitimes, etc.) afin de compliquer la neutralisation précoce.

Prévenir le device code phishing : leviers techniques et bonnes pratiques

La prévention repose sur plusieurs couches. Une recommandation citée consiste à bloquer l’approche au niveau global dans les politiques de Conditional Access, en particulier en empêchant cette méthode d’authentification lorsque cela est possible.

Au-delà du blocage, il est conseillé de renforcer l’architecture de la MFA. L’idée est de privilégier des méthodes résistantes au phishing, et de sensibiliser les employés à la méfiance face aux codes ou demandes inattendues.

Lorsque le flux OAuth concerné est indispensable pour des cas d’usage précis, la stratégie proposée serait de limiter explicitement l’exception à des utilisateurs, ressources ou scénarios strictement identifiés. Ensuite, il faut auditer en continu et retirer les autorisations dès qu’elles ne sont plus nécessaires.

Conclusion

Le device code phishing représente une évolution préoccupante du phishing moderne : en exploitant un mécanisme OAuth légitime, des attaquants peuvent obtenir des jetons et contourner la MFA sans toujours déclencher de signaux visuels évidents côté victime. L’industrialisation par des PhaaS comme Greatness, avec des campagnes structurées et des fonctionnalités intégrées, rend ces attaques plus accessibles et plus difficiles à contrer sans contrôle d’accès adapté.

La réponse doit donc être défensive et concrète : durcir les politiques Conditional Access, réduire l’exposition aux flux abusés, renforcer la MFA et former les équipes à réagir aux codes ou demandes inattendues. C’est ainsi que l’on diminue la surface d’attaque face à cette technique.

Source: https://thehackernews.com/2026/08/greatness-phaas-adds-device-code.html