Plus tôt ce mois-ci, Microsoft a découvert SesameOp, un nouveau malware de porte dérobée qui abuse de l'API OpenAI Assistants en tant que canal secret de commande et de contrôle (C2). La découverte a attiré l'attention de la communauté de la cybersécurité. Les équipes de sécurité ne peuvent plus se concentrer uniquement sur les logiciels malveillants des terminaux. Les attaquants utilisent les API légitimes des assistants d’IA publics et les défenseurs doivent s’adapter.
Qu’est-ce que SésameOp ?
SesameOp est un malware de porte dérobée personnalisé. Il est conçu pour maintenir la persistance et, plus important encore, permettre à un attaquant de gérer secrètement les appareils compromis.
Selon Microsoft, la chaîne d'infection combine un composant de charge utile (Netapi64.dll) avec une porte dérobée basée sur .NET (OpenAIAgent.Netapi64) et exploite l'API OpenAI comme canal C2 pour récupérer les commandes cryptées.
Fondamentalement, cela signifie que les attaquants ont abusé de champs tels que les descriptions de l'Assistant, les instructions personnalisées et les messages pour stocker des informations, y compris des commandes, et les exécuter à l'aide du malware SesameOp.
Toutefois, ce qui est vraiment important, c'est que les attaquants ne Non exploiter une vulnérabilité dans le service AI ; ils ont réutilisé une fonction API légitime. Pourquoi est-ce un problème ? Parce que cela signifie que les fonctions légitimes d'IA cloud auxquelles les organisations font confiance et sur lesquelles elles s'appuient peuvent désormais faire partie de l'infrastructure d'un attaquant. Cela signifie que les attaques contre eux sont beaucoup plus difficiles à détecter.
Le recours à des services légitimes pour C2 n’est pas un phénomène nouveau. Cet incident n’est que le dernier d’une histoire de communications secrètes déguisées en usage loyal. Par exemple, plus tôt cette année, Unit42 de Palo Alto a documenté une campagne de malware utilisant des URL Lambda pour C2. En d’autres termes, le modèle n’est pas nouveau, mais l’exécution spécifique l’est.
Alors, qu’est-ce que cela signifie pour la surface de votre API, vos implémentations d’IA et d’agents, et comment les défendez-vous ?
Que signifie SesameOp pour le paysage des risques liés aux API ?
Les API vulnérables ne sont pas nouvelles. Au troisième trimestre 2025, Wallarm a enregistré 1 602 vulnérabilités liées aux API, en hausse de 20 % par rapport au trimestre précédent, suivies de près par les erreurs de configuration représentant 38 % et les problèmes d'authentification défectueux. Plus révélateur encore : 16 % des ajouts au catalogue KEV de CISA étaient liés aux API.
Mais désormais, la surface d’attaque des API est plus compliquée. Les organisations déploient des assistants d'IA, des agents d'orchestration et des microservices basés sur MCP, créant ainsi des points de terminaison, des modèles de trafic et des limites de confiance complètement nouveaux que la plupart des organisations n'ont pas cartographiés ou instrumentés. SesameOp montre comment les attaquants utilisent cette réalité à leur avantage.
L'élément clé à comprendre à propos de SesameOp est que les attaquants n'ont pas brisé l'IA assistante d'OpenAI ; Ils l'ont juste réutilisé. Ils ont transformé un point de terminaison d’IA légitime en un canal de communication secret qui se fond dans le trafic légitime. En termes simples, l'assistant IA fonctionnait techniquement exactement comme il se doit.
SesameOp est emblématique d’un changement plus large dans les tactiques d’attaque des API. Les attaquants s’éloignent des vulnérabilités traditionnelles du code et se concentrent sur l’exploitation de logiques et de services métier légitimes. Ils utilisent les plates-formes cloud comme infrastructure, se fondent dans le trafic typique généré par l’IA et exploitent la confiance que les organisations accordent aux systèmes d’IA.
Les WAF et les passerelles API traditionnels n'ont pas été conçus pour gérer ce problème. Ils ne peuvent pas interpréter les instructions de l'assistant, les flux de travail des agents, la transmission de contexte ou le comportement de MCP. Ils ne comprennent pas quand un point de terminaison d'API se comporte de manière « désactivée » ou est utilisé comme canal secret.
Les défenseurs doivent s'adapter. Ils nécessitent une protection basée sur l'API et l'IA, un blocage en temps réel, une visibilité approfondie et des analyses comportementales capables de détecter lorsqu'un assistant ou un agent cesse de se comporter comme une fonctionnalité du produit et commence à agir comme le système de contrôle d'un attaquant.
Comment Wallarm peut vous aider
Alors, comment les organisations peuvent-elles se protéger contre des menaces comme SesameOp ? Explorons comment les capacités de Wallarm peuvent aider à réduire les risques à chaque étape de l'attaque SesameOp.
Étape 1 : Cartographier la surface d'attaque
L'attaquant SesameOp a exploité un canal API légitime d'assistant IA. La capacité de découverte continue de Wallarm peut révéler des API et des points de terminaison de support d'IA nouveaux ou inattendus, des informations d'identification inconnues ou l'utilisation soudaine de services d'IA à partir de machines qui ne devraient pas leur communiquer.
Étape 2 : Détecter le trafic anormal
Bien que le canal SesameOp C2 semble être des appels d'IA légitimes, les nœuds d'analyse comportementale et de filtrage de Wallarm peuvent détecter des modèles anormaux dans un trafic API par ailleurs normal. Les enquêtes répétitives, les délais de demande inhabituels ou les destinations non approuvées se démarquent car Wallarm base un comportement normal et signale les écarts, même lorsque le domaine lui-même est légitime.
Étape 3 : blocage et prévention
Une fois que la porte dérobée commence à utiliser l'API Wizards comme boucle de commande, récupérant les instructions et publiant les résultats codés, l'application en ligne de Wallarm peut briser le cycle. En bloquant les appels d'API non autorisés, les charges utiles suspectes ou les actions de l'assistant IA non inscrites sur la liste blanche, Wallarm coupe à la fois la récupération des commandes et le filtrage via le point de terminaison de l'IA.
Étape 4 : Réponse et enquête
Si quelque chose passe entre les mailles du filet, les journaux de requêtes détaillés, les métadonnées et les intégrations de Wallarm offrent aux équipes IR une visibilité claire. Cela inclut les appels inhabituels de création d'assistant depuis une machine de développement, les sondes API répétées depuis un poste de travail et les messages codés transmis à un point de terminaison IA. Ce contexte accélère le confinement et facilite la gestion du canal secret C2.
Ce que vous devez faire maintenant et la valeur ajoutée de Wallarm
SesameOp montre que la frontière entre l’utilisation légitime de l’IA et ses abus est très fine. Se défendre contre ce nouveau type de menace commence par renforcer les fondamentaux, mais en s’appuyant sur l’API et l’IA.
Les organisations doivent prioriser :
- Inventaire des API et des points de terminaison d'IA/d'agent : Ne présumez pas que tous les assistants IA, interfaces MCP ou microservices sont visibles. Vous ne pouvez pas protéger ce que vous ne pouvez pas voir.
- Surveillance du trafic entrant et sortant : Les points de terminaison publics de l’IA sont désormais candidats C2. Gardez une trace de qui leur parle, à quelle fréquence et pourquoi.
- Appliquez un contrôle strict sur les clés et les cibles API : Autoriser uniquement les clés approuvées. Suppression des informations d'identification inutilisées. Bloque les destinations inconnues ou non fiables par défaut.
- Utiliser la protection en ligne : La détection seule ne suffira pas à arrêter une porte dérobée qui utilise un point de terminaison d’IA comme boucle de communication. Vous avez besoin d’une protection en ligne capable de bloquer, et pas seulement d’alerter, les appels suspects d’API/d’agent.
- Modification de la sécurité API/AI dans le SDLC : Analysez les définitions d'API, les interfaces MCP, les autorisations des agents et les configurations des points de terminaison avant qu'ils n'atteignent la production.
- Se préparer à des scénarios d'abus légitimes : Toutes les attaques n’impliquent pas de logiciels malveillants. La détection de l'utilisation abusive des API classiques est basée sur l'analyse comportementale et la détection d'anomalies.
- Choisissez une plate-forme qui prend en charge la pile complète : Les applications Web, les API, les microservices, les agents sans serveur et IA font désormais partie de la même surface d'attaque. Vous avez besoin d'une plate-forme qui prend en charge tout.
Mais comment mettre en pratique ces fondamentaux ? Sans réunir d’innombrables outils séparés et se noyer dans le travail manuel ? En partenariat avec Wallarm. Voici comment notre solution peut vous aider :
| Ce que vous devez faire | Comment Wallarm aide |
| API d'inventaire et points de terminaison d'IA/d'agent | Découverte automatisée des API et des points de terminaison d'IA dans tous les environnements |
| Surveiller le trafic entrant/sortant | Analyse des comportements, détection d'anomalies, destinations non approuvées |
| Contrôler les clés et destinations API | Application des politiques, surveillance de l’hygiène des informations d’identification, capacités de mise sur liste verte |
| Blocage en ligne des appels suspects | Filtrage et blocage en temps réel des API et du trafic provenant d'agents malveillants ou violant les politiques |
| Déplacer la sécurité vers la gauche | Intégrations CI/CD, analyse de schéma API, pré-production de découverte de vulnérabilités |
| Détecter les abus légitimes de service | Base de référence comportementale pour détecter les C2 cachés, les boucles de sondage et les charges utiles codées dans un trafic apparemment légitime. |
| Protection complète | Couverture unifiée pour les applications Web, les API, les microservices, les agents sans serveur et les écosystèmes d'IA |
Combattez les menaces évolutives avec Wallarm
Si SesameOp nous dit quelque chose, c'est que nous ne pouvons plus traiter le trafic de l'IA après coup ou supposer que les services légitimes constituent un trafic sûr. Les organisations qui resteront en sécurité seront celles qui traiteront la sécurité des API et de l’IA/des agents comme un problème unifié.
Vous voulez voir comment Wallarm peut vous aider à vous protéger contre l’évolution des menaces ? Planifiez une démo.
Vous souhaitez en savoir plus sur le lien entre l’IA et la sécurité des API ?