ReliaQuest's Agentic AI Uncovers New China-Linked Cluster OP-512

Editor’s note: This report was authored by Alexa Feminella

Key Points

• ReliaQuest's Agentic AI surfaced a suspected new China-linked espionage cluster, “OP-512,” by correlating a high volume of seemingly unrelated events at machine speed into one high-priority incident that our threat research experts then validated.

• OP-512 deployed a custom web shell framework to a compromised Internet Information Services (IIS) server. Each deployment is cryptographically unique, making signature-based detection ineffective.

• OP-512 is at least the fourth China-linked cluster documented targeting legacy IIS servers in the past year. Organizations running end-of-life .NET frameworks on internet-facing servers should prioritize migration or segmentation immediately.

ReliaQuest’s Agentic AI recently surfaced what we assess with moderate-high confidence to be a new China-linked cluster, which we’re tracking as “OP-512.” Our AI agent stitched together a high volume of seemingly unrelated suspicious events across a customer’s environment into one high-priority incident, revealing a coordinated intrusion that manual review alone would have been unlikely to reconstruct at the same speed, if at all. ReliaQuest threat research analysts then reviewed and validated the findings.

OP-512 was highly likely conducting espionage through a compromised Internet Information Services (IIS) web server on an organization whose sector and geography align with China-linked intelligence priorities. Despite sharing techniques with broader China-linked threats, OP-512’s tools, infrastructure, and operational profile don’t match any known actor. It's at least the fourth China-linked cluster publicly documented targeting IIS web servers in the past year. But its tooling is built to evade the defenses that work against the other three.

At the center of the operation is OP-512’s custom web shell framework, consisting of three web shells (malicious files that give attackers remote access through a web browser). This framework combines capabilities we rarely see together: Each deployment is uniquely generated, access is restricted to the attacker through cryptographic controls, and compromised servers automatically report back for centralized management at scale.

The investigation also showed clear intent to stick around. The targeted server showed signs of access 75 days earlier. But rather than moving on, the attacker returned, a hallmark of state-aligned espionage. Within hours, the attacker deployed web shells, established multiple command channels, and escalated privileges.

In this report, we:

• Map OP-512 against known China-aligned operations and explain our attribution assessment.

• Walk through the full attack chain and show why endpoint prevention alone failed to stop it.

• Analyze the web shell framework's design with detection guidance beyond traditional signatures.

Where OP-512 Fits In and Where It Stands Alone

OP-512 is at least the fourth China-linked cluster documented to be targeting IIS servers in the past year. It shares narrow tactical overlaps with each but matches none of them, making it highly likely to be a previously unseen addition to an already crowded attack surface. Espionage clusters aren’t smash-and-grab operations; they’re built for patience, maintaining access for months—or years—before acting on their objectives (commonly IP theft, communications monitoring, or future operations). Detection rules tuned to known groups likely won’t catch OP-512, and the longer it goes undetected, the deeper it embeds.

Figure 1 provides a high-level overview of the attack chain. In this section, we’ll first explain why we believe OP-512 is highly likely a new cluster, then dig into the technical details.

Figure 1: High-level attack chain

There's a reason these four China-linked clusters have converged on the same technology. IIS servers in a demilitarized zone (DMZ) sit at the boundary between internet-facing and internal networks. They often receive less monitoring than core infrastructure, which is why espionage operators looking to move inward to use them as pivot points.

So why do we think OP-512 is distinct? We compared this incident's tooling, infrastructure, and objectives against the three China-linked operations most active against similar targets over the past year.

“CL-STA-0048” is the closest match. Both operations use DNS-based covert signaling with encoded data embedded in subdomain strings, a technique public reporting has highlighted as rare. But the two serve different purposes. CL-STA-0048 encodes stolen data into subdomain strings to exfiltrate it. OP-512 encodes each web shell's own URL into a DNS query to report its deployment location back to attacker infrastructure. The encoding method is the same, but the intent is different.

Hex-encoded subdomain queries are uncommon enough that their presence in both operations is unlikely to be coincidental. It suggests shared tooling, shared training, or a direct operational relationship. Researchers have noted connections across these clusters while continuing to track them separately, pointing to a broader ecosystem drawing from shared resources rather than a single coordinated operation.

Where OP-512 Breaks Away in a Crowded Hunting Ground

