botconf

BOTCONF 2017 - J1

g4l4drim

06 déc. 2017 — 9 min read

How to Compute the Clusterization of a Very Large Dataset of Malware with Open Source Tools for Fun & Profit?

Les techniques de classification en Machine Learning reposent sur la création d’un vecteur de features qu’on génère à partir des données de chaque item/malware, Une fois les vecteurs obtenus, on peut les regrouper avec des algorithme de clustering comme k-means. Bon le soucis c’est quand on à beaucoup d’item à analyser pour géner les vecteurs, il faut que ça poutre. C’est pour ça que les auteurs ont codé un parser spécifiquement pour leurs besoins.

Coté clustering, le choix de l’algo dépend du problème à analyser. Une approche possible consiste à considérer l’ensemble des malwares comme un graph et de calculer les communautés dans le graph.

Le clustering génère des « blob » de malwares, et en regardant de près certains d’entre eux, on peut déterminer de quelle famille de malware il s’agit. En suite, quand on à un nouveau malware, on à pas envie de tout re-classifier.

Autre problème, c’est les Packers, il faut filtrer pas mal d’informations peu fiables pour ne pas perturber le clustering et trier les malwares par version de compilateur, ou encore sur l’ordre des sections.

Get Rich or Die Trying

Histoire d’une APT contre l’Arabie Saoudite. L’attaquant à commencé par des e-mails piégés, avec un malware. Les chaines de caractères du malware étaient partiellement obfusqué. A coup de python, les orateurs on pu les désobfusquer. Il s’agissait d’un logiciel Netwire repacké avec une facade commerciale type « logiciel d’administration » mais avec des fonctionnalités de récupération de mots de passes et de keylogging. Bref, un bon gros RAT. L’attaquant utilisait des VPS pour les serveurs Netwire.

Autre bestiole, un programme VB6 packé, un « stealer » qui communique avec un C&C sur un site web compromis. La on est sur un niveau d’attaque beaucoup plus faible que le précédent.

3ème exécutable, packé avec du .NET, et qui propage le keylogger Hawkeye. Pour le C&C il utilise soit smtp, soit http ou ftp. Dans le cas présenté, c’est SMTP qui était utilisé pour envoyer les e-mails sur un serveur contrôlé par l’attaquant. Et du coup dans le binaire, on retrouve les codes d’accès à la boite e-mail de contrôle, et en ouvrant la boite e-mail, on découvre qu’ils ont infecté leur propres machines ! En creusant un peu plus, on fini par trouver la machine de l’attaquant, des screenshots de son compte facebook etc…

Monitoring of a transient P2P Botnet

Analyse d’un Bot IOT à l’aide d’un HoneyPot. Le bot se propage en bruteforçant des accès sur les machines victimes.

RetDec

Un outil de décompilation de binaires capable de produire du LLVM. https://retdec.com/

A Silver path; ideas for improving lawful sharing of cybercrime evidence with law enforcement

Comment faire pour partager des informations techniques de façon légalement sûre ? Quand on partage de l’information sur un cybercrime, comment peut on le faire, est-ce que ça ne vous expose pas, est-ce que ça ne risque pas de pourrir une couverture ? Voir, comment faire pour partager un élément découvert par des moyens à la limite de la légalité ? On ne se pose pas toujours la question de comment une information à été produite lorsqu’on lutte contre des botnets, mais ces problèmes peuvent foutre en l’air un dossier au sens juridique.

Il faut donc gérer la protection des données, le processus juridique, la validité légale des preuves et la recherche de la vérité. La vie privée au sens large est un droit fort, qu’il faut respecter. La recherche de la vérité est souvent en conflit avec les droits des individus, notamment la vie privée. Et du coup c’est au tribunal de gérer cet équilibre. Par exemple, une preuve obtenu illégalement est irrecevable pour assurer l’équité du jugement. Dans Khan vs UK, une preuve obtenu illégalement, peut être recevable si la méthode d’obtention ne viens pas altérer la vérité. Pour « valider » la recevabilité d’une preuve, un test est effectué pour s’assurer que l’information n’est pas obtenue par la force, n’est pas la seule preuve, et si l’on peut confronter cet élément avec d’autres et si il s’agit d’une information fiable.

L’immunité assurée à un membre des forces de l’ordre sur la protection de la vie privée par exemple, lui permet de mener à bien une enquête qui collecte les information personnelles d’un botherder. Mais si cette information est obtenue en commettant un cybercrime rend les choses beaucoup plus compliqués sur un plan juridique.

