The J-magic show: Magic packets and where to find them.

Executive summary

The Black Lotus Labs team at Lumen has been tracking the use of a backdoor attack tailored for use against enterprise-grade Juniper routers. This backdoor is opened by a passive agent that continuously monitors for a “magic packet,” sent by the attacker in TCP traffic. We have dubbed this campaign J-magic, it is a recent operation with the earliest sample uploaded to VirusTotal in September 2023. At present, we are unable to determine the initial access method, however once in place it installs the agent, a variant of cd00r, which passively scans for five different predefined parameters before activating. If any of these parameters or “magic packets” are received, the agent sends back a secondary challenge. Once that challenge is complete, J-magic establishes a reverse shell on the local file system, allowing the operators to control the device, steal data, or deploy malicious software.

We believe enterprise-grade routers present an attractive target as they do not normally have many, if any, host-based monitoring tools in place. Typically, these devices are rarely power-cycled; malware tailored for routers is designed to take advantage of long uptime and live exclusively in-memory, allowing for low-detection and long-term access compared to malware that burrows into the firmware. Routers on the edge of the corporate network or serving as the VPN gateway, as many did in this campaign, are the richest targets. This placement represents a crossroads, opening avenues to the rest of a corporate network. Our telemetry indicates the J-magic campaign was active from mid-2023 until at least mid-2024; in that time, we observed targets in the semiconductor, energy, manufacturing, and IT verticals among others.

Elements of this activity cluster share some technical indicators with a subset of prior reporting on a malware family named SeaSpy2, however we do not have enough data points to link these two campaigns with high confidence. SeaSpy was a backdoor that targeted another FreeBSD-based system, the Barracuda mail server, with a variant of cd00r. While some cd00r functions share the same non-standard names, this latest sample contains an embedded certificate that presents a “challenge” which was not present in previous examples found in VirusTotal, indicating an evolution in operational security and tradecraft. Though there have been numerous public reports of advanced actors targeting networking equipment, Black Lotus Labs tracks the J-magic campaign as unaffiliated with other more prominent clusters recently appearing in the public eye.

Technical details

Introduction

Black Lotus Labs has routinely published research on router-orientated malware, the majority of which has focused on devices in the consumer or small office/home office (SOHO) space. There are scattered reports of malware designed for enterprise grade routers (such as Jaguar Tooth and more recently Canary/BlackTech’s unnamed router malware), and the vast majority of attacks have come against Cisco IOS systems given their share in the market. The J-magic campaign marks the rare occasion of malware designed specifically for JunoOS, which serves a similar market but relies on a different operating system, a variant of FreeBSD.

Our telemetry indicates that roughly 50% of the targeted devices appear to be configured as a virtual private network (VPN) gateway for their organizations. In these instances, a victim device could be used for remote access to the Juniper router/VPN gateway and exploited for credentials or to serve as an access vector into the organization.

Once established on a device, the actor appears to favor the use of open-source malware. Our  malware sample appears to fit that trend as a custom variant of cd00r. An open-source project originally released on Packet Storm in 2000, cd00r was designed to explore the idea of an “invisible” backdoor, or one that presents a number of detection challenges for systems admins and network engineers. Upon installation, it performed the following actions

1. The agent was executed via a command line argument, specifying an interface, and listening port.
2. The agent started a pcap listener through an eBPF extension on that interface.
3. If a magic packet is detected, it spawned a reverse shell to the IP address and port specified by the magic packet.
4. The reverse shell then issues a “challenge” by sending a string encrypted via hard-coded certificate. If the remote user passes that string back, it would be given a command shell, if the string was not received it would close the remote connection.

While this is not the first discovery of magic packet malware, there have only been a handful of campaigns in recent years. The combination of targeting Junos OS routers that serve as a VPN gateway and deploying a passive listening in-memory only agent, makes this an interesting confluence of tradecraft worthy of further observation.

Malware analysis – J-magic