Where this cluster diverges is in sophistication. The web shell framework uses per-deployment cryptographic uniqueness, RSA and RC4 authentication, and timestomping (the deliberate manipulation of file timestamps to disguise when a file was created or modified). This ensures each instance evades signature-based detection, restricts access through layered encryption, and obscures forensic timelines. That combination of capabilities, especially the per-deployment cryptographic uniqueness, goes well beyond the commodity tools typically used by financially motivated groups like “GhostRedirector” and “DragonRank.”

It's realistically possible OP-512 represents an existing cluster that has entirely retooled, with CL-STA-0048 as the strongest candidate. The shared use of hex-encoded DNS subdomain queries makes that plausible. However, CL-STA-0048 has historically relied on widely available tools like “PlugX” and “Cobalt Strike.” OP-512's framework represents a fundamentally different level of investment in custom tooling and operational security, one that is difficult to reconcile with CL-STA-0048's documented capabilities.

It's also possible CL-STA-0048 developed these capabilities independently, but doing so without any continuity in infrastructure, implants, or targeting patterns would be unusual. Combined with the unique framework and dedicated infrastructure, we assess with moderate-high confidence that OP-512 is a distinct cluster operating independently.

With attribution established, the next section walks through how the intrusion unfolded and why endpoint prevention alone couldn't stop it.

75 Days of Patience, Then a Sprint

The compromised server was running Windows Server 2016 with end-of-life .NET Framework 4.0, a framework that hasn't received security updates since 2016. EDR telemetry had flagged web shell activity on the same host 75 days earlier, including DNS queries to a different attacker-controlled domain (ashx.lhlsjcb[.]com). The specific access path wasn't conclusively determined, though the legacy .NET 4.0 application on an internet-facing host presents a plausible attack surface.

What followed was fast and methodical.

Dual Notification Channels Established in Seconds

The web server's worker process (w3wp.exe) wrote the first of three web shells to the application's upload directory: a .aspx file manager with a built-in C2 notification channel. Within seconds, the self-reporting notification kicked in, transmitting the web shell’s location through two independent channels. The primary channel was a DNS query to an attacker-controlled domain. If the DNS query failed, the web shell fell back to an HTTP request to a separate command-and-control (C2) server, carrying the same encoded path. Community reporting has linked the fallback server's IP address to “Meterpreter” infrastructure.

These notifications are one-way. They report the location but don't receive commands. The actual command interface came next: Two .ashx cryptographic command handlers, each gated by the RSA+RC4 authentication (explored in detail later in this report), were deployed to the same directory shortly after. Together, the three web shells gave the attacker file management, authenticated command execution through two independent access paths, and automated reporting of the compromise, all before anyone had time to respond.

Privilege Escalation Tools Loaded Straight into Memory

With the web shells in place, the attacker moved to escalate privileges. They loaded four post-exploitation toolkits directly into the web server's process memory. Nothing was written to disk.

Three of these came from the publicly documented “Potato Suite” (“BadPotato,” “SweetPotato,” “EfsPotato”), a well-documented collection of Windows exploits that abuse built-in services to elevate access from a limited-service account to SYSTEM-level privileges. These tools appear frequently in China-linked operations, including CL-STA-0048 and GhostRedirector, making their presence here another attribution data point. A fourth toolkit was flagged in EDR telemetry as "GhostKit." No public documentation exists for a tool by this name, and it's likely a vendor-specific telemetry label rather than an established tool.

The only telemetry that caught this was EDR behavioral analytics detecting reflective .NET assembly loading within the w3wp.exe process. Without it, the activity would’ve been invisible.

The attacker then ran whoami and whoami /priv to check their account context and privileges, both issued as base64-encoded strings. Interestingly, the encoded commands matched character-for-character with the same commands we documented in the “Flax Typhoon” ArcGIS compromise. Identical encoding across two separate China-linked operations points to highly likely shared tooling or playbooks circulating within this ecosystem. The commands ran under a limited-service account, confirming the privilege escalation hadn't yet succeeded.

Prevention Fired, but the Attacker Stayed

Endpoint protection terminated the malicious process through behavior-based prevention. However, IIS automatically restarts worker processes when they crash or are killed, so the attacker's tooling reloaded across multiple successive process instances within minutes. Killing the process without isolating the host created a loop. Prevention fired repeatedly, but the activity continued.

Malicious DLLs That Outlast the Web Shells

