4 juin 2020

Retours sur le SSTIC – 18e édition « OnLine » – Jour 1

SSTIC

Cette année, BSSI était virtuellement présent à la 18e édition.

Vous souhaitez plus d’informations ? C’est par ici :

Dans cet article nous vous proposons des résumés de quelques conférences du premier jour :

Pivoter tel Bernard, ou comment monitorer des attaquants négligents

Par Daniel Lunghi (Trendmicro)

Le chercheur de Trendmicro, Daniel Lunghi, a présenté dans cette conférence les différentes techniques que ses collègues et lui-même ont utilisées afin de monitorer un groupe d’attaquant ayant effectué des attaques ciblées.

Le groupe en question a ciblé des entreprises de Paris et de jeux en ligne en Asie du Sud-Est entre mai 2019 et mars 2020.

Les buts de cette enquête étant de :

  • Identifier les TTP (Tactics, Techniques and Procedures)
  • Faciliter la détection et la réponse aux incidents
  • Récupérer autant d’information que possible sur l’attaquant

Étape 1

La première étape a été l’analyse des échantillons recueillis sur les postes infectés. Cela consiste à extraire les IOC (domaine, IP, nom de fichier, clé de registre, etc.), à lister les fonctionnalités du malware et tenter d’identifier sa famille. Un désassembleur, des règles Yara et un moteur de recherche sont suffisants pour réaliser cela.

Cette première analyse a permis de découvrir 4 familles de malware, dont 3 inconnues.

Par la suite, la présentation se concentre sur l’un des malwares. Ce dernier se présente sous la forme d’une archive contenant un exécutable signé par Microsoft, une DLL malveillante et une payload chiffrée. L’analyse montre que le malware a, entre autres, la capacité d’enregistrer les frappes clavier, d’enregistrer l’écran, et d’exécuter des commandes.

Des numéros de version indiquent que le malware a connu au moins 8 évolutions entre mai et juillet 2019.

Étape 2

La seconde étape a ensuite consisté à trouver de nouvelles souches malveillantes liées à l’attaquant à partir des éléments récupérés lors de l’analyse statique.

Les recherches sur des chaînes de caractères uniques sur VirusTotal et l’utilisation d’outils tels que RetroHunt et de règle Yara ont échoué.

Les communications entre le malware et le C&C ont dû être déchiffrées par rétro-ingénierie et ont permis de découvrir deux nouveaux C&C.

Les métadonnées des souches analysées ont permis de les relier à plusieurs autres fichiers malveillants ayant le même « original filename » ou le même auteur.

Étape 3

La troisième étape a ensuite consisté à découvrir l’infrastructure de l’attaquant.

Le « passive DNS » permet d’obtenir un historique des adresses IP associées à un nom de domaine. En effet, certains attaquants réutilisent des serveurs pour des campagnes d’attaques différentes. Il faut toutefois être vigilant, car un hébergeur peu regardant devient rapidement un nid à attaquant et un même serveur peut servir à deux groupes d’attaquant bien distincts.

Les noms de domaines déposés en même temps que les C2C déjà connus permettent de découvrir d’autre nom de domaines malveillants (par analyse de noms).

Enfin certains services comme Shodan ou Censys permettent de repérer des IP liées à des certificats TLS associés au groupe d’attaquant.

Les sandboxes publiques permettent également de découvrir des IP, des noms de domaine ou des souches malveillantes liées à l’attaquant. Cette méthode a permis de trouver quatre familles de malwares.

Ces étapes ont dû être réalisées à chaque découverte d’un nouvel élément.

Il n’y avait au départ qu’une quinzaine de souches appartenant à 4 familles de malwares distinctes, avec 5 noms de domaines et 3 adresses IP de C&C différents.

À l’arrivée, l’enquête réalisée par Trendmicro a permis de lier l’attaque à :

  • 4 familles de malwares
  • 14 noms de domaines supplémentaires
  • 6 adresses IP supplémentaires
  • Des dizaines de souches différentes
  • Un vecteur de compromission (4 documents malveillants utilisés pour du spear-phishing)
  • Une liste de nombreux outils de post-exploitation utilisés par l’attaquant
  • Une victimologie précise
  • Des liens avec deux groupes d’attaquants connus et documentés (EmissaryPanda/LuckyMouse et Winnti)

Quand les bleus se prennent pour des chercheurs de vulnérabilités

Par Sylvain Peyrefitte, Analyste du CERT d’Airbus.

La première partie de la présentation a été initiée par un rappel du travail des équipes bleus qui se résumait à l’analyse des logs. Pourtant, avec des systèmes devenant toujours plus complexes, offrant plus d’opportunités aux attaquants, le travail des défenseurs nécessite de plus en plus d’expertise englobant des compétences mixtes.

L’analyste a utilisé l’exemple d’une chaîne d’exploitation existante (exploit Bluekeep), toute en explicitant des moyens et des outils qu’un membre d’une équipe bleue peut mettre en place pour analyser, disséquer et générer des événements système de Windows (les ETW), afin  de détecter des comportements ou binaires suspects.

Ce processus fait appel à des notions et outils proches de ceux utilisés par les chercheurs de vulnérabilités.

Au début Sylvain a mentionné que le nombre de sources de log entre Windows 7 et Windows 10, a augmenté de façon exponentielle :

  • Windows 7 : 635 providers
  • Windows 10 : 1102 providers + WPP + Tracelogging

Cette augmentation a poussé les chercheurs à développer des moyens et des outils  permettant de trouver des événements, et d’en évaluer leurs pertinences en laboratoire.  Sachant qu’aujourd’hui les SIEM sont coûteux, une telle approche permet d’optimiser la collecte des événements ciblant précisément un comportement malveillant, et de faire des économies.

Le processus présenté se décompose en trois étapes :

  • Analyse des événements malveillants : Comme pendant un test d’intrusion réseau ou une analyse de trace (fichier PCAP), l’idée est d’étudier les événements pour détecter un binaire suspect. Pour cela, l’outillage Wireshark a été développé (plugins Wireshark pour disséquer les événements système de Windows)
  • Remonter à la source et l’analyser : Analyse statique via des outils de décompilation (IDA) ou dynamique via debugger du service, mettant en lumière le comportement malveillant.
  • Être proactif pour aller plus loin dans l’analyse et la détection système : une fois la détection et l’analyse réalisées, l’étape suivante consiste à créer les sources d’événements

L’analyste a ensuite expliqué la modularité du ETW (Event Tracing for Windows) et a cité les outils orientés essentiellement autour de l’analyse de performance système comme Windows Performance Analyzer, qui se base sur des providers disponibles dans la Common Language Runtime (clr.dll).

La deuxième partie de la présentation a été sous forme d’une démonstration technique.

En se basant sur le scénario d’exécution de l’exploit Bluekeep (CVE-2019-0708) sur Windows 10, l’objectif a été d’illustrer l’intérêt de Wireshark dans un cas réel.

Grâce à cet outil, il est possible d’identifier facilement un événement particulier :

Dans cet exemple :

  • Il provient du provider Microsoft-Windows-RemoteDesktopServicesRdpCoreTS
  • Il possède l’identifiant 148
  • Il possède un champ se nommant ChannelName possédant la valeur ms_t120

Une fois l’événement suspect identifié, l’étape suivante vise à comprendre pourquoi et comment cet événement est émis par le service Terminal Server, afin de savoir si ce dernier est pertinent.

Pour cela, l’analyste a décrit techniquement la procédure de l’analyse statique et dynamique, l’outil ETWBreaker a été utilisé dans ce contexte.

Une image contenant capture d’écran

Description générée automatiquement

Une fois la vulnérabilité exploitée, le schéma d’attaque principal consiste en la pérennisation de l’accès. Pour ce faire, les attaquants utilisent de plus en plus d’outils « légitimes », présents par défaut sur le système Windows. Ils vont s’employer à utiliser des outils d’administration tels que Powershell, Visual Basic Script, JavaScript, etc. dans le but d’être le plus discret possible. Sauf pour Powershell (qui possède des logs), les autres outils cités ci-dessus laissent très peu de traces.

Ceci représente un énorme avantage pour les attaquants, qui n’hésitent pas à utiliser des langages de script tels que le Visual Basic ou JavaScript pour le déploiement du premier stage d’infection.

Enfin une fois l’analyse finie, les ETW permettent de créer les sources d’événements pour aller encore plus loin dans l’analyse et la détection système.

CANanalyze : a python framework for automotive protocols

Par Erwan Le Disez et Etienne Charron

Pour finir la première journée du SSTIC, Erwan et Etienne sont « venu » pour présenter le framework CANanalyze dévéloppé en collaboration entre Renault et Thalès.

Avant de rentrer dans le vif du sujet, les consultants ont fait une présentation des différents éléments qu’il était possible d’auditer et ont rappelé le fonctionnement des ECU (Electronic Control Module), des BUS ainsi que du rôle de la passerelle (Gateway) :

Une image contenant capture d’écran

Description générée automatiquement

Il ressort de leur étude que la partie multimédia est la plus exposée car elle est interfaçable avec des éléments tels que la bluetooth. L’objectif d’un attaquant est alors d’exploiter une vulnérabilité au sein de cet ECU, bypasser la sécurité de la gateway pour ensuite aller exécuter des actions sur la partie véhicule, partie la plus sensible.

Une image contenant capture d’écran

Description générée automatiquement

L’exploitation de la Gateway peut se faire grâce à la présence de services de debug ouverts ou non authentifiés.

Après cette brève mais très intéressante introduction à la sécurité des véhicule, les deux consultants ont présentés leur outil répondant à une capitalisation de bout de code disponible en interne et avec un souhait de réaliser un framework simple d’utilisation et pouvant rajouter des fonctionnalités facilement :

Une image contenant capture d’écran

Description générée automatiquement

La conférence s’est terminée par une présentation de leur outil.

Laisser un commentaire

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