JunOS und RedPenguin

Am 13. März 2025 veröffentlichte Juniper einen interessanten Artikel über eine Malware-Infektion, die auf einer Reihe von Juniper MX-Routern gefunden wurde und auf die man im Juli 2024 aufmerksam wurde. Sie gaben der Kampagne den Namen "RedPenguin". Dieser Vorfall war faszinierend, weil er unglaublich fortschrittlich aussah und ein tiefes Verständnis des Betriebssystems der Juniper-Router (JunOS) erforderte.

Mit kompromittierten Anmeldedaten installierten diese Angreifer mehrere Daemons, die den Speicher modifizieren, Kommunikationskanäle für die Fernverwaltung einrichten, Protokolle bereinigen und verschiedene IPC-Mechanismen starten.

Was sofort auffiel, waren die Methoden der Netzwerkkommunikation. Das installierte RAT namens "jdosd" (Junos Denial of Service Daemon) kommuniziert beispielsweise mit einem C2-Server, um Befehle auszuführen und Dateien auf dem Router zu lesen und zu schreiben. Über einen UDP-Listener an Port 33512 wird ein recht einfaches Framing-Protokoll implementiert, das ein Netzwerkscanner nicht ohne weiteres finden kann.

Im Gegensatz zu TCP, bei dem der Server entweder ein SYN/ACK oder SYN/RST zurücksenden muss, ist UDP verbindungslos, was das Scannen schwierig macht, da Sie zwei Möglichkeiten haben, um festzustellen, ob ein entfernter UDP-Socket zuhört, wenn der Server keine Datenübertragung initiiert:

1. Sie können ein Paket konstruieren, das eine Antwort vom entfernten Server hervorruft. (z. B. das Senden einer DNS-Anfrage an Port 53)
2. Suchen Sie nach ICMP-Port-Unreach-Meldungen, die vom Remote-Server zurückkommen.
   1. Dies ist aufgrund der Standardfilterung und der Hostkonfiguration sehr unzuverlässig.

Mit UDP ist es also fast unmöglich, festzustellen, ob am anderen Ende etwas ist, es sei denn, man kann ein Paket konstruieren, auf das der Server mit Daten antwortet. Das UDP-Rahmenprotokoll für diesen "jdosd"-Prozess erfordert, dass sich ein C2-Server mit ihm verbindet (ein umgekehrter Prozess als bei den meisten C2-Operationen, bei denen sich das kompromittierte Gerät mit dem C2-Server verbindet) und ein speziell gestaltetes Paket sendet, das einige Authentifizierungsinformationen enthält. Sobald dieser Handshake abgeschlossen ist, beginnt der "jdosd"-Prozess, Befehle aus dem Socket zu lesen.

Leider konnten wir zum Zeitpunkt der Erstellung dieses Blogs keine Probe erhalten, um den Verbindungs-Handshake aus erster Hand zu beobachten, so dass ein blindes Scannen von UDP/33512 nach einem solchen Dienst sinnlos war. Selbst wenn wir danach scannen könnten, könnten wir nur darüber sprechen, wer kompromittiert wurde und nicht, wer die Angreifer sind, da die Angreifer sich mit den Routern verbinden und nicht umgekehrt.

Die Dienste "/usr/sbin/appid" und "/usr/sbin/to" wurden als modifizierte Version einer Open-Source-Backdoor namens Tiny SHell identifiziert, bei der mehrere fest kodierte IP-Adressen gefunden wurden. Der Router stellt dann eine Verbindung zu einer dieser IP-Adressen an Port 22 her und wartet auf Befehle, die lokal ausgeführt werden sollen. Dies sind die bekannten fest kodierten IP-Adressen:

• "/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

Dabei ist zu beachten, dass dies bereits im Juli letzten Jahres gemeldet wurde, und wir haben nicht einmal ein genaues Datum für diesen Bericht, sondern nur einen allgemeinen Zeitraum. Das bedeutet, dass der aktuelle Stand der Hosts nicht unbedingt mit dem damaligen Stand übereinstimmt.

