The Enemy Within Tracking Liminal Panda And Silentair Through Mobile Networks

Update (12 November 2026): Added a Key Takeaways section summarising the main findings.

In this blog, we outline the publicly reported, China-nexus LIMINAL PANDA threat actor’s evolution in its attacks on mobile operator networks, with a focus on its activity on the signalling interconnect network. We also outline malicious signalling activity that we have observed over the last 2 years to a new signalling threat actor, whom we term SilentAir , whose activity we also believe aligns to China-nexus cyber operations. Together they show the extent and the length to which sophisticated threat actors have advanced in this space. Finally, we outline possible connections between these two threat actors, as well as what the mobile industry needs to do to properly deal with these roaming threats.

Taiwan is the primary target of SilentAir, but not the only one. We observed SilentAir-related sources in at least six Asian countries target a dozen additional countries and territories. Targets included political and government VIPs.

The SilentAir attacks threaten calls, messages, privacy and account security. Enea observed intercepted two-factor authentication codes immediately after interception for some targets, suggesting attempts to access other accounts.

LIMINAL PANDA was detected operating across multiple operators. Enea detected hundreds of attempted covert communications. Evidence points to 5–10 infected operators, with dozens more potentially affected. Attacker activity includes stealthy compromise and information retrieval.

New malware and techniques highlight the limits of isolated defences. LIMINAL PANDA’s new GTPDoor version uses GTP-U, making malicious activity harder to detect. Operators need coordinated visibility across roaming protocols and internal systems, not isolated partial defences.

The Origin of the Global Mobile Interconnection Network

All mobile operators interconnect with each other using a number of interfaces in order to support roaming, messaging, voice and data services between each other. Across these interfaces, mobile networks exchange signalling traffic through a collection of interconnect protocols. Historically, much of this signalling relied on SS7 protocols (2G & 3G), 4G introduced the use of the Diameter protocol for LTE roaming and, most recently, HTTP/2-based protocols are used for 5G. Data roaming from 2.5G onwards has used a specific protocol called GTP (GPRS Tunnelling Protocol), which has a specific version for control plane communications (GTP-C), which sets up the data channel, and to transport the data itself (GTP-U).

All of these signalling protocols are carried over inter-operator transport environments. Dedicated circuit switched connections were first initially used for SS7 for voice and mobility management. The initial private packet interconnection for data was the GRX (GPRS roaming exchange). This was originally developed to support GTP-C and GTP-U. This evolved to become part of the IPX (IP Packet eXchange)in 2007-2008, which is a broader interconnect point capable of carrying multiple services and signalling technologies, including the original GRX services, along with Diameter, SIP and SS7, now running over IP transports.

Figure 1: Evolution of the IPX, note this excludes the Diameter/LTE interconnect evolution.

This interconnect system, built on top of the IPX, creates a large and highly trusted ecosystem involving mobile operators, roaming hubs, signalling providers and other intermediaries. That trust is essential for global roaming, but it also creates an attractive environment for attackers. The trust model was shown to be vulnerable with the emergence of SS7 security abuses in 2014, which were later validated with reports of real life attacks , along with subsequent reporting of abuse and attacks over Diameter . The industry then subsequently recommended a series of recommendations for SS7, Diameter, GTP and 5G security, along with other recommendations on general signalling security. While signalling exploits using SS7, Diameter and even SMS are now well known, until recently there have not been any public reports of actual GTP abuse. This is despite the fact there is well known, significant malware – GTPDoor – which directly exploits the GTP protocol.

Detection of GTPDoor Activity in the Wild

