TRISIS, le malware ciblant les systèmes industriels


TRISIS est un malware nouvelle génération qui cible les automates de sécurité. Il est une réelle menace pour les entreprises. Nous vous présentons le phénomène et nos recommandations pour le détecter.​

TRISIS, un malware nouvelle génération cible les automates de sécurité. Découvrez le phénomène et nos recommandations pour le détecter.​

Partager l’article :

Contexte général

Le 14 décembre 2017, FireEye (ouvre un nouvel onglet) et Dragos (ouvre un nouvel onglet) ont publié chacun un rapport autour du malware nommé TRISIS (que l’on retrouve également sous la dénomination TRITON ou HatMan) ciblant les automates de sécurité, Safety Instrument System (SIS) en anglais, de la gamme Triconex du constructeur Schneider Electric.

Ce malware est le quatrième du genre touchant spécifiquement les systèmes industriels. Le premier cas qui est probablement le plus connu est Stuxnet qui ciblait les automates programmables industriels (ou PLC en anglais) de la marque Siemens gérant les centrifugeuses d’enrichissement d’uranium du programme nucléaire en Iran. Ce malware a permis de montrer la capacité d’un code malveillant à prendre le contrôle d’une installation physique pour provoquer une casse-matériel.

La seconde attaque avec le malware Havex ciblait spécifiquement les entreprises européennes en recherchant la présence de réseau industriel.

Puis en 2015 et 2016, l’Ukraine a été touchée par deux attaques ciblant son système de distribution d’électricité provoquant une interruption de courant pendant plusieurs heures.

chronologie des malwares

L’élément important à noter dans l’attaque TRISIS est la prise de contrôle non pas d’un automate programmable industriel (PLC) mais d’un automate de sécurité (SIS). Il s’agit d’une catégorie d’automate conçue selon des normes élevées pour faire face à des défaillances ou à une panne du système de production nominal. Dans le milieu industriel, afin d’assurer la sécurité des personnes et de l’installation industrielle, des analyses de risques industriels (HAZOP, AMDEC) sont réalisées pour identifier les processus critiques nécessitant un mécanisme de sécurité complémentaire.

Le malware TRISIS montre que ces systèmes de sécurité (safety) peuvent être aussi la cible d’une cyber-attaque. Certes, les SIS sont souvent de simples équipements électromécaniques (exemple : relais électrique) ou un automate isolé. Sur des installations complexes, il peut s’agir de plusieurs automates de sécurité interconnectés entre eux mais isolés, en théorie, du reste du réseau industriel.

Découverte de l’attaque

A partir des informations que nous avons pu rassembler, il semble que l’attaque ait été détectée en août 2017 par le propriétaire de l’installation industrielle suite à une panne inexpliquée ayant provoqué un arrêt de production. La société impactée n’est pas connue publiquement, mais l’installation industrielle touchée se trouve en Arabie Saoudite. Elle semble être en relation avec la société Saudi Aramco, qui a démenti avoir été impactée.

L’attaquant n’est pas connu, ni ses objectifs réels. Toutefois, la société CyberX évoque un lien probable avec l’Iran. Un groupe d’attaquants appelé OilRig et associé à l’Iran avait été identifié en octobre 2017, il ciblait justement l’Arabie Saoudite… Il est à noter que Saudi Aramco avait elle-même été touchée par une cyberattaque appelée Shamoon en 2012 qui avait été associée une fois de plus à l’Iran.

Le tableau suivant résume le séquencement de la découverte de l’attaque :

Date

 

Activités

Août 2017 Incident sur un site production
 
Septembre 2017 Investigation avec l’équipe local et Schneider Electric
 
Novembre 2017 Analyse conjointe du malware par les sociétés Dragos et FireEye
 
13 Décembre 2017 Schneider Electric publie un bulletin de sécurité à destination de ces clients
 
14 Décembre 2017 FireEye et Dragos publie leur analyse du malware sous le nom de TRISIS et TRITON
 
18 Décembre 2017 

Le département de l’intérieur américain (NCCIC) publie son analyse du malware sous le nom de “HatMan”

Analyse du malware​

Plusieurs sociétés de sécurité ont analysé le malware (ouvre un nouvel onglet), ce dernier est composé de plusieurs fichiers :

  • exe : script python (script_test.py) converti en exécutable à partir de Windows,
  • zip : l’archive ZIP qui contient de nombreux scripts en langage Python permettant la communication avec les automates de sécurité Schneider Triconex,
  • bin : fichier binaire (pour processeur PowerPC),
  • bin : fichier binaire (pour processeur PowerPC),

Le nom du script « script_test.py » laisse supposer que l’attaquant était encore à un stade de développement de son attaque. Le malware ne dispose pas de fonctionnement de communication réseau permettant d’être piloté à distance. Un second malware de type RAT (Remote Administration Tool) doit surement exister afin d’apporter ces fonctionnalités.

Le malware peut être lancé soit avec en option l’adresse IP de l’automate à infecter, autrement il scanne les équipements répondant sur le port UDP/1502. On note qu’il ne s’agit pas du port par défaut de l’automate, cela montre que l’attaquant devait cibler des installations particulières, sur lesquelles il avait pu obtenir des informations contextualisées.

Le script, une fois connectée à l’automate Triconex, modifie la logique programmée en injectant le contenu des fichiers imain.bin et inject.bin. L’attaque ayant été détectée alors que l’attaquant était en cours de tests, il est difficile d’évaluer ses objectifs réels… On peut supposer, de par la nature de l’équipement, que les conséquences pourraient être importantes sur l’installation industrielle ou sur les vies humaines.

Plusieurs chercheurs de FireEye, Dragos et Schneider Electric ont présenté les résultats de leurs travaux à la conférence S4x18 Event (ouvre un nouvel onglet).

Détection & Recommandations

Pour identifier ce malware, il est possible de rechercher les comportements suivants :

  • Déterminer si les installations industrielles comportent des automates de la gamme Triconex (notamment le modèle 3008),
  • Contrôler la présence de fichiers suspects en utilisant les règles de détection YARA (ouvre un nouvel onglet) fournies par l’ICS-CERT et FireEye,
  • Contrôler au niveau réseau la présence de flux réseau suspect – comme par exemple à destination du port UDP/1502.

Pour les équipements sensibles de type SIS, les préconisations suivantes sont à observer :

  • L’ensemble des automates de sécurité doivent être isolés, ou sur un réseau complètement distinct,
  • Identifier l’ensemble des postes d’ingénierie utilisés pour programmer les automates de sécurité et leur appliquer les règles de sécurité adaptées en se référant notamment au guide de l’ANSSI (ouvre un nouvel onglet),
  • Analyser l’architecture du système industriel et notamment son cloisonnement avec le réseau bureautique, partenaires et Internet,
  • Conserver les automates Triconex sur la position RUN – ne permettant pas, en théorie, une modification de la logique embarquée,
David Bigot, consultant cybersécurité chez Orange Cyberdefense

A propos du blogueur

David Bigot est un consultant intervenant depuis plus de 10 ans dans la cybersécurité auprès des industriels français.

Passionné par la sécurité et technophile, il intervient dans l’audit et l’accompagnement à la sécurisation des systèmes industriels.

Suivez-nous sur Twitter
Orange Cyberdefense @OrangeCyberdef

Cette semaine sur le blog, on s’intéresse à la réponse à incident ! Découvrez les best practices ici : https://t.co/LXLSgT9civ https://t.co/9tW71CXM7T

Orange Cyberdefense @OrangeCyberdef

RT @Wisper_fr: Super conférence hier lors du salon #SITafrica de Nicolas Arpagian sur la #cybersécurtié, assurer la continuité de service…

Orange Cyberdefense @OrangeCyberdef

RT @sth4ck: On vous retrouve donc à 14h pour la suite des conférences ! Merci encore à nos sponsors @OrangeCyberdef @YogoshaOfficial https:…