Quick Assist, un outil pratique devenu vecteur d’attaque documenté
Quick Assist — ou Assistance Rapide — est une application Microsoft intégrée nativement à Windows 10 et Windows 11. Elle permet à un utilisateur de partager son écran et de céder le contrôle de sa session à un tiers distant, via une simple connexion Internet sur le port 443. Ce choix de port n’est pas anodin : il s’agit du canal HTTPS standard, ce qui signifie que la quasi-totalité des pare-feux d’entreprise laissent ce flux passer sans inspection particulière.
Microsoft Threat Intelligence a publiquement documenté l’exploitation de Quick Assist par des groupes malveillants dans le cadre de campagnes d’arnaque au support technique. Le scénario type : un attaquant se fait passer pour un technicien Microsoft ou pour le support informatique interne, convainc l’utilisateur d’ouvrir Quick Assist, obtient un code de session à six chiffres, puis prend la main sur le poste en quelques secondes. Une fois connecté, il peut déposer des charges utiles, exfiltrer des données ou persister dans le système.
Ce vecteur est particulièrement efficace parce que l’outil est légitime, signé Microsoft, présent par défaut sur toutes les machines Windows 10 et 11, et que les utilisateurs ont tendance à lui faire confiance. Aucune installation préalable n’est requise côté victime, ce qui accélère l’attaque.
Ce que Microsoft a changé dans la distribution de l’application
Depuis Windows 11, Quick Assist ne fait plus partie de l’installation système figée : Microsoft l’a migré vers le Microsoft Store pour pouvoir le mettre à jour indépendamment des cycles de mise à jour de Windows. Sur Windows 10, il reste encore présent sous forme de composant Windows natif dans certaines versions, mais la tendance est à la découplage progressif.
Ce changement a des conséquences directes pour les équipes IT. Les méthodes classiques de suppression d’un composant Windows — via DISM ou les fonctionnalités optionnelles — ne fonctionnent plus de la même façon. Quick Assist est désormais packagé au format MSIX, le format d’application utilisé par le Store. Son identifiant de package est MicrosoftCorporationII.QuickAssist. Si le Microsoft Store reste accessible sur les postes, l’application peut être réinstallée en quelques clics par n’importe quel utilisateur, même sans droits administrateur locaux.
Pour les administrateurs qui gèrent un parc via Microsoft Intune, ce glissement vers le Store implique d’adopter une approche de gestion des applications packagées, différente de ce qu’on ferait pour bloquer un exécutable Win32 classique. Le contrat de maintenance informatique qui encadre votre parc devrait d’ailleurs mentionner explicitement la gestion des applications Store pour éviter les angles morts de responsabilité.
Bloquer Quick Assist via une stratégie de conformité Intune
La méthode la plus directe dans Intune consiste à créer un profil de configuration de type « Applications » ciblant l’AppX de Quick Assist. Dans le portail Intune (endpoint.microsoft.com), rendez-vous dans « Apps » > « Windows » > « Add », puis sélectionnez le type « Microsoft Store app (new) ». Vous pouvez rechercher Quick Assist directement, puis configurer le mode de déploiement sur « Uninstall » pour le désinstaller des postes ciblés.
Pour aller plus loin et empêcher toute réinstallation, une politique de restriction d’applications via un profil de configuration « Device restrictions » permet de bloquer l’accès au Microsoft Store pour les applications non gérées. Couplée à la désinstallation forcée, cette approche supprime l’application et ferme la porte de réinstallation autonome. L’affectation du profil se fait sur des groupes d’appareils Azure AD — pensez à exclure les groupes de techniciens IT si ceux-ci ont un usage légitime de l’outil.
Une alternative consiste à utiliser un script PowerShell déployé via Intune avec la commande Get-AppxPackage QuickAssist | Remove-AppxPackage, exécutée dans le contexte système. Cette approche est plus rapide à déployer mais moins persistante : elle ne bloque pas une réinstallation ultérieure.
Passer par AppLocker ou WDAC pour un blocage plus strict
Pour les environnements soumis à des exigences de contrôle applicatif renforcé — secteurs réglementés, OIV, environnements à haute sensibilité — une règle AppLocker ou Windows Defender Application Control (WDAC) offre une couche de protection supplémentaire. Même si Quick Assist venait à être réinstallé, son exécution serait bloquée au niveau du système.
Via Intune, une politique WDAC se déploie dans « Endpoint security » > « Attack surface reduction » > « App and browser control ». Vous y définissez une politique XML qui refuse explicitement l’exécution de l’application identifiée par son nom de package ou son certificat éditeur. WDAC opère en mode kernel, ce qui le rend difficile à contourner pour un utilisateur standard.
AppLocker reste une option viable pour les parcs sous Windows 10 Pro ou Enterprise sans WDAC. Une règle de type « Packaged app rules » ciblant MicrosoftCorporationII.QuickAssist bloque son lancement sans nécessiter de politique WDAC complète. Les deux mécanismes sont compatibles avec un déploiement Intune via des profils OMA-URI personnalisés.
Les limites à connaître avant de déployer
Le premier point de friction est la résilience du Store. Si l’accès au Microsoft Store n’est pas restreint indépendamment, un utilisateur peut réinstaller Quick Assist en quelques minutes. La désinstallation seule ne suffit pas dans un environnement où les utilisateurs ont accès au Store.
Le second risque est lié aux mises à jour Microsoft : le nom du package ou son identifiant peut changer lors d’une mise à jour majeure. Une règle ciblant un nom précis peut devenir inopérante sans que personne ne le remarque immédiatement. Prévoir une vérification périodique du nom du package actif est une précaution raisonnable.
Enfin, certains services IT utilisent Quick Assist pour le support interne, faute d’avoir déployé une solution dédiée comme Remote Help (l’outil Microsoft Intune prévu pour cet usage en entreprise). Avant de bloquer globalement, identifiez ces usages et prévoyez une exclusion de groupe ciblée pour les techniciens concernés — ou planifiez la migration vers Remote Help.
Surveiller les tentatives d’utilisation après le blocage
Un blocage sans supervision reste incomplet. Microsoft Defender for Endpoint remonte des événements de type « App blocked » ou « Process blocked » lorsqu’une politique WDAC ou AppLocker empêche le lancement d’une application. Ces événements sont visibles dans le portail Microsoft 365 Defender, sous « Device timeline » pour chaque machine concernée.
Dans Intune, les rapports de conformité des profils de configuration indiquent si la politique de désinstallation a bien été appliquée sur l’ensemble du parc. Un poste qui reste en état « Not compliant » après un délai raisonnable mérite une investigation : problème de connectivité, version de l’agent non à jour, ou tentative de contournement.
La valeur d’un monitoring actif réside dans la détection d’anomalies : un poste sur lequel Quick Assist est tenté d’être relancé plusieurs fois en dehors des horaires métier peut signaler une tentative d’ingénierie sociale en cours. Les alertes Defender peuvent être intégrées dans un SIEM ou dans Microsoft Sentinel pour une corrélation plus large. Le comportement de certains processus Windows légitimes peut prêter à confusion dans ces journaux — garder une baseline propre facilite la détection des écarts réels.
Le blocage de Quick Assist via Intune est une mesure défensive concrète et déployable en quelques heures. Sa vraie robustesse dépend de la combinaison entre désinstallation forcée, restriction du Store, contrôle d’exécution via WDAC, et supervision active des journaux — chaque couche compensant les angles morts des autres.