Dans la GDPR, il y à un élément qui viens justifier le partage d’information obtenue de façon « illégale » au sens de la GDPR, c’est si cette tâche est d’intérêt public: Article 6(1)(e). Mais du coup c’est quand même dépendant de l’implémentation par les états.

tracking botnets with bots

Extraire les configuration des malwares de façon automatique, imiter leurs protocoles de c&c en python pour en récupérer les mises à jour, les scripts de « webinject » qui sont injectés dans les interfaces de gestion de comptes en ligne, etc… Un gros travail de fond pour procéder au tracking des botnets. Le problème, c’est quand les bots ont une configuration dépendante de la localisation géographique. Dans ce cas il faut faire en sorte de sortir les communication du bot émulé sur divers vps un peu partout dans le monde pour obtenir les versions locales des configurations.

Autre soucis, les C&C qui se sont fait partiellement sinkholé, ou qui reposent sur du .onion. Lorsqu’il s’agit du botnet P2P, il faut pouvoir découvrir tout les pairs possibles. Pour ce faire, les orateurs stockent dans une bdd les pairs déjà découverts.

Coté légal, un des soucis c’est que faire du DDoS est illégal dans certains pays, et même si on fait ça depuis une sandbox à des fins d’analyse, on à pas de « joker » juridique qui viens protéger ceux qui analysent ces malwares. Pareil pour le Spam, etc… du coup on met en place des filtres, des limitation de débit etc… ce qui provoque la détection du bot sandboxé, et le blacklist/banissement de ce dernier, supprimant de fait les information qu’on peut en obtenir au fil du temps.

Socks as a service: Botnet Discovery

Ce qu’il y a de bien avec une ip, c’est qu’elle est sous la responsabilité de quelqu’un, et qu’on peut donc la « coller » sur une carte. Lorqu’on défend, et qu’on souhaite interragir avec un botnet ou un exploit kit, utiliser un proxy peut être utile pour contourner les blacklists ou les contrôle de géolocalisation IP. C’est un peu comme Netflix avec les contenu et les utilisateurs qui cherche à apparaitre comme étant des US pour avoir accès à plus de contenu. Autre exemple avec les télphones mobiles dont les bots communiquent seulement sur les range IP correspondant à des téléphones, et toute ip hors de ces blocks est immédiatement « suspecte ».

Lorsqu’on loue un proxy, l’opérateur peux demander à quoi va servir le proxy, et en fonction des usages, adapter la rotation ip entre les proxy, etc… Du coup les prix varient en fonction des usages et de la localisation géographique du point de sortie. Certains proxy sortent sur des datacenter, d’autres depuis des IP résidentielles. D’autres proxy sont librement postés sur pastebin et divers forums de pirates. Lorsqu’on regarde de près la répartition géographique de ces proxy ouverts, un grand nombre sont disponibles aux US.

Certains acteurs du marché noir revendent sur plusieurs plateformes, et créent une « illusion » de prix élevé sur l’ensemble de ces plateformes, ce qui complique l’analyse du coût de ces proxy. Grosso modo, le proxy coûte 2$ par jour, et on est pas vraiment sûr que ça durera dans le temps, ni qu’on pourra ressortir sur le même endroit. Autre type de proxy revendu sur le marché noir, c’est les « backconnect encore appellé Bastion. Les points de sorti aux US valent plus cher que les autres. Ces services offrent aussi du support sur WeChat & QQ, et supportent Alipay, indiquant la clientelle ciblée par ce service. Pour les plateformes « mobiles », les services de proxy offrent carrément de la ré-écriture de headers pour éviter que le user-agent ne trahisse l’utilisateur du proxy.

Exemple avec un bot qui se propage depuis des instances WordPress. Il dispose d’urls très spécifiques. Il utilise google pour rechercher d’autres instances à compromettre, et collecte en suite un maximum d’informations sur la cible afin de faciliter le bruteforce. Quand on regarde la répartition des blogs infectés, on en trouve partout chez des hébergeurs.

Example of automated takedown of IoT Botnets

Exemple de takedown d’un Botnet IOT très basique par OVH. On sait que les botnet IoT ont une grosse capacité de nuisance. Pour un bon takedown, il faut récupérer les adresses des serveurs de C&C. Les exécuter en sandbox, c’est compliqué, les architectures cpu sont exotiques, les kernels visés sont très vieux, du coup ça marche pas bien dans cuckoo, par contre c’est très simple à unpack et à analyser statiquement. Du coup on peut reporter les IP de C&C aux services abuse.

