OP-512 Alert: New Custom Web Shell Framework Targeting IIS
Hey everyone,
Just caught the latest report from ReliaQuest regarding the new threat cluster OP-512. They’ve linked this activity (with moderate to high confidence) to Chinese state-sponsored actors, and it’s specifically gunning for Microsoft IIS servers.
The scary part here isn't just another credential dump; it's the deployment of a bespoke web shell framework. Since the malware is custom-built, standard signature-based detection (AV/EDR) is likely to miss it initially until heuristics catch up. The "OP" designation stands for "opponent," and their focus on espionage suggests persistence is key.
Immediate Actionable Steps
I highly recommend auditing your inetpub directories for any suspicious script additions, particularly in less commonly monitored extensions.
You can use the following PowerShell snippet to hunt for recently modified ASP.NET files in your web root:
$Date = (Get-Date).AddDays(-7)
Get-ChildItem -Path "C:\inetpub\wwwroot" -Recurse -Include *.aspx, *.asmx, *.ashx, *.config |
Where-Object { $_.LastWriteTime -gt $Date -or $_.CreationTime -gt $Date } |
Select-Object FullName, LastWriteTime, Length
Additionally, check your IIS logs for patterns consistent with web shell communication—often short POST requests with specific cookies or User-Agents.
We need to assume they are already inside some networks. Is anyone else seeing anomalies in their IIS logs that match this profile, or are we mostly blind until full IoCs drop?
Great post. From a SOC perspective, we're tuning our SIEM rules for IIS POST requests to URLs that don't exist in the sitemap but return 200 OK. Also, looking at the User-Agent strings—if they're static, it's a dead giveaway. We're using this KQL query in Sentinel:
W3CIISLog
| where sPort == 80 and scStatus == 200
| where csMethod == "POST"
| summarize count() by csUriStem, csUserAgent
| where count_ > 100
High frequency from a single stem usually equals a shell.
I've been removing unused ISAPI extensions and CGI binaries on our IIS boxes as a precaution. If the framework is custom, they might be leveraging obscure modules. Also, enabling Advanced Audit Policy for 'File System' on C:\inetpub is a lifesaver for knowing when a file touched the disk, even if the malware tries to hide its timestamps. Don't forget to check the appcmd.exe history if you suspect config changes!
Bespoke frameworks often bypass standard WAFs because they don't look like China Chopper or ASPXSpy. They might use steganography in images or valid-looking traffic. If you're pentesting IIS, check for non-standard DLLs loaded into the w3wp.exe process memory using Process Hacker or similar. Sometimes the shell isn't a file on disk at all, just a memory-resident module.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access