Quantify the value of Netskope One SSE – Get the 2024 Forrester Total Economic Impact™ study

fermer
fermer
  • Pourquoi Netskope signe chevron

    Changer la façon dont le réseau et la sécurité fonctionnent ensemble.

  • Nos clients signe chevron

    Netskope sert plus de 3 400 clients dans le monde, dont plus de 30 entreprises du Fortune 100

  • Nos partenaires signe chevron

    Nous collaborons avec des leaders de la sécurité pour vous aider à sécuriser votre transition vers le cloud.

Un leader sur SSE. Désormais leader en matière de SASE à fournisseur unique.

Découvrez pourquoi Netskope a été classé parmi les leaders de l'édition 2024 du Gartner® Magic Quadrant™️ pour le Secure Access Service Edge à fournisseur unique.

Recevoir le rapport
Pleins feux sur les clients visionnaires

Découvrez comment des clients innovants naviguent avec succès dans le paysage évolutif de la mise en réseau et de la sécurité d’aujourd’hui grâce à la plateforme Netskope One.

Obtenir l'EBook
Pleins feux sur les clients visionnaires
La stratégie de commercialisation de Netskope privilégie ses partenaires, ce qui leur permet de maximiser leur croissance et leur rentabilité, tout en transformant la sécurité des entreprises.

En savoir plus sur les partenaires de Netskope
Groupe de jeunes professionnels diversifiés souriant
Votre réseau de demain

Planifiez votre chemin vers un réseau plus rapide, plus sûr et plus résilient, conçu pour les applications et les utilisateurs que vous prenez en charge.

Obtenir le livre blanc
Votre réseau de demain
Netskope Cloud Exchange

Le Netskope Cloud Exchange (CE) fournit aux clients des outils d'intégration puissants pour optimiser les investissements dans l'ensemble de leur infrastructure de sécurité.

En savoir plus sur Cloud Exchange
Aerial view of a city
  • Security Service Edge signe chevron

    Protégez-vous contre les menaces avancées et compatibles avec le cloud et protégez les données sur tous les vecteurs.

  • SD-WAN signe chevron

    Fournissez en toute confiance un accès sécurisé et performant à chaque utilisateur, appareil, site et cloud distant.

  • Secure Access Service Edge signe chevron

    Netskope One SASE fournit une solution SASE cloud-native, entièrement convergée et à fournisseur unique.

La plateforme du futur est Netskope

Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG), and Private Access for ZTNA built natively into a single solution to help every business on its journey to Secure Access Service Edge (SASE) architecture.

Présentation des produits
Vidéo Netskope
Next Gen SASE Branch est hybride - connectée, sécurisée et automatisée

Netskope Next Gen SASE Branch fait converger Context-Aware SASE Fabric, Zero-Trust Hybrid Security et SkopeAI-Powered Cloud Orchestrator dans une offre cloud unifiée, ouvrant la voie à une expérience de succursale entièrement modernisée pour l'entreprise sans frontières.

En savoir plus Next Gen SASE Branch
Personnes au bureau de l'espace ouvert
L'architecture SASE pour les nuls

Obtenez votre exemplaire gratuit du seul guide consacré à la conception d'une architecture SASE dont vous aurez jamais besoin.

Obtenir l'EBook
SASE Architecture For Dummies eBook
Optez pour les meilleurs services de sécurité cloud du marché, avec un temps de latence minimum et une fiabilité élevée.

Découvrez NewEdge
Autoroute éclairée traversant des lacets à flanc de montagne
Permettez en toute sécurité l'utilisation d'applications d'IA générative grâce au contrôle d'accès aux applications, à l'accompagnement des utilisateurs en temps réel et à une protection des données de premier ordre.

Découvrez comment nous sécurisons l'utilisation de l'IA générative
Autorisez ChatGPT et l’IA générative en toute sécurité
Solutions Zero Trust pour les déploiements du SSE et du SASE

En savoir plus sur la confiance zéro
Bateau roulant en pleine mer
Netskope obtient l'autorisation FedRAMP High Authorization

Choisissez Netskope GovCloud pour accélérer la transformation de votre agence.

En savoir plus sur Netskope GovCloud
Netskope GovCloud
  • Ressources signe chevron

    Découvrez comment Netskope peut vous aider à sécuriser votre migration vers le Cloud.

  • Blog signe chevron

    Découvrez comment Netskope permet la transformation de la sécurité et de la mise en réseau grâce à l'accès sécurisé à la périphérie des services (SASE).

  • Événements et ateliers signe chevron

    Restez à l'affût des dernières tendances en matière de sécurité et créez des liens avec vos pairs.

  • Définition de la sécurité signe chevron

    Tout ce que vous devez savoir dans notre encyclopédie de la cybersécurité.

Podcast Security Visionaries

Prévisions pour 2025
Dans cet épisode de Security Visionaries, Kiersten Todt, présidente de Wondros et ancienne directrice de cabinet de l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA), nous parle des prévisions pour 2025 et au-delà.

Écouter le podcast Parcourir tous les podcasts
Prévisions pour 2025
Derniers blogs

Découvrez comment Netskope peut faciliter le parcours Zero Trust et SASE grâce à des capacités d'accès sécurisé à la périphérie des services (SASE).

Lire le blog
Lever de soleil et ciel nuageux
SASE Week 2024 A la demande

Apprenez à naviguer dans les dernières avancées en matière de SASE et de confiance zéro et découvrez comment ces cadres s'adaptent pour répondre aux défis de la cybersécurité et de l'infrastructure.

Explorer les sessions
SASE Week 2024
Qu'est-ce que SASE ?

Découvrez la future convergence des outils réseau et sécurité dans le modèle économique actuel, dominé par le cloud.

En savoir plus sur SASE
  • Entreprise signe chevron

    Nous vous aidons à conserver une longueur d'avance sur les défis posés par le cloud, les données et les réseaux en matière de sécurité.

  • Carrières signe chevron

    Join Netskope's 3,000+ amazing team members building the industry’s leading cloud-native security platform.

  • Solutions pour les clients signe chevron

    Nous sommes là pour vous et avec vous à chaque étape, pour assurer votre succès avec Netskope.

  • Formation et accréditations signe chevron

    Avec Netskope, devenez un expert de la sécurité du cloud.

Soutenir le développement durable par la sécurité des données

Netskope est fière de participer à Vision 2045 : une initiative visant à sensibiliser au rôle de l'industrie privée dans le développement durable.

En savoir plus
Soutenir le développement durable grâce à la sécurité des données
Contribuez à façonner l'avenir de la sécurité du cloud

At Netskope, founders and leaders work shoulder-to-shoulder with their colleagues, even the most renowned experts check their egos at the door, and the best ideas win.

Rejoignez l’équipe
Carrières chez Netskope
Les professionnels du service et de l'assistance de Netskope veilleront à ce que vous puissiez déployer avec succès notre plateforme et en tirer toute la valeur.