Our investigation into this campaign began with the discovery of an interesting malware sample uploaded to VirusTotal. The file had a name of “JunoscriptService” which mimics the Junos automation scripting service. Given that we identified the sample on a public repository, we do not have insight into the initial access vector. Once the file is uploaded on to the infected router, it expects an interface and port to be provided from the command line when executed. If these are supplied, the malware will rename itself as “[nfsiod 0]” to masquerade as the local NFS asynchronous I/O server, then hide its tracks by overwriting the previous command line arguments. Once it renamed its process, it calls the function start_pcap_listener().

The start_pcap_listener function creates an eBPF filter on the supplied interface and port, then enters a loop to process any packets hit by the filter.

The loop first checks if the packet is from the infected machine by comparing the host IP and the remote IP, if they are the same the packet is ignored. If the packet comes from a remote IP, then various fields/offsets are checked for magic bytes. There are five checks for various fields in the packet and if any of these checks are passed, a function called reverse_shell is called with IP and port to open a reverse shell to the specific tuple in the magic packet. The first predefined conditions are found below:

Magic packet conditions

The passive agent is embedded in a position to observe all TCP traffic inbound to the device, discreetly filtering for a specific set of information, or “conditions,” inserted by the attacker.

Condition 1:

• at offset 0x02 from the start of the TCP options shows the following two-byte sequence: “1366”
• the TCP options must be at least 4-bytes in size
• the attacker IP address will be in the “Sequence Number” field of the TCP header
• the destination port number equals 443

Condition 2:

• the source port of the TCP header must contain the following two-byte sequence “36429”
• the attacker IP address will be in the Sequence Number field of the TCP header
• the destination port number equals 443

Condition 3:

• the payload data following the IP and TCP headers starts with the four-byte string: Z4vE
• the attacker IP address will immediately follow the four-byte string: 0x04
• the attacker port number will immediately follow the IP address at offset 0x08

Condition 4:

• at offset 0x08 within the TCP header, the option field starts the following two-byte sequence “59020”
• at offset 0xA within the TCP options starts the attacker IP address
• the destination port number equals 443

Condition 5:

• offset 0x08 within the TCP options starts the following two-byte sequence “59022”
• offset 0xA within the TCP options starts the attacker IP address
• the attacker port number will follow the attacker IP at offset 0x0E from the start of the TCP option

If any of the remote IP addresses match on one of the five predefined conditions above, it moves to spawn a reverse shell. The reverse_shell function forks, creating a child process and renames it to [nfsiod 1]. Next it enters a loop that will connect back to the IP and port retrieved from the packet filter, using SSL. It creates a random alphanumeric string that is five characters long. This random string is encrypted using a hardcoded public RSA key.

It sends the encrypted five-character string as a challenge to the supplied IP/port combo. The response from the IP is compared to the previously created random string. If they are not equal, the connection is closed. If the strings are equal, then a shell is created with the command prompt “>>” until it receives the exit command. This would allow them to run arbitrary commands on the impacted device.

We suspect that the developer has added this RSA challenge to prevent other threat actors from spraying the internet with magic packets to enumerate victims and then simply repurposing the J-Magic agents for their own purposes, as other nation-state actors are known for exhibiting that parasitic tradecraft such as Turla.

The intersection of cd00r, SeaSpy, and J-magic

Once established on a device, the actor favors the use of open-source malware, our sample being a custom variant of cd00r. Originally released on Packet Storm in 2000 to explore the idea of an “invisible” backdoor. The project was later improved upon in 2015 then uploaded to Github; this iteration afforded more modularity such as selecting the listening port, adding a port-knock, and updating the shell to a pseudo-terminal. One of the key differences is that neither SeaSpy nor J-magic contain the port-knocking sequence from the Github version.

One other similarity between SeaSpy and J-magic is that they have five magic packet conditions, however those conditions were different across the two samples. We also observed some of the function name overlap between SeaSpy and J-magic such as “reverse_shell” and “>>” denoting a command terminal session; unfortunately, these names were common, so we assigned a low level of correlation based upon the technical overlap. The last difference is that the J-magic sample included a certificate, which was used in the challenge component referenced above; we did not observe that function or any embedded certificates in the sample that was publicly available. So, while we can associate this malware family with high confidence as a variant of cd00r, we have low confidence in the correlation to the SeaSpy family based upon the information that was released publicly.

