Catégories
conférences

Botconf 2018 – J1

C’est reparti pour une nouvelle BotConf à Toulouse… malgré quelques problèmes de transports en commun pour ceux qui ont participé aux workshops 😉

[Edit: @xme à un compte-rendu en anglais ici ]

Swimming in the Cryptonote Pools

Un premier talk du CERT-EU.
Sur BitCoin, on peut tracer l’ensemble des transactions d’un wallet à l’autre. Sur monero, il vous faut la clef privée du wallet pour tracer les transactions. 
Il y a beaucoup de malwares qui minent des crypto-monnaies, et le font dans des pool de minage. L’orateur utilise des règles Yara pour récupérer les id des wallet car il s servent aussi à l’authentification des utilisateurs du pool. Le problème c’est que c’est souvent stocké en base64 dans les malwares, ce qui génère des faux positifs. Lorsque le malware est packé, l’orateur utilise retdec et snowman pour les unpacker avant d’y rechercher des informations sur les wallet.

Les API des pools de mining ne sont pas très privacy by design, et du coup l’orateur peut récupérer les wallet des participants à une pool de minage en lui envoyant les adresses qu’il à trouvé.

APT attack against the middle-east

@CurlyCyber
Description d’une attaque par apt-c-23. Tout commence avec un document piégé citant un article de news,  dont une partie du code est issu d’un code copier-collé depuis slack. Le C&C communique sur https, mais si jamais il n’y arrive pas, il y a une addresse de backup avec une URL encodée en base64 qui répond sur /api/devices/requests qui peut répondre une autre addresse de C&C.  Les fonctions des malwares de ce groupe font souvent référence à des personnages de big bang theory et autres séries télé.

Dans les whois des noms de domaines les plus anciens, on retrouve des informations probablement fausses, mais cohérentes correspondant à une entreprise de de hosting à gaza. D’autres noms de domaines employé par ce groupe pointent sur d’autres entreprises de gaza.

Code Cartographer’s Diary

L’orateur nous avais déjà présenté Malpedia l’an dernier. Il s’agit d’une suite de ce talk. L’objectif de malpedia, c’est d’avoir une collection de malwares triés, rangés dans les bon contextes, unpackés, avec des yara associés, etc… L’objectif c’est de pouvoir par exemple faire des associations entre les malwares lorsqu’ils ré-utilisent du code entre eux. Tout ceci pour permettre aux chercheur de mener des expérimentations sur ce dataset (machine learning, IA, etc…).  Le dataset se veut « petit » mais complet en nombre de familles de malwares.

Petit retour sur les techniques de lookup d’API windows employés par les malwares présents dans malpédia: Import PE, Chargement dynamique par appel à GetProcAddress et hash d’API et plein de techniques d’obfuscations.  L’orateur présente en suite quelques statistiques sur l’usage de ces API extraites par ApiScout, leur distribution, leur fréquence, etc…

Malpedia permet de servir de dataset à des techniques de mesure de similarité de code. L’orateur détaille le fonctionnement de MinHash et son usage pour la similarité entre malwares. En gros, il prend les n-gram des mnemoniques et quelques stats sur la fonction, les ballance dans minhash et compare avec une autre fonction.

En faisant de la similarité multi-critères, l’orateur à essayé de comparer des familles de malwares. Le problème c’est qu’il se retrouve avec un gros blob de binaires collés, et plein de malwares éparpillés… cela s’explique par le fait que les malwares utilisent un grand nombre de librairies communes, ce qui fausse le clustering. Du coup en filtrant les libs connues des ensembles de fonctions, on obtiens des clusters par familles.

Chess with Pyotr

Storm Worm: botnet p2p, distribué par du spam. le c2 fonctionnait sur du EDonkey, et utilisait la dht de kademlia pour échanger des infos sous la forme de hash md4. ils utilisait xor pour « encoder » les échanges, mais ne comprennait pas vraiment le fonctionnement de ce protocole p2p. En empoisonnant le cache des bots, on peut faire un takeover sur le botnet et reprendre le contrôle.

Waledac utilisait une architecture hybride avec du p2p et reposait sur les bots avec une ip publique pour servir de relais pour les bots derrière des NAT ou des firewalls. Les worker qui génèrent du spam, etc… était séparé des bots de contrôle qui bénéficiait d’une ip publique. Le problème d’un botnet p2p, c’est de bootstrapper et de trouver un pair auprès de qui récupérer la liste des pairs du botnet avec qui échanger. Chaque pair générais un certificat x509 auto-signé et une clef RSA de 1024 bits. Autre stratégie employés pour le bootstrap: des serveur fast-flux dns avec des reverse proxy.

