Botconf 2016 - J3

Nymaim

Nymain est un malware vu la première fois en 2013 dont le code source à été leaké, et qui maintenant sert de dropper pour de la fraude bancaire. Alors qu’en 2013 il servait de ransomware. Le malware vérifie les infos CPU et refuse de s’exécuter sur des xeons et autres processeurs spécifiques aux serveurs car si c’est un serveur, c’est une sandbox. (a quand les laptops xeon pour se protéger des malwares ?). Il possède des techniques anti-dumping, de l’obfuscation de code, bref plein de merde pour les reversers. Le loader du malware à un timeout pour ses campagnes et du coup au delà d’une certaine date, il arrête de fonctionner pour ralentir les outils d’analyse automatique. Coté DNS, les réponses ne sont pas la vraie IP, mais une version obfusquée, et un algo génère la bonne IP à partir du DNS. Une checksum permet de vérifier que l’IP est bien sous contrôle de l’attaquant ce qui complique le Sinkholing. Bien sûr le malware utilise aussi un DGA pour le nom du domaine, et ce nom change chaque jour. Comme il vise des sites bancaires, sa configuration embarque des bouts de code javascript à injecter dans les sites des banques.

Rough Diamonds in Banking Botnets

(Petite musique pour réveiller l’assemblée). Présentation sur comment les cyber-criminels améliorent leurs backends de traitement pour retrouver des données et des informations « rentables » chez les victimes, ou des machines compromises « juteuses ». (TLP: Red, donc pas plus de liveblogging).

CERT PL – ISFB, Still Live and Kicking

Un talk sur ISFB qui n’a rien à voir avec vawtrak/gosi/ursnif/gozi2  c’est l’un des banker les plus populaires sur le marché avec plein de petit descendants. c’est un crimekit disponible au marché noir. Ce malware présente plein de chaines de caractères inutiles partout qui peuvent servir de signature/IOC. Bon sinon il y à une IOC qui marche bien (sur le slide 😉 ). Ce malware utilise des techniques anti-vm avec des chaines chiffrées qui ne se déchiffrent que si la souris bouge.
On retrouve pas mal de trucs pour gérer la connexion au site bancaire: enregistrement vidéo, clavier, redirections, etc… (slides)

Esentire – Preventing File-based botnet persistence and Growth

Comment éviter qu’un dropper n’arrive sur une machine et ne prenne pied sur un système et lance sa payload. L’orateur présente un ensemble de contre-mesures pour un système Windows. Rien sur les « fileless infection » et cie. La première source d’infection c’est le social engineering, d’un e-mail foireux à des sites spécialement crafté pour piéger l’utilisateur. Pour les bot-herder le but c’est d’avoir un maximum de pigeons. L’exploitation se fait via du malvertising et des exploit-kits. Ces exploit-kits peuvent dropper n’importe quoi comme malwares. L’objectif des attaquant c’est d’exécuter du code sur la machine victime. Des binaires, du JS, des shellcodes sont les quelques pièces utilisés pour dropper un malware. Les pièces jointes sous divers format aussi: macro office, powershell, html/hta etc… tout est bon à prendre. L’exécution d’un tel code provoque souvent un arbre d’exécution trèèèèès long.

Pour se protéger, il faut faire de la défense en profondeur et ajouter des couches de protection. Le blocage de l’exécution peut être obtenue à différent niveaux. Ces modifications peuvent être propagées par GPO par exemple. On retrouve des principes simples de protection:

• pas d’exécution de code en mode adminsitrateur par défaut,
• retirer JAVA si vous n’en avez pas besoin,
• éviter la possibilité que les utilisateurs installent eux-même leurs soft,
• utiliser un Local Administrator Password (LAPS) aléatoire et spécifique pour CHAQUE poste
• désactiver WSH par défaut (windows script host) qui permet l’exécution de Javascript et de VBS (ça se fait avec une simple clef de registre),
• désactiver l’exécution des macro par défaut au travers de règles spécifiques disponibles pour tout les logiciels office. On peut aussi modifier le comportement vis à vis des macro dans office via GPO,
• bloquer powershell, c’est très galère et les local security policy ne fonctionnent pas. idem pour les execution policies. là v5 apporte des solutions de logging et de sécurité. On peut l’exécuter en mode « restreint » ou seuls les scripts signés peuvent accéder aux api privilégiés (com/syscall),
• AppLocker est une solution de whitelisting qu’on peut configurer via GPO. le whitelinsting se fait par hash/localisation/éditeur. Par éditeur nécessite forcément la signature du binaire,
• Blocage des exécutables dans %OSDRIVE%Users*,
• restreindre l’accès utilisateur sur System32 et Windows,
• pour bloquer les Macro, on peut le faire avec Applocker en bloquant la DLL de VBA. Idem pour Powershell,
• bloquer l’accès a MSHTA.exe contre les fichiers .hta,
• DeviceGuard pour finir.

Dridex Gone Phishing

Dridex est un trojan bancaire très populaire et très jeune (2 ans et demi) avec de grosses capacités d’injection web. Le réflexe classique pour vérifier la légitimité d’une page, c’est de valider le certificat SSL et l’URL. Mais lorsqu’il s’agit d’un WebInject, c’est très difficile pour un utilisateur de différencier entre une page légitime, et une page injectée. Dridex se configure avec du XML.

Le vol d’identifiant peut se faire de plein de façon: du keylogger au phishing en passant bien entendu par les Web-Injections (l’injection de code JS/html supplémentaire dans le navigateur AKA MitB). En faisant croire à l’utilisateur que le compte est temporairement bloqué, les attaquants lui demande toutes les informations nécessaires à la fraude pour « débloquer » leur compte.  Autre technique originale à l’aide d’un poisonnng du cache DNS pour rediriger l’utilisateur vers un faux site avec un vrai certificat pour que l’URL ne change pas. Dridex utilise un mix de phishing et de redirection DNS avec certificat pour esquiver les contrôles JS et de certificats que pourrait faire un utilisateur averti. Pour imiter parfaitement le comportement de l’utilisateur, Le cybercriminel fait ses transactions depuis la machine de la victime.