Mapping Suspected KEYPLUG Infrastructure: TLS Certificates, GhostWolf, and RedGolf/APT41 Activity

Tracking the infrastructure threat actors use is essential in identifying their operations, past and present, and gaining insights into their operational preferences. Defenders and researchers can trace attacks and anticipate future activity by analyzing the digital breadcrumbs left behind on servers, such as TLS certificates and server configurations.

In March 2023, Recorded Future's Insikt Group published a report detailing a cluster of network infrastructure associated with KEYPLUG, which they attributed to a suspected Chinese state-sponsored actor tracked by the company as RedGolf. The group is also referred to as APT41, BARIUM, and Earth Baku, among other aliases. Insikt Group uses the designation "GhostWolf" to describe this particular infrastructure set.

Building on these findings, we examined the IP addresses in the report's IoC section to identify pivots and uncover evidence of ongoing activity. Our research revealed overlaps with recently reported operations, including KEYPLUG activity targeting Italian organizations in mid-2024. This post will shed light on how looking into historical TLS certificates can uncover renewed activity by the original threat actor or attempts by another group seeking to imitate their operations.

Historical Context and the Anomaly

Our starting point in researching this activity relied on the IoC section of the report mentioned above. which listed 39 IPs associated with the GhostWolf infrastructure. We queried each IP in the Hunt app to identify commonalities that would aid in tracking more recent servers. One key data point surfaced again and again: the presence of a wolfSSL certificate found under the SSL History tab.

wolfSSL is a lightweight, open-source SSL/TLS library designed for secure communications, particularly in embedded systems and RTOS environments. The certificate identified as belonging to the GhostWolf cluster closely mirrors the example certificates provided on the wolfSSL GitHub repository. Specifically, the server administrator opted for the 1024-bit version, although larger key sizes like 2048-bit are also available.

The example certificate hosted in the repo is displayed below.

If you look too quickly, you may think the fields of the malicious certificate are identical to those in the above screenshot. However, a subtle but critical difference in the Organizational Unit (OU) fields is visible upon closer inspection. The legitimate example certificate uses "Consulting_1024" for both the Issuer and Subject, while the servers found by Insikt Group change this field to "Support_1024."

This small configuration change not only modifies the certificate's original SHA-256 hash but also produces a distinct JA4X fingerprint. As we'll discuss in the next section, these characteristics, combined with other indicators, allow us to identify newly deployed servers while filtering out those associated with the legitimate testing certificate.

Leveraging Hunt for TLS Certificate Analysis

Now that we've explored the GhostWolf infrastructure and the unique certificate configuration that led to our findings let's examine how Hunt's SSL History tools--specifically "Certificate IPs"--enable a deeper understanding of related servers and help build our search queries.

Pivoting With Certificate IPs

Revising the initial screenshot, users can click the Certificate IPs button next to a certificate of their choice to view a detailed history. For example, the certificate in question with SHA-256 hash 4C1BAA3ABB774B4C649C87417ACAA4396EBA40E5028B43FADE4C685A405CC3BF is currently associated with 122 IP addresses according to our scan data.

The historical data includes many IPs from the RedGolf report, confirming that this hash is likely linked to the reported KEYPLUG activity and validating our approach to tracking this infrastructure.

If you haven't already, we highly recommend reading the entire PDF produced by the Insikt Group to learn additional insights into hosting provider preferences and server locations.

We won't be analyzing all 122 results here. Instead, later in this post, we will focus on the most recent IPs returned from our query, along with a small group of closely assigned servers overlapping with an indicator noted in Yoroi's 2024 blog post.

JA4X Fingerprints

When creating queries to search for adversary infrastructure, relying on a single data point is insufficient and a waste of time. To further refine the returned results, we'll turn to JA4X, integrated within the Hunt app on the certificate data page.

If you're unfamiliar with JA4X, it's part of the JA4+ suite and an extension of the JA3 TLS fingerprinting method, designed to create more precise fingerprints by including additional metadata. This enhancement improves the detection of malicious or anomalous connections.

Examining the data for this certificate, we found that only 41 servers shared the JA4X fingerprint c9d784bbb12e_c9d784bbb12e_83900cc62ac7. This suggests a significant degree of similarity in how these servers are configured or managed, indicating they are under the control of the same threat actor.

At this point, we have identified multiple unique indicators tied to the certificate, including:

• The anomalous OU field: Support_1024.

• The SHA-256 hash of the certificate.

• The JA4X fingerprint: c9d784bbb12e_c9d784bbb12e_83900cc62ac7.

The more precise and targeted our query is, the more effectively we can narrow down results to a manageable set for further investigation. In the next section, we'll use Hunt's Advanced Search feature to see how many servers are still active.

Ongoing Activity

With all the necessary data points identified, we can now craft a search query to pinpoint likely GhostWolf servers that are still active. Given that we have both a JA4X fingerprint and an SHA-256 hash, we'll use JA4X for this search, as it provides more granular insights into handshake behavior, cipher suites, and other specific configuration details. Additionally, we'll include certificates with the Organizational Unit (OU) field set to Support_1024, as this appears to be a consistent marker for this cluster of IP addresses.

Using Hunt's Advanced Search feature, we crafted the following query in SQL syntax:

ja4x:c9d784bbb12e_c9d784bbb12e_83900cc62ac7 
AND 
subject.organizational_unit:"Support_1024"

The above resulted in just six IP addresses, with the earliest detection by our network scans dating back to 2023.

Recent Activity and Observations

A few of the servers in the above figure were deployed within the past week, while others have remained active for varying durations. Port 443, usually HTTPS, is the most popular.

Public reporting on KEYPLUG highlights its support for various protocols, including HTTP/S, TCP, WSS, and KCP over UDP. For the servers running on port 443, scan data revealed responses of either TLS or TCPWRAPPED. Further examination of port history indicates that some IPs also hosted WebSocket or raw TCP servers during overlapping periods.

Hosted on port 8443 of ``154.31.217[.]200```, is what we believe (thanks to discussions with friends of Hunt) to be an HTTPS-based KEYPLUG C2 server that we have been tracking for some time.

Table 1 below depicts the hosting provider and geolocation information for the six IPs identified in our query:

In May 2024, Yoroi published a blog post on a suspected APT41 intrusion into Italian organizations, noting an IoC for IP address 67.43.234[.]146:443 communicating over the QUIC protocol. This is a closely assigned server to one of the results above in Table 1, 67.43.234[.]150. Reviewing the SSL History Certificate IPs in Hunt revealed two additional adjacent IPs- 67.43.234[.]147 and 67.43.234[.]148-active from March 27, 2023, to December 23, 2024.

This pattern of connected servers assigned in close groups aligns with reporting on GhostWolf infrastructure as a common acquisition method.

While we, unfortunately, have no malware samples available to confirm direct connections between the IPs in the table and those mentioned in Yoroi's post, the overlaps and similarities to the acknowledged GhostWolf server warrant further investigation and monitoring.

A GhostWolf Variant?

While investigating additional servers associated with the JA4X fingerprint, we identified another certificate (SHA-256 Fingerprint: 3d4a60efbfbd4d3eefbfbd62efbfbd0d51efbfbd53efbfbd1a6731efbfbd7fefbfbd1174efbfbd) on 114.55.6[.]216, which remains active at the time of writing. Unlike the other certificates using Support_1024, this one resembles the example certificate on the wolfSSL GitHub repo. However, the Issued On date and time are identical to our findings above, suggesting a possible connection.

Although we cannot conclusively link this server to RedGolf activity, its hosting provider, geographic location (Aliyun Computing Co., LTD, CN), and observed port usage align with previously reported command and control infrastructure.

As we've seen throughout this blog post, analysis of TLS certificates, no matter how old, and their associated fingerprints can reveal potential connections worth investigating. Below, we'll summarize our findings and outline key takeaways for continued research and defense.

Conclusion

The reuse of modified certificate and server configurations over extended periods, coupled with consistent hosting provider preferences and consecutive IP assignments, suggests the ongoing activity of this threat actor. Whether this infrastructure is tied to RedGolf/APT41 or another group with access to the certificates remains uncertain. Still, the patterns observed and the recency of new servers being spun up warrant closer attention.

The above underscores the value of tracking certificates within your environments for defenders. Recommendations include:

• Monitoring environments for certificates with unusual or suspicious fields, such as altered Organizational Unit (OU) values or unexpected issue dates.

• Incorporating TLS fingerprinting methods like the JA4+ suite into detection workflows to identify suspicious patterns in network traffic.

These basic steps can assist users in detecting suspicious infrastructure more effectively, even when threat actors attempt to blend in the noise.

Network Observables and Indicators of Compromise (IOCs)

Historical Network Observables and IOCs