Global telemetry

Analysis of the malware and the five conditions to execute J-magic revealed some network-based features, used to create analytics in our netflow-based telemetry. We queried our telemetry for those conditions then enriched the destination IP address with public scan data to ensure it was identified as a Juniper router, based upon available banners. If the destination IP address was not a Juniper router, it was dropped as a likely false positive.

We first deployed this analytic in mid-March 2024 and ran it through September 1, 2024, it fired on less than .01% of analyzed netflow during that time. The yield was an incredibly small dataset of potential true positives corresponding to 36 unique IP addresses representing organizations across the globe.

Potentially impacted IP addresses were grouped into two clusters; the first cluster, which made up the lion’s share, was comprised of impacted IP addresses that have self-signed X.509 certificates – indicating that these devices were acting as a VPN gateway. The remaining cluster was made up of those with an exposed NETCONF port, which is used to help automate the pulling of router configuration information and management. This second set of routers were not associated with consumer environments but rather were managed as part of a larger fleet of routers in the network communications space.

Juniper routers acting as VPN gateways

Once we started to identify Juniper routers that received one of the magic packet conditions, we noticed most of them were associated with customer premise equipment (CPE), which indicated these routers were acting as a VPN gateway for several organizations around the world. We split the VPN gateway victims into two subsets; the first is for organizations that received more than one magic packet and the second, for organizations that only received one packet. Once we had the list of potentially impacted organizations from their IP address, we enriched them again to see which IP addresses were associated with VPN gateways and computed the number of magic packets the victim IP address received.

• Heavy machinery: Norway

  • 3 Magic Packets (May 12 – July 29, 2024)

• Fiber: Russia

  • 2 Magic Packets (May 26 – 27, 2024)

• Electric panels: Norway

  • 7 Magic Packets (June 5 – August 23, 2024)

• IT: United Kingdom

  • 3 Magic Packets (June 6 – August 25, 2024)

• Unknown vertical: United Kingdom

  • 2 Magic Packets (June 11 – July 27, 2024)

• Bioengineering: Norway

  • 2 Magic Packets (June 13 – July 27, 2024)

• Marine manufacturing: Norway

  • 2 Magic Packets (June 16 – August 12, 2024)

• Construction: United Kingdom

  • 4 Magic Packets (July 3 – August 3, 2024)

Two of the more potentially interesting victims include a fiber optics/luminescence firm, and a maker of solar panels. The other two victims appeared to be in the manufacturing vertical, including two who build or lease heavy machinery.

The second list of IP addresses in the following verticals and countries only received a single packet on the dates shown that matched our signatured conditions; therefore, this group was more prone to false positives.

• Semiconductors

  • Armenia (April 1, 2024)

• Insurance

  • United States (May 2, 2024)

• IT services

  • Brazil (May 21, 2024)
  • Netherlands (June 6, 2024)
  • Brazil (June 24, 2024)
  • Norway (July 11, 2024)
  • Colombia (August 5, 2024)
  • United States (August 8, 2024)
  • Norway (August 18, 2024)

While there was some overlap in targeting of the energy sector, we also saw targeting of the technology sector, and one semiconductor manufacturer. There were also victims in the expected verticals such as manufacturing firms, in this case one that makes ferries and boats. One interesting data point is that many of the source IP addresses that sent out magic packets were listed as public VPN and Proxy services. We suspect the attacker chose these public services to better hide in the noise. And though they sent the magic packet from a public proxy, they could redirect the reverse shell to a different IP address where they had more control.

Network configuration devices: NETCONF

While the majority of the results were identified as Juniper routers acting as VPN gateways, there was a second set of limited IP addresses that had an exposed NETCONF port, which is used to help automate router configuration information and management. We have identified some of the routers that had HTML banners displaying a “Phone home” client, which is used to remotely retrieve software or configuration files. These remote management services suggest that the routers are likely managed as part of a larger fleet, such those in a network service provider, rather than used as CPE.