Kelihos est un botnet de spam, vol d’identifiants de connexion, ddos, de fraude au click, de proxy socks, vol de cryptomonnaies, et de « pay per install ». la première version avait un mode debug intégré. Il tournait sur le port 80 par défaut, mais il était conçu pour fonctionner sur un autre port. Le port TCP était stocké sur 4 octets alors qu’un port s’encode seulement sur 2 octets, ce qui à servi aux orateurs pour attaquer le protocole du botnet et l’empoisonner.
le dev de kelihos à été spotté à l’aide de traces laissés dans ses codes. Un download d’un jpeg sur son serveur perso lancé comme tâche de test sur l’ensemble du botnet. Ils ont retrouvé le code d’une partie du malware sur github de l’auteur. Pour le poisoning, ils ont bootstrappé, puis se sont fait insérer dans la peerlist. Les orateurs détaillent le fonctionnement des tâches planifiés sur le botnet, et le mécanisme de template pour les spams.

Kelihos.B est une nouvelle version après le take-over. Apparu le 30 Novembre 2011, il restait des symboles de debug dedans, mais le code source n’était plus publique. Kelihos C à été takedown à la conf RSA, et la version D est sortie 20 minutes après. Les forces de l’ordre ont profité du fait que l’auteur du malware était en vacance en Espagne pour s’arranger avec les orateurs pour effectuer le takedown en même temps que l’arrestation.   

Formbook

@netsecurity1
Formbook cible un grand nombre de navigateur mais aussi certains clients de chat. Il est vendu & loué par le développeur. L’auteur du malware fournissait des binaires customisé par client. Le panel est fourni à ceux qui louent le malware, s’il est acheté, les clients doivent l’héberger eux même. FormBook est dans le top10 de la sandbox any.run.

Pour échapper aux analyses, Formbook obfusque ses chaînes en les construisant avec des mov sur la stack. Les api sont importé par hash, et utilise BZip2 & crc32 pour hasher les noms des fonctions. Il dispose de blacklist et ne s’execute pas si il découvre ces éléments sur le systèmes: noms de process, noms de dll présentes à l’exécution du programme, noms d’utilisateur lié à certaines sandboxes, etc…

Les chaînes peuvent être déchiffrés avec MalwareHash. La table des imports est vide, FormBook importe les fonctions de plusieurs façons: par nom, par ordinal ou par hash. Formbook fait du process-hollowing sur explorer.exe pour migrer de processus, ce qui fait qu’il ressemble à un processus windows légitime. Pour le hooking de fonction dans les programmes ciblés par Formbook, il embarque un petit disassembleur pour écrire les inline hook aussi bien dans des process 32 que 64 bits. Pour récupérer les mots de passes enregistrés, FormBook récupère les bases sqlite de Firefox & Chrome. Pour protéger ses serveurs C&C, Formbook utilise des faux serveurs C&C qui sont contactés en même temps que le vrais serveur C&C.

How much should you pay for your own Botnet

L’orateur à mis en place des botnets de test pour valider des solutions anti-DDoS, il s’est donc demandé combien ça coûtais et si c’était abordable ou pas. Cette présentation ne tiens pas compte des problèmes légaux, et n’a pas pour vocation à décrire les techniques de DDoS. Le coût du botnet dépend du coût de l’infrastructure, et du coût en bande passante. Les deux étant facturé de façon fine sur les plateformes de cloud. Après prise en compte des variation de coût induite par les localisations géographique des serveurs loués, l’orateur à effectué son comparatif.  Il a ainsi pu générer un DDoS de 9TB pour moins de 900€

Collecting particles from Neutrino Botnets

Neutrino est un botnet très connu. Les orateurs nous raconte son histoire et ses modifications, de la première version sans obfuscation aux versions récentes, plus modulaires et embarquant des mécanismes d’obfuscation des appels aux API Windows. La version actuelle chiffre ses modules, et utilise une clef de registre Winlogon pour sa persistance.

Neutrino est vendu à un grand nombre de cybercriminels, du coup il faut réussir à séparer les samples en groupes liés à chaque cybercriminel. L’identification d’une variante de neutrino se fait par les serveurs de C&C, sa version, son nom de bot, et son identifiant de build. La classification par build id se fait plutôt bien.

