The Leak That Sparked the Investigation
Late last week, a data dump allegedly from a workstation of a threat actor who has been targeting organizations in South Korea and Taiwan was dropped on the website DDoSecrets.com, a leak site sometimes described as a successor to WikiLeaks, known for publishing sensitive and sometimes hacked data.
The author of this leak attributes this threat activity to the North Korean APT actor known as Kimsuky. Whether or not that is an accurate attribution is outside the scope of this blog; we’ll leave that up to the threat intelligence shops to validate or refute.
Spur specializes in identifying and labeling anonymizing infrastructure, so when a customer tipped us off to the IP address this threat actor was using, we set off in identifying the actual VPN or Proxy service used. This is a good case study in IP attribution in APT campaigns.
Pivoting From IP Address to Proxy Infrastructure
The original leak called out the IP address 156.59.13[.]153 and a potential fingerprint: an SSL certificate with the common name *.appletls[.]com on the non-standard port 4012. The SHA1 hash of this cert is a26c0e8b1491eda727fd88b629ce886666387ef5.
As also suggested by the original leak document, there are indeed over 1,000 other IPs addresses with that same certificate present, with some IPs listening on multiple ports all in that same 40** port range. The vast majority of these IP addresses are in China, but there are dozens spread through the world in various datacenter hosting providers.
So we can conclude that this is some sort of organized effort, was a commercial proxy service used in these cyber attacks? It’s very possible that this is simply infrastructure stood up by the threat actor in question.
After exhausting more technical means of identifying what this service could possibly be, we turned good old fashioned open-source research. Google offered very few results for this particular domain name (appletls[.]com), but where Google fails to provide, GitHub succeeds in a surprising number of cases.
Trojan Protocol and the Great Firewall Workaround
In the handful of results returned by the GitHub search (most being verbatim copies of the original data leak from DDoSecrets), one stood out. This line is immediately identifiable as a Trojan node configuration. Trojan is a proxy protocol designed to bypass the Great Firewall of China (AKA: GFW) by imitating HTTPS.
As is so often the case, one of these Trojan node strings got mixed in to a compilation of other proxy configurations in GitHub snippets that are passed around via Telegram and other chat services and forums.
We finally had a new thread to pull! We were confident now that this is a Trojan-based service, and we have another selector on which to pivot: ganode[.]org. This marks a useful case of Trojan proxy detection in practice.
A quick treatise on the Trojan URL format:
trojan://<password>@<server>:<port>?<params>#<tag>
- password: the authentication secret required to connect to the server, typically a UUID or other alphanumeric string.
- server: The hostname or IP address of the Trojan server.
- port: The port number the server is listening on. Often, this is 443 for HTTPS mimicry (as is the point of the Trojan protocol).
- tag: arbitrary comment typically displayed by the proxy client applications next to the node.
- params: There are several optional but typical parameters you might see here:
- sni=hostname: Server Name Indication (SNI) for TLS handshake, used for domain fronting.
- peer=hostname: Override the peer name used during the TLS verification.
- allowInsecure=1: Skip TLS certificate verification.
So in the case of this configuration string, we’re connecting to the front-end domain of cTAX2K93hsoCm8MXX6eY.ganode[.]org but we’re expecting a certificate that validates against mf429xciejryees2cusm.appletls[.]com, just like the certificate presented by the IP address for which we’re trying to identify a commercial service name.
From Ganode.org to WgetCloud
Googling the domain “ganode[.]org” give us more promising results, pointing us right back to GitHub, this time in an issue.
Although there is some uncertainty, this inline snippet definitely looks to me like a GFW-hopping proxy application firing up and loading a node list. Towards the bottom, we see another distinct-looking string: GaCloud. Pivot!
You know what, we’ve had such luck with GitHub, let’s eschew Google altogether and just start there.
Immediate gold. We have a new selector: WgetCloud. Pivot!!
TL;DRC (too long; don’t read Chinese): “WgetCloud (formerly GaCloud) is a service provider specializing in stable VPNs”.
Alright, we have a service name. Last step is verification. Should be easy…
… Oh right, it’s all Chinese.
Inside the WgetCloud Service Offerings
After asking ChatGPT to solve this Captcha for me, we had an account. Let’s check out their service offering.
TL;DRC: There are three tiers of service offering. The most premium tier offers 29 exit nodes in several distinct countries, including China, Singapore, the United States, Germany, Australia, Russia, etc. Payment is accepted via WeChat, AliPay, and TRC20. A 30-day subscription will set you back between between $8 and $12 USD, depending on the tier.
After purchasing, we’re able to access a “subscription URL” that points to a base64-encoded file containing our proxy node configurations. This URL is loaded into the Trojan-capable proxy application of your choice. In this case, we’ll use Txray, a popular terminal-based application built on Xray core.
Using Txray, we can see our node listing. Let’s check out one of these IP and port pairs (in the column to the right). Given our knowledge that this socket must return an SSL certificate, we can use openssl to inspect it and get what we’re after…
And there it is. Granted, this is just the entry or gateway IP address. However, actually using these nodes results in exit IP addresses that also have our golden certificate here present.
Verification: Linking APT Activity to WgetCloud Nodes
So, we can conclude the Singapore IP address reportedly used by this threat actor belongs to this service, WgetCloud. Whether or not they purchased a subscription or acquired this particular Trojan proxy through other means is unknown. This highlights the broader risk of APT proxy infrastructure blending into commercial offerings.
Spur has labeled all WgetCloud nodes (~1,700 at time of writing) as WGETCLOUD_PROXY across all products: Monocle, Context API, and our Data Feeds. This ensures our customers benefit from threat intelligence on Chinese proxies and other anonymizing services used in cyber campaigns.
How Spur Helps Overcome Attribution and Proxy Detection Challenges
The challenges highlighted in this post—uncertain attribution, anonymized infrastructure, and the difficulty of separating commercial proxy services from APT infrastructure—are the same issues our customers face daily. Spur addresses these challenges by:
- Unmatched Coverage and Fidelity: Spur tracks over 54 million+ active anonymous IPs, 500+ VPN services, and 160+ proxy services, delivering the highest-fidelity IP intelligence available. Our data is transparent, fresh, and actionable—with a consistently low false-positive rate.
- Focusing on Blind Spots Others Miss: Unlike traditional providers, Spur delivers visibility into residential proxies, mobile IPs, malware-based proxy networks, and bot infrastructure, where attackers hide to evade detection.
- Actionable Enrichment for Attribution: By adding context such as proxy/VPN status, ASN, device type, and tunnel entry/exit details, Spur enables more effective attribution of adversary tradecraft.
- API-First and Analyst Friendly: Spur integrates directly into SIEM, SOAR, fraud detection, and threat intelligence platforms. Our real-time API and historical datasets support both inline prevention and forensic investigations.
- Business Outcomes that Matter: Customers reduce fraud losses, improve analyst efficiency, and lower infrastructure costs. For example, a leading bank have seen a 40%+ drop in account takeovers by enriching authentication sessions with Spur data.
Through these capabilities, Spur empowers security and fraud teams to see through anonymization, attribute activity more effectively, and disrupt attacker infrastructure before it can be leveraged at scale.
Get Started with Spur
Ready to see how Spur can strengthen your defenses against anonymized infrastructure? Try it for free or contact us to determine how Spur can assist with your IP enrichment and VPN/proxy detection challenges.
Frequently Asked Questions
Why does identifying proxy infrastructure matter?
Attribution and threat hunting become far more effective when anonymization layers like proxies and VPNs are identified and labeled.
How does Spur detect these services?
Spur combines large-scale IP intelligence collection with fingerprinting methods, enrichment, and continuous monitoring.
Can benign users also use WgetCloud?
Yes, commercial services are often used by both legitimate users and threat actors, which makes contextual labeling critical.
Where can I learn more?
Learn more at our solutions pages for IP data feeds for VPN/proxy detection; IP enrichment APIs; and session-based detection of residential proxies and bots.
