botconf

BotConf 2016 - J1

g4l4drim

30 nov. 2016 — 8 min read

(CR de @xme pour le 1er jour ici)

ESET – Visiting the bear den

Retour sur sednit/apt-28/Fancy Bear/etc…. Une équipe d’APT très « médiatique » pour ces dernières attaques. Une campagne de fishing à été détectée à cause d’un défaut de sécurisation d’un minifier bit.ly en mode privé. Ces attaques ont visé des politiciens, des organisation type OTAN & Europe, etc. Ils utilisent beaucoup de 0-Day et des exploits de CVE assez récent comme l’enchainement d’une vulnérabilité Flash avec une vulnérabilité dans le kernel windows. Ils développent beaucoup d’outils d’attaques depuis 2004. Exemple bidon d’illustration des TTP de sednit inspiré de vrais cas. Serge (la cible) reçoit un e-mail dont le nom de domaine est très proche du vrai, et dont l’url est la même que celle du site légitime. L’infection par sedkit commence. Comme tout les EK, on atterri dans une page d’accueil de 200 lignes de JS qui vérifie plein d’informations sur l’utilisateur, puis les plugins. Une fois ces données collectés, le JS génère un rapport JSON. L’exploit est en suite envoyé à la victime. L’exploit est parfois une 0-Day, parfois un exploit public re-travaillé. Parfois il s’agit d’une chaine ROP très grosse, parfois il s’agit d’un code Powershell.

Le dropper utilise des techniques d’anti-analyse qui consomment beaucoup de cpu pour détecter l’émulation. En suite la payload Seddownload est déposée et un exploit d’élévation de privilèges est utilisé pour obtenir les privilèges système et assurer la persistance de la payload. La payload vérifie la connectivité internet en requêtant google, et si ça ne marche pas, elle récupère les infos de configuration directement dans les fichiers de conf des navigateurs. Si ça ne marche pas, elle s’injecte dans le process d’un navigateur en fonctionnement. Une fois la connectivité assurée, la payload renvoie des informations sur l’environnement système à son serveur de Command & Control.

Une fois que les opérateurs du c&c ont vérifié qu’il s’agissait d’une vraie victime, la payload déploie une backdoor Sedreco & déchiffre une configuration. Cette backdoor dispose d’un système de plug-in pour en étendre les capacités. Les plug-ins sont des dll déployées dans le même espace d’addressage que la backdoor. En suite Sedreco déploie une backdoor plus lourde nommée Xagent. Cette backdoor peut utiliser plusieurs canaux de communication comme les e-mails. Pour passer les filtres antispams, les e-mails utilisent un protocole utilisant des mots clefs et des phrases pour passer inaperçu.

Pour tirer le maximum de la victime, sednit utilise divers outils, parfois créés uniquement pour la cible, parfois pour prendre des captures d’écrans lorsque la souris bouge. Un de leurs composant, Xtunnel, sert à transformer la victime en proxy pour attaquer d’autre cible (mouvement latéraux).
Pour assurer la persistance, une dll modifié d’office est utilisée ce qui fait qu’a chaque fois que Serge lance office, la backdoor Xagent s’exécute. Autre outil utilisé par sednit: un downloader codé en delphi nommé Downdelph qui déploie un rootkit kernel pour XP et Windows10 ou un bootkit.

Le groupe sednit à un écosystème logiciel très diversifié, on peut donc se demander comment sont produit ses outils. Les outils sednit sont compilés spécifiquement pour leurs cibles. Les développeurs de ces outils sont probablement intégrés à l’équipe de sednit. On retrouver certaines techniques communes à de nombreux outils de sednit, du coup il est probable que les mêmes développeurs soient à l’origine de tout ces outils. De la ré-utilisation de code est faite aussi par les développeurs, on retrouve par exemple des bout de Caperb dans leur dropper. (plus de détails sur leur blog)

LURK – The story about five years of activity