Four malicious Dynamic Link Library (DLL) files were recovered from the ASP.NET temporary compilation directory on the compromised host. These are compiled artifacts that the .NET runtime automatically generates when .aspx or .ashx files are first accessed—in this case, the three web shells. They were detected and quarantined approximately 19 hours after creation.

Critically, these compiled DLLs persist even after the original web shell files are deleted. For incident responders, that means removing the web shells alone isn't enough. The ASP.NET temporary compilation directories need to be hunted down and cleared separately, or the compiled artifacts will remain on disk as forensic evidence and potential reactivation points.

A Cryptographically Locked Web Shell Framework

In the previous section, we walked through what OP-512 did with these web shells. In this one, we break down how they work and why they're so difficult to detect.

Three samples were recovered, which fall into two categories:

All three web shells include timestomping, the deliberate manipulation of file timestamps to disguise when a file was created or modified. A common forensic technique is to sort files by modification date to spot recently written artifacts. A web shell dropped in 2026 among files last modified in 2022 would stand out immediately. To counter this, the web shells scan every file and subdirectory around them, calculate the median last-modified timestamp, and overwrite their own creation and modification times to match. As a result, the web shells look like they’ve been there for years.

The function also accepts an explicit timestamp as input, giving the operator the option to backdate a file to a specific event or patch window rather than relying on the automatic calculation.

Drop It and Forget It: The Web Shell That Phones Home

The .aspx file manager was the first web shell deployed and the only one with a built-in C2 notification channel. This web shell's C2 channel activates whenever the page is visited, whether by the operator, an automated scanner, or even a legitimate user navigating to the URL. On activation, it encodes the web shell's own URL and transmits it as a DNS query to an attacker-controlled domain. If the DNS query fails, it falls back to an HTTP request to a separate C2 server carrying the same encoded path. A five-minute cooldown prevents repeated transmissions.

Beyond the notification, the shell provides standard file system operations: directory listing, read/write, upload, delete, rename, and the timestomping described earlier.

The design decouples deployment from discovery. The operator drops the file and moves on, knowing their infrastructure will catalog its location automatically. For defenders, this means any access to the web shell, even during incident response, may alert the attacker. Treat suspected web shell files as already compromised before interacting with them.

Cryptographically Authenticated Command Handlers

The two command handlers (.ashx files) follow the same structural pattern but were generated with different cryptographic keys. Identical code structure, combined with randomized variable and method names across both samples, strongly suggests an automated builder producing unique instances from a shared template.

