Catégories
conférences

Botconf 2016 – J2

(CR de @xme ici)

Christiaan Beek – Intel Security – Keynote on ransomware

Les ransomwares se sont développés aussi à l’aide des crypto-monnaie qui facilitent la furtivité des cyber-criminels. 2016 est vraiment l’année des ransomware pour l’orateur. Certains criminels ont ainsi déployé des ransomware basé sur du bash parce-qu’ils passent au travers des signatures AV. Ils les ont déployé sur des serveurs web. Certains ransomwares font du chiffrement de disque, mais le plus présent cette année reste Locky & Angler avec le takedown de LURK. Du coup sur le « marché noir » c’est Neutrino qui prend la relève. Les entreprises sont devenu la cible de campagne de ransomware lancé par des concurrents économiques. Tandis que la concurrence récupère de l’attaque, le business continue pour le commanditaire. Du coup on a vu du « ransomware as a service » se développer avec possiblité de customiser le nom du ransomware etc…

De nombreux ransomwares sont dérivés à partir d’un code open-source publié sur github. Coté « support technique » du ransomware lors de la négociation des clefs de déchiffrement, certains clients menacent d’aller voir interpol pour négocier un prix à la baisse.

Coté détection et analyse, le machine-learning, le principe est de séparer le bon-grain de l’ivraie, sauf que beaucoup de fichiers malicieux sont conçus pour avoir l’air légitimes, de même que certains fichiers légitimes peuvent être mal classifiés. Du coup on essaye d’identifier les algo qui fonctionnent le mieux. Pour les PE on y arrivait bien, mais les lockers basés sur Powershell & JScript sont venu foutre la merde. Autre approche: le monitoring des appels d’API qui peuvent révéler certains patterns particuliers, mais dans la pratique ça ne marche pas. On peut aussi essayer de faire de la détection en mémoire que l’on combine avec des événements pour détecter et bloquer le ransomware avant qu’il ne chiffre quoi que ce soit (c’est en béta, et c’est ici).

La réponse légale est en route contre les ransomwares pour lutter contre ce phénomène de masse. Du coup les forces de l’ordre mettent à disposition des victimes un « crypto-sherif » qui sur la base de 2-3 samples chiffrés identifie le ransomware et sert à alimenter la base des victimes et éventuellement à indiquer si des clefs ou un déchiffreur est disponible. Heureusement que de nombreux chercheurs en sécurité développent des outils de déchiffrement pour restaurer les données des victimes qui n’ont pas de backup. Du coup les cyber-criminels s’énervent et propage un ransomware sans rançon nommé no_more_ransom pour se venger de l’initiative NoMoreRansom.org.

Le futur du ransomware, c’est l’IoT avec des frigos qui refusent de fonctionner, des voitures qui refusent de démarrer ou bien des lampes qui clignotent, sans parler des routeurs domestiques dont dépendent tout ces gadgets connectés.

Attacking linux moose 2.0

(nsec.io) Une étude fait par GoSecure / ESET / L’université de montréal. Moose est un virus qui infecte les IoT qui tournent sur busybox: caméra IP, Routeur, DVR, etc… Il se propage par du bruteforce telnet comme miraï. Son utilisation de base c’est de servir de proxy pour les criminels vers des réseaux sociaux. Du coup GoSecure à mis en place pas mal de honeypots pour observer son comportement. Beaucoup de détails techniques ont été couvert dans les whitepapers d’ESET et l’an dernier à la botconf.

Pour étudier la version 2.0, l’équipe à monté un honeypot ARM a faible interaction basé sur Qemu sur lesquels ils ont déployé moose. Ils ont mis en place un proxy mitm, et émulé busybox & cie pour que tout fonctionne bien pour le ver. Cowrie est un outil maintenu qui a permis de construire le honeypot en y ajoutant le support de telnet. Le stripping de HTTPS n’a pas marché sur les réseaux sociaux, ils ont du faire du full MiTM au lieu de sslstrip pour tout obtenir en espérant qu’il n’y avait pas de vérification de certificats dans le bot. Ce qui fut le cas. Bon il a fallu éviter de catcher les échanges avec le C&C. Il a fallu jouer avec bettercap pour désactiver le contournement HSTS, et c’était galère. Mitmproxy à finalement bien fait le taff. L’erreur de certificat imitait l’erreur générée par une appliance de sécurité, ce qui fait que les opérateurs du botnet n’y on vu que du feu.

