Netskope Threat Labs a annoncer le lancement d’un nouvel outil open source destiné à détecter les attaques ciblant la chaîne d’approvisionnement.
L’outil Netskope, Behavioral Evaluation of Application Metrics (BEAM), ne nécessite aucun déploiement d’agent sur les points de terminaison (endpoints).
Il analyse le trafic réseau déjà collecté au sein de votre organisation afin de déterminer si vos applications communiquent avec des hôtes inhabituels susceptibles d’être impliqués dans une attaque.
Cet outil a été présenté lors d’un briefing Black Hat USA 2025.

Attaques de la chaîne d’approvisionnement

En décembre 2020, une cyberattaque massive a ciblé SolarWinds, l’un des principaux fournisseurs de logiciels d’observabilité.
Cette attaque était particulièrement insidieuse, car elle n’exploitait pas directement les vulnérabilités des produits SolarWinds, mais celles de la chaîne d’approvisionnement qui les alimente.
Du code malveillant a été intégré à plusieurs versions des logiciels SolarWinds, compromettant ainsi des milliers d’organisations dans le monde, notamment des agences gouvernementales et de grandes entreprises.

Cet incident a mis en lumière une menace croissante pour la cybersécurité : les attaques contre la chaîne d’approvisionnement logicielle.
Dans ce type d’attaque, les acteurs malveillants ne ciblent pas seulement des entreprises ou des utilisateurs individuels, mais le réseau complexe de fournisseurs, de partenaires et de prestataires qui soutiennent le développement logiciel moderne.

Pourquoi les attaques de la chaîne d’approvisionnement sont-elles si efficaces ?

Les attaques ciblant la chaîne d’approvisionnement sont particulièrement efficaces, car elles exploitent la confiance et la dépendance envers les fournisseurs tiers. Voici quelques raisons :

• Complexité : le développement logiciel moderne implique une multitude de fournisseurs, partenaires et prestataires. Cette complexité crée de nombreux points d’entrée pour les attaquants.

• Manque de visibilité : il est souvent difficile de surveiller et de contrôler l’ensemble de la chaîne d’approvisionnement, ce qui complique la détection d’anomalies ou d’activités suspectes.

• Confiance présumée : les organisations ont tendance à supposer que leurs fournisseurs sont sûrs, ce qui peut conduire à un faux sentiment de sécurité.

Inspiration pour la création de BEAM

L’attaque SolarWinds a suscité de nombreuses discussions sur la manière d’identifier et d’atténuer ce type de menace.
La CISA a publié un avis concernant cette attaque, incluant la recommandation suivante :

« Analyser le trafic réseau stocké pour y déceler des signes de compromission, notamment les nouveaux domaines DNS externes auxquels un petit nombre d’hôtes de l’agence (par exemple, les systèmes SolarWinds) ont établi des connexions. »

Ce conseil s’avère particulièrement intéressant, car il a permis de soulever plusieurs questions.

• Qu’est-ce qui, dans le trafic, permet d’identifier l’application qui le génère, et dans quelle mesure peut-on s’y fier ?

• L’avis mentionne les connexions externes, mais quels éléments précis de ces connexions peuvent être considérés comme suspects ?

• Est-il possible de surveiller en continu le trafic réseau et d’identifier avec succès un comportement inhabituel pour des applications spécifiques ?

Pour répondre à ces questions :

• Dans la communauté de la sécurité, il est généralement admis qu’il faut éviter de se fier aux chaînes User-Agent, car elles peuvent être facilement falsifiées. Cependant, la surveillance d’environnements d’entreprise à travers le monde, composés en grande partie d’utilisateurs non spécialistes de la sécurité, révèle un volume important de trafic contenant des chaînes User-Agent non modifiées.
  Netskope peut ainsi construire des modèles fiables pour les applications fréquemment utilisées, basés sur ces chaînes observées dans le trafic.