8.222.225.8 (siehe oben) hatte zwischen dem 1. Juni 2024 und dem 1. August 2024 durchgängig nur zwei Dienste laufen; der bemerkenswerteste ist der Dienst, der auf Port 22 lauscht (der Port, mit dem sich die TinySHell-Malware verbindet), der sich selbst als alltäglicher Standard-OpenSSH-Server anpreist. Die Existenz dieses speziellen Dienstes bedeutet entweder, dass dies nicht der Port war, mit dem sich die Malware ursprünglich verbunden hat, oder dass es sich um einen stark modifizierten TinySHell-Server handelt, der wie ein echter OpenSSH-Server aussieht.

Das einzige Mal, dass unter 45.77.39.28 in diesem Zeitraum Dienste liefen, war Ende Juli, genauer gesagt am 29. Juli 2024. Wie der vorherige Host lauschte ein OpenSSH-Server auf Port 22 und wurde zwei Tage später, am 31. Juli 2024, entfernt.

Auf 116.88.34.184 liefen im Juli 2024 durchgängig sechs verschiedene Dienste, mit Ausnahme des 02. Juli, als ein seltsamer unbekannter Dienst auf Port 3265 gestartet und am 04. Juli gestoppt wurde. Abgesehen von dieser Anomalie handelte es sich bei dem Host um einen Heim-Medienserver, auf dem Plex, ein Synology NAS und eine ASUS ZenWiFI AX Mini Administrationsseite (die möglicherweise für CVE-2024-3080 anfällig war) lief. Wie bei den beiden vorherigen Hosts handelte es sich bei dem Dienst, der auf Port 22 lauschte, um einen legitimen SSH-Server, auf dem Dropbear anstelle von OpenSSH lief.

118.189.188.122 hat im Juli durchgehend nur zwei Dienste betrieben 2024: eine ASUS RT-AX82U-Verwaltungsschnittstelle auf Port 8443 (die möglicherweise für CVE-2022-35401anfällig war) und ein Dropbear-SSH-Server auf Port 22 (die beide am 13. März 2025 immer noch aktiv sind). Auch hier gibt es keine Anzeichen für einen besonderen Dienst wie TinySHell, der über Port 22 läuft.

Auf 129.126.109.50 liefen im Juli 2024 zwei Dienste: ein Dropbear-SSH-Dienst auf Port 22 und ein ASUS RT-AX55 (der möglicherweise für einen vom taiwanesischen CERT gemeldeten RCE anfällig war)

158.140.135.244 führt seit Juli 2024 die gleiche Anzahl von Diensten aus. Port 22 ist ein weiterer OpenSSH-Server, und neben einer Reihe verschiedener ASP-Websites finden wir eine weitere ASUS-Router (RT-AX58U) -Administrationsseite auf Port 8443, die möglicherweise für einen Exploit anfällig ist , über den wir bereits im Juni 2024 berichtet haben.

223.25.78.136 ist derzeit nicht mehr derselbe physische Host wie im Juli 2024. Ab dem 07. Juli 2024 beobachteten wir fünf verschiedene Dienste: einen Dropbear-SSH-Server auf Port 22, einen IKE-VPN-Server auf UDP 500, einen OpenVPN-Dienst auf Port 1194, einen Seriell-zu-Netzwerk-Dienst (ser2net) auf Port 5000 und eine weitere ASUS-RT-AX58U-Router-Verwaltungsseite auf Port 8443.

Wie für 101.100.182.122liefen im Juli 2024 keine Dienste, und wir haben sogar ein paar Monate vorher nachgesehen; es könnte sein, dass unser Scanner etwas übersehen hat.

Wir heben diese ASUS-Administrationsschnittstellen hervor, denn wenn Mandiant mit seiner Einschätzung richtig liegt, dass diese Angriffe über ein ORB-Netzwerk (Operational Relay Box) durchgeführt wurden, dann sehen viele der Dienste, die Sie auf den Quellhosts sehen, wie SOHO-Geräte für Privatanwender aus (z. B. ASUS-Router). In Wirklichkeit sind (oder waren) diese Geräte höchstwahrscheinlich kompromittiert und werden als Proxys verwendet. Und da wir wissen, dass ASUS das Ziel mehrerer groß angelegter Hacking-Kampagnen war, ist es wahrscheinlich, dass diese Geräte unschuldigen Personen gehörten, aber von böswilligen Parteien kontrolliert wurden. Es ist ein zu merkwürdiger Zufall, dass fast alle dieser C2-Server mit ASUS-Routern betrieben wurden.