Moose est furtif, il ne fait pas de DDoS, pas de fraude à la publicité ni de spam, et il n’a pas de persistance. L’addresse du C&C est passé en argument au binaire, on ne peut donc pas la récupérer par analyse statique, il faut avoir un honeypot et avoir supervisé l’infection. Le proxy n’est accessible que depuis une whitelist donnée, ce qui évite qu’un scan de l’internet permette d’identifier l’ensemble des hôtes infectés. Les informations de la victime servent à contrôler la validité des requêtes de mise à jour. Le protocole de moose imite des échanges HTTP pour plus de furtivité. Les messages du C&C passent dans les cookies de session alors que la page d’accueil ressemble à une page apache par défaut classique qui ne génère pas de cookies.

Moose génère de l’argent via la revente de follower sur Instagram. Une grosse partie du traffic est généré de sorte que le bot à l’air humain vu des logs du site avant de mettre un contact en favoris ou de le follow. Du coup il ne se fait pas bloquer comme spam, mais les faux comptes se font rapidement dégager d’instagram. Les acheteurs sont des comptes d’entreprise avec des très petits moyens ou des individus qui font du personnal branding.

Lors d’une expérience, les orateurs ont acheté des followers, et bien entendu, quand les ban sont tombé, le nombre de followers est retombé. Ils ont donc relancé l’opérateur du botnet 2-3 fois pour récupérer d’autres followers jusqu’à ce qu’il soit lassé et cesse de répondre à leurs requêtes. Après analyse, Moose faisait 13$ par mois par bot. Combien d’administrateurs sont derrière Moose?  il y a 7 addresses IP dans la whitelist, avec 3 langages différents: Anglais, Espagnol et Néerlandais, probablement un modèle de revente du botnet à quelques clients.

Tracking Exploit Kits

L’écosystème des exploit-kits est très segmenté, entre les revendeurs de traffic, ceux qui vendent des exploit kits, ceux qui revendent de l’hébergement compromis pour héberger les EK, ceux qui font du blanchiment de Bitcoins, etc… Les EK ont généralement des blacklists par géolocalisation de l’ip de la victime, du fingerprinting mais ils exposent aussi des motifs dans les urls qui peuvent être matché par des expressions régulières (ou pas?). Les EK bloquent les chercheurs en sécurité en filtrant les ranges IP des entreprises de sécurité, par contre les VPN low cost grand public ne sont jamais bloqués. Coté VM pour l’analyse, il faut préparer des variations avec des navigateurs vulnérables qui ne fonctionneront pas sur tout les EK. Des 0-day yen a une fois l’an sur les EK, du coup ce n’est pas très fréquent car ça coûte cher et ça ne dure pas longtemps vu que les éditeurs vont la patcher très rapidement. Cuckoo génère beaucoup trop de données lorsqu’on cherche uniquement à récupérer le binaire envoyé par l’EK. Pour les urls d’infection: le forensic sur les logs est une bonne base, certains font du crawling (ou collectent les urls dans les spams). Les crawlers de BING sont capable de retrouver pas mal d’urls d’infection et sont fournies aux partenaires de microsoft MAPP/VIA. (slides ici). Comme les gestionnaires d’EK revendent par nombre d’infection unique, ils font très attention à ne pas re-infecter 2x la même machine, mais ne rechignent pas à les infecter avec un autre malware.

Improve DDoS botnet tracking with Honeypots

L’orateur piste les botnets de DDoS depuis 2014, et à réussi à identifier plus de 30 familles de botnets avec plus de 6000 groupes de machines infecté par ces derniers. Une possibilité pour identifier les botnets de DDoS, c’est la façon dont les paquets Syn-Ack sont générés par les bots. Une autre approche consiste à déployer des honeypots et à observer le fonctionnement du bot. En alignant les packet dans une matrice de features, on voit se dégager des parties fixes et des parties variables, on peut donc générer automatiquement une signature. Une fois la signature obtenue, on peut identifier les DDOS effectués par la même famille de botnet.

Talos – Function identification and recovery signature tool