Aller à Solutions clients
Services professionnels Netskope
Sécurisez votre parcours de transformation numérique et tirez le meilleur parti de vos applications cloud, Web et privées grâce à la formation Netskope.

En savoir plus sur les formations et les certifications
Groupe de jeunes professionnels travaillant

Introduction lien lien

Les attaquants ajoutent à leurs logiciels malveillants des capacités de commande et de contrôle (C2) nouvelles et sophistiquées qui leur permettent d'échapper facilement aux défenses statiques courantes basées sur les signatures IPS ou les listes de blocage IP/domaine/url en utilisant des outils C2 courants et largement disponibles tels que Cobalt Strike, Brute Ratel, Mythic, Metasploit, Sliver et Merlin. Ces outils fournissent des capacités de post-exploitation, notamment de commande et de contrôle, d'escalade des privilèges et d'actions sur l'hôte, et ont été conçus à l'origine pour les tests de pénétration et les opérations de l'équipe rouge.

Cependant, les attaquants ont détourné et intégré ces mêmes boîtes à outils à des fins malveillantes, car de nombreux produits sont libres, comme Mythic et Merlin, tandis que d'autres produits commerciaux, comme Cobalt Strike et Brute Ratel, ont été volés par des attaquants par le biais de copies piratées ou de fuites de code source. Cela a effectivement transformé ces mêmes outils en cadres C2 adverses pour une post-exploitation malveillante.

Ces outils peuvent facilement façonner et modifier de nombreux paramètres des communications C2, ce qui permet aux logiciels malveillants d'échapper encore plus facilement et plus longtemps aux défenses actuelles et de causer des dommages plus importants au sein des réseaux des victimes, notamment : le vol de davantage de données, la découverte de données plus précieuses, l'indisponibilité des applications/services professionnels et le maintien d'un accès caché aux réseaux en vue de dommages ultérieurs.

Les approches actuelles de détection des derniers logiciels malveillants utilisant des cadres C2 utilisent des signatures et des indicateurs statiques, y compris la détection des exécutables d'implants, des signatures IPS pour la détection du trafic C2, et des filtres IP/URL qui sont inadéquats pour traiter les profils dynamiques et malléables des outils de cadre C2 largement disponibles.

Une nouvelle approche est nécessaire, qui ne soit pas aussi rigidement liée aux attaques connues, mais qui soit basée sur la détection d'anomalies d'un ensemble complet de signaux introduits dans des modèles d'apprentissage automatique entraînés, avec un suivi fin du périphérique et du risque pour l'utilisateur. Cette approche complétera les approches existantes, mais peut augmenter considérablement les taux de détection tout en maintenant les faux positifs à un niveau bas et en assurant une protection future contre l'évolution des schémas de trafic C2 qui sont facilement activés par ces mêmes outils d'encadrement C2.

Ce document examine les lacunes des approches actuelles et l'efficacité accrue de l'utilisation d'une approche ciblée d'apprentissage automatique avec des signaux de réseau supplémentaires et des mesures de risque fines basées sur des modèles au niveau de l'utilisateur et de l'organisation. Nous examinons également certains des principaux défis à relever pour tester l'efficacité d'une solution de détection de balises C2.

 

Cadres adverses C2 lien lien

Cobalt Strike, Metasploit, Mythic et Brute Ratel sont quelques-uns des outils de simulation d'adversaires commerciaux et open-source conçus à l'origine pour les tests de détection de logiciels malveillants de l'équipe rouge. Ces boîtes à outils sont parfois appelées outils d'émulation de la menace ou cadres C2, car elles offrent un ensemble de fonctionnalités (Gill) permettant de simuler l'activité d'une menace réelle pendant les opérations de l'équipe rouge, en mettant l'accent sur les parties de commandement et de contrôle post-exploitation de la chaîne d'attaque.

Il se peut que nous utilisions certains de ces termes de manière interchangeable tout au long du document, mais nous utiliserons généralement les cadres C2 pour souligner que ces outils sont utilisés par des acteurs malveillants pour avoir un impact sur les environnements de production et que le problème à résoudre va bien au-delà des simulations ou des émulations réalisées par de sympathiques équipes rouges internes.

Ces outils C2 ont été intégrés, piratés ou volés et utilisés par de nombreux attaquants ("Cobalt Strike : International law enforcement operation tackles illegal uses of 'Swiss army knife' pentesting tool"), y compris des acteurs étatiques tels que l'APT29 russe dans SolarWinds ("SolarWinds Supply Chain Attack Uses SUNBURST Backdoor") et le TA415 de la RPC (Larson et Blackford) pour améliorer et faire évoluer les capacités de communication furtive de divers RAT, botnets et logiciels malveillants dotés d'un système C2.

Cobalt Strike est l'outil le plus populaire du cadre C2, et nous l'utilisons comme exemple spécifique tout au long de ce document, bien que les observations s'appliquent à tous les outils similaires. Le diagramme d'architecture de haut niveau de Cobalt Strike ci-dessous présente ses composants de base (Rahman) et le flux d'attaque en cours d'exécution.

Architecture de haut niveau Cobalt Strike

Figure 1 : Architecture de haut niveau de Cobalt Strike

 

#

Étape de l'attaque

Description

1

Accès initial / infectionVecteur d'infection initial, y compris le téléchargeur et le chargeur de la charge utile de la balise.

2

Appeler à la maison (C2)

Beacon appelle le serveur d'équipe en utilisant typiquement HTTP/HTTPS/DNS. Peut utiliser l'obscurcissement du domaine/de l'IP via des redirecteurs tels que les proxys, le fronting de domaine (par ex. CDN) ou le masquage de domaine. Les balises peuvent également enchaîner les communications pour contourner la segmentation des réseaux internes.

3

Commandement et contrôle de l'attaquantL'attaquant contrôle Beacon et émet diverses commandes. Vous pouvez utiliser des scripts Aggressor pour automatiser/optimiser workflow.

4

Exécuter des commandesLa balise peut utiliser Execute Assembly (exécutables .NET) dans un processus séparé ou Beacon Object Files dans la session/le processus de la balise, ce qui permet d'étendre les capacités de post-exploitation. L'injection de mémoire est utilisée pour éviter d'être détectée par les systèmes de défense des points finaux qui se concentrent sur les fichiers et l'activité du disque associés aux fichiers malveillants.

5

Actions sur l'hôteDe nombreuses actions intégrées sont fournies pour de nouvelles capacités via des extensions telles que BOF ou Execute Assembly.

Tableau 1 : Chaîne d'attaque utilisant le cadre Cobalt Strike C2

 