• Netskope a examiné de nombreux ensembles de données de trafic réseau anonymisées et identifié des caractéristiques typiques révélant des schémas de trafic suspects.
  Après plusieurs mois de recherche, Netskope a recensé plus de 180 caractéristiques permettant de profiler efficacement le trafic.

• Netskope a ensuite développé une Proof of Concept (PoC) capable d’analyser le trafic réseau et de détecter des comportements anormaux, ce qui a inspiré la création du projet open source BEAM.

Proof of Concept de Nestskope

Netskope a développé un proof of concept (PoC), validé par des tests menés en équipe rouge, qui réalisait trois fonctions principales :

1. Ingestion de données réseau : analyse des fichiers PCAP, HAR, etc.

2. Inspection des chaînes User-Agent : pour déterminer quelles applications affirmaient être à l’origine du trafic.

3. Comparaison du trafic aux modèles établis : afin de vérifier si les applications se comportaient comme prévu, en fonction des caractéristiques sélectionnées.

Netskope a ensuite organisé un exercice équipe rouge / équipe bleue avec une première version de BEAM, incluant des modèles pour plusieurs applications courantes.
Lors de cet exercice, un membre de l’équipe rouge a compromis l’une de ces applications afin qu’elle communique avec une URI C2 personnalisée, sans révéler quelle application avait été compromise ni la destination de la communication.
Pour reproduire un environnement d’entreprise réaliste, Netskope a utilisé un proxy pour surveiller l’ensemble du trafic et déchiffrer le protocole HTTPS.

À ce stade, le trafic était analysé par BEAM à l’aide de modèles préentraînés intégrant plus de 60 caractéristiques distinctes du trafic web.
L’analyse de BEAM a indiqué une probabilité de 94 % que l’application ait été compromise, ce qui a permis d’identifier rapidement la compromission orchestrée par le membre de l’équipe rouge.

Ces résultats encourageants ont motivé l’entreprise à poursuivre le développement du projet et à en publier une version gratuite et open source.

Comment ça fonctionne ?

BEAM accepte des fichiers contenant du trafic HTTPS ou HTTP déchiffré, tels que des fichiers PCAP (via Zeek) ou HAR.
Il analyse le trafic, capture et extrait la chaîne User-Agent afin de déterminer l’application à l’origine du trafic.
Si une chaîne User-Agent n’a jamais été observée auparavant, BEAM tente d’identifier l’application correspondante à l’aide d’un modèle de langage étendu (LLM) et de bibliothèques d’analyse de chaînes User-Agent.

Une fois l’application identifiée, l’association entre la chaîne User-Agent et l’application est enregistrée dans une base de données locale.
Ainsi, lorsque BEAM rencontre à nouveau la même chaîne User-Agent, il peut immédiatement en déduire l’application correspondante.

Le trafic est ensuite enrichi avec les informations applicatives, puis son comportement est comparé à des modèles préentraînés.
Cette comparaison permet d’évaluer la probabilité qu’une application adopte un comportement suspect.

L’analyse comportementale repose sur l’algorithme XGBoost.
Les applications actuellement modélisées sont :

• Asana

• Box

• Canva

• Kanji

• OmniFocus

• Mou

• Spotify

• Todoist

Ces applications ont été sélectionnées car elles figurent parmi les outils tiers les plus populaires, tout en présentant des modèles et des schémas de trafic distincts.
Bien que la version actuelle de BEAM ne contienne des modèles que pour un ensemble limité d’applications, ce processus d’apprentissage a permis a Netskope d’en analyser un éventail beaucoup plus large.

BEAM utilise l’ensemble de caractéristiques (features) suivant :