We suspect these devices were targeted for their central role in the routing ecosystem. As routers that are configured with network filters, settings, policies, tracking, and controls, they are valuable as targets for attackers who may want to pivot or persist within an ecosystem. We identified two IP addresses that received multiple packets, while most of them only received one packet. Due to the limited number of results and the potential for false positives, we did not want to assign too much weight to these matches.

• Unknown vertical: United States

  • 3 Magic Packets: May 25, 2024 (18:58:34) – August 7, 2024 (03:06)

• Telecommunications: Colombia

  • 2 Magic Packets: August 1, 2024 (10:21:49) – August 5, 2024 (13:07:39)

The following IP addresses in various verticals and countries received a single packet on the dates and times shown and were not identified as a VPN gateway:

• Government

  • Indonesia – March 29, 2024 (09:01:43)

• Internet service provider

  • United States – April 23, 2024 (10:05:13)

• IT services

  • Colombia – August 2, 2024 (16:12:06)

• Telecommunications

  • Colombia – March 27, 2024 (08:05:16)
  • Brazil – August 2, 2024 (06:12:30)
  • Argentina – August 9, 2024 (21:31:23)
  • Peru – August 10, 2024 (11:21:33)
  • Venezuela – August 10, 2024 (19:40:49)
  • United States – August 21, 2024 (20:01:28)

• Vertical unknown

  • United States – May 25, 2024 (18:58:34)
  • Chile – July 11, 2024 (14:02:51)
  • Colombia – August 2, 2024 (23:26:33)
  • Argentina – August 5, 2024 (19:29:23)
  • Chile – August 8, 2024 (03:36:12)
  • Colombia – August 8, 2024 (20:09:06)
  • Colombia – August 10, 2024 (07:12:28)
  • United Kingdom – August 22, 2024 (08:57:27)

One interesting correlation was that many of these remotely administered routers were physically located in South America, while most of the VPN gateways were in Europe. This could indicate that the actors are still in more of a planning/reconnaissance phase in South America. Conversely, they have placed a greater emphasis on Internet Service Provider and telecommunications firms in this part of the world.

Dedicated command and control servers

While the magic packets could have been sent from anywhere on the internet, the trigger packet contained a callback IP address. This is where the malware would send the challenge and if passed, spawn a remote shell to interact with the file system.  Like in the prior campaign, the actor favors procured VPSs with a self-signed certificate. The certificate fingerprint can be found in the indicators of compromise on our Github page. The fingerprint was observed on the same IP address, 198.46.158[.]172, at the same time from January 3 – April 21, 2024.

Conclusion

One of the most notable aspects of the campaign is the focus on Juniper routers. While we have seen heavy targeting of other networking equipment, this campaign demonstrates that attackers can find success expanding to other device types such as enterprise grade routers. We find it noteworthy that the Magic Packet malware is becoming an increasing trend in use against perimeter devices, first with BPFdoor, and Symbiote. We suspect this will only increase, as greater difficulty in detection creates more trouble for defenders and what reporting exists is solely the result of greater awareness surrounding this technique. While there is some weak association with the actors behind the SeaSpy malware campaign, we do not have any overlap between this campaign and other families mentioned in industry reports, nor with those who have previously used BPF-based backdoors. While several newsworthy groups have lately been shown to be proficient in the use of passive agents and targeting networking equipment; we have not seen any tooling overlap, victimology trends, or operational infrastructure. As we develop additional research, we will keep the community apprised of our findings and weight given to those data points.

For users of enterprise-grade routers seeking to improve detection for this activity, we recommend the following hunt guides focused on BPF based malware: Trusted Sec’s blog on memory injection, SandFly Security blog as well as Elastic’s blog with OSquery syntax.

We also suggest this detection blog for cd00r, and lastly we recommend:

• Searching your environment for all IoC’s provided in this report
• Reviewing network logs for signs of data exfiltration and lateral movement
• Checking for common persistence mechanisms

Analysis of the J-magic campaign was performed by Danny Adamitis and Steve Rudd. Technical editing by Ryan English.

For additional IoCs associated with this campaign, please visit our GitHub page.

If you would like to collaborate on similar research, please contact us on social media @BlackLotusLabs.

This information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk.