Contenu de détection proactive : CVE-2019-0708 vs ATT&CK, Sigma, Elastic et ArcSight

Je pense que la majeure partie de la communauté de la sécurité a convenu que la vulnérabilité CVE-2019-0708 est d’une priorité critique à traiter. Et bien que dire « corrigez vos affaires ! » semble être la première chose à laquelle il faut penser, les souvenirs de WannaCry et NotPetya sont encore frais dans mon esprit. Nous savons que les correctifs ne seront pas appliqués à la vitesse et à l’échelle nécessaires. Et donc, nous construisons à nouveau les règles de détection !

Un petit détail important : la vulnérabilité CVE-2019-0708 est liée aux services de bureau à distance (RDS), donc à la mise en œuvre réelle par Microsoft de l’utilisation du protocole Remote Desktop (RDP) sur Windows. Le protocole RDP lui-même est correct. J’ai l’impression que cette déclaration doit être ici pour éviter toutes sortes de battage médiatique similaire à celui que nous avons vu pendant l’épidémie de Wannacry.

Le hashtag « BlueKeep » a d’abord été utilisé par Kevin Beaumount. Je l’ai choisi pour deux raisons : la référence à GoT et pour trouver des publications pertinentes sur Twitter, car on ne peut pas simplement hashtaguer un CVE (à moins qu’on enlève les tirets). BlueKeep rend juste twiterops plus facile 😉

https://twitter.com/GossiTheDog/status/1128348383704485895

Inverser la tendance en faveur des défenseurs.
Pour établir une théorie de détection, nous devons considérer deux modèles de menaces :

1. Menace de ver, similaire au scénario WannaCry.
2. Acteur APT, utilisant la vulnérabilité dans le cadre d’une campagne plus sophistiquée, tout comme EternalBlue & SMB faisaient simplement partie du désastre de NotPetya.

Pour identifier les actifs à risque, nous nous référerons au tableau suivant, partagé par la courtoisie de Dragos :

source : https://dragos.com/blog/industry-news/ics-impact-from-microsoft-rdp-vulnerability/

Le CVE-2019-0708 peut-il être utilisé pour un accès initial à grande échelle similaire à Wannacry ? Un rapide coup d’œil aux données de Shodan révèle de nombreuses machines sur Internet avec le port 3389 exposé et exécutant des versions potentiellement vulnérables de Windows :

https://www.shodan.io/search?query=port:3389+os: »Windows+7+or+8″

https://www.shodan.io/search?query=port:3389+2003

https://www.shodan.io/search?query=port:3389+2008

https://www.shodan.io/search?query=port:3389+os: »Windows+XP »Et au total, nous envisageons 2,375 millions d’hôtes avec RDP accessibles depuis Internet – mais ne tirez pas encore de conclusion !

https://www.shodan.io/search?query=Remote+Desktop+Protocol

En citant le tweet de Dan Tentler du 23 avril 2017 « tous ces hôtes ne sont pas sous Windows, et tous ces ports ne sont pas smb ». En adaptant cela à aujourd’hui « Tous ces 2,3 millions d’hôtes ne sont pas sous Windows et tous ces ports ne sont pas des services vulnérables au CVE-2019-0708 ». Si nous comparons cela à la chronologie de WannaCry, nous en sommes au stade où MS-17010 est déjà sorti, EternalBlue n’est pas encore sorti et donc nous ne pouvons pas aller scanner pour le prochain DoublePulsar. Et jusqu’à ce qu’un tel PoC existe et que quelqu’un scanne pour une porte dérobée présente, tout comme Dan l’a fait il y a 2 ans, nous ne pouvons pas être absolument certains que les choses tournent mal. Ils sont toutefois « sur le point » d’atteindre ce stade et peut-être que nous avons encore 30 jours pour mettre en place des défenses, peut-être moins.

https://twitter.com/Viss/status/856227372785221632

Bien que nous puissions débattre pour savoir si ces machines sont utilisées par de vraies organisations, leur statut de mise à jour, la segmentation du réseau, etc., il est de notoriété publique que de nombreuses entreprises exploitent encore des versions vulnérables de Windows et que les cycles de mise à jour peuvent être difficiles pour ces systèmes. De plus, par rapport à Wannacry, nous voyons environ 24 000+ hôtes potentiellement exploitables contre 140 000+ hôtes avec DoublePulsar face à Internet 3 semaines avant l’incident.

Le plus grand danger à ce stade est l’exploitation de CVE-2019-0708 une fois à l’intérieur de l’organisation pour compromettre rapidement les hôtes et pour le mouvement latéral. Et comme l’Exploit PoC n’est pas encore sorti au moment de la rédaction de cet article (de nombreux faux existent cependant), nous utiliserons tous les outils à notre disposition pour construire la détection -avant- même que l’exploit ne sorte.

En considérant tout ce qui précède, les trois principales choses que vous pouvez faire en tant que défenseur sont :

1. Déployer du contenu de détection proactive.
2. Prôner rigoureusement l’application de correctifs ou l’atténuation de la vulnérabilité.
3. Suivre l’évolution de la situation en se basant sur les informations des chercheurs de confiance.

Pour renforcer certains des points, je voudrais me référer à 2 tweets de Florian Roth sur le problème :

Règles Sigma, premières au secours.

La première règle, référencée plus loin sous Sigma #1, a été partagée par la courtoisie de Markus Neis sur le dépôt github de Sigma pour aborder la technique de déplacement latéral T12010 / Exploitation des services à distance https://attack.mitre.org/techniques/T1210/ :

En une heure, une règle similaire (Sigma #2) a été publiée sur SOC Prime TDM par Roman Ranskyi en tant que communauté / utilisation gratuite avec des distinctions dans la logique de détection étendant à T1036 / Déguisement https://attack.mitre.org/techniques/T1036/ et T1046 / Analyse de Service Réseau https://attack.mitre.org/techniques/T1046/ .

Fondamentalement, nous avons des détections TLP:WHITE et TLP:GREEN là-bas, avant l’exploit ! Mais cela suffit-il pour détecter une attaque à grande échelle ?

Apprentissage automatique, aller un peu plus loin.

Explorons comment les capacités d’apprentissage automatique peuvent nous donner un avantage sur le problème et commençons par créer une recette pour la pile Elastic.

Recette ML : Détecter le mouvement latéral sur RDP potentiellement lié à CVE-2019-0708

Théorie

Un nombre excessif d’adresses IP de destination uniques dans les connexions RDP initiées depuis un hôte unique durant une fenêtre de temps limitée peut être une indication du Mouvement Latéral et de la propagation du ver qui utilise le protocole RDP comme méthode de propagation (en utilisant l’exploit RDS lié à la vulnérabilité CVE-2019-0708).

Description

Cette recette de cas d’utilisation identifie les adresses IP sources qui peuvent potentiellement être des points de propagation de ver RDP ou de Mouvement Latéral via RDP / T1076 à travers les segments de réseau.

Efficacité

Cette recette de cas d’utilisation est fournie dans le cadre d’une Détection Proactive automatisée pour la vulnérabilité d’exécution de code à distance des services de bureau à distance (CVE-2019-0708) à un ver RDP encore inexistant, qui est supposé exploiter la vulnérabilité et utiliser RDP pour le Mouvement Latéral à travers les segments de réseau LAN internes. Des informations supplémentaires concernant le comportement du ver RDP après l’avoir observé dans la nature peuvent être utilisées pour ajuster la recette afin de produire des résultats de détection plus efficaces.

Type de cas d’utilisation

Comportement d’attaque élémentaire (EAB) – Ce cas d’utilisation détecte les anomalies associées aux comportements d’attaque élémentaires. Chaque anomalie détectée se voit attribuer un score d’anomalie normalisé, et est annotée avec les valeurs d’autres champs dans les données qui ont une influence statistique sur l’anomalie. Les comportements d’attaque élémentaires qui partagent des influenceurs statistiques communs sont souvent liés à une progression d’attaque commune.

Source de données du cas d’utilisation

Événements Netflow, journaux de flux VPC de données similaires au format ECS, qui contiennent des journaux de connexions RDP entre des hôtes Windows dans des segments de réseau internes.

Recette de cas d’utilisation

Exemple

Exemple de requête Elasticsearch :« query »: {« term »: {« destination.port »: {« value »: « 3389 », »boost »: 1}}}Analyse / configuration de détecteur d’apprentissage automatique :Détecteur(s) : high_distinct_count(destination.ip) sur source.ip
Bucketspan : 15m
Influenceurs : source.ip

Explorer les résultats ML dans la pile Elastic.

La vue des métriques uniques nous trouve les drones que nous recherchions. Donc, plus l’ensemble de données que nous avons en place est bon, plus la détection des anomalies sera précise.

L’Explorer d’anomalies aide à expliquer l’histoire des connexions RDP habituelles contre un comportement de ver ou un administrateur super travailleur qui peut ou non travailler pour l’acteur de la menace APT 😉

Le son chaud des tubes du moteur de corrélation ArcSight.

À ce stade, nous avons une logique de détection clairement définie, voyons si nous pouvons l’appliquer sur la technologie que de nombreuses entreprises utilisent encore comme outil SIEM principal. Il y a plusieurs tâches que nous essaierons de résoudre en ce qui concerne la menace à venir :

Identifier les actifs à risque sur une base automatisée.

Suivre l’activité RDP anormale sur les actifs susmentionnés.

1. Tenter de détecter le Mouvement Latéral en utilisant des règles Sigma et basées sur le comportement.
2. Tâche n°1 : c’est là que nous pouvons nous appuyer sur plusieurs fonctions dans ArcSight.
3. Établir une liste d’actifs vulnérables au CVE-2019-0708 en s’appuyant sur le modèle d’actifs et de réseau qui (devrait être) alimenté par tout analyseur de vulnérabilité qui fournit une sortie CEF (Qualys, Nessus ou même nmap feront l’affaire).

Que faire si nous n’avons pas d’analyste ? Nous pouvons suivre les hôtes potentiellement vulnérables en établissant un filtre sur les actifs XP, 7, 2003 et 2008 soit sur la base du modèle d’actifs & de réseau, soit sur la base des ID d’événements Windows générés par ces versions qui sont distinctes des versions plus récentes de Windows.

Tâche n°2 : pour substituer l’apprentissage automatique nous créerons une règle qui recueille les événements de pare-feu et de Netflow basés sur la catégorisation et stocke les IP source & destination RDP dans la liste active. De cette manière, nous pouvons trouver la première connexion vers ou depuis des actifs susceptibles d’être/confirmés vulnérables. En plus nous construirons des tendances pour profiler les connexions RDP et détecter des pics de trafic par le nombre de connexions.

Tâche n°3 : le portage de la règle Sigma n°1 de la requête à la corrélation en temps réel couvrira la détection du Mouvement Latéral T1210. Pour ce faire, j’ai copié la source Sigma #1 dans Uncoder.io pour produire une requête ArcSight. Une belle chose avec les requêtes ArcSight est qu’en ayant une certaine connaissance du langage, on peut facilement transformer le code en filtre pour une règle de corrélation en temps réel.

Combinez le tout et intégrez-le à votre SOC !

Pour ArcSight, les éléments de contenu ci-dessus sont liés dans un tableau de bord unique qui devrait rester vide dans des conditions normales d’exploitation. Pour que les événements commencent à bourdonner dans le canal principal du SOC, ajoutez une règle légère pour consommer les alertes corrélées du canal actif “Détails de l’événement corrélé.”

Pour le SOC basé sur Elastic, nous avons ajouté un simple tableau de bord Kibana. Il affiche les pics RDP et les visuels d’apprentissage automatique pour détecter les anomalies basées sur le trafic netflow ainsi que les détails sur les déclencheurs de règle Sigma, les hôtes impactés etc.

Elasticsearch, ArcSight ou Sigma ?

Si nous utilisons ATT&CK comme référence, Elastic est le gagnant d’une technique en avance.

L’avantage principal de la pile Elastic est sa capacité à combiner à la fois l’apprentissage automatique et les requêtes modernes de threat hunting basées sur Sigma. N’oubliez pas que le refactor des règles Sigma en requêtes de corrélation en temps réel ne trouve pas le Déguisement / T1036 sur ArcSight.

Cependant, il est à noter qu’il est en fait plus facile de configurer ArcSight pour utiliser les données des analyseurs de vulnérabilité pour la corrélation inter-appareil. Combiné à toutes les autres sources de journaux dans le package de règles de détection, cela peut être plus efficace pour de nombreuses organisations.

Si nous examinons la tâche du point de vue de la vitesse et du coût de développement de la détection, Sigma mène clairement la voie. Tant que votre SIEM ou EDR prend en charge Sigma ou que vous avez des journaux Sysmon de toutes vos machines, y compris XP, 7, 2003 et 2008, cela sera une solution optimale pour vous. Une fois de plus, l’avantage d’un plus grand package de détection par rapport à une seule règle repose principalement sur notre supposition qu’une véritable attaque utilisera RDP pour le mouvement latéral. Il n’y a pas de taille unique qui convient à tous lorsqu’il s’agit de détection de menaces. La note finale sera établie lorsque l’exploit réellement fonctionnel sera disponible et que nous pourrons développer la détection, très probablement en utilisant des règles Sigma. À la fin de la journée, nous avons construit un contenu de détection proactive basé sur des règles et des apprentissages automatiques pour les “inconnues connues”, tout comme l’a récemment déclaré le Dr Anton Chuvakin dans son billet :

N’oubliez pas la prévention et corrigez vos affaires

However, it is worth noting that it is actually easier to setup ArcSight to leverage data from vulnerability scanners for cross-device correlation. Combined with all the other log sources in detection rule package can be more effective for many organizations.

If we look at the task from the point of the speed and cost of detection development Sigma clearly leads the way. As long as your SIEM or EDR supports Sigma or you have Sysmon logs from all your machines including XP, 7, 2003 and 2008 this will be an optimal solution for you. Once again, the advantage of a bigger detection package vs single rule is mainly based on our assumption that a real attack will leverage RDP for lateral movement. There is no one size that fits all when it comes to threat detection. The final score will be set when the real working exploit is out and we can build out the detection, very likely using Sigma rules. At the end of the day, we have built a Proactive Detection content based on Rules and Machine Learning for the “Known Unknown”, just like Dr. Anton Chuvakin recently stated in his post: N’oubliez pas la prévention et corrigez vos affaires .

 Apprenez des erreurs des autres, corriger cela à l’avance sera aussi bénéfique que si vous aviez tous les SMB corrigés lors de l’épidémie de Wannacry. Si vous obtenez un non de l’équipe de correctif, déployez des détections, testez les sauvegardes et déléguez le risque.

Liens vers du contenu de détection gratuit et mappages à MITRE ATT&CK Liens vers du contenu de détection gratuit et mappages à MITRE ATT&CK

Sigma #1 par Markus Neis

1. Mouvement latéral ; T1210 ; sources de journaux : microsoft sysmon. Mouvement latéral ; T1210 ; sources de journaux : microsoft sysmon.Sigma #2 par Roman Ranskyi
2. Mouvement latéral, Évasion de défense, Découverte ; T1210, T1036, T1046 ; sources de journaux : microsoft sysmon. Mouvement latéral, Évasion de défense, Découverte ; T1210, T1036, T1046 ; sources de journaux : microsoft sysmon.Pack de règles ArcSight .ARB
3. https://tdm.socprime.com/tdm/info/2160/ https://tdm.socprime.com/tdm/info/2160/ Déplacement latéral, Découverte; T1210, T1046, T1076; sources de logs : pare-feu, netflow, scanner de vulnérabilités, journaux MS Active Directory, Sysmon.
4. Pack de règles Elastic Stack https://tdm.socprime.com/tdm/info/2160/ Déplacement latéral, Évasion de défense, Découverte; T1210, T1036, T1046, T1076; sources de logs : netflow, journaux MS Active Directory, Microsoft Sysmon.

SOC Workflow App édition communautaire : https://github.com/socprime/soc_workflow_app_ce

/Restez en sécurité