Sécurité et protection des terminaux
Comment fonctionne techniquement l'identification de l'appelant en direct, ce que les logiciels de sécurité peuvent remarquer et comment préparer votre protection des terminaux
Aperçu
Le client Windows echo fournit l'identification de l'appelant en direct : lors d'un appel Microsoft Teams entrant, il affiche les coordonnées de l'appelant avant même que l'appel ne soit accepté. Pour cela, le client doit détecter la notification d'appel Teams et y lire le numéro de téléphone de l'appelant.
Cette page explique quels mécanismes système le client utilise à cette fin, pourquoi les logiciels de protection des terminaux (antivirus, EDR) peuvent y prêter attention et comment préparer votre environnement afin que des alertes ou faux positifs ne perturbent pas l'exploitation.
Fonctionnement technique de l'identification de l'appelant
Les versions récentes de Microsoft Teams affichent la notification d'appel entrant d'une manière qui n'est plus lisible via les interfaces d'accessibilité de Windows (UI Automation) qu'utilisaient les versions précédentes du client echo. Le client lit donc le numéro de téléphone directement dans la notification telle qu'affichée à l'écran :
| Mécanisme | Ce que fait le client | Portée |
|---|---|---|
| Hook d'événements de fenêtre | Enregistre un hook d'événements système (SetWinEventHook) pour être notifié lorsque la notification d'appel Teams apparaît. Il s'agit d'un mécanisme de notification passif — aucun code n'est injecté dans d'autres processus. | Permanent, passif |
| Capture d'écran | Lorsque la notification d'appel Teams apparaît, le client capture uniquement la petite zone d'écran de cette notification (environ 370 × 250 pixels) pour y lire le numéro de téléphone. | Uniquement pendant qu'un appel sonne, env. 2 captures par seconde pendant quelques secondes |
| Reconnaissance de texte (OCR) | L'image capturée est convertie en texte avec le moteur OCR intégré à Windows puis analysée à la recherche d'un numéro de téléphone. | En mémoire uniquement |
| Interfaces d'accessibilité | Pour les autres fenêtres Teams (p. ex. la fenêtre d'appel active), le client continue d'utiliser Windows UI Automation, comme auparavant. | Piloté par événements |
Tout aussi important, ce que le client ne fait pas :
- Aucun hook clavier ou souris — aucune saisie n'est interceptée (pas de keylogging).
- Aucun enregistrement d'écran continu — les captures n'ont lieu que pendant qu'une notification d'appel Teams est affichée, et se limitent à sa zone.
- Les images capturées ne sont jamais stockées ni transmises. Elles sont traitées en mémoire et immédiatement supprimées. Seul le numéro de téléphone extrait est utilisé — il est envoyé au backend echo pour la résolution du contact, exactement comme dans les versions précédentes.
- Aucune injection de code dans Teams ou tout autre processus.
Pourquoi les logiciels de sécurité peuvent y prêter attention
Les API de capture d'écran sont également utilisées par des logiciels malveillants (screen grabbers, info stealers). La protection des terminaux basée sur le comportement (EDR comme Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, etc.) surveille donc ces schémas d'API. En pratique, cela peut conduire à :
- Des alertes informatives ou de type hunting dans la console EDR, p. ex. « activité de capture d'écran », typiquement déclenchées lors d'un appel entrant.
- Des faux positifs heuristiques, en particulier lorsqu'une version est toute récente ou que la réputation de l'exécutable n'est pas encore établie.
- Des questions de votre SOC lorsque le comportement est observé sans contexte.
Le schéma que les produits de sécurité considèrent comme réellement malveillant — capture continue et furtive combinée à l'exfiltration des images — ne s'applique pas au client echo : les captures sont pilotées par événements, minuscules et purement locales, et l'application est une application de bureau visible et signée.
Préparation recommandée
Ne déployer que le paquet original signé
Distribuez le client Windows echo exactement tel qu'il est livré par Snapbean. Ne repaquetez pas l'application et ne la re-signez pas — la signature de l'éditeur est le principal signal de confiance pour SmartScreen et la protection des terminaux.
Allowlisting par éditeur
Si vous utilisez le contrôle des applications (AppLocker, WDAC) ou l'allowlisting EDR, créez la règle sur la base du certificat de l'éditeur (Snapbean Software AG) plutôt que sur des chemins de fichiers ou des hachages. Les règles d'éditeur survivent aux mises à jour de l'application ; les règles de hachage doivent être renouvelées à chaque version.
Informer votre SOC / documenter le comportement attendu
Ajoutez les éléments suivants à votre runbook SOC ou à la documentation de votre inventaire logiciel :
- Lors des appels entrants, le client Windows echo capture la zone d'écran de la notification d'appel Microsoft Teams (piloté par événements, quelques secondes, env. 370 × 250 pixels) et extrait le numéro de téléphone de l'appelant avec le moteur OCR intégré à Windows.
- Les images capturées sont traitées uniquement en mémoire et ne sont jamais stockées ni transmises.
- Les alertes corrélées (« activité de capture d'écran » de
echoForTeams.exeau moment d'un appel Teams entrant) constituent un comportement attendu.
En cas de faux positif
- Vérifiez la signature du fichier (éditeur : Snapbean Software AG) et le chemin d'installation.
- Restaurez le fichier depuis la quarantaine et ajoutez une exclusion (de préférence basée sur l'éditeur, voir étape 2).
- Signalez le faux positif à votre fournisseur de protection des terminaux — cela améliore le verdict pour tous les clients. Vous pouvez référencer cette page comme documentation éditeur du comportement.