China-Linked OP-512 Targets IIS Servers With Custom Web Shell Framework

A newly documented threat cluster tracked as OP-512 is targeting Microsoft Internet Information Services servers with a custom web shell framework built for stealth, persistence, and remote access.

Security researchers at ReliaQuest assess with moderate-high confidence that OP-512 is linked to China-aligned espionage activity. The company says the group compromised an IIS server and deployed three custom web shells designed to evade signature-based detection.

The campaign matters because it shows how legacy, internet-facing IIS infrastructure remains a high-value target. OP-512 did not rely only on commodity web shells. It used per-deployment cryptographic uniqueness, automated reporting, and timestomping to make each intrusion harder to detect and investigate.

OP-512 appears to be a distinct China-linked cluster

The The Hacker News report said OP-512 is the fourth China-linked cluster publicly documented targeting IIS servers in the past year. ReliaQuest compared the group’s tactics with CL-STA-0048, GhostRedirector, and DragonRank, but said OP-512 does not match any known actor cleanly.

ReliaQuest said the compromised server showed earlier suspicious activity around 75 days before the main intrusion. The actor later returned and deployed the full web shell framework within hours, which suggests a patient espionage-focused operation rather than a smash-and-grab attack.

The targeted system was running Windows Server 2016 with .NET Framework 4.0. Microsoft’s .NET Framework lifecycle page lists support for .NET Framework 4.0 as ending on January 12, 2016.

Detail	What researchers reported
Threat cluster	OP-512
Attribution	Assessed as China-linked with moderate-high confidence
Target technology	Microsoft IIS servers
Main tooling	Three-part custom web shell framework
Observed environment	Windows Server 2016 with end-of-support .NET Framework 4.0
Main risk	Persistent remote access, command execution, and privilege escalation attempts

The web shell framework is built to avoid signatures

OP-512’s framework used three malicious files: one .aspx file manager and two .ashx command handlers. The first file helped the attacker manage files and report the compromised shell’s location back to attacker infrastructure.

MITRE describes a web shell as a script placed on an accessible web server to give an attacker access to the server and potentially a gateway into the wider network. In OP-512’s case, the web shells were not generic copies. Each deployment was generated uniquely.

The command handlers used cryptographic controls so one implant could not automatically be used to access the other. This design makes simple file-hash blocking weak because each deployment can produce different fingerprints.

• The .aspx file acted as a file manager and self-reporting component.
• The two .ashx handlers provided separate authenticated command paths.
• Each deployment was cryptographically unique.
• The framework reported the web shell location through DNS and HTTP fallback channels.

Timestomping complicated the investigation

OP-512 also used timestomping to make malicious files blend into the server’s existing file history. The framework scanned nearby files, calculated a median timestamp, and changed its own creation and modification times to match surrounding artifacts.

MITRE defines timestomping as modifying file timestamps, often to mimic files in the same folder. This can make recently created attacker files look older than they really are.

For incident responders, this means a simple “new files first” review can miss the web shell. Teams need to compare IIS logs, ASP.NET compilation artifacts, DNS activity, EDR events, and file system metadata instead of relying only on timestamps.

How the attack unfolded on the IIS server

ReliaQuest said IIS worker process w3wp.exe wrote the first web shell into an upload directory. Within seconds, the web shell encoded its own location and sent it to attacker-controlled infrastructure.

The ReliaQuest analysis said the primary notification channel used DNS, while an HTTP request acted as a fallback. The attacker then added two .ashx command handlers protected by separate cryptographic keys.

After establishing access, OP-512 loaded several privilege escalation toolkits directly into memory. Three were tied to the publicly known Potato family of Windows privilege escalation tools. A fourth appeared in telemetry as GhostKit, although ReliaQuest noted that no public documentation exists for a tool by that name.

Attack stage	Observed behavior
Initial persistence	Web shell written to an IIS upload directory
Self-reporting	Web shell location transmitted through DNS, with HTTP fallback
Command access	Two cryptographically protected .ashx handlers deployed
Privilege escalation	Post-exploitation tools loaded into process memory
Defense evasion	Timestomping and per-deployment uniqueness used to reduce detection

Endpoint prevention alone did not stop the activity

ReliaQuest said endpoint protection killed the malicious process after detecting suspicious behavior. However, IIS automatically restarted worker processes, allowing the attacker’s activity to reload across new process instances.

This is a key lesson for defenders. Killing a process can interrupt an attack, but it does not remove the web shell, fix the exposed web application, or isolate the server from attacker control.

