ReliaQuest has identified a threat cluster named OP-512 deploying custom web shell frameworks against Microsoft IIS servers, with moderate to high confidence attribution to China-based actors. The framework uses timestomping and other anti-forensic techniques to evade signature-based detection systems. This is significant because your existing detection rules—built to catch known web shell signatures—won't trigger when attackers create their own tools.
Custom Frameworks: A New Threat
OP-512 marks a shift from using common web shells to creating frameworks tailored for specific environments. Instead of using publicly available variants like China Chopper or ASPXSpy, these actors have developed custom IIS modules that mimic legitimate server activity. The timestomping technique alters file timestamps to match surrounding system files, making timeline analysis unreliable. Your incident response team can't rely on filesystem metadata to determine when the compromise occurred.
The focus on IIS—rather than Apache or nginx—suggests attackers are conducting reconnaissance to tailor their tools to your infrastructure. This invalidates the "deploy everywhere" approach to web shell detection.
Key Findings
Custom frameworks evade signature detection. OP-512's web shell doesn't match known YARA rules, hash databases, or string patterns because it's unique. Your endpoint detection system that flags "eval(base64_decode())" won't catch a compiled IIS module with legitimate-looking function names. The framework likely includes multiple variants to avoid detection across different environments.
Timestomping disrupts forensics. When investigating a suspected compromise, you typically look for recently modified files in web directories. OP-512 sets file timestamps to match IIS installation dates or last patch cycles. During an investigation, you might see a web shell with a modification date of 2019 next to your current application code. Without behavior-based monitoring, you'll miss it during manual sweeps.
Legacy IIS deployments are vulnerable. Organizations running IIS 7.5 or 8.0 on Windows Server 2008 R2 through 2012 R2 have systems that receive only critical security patches—if they're still under extended support. These servers often host internal applications that are difficult to migrate. OP-512 actors exploit this vulnerability.
Anti-forensic techniques assume scrutiny. The sophistication of OP-512's evasion methods—timestomping, custom compilation, IIS-native modules—indicates that threat actors expect detection attempts. If you're running IIS in production, assume you're being profiled as a potential target.
Implications for Your Team
Your current web shell detection strategy likely relies on file integrity monitoring, signature-based scanning, and log analysis. OP-512 defeats all three by deploying as an IIS module (which modifies server behavior without dropping obvious files), using custom code (no signature matches), and generating traffic that resembles legitimate administrative activity.
This creates a detection gap where your tools report "all clear" while attackers maintain access. The gap widens if you're running legacy IIS versions that don't support modern logging extensions or security features introduced in IIS 10.0.
For compliance frameworks, this matters under NIST CSF v2.0 function DE.CM (Detection Processes and Procedures), which requires continuous monitoring capabilities that can identify anomalous activity. Signature-only detection doesn't meet this requirement when facing custom threats. Under PCI DSS v4.0.1 Requirement 11.3.1, you must maintain intrusion detection systems that monitor all traffic at the perimeter and critical points in the cardholder data environment—but IIS module-level activity happens inside the trust boundary where many teams have limited visibility.
Action Items by Priority
Immediate: Deploy behavior-based IIS monitoring. Configure Windows Event Log to capture IIS module loads (Event ID 2280) and monitor for unexpected w3wp.exe child processes. Enable Failed Request Tracing for your application pools to capture unusual handler execution patterns. This provides visibility into module-level activity that file scanning misses.
Week 1: Audit IIS module installations. Run appcmd.exe list module on each IIS server and compare results against your configuration baseline. Investigate any module you didn't intentionally install. Document your legitimate module inventory now—before you need it during an incident. Create a detection rule that alerts when the module list changes.
Week 2: Implement request timing analysis. Web shells typically execute OS commands that take longer than normal application responses. Configure your web application firewall or reverse proxy to log response times and alert on requests to .aspx/.ashx endpoints that exceed 5 seconds. Combine this with user-agent analysis—many web shell management tools use distinctive client signatures.
Month 1: Upgrade legacy IIS deployments. Identify every IIS instance running version 8.5 or earlier. For systems that must remain on legacy versions, implement network segmentation so they can't reach external networks directly. Deploy a forward proxy that logs all outbound connections and blocks non-business-justified destinations. This contains post-compromise activity even if initial access succeeds.
Month 2: Add process execution monitoring. Deploy Sysmon or your EDR tool's equivalent to log process creation events (Sysmon Event ID 1) where the parent process is w3wp.exe. Normal IIS operation rarely spawns cmd.exe, powershell.exe, or net.exe. When it does, you want to know immediately. Configure alerts for any w3wp.exe child process that isn't your application's documented behavior.
Quarter 1: Test detection against custom payloads. Don't just run Metasploit's web delivery module and call it validated. Write a simple custom ASPX handler that executes "whoami" and returns the result. Deploy it through your change control process. Does your monitoring catch it? If not, your detection strategy has a blind spot that OP-512-style attacks will exploit.
By following these steps, your team can better protect against the evolving threat of custom web shell frameworks like OP-512.
