{ "id": "20126412-9063-4619-946e-786c2fb5e12b", "created_at": "2026-04-06T00:19:37.606896Z", "updated_at": "2026-04-10T03:21:19.943568Z", "deleted_at": null, "sha1_hash": "12e91322a0a56f4218de3e37d6e48d6cf82ee131", "title": "JunOS and RedPenguin - Censys", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 263812, "plain_text": "JunOS and RedPenguin - Censys\r\nBy Jean Pierre Ruiz Ocampo\r\nPublished: 2025-03-14 · Archived: 2026-04-02 10:46:27 UTC\r\nOn March 13, 2025, Juniper published an interesting article about a malware infection found on a set of Juniper\r\nMX routers that they were made aware of in July 2024. They have dubbed the campaign “RedPenguin.” This\r\nincident was fascinating because it looked incredibly advanced and required a deep understanding of Juniper\r\nrouters’ operating system (JunOS).\r\nUsing compromised login credentials, these attackers installed several daemons that modify memory,\r\nestablish communication channels for remote administration, clean up logs, and start up various IPC\r\nmechanisms.\r\nWhat stood out immediately was the network communication methods. For example, the installed RAT called\r\n“jdosd” (Junos Denial of Service Daemon) communicates with a C2 server to execute commands and read and\r\nwrite files to the router. Utilizing a UDP listener on port 33512, it implements a fairly basic framing protocol that\r\na network scanner couldn’t easily find.\r\nUnlike TCP, where the server must send back either a SYN/ACK or SYN/RST, UDP is connectionless, which\r\nmakes it challenging to scan as you have two options for determining whether a remote UDP socket is listening\r\nwhen the server does not initiate data transmission:\r\n1.\r\nYou can construct a packet that will elicit a response from the remote server. (e.g., sending a DNS query to\r\nport 53)\r\n2. Look for ICMP port unreach messages coming back from the remote server.\r\n1.\r\nThis is very unreliable due to standard filtering and host configuration.\r\nSo, with UDP, unless you can construct a packet where the server will respond with data, it’s nearly impossible to\r\ntell if something is on the other end. The UDP framing protocol for this “jdosd” process requires that a C2 server\r\nconnects to it (a process reversed from most C2 operations where the compromised device connects back to the\r\nC2) and sends a specially crafted packet that includes some authentication information. Once this handshake has\r\nbeen completed, the “jdosd” process will start reading commands from the socket.\r\nUnfortunately, as of drafting this blog, we could not obtain a sample to observe the connection handshake\r\nfirsthand, so blindly scanning UDP/33512 for such a service was futile. Even if we could scan for it, we could\r\nonly talk about who was compromised instead of who the attackers are, given that the attackers connect to the\r\nrouters instead of vice versa.\r\nBut this is not the case for all of the malware that was installed; the services “/usr/sbin/appid” and “/usr/sbin/to”\r\nwere identified to be a modified version of an open-source backdoor called Tiny SHell where several hard-coded\r\nhttps://censys.com/blog/junos-and-redpenguin\r\nPage 1 of 6\n\nIP addresses were found. The router will then connect to one of these IP addresses on port 22 and listen for\r\ncommands to execute locally. These are the known hard-coded IP addresses:\r\n“/usr/sbin/appid”\r\n129.126.109.50\r\n116.88.34.184\r\n223.25.78.136\r\n45.77.39.28\r\n“/usr/sbin/to”\r\n101.100.182.122\r\n118.189.188.122\r\n158.140.135.244\r\n8.222.225.8\r\nOne thing to note here is that this was reported way back in July of last year, and we don’t even have an exact date\r\nfor this report, just a generic range. This means that looking at the hosts as they currently are may not be the same\r\nas looking at them from that point in time.\r\nhttps://censys.com/blog/junos-and-redpenguin\r\nPage 2 of 6\n\n8.222.225.8 (above) consistently had only two services running between June 1st, 2024, and August 1st, 2024; the\r\nmost notable is the service listening on port 22  (the port to which the TinySHell malware connects), which\r\nadvertised itself as a standard everyday OpenSSH server. The existence of this specific service either means that\r\nthis was not the port the malware originally connected to, or it’s a highly modified TinySHell server made to look\r\nlike a real OpenSSH server.\r\nThe only time 45.77.39.28 had any services running in this time range was at the end of July, specifically July\r\n29th, 2024. Like the previous host, an OpenSSH server listened on port 22 and was removed two days later, on\r\nJuly 31st, 2024.\r\nhttps://censys.com/blog/junos-and-redpenguin\r\nPage 3 of 6\n\n116.88.34.184 consistently had six different services running throughout July 2024, except for July 02, when a\r\nstrange unknown service was started on port 3265 and stopped on July 04. Outside this anomaly, the host was a\r\nhome media server running Plex, a Synology NAS, and an ASUS ZenWiFI AX Mini administration page (which\r\nmay have been vulnerable to CVE-2024-3080). Like the prior two hosts, the service listening on port 22 was a\r\nlegitimate SSH server running Dropbear instead of OpenSSH.\r\n118.189.188.122 consistently ran only two services throughout July 2024: an ASUS RT-AX82U administration\r\ninterface on port 8443 (which may have been vulnerable to CVE-2022-35401) and a Dropbear SSH server on port\r\n22 (which are both still up and running as of March 13, 2025). Again, there is no sign of any unique service like\r\nTinySHell running over port 22.\r\nhttps://censys.com/blog/junos-and-redpenguin\r\nPage 4 of 6\n\n129.126.109.50 had two services running throughout July 2024: a Dropbear SSH service on port 22 and an ASUS\r\nRT-AX55 (which may have been vulnerable to an RCE reported by the Taiwanese CERT)\r\n158.140.135.244 has been running the same number of services since July 2024. Port 22 is yet another OpenSSH\r\nserver, and alongside a bunch of different ASP websites, we find yet another ASUS router (RT-AX58U)\r\nadministration page on port 8443, which may have been vulnerable to an exploit we reported on back in June of\r\n2024.\r\nhttps://censys.com/blog/junos-and-redpenguin\r\nPage 5 of 6\n\n223.25.78.136, as it stands currently, is not the same physical host as it was back in July of 2024. Starting around\r\nJuly 07, 2024, we observed five different services: a Dropbear SSH server on port 22, an IKE VPN server on UDP\r\n500, an OpenVPN service on port 1194, a serial to network (ser2net) service on port 5000, and yet another ASUS\r\nRT-AX58U router administration page on port 8443.\r\nAs for 101.100.182.122, we did not have any services running throughout July 2024, and we even looked a few\r\nmonths prior; it could be that our scanner somehow missed something.\r\nWe highlight these ASUS administration interfaces because if Mandiant is correct in assessing that these\r\nattacks were conducted via an ORB (Operational Relay Box) network, then many of the services you will see on\r\nthe source hosts will look like residential SOHO-grade devices (such as ASUS routers). The reality is that these\r\ndevices are (or were) most likely compromised and being used as proxies. And given that we know that ASUS has\r\nbeen a target of several large-scale hacking campaigns, it’s probably a safe bet to say that these devices were\r\nowned by innocent individuals but were controlled by malicious parties. It’s too strange of a coincidence that\r\nalmost all of these C2 servers were running ASUS routers.\r\nThe Censys ARC Research Team\r\nCensys ARC is a team of elite security and threat researchers dedicated to identifying, analyzing, and shedding\r\nlight on Internet phenomena that impact our world. Using Censys’ Map of the Internet — the world’s most\r\ncomprehensive, accurate, and up-to-date source for Internet infrastructure — ARC investigates and measures the\r\nentirety of the public Internet to share critical and emerging threat intelligence and insights with organizations\r\naround the world. \r\nSource: https://censys.com/blog/junos-and-redpenguin\r\nhttps://censys.com/blog/junos-and-redpenguin\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://censys.com/blog/junos-and-redpenguin" ], "report_names": [ "junos-and-redpenguin" ], "threat_actors": [], "ts_created_at": 1775434777, "ts_updated_at": 1775791279, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/12e91322a0a56f4218de3e37d6e48d6cf82ee131.pdf", "text": "https://archive.orkl.eu/12e91322a0a56f4218de3e37d6e48d6cf82ee131.txt", "img": "https://archive.orkl.eu/12e91322a0a56f4218de3e37d6e48d6cf82ee131.jpg" } }