L'accès persistant aux permis OAuth et aux sessions ouvertes après l'engagement n'est pas suffisant pour changer la

La menace ne ressemble pas toujours à une explosion spectaculaire; elle entre souvent par la porte d'entrée parce que quelqu'un l'ouvre. Au cours des dernières semaines, on a observé une tendance répétée dans laquelle les attaquants combinent l'ingénierie sociale avec des mécanismes d'authentification et d'administration légitimes pour obtenir un accès persistant aux comptes et environnements d'entreprise. Les vecteurs les plus courants ne sont pas des vulnérabilités de jour zéro, mais des autorisations accordées par les utilisateurs ou des sessions distantes qui restent ouvertes après un engagement. Cela change la façon dont il doit être répondu: il ne suffit pas de changer le mot de passe.

Techniquement, les abus les plus fréquents profitent du flux de consentement d'OAuth / SSO et des sessions persistantes d'outils de support à distance ou d'accès à distance. Dans le cas d'OAuth, une application malveillante ou une page de consentement falsifié demande à l'utilisateur la permission d'agir en son nom; si l'utilisateur accepte, l'application reçoit des jetons (jeton d'accès et souvent jeton de rafraîchissement) qui vous permettent de garder l'accès sans mot de passe. Ces jetons persistent jusqu'à ce qu'ils soient explicitement révoqués ou expirés, de sorte qu'un changement de mot de passe n'élimine pas nécessairement cet accès. De même, les attaquants utilisent des sessions de bureau à distance actives ou un logiciel de support (TeamViewer, AnyDesk, etc.) pour maintenir un canal direct : fermer la session du système local ne révoque pas toujours l'autorisation du logiciel de télécommande.

Des techniques plus "classiques" qui facilitent la tromperie sont également exploitées : des pages avec des domaines très similaires (typosquatting), des instructions d'installation qui redirigent vers des installateurs malveillants, et des fichiers partagés avec des liens qui demandent l'approbation de l'application ou l'accès aux données. Parallèlement, les campagnes Ransomware et de vol d'identité continuent d'utiliser l'accès obtenu par ces routes pour chiffrer les données, extraire des informations ou déployer des serveurs de commande et de contrôle (C2) cachés derrière des services légitimes.

Personnes touchées est large: les utilisateurs individuels dont le compte ou les services de messagerie en nuage sont la clé de plusieurs plates-formes; les petites et moyennes entreprises qui délèguent à SaaS les applications et le consentement délégué des employés; et les grandes organisations lorsque les configurations SSO, le consentement aux applications et les politiques d'accès ne sont pas durcis. Confirmé : Les concessions de permission par les utilisateurs et les sessions à distance ouvertes sont des vecteurs pratiques et récurrents. Estimation : L'impact réel est multiplié dans les environnements où il y a des comptes avec des rôles administratifs ou l'accès à des actifs critiques; dans de tels cas, la chaîne d'attaque peut monter au ransomware ou au vol de données de masse. Incertain: l'ampleur globale des campagnes simultanées et l'autorité exacte de chaque opération prend généralement du temps pour être confirmée par les équipes d'intervention et les fournisseurs de cloud.

Les conséquences pratiques sont claires: accès persistant sans mot de passe, post et contact vol, exfiltration de fichiers, établissement de porte arrière (permissions, directeurs de service, clés API) et ransomware ou exécution frauduleuse. Un point crucial rapporté par les analystes est que Supprimer le mot de passe ne supprime pas automatiquement les jetons émis ou les fermetures de connexion à distance, de sorte que les portes ouvertes existent toujours si les autorisations et les sessions actives ne sont pas révoquées.

Que faire maintenant : des actions concrètes pour les utilisateurs individuels et les responsables de la sécurité.

Pour tout utilisateur: examinez les applications avec accès à votre compte et supprimez l'inconnu ou inutile; vérifiez les sessions actives et fermez celles que vous ne reconnaissez pas; activez la vérification en deux étapes robustes (de préférence sans SMS : clés FIDO2 ou applications d'authentification); et n'acceptez pas les permissions d'application qui demandent un large accès au courrier, aux fichiers ou aux contacts à moins que vous ne faisiez confiance au développeur. Google maintient une page pour gérer les applications et les sessions connectées qui est utile comme première étape: Gérer l'accès à votre Compte Google. De plus, si vous utilisez des outils de soutien à distance, fermez et vérifiez la liste des appareils autorisés et avisez le fournisseur si vous soupçonnez un abus.

Pour les équipements et les entreprises: mettre en oeuvre des politiques de consentement administratif qui limitent la capacité des utilisateurs d'accepter des demandes de tiers non révisées; permettre l'établissement de listes blanches de demandes approuvées; vérifier le consentement délégué et fournir une formation spécifique sur l'hameçonnage du consentement (comment reconnaître les demandes légitimes d'OAuth contre les imitations). Dans les environnements Microsoft / Azure, examiner et gérer les autorisations d'applications commerciales via le portail Azure AD et envisager de révoquer les approbations de subventions aux applications suspectes; Microsoft offre la documentation pour gérer le consentement et les autorisations d'application dans Azure AD: Gérer le consentement de la demande.

Parmi les autres mesures techniques nécessaires, mentionnons la fermeture des sessions et la révocation des jetons après les incidents (dans certains fournisseurs, il est possible de révoquer les jetons de rafraîchissement ou les « sessions de révocation »), la désactivation des protocoles d'authentification existants qui ne supportent pas l'AMF, l'adoption de politiques d'accès conditionnel (par emplacement, dispositif et risque), la rotation des clés et des secrets d'application, et la surveillance du journal pour détecter les concessions de consentement imprévues ou la création de services primaires. Il est également de bonne pratique de limiter les permis d'application au moindre privilège nécessaire et d'utiliser les outils EDR pour détecter et bloquer les transferts de données inhabituels ou l'exécution d'outils administratifs par des processus non autorisés.

En bref, la normalité de ces intrusions - un appel, un fichier partagé ou un bouton « Octroi » - exige que le permis accordé soit traité comme un risque de sécurité en soi. La réponse efficace combine la révocation explicite des permis et des séances, le durcissement des politiques de consentement et des contrôles préventifs tels que des listes d'AMF et d'applications blanches solides. Passer en revue ce que vous avez déjà accès avant d'ajouter quelque chose de nouveau est, pour l'instant, la règle la plus pratique et efficace pour réduire la surface d'attaque.