GTPDoor is a Unix-based remote-access implant that uses the GTP-C protocol for covert command & control (C2) communications. It was first publicly reported and analysed from two publicly available versions in February 2024, by the malware researcher HaxRob. It was then subsequently featured as a tool used by the threat actor named CL-STA-0969, by Palo Alto . This threat actor was stated to have a large overlap with the threat actor named LIMINAL PANDA by CrowdStrike . CrowdStrike had assessed in Nov 2024 that LIMINAL PANDA’s activity “ aligns with China-nexus cyber operations ” – with low confidence. Since then, another firm, Brandefence, stated they: “ assess with moderate confidence that some aspects of LIMINAL PANDA are operating on behalf of a regional bureau of China’s Ministry of State Security (MSS).”

The recommendations from these IP security firms to deal with entities like LIMINAL PANDA have included the need for GTP Firewalls, but there hasn’t been any reported detection of GTPDoor activity on the GTP-C protocol until very recently. In July 2026 POST Luxembourg reported publicly that they had detected GTPDoor activity. This marked the first time GTPDoor activity using the GTP-C protocol had been reported on.

At this point, we can reveal that we began to detect GTPDoor activity, and other associated LIMINAL PANDA activity on the GTP-C interface, via our GTP firewall, in multiple customer mobile operators from Q1 2026 onwards . As part of our service, we successfully blocked this GTPDoor activity. Like POST, in subsequent investigation of the traffic and its sources we could see that these GTPDoor sessions were being used to try to send commands or help initiate connections to exfiltrate information. In total we detected several hundred attempted covert C2 communications, and disrupting this gave us information pointing to multiple other infected mobile operators over the IPX interface. We have directly observed or seen strong indications of at least 5 to 10 mobile operators infected and our intelligence leads us to believe that there may be several dozen infected operators globally, with an emphasis on Asia, Africa and Latin America.

The types of GTPDoor-transported commands we observed included:

Starting/stopping communication & exfiltration tunnels (using modified versions of tools like SGSNemu)

Encapsulation of commands using other tools for lateral movement through the infected operator (using malware like EchoBackdoor)

Initiation of other processes, including SSH commands

Malware process health checks, general host environment process checks

Hiding of activity, including attempts to delete files and directories, timestomping etc

And other activity consistent with a threat actor seeking to preserve and expand their presence in infected networks.

A specific example of how LIMINAL PANDA uses GTPDoor is a combination of commands to setup the local tool environment, send commands to other nodes to initiate data exfiltration and C2 communication via a GTP-U tunnel, and then cleanup the environment by terminating the tunnel and terminating utilised malware once all the information was retrieved. Below is a typical sequence of events the LIMINAL PANDA attacker uses, using GTPDoor, and a combination of other binaries to exfiltrate information from Operator B to Operator A.

Figure 2: GTPDoor-initiated GTP-U tunnel setup. Note: in the above diagram “Backdoor” could be any number of potential backdoor binaries LIMINAL PANDA uses, although EchoBackDoor is primarily observed in our experience.

Typically, the information is tunnelled from the targeted infected mobile operator (operator B in this case) back to a GGSN or some other IPX facing node in Operator A, which is also infected. However, it is also possible for the tunnel to be setup in the opposite direction, or different mobile operators may be used. While the CrowdStrike blog discussed the fact that a scheduled script initiated the tunnels at a set time each day, this is not what we observed in our experience. Instead, we detected that in the early stages of an infection, tunnels are attempted to be generated quite frequently, while later on there are larger and larger gaps between the tunnel creations. These differences may be due to changes in attacker behaviour over time or because we observed live behaviour.

Figure 3: Distribution of the GTP-U tunnel durations shows that exactly half occur in less than 21 minutes, whereas other lasted for much longer. A very small volumes of tunnels lasted for 24 hours+.

From our observations and events after subsequent blocking of GTPDoor, it is clear that the attacker had other methods to control malware in the mobile network, including SSH. However, GTPDoor was extensively used at times when those were either unavailable or as a backup. Our experience shows that both the LIMINAL PANDA group and misuse of the GTP-C interface is a live and present threat to mobile networks, especially as LIMINAL PANDA have expanded their toolset to go beyond GTP-C.

New GTPDoor Evolution: Now Available in GTP-U