Pour la récupération automatique, on automatise de cassage du XOR en testant des clefs connues, puis on grep les DNS dans les strings du binaire. Autre technique: rechercher les constantes du binaire pour des IP hardcodés. Pour ce faire, l’orateur à automatisé le reverse engineering avec r2pipe. Si ça ne fonctionne pas, l’orateur recycle un vieux raspberry pi comme sandbox.

Coté chiffres, ils ont réussi à réduire par 5 le nombre d’abus lié à des C&C hébergés chez eux.

The new era of Android banking botnets.

Les malwares bankaires android était souvent associés avec des malwares bancaires pour contourner les authentifications double facteur par SMS et cie. L’installation se faisait souvent par social-engineering. Ces applications sont peu voir pas obfusqués et disposent d’un mécanisme simple d’envoie de SMS pour diffuser le code 2FA.

Les nouveaux malwares android, eux sont reconfigurables à la volée comme les malwares bancaires qu’on trouve sous windows. Ces malwares sont généras avec du code d’obfuscation type code mort, et une génération de faux certificat à partir d’une liste de prénoms et de noms. Ces nouveaux malwares sont propagés via des sms incitant les victime à installer « un dispositif de sécurité anti fraude ». Certains utilisent des hash correspondant aux applications ciblés, et ils ne s’activent que si l’appli ciblée est présente. Du coup pour identifier les appli en question il faut une putain de liste de noms d’applications.

Hunting down Gooligan

1er malware qui volait des credentials OAuth. OAuth est un mécanisme d’authentification pour les applications. Twitter, google, facebook utilisent OAuth pour fournir des accès à un compte. C’est un standard de fait. SnapPea est le premier malware de ce genre. Ghostpush est connu pour sa capacité à rester persistant entre les reboot et même quand le mobile se fait flasher. Gooligan innove par le fait qu’il collecte les token OAuth.

Gooligan est propagé dans les Apk exsitant qui sont repacké avec le malware dedans. La payload de l’APK va charger dynamiquement un rootkit qui va rooter le téléphone, et obtenir des moyens de persistance. Il va en suite infecter le processus GooglePlay. La payload est souvent dans une image embarqué comme ressource de l’APK. L’image contiens une clef XOR. Dans la payload, on récupère un exploit pack Kingroot. Une fois le périphérique rooté, le malware déploie un système de persistance en posant des fichiers dans la partition système qui n’est pas accessible par l’utilisateur. On retrouve le binaire SU, très connu des adeptes du « rooting » Android. Ces techniques sont utilisés aussi par GhostPush. Le playstore se fait injecté via une librairie partagée. Le code injecté écoute pour des évènements type power, network, screen. Via ces events, il à de grande chances d’être appellé. Une fois appellé, il télécharge un DEX contenant la logique de fraude. Ce malware utilise des techniques publiés sur github pour l’injection et décrites sur des blogs chinois. Les samples embarquent des IP de C&C basés en chine.

Pour gagner de l’argent, ils revendent de bonnes notes sur le play store, et injectent des pubs. Pour l’App boosting, ils utilisent le token OAuth qui sert uniquement à la communication entre le Play Store et le téléphone. Avant les pirates qui faisait du « boosting » mettaient en place de fausses installations Android, mais elles sont maintenant bien détectés. D’ou leur changement de tactique pour le Boosting en volant les tokens. A son exécution, le malware ballance toute les infos qu’il à sur le téléphone, et ces informations servent à « forger » une fausse identité de téléphone. Ces fausses requêtes passent par des téléphones infectés mais non rootés parceque le kit n’était pas fonctionnel sur des versions d’Android plus récentes. Autre technique: générer du click sur des pubs injectés. Le gros dse victimes se situe dans les pays émérgents dont l’Inde parceque les téléphones ne sont pas à jour.

Pour le takedown, Les orateurs ont travaillé avec ShadowServer pour sinkholer les domaines qui servaient à la collecte des des tokens. Puis les token affectés ont été révoqués, et les utilisateurs prévenus. Les notifications était traduites pour que ça soit compréhensible pour les utilisateurs, et sur plusieurs canaux pour être sûr de les joindre. Puis mettre en place les pages d’aide et de support pour répondre aux questions des victimes.