JunOS et RedPenguin

Le 13 mars 2025, Juniper a publié un article intéressant sur une infection par un logiciel malveillant trouvée sur un ensemble de routeurs Juniper MX dont l'existence a été portée à sa connaissance en juillet 2024. La campagne a été baptisée "RedPenguin". Cet incident était fascinant car il semblait incroyablement avancé et nécessitait une compréhension approfondie du système d'exploitation des routeurs Juniper (JunOS).

En utilisant des identifiants de connexion compromis, ces attaquants ont installé plusieurs démons qui modifient la mémoire, établissent des canaux de communication pour l'administration à distance, nettoient les journaux et démarrent divers mécanismes IPC.

Ce qui ressort immédiatement, ce sont les méthodes de communication réseau. Par exemple, le RAT installé appelé "jdosd" (Junos Denial of Service Daemon) communique avec un serveur C2 pour exécuter des commandes et lire et écrire des fichiers sur le routeur. Utilisant un listener UDP sur le port 33512, il met en œuvre un protocole de cadrage assez basique qu'un scanner de réseau ne pourrait pas facilement trouver.

Contrairement à TCP, où le serveur doit renvoyer un SYN/ACK ou un SYN/RST, UDP est sans connexion, ce qui le rend difficile à analyser, car vous disposez de deux options pour déterminer si un socket UDP distant est à l'écoute lorsque le serveur n'initie pas de transmission de données :