Retour sur un groupe d’APT qui à finalement été arrêté. L’infection commence par du drive-by download d’un exploit kit placé sur un site attirant les victimes. Les sites compromis sont des victimes collatérales. Les urls de l’exploit kit étaientt très basiques et permettaient d’identifier rapidement si on avait affaire au fingerprinting ou à l’exploit ou à la payload. Avec une simple signature on pouvait rapidement identifier les infections de LURK. L’enchainement des urls n’a pas vraiment beaucoup changé. Vu que la réputation d’un nom de domaine est parfois basé sur la date d’enregistrement du DNS, les acteurs de LURK attendaient 16 mois avant d’utiliser le nom de domaine pour l’infection. Tous les DNS du C&C ont été enregistrés par la même addresse e-mail. Certaines infections se faisaient au travers de régies publicitaires, ou par des logiciels backdoorés sur des sites de diffusion de logiciel eux-mêmes compromis. D’autres sites était compromis via une faille web. LURK y installait un webshell et venait modifier le header du site pour y injecter leur iframe d’attaque. D’autres sites était infectés par un module apache malicieux. Même après un an et demi d’activité, la détection des malwares de LURK était assez faible. Des similarités entres Angler et l’exploit-kit de LURK ont été identifiés, notamment l’infection sans fichiers (tout en mémoire). Lors de l’arrêt de LURK, l’activité de Angler et Locky à chuté drastiquement.

Yandex – Browser based malware evolution and prevention

Le man in the browser consiste à modifier le fonctionnement du navigateur pour altérer le javascript contenu dans les pages de rendu. L’objectif est de voler les identifiants et passwords des utilisateurs, ou de modifier l’affichage de certaines pages comme celles de banques ou de réseaux sociaux pour cacher aux yeux de la victime les opérations effectués sur leur comptes. Historiquement, les browser helper object était utilisés pour modifier le comportemet d’IE. Traditionnellement, le MiTB reposait sur des hook sur les navigateurs, mais leur rythme de mise à jour génère pas mal de travail pour le cybercriminel. De plus les hook posés sont très spécifiques et visibles à l’analyse. La nouvelle génération de MiTB repose sur des extensions de navigateur, ou des fichiers de configuration de proxy WPF, ou des proxy distants malicieux ou des VPN malicieux qui altèrent le contenu téléchargé par les navigateurs. Les extensions de navigateurs sont relativement stables et faciles à maintenir. Le malware Eko était téléchargeable directement depuis le chrome store, et servait à générer des actions indésirables sur le compte facebook des victimes. Le malware se propageait sur facebook à coup de tag vidéos et messages privés. L’extension chargeait dynamiquement un code de « démarrage » qui venait via une XHR récupérer le code malveillant. Une fois installée, l’extension malicieuse contournait les mécanismes de blocage publicitaire en place dans le navigateur, gérait la persistance par autorun, modifiait la politique de sécurité de chrome. Lorsqu’un utilisateur fait une recherche sur google, l’extension redirigeait l’utilisateur sur un autre moteur de recherche en re-utilisant ses critères de recherche.

Coté détection et protection, c’est pas simple vu que les fonctions malicieuses sont stockés sur un site tiers, de préférence populaire pour éviter tout blacklisting. L’extension malicieuse utilise un hash de l’url consulté pour obtenir le code malveillant à exécuter, ce qui complique l’analyse du nombre de sites ciblés par l’extension malicieuse. Cependant, il est possible de détecter les modifications et le fonctionnement de ces extensions à l’aide de CSP (content security policy). En effet, CSP permet d’empêcher le chargement dynamique du contenu malicieux. Le problème c’est que les extensions peuvent éditer les headers et notamment ceux lié à la CSP. Autre possibilité: utiliser javascript pour valider le contenu de la page et détecter sa modification au sein du client. Il faut faire en sorte que ce code de validation ne puisse être supprimé sans casser le rendu de la page. Coté client, on peut vérifer la validité d’une extension par rapport à celle présente sur le chrome store. La validation de signatures est aussi une technique au sein du navigateur pour éviter cela. Enfin CSP ne sert pas que à bloquer des XSS.

Language Agnostic Botnet detection based on ESOM and DNS.

Les Bots utilisent le DNS comme canal de communication ou bien simplement pour joindre leur C&C au travers d’une routine de génération de nom de domaines (DGA) les SOM sont des réseaux de neurones, et quand ils sont très gros on appelle ça des ESOM. Du coup, il faut entraîner le réseau avec un dataset de noms de domaines non-malicieux en espérant que l’échantillon d’apprentissage n’est pas contaminé par des DNS générés. (après ça fait des jolies cartes de pixels colorés que je ne comprend pas)

Vawtrack Banking Trojan

Vawtrack est un cheval de troie qui vise les clients de banque. Il utilise un packer qui compresse avec lzmat, il fonctionne en 32 et 64 bits, etc… dans le packer il y a un buffer de configuration qui est claqué en dur avec les adresses des C&C, des clefs crypto de validation, etc… Pour le stockage, vawtrack à un algo de génération de noms (le DGA du FS). De plus Vawtrack log les crash et les envoient à son C&C. Coté architecture, le malware utilise un système d’IPC entre le processus maître et ses fils. (report ici). Le malware utilise bien-sûr du MiTM pour faire du MiTB. Le contenu web injecté est protégé par de la crypto s-box (cryptoquoi?). Ce contenu est associé à une configuration qui peut faire des capture vidéo de l’écran lors de la composition du code secret sur clavier virtuel.
Truc rigolo, 2000+ serveurs Windows ont été infectés par Vawtrack. Vawtrack à été distribué via Pony. Vawtrack est architecturé sur 3 type de serveurs: le C&C, les serveurs support qui hébergent les modules et les mise à jour, et les serveurs de transfert automatiques – ATS. En fonction de la config, le serveur ATS fait du MitM pour gérer les transferts, ou bien du webinject (MiTB). L’injection web rajoute un keylogger JS. Chaque campagne visant une banque donnée est identifié par un projectID. En analysant les échanges avec le serveur ATS et les samples injectés, il semblerait qu’il y ai un code d’injection « racine » qui à été dérivé en fonction de la zone géographique, puis des banques ciblés.

The metrics and economics of cyber insurance for malware related claims

Le Mr travail à RiskAnalytics. (le Mr nous prévient qu’il y aura bcp de cyber dedans, j’vais filtrer). Le crime numérique est omniprésent et coûte très très très cher: 445 Milliards de $us. Le rapport de Ponemon sur le coût d’une fuite d’information bien que controversé est très utilisé comme référence. Le coût par utilisateur est estimé entre 3 et 6$ en fonction de la taille du leak. Ce type de métrique est nécessaire pour les assureur afin d’évaluer combien ça pourrait leur coûter vs combien ils vont vous facturer pour vous assurer (pari gagnant pour eux quoi…). Bon souscrire une assurance contre le risque SSI n’est pas simple, c’est plutôt pour les gros, et ça se fait parfois avec l’accompagnement d’une boite spécialisée en sécurité. Globalement, les assureurs payent presque toujours, même s’il y a eu quelques rare cas de refus. Plus la structure est petite, moins elle peut se protéger techniquement, plus elle fait appel à une mécanique d’assurance. (est-ce que l’assurance paye pour la clef de déchiffrement du ransomware en BTC ?). L’argent de l’assurance sert à payer les coûts de la crise: forensic, remise en état, etc… En fonction de l’origine de l’attaque, certains assureurs refusent de payer, comme par exemple l’espionnage d’état, la perte de revenu (couvert par d’autres assurances). Du coup la partie assurance & sécurité vont être de plus en plus proches, les entreprises de sécurité venant conseiller ou auditer les clients des assureurs pour réduire le risque. De même la sécurité numérique individuelle est la prochaine étape pour les entreprise d’antivirus.