The comparison (See Figures 2 & 3) shows the RC4 decryption function from both handlers. The algorithm is identical, but every variable and method name has been randomized. The builder also injects dead variables (_nkkspqwc = 1534 in one, _nbgrzrak = 6392 in the other) and junk comments (// rmluimqjmidu) that serve no functional purpose. The result: two files that perform the same operation but produce completely different file hashes, rendering signature-based detection useless.

Figure 2: RC4 decryption function — Command Handler 1

Figure 3: RC4 decryption function — Command Handler 2

When a command is received, the web shell processes it through four stages:

1. Base64 decode the HTTP request body

2. RC4 decrypt the resulting payload

3. Verify the RSA signature against the embedded public key

4. Execute the command only if verification succeeds

Each handler embeds a unique RSA public key. Without the corresponding private key, no-one can issue commands, not defenders, nor threat actors, not even another OP-512 operator using a different key pair. The layered encryption and signature verification also make command traffic difficult to inspect or replay at the network layer.

The two handlers on this server were deployed with different RSA keys, meaning they require different private keys to operate. This could represent separate operator access, distinct access tiers, or key rotation. Regardless, it reflects deliberate compartmentalization. Compromising one key doesn't grant access to the other implant.

Behavioral Telemetry Is the Only Path Forward

By now the pattern is clear. Nothing about this framework is static. The hashes change every deployment, code is obfuscated, and command traffic is encrypted. Signature-based detection may not catch it, but here’s what will:

Step Up Your Defenses Against China-Linked Espionage

ReliaQuest’s Approach

The critical window in this intrusion was minutes, not hours. By the time endpoint protection generated an alert, the attacker had already multiple access paths in place. In fast-moving intrusions like these, where early detection depends on speed and correlation, ReliaQuest GreyMatter—especially GreyMatter Agentic AI—helps security teams detect, contain, investigate, and respond to threats before they escalate.

GreyMatter Agentic AI connects what would otherwise look like isolated, low-fidelity events into a single intrusion narrative—faster than any human analyst could. In this case, web shell creation, outbound DNS activity, dynamically loaded cryptographic components, a command shell spawned from a web server process, and outbound C2 connections all happened within a narrow window. Individually, each event might not trigger an alert, but together, they reveal the full attack chain. As attackers move faster, the ability to correlate complex activity at machine speed and subsequently automatically contain threats is what makes the difference between stopping an intrusion early and responding after damage is done.

GreyMatter Transit detects the self-reporting C2 channel at the earliest possible stage. The web shell transmits its location via abnormally long, hex-segmented DNS queries the moment the page loads. Transit catches these before data reaches storage, provided DNS telemetry is routed through it with visibility into outbound queries from web server hosts.

ReliaQuest Detection Rules: ReliaQuest detection content is continuous updated using the latest relevant threat intelligence.

GreyMatter Automated Response Playbooks address the specific problem we saw in this intrusion when endpoint prevention killed the malicious process, but IIS automatically restarted it. Automated containment removes the window attackers depend on. Organizations can reduce their mean time to contain (MTTC) to five minutes or less by deploying detection rules with the following Automated Response Playbooks:

• Isolate Host: Quarantines the affected server at the first confirmed sign of web shell activity, triggered by w3wp.exe spawning cmd.exe or reflective .NET assembly loading. In this intrusion, earlier isolation would have stopped the attacker from re-establishing access through IIS process restarts.

• Terminate Active Session: Kills active sessions on the compromised host, forcing the attacker to re-establish access. This matters here because IIS automatically restarts worker processes, so killing the process alone isn't enough. Most effective when paired with host isolation.

For faster containment, these Playbooks can be configured to execute automatically upon detection, removing the manual approval step and reducing response time to seconds.

Your Action Plan

These steps directly address the gaps this intrusion exploited.

• Retire or isolate end-of-life .NET frameworks on internet-facing servers: The compromised server was still running .NET Framework 4.0, which has been unsupported since 2016. Prioritize migration or decommissioning. Where that's not immediately feasible, segment these servers from higher-value network tiers, restrict upload functionality, apply web application firewall (WAF) rules, and disable unnecessary IIS handler mappings.

• Harden and monitor upload directories and compilation paths: Disable script execution in upload directories via IIS handler mappings for .aspx, .ashx, .asp, and .asmx files, and verify with a dedicated web.config. Monitor ASP.NET temporary compilation directories for new DLL creation outside normal deployment windows.

• Don't close incidents until the root cause is fixed. Blocking outbound traffic or removing a web shell addresses the symptoms, not the entry point. Espionage clusters count on this, knowing they can return if the underlying vulnerability is still there. Incident closure should require confirmation that the exploited access path has been remediated.

Key Takeaways and What’s Next

Four China-linked clusters targeting the same technology in under a year is unlikely to be a coincidence. Internet-facing IIS servers running legacy, unsupported software remain a preferred entry point across this threat ecosystem and show no signs of slowing down.

What should concern defenders most is what makes OP-512 different. This threat cluster isn't using commodity tooling and recycling it across campaigns. It's using a purpose-built framework designed to defeat the detection methods that work against the other three clusters. Organizations that have tuned their defenses to known actors are likely not covered here.

ReliaQuest assesses that attacks on legacy IIS infrastructure will likely continue through 2026 and 2027, as long as these servers remain online. Organizations still running end-of-life .NET frameworks on internet-facing servers should treat this as a direct signal to fast-track migration plans and prioritize behavioral monitoring in the interim.

IOCs

These indicators are specific to this intrusion and may not appear in future OP-512 operations. Behavioral detections should take priority. The patterns most likely to persist across deployments are the self-reporting C2 structure (hex-encoded URL segments transmitted as DNS subdomains), IIS worker processes initiating outbound DNS or HTTP immediately after web shell file creation, and RSA+RC4 authentication in .ashx handlers.

Sources

¹ hxxps://www.imda.gov[.]sg/assets/a5395ab6-7388-4c1e-97db-18bdf654e163.pdf ² hxxps://thehackernews[.]com/2025/09/ghostredirector-hacks-65-windows.html ³ hxxps://thehackernews[.]com/2025/02/dragonrank-exploits-iis-servers-with.html