1. Vous pouvez construire un paquet qui provoquera une réponse du serveur distant. (par exemple, envoi d'une requête DNS au port 53)
2. Recherchez les messages ICMP de non-atteinte de port renvoyés par le serveur distant.
   1. Cette méthode est très peu fiable en raison du filtrage standard et de la configuration de l'hôte.

Ainsi, avec UDP, à moins que vous ne puissiez construire un paquet dans lequel le serveur répondra avec des données, il est presque impossible de savoir s'il y a quelque chose à l'autre bout. Le protocole de cadrage UDP pour ce processus "jdosd" exige qu'un serveur C2 s'y connecte (un processus inversé par rapport à la plupart des opérations C2 où le dispositif compromis se connecte en retour au C2) et envoie un paquet spécialement conçu qui inclut certaines informations d'authentification. Une fois cette poignée de main terminée, le processus "jdosd" commence à lire les commandes du socket.

Malheureusement, au moment de la rédaction de ce blog, nous n'avons pas pu obtenir d'échantillon pour observer de première main la poignée de main de la connexion, de sorte qu'il était inutile d'analyser aveuglément UDP/33512 à la recherche d'un tel service. Même si nous pouvions le rechercher, nous ne pourrions parler que des personnes compromises et non des attaquants, étant donné que ces derniers se connectent aux routeurs et non l'inverse.

Les services "/usr/sbin/appid" et "/usr/sbin/to" ont été identifiés comme étant une version modifiée d'une porte dérobée open-source appelée Tiny SHell où plusieurs adresses IP codées en dur ont été trouvées. Le routeur se connectera alors à l'une de ces adresses IP sur le port 22 et écoutera les commandes à exécuter localement. Voici les adresses IP codées en dur connues :

• "/usr/sbin/appid"
  • 129.126.109.50
  • 116.88.34.184
  • 223.25.78.136
  • 45.77.39.28
• "/usr/sbin/to"
  • 101.100.182.122
  • 118.189.188.122
  • 158.140.135.244
  • 8.222.225.8

Une chose à noter ici est que cela a été rapporté en juillet de l'année dernière, et nous n'avons même pas de date exacte pour ce rapport, juste une fourchette générique. Cela signifie que l'examen des hôtes tels qu'ils sont aujourd'hui n'est pas forcément identique à l'examen qu'ils ont fait à cette époque.

8.222.225.8 (ci-dessus) n'a constamment eu que deux services en cours d'exécution entre le 1er juin 2024 et le 1er août 2024 ; le plus remarquable est le service écoutant sur le port 22 (le port auquel le logiciel malveillant TinySHell se connecte), qui s'est annoncé comme un serveur OpenSSH standard de tous les jours. L'existence de ce service spécifique signifie soit qu'il ne s'agit pas du port auquel le logiciel malveillant s'est connecté à l'origine, soit qu'il s'agit d'un serveur TinySHell hautement modifié pour ressembler à un véritable serveur OpenSSH.

La seule fois où 45.77.39.28 a eu des services en cours d'exécution dans cet intervalle de temps, c'était à la fin du mois de juillet, plus précisément le 29 juillet 2024. Comme pour l'hôte précédent, un serveur OpenSSH écoutait sur le port 22 et a été supprimé deux jours plus tard, le 31 juillet 2024.

116.88.34.184 a toujours eu six services différents en cours d'exécution tout au long du mois de juillet 2024, à l'exception du 02 juillet, lorsqu'un étrange service inconnu a été démarré sur le port 3265 et s'est arrêté le 04 juillet. En dehors de cette anomalie, l'hôte était un serveur multimédia domestique exécutant Plex, un NAS Synology, et une page d'administration ASUS ZenWiFI AX Mini (qui pourrait avoir été vulnérable à la CVE-2024-3080). Comme pour les deux hôtes précédents, le service écoutant sur le port 22 était un serveur SSH légitime utilisant Dropbear au lieu d'OpenSSH.

118.189.188.122 n'a assuré que deux services tout au long du mois de juillet 2024 : une interface d'administration ASUS RT-AX82U sur le port 8443 (qui pourrait avoir été vulnérable à CVE-2022-35401) et un serveur SSH Dropbear sur le port 22 (qui sont tous deux toujours opérationnels au 13 mars 2025). Là encore, il n'y a aucun signe d'un service unique comme TinySHell fonctionnant sur le port 22.

129.126.109.50 avait deux services en cours d'exécution tout au long du mois de juillet 2024 : un service SSH Dropbear sur le port 22 et un ASUS RT-AX55 (qui pourrait avoir été vulnérable à un RCE signalé par le CERT taïwanais).

158.140.135.244 exécute le même nombre de services depuis juillet 2024. Le port 22 est encore un autre serveur OpenSSH, et à côté d'un tas de sites web ASP différents, nous trouvons encore une autre page d'administration de routeur ASUS (RT-AX58U) sur le port 8443, qui pourrait avoir été vulnérable à un exploit que nous avons rapporté en juin 2024.

223.25.78.136, tel qu'il est actuellement, n'est pas le même hôte physique qu'il était en juillet 2024. À partir du 7 juillet 2024, nous avons observé cinq services différents : un serveur SSH Dropbear sur le port 22, un serveur VPN IKE sur UDP 500, un service OpenVPN sur le port 1194, un service serial to network (ser2net) sur le port 5000, et encore une autre page d'administration du routeur ASUS RT-AX58U sur le port 8443.

Comme pour 101.100.182.122nous n'avons eu aucun service en cours d'exécution pendant le mois de juillet 2024, et nous avons même regardé quelques mois auparavant ; il se peut que notre scanner ait manqué quelque chose.

Nous mettons en évidence ces interfaces d'administration ASUS parce que si Mandiant a raison d'estimer que ces attaques ont été menées via un réseau ORB (Operational Relay Box), alors beaucoup des services que vous verrez sur les hôtes sources ressembleront à des dispositifs résidentiels de type SOHO (tels que les routeurs ASUS). En réalité, ces appareils sont (ou étaient) très probablement compromis et utilisés comme proxy. Et comme nous savons qu'ASUS a été la cible de plusieurs campagnes de piratage à grande échelle, il est probablement plus sûr de dire que ces appareils appartenaient à des individus innocents mais étaient contrôlés par des parties malveillantes. C'est une coïncidence trop étrange que presque tous ces serveurs C2 utilisent des routeurs ASUS.