Les orateurs présentent en suit différents clients du malware, avec leurs objectifs et les modules qu’ils utilisent pour commettre leur forfaits. Les webinjects sont très populaires pour le vol d’identifiants bancaires et la génération de transferts bancaires à l’insu des clients.

Trickbot: The trick is on you !

Trickbot est un trojan bancaire découvert en 2016, très similaire à Dyre. C’est un bot très modulaire, avec du webinject, du vol de mots de passe de clients mail, etc…  Le loader charge un module de coeur et une configuration qui  contiens une liste de fichiers de config supplémentaires et de modules associés à charger. La communication de Trickbot est basé sur un système de commandes. Il y a deux catégories de commandes: soit elle viens du client, soit elle viens du serveur de C&C. Lorsqu’il s’agit du client, on retrouve dans les urls les identifiants de campagne, de client, etc… Du coup les orateurs ont conçu un système de tracking des commandes lancés par les cybercriminels.  La majorité des opérateurs de Trickbot sont en Russie, et la majorité des cibles sont aux US.

Automation and Structured Knowledge in Tactical threat intelligence.

Les orateurs sont membre du GReAT de Kaspersky, et suivent plus de 100 groupes d’attaquants, ce qui génère un très gros volume d’informations techniques. Les incidents isolés au sein des clients de Kaspersky, sont souvent les symptomes d’actions de cybercriminels. Le renseignement sur la menace  est le produit d’un processus de transformation d’élément techniques observés en connaissances sur les malwares, les groupes d’attaquants, leurs méthodes, etc…

Il faut d’abord transformer une expertise technique en un outil, c’est un peu la base de nombreux outils open-source. Le problème c’est de gérer la volumétrie monstrueuse d’échantillons de malwares à analyser. D’abord il faut bien cibler ce que l’on souhaite obtenir, déterminer les action à entreprendre, les subdiviser en tâches atomiques, puis déterminer la faisabilité de chacune. Par exemple, à la question « est-ce que ce sample est malicieux », on fait des vérifs VT, on lance PEiD, etc… on élimine les contradictions à coup d’IDA, et on prend une décision… le problème c’est que la partie IDA est difficile à automatiser « simplement ». Du coup, il faut revoir ses attentes, éliminer ce qui n’est pas automatisable, et en faire une chaîne de traitement réalisable et adaptée.

En Threat intel tactique, on utilise un grand nombre de modèles pour faciliter la visualisation de l’information et sa transmission à des personnes moins techniques. Arbres d’attaques, modèles d’adversaires, kill chain, sont les briques de bases pour construire ces modèles de threat intel. L’att&ck framework et autres outils du MITRE sont très utiles pour ce type de modélisations, et offrent un vocabulaire structuré associé. Comme c’est un langage structuré, qui s’adosse à des bases de donnés, on peut s’en servir dans la gestion des connaissances.

Les arbres d’attaques sont assez agréables à lire, mais quand on met trop d’informations dedans, on à du mal à les interpréter s’ils sont généré automatiquement. En plus ils ne sont pas adapté à la visualisation des dépendances. La kill chain c’est linéaire, c’est agréable pour comprendre une séquence d’actions, mais ça n’est pas complet. Les graphs, c’est un super outil exploratoire, mais ça biaise l’analyse, car ça donne l’impression que deux éléments sont fortement liés alors que ce n’est pas toujours vrai.

L’objectif des orateurs est de produire des connaissances exploitables et compréhensibles. Première idée: transformer les sorties de manalyzer et les traduires sur l’att&ck framework. En partant des matrices du MITRE, et en sélectionnant les techniques qui vont bien on peut retrouver les informations de mitigation, de détection. Sauf qu’en pratique, la correspondance entre l’Att&ck et les sorties d’un outil d’analyse n’est pas toujour bonne. De plus, pour un même échantillon, les résultats varient d’une sandbox à l’autre quand aux éléments de l’Att&ck remonté ne sont pas les mêmes.

Le problème c’est que Att&ck modélise l’intention, et que cette intention peut prendre une infinité de variations observable par les outils d’analyse de malwares. Les orateurs ont donc mappé les sorties de manalyze avec la matrice du framework Att&ck pour faciliter l’analyse de ses sorties et leur mise en relation automatique avec les informations de détection et de mitigation décrites dans le framework.

Laisser un commentaire

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