Fini le WannaCry : IOC de vers de rançongiciel, C2 Tor et analyse technique + règles SIEM

Bonne nouvelle à tous !

Après une longue journée, nuit et matinée à étudier les nouvelles, rechercher et traquer le runçongiciel #WannaCry, il y a quelques découvertes à partager. Cela inclut des IOCs pour Host et Network, leur analyse obtenue avec l’aide de chercheurs en sécurité et praticiens, une révision de l’infrastructure C2 et ses interactions avec Tor. Enfin, quelques cas d’utilisation gratuits pour SIEM qui peuvent immédiatement vous aider à détecter et commencer à bloquer la catastrophe mentionnée ci-dessus avant son escalade. Et voici un rapide examen des signatures SIGMA que j’ai récemment découvertes (Yara pour SIEM). Avertissement : le but de cet article est de fournir des IOCs et des conseils sur la manière de détecter et de bloquer la menace #WannaCry en utilisant des outils SIEM, OSINT, des pare-feu, des proxys/passerelles de sécurité et de faire tout cela dans les délais les plus courts possibles. Ce n’est pas une analyse inversée de malware ou un article médiatique, un énorme travail dans ce domaine a déjà été fait par beaucoup de gens (vous savez qui vous êtes, merci pour votre aide !)

Analyse macro

Au cas où vous auriez manqué toute l’explosion médiatique sur l’épidémie du rançongiciel #WannaCry / #WannaCrypt qui a frappé le monde le vendredi 12^th 2017, ces 2 articles de haut niveau se démarquent selon moi comme les plus complets et rapides à comprendre parmi la quarantaine que j’ai lus jusqu’à présent : forbes.com, blog.qualys.com.

Et un enregistrement de carte d’attaque par MalwareTech qui a pris le contrôle de l’un des domaines de malware.

Mais pourquoi pas Cisco Talos ? Voici le lien http://blog.talosintelligence.com/2017/05/wannacry.html, mais cet article est long à lire et suscite des questions sur la partie technique (lisez pour voir pourquoi). Et si vous lisez ceci, cela signifie que nous travaillons ensemble pour résoudre la nature technique de cet incident et éviter que cela et des attaques similaires se produisent à l’avenir.

Pour conclure l’analyse macro, une citation d’un collègue en sécurité :“Très bien, mais mon point principal est que, maintenant que les outils de piratage de la CIA/NSA ont été divulgués, je suis sûr que cela arrivera à nouveau… les entreprises devront être proactives, interroger leur CMDB et localiser ces systèmes hors support, et les mettre rapidement à niveau, les renforcer en désactivant tous les services Windows non-essentiels, et soumettre les plus critiques à des tests d’intrusion tiers… si l’entreprise choisit de ‘accepter le risque’ (pour éviter le coût), il est juste que le risque leur soit pleinement expliqué.”

Passons à la partie amusante !

IOCs basés sur le réseau et leur utilité

En ce qui concerne l’OSINT, nous pourrions trouver 39 adresses IP, parfois avec des ports, des protocoles et des commentaires. Cela vient de McAfee, Cisco Talos et de l’échantillon de bac à sable de Payload Security. Nous savons tous que l’IP en elle-même n’est pas une bonne #inteldethreat alors faisons une analyse de ce que nous voyons et comment cela peut nous aider à détecter et bloquer WannaCry / WannaCrypt ou toute autre chose qui #wannamesswithourproperty. Chaque IP a été pingée, analysée via VirusTotal et avec le flux DetectTor de SOCPrime. Ce dernier est une collection de 1,5 ans d’activité du réseau Tor recueillie en temps réel. Tableau initial pour votre référence.

Que voyons-nous ? 36 des 39 IP ou 92% des adresses C2 signalées sont, en effet, des nœuds Tor. Et 37 IP sont signalées comme malveillantes par VirusTotal dans les jours ou dans les 1,5 mois suivant les incidents, ce qui représente 87%. Mais pourquoi voyons-nous presque aucun port ? Analysons plus en détail, pas le temps de dessiner une belle image (aussi mes compétences en dessin sont mauvaises) donc je vais partager 2 images d’un autre tableau .XLS :

Qu’en est-il des tableaux et des couleurs ? Pour n’en nommer que quelques-uns :

1) Il n’y a qu’un seul pont Tor caché (orange). Cela signifie que l’attaquant était pressé de lancer les opérations et est probablement un cybercriminel et non un acteur APT sponsorisé par un État (à moins qu’il ne s’agisse d’un plan de tromperie ultra-sophistiqué pour faire croire que vous n’êtes pas un acteur APT). Si nous comparons cette épidémie à des campagnes APT sérieuses, les ponts Tor cachés rendent l’infrastructure beaucoup plus furtive et plus difficile à gérer, également plus coûteuse.

2) Le transport utilisé sur tous les nœuds Tor n’est pas obfusqué et n’utilise pas les Tor meek et Obfs4 modernes. Cela signifie que le trafic est relativement facile à distinguer dans un environnement d’entreprise, vous n’avez même pas besoin d’un DPI pour le faire.

3) Toutes les IP signalées ont été comparées avec Detect Tor, qui possède plus de 18 mois d’historique de nœuds Tor, de transport et de réputation. Cela nous permet de découvrir les ports utilisés par les nœuds Tor et de les attribuer, enrichissant ainsi les IOCs. Vous pouvez également trouver de nouveaux nœuds (31 et 37), seulement 2 sur 39, ce qui signifie qu’il n’y avait pas de nouvelle infrastructure Tor spéciale déployée pour l’attaque – le réseau Tor existant a été utilisé avec des domaines C2 cachés derrière un web .onion.

4) Dans les C2 signalés, 13 ports, soit 33%, sont 443 et 13 sont 9001 (port Tor par défaut) et 3 autres sont des ports 900X. Avec des réseaux correctement segmentés, les connexions sortantes vers le port 9001 ne passeront pas depuis n’importe quel segment de la plupart des entreprises. Dans l’ensemble de données enrichies, nous traitons 59 ports, les ports 443 et 9001 représentant 59% de tous les ports. Nous voyons également que 4 des IP signalées par Talos n’ont pas de ports, cependant, elles sont actives au 13.05.17 et nous avons découvert les ports.

5) Les #28, 38 et 39 ne sont PAS des nœuds Tor, cependant, ils sont signalés comme malveillants par VirusTotal et aucun port n’est à nouveau signalé par Talos. Il s’agit probablement de sites de distribution.

6) Le #62 est un faux positif signalé par Talos, car il mène à deb.torproject.org et à d’autres sous-domaines multiples de torproject qui sont assez bénins – ils hébergent le navigateur Tor, ce qui ne les rend pas un C2 ou un site malveillant.

Que faire des informations C2 ? Vous pouvez les utiliser comme IOC codés en dur pour les 1 à 2 prochaines semaines mais leur précision se détériorera à chaque heure qui passe. Ce qui est plus important, c’est que le réseau C2 est complètement derrière Tor et en faisant des listes noires actives sur le périmètre de l’entreprise et les appareils d’extrémité, nous pouvons prévenir le trafic C2 totalement. Au moins pour cette variation du ver rançongiciel wannacry?, puisque les capacités de tunneling DNS n’ont pas été rapportées au moment de cette rédaction.

IOCs basés sur l’hôte :

Il existe une signature SIGMA créée par l’auteur du projet Florian Roth sur github : github.comCitation du site du projet : « Sigma est un format de signature générique et ouvert qui vous permet de décrire des événements de journalisation pertinents de manière directe. Le format de la règle est très flexible, facile à écrire et applicable à tout type de fichier de journalisation. L’objectif principal de ce projet est de fournir une forme structurée permettant aux chercheurs ou analystes de décrire leurs méthodes de détection développées et de les rendre partageables avec d’autres.

Sigma est pour les fichiers journaux ce que Snort est pour le trafic réseau et YARA est pour les fichiers.

Les cas d’utilisation incluent :

• Décrivez votre méthode de détection découverte une fois dans Sigma pour la rendre partageable
• Partagez la signature en annexe de votre analyse avec les hachages de fichiers et les serveurs C2
• Partagez la signature dans les communautés de renseignement sur les menaces – par ex. via MISP
• Fournissez des signatures Sigma pour un comportement malveillant dans votre propre application (Messages d’erreur, violations d’accès, manipulations)
• Intégrez un nouveau journal dans votre SIEM et vérifiez le dépôt Sigma pour les règles disponibles
• Écrivez un convertisseur de règles pour votre outil d’analyse de log personnalisé et traitez automatiquement les nouvelles règles Sigma
• Offrez un flux gratuit ou commercial pour les signatures Sigma »

Nous travaillons ensemble avec l’équipe Sigma pour étendre les capacités à plus de technologies SIEM.

Vous pouvez trouver plus d’IOCs d’hôtes sur le bac à sable de Payload Security ici : hybrid-analysis.comDes IOCs d’hôte supplémentaires sont en préparation et seront inclus dans l’article dans les prochaines 24 heures.

Mitigation, alias CryNoMore

• Aucun accès entrant ou sortant à Tor depuis les locaux de l’entreprise. Utilisez les ACL sur FW / NGFW, des passerelles de sécurité / proxys et DNS RPZ si vous avez un DNS unix. Vous pouvez obtenir le flux Tor depuis l’OSINT ou notre UCL, consultez et inscrivez-vous ici my.socprime.com/en/ucl/tor/, le cas d’utilisation est maintenant gratuit à jamais pour toutes les entreprises et organisations du secteur public. Cela bloquerait la majeure partie des communications de livraison et de C2.
• Vous avez un OS MS obsolète en cours d’exécution et vous ne pouvez pas le corriger ? Utilisez ceci comme un correctif « dism /online /norestart /disable-feature /featurename:SMB1Protocol » ou toute autre méthode de votre choix pour désactiver les services SMB. Idée de source :

• Corrigez MS17-010 si vous ne l’avez pas encore fait : technet.microsoft.com Et corrigez contre toutes les exploitations révélées par Shadow Brokers dès que possible. Besoin d’aide pour mesurer le risque ? Scannez le réseau avec Qualys, Tenable ou tout autre outil qui comprend les ID CVE. La liste des CVE peut être obtenue ici : https://github.com/misterch0c/shadowbroker
• Vous avez SMB sur le périmètre ? Alors vous êtes probablement déjà chiffré 🙁 Utilisez Shodan pour trouver les ports ouverts sur votre périmètre, c’est gratuit. Bien qu’une cartographie et un scan de ports continus fassent mieux, même le bon vieux NMAP peut faire le travail.
• Si vous vérifiez chaque connexion sortante sur le port 443 avec VirtusTotal, vous bloqueriez probablement >87% du trafic C2 dans cette attaque. Pensez-y.
• En règle générale, posez-vous cette question : pourquoi autorisez-vous le trafic sortant vers le port 9001 de toute façon ? Ou en fait vers tout port à l’exception de 80 et 443.
• Bloquez toutes les requêtes sortantes sur les ports 80 et 443 vers les adresses IP qui ne se résolvent pas en domaine. Vous pouvez être plus créatif et limiter cela avec une liste blanche du top 1M d’Alexa et exclure les sous-réseaux dsl/internet domestique/internet mobile. Si vous avez une passerelle de sécurité web avancée, alors bloquez l’accès non seulement à toutes les URL malveillantes mais aussi aux URL non catégorisées.
• Vous ouvrez toujours les pièces jointes d’email inconnues sur des emails que vous n’attendiez pas ? Ne le faites pas. Vraiment pas.

p.s. Les dernières 48 heures ont été un enfer de « plaisir » : d’abord j’ai fouillé mon ordinateur portable de fond en comble pour une porte dérobée HP dans les pilotes audio et n’ai rien trouvé. Ensuite, il s’est soudainement avéré que MS17-010 ne s’est pas installé correctement sur ma machine… Donc voilà, la transition de l’école à l’ancienne « faire confiance mais vérifier » au slogan Cyber 2.0 de « Ne jamais faire confiance et toujours vérifier ». Cela n’a jamais été aussi juste, il est temps de vivre par cela.

/Restez en sécurité. Et testez vos sauvegardes régulièrement.

Votez / Partagez / Commentez / Invitez à discuter

CSV : WannaCry_IOCs_sources publiques et VTCSV : WannaCry_IOCs_vérification croisée avec le flux Tor