Cobalt Strike et d'autres outils similaires permettent de configurer facilement et largement le trafic HTTP/S, produisant un trafic C2 qui semble souvent inoffensif, qui ressemble à un trafic HTTP/web normal et qui est similaire au trafic d'un navigateur web ou d'une application populaire. Les outils sont fournis avec des configurations par défaut qui émulent à la fois des logiciels malveillants connus et des applications valides connues.

Bien que le DNS soit également pris en charge en tant que protocole C2, nous nous concentrerons sur le C2 HTTP/S car il reflète la majeure partie du trafic réseau entrant/sortant d'une organisation, est plus complexe en raison de la variété des applications utilisant HTTP/S, et attire la majorité des acteurs malveillants qui tentent de se cacher parmi le bruit du réseau, y compris les balises C2 légitimes et bénignes.

Les boîtes à outils sont hautement configurables (via des profils malléables) et peuvent facilement faire varier le moment, la fréquence, le volume, les protocoles d'application, les IP/domaines de destination, les agents utilisateurs, les en-têtes HTTP, les verbes HTTP, les URI, les paramètres, les certificats SSL/TLS, le délai de balisage avec une gigue aléatoire, et la charge utile/le contenu. Les outils du cadre C2 permettent également un grand nombre d'actions post-exploitation, qui sont chiffrées, téléchargées et exécutées en mémoire, ce qui rend l'activité post-compromission très difficile à détecter sur les points finaux.

Nous nous concentrerons sur les capacités spécifiques de communication C2 des outils du cadre C2 (par exemple, le balisage C2), sur la facilité avec laquelle les communications peuvent être modifiées (par exemple, via les profils malléables C2 de Cobalt Strike) et sur les défis posés aux organisations qui tentent de détecter les logiciels malveillants furtifs.

Il existe de nombreuses ressources intéressantes sur les fonctionnalités des profils malléables (Gill) de Cobalt Strike, mais nous nous contenterons de souligner certaines des caractéristiques les plus utilisées. Voici un extrait du profil malléable permettant d'imiter l'application du navigateur Gmail dans Cobalt Strike (Mudge) :

Figure 2 : Profil C2 malléable (gmail)

Figure 2 : Profil C2 malléable (gmail)

 

Voici quelques-unes des fonctionnalités et des domaines clés du profil :

Section | Paramètres

Description | Capacités

certificat https# Utilisez un certificat existant ou générez un certificat auto-signé comme dans cet exemple.
# exemple.
options globales# Ces options globales ci-dessous fixent le temps de sommeil de la balise C2 à 60 secondes avec une gigue aléatoire de +/- 15%.
# une gigue aléatoire de +/- 15%, montrant la possibilité de varier le timing de l'appel de retour pour éviter une
# une détection aisée.
set sleeptime "60000";
set jitter "15";


# D'autres options globales spécifient des paramètres d'action post-exploitation sur l'hôte tels que le
# nom du processus créé pour exécuter des commandes utilisant l'injection en mémoire ou le
# pipename utilisé pour les communications IPC. Ces éléments ne sont pas pertinents pour C2.
set pipename "interprocess_##";
set spawnto "userinit.exe";
http-get# Le chemin uri utilisé pour les communications avec le serveur beacon->peut être modifié à l'aide d'une liste
set uri "/_/scs/mail-static/_/js/";

# Les communications avec le client (serveur beacon->), y compris les cookies, les en-têtes et l'encodage, # peuvent toutes être spécifiées et modifiées facilement.
# peuvent toutes être spécifiées et modifiées facilement au niveau du protocole HTTP
client {
metadata {}
header {}
}


# De même, les communications entre le serveur et la balise>peuvent également être modifiées au niveau du protocole HTTP
# au niveau du protocole HTTP
serveur {
header {}
}


# Cobalt Strike permet de façonner le flux de communication bidirectionnel entre le # client Beacon et le serveur C2 Team ("A Beacon HTP").
# client Beacon et le serveur C2 Team ("A Beacon HTTP Transaction Walk-through") :
# 0. http-stager {} optional stager to download full Beacon
# 1. http-get {client} client -- call home → server
# 2. http-get {server} server -- cmds → client
# 3. http-post {client} client -- cmd output → server
# 4. http-get {server} server -- confirm → client

Tableau 2 : Description du profil C2 malléable (gmail)

 

Comme on peut le voir ci-dessus, de simples modifications de ces profils peuvent facilement changer le comportement des communications C2 pour imiter les applications courantes, leurs balises et le trafic web. Il existe plus de 240 profils publics malléables pour le seul Cobalt Strike, facilement utilisables ou modifiables.

 

Méthodes de détection actuelles lien lien

Les approches actuelles de détection du trafic C2 malveillant tendent à faire correspondre des signatures d'octets codées en dur ou à utiliser des expressions régulières pour faire correspondre la charge utile ou les en-têtes (signatures IPS), ou sont basées sur la correspondance de listes d'adresses IP/domaines/URL. Ces approches sont statiques et facilement contournées par la nature dynamique et configurable des boîtes à outils du cadre C2 intégrées par les attaquants.

Signatures IPS

Pour illustrer les défis posés par les solutions IPS, voici l'une des règles Snort permettant de détecter le cheval de Troie Zeus (Snort) :

Figure 3 : Règle Snort (cheval de Troie Zeus)

Figure 3 : Règle Snort (cheval de Troie Zeus)

 

Snort et de nombreuses solutions IPS autorisent diverses correspondances de contenu ou d'en-têtes aux niveaux 3 et 4, ainsi qu'au niveau de l'application, comme indiqué par les verbes d'action dans la règle. De nombreuses correspondances, telles que l'option content rule, sont des correspondances statiques octet/caractère, tandis que l'option pcre rule est une correspondance d'expression régulière.

Si l'on examine côte à côte le côté adverse (par exemple, le profil malléable C2 pour gmail vu précédemment) et le côté défensif (par exemple, la règle Zeus snort), la correspondance statique codée en dur et la fragilité sont évidentes. Imaginez qu'un attaquant ait créé et déployé une nouvelle variante de Zeus qui utilise Cobalt Strike et qu'un IPS Snort ait mis en place la règle Zeus ci-dessus qui a détecté efficacement le nouveau logiciel malveillant. L'attaquant pourrait facilement modifier un caractère du profil, par exemple en ajoutant un espace dans MSIE pour éviter la correspondance : content :"|3B 20|MSIE|20|"; et le logiciel malveillant pourrait échapper à la signature IPS.

Bien qu'il y ait une connaissance du contexte et un suivi de l'état, l'approche de la signature IPS est intrinsèquement limitée en raison de sa correspondance statique, qui entraîne des faux négatifs et une évasion facile (changer littéralement un caractère dans un champ peut contourner une règle IPS).