While we first detected GTPDoor activity using the GTP-C protocol, through our investigations we subsequently uncovered evidence that LIMINAL PANDA uses a new GTPDoor version, specifically one which uses the GTP-U protocol , not GTP-C. GTP-U is the data transport part of the GTP protocol, while GTP-C is the control plane part of it. We were then able to discover a Linux malware sample on VirusTotal which mapped to the GTP-U behaviour (see IoCs).

We call this new version of the GTPDoor malware, GTPDoor version 3 or GTP-U-Door/GTPDoor(U) . The use of GTP-U is a very significant development when it comes to detecting malicious network activity. This is because:

Inspection and filtering of GTP-U traffic is more complex as there are multiple layers of protocols within the GTP-U tunnels.

The volume of GTP-U traffic on IPX connections is order of magnitudes higher than GTP-C, making it much easier to hide or embed malicious traffic within here.

Traditionally GTP-U has been seen as less ‘exploitable’ compared to GTP-C, so mobile operators have not invested the same resources into securing it.

A comparative breakdown of an example GTP-U-Door packet compared to the original GTPDoor version1/2 is shown below:

Figure 4: Structure of GTPDoor v1/v2 versus GTPDoor v3.

In both cases, we have shown the bytes after the TEID as padding, because from the malware’s perspective, it doesn’t actually care what they are. In reality, LIMINAL PANDA would normally use Echo Requests for GTP-C, and T-PDUs with an inner IP payload for GTP-U. As you can see the GTPDoor v3 payload is deep within the GTP-U packet itself. We believe that GTPDoor v3 is deployed primarily as a backup in case other methods were blocked.

Figure 5: Code capture of UDP Ports used by GTPDoor v3

In terms of the binary itself, it shows a clear lineage from earlier versions. The default XOR key is the same as GTPDoor v1 and v2, with also the same ability to change the key. The other main change is the adoption of libpcap for packet capture, replacing the raw socket receive path in v1/v2. One possible reason the malware authors may have modified this is that the libpcap listener does not appear in ‘netstat’ or ‘lsof’, which was one of the host-based detection methods from HaxRob’s GTPDoor v1/2 analysis . Curiously though some features from GTPDoor v2 are removed – GTPDoor v3 doesn’t have an ACL feature like GTPDoor v2.

Figure 6: GTPDoor commands per version. GTPDoor v3 shows more similarity to GTPDoor v1 than v2.

Overall, we regard this as a significant development in LIMINAL PANDA’s telecom capability, as it’s an evolution towards an area of IPX traffic that has escaped larger scrutiny to date. It’s also a form of future proofing as GTP-C is used from 2G to 4G only, but it will be replaced in 5G, unlike GTP-U, which is reused in 5G. However, this not the only significant development in malicious activity on the IPX interface.

SilentAir: New State-level Threat Actor Generating Malicious Signalling Activity

Investigating the activity we initially found some similar behaviour to the Russian-linked signalling Threat actor HiddenArt [3] . HiddenArt attempted to hide by using SCCP Global Titles or GTs, (SS7 signalling addresses) that were similar to legitimate network elements. In addition, HiddenArt distinguished itself by sometimes seemingly responding twice to transaction sequences it initiated, or by changing its source to Russian signalling addresses halfway through the transaction. This ultimately allowed us to determine that HiddenArt did not fully control all of the signalling addresses it used.

When received, these uninitiated transactions were ignored by the infected network

When received, the uninitiated transactions were errored (aborted) at the end by the infected network

When received, the uninitiated transactions were correctly acknowledged at the end by the infected network

This wide range of behaviour is not standard behaviour for a node doing malicious update locations and so drew attention. A “normal” malicious signalling interception node would respond correctly to all of these transactions. In this SilentAir case, this activity suggested that only specific transactions were being processed, and anything that did not match was being ignored or being left to be dealt with by the underlying mobile network. We also observed cases where the same node seemingly responded twice to a transaction – a sure sign of suspicion. Therefore, just like in the HiddenArt case we were left with two possible explanations:

The source of the attacks was being spoofed from outside the network and the responses received at the network were being copied along the return path – like HiddenArt.

The source of the attacks was inside the network, i.e. a network node was compromised with a malicious process. This was sending attacks and receiving responses.

During our investigation, we were later able to observe network elements within a mobile operator both initiate and receive the signalling attack commands, confirming that it was (2) above, i.e. the network itself was compromised . This compromised node inside the mobile network behaved exactly like other SilentAir nodes we had observed in other networks. The use of malware inside the network also meant that the system was far more stable and less prone to failure that the HiddenArt “copying” system, which often had to switch to Russian GTs in order to sustain long command sequences.

Subsequent detection and blocking of these attacks initially provided to be difficult, as the attackers had a good understanding of both mobile networks and signalling defence methods. Once containment was in place, we recovered artifacts of unauthorised access, but due to the SilentAir operators’ good operational security (OPSEC), we were unable to successfully analyse the hypothetical SilentAir binary used for these attacks. However, from this and other analysis we were able to piece together a comprehensive overview of the tactics and objectives of this threat actor.

Signalling Targeting Tasking of SilentAir

From our analysis, the external targets of this signalling threat actor are split into two types:

At times we also observed multiple source SilentAir nodes in different infected mobile networks in different countries co-ordinate to launch attacks on high value, VIP-type targets, but this was exceptional, normally only one infected mobile network would be used at a time. This co-ordination indicates these systems communicate to a single controller who initiated the tasking.

The SilentAir attacker normally uses the SS7 protocol, but also sometimes the Diameter protocol, and on both protocols a primary focus of the attacks is malicious location updates (SS7 or Diameter Interception). A breakdown of the types of attacks, from SilentAir sources are below:

For comparison, we have compared this to our research on the normal kinds of attacks we observe from surveillance companies, who account for the overwhelming majority of attacks on signalling interfaces. As you can see the SilentAir threat actor’s activity is very different. An overview of the activity is as follows:

Given the above, Enea’s Threat Intelligence Unit assess that SilentAir’s activity aligns with China-nexus cyber-operations. This assessment is made with low confidence based on the following factors:

As stated, the Threat actor’s signalling behaviour strongly matches a state-level actor, not a criminal group or a surveillance company.

Other overall features of the nature of the signalling activity, including its periods of activity. The timing of the attacks strongly suggests a human involvement, not automatic processes. When we plot out normal signalling attacks (non-silent SMS) we see that global attack activity – regardless of the timezone of the target – strongly matches what would be expected for a UTC+8 /China Standard Time operator – see figure 7. Similar to the recent analysis of the China-nexus Volt Typhoon threat actor by Lumen , we see two dips of activity, one in the mid-morning and one in the evening. We also observed pauses or reductions of activity around China holiday periods.

The nature of the targets, some of whom we learnt were VIP individuals in the political and government domain in their respective countries.

An additional factor is the possible co-ordination of SilentAir with the reportedly China-nexus LIMINAL PANDA group (see later), however as this is unproven it does not influence our current assessment.

Specific SilentAir Tactics: Usage of Silent SMS

In the section, we outlined the high prevalence of “other” activity by the SilentAir attacker, specifically the use of silent SMS. The use of silent SMS actually turns out to be one of its most interesting tactics, as it gives us clues to both the mindset and ultimate objectives of the Threat Actor.

Figure 7: Heatmap of SilentAir’s signalling attacks, one showing Tracking, Interception and Harvesting activity, another showing Other (silent SMS activity). Non-silent SMS activity aligns well with UTC+8 working day. Silent SMS activity is most active around midnight, with residual retries after that. Silent SMS during the day is expected to be testing activity.

Above is the timing for both Tracking/Harvesting/Interception or non-silent SMS activity by the SilentAir threat actor, and Other (silent SMS) activity. This is taken from globally observed behaviour, across multiple timezones. As stated, non-silent SMS activity is very regularly aligned with a UTC+8 working day. Works starts at 9am, most attacks happen during the days, with dips in the morning and evening, before some residual activity in the early morning. Notably we essentially never observe activity over the weekend.

Silent SMS on the other hand shows a very different pattern, it heavily spikes on midnight on all days bar Saturday night/Sunday morning, and has only some residual activity during the day. The different timing for the silent SMS matches its primary usecases:

Figure 8: Flow diagrams showing the two outcomes of an updateLocation attack, and how silent SMS can be used to determine if the attack was successful. Note: Depending on the destination, SMSC may strip silent SMS features from MT-FSM.

Surprisingly for silent SMS messages, the ones generated by the SilentAir threat actor contain text. This text is a mix of generic, spam-like motivational or promotions messages, often in English, but sometimes in local languages, although the English phrases used would not be typical for native speakers. Some examples of these are below:

Wishing you endless energy and wellness!

Stay healthy, stay happy, always shine!

Strong body, calm mind, joyful heart!

Health as steady as mountains ahead!

Fresh air, bright smiles, vibrant life!

While it was initially confusing as to why any text would be included (as the user would never see it), our belief for this is that we have observed sometimes the interim SMSC that is used to transport the silent SMS message to its final destination can sometimes strip out the silent SMS features of the text. This would render the message visible to the recipient. While a blank text message or a text message with machine like text would generate concern, including spam like-content is a form of social engineering and would mean the recipient would simply dismiss it, unaware of the message’s true origin and purpose.

Strength of Association Between SilentAir and LIMINAL PANDA

In investigating both the LIMINAL PANDA and the SilentAir Threat actors, we quickly became aware of a possible link between the two. As stated, we were unable to successfully analyse the hypothetical SilentAir binary used for these attacks, and as a result we cannot at this time confirm a LIMINAL PANDA association, however, we had to consider a link in some form due to the following:

Shared Timing : The timing of the malicious signalling activity we observed from several SilentAir infected mobile operators tracked with the time period of a known LIMINAL PANDA infection in those same mobile operators. In addition, we sometimes observed overlaps between some SilentAir signalling attacks from infected nodes in a mobile operator, followed by attempts of subsequent LIMINAL PANDA/ GTPDoor initiated data exfiltration tunnel establishments from other infected network nodes in the mobile operator. After these LIMINAL PANDA GTP communication attempts finished, new forms of SilentAir signalling attacks were initiated by the infected network. However, at other times we didn’t see any form of co-ordination.

Shared Targeting : The SilentAir mobile operator targeting we observed on the signalling attacks also matches LIMINAL PANDA’s reported mobile operator targets in the Asian area. This however is not an exclusive feature, nor is there any known Taiwan focus by LIMINAL PANDA

Known Capability : The SilentAir signalling activity we observed seems similar – but not fully – consistent with a little-known Linux binary trojan called SCTPE (see IoCs), which is a kernel-level software directly designed to send and receive SS7 and Diameter traffic. According to a report from the Singaporean government, this program has been associated with moderate confidence to LIMINAL PANDA by CrowdStrike. Controlled by a user-level process, SCTPE [5] , injects SS7/Diameter traffic using an underlying SCTP connection already in place on the infected machine. Once the traffic has been injected it has a set window (5 seconds) to receive back data responses, and then potentially to generate further packets in the sequence. Any other transactions received are ignored and not processed, and are left to whatever SCTP-connection using process that is running on the machine. A screenshot of the relevant reverse compiled code from the SCTPE binary is below.

Figure 9: SCTPE’s TCAP TID/Diameter End2EndID red-black tree traversal logic. Return value of 0 means previously generated (cached) id received in less than 5001 milliseconds, -1 means ID has never been cached – so not a transaction to process, -2 was cached but timer has expired. Return function only processes an id with return value of 0.

However, the issue in aligning the known SCTPE binary’s behaviour with real-life observed SilentAir activity is that we have seen uninitiated transactions being handled with and responded to by the infected SilentAir node . Some of these responses we believe are due to the underlying host node running legitimate SCTP clients, and these responding to the transactions. But others we believe are from the SilentAir process itself. This should not be possible based on the current SCTPE binary known. It strictly only processes transactions it generated.

Figure 10: Flow diagram showing what would be expected from the LIMINAL PANDA-connected SCTPE binary (left), and what we actually observed from the SilentAir threat actor (right). SilentAir responds to transactions it did not initiate.

Given that the basis of some of the attacks – such as the interception of SMS or calls – rely on the receipt of an uninitiated transaction by the SilentAir node, then it becomes clear that the use of SCTPE would not be suitable for them in all cases. SCTPE seems much more suited for simple request/response attacks.

Overall, this points to a possible, but unconfirmed link of the SilentAir actor with LIMINAL PANDA. If not LIMINAL PANDA, then the question is who. While other threat actors such as the reportedly China-nexus threat actor Red Menschen target protocols used in telecom like SCTP, LIMINAL PANDA is the only threat actor know to date to actively exploit the IPX. LIMINAL PANDA has also been identified in using other tools like SIGTRANslator and Cordscan which also use core network signalling protocols for lateral movement and discovery respectively.

On the other hand, the fact we observe behaviour outside the capabilities of the known SCTPE malware is important in questioning a direct association. In addition, the operational security of the SilentAir actor seemed far superior to LIMINAL PANDA, and the times of operation seemed subtly different between the two actors. This is why we do not directly associate the two at this time . It’s possible that different groups may access to a compromised operator once obtained or co-operate in carrying out separate operations. It’s also equally possible that these mobile operators may have been compromised by two China-nexus threat actors at the same time.

We will continue to monitor this actor, and if our assessment of SilentAir attribution’s to LIMINAL PANDA changes we will update this blog. Regardless of attribution, the behaviour of the SilentAir threat actor represents a serious threat to mobile operators.

As part of this activity, we have worked with our customers to remove any potential LIMINAL PANDA activity on their network, as well as contacting any other LIMINAL PANDA infected operator we detected. We also informed the SilentAir infected mobile operators of the presence of malicious signalling sources in their network, potentially connected to this group. This, coupled with other activity by industry partners during the same time has meant that we believe that LIMINAL PANDA’s and SilentAir’s global footprints have been affected, forcing it to adapt and react. We will continue to monitor signalling traffic to determine the extent of its and other threat actors’ actions.

While LIMINAL PANDA & SilentAir are the focus of this report, the same techniques they use could be repeated by any other threat actor. This leads us to the following recommendations:

Attackers will use every interconnect protocol, so defenders need comprehensive signalling security at the edge . If they have not already done so, mobile operators should deploy GTP-C and GTP-U security systems/ firewalls. These systems must also be aligned and sharing information with SS7 and Diameter security firewalls. As we show in this report, the advantage in having visibility on multiple interconnect protocols gives the ability to detect threats which would not be apparent from just one protocol. If you have one attacker and five defending systems, all seeing only a little part of the attacks, this greatly reduces the chance of successfully understanding and stopping the overall attack.

Signalling security cannot just be based on industry recommendations . The industry has come a long way in recommending what types of checks to do on what signalling protocols, but there is a danger that these recommendations come to be regarded as the endpoint for signalling security, rather than the start. SilentAir and other advanced adversaries show the need to go beyond rote protections. Any credible signalling security system needs to be accompanied with methods and analysis that goes beyond the industry basics, otherwise the mobile operator is left with the illusion they are protected, when they are not.

The IPX interface must be regarded as untrusted . The evolution of signalling security has been based on the gradual realisation that the interconnect between mobile operators cannot be regarded as a trusted link. SilentAir and in particular LIMINAL PANDA exploits any available interconnect protocol, not just SS7, Diameter, GTP, but also other protocols like DNS, ICMP etc. Interconnect security must be taken to the logical conclusion of treating all of the IPX interface as untrusted. This means additional deeper analysis and firewalling of all current and future traffic, which again has to be considered, not in isolation, but in a cross-protocol and multi-bearer approach.

Internal mobile network security also needs to take into account signalling protocols . Within the mobile network, LIMINAL PANDA uses multiple control plane protocols and tools like SIGTRANslator and Cordscan to relay C2 commands, perform scans and explore its environments, however mobile operators often don’t scan these protocols or investigate the correctness of what is being communicated. This is a significant vulnerability that is being exploited today. Once the IPX edge is secure, these internal interfaces need to be properly analysed. Firewalling does not necessarily need to occur at these points, but detection logic does. This takes on critical importance with the growth of 5G networks, where mobile operators don’t physically own all parts of their network.

Signalling security is a critical part of the mobile operator’s overall security . Alignment of signalling/IPX security outputs and detections also needs to happen with the rest of the mobile operator’s security profile. In the past signalling security has been often treated as a core network responsibility, due to a lack of telecom expertise in operator security and the perceived difference of threats. LIMINAL PANDA, which is equally comfortable gaining access by signalling protocols or by more “traditional” methods like SSH access or shared credentials shows the need for mobile operators to integrate signalling security with other IT security systems. This is easier to move from signalling space to IT space than vice versa.

As well as the above, there are other practical implications that mobile operators need to consider. One key implication is that managed core networks have an impact on network security . In investigating attacks, we repeatedly encountered the fact that mobile operators have in many cases outsourced the running of their core network to vendors. While this may make economic and practical sense, it makes security investigations more difficult. If mobile operators don’t have full knowledge and ownership of their network, then sensitive investigations become much harder. This is especially important to consider if countries need to have digital sovereignty of their critical assets, of which telecom network are a part of.

We have shown that the LIMINAL PANDA group has expanded its tooling, and that it or a similarly focused threat actor we named SilentAir is also actively launching attacks on the signalling interface. Our experience in tracking this group over the last 18+ months, has shown us that access to any one of the world’s 800+ mobile operators then gives an attacker access to all others through the IPX interface. With the introduction of AI, the bar for attackers to create new malware to exploit the IPX has greatly reduced. While the LIMINAL PANDA & SilentAir groups themselves have been disrupted for now, the conditions remain for them or any other group to come back and further exploit mobile operators. The tools have been built and the threat has been proven – if mobile operators don’t want to be the victim of a hacking or signalling attack then they need to react now.

Analysis of LIMINAL PANDA and SilentAir was performed by Enea’s Technology team and Enea’s Threat Intelligence Unit. To create this report, we have worked with our customers, other mobile operators, and the general telecom security industry. We have also co-ordinated with POST Luxembourg’s Cyberforce team, because in recent months it became apparent that we were investigating much of the same activity. Competition in cybersecurity matters should not interfere with the need to block and disrupt malicious activity where possible, and we are grateful to POST for their hard work and expertise.

IOC MD5s – Sample Malware Reference

[1] “State-level” is the term we use to differentiate specific signalling threat actors from criminal groups or commercial surveillance companies, based on activity, targeting and objectives, see for an example and explanation.

[2] The name SilentAir is comprised from the following elements: “Silent” due to the fact of its stealthy and (nearly) undetectable nature, as well as the sending of silent SMS being one of its most notable attacks. “Air” is an Old Irish word meaning “in front of” or “before”. In the traditional Irish system of orientation, this was associated with facing the rising sun, and the root subsequently contributed to later Irish words meaning “East” ( oirthear )

[3] For the purposes of clarity, we do not believe HiddenArt and SilentAir are linked.

[5] According to this report it is termed SIGweaver by Crowdstrike