I’ve been analyzing a lot of public Chinese government data. A little while back, my crawler was looking for materials on a Chinese Communist Party (CCP) education portal when it fell into a tar pit. It looked like someone had landed a command injection attack against them. So I went on a who dun it investigation. Since I’m talking about it, you can probably guess that it wasn’t that type of vulnerability. But it was a fun.
Bottom Line Up Front
One of the remote provinces’ CCP education portals will serve you somebody else’s attack payload if you ask it for page 2 of its news list. It has been doing this since at least December 8, 2025, and the Internet Archive has been crawling and republishing those poisoned links the whole time.
That looks like someone hacked a Chinese government server so you can see why I got very interested in a hurry. The injection payload in the image above comes from a commercial vulnerability scanner. The site never runs the payload, and I can’t find a way that it could be actually dangerous unless you laugh so hard at me that coffee sprays out your nose. Academics would probably call it a vulnerability. It’s operationally useless outside of contrived examples. It’s a bug. That makes this a story I can tell about doing incident response on a Chinese government server. The irony is not lost on me.
Story time
The recursive link. I’ve been analyzing a lot of People’s Republic of China (PRC) government content. I was crawling one of the remote provinces’ CCP education portals when a page returned something odd. The site’s own next page / last page links, had a shell command substitution in the query string. Inside it was a ping to a random subdomain of d[.]360tcp[.]com. That has exactly one purpose. If the server runs the attackers command then the server does a DNS lookup and sends the ping packet. Whoever owns the 360tcp[.]com domain sees the ping packet and knows the server executed their input. Or if the attacker is really good they have passive visibility somewhere in the recursive DNS network so they can see the DNS lookup; then whomever owns 360tcp[.]com gets the blame while the attacker still know their command injection succeeded. This is how you prove a blind command injection in a way that doesn’t burn your real payload if some former-defense-tech-CEO-on-sabbatical with a crawler runs across it then writes a substack article. Finding it on a Chinese government site’s own infrastructure is what a compromise looks like. I admit I giggled a little maniacally when I saw it.
It’s been there for at least eight months. Three pages came back carrying the command injection payload. I only sent a section number and a page number because I (really, my automation) was just crawling and downloading CCP personnel training materials for something else I’m working on. The Internet Archive crawled those poisoned URLs thirteen times since Dec 8, 2025 so we know roughly when it happened.
At that point I did the obvious thing and went looking for a broader attack campaign. I checked 10,746 .gov[.]cn hosts for command injection callbacks. Like I said, I may be doing a lot bit of crawling, downloading, and analyzing.
Bah humbug. The scan only found the tell tale results on the one host. And on that host there was a second callback I didn’t notice until now: reversecheck[.]jiance[.]qianxin[.]com. It’s the QiAnXin cloud scan. QiAnXin is one of the two largest security companies in China. That’s a commercial vulnerability scanner.
The other domain d[.]360tcp[.]com is delegated to a nameserver literally called dnslogns (read that as DNS log nameserver). It’s been registered since 2017 through Alibaba. If you’ve been in offensive cyber for more than a few years then you think of Qihoo (a major Chinese cybersecurity product company) the moment you hear “China” and “360”. But I don’t have any evidence for it. The argument against it is that Qihoo is also a domain registrar so I wouldn’t expect them to register a domain through their Alibaba rival.
There isn’t a vulnerability anyway. Being disappointed with no attacker I went looking for the vulnerability itself, and got disappointed there too. I pulled all 498 archived responses from the host and tested every way the stored string could hurt somebody. There are 1,197 attacker-controllable values sitting inside and across those pages. Zero of them contain an unescaped quote, so none can break out of what it lives in. Zero reach script context. Zero produce a database error. Zero emit an attacker-chosen address as a link destination, so there is no phishing pivot and no search-engine poisoning. And a clean request and a payload-bearing request to the same page return byte-identical bodies, which a server evaluating that parameter would not do.
The site is not running anything. It is remembering. Somebody sent that string, and the server bakes it in.
And that is the tar pit. The site builds its previous/next page links out of whatever query string you hand it, which means the not-really-a-command-injection link regenerates itself on every page it appears on. Every time you go to the “next” link, that next page will encode the command injection payload one level deeper. Every page is new, so a plain duplicate check never catches it, and you can trudge through that tar pit forever. My crawler did, until my own data normalizer stopped and warned me shenanigans were afoot. A command injection by any other name still looks like a command injection.
This was an entertaining diversion. I never expected in my life to be performing incident analysis on a Chinese Government or Chinese Communist Party server.