Faux support sur Teams : un appel peut mener aux comptes de l’entreprise
Microsoft décrit deux intrusions parties d’un faux appel informatique et d’une session de contrôle à distance. Le changement de mot de passe peut laisser des certificats et sessions utilisables.
Pour aller plus loin
Image générée · SecuFocus
En bref
L’essentiel
Un interlocuteur Teams se présente comme le support et vous demande d’ouvrir Quick Assist ? Vérifiez la demande par un canal interne que vous connaissez avant de lui confier l’écran ou le contrôle. Microsoft a publié le 30 octobre l’analyse de deux intrusions où cette étape a permis d’atteindre les identités de l’entreprise. L’activité ne repose pas sur une faille de Teams : l’usurpation du support et des configurations de certificats trop permissives ont ouvert le chemin.
La bascule se fait au partage du contrôle
Dans les deux cas décrits, des messages ou appels Teams ont imité une équipe informatique. Les utilisateurs ont été amenés à autoriser une session de support à distance, principalement avec Quick Assist. Les attaquants ont ensuite utilisé cette session pour déposer et lancer leurs outils.
Le nom affiché, une apparence professionnelle ou l’usage d’un logiciel légitime ne valident pas l’identité de l’interlocuteur. Microsoft recommande de confirmer les demandes non sollicitées par un canal interne connu et de tenir compte des avertissements sur les contacts externes ou les appels suspects.
Un certificat peut survivre au premier mot de passe compromis
Les attaquants ont examiné Active Directory Certificate Services, le service de certificats de l’entreprise. Dans un cas, un modèle d’émission trop permissif a permis d’obtenir des certificats pour des identités privilégiées. Dans l’autre, un relais d’authentification a conduit à un certificat pour le compte d’un contrôleur de domaine.
Ces parcours, appelés ESC1 et ESC8 dans l’analyse, concernent la configuration de l’infrastructure. Ils ne prouvent pas qu’un simple appel Teams donne les mêmes droits dans toutes les entreprises. Ils expliquent surtout pourquoi réinitialiser le mot de passe du premier utilisateur ou réinstaller son poste peut laisser d’autres accès ouverts.
La réponse doit couvrir les identités et les sessions
Microsoft décrit deux résultats différents. Dans le premier incident, une identité privilégiée exclue du confinement automatique est restée disponible et a ensuite servi à une exfiltration. Dans le second, le client a isolé le poste après les alertes et aucune progression ultérieure n’a été observée.
Pour une équipe de réponse, il faut rapprocher l’appel, la session de support, les processus lancés, les comptes, les certificats émis et les tickets Kerberos. Révoquer un certificat n’annule pas rétroactivement tous les tickets déjà délivrés. Les exclusions de confinement demandent donc une action compensatoire vérifiée, pas seulement une alerte acquittée.
Pour un utilisateur, le geste immédiat reste plus simple : ne donnez pas de code de connexion ou de contrôle à un support arrivé sans demande vérifiée. Si la session a déjà eu lieu, avertissez votre équipe informatique par un canal sûr et gardez ses horaires et traces. SecuFocus n’attribue pas ces cas à un acteur précis : Microsoft ne le fait pas dans cette analyse.
Vérifier, approfondir
Les sources de cet article
Les numéros relient chaque référence aux passages qui l’utilisent. La date indique quand la documentation a été consultée.
Cet article s’appuie sur les sources ci-dessus. Les exercices proposés sont à réaliser sur vos appareils ; SecuFocus ne les présente pas comme des essais menés par la rédaction. Les interfaces et les fonctions peuvent changer. Méthode et corrections.
Citer cet article
Pour retrouver cette lecture ou la partager avec sa référence.