This post is also available in: 日本語 (Japanese)
Unit 42 recently identified a new, difficult-to-detect remote access trojan named PingPull being used by GALLIUM, an advanced persistent threat (APT) group.
Unit 42 actively monitors infrastructure associated with several APT groups. One group in particular, GALLIUM (also known as Softcell), established its reputation by targeting telecommunications companies operating in Southeast Asia, Europe and Africa. The group’s geographic targeting, sector-specific focus and technical proficiency, combined with their use of known Chinese threat actor malware and tactics, techniques and procedures (TTPs), has resulted in industry assessments that GALLIUM is likely a Chinese state-sponsored group.
Over the past year, this group has extended its targeting beyond telecommunication companies to also include financial institutions and government entities. During this period, we have identified several connections between GALLIUM infrastructure and targeted entities across Afghanistan, Australia, Belgium, Cambodia, Malaysia, Mozambique, the Philippines, Russia and Vietnam. Most importantly, we have also identified the group’s use of a new remote access trojan named PingPull.
PingPull has the capability to leverage three protocols (ICMP, HTTP(S) and raw TCP) for command and control (C2). While the use of ICMP tunneling is not a new technique, PingPull uses ICMP to make it more difficult to detect its C2 communications, as few organizations implement inspection of ICMP traffic on their networks. This blog provides a detailed breakdown of this new tool as well as the GALLIUM group's recent infrastructure.
Palo Alto Networks customers receive protections from the threats described in this blog through Threat Prevention, Advanced URL Filtering, DNS Security, Cortex XDR and WildFire malware analysis.
Full visualization of the techniques observed, relevant courses of action and indicators of compromise (IoCs) related to this report can be found in the Unit 42 ATOM viewer.
|Related Unit 42 Topics||Advanced persistent threats|
Table of Contents
Protections and Mitigations
Indicators of Compromise
PingPull was written in Visual C++ and provides a threat actor the ability to run commands and access a reverse shell on a compromised host. There are three variants of PingPull that are all functionally the same but use different protocols for communications with their C2: ICMP, HTTP(S) and raw TCP. In each of the variants, PingPull will create a custom string with the following structure that it will send to the C2 in all interactions, which we believe the C2 server will use to uniquely identify the compromised system:
PROJECT_[uppercase executable name]_[uppercase computer name]_[uppercase hexadecimal IP address]
Regardless of the variant, PingPull is capable of installing itself as a service with the following description:
Provides tunnel connectivity using IPv6 transition technologies (6to4, ISATAP, Port Proxy, and Teredo), and IP-HTTPS. If this service is stopped, the computer will not have the enhanced connectivity benefits that these technologies offer.
The description is the exact same as the legitimate iphlpsvc service, which PingPull purposefully attempts to mimic using Iph1psvc for the service name and IP He1per instead of IP Helper for the display name. We have also seen a PingPull sample use this same service description but with a service name of Onedrive.
The three variants of PingPull have the same commands available within their command handlers. The commands seen in Table 1 show that PingPull has the ability to perform a variety of activities on the file system, as well as the ability to run commands on cmd.exe that acts as a reverse shell for the actor.
|A||Enumerate storage volumes (A: through Z:)|
|B||List folder contents|
|F||Read file, convert to hexadecimal form|
|G||Write file, convert from hexadecimal form|
|H||Copy file, sets the creation, write, and access times to match original files|
|I||Move file, sets the creation, write, and access times to match original files|
|M||Run command via cmd.exe|
Table 1. Commands available in PingPull’s command handler.
To run a command listed in Table 1, the actor would have the C2 server respond to a PingPull beacon with the command and arguments that it encrypts using AES in cipher block chaining (CBC) mode and encodes with base64. We have seen two unique AES keys between the known PingPull samples, specifically P29456789A1234sS and dC@133321Ikd!D^i.
PingPull would decrypt the received data and would parse the cleartext for the command and additional arguments in the following structure:
&[AES Key]=[command]&z0=[unknown]&z1=[argument 1]&z2=[argument 2]
We are not sure of the purpose of the z0 parameter in the command string, as we observed PingPull parsing for this parameter but do not see the value being used. To confirm the structure of the command string, we used the following string when issuing commands in our analysis environment, which would instruct PingPull to read the contents of a file at C:\test.txt:
During our analysis, PingPull would respond to the command string above with ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM=, which decodes to and decrypts (AES key P29456789A1234sS) to some text in a test file.\x07\x07\x07\x07\x07\x07\x07, which is the content (PKCS5_PADDING-padded) of the file C:\test.txt on our analysis system.
PingPull samples that use ICMP for C2 communications issue ICMP Echo Request (ping) packets to the C2 server. The C2 server will reply to these Echo requests with an Echo Reply packet to issue commands to the system. Both the Echo Request and Echo Reply packets used by PingPull and its C2 server will have the same structure as follows:
[8-byte value]R[sequence number].[unique identifier string beginning with “PROJECT”]\r\ntotal=[length of total message]\r\ncurrent=[length of current message]\r\n[base64 encoded and AES encrypted data]
When issuing a beacon to its C2, PingPull will send an Echo Request packet to the C2 server with total and current set to 0 and will include no encoded and encrypted data, as seen in Figure 1.
The data section in the ICMP packet in Figure 1 begins with an 8-byte value of 0x702437047E404103 (\x03\x41\x40\x7E\x04\x37\x24\x70) that PingPull has hardcoded in its code, which is immediately followed by a hardcoded R. However, another PingPull sample that used ICMP for its C2 communications omitted this 8-byte value, as seen in Figure 2.
After the R is a sequence number that increments when sending or receiving data that exceeds the maximum size of the ICMP data section. The sequence number is immediately followed by a period “.” and then the unique identifier string generated by PingPull that begins with PROJECT. The ICMP data section then includes total=[integer] and current=[integer], which are used by both PingPull and its C2 to determine the total length of the data transmitted and the length of the chunk of data transmitted in the current packet. The data transmitted in each ICMP packet comes in the form of a base64-encoded string of ciphertext generated using AES and the key specific to the sample. This encoded and encrypted data comes after the new line that immediately follows the “current” value. For instance, when responding to our test command, PingPull sent the ICMP Echo Request packet seen in Figure 3 to the C2 server, which has the expected base64-encoded string of ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM= for the results of the command.
Another variant of PingPull uses HTTPS requests to communicate with its C2 server instead of ICMP. The initial beacon uses a POST request over this HTTPS channel, using the unique identifier string generated by PingPull as the URL. Figure 4 is an example POST request sent by PingPull as a beacon, where samp.exe was the filename, DESKTOP-U9SM1U2 was the hostname of the analysis system and 172.16.189[.]130 (0xAC10BD82) was the system's IP address.
The initial beacon is a POST request that did not have any data, which resulted in the Content-Length of 0 within the HTTP headers. When responding with the results to commands, PingPull will issue a second POST request using the same URL structure with the results in the data section in base64-encoded and encrypted form using the AES key. Figure 5 shows PingPull responding to our test command to read the contents of C:\test.txt with ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM= in the data section of the POST request, which decodes and decrypts to some text in a test file.\x07\x07\x07\x07\x07\x07\x07.
This variant of PingPull does not use ICMP or HTTPS for C2 communication, rather it uses raw TCP for its C2 communication. Much like the other C2 channels, the data sent in this beacon includes the unique identifier string generated by PingPull that begins with PROJECT. However, the TCP C2 channel begins with a 4-byte value for the length of data that follows, as seen in the following beacon structure:
[DWORD length of data that follows]PROJECT_[uppercase executable name]_[uppercase computer name]_[uppercase hexadecimal IP address]
Figure 6 shows an example of the entire TCP communications channel:
- The beacon sent by PingPull in the first red text.
- The C2 issuing a command in the blue text.
- PingPull responding to the command in the second red text at the bottom of the image.
The beacon seen in Figure 6 begins with a data length of 44-bytes (0x2c), with the unique identifier string generated where samp_f86ebe.exe was the filename, DESKTOP-U9SM1U2 was the hostname of the analysis system and 172.16.189[.]130 (0xAC10BD82) was the system's IP address. The C2 response to the beacon begins with the data length of 64 bytes (0x40) followed by the base64-encoded string that represents the ciphertext of the command. PingPull ran the command supplied by the C2 and sent the results in a packet that begins with a data length of 44 bytes (0x2c), followed by the expected base64-encoded string of ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM= for the results of the command.
On Sept. 9, 2021, a sample of PingPull named ServerMannger.exe (SHA256: de14f22c88e552b61c62ab28d27a617fb8c0737350ca7c631de5680850282761) was shared with the cybersecurity community by an organization in Vietnam. Analysis of this sample revealed that it was configured to call home to t1.hinitial[.]com. Pivoting on the C2, we identified several subdomains hosted under the hinitial[.]com domain that exhibited a similar naming pattern:
Digging deeper into these domains, we began to identify overlaps in certificate use between the various IP infrastructure associated with each of the subdomains. One certificate that stood out in particular was an oddly configured certificate with a SHA1 of 76efd8ef3f64059820d937fa87acf9369775ecd5. This certificate was created with a 10-year expiration window, a common name of bbb, and no other details, which immediately raised the question of legitimacy.
First seen in September 2020, this certificate was linked to six different IP addresses all hosting a variant of the hinitial[.]com subdomains as well as an additional pivot to a dynamic DNS host (goodjob36.publicvm[.]com). Continuing this method of pivoting across all of the PingPull samples and their associated C2 domains has resulted in the identification of over 170 IP addresses associated with this group dating back to late 2020. The most recent IP infrastructure is provided below for defensive purposes.
Protections and Mitigations
We recommend that telecommunications, finance and government organizations located across Southeast Asia, Europe and Africa leverage the indicators of compromise (IoCs) below to identify any impacts to your organizations.
For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:
Cortex XDR detects and protects endpoints from the PingPull malware.
WildFire cloud-based threat analysis service accurately identifies PingPull malware as malicious.
Threat Prevention provides protection against PingPull malware. The “Pingpull Command and Control Traffic Detection” signature (threat IDs 86625, 86626 and 86627) provides coverage for the ICMP, HTTP(S) and raw TCP C2 traffic.
Advanced URL Filtering and DNS Security identify domains associated with this group as malicious.
Users of the AutoFocus contextual threat intelligence service can view malware associated with these attacks using the PingPull tag.
If you think you may have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
- North America Toll-Free: 866.486.4842 (866.4.UNIT42)
- EMEA: +31.20.299.3130
- APAC: +65.6983.8730
- Japan: +81.50.1790.0200
GALLIUM remains an active threat to telecommunications, finance and government organizations across Southeast Asia, Europe and Africa. Over the past year, we have identified targeted attacks impacting nine nations. This group has deployed a new capability called PingPull in support of its espionage activities, and we encourage all organizations to leverage our findings to inform the deployment of protective measures to defend against this threat group.
Special thanks to the NSA Cybersecurity Collaboration Center, the Australian Cyber Security Centre and other government partners for their collaboration and insights offered in support of this research.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Mitre - GALLIUM group
Microsoft - GALLIUM: Targeting Global Telecom
CyberReason - Operation Soft Cell: A Worldwide Campaign Against Telecommunications Providers
Indicators of Compromise
PingPull C2 Locations
(Active in last 30 days)
Updated June 13, 2022, at 4:45 a.m. PT
Get updates from
Sign up to receive the latest news, cyber threat intelligence and research from us