Le reverse de malware c’est souvent une boucle sans fin d’analyse de malwares de la même famille, une version plus récente, plus vieille etc… du coup c’est toujours les mêmes fonctions encore et encore. L’idée c’est de répliquer ce travail et de le partager. Du coup pour s’économiser, il faut dégager ce qu’on à déjà reverser dans un échantillon précédent. Bon ya pas de googledoc pour IDA Pro (faut faire du radare2 ?), du coup Le plugin FIRST à pour but de préserver les annotation IDA et de les partager d’une session à l’autre. A partir des opcodes, du nom de la fonction ou de l’architecture, le serveur retrouve les annotations associés et les renvoie au plugin. (ça fait vachement penser à polychombr. Dommage que ça soit ENCORE un truc pour IDA). Pour enrichir le serveur avec des donnés utiles, l’équipe de TALOS derrière ce projet ont compilé plein d’outils open-source avec plein d’options pour obtenir plein de « metadata » à mettre dans l’outil pour retrouver les fonctions usuelles. Un indicateur de similarité permet de vérifier lors d’une recherche la qualité du matching entre les métadonnés et la fonction que vous cherchez à identifier. (je vous invite a checker la démo dès sa mise en ligne sur la chaine youtube botconf).

Advanced Incident Detection and Threat Hunting using Sysmon (and Splunk)

L’idée c’est d’utiliser sysmon et de pousser tout ça dans splunk pour analyser à postériori des comportements étranges sur les systèmes. L’idée vient d’une présentation à RSA de Mark Russinovich.  Sysmon peut produire des log via le système d’event-log de windows. On configure Sysmon via un fichier sysmon-config.xml ou l’on vient filtrer les information réellement utiles. Ensuite il faut réussir à distinguer entre les actions annormales et/ou malveillantes et les usages normaux. Une des principales sources d’information, c’est l’OSINT à partir de blogs et autre rapports de la communauté DFIR/Malware/Infosec.

Exemple avec svchost.exe lancé sans l’option -k ou alors avec le le mauvais path. Ex avec l’Adwin RAT dont le taux de détection était null sur VT à sa découverte, et quelques jours plus tard il y avait une détection de 8/40. Dans VT on retrouve la liste des process avec leurs arguments de lancement, du coup on peut utiliser ces informations pour rechercher ce RAT dans Splunk.

Autre exemple avec un maldoc dont le fichier excel lance un svchost. Le process hollowing évite la création d’un thread spécifique pour lancer le malware, mais est détecté par la dernière version de Sysmon. Chaque e-mail peut être balancé dans une sandbox pour en extraire divers éléments: dns, http, connexions tcp, règles yara qui matchent, etc… et de ça on en extrait un comportement qu’on re-injecte dans des recherches Splunk qui remonte alors les hôtes potentiellement infectés. Une grande partie des RAT Java sont détectables à partir de leur technique de persistance.

Pour les keylogger userland type iSpy, une recherche sur /stext permet de trouver un grand nombre de keyloggers. /stext est un paramètre très utilisé par les applications pour cacher les mots de passes. Autre exemple avec Locky. vssadmin sert à supprimer les shadow-copy des documents. rundll32 est appellé par locky soit avec un répertoire temporaire dans les paramètres. De même en recherchant dans les fichiers créés les noms carractéristiques de Locky, on peut identifier facilement l’infection.

Pour powershell, il y a de l’obfuscation, il faut donc ajouter un peu de desobfuscation dans les requêtes splunk pour remonter les scripts malicieux (et c’est pas simple). Plus généralement, le Threat Hunting est une activité humaine à plein temps, même si elle s’appuie sur de l’outillage pour passer à l’échelle. http://www.threathunting.net/ est une super source pour ceux qui veulent se lancer dans cette activité. Un attaquant qui fait du powershell aura tendance à lancer certaines commandes comme whoami /groups. Du coup avec quelques règles bien senties on peut pister les mouvement latéraux de l’attaquant.

Various Artists – How Dridex Hides Friends

Talk technique sur les mécanismes de furtivité de Dridex. Une fois le shellcode exécuté par j.bat, une connexion est effectuée vers le C&C pour récupérer la charge à exécuter. La charge en question est un utilitaire nommé « Remote Utilities », un outil d’administration à distance (RAT) certifié « mcAffee secured. ». Du coup quels sont les liens entre j.bat, le rat et Dridex. Entre le RAT et j.bat c’est la timeline. Il n’y a pas de trace du téléchargement de j.bat par l’utilisateur, ça s’est donc fait à son insu.  J.bat étant apparu 6j après l’infection par Dridex, il est probable que ça soit Dridex qui l’ai installé. Il semblerait que la victime ai laissé son token 2FA connecté, et l’attaquant à fait le transfert à l’aide du RAT à l’insu de l’utilisateur en utilisant une probable « session privée » du navigateur. Le TTP de Dridex ne colle pas avec le TTP du script powershell j.bat qui est de bien plus haut niveau que ce qui se voit pour Dridex. Du coup ce n’est pas le même groupe d’attaquants. L’un (dridex) à revendu à l’autre (j.bat+rat) l’accès à la machine victime.

A Tete-a-Tete with RSA Bots

Présentation de l’analyse d’un botnet dont la communication avec le C&C se fait via une clef générée au runtime. Du coup pour pouvoir communiquer avec le C&C, les auteurs ont hooké dans le malware, la partie crypto avant la négociation de la clef de session, et ont changé la clef publique par la leur. Puis  ils l’ont le laisser s’exécuter normalement. Et quand le malware contacte son C&C, un spoofer DNS redirige la communication et permet de récupérer la négociation de la clef de session et de récupérer cette dernière. A partir de là il fut possible d’étudier les échanges protocolaires et de recréer un faux serveur pour tester les samples et voir si le protocole du bot évolue ou pas vu que si il évolue, il ne peut plus communiquer avec son faux C&C.

Botnet Takedown the ISP Way

Petits rappels sur le fonctionnement d’un botnet. Pour un ISP, se débarrasser d’un Botnet, c’est économiser de la bande passante. Une technique classique pour démanteler un Botnet consiste à sinkholer les bot en rachetant un DNS expiré, ou forcer l’expiration du nom de domaine et le récupérer juste après. Le problème c’est que ça dépend du provider DNS, et les hébergeurs bullet-proof n’en ont rien à faire. Du coup il faut trouver une autre solution. L’ISP contrôle une partie du traffic DNS des victimes, et peut donc intervenir à ce niveau pour les C&C identifiés. Il est aussi possible de faire du DPI au coeur du réseau en plus du traditionnel monitoring NetFlow & Cie. Du coup un ISP peut rediriger les bot vers un serveur d’analyse. C’est possible pour des bots bien connus dont le protocole est centralisé et à été reversé. Ainsi on peut envoyer des requête de désinstallation aux bots, désinfectant par la même le malware de la machine victime. Du coup l’ISP qui présente à mise en place un dispatch server avec un « super sinkhole server » universel qui est capable de discuter avec différent bots et de prévenir les utilisateur de leur infection.

Detecting the behavioral relationships of malware connections.

by @eldracote / Slides are live on bit.ly/BotConf
Bien entendu on se bat avec les outils qu’on à, mais on voit bien que les IOC et les signatures ne suffisent pas. De plus on à pas toujours accès aux contenus via de la DPI, donc ce n’est pas possible d’y appliquer de la DPI. La réponse classique c’est « faisons de la détection comportementale ». Le problème c’est comment utiliser correctement du machine learning pour détecter des botnets ? et l’utiliser correctement pour que les résultats soient là. L’automatisation est nécessaire pour tenir la volumétrie. L’orateur propose un outil: https://stratosphereips.org/ basé sur le machine learning pour faire de la détection. Les dataset et l’outil sont entièrement gratuit et open-sources. Pour chaque type de protocole et d’échange, on y associe une lettre, et l’ensemble de ces lettres génèrent un pattern comportemental qu’on peut associer à un malware type. ça ne fonctionne pas tout le temps car certaines connexion issue de bots ressemble vachement à du trafic légitime.

Vu qu’un malware a un comportement généré par un code, ce code et donc ce comportement peut être modélisé. Le modèle de stratosphere ips consiste à réaliser le graph ou chaque noeud est un un couple ipsource-port et chaque connexion un lien. Du coup en observant les graph, on peut identifier les comportement normaux et ceux qui semblent anormaux. A partir de ces graph en regardant les boucles, les liens qui se répètent, etc… on peut sortir des indicateurs qui rentre facilement dans un modèle adapté au machine learning. Un bot est trahi par des comportements très répétitifs.

Analysis of free movies and series websites guided by user search terms.

Les sites web qui diffusent des contenus protégés, ou des liens vers des contenus protégés, servent aussi à diffuser des malwares aux visiteurs de ces sites. C’est très efficace car ça attire une grosse population de victimes potentielles. Ces sites de streaming tentent d’inciter l’utilisateur à exécuter une soi-disante mise à jour de flash, ou d’un obscur codec fictif. Pour faire marcher la moulinette de ces sites, l’orateur à utilisé Google Trends. A partir des recherches populaires par catégorie, ils ont crawlé les sites en résultat avec un navigateur instrumenté avec Selenium. Pour l’analyse, c’est VT et les autres services en ligne derrière ce dernier qui ont servi.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *