malware industriel Triton
Découvrez dans cet article l’analyse, par l’équipe Security de Sentryo, d’un malware spécialement conçu pour compromettre la sécurité des systèmes industriels. Retrouvez les détails de fonctionnement du malware industriel Triton et les mesures à mettre en œuvre pour se protéger.

Malware industriel Triton : résumé opérationnel

Note : Cet article a été mis à jour après la mise à jour de l’analyse du malware par le CERT américain, de nombreux détails techniques y sont disponibles.

Triton, aussi nommé Trisis et Hatman, est un malware découvert en novembre au Moyen-Orient et dont les premières analyses sont parues mi-décembre 2017. C’est le premier malware visant spécifiquement un système industriel de sûreté (SIS : Safety Instrument Systems) qui ait été activé (une première version dormante de Stuxnet, n’ayant a priori pas été activée, visait déjà ce type d’automates). Le SIS visé était ici le produit Triconex de Schneider Electric.

Les premières analyses menées par FireEye et Dragos ainsi que les retours faits lors de la toute récente conférence internationale S4x18 indiquent que le but de ce malware était l’installation d’un Remote Access Trojan (RAT). Ce RAT permettrait de prendre le contrôle distant des systèmes afin d’éventuellement infliger des dommages matériels ou humains. L’attaquant, encore non-identifié, disposerait néanmoins de moyens techniques et financiers très importants, similaires à ceux d’un État. Le malware semble n’avoir été utilisé que dans le cadre de cette campagne d’attaque ciblée.

Le système Triconex est déployé sur plus de 15 000 sites dans de nombreux pays. Schneider Electric a travaillé à un patch correctif pour les modèles touchés ainsi qu’à un outil de détection.

Lieu, date, cible et objectif de l’attaque

L’attaque a été analysée à la mi-novembre mais elle semble remonter au mois d’août 2017 : une équipe locale associée à Schneider Electric aurait mené une première analyse lors d’une phase intermédiaire. Une seule cible est connue à ce jour et, bien que son identité ne soit pas confirmée, il pourrait s’agir d’une infrastructure saoudienne (certaines sources évoquent le nom de l’entreprise Aramco).

La cible du malware Triton
Dans le cas de l’infrastructure saoudienne visée, la cible était un modèle spécifique de système de sécurité Schneider Electric qui permet de déclencher différentes mesures de sûreté en cas d’anomalie sur un système de production.
 En particulier les modèles Triconex MP3008 avec une version logicielle comprise entre 10.0 et 10.4 sont vulnérables (les autres versions ne sont pas vulnérables sans modification de l’attaque).

Il est pour l’instant impossible de savoir avec certitude quels étaient les objectifs réels de l’attaquant car la phase finale de l’attaque ne s’est pas déroulée. Cependant, les différentes analyses montrent que les attaquants auraient déjà pu provoquer assez simplement l’arrêt de la production, ce qui n’était donc probablement pas le but final.

Déroulement de l’attaque

Les différents fichiers composant le malware Triton (en particulier les fichiers permettant la mise en place du RAT) sont disponibles en ligne, ce qui explique que diverses analyses ont déjà pu être menées. L’attaque s’est déroulée en différentes phases.

Première phase : distribution du code

Les attaquants ont obtenu un accès distant à un poste de travail utilisé pour le contrôle et la programmation des automates de SIS, ils ont ensuite utilisé une implémentation personnalisée du protocole TriStation pour télécharger le code sur le contrôleur Triconex. Le programme utilisé est un exécutable nommé trilog.exe, compilé à l’aide de Py2Exe, ce qui a facilité le reverse engineering. Dans le cas de Triton, l’adresse IP de la cible était indiquée directement dans le code source,  et le malware industriel ne s’est pas servi des possibilités de découverte réseau dont il était pourtant équipé. Le code injecté en mémoire exécute automatiquement une série de vérification permettant de vérifier que l’automate est bien vulnérable à la suite de l’attaque.

Deux obstacles pour les pirates
2 faiblesses importantes ont dû être neutralisées par les attaquants :

  • L’automate Triconex n’accepte le téléchargement de programmes qu’en mode « PROGRAM », tandis que d’autres modes (tels que « RUN ») les empêchent, ces modes sont changés manuellement via un système physique.
  • Le code injecté n’est pas persistant, il est par exemple effacé lors du téléchargement d’un nouveau programme (« download all »).

Deuxième phase : persistance et communication

Afin de surmonter ces faiblesses, les attaquants ont utilisé une faille « Zero-Day » pour réaliser une élévation de privilège et écrire le code dans la zone mémoire système et non plus utilisateur (à cause de l’importance des SIS, les automates ne sont que très rarement redémarrés, ce qui réduit le risque d’effacement de cette mémoire). Cette zone mémoire n’est pas effacée lors du téléchargement de nouveaux programmes.

Plus concrètement, une payload est écrite dans une zone mémoire vierge après diverses vérifications. Une fois cette payload en mémoire, le programme d’origine est patché pour inclure un saut conditionnel vers l’adresse de la payload. Une fonctionnalité de vérification d’intégrité de la RAM est également patchée pour éviter toute détection.

Une fois l’élévation de privilège utilisée et la payload fonctionnelle, le script utilisé est effacé et remplacé par un programme bénin n’effectuant aucune action. A ce moment l’automate est entièrement compromis.

Afin de communiquer entre l’automate et le poste de travail, le programme malveillant était programmé pour écouter des messages habituellement utilisés pour des procédures de debug (messages « GetMPStatus ») puis d’exécuter la commande attendue (à savoir “lire”, “écrire” ou “exécuter”). Cette communication permet par exemple de modifier la mémoire de l’automate même si celui-ci est dans un mode empêchant le téléchargement classique de programme (mode “RUN”).

Troisième phase : utilisation du RAT

À ce stade, à l’aide du RAT, les attaquants sont capables de contrôler à distance les automates de sécurité : il ont réussi à empêcher ceux-ci de réagir en cas de fonctionnement anormal de la production voire d’enclencher directement des procédures néfastes.

Un bug met en échec l’attaque ?

Avant que ces attaques finales puissent être exécutées, le processus industriel surveillé par ce SIS s’est arrêté, après que les automates sont entrés en mode de sûreté (failed safe state). Il est possible que ce comportement soit dû à un bug dans le programme des attaquants.

Afin de réaliser l’implantation du code dans les automates de contrôle, les attaquants utilisaient d’abord une fonctionnalité permettant de tester l’écriture en mémoire avant de l’écraser avec une programme bénin : c’est peut-être cette fonctionnalité qui a provoqué le bug et a donc limité l’impact de l’attaque. Note : Le nouveau rapport publié par le CERT américain ne donne pas d’information supplémentaire concernant la détection du malware.

Détails techniques supplémentaires

Faille Zero Day utilisée

Le programme a utilisé un appel système mal sécurisé afin d’obtenir une capacité d’écriture de 2 octets, utilisée ensuite pour l’élévation de privilège. En particulier, cet appel système lisait depuis une zone mémoire utilisateur sans vérification, les pointeurs utilisés pouvaient être modifiés durant l’exécution sans entraîner d’exception, les valeurs passées en paramètres pouvaient être conçus pour que la valeur écrite en mémoire soit la même que celle passée en paramètre, enfin aucune vérification n’empêchait la valeur d’être écrite dans une zone de mémoire protégée.

Utilisation de la fonction « Download Changes »

Afin d’ajouter la payload en mémoire sans nécessiter l’arrêt de l’application de contrôle, le malware a utilisé la fonction “download changes”, qui permet d’effectuer des changements sur le programme en cours d’exécution. Ce mode ne permet pas de supprimer entièrement le programme en cours (à l’inverse de “download all”), il est néanmoins possible d’en écraser certaines parties, ce qui était utilisé pour remplacer une payload ou effacer le programme avec la charge bénigne.

Le fichier CRC.pyc et la possibilité d’une menace plus large

Un fichier a éveillé l’attention des experts qui ont analysés le malware Triton car il pourrait indiquer que les attaquants visent également d’autres systèmes industriels. En effet, le fichier CRC.pyc implémente de nombreuses fonctions de contrôle de redondance cyclique ou CRC (concrètement ces fonctions permettent de détecter des erreurs dans la donnée, par exemple après un transfert, en utilisant des données redondantes) pour différentes normes et protocoles (comme Modbus ou XMODEM) non utilisées par le protocole TriStation.

Se protéger contre le malware industriel Triton

Afin de détecter le malware il est possible d’utiliser les règles YARA publiées par FireEye et le CERT américain, il est également possible de surveiller la présence de flux sur des ports particuliers (l’utilisation du port 1502 en UDP). Cependant, étant donné le niveau de sophistication de l’attaque et les moyens dont semblent disposer les attaquants, il est probable que ces règles statiques deviennent rapidement inefficaces.

Bien que le malware industriel Triton n’ait pas eu de graves conséquences cette fois-ci, il met une fois de plus en évidence la volonté d’acteurs puissants de développer des outils malveillants ciblant les systèmes industriels. Ces outils n’ont pas pour simple but un arrêt de la production mais bien le sabotage et l’endommagement des systèmes (à l’instar de Stuxnet). Cependant, à la différence de Stuxnet, Triton permet une communication totale et à distance entre l’attaquant et les automates du système de sécurité, et c’est probablement ce qui le rend encore plus particulier.

Une surveillance active du réseau industriel permettrait cependant de détecter des comportements suspects du malware. La reprogrammation intempestive de l’automate, l’utilisation de certaines fonctions inhabituelles (debug) et les communications vers l’extérieur (serveur de contrôle) sont autant d’éléments qu’une analyse basée sur une capacité de DPI industriel pourra détecter. Restez à l’écoute du magazine Sentryo pour suivre les évolutions du malware industriel Triton !

Sources :

https://dragos.com/blog/trisis/TRISIS-01.pdf

https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html

https://ics-cert.us-cert.gov/sites/default/files/documents/MAR-17-352-01%20HatMan%E2%80%94Safety%20System%20Targeted%20Malware_S508C.pdf

https://github.com/ICSrepo/TRISIS-TRITON-HATMAN

https://www.midnightbluelabs.com/blog/2018/1/16/analyzing-the-triton-industrial-malware

https://ics-cert.us-cert.gov/sites/default/files/documents/MAR-17-352-01%20HatMan%20-%20Safety%20System%20Targeted%20Malware%20%28Update%20A%29_S508C.PDF

https://www.cyberark.com/threat-research-blog/anatomy-triton-malware-attack/