Cela ne veut pas dire que les solutions IPS ne sont pas utiles. Les signatures IPS devraient plutôt être conservées, car elles constituent une défense périmétrique utile, bloquant de manière rapide et efficace de nombreux exploits connus sur le réseau. Dans ce cas, même si un IPS n'atteint qu'un taux de détection de 60 %, ces 60 % peuvent être bloqués ou faire l'objet d'une alerte facilement, ce qui évite un traitement coûteux en aval.

Listes de blocage IP/URL

D'autres approches traditionnelles, telles que l'utilisation de listes de blocage (IP ou URL), sont souvent appliquées dans le but d'empêcher l'accès initial ou le téléchargement de logiciels malveillants lors de la navigation sur le web, ainsi que pour bloquer le trafic C2 potentiel.

Les listes de blocage posent souvent un problème : elles sont souvent obsolètes, ce qui entraîne des faux positifs, et elles sont réactives, c'est-à-dire qu'elles sont mises à jour après la compromission de la cible n° 1 ou du patient n° 0.

Ce phénomène est exacerbé par les techniques d'indirection IP/domaine utilisées pour masquer le domaine ou l'adresse IP du serveur C2. Cobalt Strike utilise des redirecteurs, qui peuvent être aussi simples que des proxys IP, pour masquer le véritable domaine ou l'IP du serveur C2. Il existe également d'autres techniques telles que l'utilisation de CDN (domain fronting) ou le masquage de domaine (domain masquerading), qui tirent parti de la non-concordance entre TLS (SNI) et HTTPS (host) pour dissimuler le domaine malveillant final à certains filtres de sécurité des URL.

Heuristique du trafic sur le réseau

Une autre approche consiste à utiliser des heuristiques, généralement appliquées à des modèles de trafic réseau basés sur le volume ou le temps. L'exemple classique consiste à détecter des communications sortantes régulières (par exemple, toutes les 60 minutes), éventuellement à destination d'une adresse IP sans enregistrement A du DNS.

Pour échapper à la détection, les boîtes à outils du cadre C2 permettent de configurer facilement un facteur aléatoire dans le délai de balisage en utilisant le paramètre de gigue dans un profil malléable Cobalt Strike :

Figure 4 : Paramètres du profil malléable C2 (synchronisation du balisage)

Figure 4 : Paramètres du profil malléable C2 (synchronisation du balisage)

 

Ces paramètres spécifient un intervalle d'appel à domicile de 60 secondes +/- 15 %, ce qui signifie que l'intervalle réel variera de 51 à 69 secondes, échappant ainsi aux contrôles simples des balises récurrentes à intervalles constants.

Efficacité

Le problème des approches actuelles est qu'elles ne détectent pas efficacement les communications C2 malléables et qu'elles sont facilement contournées, même si elles sont réglées de manière spécifique. Ils permettent de détecter efficacement les techniques d'attaque statiques à l'aide d'indicateurs bien connus, mais passent à côté d'attaques plus dynamiques ou sophistiquées ou créent un grand nombre de faux positifs.

À titre d'exemple, en testant les profils malléables Cobalt Strike C2 les plus courants provenant de dépôts publics, les solutions IPS prêtes à l'emploi telles que Snort et Suricata ont détecté nettement moins de 20 % des communications C2 provenant des boîtes à outils de cadre C2 les plus courantes.

Même après avoir spécifiquement ajouté des règles pour faire correspondre autant de profils publics que possible, en optimisant pour ce test spécifique, la couverture n'a pu augmenter raisonnablement qu'à ~60% sans introduire de faux positifs significatifs qui seraient très problématiques dans un environnement de production.

L'efficacité pose de nombreux problèmes : non seulement les faux positifs sont plus nombreux, mais la configuration résultante est rigidement construite pour le test spécifique en question et peut facilement être contournée par une légère modification des profils. En fin de compte, environ 40 % des profils ne sont pas détectés, ce qui représente un taux de faux négatifs très élevé. Sans parler des faux négatifs supplémentaires d'un attaquant déterminé qui personnalise les profils C2 pour imiter des applications existantes bien connues d'une manière légèrement différente.

Nouvelle approche de détection lien lien

Une approche plus efficace est nécessaire, basée non pas uniquement sur des indicateurs statiques, mais sur des modèles d'apprentissage automatique ciblés qui peuvent détecter des anomalies dans le trafic réseau en utilisant une multitude de signaux réseau qui indiquent une activité de commande et de contrôle suspecte par rapport à ce que les applications valides font normalement pour les utilisateurs spécifiques au sein de l'organisation spécifique. En outre, des mesures de risque fines devraient être suivies au niveau de l'utilisateur afin de fournir les mesures d'atténuation les plus précises et les plus efficaces. Des innovations dans ces trois domaines sont nécessaires pour améliorer considérablement la détection des balises C2 furtives à partir des outils du cadre C2 :

Figure 5 : Nouvelle approche de la détection des balises C2

Figure 5 : Nouvelle approche de la détection des balises C2

 

Signaux complets

Un ensemble complet de signaux est nécessaire et devrait inclure les caractéristiques de la source, de la destination et du trafic, telles que les certificats SSL/TLS utilisés à la fois à la source (environnement interne du logiciel malveillant) et à la destination (serveur C2), le domaine/IP/URL, les caractéristiques de la source telles que les caractéristiques de l'agent utilisateur/du processus, la taille/la rapidité/les schémas du trafic, les en-têtes HTTP/la charge utile/l'URL, pour n'en citer que quelques-uns.

En examinant divers signaux dans le temps, le volume, les couches du réseau et le profil global du trafic, la détection comportementale peut fournir un mécanisme général et efficace pour détecter les derniers logiciels malveillants par le biais d'une activité de balisage C2 suspecte et malveillante.

Figure 6 : Signaux complets

Figure 6 : Signaux complets

 

Les types de signaux comportent plusieurs dimensions :

  • Flux du réseau : attributs de la source et de la destination, ainsi que modèles de trafic
  • Couches réseau : différents signaux des couches 3 à 7 (anomalies dans les en-têtes TCP/IP, les empreintes SSL/TLS, les en-têtes HTTP/charges utiles et le contenu au niveau de l'application)
  • Temps : fréquence, schémas temporels anormaux pour détecter les activités peu fréquentes et lentes
  • Données : contenu et volume (tailles de paquets anormales, rafales, statistiques cumulatives)

En outre, il existe plusieurs types de signaux :

  • Basé sur le modèle de trafic (volume, moment, contenu), y compris le balisage répété en liaison avec un agent utilisateur ou un domaine inhabituel.
  • Heuristique (par exemple, bureaux d'enregistrement suspects ou empreintes SSL malveillantes connues)
  • Anomalies (domaine, agents utilisateurs ou empreintes SSL inhabituels)

Un point important est que certains des signaux susmentionnés font partie des approches actuelles et des solutions existantes. Cela renforce l'idée qu'un signal particulier tel qu'un pic de trafic (volume important) n'est ni bon ni mauvais, ni efficace ni inefficace en soi. C'est plutôt le contexte et le traitement du signal qui sont déterminants. Lorsqu'il est utilisé à la périphérie d'un réseau pour bloquer/autoriser le trafic, un signal susceptible de générer des faux positifs peut entraîner de graves problèmes opérationnels. Cependant, lorsqu'il est introduit dans un système de détection des anomalies qui intègre ce signal dans une mesure granulaire du risque (voir ci-dessous) et dans un modèle bien entraîné, il peut être extrêmement efficace pour détecter de nouvelles menaces de manière robuste et avec un faible taux de faux positifs.

Anomaly Detection

La détection efficace des balises C2 provenant des boîtes à outils C2 nécessite des modèles d'apprentissage automatique basés sur une gamme plus complète de signaux afin d'identifier les boîtes à outils C2 d'aujourd'hui et les futurs comportements suspects sur le réseau qui pourraient indiquer une activité C2.

Figure 7 : Détection des anomalies

Figure 7 : Détection des anomalies

 

La détection des anomalies doit être basée sur des modèles au niveau de l'utilisateur/périphérique, du rôle et de l'organisation. En d'autres termes, les anomalies supposent que nous disposions d'une base de référence "normale" d'activité ou de comportement à laquelle se comparer. La détection d'une activité suspecte peut se produire dans différentes circonstances. Il existe des anomalies basées sur les actions d'un utilisateur par rapport à sa base historique "normale" ou par rapport à la base "normale" de l'organisation ou par rapport à des personnes ayant des rôles similaires. Tous ces modèles ont des cas d'utilisation valables qui sont exclusifs les uns des autres, et une bonne approche intégrera plusieurs modèles avec des portées différentes.

Données de formation

Les ensembles de données d'entraînement doivent comprendre à la fois du trafic malveillant et du trafic bénin :

  • Le trafic malveillant peut être simulé à l'aide d'outils de test C2 généraux, de tests de balisage adverses C2 spécifiques basés sur des configurations publiquement disponibles d'outils de cadre C2, ainsi que de configurations personnalisées du point de vue d'une équipe rouge et d'exercices officiels d'équipe rouge.
  • Le trafic bénin ou valide est mieux recueilli auprès d'un nombre significatif d'utilisateurs réels dans des organisations réelles sur une période suffisamment longue pour normaliser les biais des utilisateurs et des organisations.

Les ensembles de données de formation sont l'envers des ensembles de données de test, et il convient de consacrer beaucoup de temps à l'analyse et à la validation de bonnes données de formation et de test. Certains des facteurs permettant d'obtenir de bons ensembles de données de test sont examinés dans une section ultérieure.

Mesures granulaires des risques

Le résultat de la détection des anomalies est essentiel. La meilleure approche ne consiste pas à bloquer/autoriser ou à alerter/silencer sur la base d'un signal brut, mais à suivre et à ajuster des mesures de risque fines au niveau de l'utilisateur, du rôle et de l'organisation, qui peuvent ensuite être utilisées pour des actions correctives telles que l'alerte, l'accompagnement ou le blocage.

Cette approche du suivi et de la gestion des risques est fondamentalement différente de celle qui est généralement utilisée aujourd'hui. La plupart des défenses périmétriques préventives, qui bloquent, alertent ou autorisent le trafic, sont généralement statiques et sujettes à des taux élevés de faux positifs. Le résultat net est que ces solutions sont activées avec une politique conservatrice de blocage de certains risques connus, ce qui ouvre la voie à un grand nombre de faux négatifs. Dans le cas des pare-feu, nous constatons des problèmes de faux positifs dus à des actions de blocage trop agressives basées sur des renseignements sur les menaces IP. En ce qui concerne les solutions IPS, nous avons discuté des problèmes de faux positifs posés par les signatures statiques qui tentent de détecter le trafic C2 dynamique et hautement configurable.

Mais les faux positifs au niveau du périmètre peuvent être très utiles en tant que signal pour une couche plus intelligente. Dans ce scénario, nous ne l'utiliserions pas pour une évaluation binaire (autoriser/bloquer, alerter/ignorer) mais comme une mesure fine du risque ajustée dans le temps (par ex. ) avec un seuil défini avant de prendre des mesures. Une mesure granulaire du risque, par exemple un score de risque de 1000 (aucun risque) à 0 (risque extrême) pour un utilisateur, un périphérique ou même une adresse IP, nous permet de modéliser le spectre de gris associé aux menaces du monde réel, où il y a rarement des évaluations claires 100 % malveillantes ou 100 % bénignes.

Le concept est illustré dans la figure suivante, où trois signaux différents peuvent être détectés, ce qui, en soi, est susceptible de donner lieu à des faux positifs. Cependant, lorsqu'ils sont associés à un risque incrémental et évalués par un modèle d'apprentissage automatique, ces mêmes signaux permettent d'évaluer le risque cumulatif au fil du temps et, en fin de compte, de détecter une anomalie avec un degré de confiance élevé.

Figure 8 : Mesures granulaires des risques

Figure 8 : Mesures granulaires des risques

 

Notez que les signaux de cet exemple peuvent ne pas être aussi simples que des signaux statiques. Par exemple, un "agent utilisateur et un certificat SSL/TLS non reconnus par un domaine inhabituel" peuvent constituer une anomalie par rapport à la base de référence "normale" du trafic pour cet utilisateur spécifique ou par rapport à des fonctions similaires d'utilisateurs ou de l'ensemble de l'organisation. Un "bureau d'enregistrement suspect" peut être un amalgame de la réputation d'un domaine corrélée au fil du temps. Et le "balisage périodique" n'est plus une simple correspondance d'un taux ou d'une durée fixe, mais peut au contraire détecter une activité anormale mais régulière et répétée dans une fenêtre temporelle qui s'apparente à une activité liée à un bot par opposition à des appels de démon d'application valides.

Dans la pratique, cela nous permet d'ajuster un score de risque de manière progressive et appropriée sur la base d'un signal de faible fidélité. Il n'entraîne aucune action de blocage ou d'alerte jusqu'à ce que le score de risque cumulé dépasse un seuil élevé défini. Cela nous permet d'identifier les cas où il existe un grand nombre d'indicateurs peu fiables et peu risqués qui, lorsqu'ils sont combinés à un indicateur plus fiable et plus risqué pour un utilisateur ou un périphérique particulier, génèrent cumulativement une alerte et une action en cas de risque critique, avec un risque de faux positifs considérablement réduit.

Évaluation et test

Une nouvelle approche peut être théoriquement valable et en pratique échouer lamentablement, et la preuve se résume souvent à des données ou à des tests. Les fournisseurs de solutions et les organisations à la recherche de solutions ont besoin d'une approche solide pour tester les nouvelles menaces et évaluer les solutions. Pour obtenir des résultats précis, il est essentiel d'effectuer des tests avec un ensemble de données diversifié comprenant à la fois du trafic malveillant et bénin.

Trafic bénin
Le trafic bénin doit être réaliste, complet et similaire à la production en termes de nombre d'utilisateurs et d'activité. Le bon trafic, qui dépend souvent de l'utilisateur, doit être étudié sur un large échantillon d'utilisateurs et sur une période de temps raisonnable. Cet ensemble de données de test mesurera les taux de faux positifs (FP). Les principales variations dans les ensembles de données seront les signaux des clients tels que les applications, les agents utilisateurs et les certificats SSL/TLS utilisés par les clients, les signaux de destination vus dans les domaines/adresses IP de destination, et les signaux de trafic dans les en-têtes, la charge utile, la taille et le temps.

La bonne nouvelle est que le trafic bénin est facilement collecté dans le cadre des activités quotidiennes des utilisateurs de l'organisation, tandis que la mauvaise nouvelle est qu'il doit être validé comme étant bénin. L'approche pratique consiste à échantillonner statistiquement le trafic bénin jusqu'à un certain facteur de confiance raisonnable, puis à passer la majeure partie du temps à se concentrer sur les alertes de la solution de détection C2 testée, en vérifiant que les alertes sont de vrais ou de faux positifs. En d'autres termes, il s'agit d'échantillonner et de vérifier en amont pour constituer une base de référence, de supposer que l'ensemble de données bénignes est propre, puis de procéder à l'identification des faux positifs sur la base des tests.

Figure 9 : Test de trafic bénin

Figure 9 : Test de trafic bénin

 

Trafic malveillant
L'utilisation de profils publics à partir d'outils C2 populaires constitue une base solide pour tester le mauvais trafic. Ces profils représentent des configurations pratiques et fréquemment utilisées qui échappent aux défenses et permettent de mesurer les taux de faux négatifs (FN). Toutefois, il convient d'accorder une grande attention à l'obtention d'un ensemble de données représentatif du "mauvais trafic", car il existe potentiellement plusieurs niveaux de couverture et ce que les ensembles de données testent, comme l'illustre le diagramme suivant :

Figure 10 : Test du trafic malveillant

Figure 10 : Test du trafic malveillant

 

  1. Les outils de simulation de violation et d'attaque tels que SafeBreach sont excellents pour les tests de couverture et les tests répétés. Leurs scénarios de test C2 comprennent généralement au moins une simulation de l'activité des cadres C2. L'avantage est qu'un large éventail de fonctionnalités est disponible, y compris les attaques générales de logiciels malveillants, avec des interfaces graphiques et des architectures bien conçues, ainsi que des procédures de test et des rapports reproductibles. Ces outils peuvent vous fournir un large éventail de scénarios, notamment : activité à faible débit, infrastructure IaaS/CSP, trafic HTTP et non HTTP, trafic SSL/HTTPS et usurpation d'identité d'une variété d'agents utilisateurs.
  2. Outils du cadre C2 (profils publics). Les tests approfondis des cadres C2 nécessitent un travail ciblé. Une approche consiste à créer un ensemble de données de test basé sur les profils publics spécifiques des outils du cadre C2, par exemple Cobalt Strike. Ces profils publics malléables ont tendance à être largement partagés et utilisés par de nombreux utilisateurs et acteurs malveillants, car ils comprennent des émulations utiles d'applications bénignes telles que gmail. Cette approche permet d'effectuer des tests généralement plus complets sur les cadres C2 spécifiques.
  3. Outils du cadre C2 (profils personnalisés). La personnalisation interne des profils C2 malléables peut permettre de tester les cadres C2 de manière encore plus réaliste. Ces configurations personnalisées peuvent être réalisées au cours des opérations internes de l'équipe rouge. Cela demande plus de travail et d'investissement car les opérateurs de l'équipe rouge doivent maîtriser les outils du cadre C2.
  4. Attaques réalistes. Les tests les plus réalistes impliquent des tests en boîte noire avec des programmes externes de tests d'intrusion ou de recherche de bogues (bug-bounty). Dans ces scénarios, les exigences de l'exercice sont soigneusement construites pour exiger ou encourager des exploits POC réels qui utilisent des outils de cadre C2 spécifiques ou tout comportement de balisage C2, avec des mises en garde pour éviter la détection sur une certaine période de temps. L'objectif de ces exercices n'est pas seulement de tester les vecteurs d'accès initiaux, ce qui est la norme, mais de se concentrer sur les activités postérieures à l'intrusion en montrant une capacité à installer une charge utile de porte dérobée avec une activité C2 démontrée. Cela permet d'enrichir l'ensemble des données de test au-delà des cadres C2 et de tester le code POC de la porte dérobée avec des communications C2 personnalisées. Il s'agit également d'un excellent test de la résistance de tout outil de détection face à un "attaquant" compétent utilisant des TTP différentes ou personnalisées.

Les essais peuvent impliquer une ou plusieurs approches, mais des choix explicites doivent être faits sur la manière de créer, de rassembler et de valider les ensembles de données d'essai et sur la manière de mesurer les résultats escomptés. La création et la collecte des ensembles de données de test sont très importantes pour que les tests puissent être automatisés et facilement répétés.

Il est également essentiel de mesurer des paramètres complets pendant les tests : vrais et faux positifs, vrais et faux négatifs. Si la collecte de tous les indicateurs semble évidente, il est difficile d'être précis dans la définition et clair et reproductible dans la méthodologie de mesure, ce qui conduit à des résultats trompeurs.

Cibles faussement positives et faussement négatives
Avec les nouvelles menaces évasives créées par les cadres C2, toutes les nouvelles solutions de détection n'auront pas de taux de FP et de FN largement acceptés. Toutefois, il est essentiel de définir des objectifs en matière de PC et de PN. Avec des ensembles de données de test de qualité connue, il est possible de créer des références pour l'environnement et les utilisateurs/périphériques actuels, ce qui permet ensuite de créer des objectifs raisonnables par rapport à ces références.

Par exemple, supposons qu'une organisation ne disposant que d'un IPS commence à évaluer de nouvelles solutions de détection C2 et qu'elle ne sache pas exactement quels sont les taux de FP/FN acceptables. L'organisation peut encore définir des objectifs raisonnables en suivant une méthodologie de test telle que la suivante :

  • Créez des données de test de qualité pour le trafic bénin sur la base des données de production et le trafic malveillant sur la base, par exemple, des profils publics C2 malléables pour Cobalt Strike, et en validant manuellement des échantillons de ces ensembles de données.
  • Créer une méthodologie de test claire et reproductible en définissant des outils de test et de mesure.
  • Mesurer tous les paramètres (TP/TN/FP/FN) pendant les essais.
  • Testez de nouvelles solutions et comparez les mesures. Par exemple, l'IPS pourrait être réglé spécifiquement pour obtenir de meilleurs taux de TP pour le trafic malveillant, tout en veillant à ce que les taux de FP/TN/FN soient également mesurés et validés. L'efficacité des différentes solutions peut alors être correctement évaluée, en particulier en ce qui concerne l'impact total sur l'organisation, tel que décrit dans la section "Impact" ci-dessous.
  • Testez de nouveaux ensembles de données et comparez-les. Cherchez à personnaliser les ensembles de données pour refléter les ajustements raisonnables effectués par un attaquant. Il y a plusieurs façons de procéder.
    • Par exemple, lorsque vous testez Cobalt Strike, ses profils C2 malléables peuvent être facilement modifiés pour émuler des applications bénignes un peu différentes ou des applications bénignes complètement nouvelles qui sont utilisées au sein de l'organisation spécifique. Cela peut se faire en reniflant le trafic HTTP/S sortant via un proxy.
    • Testez non pas un mais plusieurs outils du cadre C2, car ils diffèrent en termes de capacités et de techniques. L'utilisation d'un autre outil d'encadrement C2 est également une bonne chose, car la mise en forme du trafic C2 sera différente.
    • La création d'une charge utile d'essai personnalisée avec ses propres communications C2 codées à la main est une autre façon de modifier les ensembles de données d'essai, mais c'est elle qui demande le plus de temps et d'investissement.

Test de résilience
En testant de nouveaux ensembles de données avec différentes solutions, nous obtenons également des informations précieuses sur la rigidité et la résilience des différentes solutions. Dans le présent document, nous avons soulevé le fait que les approches basées sur le codage en dur et les signatures sont non seulement moins efficaces pour détecter les cadres C2, mais qu'elles sont également rigides, ce qui se traduit par des taux élevés de FP/FN et permet un contournement facile avec de simples modifications de l'attaque, comme des changements de profil malléables.

La résilience de toute solution peut être testée en s'assurant que les ensembles de données sont modifiés dans les limites du raisonnable (c'est-à-dire en restant dans la même catégorie de TTP). En d'autres termes, nous pouvons effectuer un test de résilience réaliste en modifiant les communications C2 dans l'ensemble de données de trafic malveillant à l'aide de profils C2 malléables et en surveillant les taux TP/TN/FP/FN. Nous voyons comment la couverture varie et nous comprenons également quels changements doivent être apportés à la solution de détection pour maintenir la couverture pour des cibles TP/TN/FP/FN particulières.

Le fait de refaire des tests avec des ensembles de données modifiés de cette manière est analogue à un attaquant qui modifie sa TTP. Elle évalue la résilience et l'efficacité de la nouvelle solution de détection, car nous pouvons voir si elle est toujours capable de détecter des changements dans la même catégorie de techniques de menace (communications C2 sur HTTP/S).

Impact des faux positifs et des faux négatifs
La mesure des taux de FP/FN est une bonne chose et permet une amélioration relative, mais nous devons également mesurer ou au moins estimer l'impact des FPS et des FN, sans quoi il est impossible d'évaluer l'utilité réelle d'une solution de détection. En d'autres termes, un taux de PF de 1 % ou une amélioration de 5 % du taux de PF n'a pas de contexte si nous ne pouvons pas mesurer l'impact de ce 1 % ou de ce +5 % d'une manière qui ait un sens pour les décideurs en matière de budget de sécurité.

Voici deux approches qui peuvent aider à traduire les taux de TP/TN/FP/FN en un impact plus quantifiable :

  1. Impact de l'utilisateur dans le temps : Examinez le nombre absolu de faux positifs équivalant aux taux de FP et normalisez-le en tant que taux par utilisateur au fil du temps. Il s'agit d'une mesure qualitative qui a souvent plus de sens que les taux en % ou les chiffres absolus. Par exemple, plutôt que 1% de PF ou 2 437 faux positifs, il peut être plus facile d'évaluer l'impact de 0,1 faux positif par utilisateur et par jour. S'il s'agissait d'une passerelle web sécurisée, quelqu'un dans l'organisation pourrait déterminer si une certaine cible de PF est acceptable en se basant sur l'impact de l'utilisateur au fil du temps. Dans ce cas, les logiciels malveillants basés sur le cadre C2 entraînent des violations, et l'impact sur les utilisateurs se caractérise davantage par des temps d'arrêt ou des pertes de données par utilisateur sur une période donnée. Nous avons N% de chances de perdre X dollars par utilisateur chaque année. Il s'agit souvent d'estimations approximatives, mais tout début est utile car il peut être révisé et amélioré par des itérations régulières. Si l'impact est évalué en termes d'utilisateurs au fil du temps, il devient alors facile d'évaluer les solutions de détection ou de protection, dont le prix est souvent calculé en fonction du nombre d'utilisateurs par an.
  2. Impact des opérations de sécurité en termes de temps, d'argent et de probabilité de violation. Outre l'impact sur l'utilisateur final, il convient d'évaluer l'impact sur l'administration, en particulier sur les personnes chargées des opérations qui consacrent souvent du temps à la gestion des alertes de détection. Le temps passé à répondre aux alertes bruyantes peut être traduit directement en coût salarial en ETP. Le facteur supplémentaire de la fatigue des alertes a un impact réel qui peut être estimé en termes d'efficacité (temps de réponse) et, plus important encore, en termes de perte de temps et d'attention face à des menaces ayant un impact réellement plus important, qui sont perdues ou qui ne font pas l'objet d'une enquête. Ce dernier impact devient un facteur de l'impact de la violation - les violations sont plus susceptibles de se produire lorsque les opérations de sécurité ont trop de faux positifs à examiner et à supprimer.

Une évaluation d'impact est souvent le seul moyen de comprendre des éléments cruciaux tels que le coût réel de l'efficacité de la détection. Par exemple, une solution de détection trop agressive avec une configuration de FN faibles et de FP élevés est inutile et nuisible parce que les opérations de sécurité perdent un temps excessif à répondre à des alertes de faible fidélité au lieu de s'engager dans des activités à plus forte valeur ajoutée. De même, une solution de détection trop conservatrice, avec des PF faibles mais des FN élevés, expose l'organisation à un risque élevé en cas de violation potentielle, ce qui peut être inacceptable du point de vue de l'évaluation globale des risques.

L'impact doit être estimé et évalué en même temps que les principaux paramètres TP/FP/TN/FN.

Des tests réalistes

L'équipe rouge est composée d'êtres humains, et non d'outils automatisés de détection des brèches ou de tests d'intrusion. Il est fortement recommandé d'utiliser non seulement des utilisateurs et des environnements de production pour tester les solutions de balisage C2, mais aussi des scénarios adverses réalistes tels que les tests d'intrusion ou la chasse aux bogues. En ajustant les montants des primes et les exigences pour montrer l'implantation explicite et les actions post-exploitation réussies des boîtes à outils de cadre C2 populaires, nous pouvons rendre le "trafic malveillant" réel et mesurable. Cette exigence pourrait être élargie à toute activité de balisage C2, y compris un code personnalisé pour tester la résilience de la solution de détection, et l'exigence de test devrait inclure la démonstration d'une activité de balisage quotidienne réussie et l'exécution d'une commande pendant une semaine, sans détection.

Si un test d'intrusion externe ou un programme de chasse aux bogues est répété, les différences de taux de détection seront mesurables et utiles pour évaluer l'efficacité et le retour sur investissement.

Grâce à une approche rigoureuse des essais, non seulement l'efficacité des essais sera mesurée de manière exhaustive, mais des cibles et des objectifs continus pourront être créés par rapport à une base de référence actuelle/historique. De plus, si les mêmes tests et mesures sont effectués pour plusieurs solutions, il est facile de comparer les performances et de prendre des décisions d'achat ou de mise en œuvre.

Considérations relatives à la conception

La recherche et la conception impliquant ces concepts et l'approche globale sont discutées plus en détail dans : Systèmes et méthodes de sécurité pour la détection de commandement et de contrôle malléables (Mulugeta).

 

Avantages lien lien

Détection des anomalies des nouvelles menaces inconnues

Cette approche permet d'atténuer efficacement les menaces inconnues en s'appuyant sur des modèles d'apprentissage automatique formés sur le comportement des applications propres aux utilisateurs au sein d'une organisation. La mesure granulaire du risque utilisateur réduit considérablement les faux positifs.

En revanche, les approches réactives existantes reposent sur l'identification d'une première victime ou d'un patient zéro (un agneau sacrifié pour le bien commun), suivie d'une analyse et d'une recherche des fournisseurs qui peuvent prendre des jours, voire des mois, avant qu'un fournisseur ne publie une nouvelle signature ou une nouvelle règle pour bloquer la nouvelle menace pour les clients qui n'ont pas encore été attaqués. De par sa conception, cette approche est inefficace pour bloquer les menaces malléables nouvelles et émergentes.

Une approche de détection des anomalies, s'appuyant sur des modèles d'apprentissage automatique spécifiques et adaptés, peut détecter de manière unique les comportements suspects sans nécessiter un cycle d'analyse, de publication et de mise à jour. L'approche reste robuste même si les tactiques de lutte contre les menaces évoluent.

Analyse complète des signaux

La détection d'anomalies sur un ensemble complet de signaux tels que le temps, le volume, les communications TCP/IP, les empreintes SSL/TLS, les charges utiles des protocoles d'application, permet de détecter efficacement les communications sophistiquées et malléables de C2.

Détection de la boîte à outils des adversaires

Cette approche permet de détecter efficacement l'utilisation des derniers outils et cadres C2, ainsi que les activités nouvelles et suspectes de balisage C2, en s'appuyant sur la détection des anomalies à l'aide d'un large éventail de signaux réseau spécifiques aux utilisateurs dans l'environnement et en les comparant au trafic valide et inoffensif dans l'environnement.

Efficacité de la détection

Les approches actuelles (signatures IPS + blocages IP/domaine/URL) passent à côté d'un grand nombre de communications C2 avancées dans les derniers logiciels malveillants (de 40 % à 80 % selon les scénarios de test).

En utilisant une nouvelle approche avec un modèle d'apprentissage automatique adapté, la détection d'anomalies d'un riche ensemble de signaux et une mesure granulaire du risque, plus de 85-95% de ces attaques actuellement éludées peuvent être détectées.

Il en résulte un taux global de détection des vrais positifs de plus de 95 %, avec un minimum de faux positifs.

 

Conclusion lien lien

Les boîtes à outils des cadres C2 ont permis aux attaquants d'utiliser des techniques sophistiquées pour échapper à la détection des systèmes de commandement et de contrôle (C2). Notamment, des outils très répandus comme Cobalt Strike, Brute Ratel et Mythic sont accessibles sous forme de code source libre ou de code commercial piraté ou volé.

Les approches statiques traditionnelles, qui s'appuient fortement sur des signatures et des indicateurs statiques tels que les listes de blocage IP/URL, sont confrontées à de graves limitations et sont facilement contournées par ces menaces en constante évolution.

Pour relever ce défi, il est nécessaire d'adopter une approche fondamentalement différente qui s'appuie sur des modèles d'apprentissage automatique. Ces modèles intègrent un ensemble complet de signaux de réseau, spécialement formés au niveau de l'utilisateur et de l'organisation. En outre, ils utilisent des mesures fines du risque pour l'utilisateur afin de réduire les faux positifs et de mesurer le gris souvent associé aux menaces.

L'efficacité des méthodes d'apprentissage automatique doit être soigneusement évaluée par les utilisateurs. Il est essentiel de procéder à des essais rigoureux sur un banc d'essai robuste contenant du trafic malveillant et bénin pour déterminer leur efficacité en matière de détection et d'atténuation de ces nouvelles menaces.

 

References lien lien

"Cobalt Strike : Une opération internationale d'application de la loi s'attaque aux utilisations illégales de l'outil de pentesting "couteau suisse"". The Record from Recorded Future News, 3 juillet 2024, https://therecord.media/cobalt-strike-law-enforcement-takedown. Consulté le 23 août 2024.

Gill, Andy. "Comprendre les profils Cobalt Strike - Mise à jour pour Cobalt Strike 4.6". ZSEC Blog, 13 avril 2022, https://blog.zsec.uk/cobalt-strike-profiles/. Consulté le 23 août 2024.

Larson, Selena, et Daniel Blackford. "Cobalt Strike : L'outil APT favori des logiciels criminels". Proofpoint, 29 juin 2021, https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware.

Mudge, Raphael. "Profils C2 malléables : gmail". Malleable-C2-Profiles normal gmail.profile, rsmudge, 28 février 2018, https://github.com/rsmudge/Malleable-C2-Profiles/blob/master/normal/gmail.profile.

Mulugeta, Dagmawi. "Systèmes et méthodes de sécurité pour la détection de commandes et de contrôles malléables". Systèmes de sécurité et méthodes de détection de commandement et de contrôle malléables, Free Patents Online, 20 août 2024, https://www.freepatentsonline.com/12069081.html.

Rahman, Alyssa. "Cobalt Strike | Defining Cobalt Strike Components & BEACON." Google Cloud, 10 décembre 2021, https://cloud.google.com/blog/topics/threat-intelligence/defining-cobalt-strike-components/.

Grognement. "SID 1:25050". Règle Snort : MALWARE-CNC Win.Trojan.Zeus variant connexion sortante, Snort, https://www.snort.org/rule_docs/1-25050.

"SolarWinds Supply Chain Attack Uses SUNBURST Backdoor". Google Cloud, 13 décembre 2020, https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor/.