The report also said malicious DLLs were later found in ASP.NET temporary compilation directories. Those compiled artifacts can remain even after the original .aspx or .ashx files have been deleted, which gives incident responders another place to hunt.

Why legacy IIS servers remain attractive targets

IIS servers often sit at the edge of a network. They handle external traffic, host business applications, and may connect to internal systems. If they run old frameworks or poorly segmented applications, attackers can use them as a foothold.

Microsoft’s lifecycle documentation shows why older .NET Framework deployments need urgent review. Unsupported framework versions no longer receive security support, which increases risk for internet-facing applications.

The broader pattern also reinforces the same message. The Hacker News noted that other China-linked clusters have also focused on IIS servers, including groups using BadIIS, PlugX, Cobalt Strike, and other custom tooling.

What defenders should monitor

Security teams should prioritize behavior over signatures. OP-512’s web shells were designed to make every deployment look different, so hash-based detection will not cover the full risk.

Defenders should watch for IIS worker processes creating .aspx or .ashx files in upload paths, especially when followed by immediate outbound DNS or HTTP traffic. They should also review ASP.NET temporary compilation directories for unexpected DLL creation.

MITRE’s web shell technique page is useful for mapping this activity to defensive controls because it frames web shells as persistent server-side components rather than one-time malware files.

• Monitor w3wp.exe writing scripts into upload directories.
• Alert on outbound DNS or HTTP traffic immediately after new server-side script creation.
• Inspect ASP.NET temporary compilation directories for unexpected DLLs.
• Review file timestamp anomalies and compare them with web server logs.
• Do not rely only on file hashes for custom web shell detection.
• Isolate affected IIS servers during response, not only the suspicious process.

Recommended hardening steps

Organizations should retire or isolate internet-facing IIS applications that depend on unsupported .NET Framework versions. If migration takes time, teams should add segmentation, strict monitoring, and application-layer controls.

Microsoft’s IIS request filtering documentation describes request filtering as a built-in IIS security feature. Admins can use request filtering, file extension controls, and application rules to reduce the chance that upload directories execute server-side scripts.

Security teams should also disable script execution in upload folders wherever possible. Upload directories should store user files, not execute .aspx, .ashx, or other server-side code.

Control	Why it helps
Retire unsupported .NET applications	Reduces exposure from legacy framework and application flaws
Disable script execution in upload directories	Prevents uploaded server-side files from becoming web shells
Monitor ASP.NET temporary compilation directories	Finds compiled web shell artifacts that can outlast source files
Segment IIS servers	Limits lateral movement from compromised web infrastructure
Use behavioral detections	Catches unique web shells that do not match known hashes

Indicators tied to the reported intrusion

ReliaQuest published indicators from the observed OP-512 intrusion, but warned that they may not appear in future activity. Behavioral patterns should take priority because the framework was designed for uniqueness and infrastructure rotation.

The indicators below are defanged and should be used for hunting, blocking, and enrichment. They should not replace broader detection for suspicious IIS worker process behavior, cryptographic .ashx handlers, and timestamp manipulation.

Type	Indicator	Context
Domain	ashx.lhlsjcb[.]com	DNS C2 domain observed during earlier activity on the same host
Domain	hcgos[.]com	DNS C2 domain used by the self-reporting notification channel
IP address and port	43.160.202[.]246:8053	Meterpreter C2 server on a non-standard port
IP address and port	140.206.161[.]227:443	Outbound connection from the compromised host
IP address	124.156.129[.]151	Source IP associated with web shell interaction

Incident response teams should not stop at file removal

Deleting the visible web shell files is not enough. Responders should determine the original access path, clear compiled ASP.NET artifacts, rotate credentials stored on or reachable from the server, and review outbound traffic around the suspicious windows.

Teams should also validate whether the server touched internal systems after compromise. IIS servers often have access to databases, file shares, APIs, and service accounts, making post-compromise scoping essential.

Because OP-512 used timestomping, defenders should treat file timestamps with caution. MITRE’s timestomp guidance reinforces why attackers manipulate timestamps to hide newly created or modified files from investigators.

What organizations should do now

Organizations running IIS should inventory public-facing servers, identify applications using unsupported .NET Framework versions, and confirm whether upload paths can execute scripts.

Admins should review IIS request filtering settings, add WAF rules where appropriate, and monitor for .aspx or .ashx files appearing in locations that should only hold uploaded content.

The larger takeaway is that OP-512 shows why legacy web infrastructure remains a major espionage target. Signature matching helps, but it will not catch a framework built to generate unique implants. Defenders need segmentation, modernized applications, behavioral monitoring, and full host isolation when IIS compromise is suspected.

FAQ