Catégorie de fonctionnalité	Nombre de fonctionnalités	Description
Résumé de l’application de base	32	Mesures de base telles que le nombre de transactions, les méthodes HTTP, les codes d’état, les domaines
Statistiques numériques	76	Analyse statistique pour time_taken_ms, client_bytes, server_bytes, time_interval_sec
Caractéristiques temporelles	7	Modèles basés sur le temps, détection des rafales, analyse circadienne
Comportement du réseau	9	Modèles d’URL, redirections, erreurs, cohérence des réponses
Analyse de contenu	12	Types de contenu, compression, tailles de réponse, incompatibilités de type
Sécurité du protocole	9	Utilisation HTTPS, versions HTTP, contenu mixte, indicateurs de sécurité
Empreinte digitale d’en-tête	10	Analyse de l’agent utilisateur, détection du navigateur, modèles de référencement
Indicateurs de la chaîne d’approvisionnement	12	Domaines externes, utilisation du CDN, modèles suspects, détection d’automatisation
Base de référence comportementale	7	Diversité IP, volumes de requêtes, taux d’erreur, utilisation des méthodes
Analyse de domaine basée sur des graphiques	12	Relations de domaine, analyse TLD, complexité des sous-domaines
Fonctionnalités totales	186

L’exécuter dans votre environnement

Vous pouvez accéder directement à l’outil sur GitHub : https://github.com/netskopeoss/beam.
Netskope a inclus un exemple de fichier HAR dans BEAM afin que vous puissiez l’essayer immédiatement, sans avoir à utiliser vos propres données.

Voici un exemple de sortie généré à partir de notre fichier HAR de démonstration :

Figure : Capture d’écran de la sortie de démonstration de BEAM

Le fichier HAR analysé ci-dessus contenait principalement du trafic provenant de Chrome et de Box.
Ce trafic a été comparé aux modèles de BEAM.
BEAM a déterminé que le risque de compromission était supérieur à 99 % car le trafic du fichier HAR indiquait une communication entre cette application Box et un point de terminaison (endpoint) inhabituel (xqpt5z.dagmawi.io).

Pour ce faire, il a identifié des schémas de trafic ne correspondant pas aux schémas de communication habituels d’une instance client Box.

Résultats et interprétation

Dans le répertoire beam/predictions, une image accompagnant le graphique SHAP Waterfall est générée pour chaque session analysée.
Ce graphique illustre le raisonnement derrière la prédiction, en décomposant l’impact de chaque caractéristique (feature) sur le résultat du modèle.

Dans l’exemple ci-dessus, le graphique met en évidence les principales raisons pour lesquelles cette session a été identifiée comme potentiellement compromise :

• Connexion à un point de terminaison (endpoint) inhabituel présentant un niveau élevé d’entropie (url_entropy)

• Volume de données transféré vers le serveur nettement inférieur à la normale (min_server_bytes)

• Durée de transaction avec le serveur anormalement courte (median_time_taken_ms)

• Nombre d’hôtes contactés pour les mises à jour différent des habitudes (key_hostname_cnt)

Exécuter BEAM sur vos propres applications

BEAM permet aux utilisateurs de créer des modèles personnalisés pour leurs propres applications, non incluses dans le code source initial.
Pour ce faire, il suffit de capturer le trafic des applications à modéliser sous forme de fichiers HAR ou PCAP.

BEAM nécessite au minimum 50 transactions pour disposer d’un volume de données suffisant à la construction d’un modèle fiable, toutefois, plus le trafic collecté est important, meilleurs seront les résultats.

Comment ça fonctionne ?

La modélisation d’applications sur mesure repose sur des méthodes d’ensemble non supervisées, notamment TensorFlow, Isolation Forests et One-Class Support Vector Machines (SVM).
BEAM tente de créer un modèle personnalisé pour toute application disposant d’un volume de trafic suffisant dans l’échantillon, puis enregistre ce modèle afin qu’il puisse être utilisé par le moteur de détection.

Si une application ne contient pas assez de transactions dans la capture de trafic, BEAM ne crée pas de modèle pour celle-ci.

Exemple d’utilisation

Conclusion

Si ce projet vous intéresse, n’hésitez pas à cloner le dépôt GitHub et à l’essayer par vous-même !

N’hésitez pas à signaler les problèmes, proposer des améliorations ou partager vos suggestions.

Pour en savoir plus concernant la solution Netskope, n’hésitez pas à nous contacter ou demander un devis gratuitement

Source : Netskope